에이전트가 '팀'처럼 움직이려면 구조가 필요하다
코딩 에이전트가 코드를 생성하는 것과, 소프트웨어 작업을 완결하는 것은 다른 문제다. 그 사이에는 메모리, 실행 경계, 검증, 복구, 권한, 그리고 딜리버리 인프라가 필요하다. 지금 많은 팀이 에이전트 도입을 시도하지만, 정작 이 구조를 설계하지 않고 에이전트를 그냥 '대화 상대'로만 쓰고 있다. 그 결과는 예측 불가능한 결과물, 무너지는 품질, 그리고 결국 팀원의 번아웃이다.
최근 공개된 세 가지 시도—Agent OS의 로컬 우선 코딩 에이전트 아키텍처, Human-in-the-Loop 거버넌스 설계론, AI Council 딜리버리 시스템—는 각기 다른 문제를 다루는 것처럼 보이지만, 실제로는 하나의 질문에 대한 답을 조각조각 내고 있다. 팀이 에이전트를 어떻게 조직화할 것인가.
첫 번째 구조: 역할을 분리하라
Agent OS(dev.to)가 제안하는 핵심은 단순하다. '생각하는 에이전트'와 '실행하는 에이전트'를 분리하라는 것이다. Main Agent는 대화, 계획, 프로젝트 메모리, 오케스트레이션을 담당하되, 저장소 코드를 직접 편집하거나 셸 명령을 실행할 수 없다. Coding Agent는 샌드박스 내에서 파일 검사, 코드 편집, 제한된 명령 실행을 수행하지만, 프로젝트 메모리를 수정하거나 다른 프로젝트 워크스페이스에 접근하는 건 불가능하다.
이 구조가 왜 중요한가? 팀 환경에서 에이전트는 하나가 아니다. 동시에 여러 컨텍스트를 처리해야 하고, 한 에이전트의 실수가 다른 워크플로우에 번지는 상황을 막아야 한다. 역할을 분리하고 샌드박스 경계를 명확히 하면, 병렬 에이전트 팀을 격리된 워크스페이스에서 운영할 수 있다. 내일 당장 팀에 적용할 수 있는 가장 실용적인 원칙이다.
중요한 건 '완료 선언'을 에이전트 스스로 하게 두지 않는 것이다. Agent OS는 실제 빌드나 테스트 커맨드 통과를 완료의 기준으로 삼고, 브라우저 플로우 실행, 스크린샷 캡처, 시각적 검토, 실패 분류, 제한된 복구 패스까지 포함한 검증 체인을 설계했다. Git 푸시, PR, 배포, 데이터베이스 마이그레이션은 명시적 확인 계약을 통해서만 실행된다. 에이전트가 '아마 원했겠지'라고 추론해서 외부 시스템을 조용히 변경하는 건 허용하지 않는다.
두 번째 구조: Human-in-the-Loop를 체크박스로 쓰지 마라
'Human-in-the-Loop'는 대부분의 에이전트 아키텍처 다이어그램에 등장하고, 거버넌스의 상징처럼 쓰인다. 그런데 dev.to의 거버넌스 설계 아티클은 불편한 진실을 짚는다. 현실의 HITL 대부분은 거버넌스가 아니라 승인 도장이다.
하루에 40번 팝업을 마주한 팀원은 결국 내용을 읽지 않고 승인한다. 모든 쓰기 작업에 인간 개입을 요구하는 단순 정책은, 오히려 인간이 반사적으로 승인하도록 훈련시킨다. 그 결과 감사 로그에는 '인간이 승인했다'고 남지만, 실제로는 아무도 검토하지 않은 상태가 된다.
핵심 재설계 원칙은 세 가지다.
첫째, 데이터가 아니라 결정을 보여줘라. 에이전트가 실행하려는 SQL 쿼리 원문을 그대로 보여주는 게 아니라, '신뢰도 60%의 비가역적 삭제 1건, 틀렸을 경우 야간 백업에서 복구 가능'이라는 형태로 요약해야 한다. 지친 팀원이 판단할 수 있는 건 파싱이 아니라 맥락이다.
둘째, 정말 위험한 것에만 인터럽트하라. 가역성, 영향 범위, 에이전트 자신의 신뢰도를 기준으로 ALLOW / REVIEW / BLOCK 세 가지 결과로 라우팅하는 구조가 필요하다. 1,200명에게 이메일을 보내는 비가역적 작업은 인간 승인 팝업이 아니라 아키텍처 레벨에서 BLOCK으로 처리해야 한다. 승인 게이트가 자주 울릴수록 중요한 게이트의 신뢰도는 떨어진다.
셋째, '거부'에 실제 경로를 줘라. 거부 버튼을 누르면 에러가 나거나 워크플로우가 멈추는 구조라면, 팀원은 금방 '거부는 뭔가를 망가뜨리는 버튼'이라는 걸 학습한다. 거부는 더 안전한 대안 실행, 에이전트 재계획, 상위 권한자 에스컬레이션, 축소된 상태의 우아한 완료 중 하나로 연결되어야 한다.
역설적이지만, 좋은 거버넌스 설계는 인간 개입을 줄이는 방향으로 간다. 감시 용량은 작고, 불필요한 개입은 그 용량을 소모시킨다.
세 번째 구조: 대화가 아니라 아티팩트가 워크플로우를 통제하게 하라
dev.to의 AI Council 딜리버리 시스템 사례는 멀티 에이전트 운영의 실질적인 병목을 정확히 짚는다. 에이전트를 '대화 상대'로만 쓰면, 인간이 모든 핸드오프의 접착제가 된다. 결정이 긴 채팅 속 어딘가에 묻혀 있고, 다음 에이전트가 그걸 해석해야 하며, 팀 리드는 컨텍스트를 머릿속에서 계속 재조립해야 한다.
대안은 상태를 아티팩트로 외부화하는 것이다. 증거는 소스 기반 브리프가 되고, 결정은 승인된 스펙이 되고, 스펙은 경계가 명확한 구현으로 이어지고, 구현은 독립적으로 감사된다. 스펙 상태가 approved면 실행 에이전트가 진행하고, draft면 멈춘다. 에이전트는 추측하지 않는다.
역할도 안정적인 커맨드로 고정했다. /source-architect, /spec-executor, /execution-auditor처럼 역할을 커맨드화하면, 매번 프롬프트를 재조립할 필요 없이 동일한 경계와 정지 조건으로 에이전트를 호출할 수 있다. 역할 드리프트가 줄고, 팀 리드의 컨텍스트 전환 비용도 떨어진다.
감사 이후의 수정 워크플로우도 중요하다. 감사 발견사항을 바로 실행 에이전트에게 돌려보내면 안 된다. 올바른 발견이 잘못된 수정으로 이어질 수 있기 때문이다. 구현 → 독립 감사 → 수정 계획 → 독립 계획 리뷰 → 수정 구현 → 재감사라는 순서가 필요하다. 이 사례에서 계획 리뷰 단계가 없었다면, 기존 디렉토리 컨벤션을 뒤집고 다른 워크플로우에 영향을 미치는 수정이 그대로 반영될 뻔했다.
세 구조가 맞물릴 때 팀이 얻는 것
이 세 기사가 개별적으로 다루는 문제들—역할 분리, 거버넌스 게이트 설계, 아티팩트 기반 워크플로우—은 사실 하나의 운영 아키텍처를 구성한다.
- 역할 분리는 에이전트가 자기 권한 밖의 일을 하지 않게 막는다.
- 샌드박스 실행과 검증 체인은 에이전트 스스로의 완료 선언을 신뢰하지 않게 한다.
- 스마트한 인간 개입 게이트는 중요한 결정에만 팀원의 주의를 집중시킨다.
- 아티팩트 기반 상태 관리는 팀 리드가 대화를 재구성하지 않고도 여러 워크플로우를 동시에 감독할 수 있게 한다.
이 구조가 없으면 에이전트는 빠른 것처럼 보이지만 팀 리드가 더 바빠진다. 이 구조가 있으면, 팀 리드는 중요한 판단에만 개입하고 나머지는 에이전트가 경계 안에서 자율적으로 처리한다.
팀에 당장 적용할 수 있는 체크리스트
내일 팀 미팅에서 꺼낼 수 있는 질문들이다.
- 우리 팀의 에이전트는 '계획하는 역할'과 '실행하는 역할'이 분리되어 있는가, 아니면 하나의 에이전트가 모든 걸 하고 있는가?
- 에이전트의 완료 선언은 실제 빌드/테스트 통과로 검증되는가, 아니면 모델의 자체 주장을 그대로 받아들이고 있는가?
- 팀원이 하루에 몇 번이나 에이전트 승인 요청을 받는가? 그 빈도가 높다면, 정말 위험한 승인을 놓치고 있을 가능성이 높다.
- 거버넌스 결정이 대화 속에 묻혀 있는가, 아니면 명시적 아티팩트로 외부화되어 있는가?
- 에이전트의 '거부' 경로가 설계되어 있는가, 아니면 에러나 워크플로우 중단으로 이어지는가?
전망: 에이전트 조직화는 소프트웨어 아키텍처다
에이전트 도입이 성숙해질수록, 팀이 에이전트를 조직화하는 방식이 곧 그 팀의 소프트웨어 아키텍처 수준을 드러낼 것이다. 역할 경계가 없는 에이전트는 권한이 없는 팀원과 같다. 검증 없는 완료 선언은 테스트 없는 배포와 같다. 형식적인 HITL은 리뷰 없는 PR 승인과 같다.
좋은 소식은, 이 세 기사가 보여주듯 실전 검증된 패턴이 이미 나오고 있다는 것이다. 나쁜 소식은, 이 구조를 설계하는 건 여전히 사람의 몫이라는 것이다. AI가 에이전트를 조직화해주지는 않는다. 그 아키텍처를 설계하고 유지하는 팀 리드의 판단이 AI-First 팀의 진짜 경쟁력이 된다.