에이전트를 팀에 풀면 생산성이 올라간다는 건 이제 가설이 아니다. 진짜 질문은 다음이다. 어떤 구조 위에서 에이전트를 굴릴 것인가. 최근 공개된 세 가지 사례—535개 에이전트가 자율 운영되는 멀티에이전트 플랫폼, 프로덕션 등급 에이전트 하네스 패키지 설계, 그리고 AI 생성 MVP 스프린트 전 의사결정 메모—는 서로 다른 레이어에서 같은 질문에 답하고 있다. 에이전트를 투입하기 전, 설계를 먼저 확정하라.
레이어 1: 에이전트 간 협업 구조를 어떻게 설계할 것인가
dev.to에 공개된 pcell.si 프로젝트는 코딩 경력이 20년간 단절됐던 개발자 한 명이 Claude Code로 3주 만에 구축한 멀티에이전트 플랫폼이다. 현재 545개의 에이전트가 자율적으로 지식 클레임을 생성하고, 피어 리뷰를 수행하며, 평판 포인트를 획득하고 소비한다. 인간 모더레이터는 없다.
이 시스템이 작동하는 핵심은 세 가지 경량 메커니즘이다. 신뢰도 80% 미만의 작업만 피어 리뷰를 트리거하는 신뢰도 게이팅, 2분마다 미할당 태스크를 에이전트 역량 레지스트리와 매칭하는 역량 기반 라우팅, 그리고 신뢰 등급 에이전트 두 명 이상이 '유용함'에 투표하면 자동 승인되는 합의 기반 수락이다. 복잡한 P2P 네트워크도, 블록체인도 필요 없다. 에이전트마다 Ed25519 서명으로 비부인성 신원을 부여하고, 모든 행동을 감사 가능한 행동 원장에 기록한다.
여기서 팀 리빌딩 맥락의 시사점은 명확하다. 에이전트 협업 구조를 설계할 때 '얼마나 강력한 에이전트를 쓸 것인가'보다 '어떤 조건에서 에이전트가 독립 실행하고, 어떤 조건에서 검증을 요구할 것인가' 를 먼저 정의해야 한다. 신뢰도 임계값, 역량 도메인 분류, 합의 기준—이 세 가지가 멀티에이전트 시스템의 실질적인 거버넌스 레이어다.
레이어 2: 프로덕션에서 에이전트 행동을 어떻게 통제할 것인가
dev.to의 Agent Series 20편은 데모용 900줄짜리 단일 파일을 실제 임포트 가능한 패키지로 리팩토링하는 과정을 다룬다. 핵심은 8중 방어 레이어를 모듈로 분리하되, 단일 진입점(AgentHarness)으로 통합하는 설계다.
설계에서 특히 주목할 지점은 두 가지다. 첫째, execute()와 approve_and_execute()를 분리한 것. 에이전트 자동 실행 경로와 인간 승인 경로를 메서드 수준에서 명시적으로 분리함으로써, 코드 레벨에서 '이 액션은 인간이 개입해야 한다'는 의도를 강제한다. approved=False 파라미터 하나로 통합하면 의도가 모호해지고 테스트도 어려워진다.
둘째, IRREVERSIBLE 권한 레벨의 예산 처리 방식이다. 에이전트가 비가역적 액션을 시도하면 execute()는 즉시 예산을 환불하고 HumanApprovalRequired를 발생시킨다. 실제 예산 차감은 approve_and_execute()에서만 일어난다. 사소해 보이지만, 이게 무너지면 에이전트가 거부된 액션의 비용을 계속 소진하면서 예산 추적이 무의미해진다. 프로덕션 에이전트 시스템에서 비용 통제가 생각보다 훨씬 세밀한 설계를 요구한다는 걸 이 사례가 구체적으로 보여준다.
팀 적용 관점에서 이 패키지 구조는 즉시 참조 가능한 템플릿이다. 액션 레지스트리, 예산 관리, 샌드박스, 감사 로그, 롤백 코디네이터—각 레이어를 독립 모듈로 유지하면 팀이 필요한 레이어만 선택적으로 도입할 수 있고, 격리 테스트도 가능해진다. 에이전트 하네스를 처음부터 패키지 설계로 접근하는 것과 데모 코드에서 확장하는 것은 유지보수 비용에서 차이가 난다.
레이어 3: 에이전트가 만든 결과물을 스프린트에 넣기 전 무엇을 확인할 것인가
dev.to에 공개된 AI 생성 MVP 스프린트 전 의사결정 메모는 가장 실용적인 레이어를 다룬다. AI가 클릭 가능한 MVP를 빠르게 생성한 뒤 곧바로 태스크 분해로 넘어가는 관행에 제동을 거는 6단계 체크리스트다.
핵심은 '증명 화면(proof screen)'의 개념이다. MVP에서 단 하나의 화면을 지정해 "이 화면이 기능 완성을 증명하는가"를 묻는다. 이 화면이 여전히 장식적으로 느껴진다면, 그 MVP는 아직 데모다. 또 하나는 '페이크 엣지 케이스' 검증이다. AI가 생성한 플로우는 오너가 없거나, 마감일이 비어 있거나, 아이템이 블록된 상황에서 조용히 무너지는 경우가 많다. 이 질문들을 스프린트 전에 던지지 않으면, 그 무너짐은 팀의 구현 시간이 투입된 뒤에 발견된다.
그리고 '의도적 첫 스프린트 컷'—애널리틱스, 알림, 빌링, 권한 매트릭스, 어드민 설정을 명시적으로 제외하는 것. AI 생성 플로우는 '그럴듯한 완성도'를 가지고 있어서 팀이 불필요한 기능을 먼저 구현하도록 유도하기 쉽다. 이 메모의 존재 이유는 그 유혹을 사전에 차단하는 것이다.
세 레이어를 연결하면 보이는 것
멀티에이전트 협업 구조, 프로덕션 행동 통제 패키지, 스프린트 전 의사결정 메모—이 세 사례는 에이전트 투입의 각기 다른 단계를 다루지만, 공통으로 가리키는 지점이 있다. 에이전트 시스템의 품질은 에이전트 자체의 능력보다 그것을 둘러싼 구조 설계에 의해 결정된다.
신뢰도 임계값을 정의하지 않은 멀티에이전트 시스템은 조정 비용이 폭발한다. 비가역적 액션을 구분하지 않은 하네스는 인간 개입 시점을 놓친다. 증명 화면을 정의하지 않은 AI 생성 MVP는 팀의 구현 시간을 낭비한다. 세 가지 모두 에이전트를 더 좋게 만드는 것이 아니라 에이전트를 감싸는 레이어를 설계하는 문제다.
에이전트 도입 속도가 빨라질수록 이 설계 단계는 더 빨리 밟아야 한다. '일단 붙여보고 정리하자'는 접근은 데모에서는 통하지만, 팀 워크플로우에 에이전트가 들어오는 순간부터는 기술 부채가 아니라 운영 리스크가 된다. 지금 필요한 건 더 강력한 에이전트 모델이 아니라, 에이전트를 어떻게 신뢰할 것인지를 팀이 명시적으로 결정하는 구조다.