AI 에이전트를 '팀처럼' 굴린다는 말은 이제 비유가 아니다. 실제로 PM, 디자이너, 프론트엔드, 백엔드 역할을 각각의 에이전트에 위임하고, 오케스트레이터가 이들을 지휘해 기획부터 배포까지 자율 루프를 완성하는 구조가 현장에서 작동하고 있다. 문제는 이 루프가 돌아간다고 해서 끝이 아니라는 점이다. 품질은 누가 검증하나? 비용은 얼마나 타나? 지금 이 두 질문에 답하지 못하면, 에이전트 팀은 생산성 도구가 아니라 기술 부채 생성기가 된다.
에이전트를 팀으로 묶는 법: 역할 분리와 오케스트레이션 설계
velog에 공개된 1인 풀스택 개발자의 멀티 에이전트 오케스트레이션 구축기는 이 문제를 정면으로 다룬다. 핵심 구조는 단순하다. ~/.agents/skills/ 아래에 product_manager, ui_ux_designer, frontend_dev, backend_dev 디렉토리를 두고, 각 디렉토리의 SKILL.md에 해당 역할의 페르소나와 제약 조건을 선언한다. 그리고 ~/.agents/workflows/orchestrate.md가 이 에이전트들을 순서대로 호출하는 지휘 규칙을 담는다.
이 구조가 의미 있는 이유는 '역할 혼선'을 차단하기 때문이다. 단일 에이전트에게 기획부터 코드까지 맡기면 프론트엔드와 백엔드 관점이 뒤섞이며 할루시네이션이 발생한다. 역할별 SKILL.md는 에이전트가 코드를 생성할 때 자신의 도메인 밖으로 나가지 않도록 하는 소프트 가드레일이다. /orchestrate [요구사항] 명령 하나로 PM이 task.md를 작성하고, 디자이너가 implementation_plan.md를 채우고, 개발 에이전트가 실제 코드를 치고 터미널 테스트까지 돌리는 루프가 자율적으로 완성된다. 개발자는 지시하는 팀장이 되고, 에이전트는 실무 부서가 된다.
QA를 에이전트에게 넘길 때: 신뢰의 조건
오케스트레이션 루프가 돌아간다고 해도, 그 결과물이 실제로 동작하는지는 별개의 문제다. dev.to에 소개된 Google Antigravity는 이 QA 공백을 에이전트로 메우는 접근법이다. Selenium이나 Playwright처럼 CSS 셀렉터에 의존하는 스크립트 방식 대신, 에이전트가 DOM을 접근성 트리 기반으로 파악하고 실제 사용자처럼 브라우저를 조작한다. 셀렉터가 바뀌어도 테스트가 깨지지 않는다.
그런데 AI 에이전트 기반 테스트에서 가장 큰 리스크는 '테스트가 통과했다고 에이전트가 거짓말하는 것'이다. Antigravity는 이 신뢰 문제를 검증 아티팩트로 해결한다. 각 실행마다 스크린샷, 브라우저 레코딩(비디오 트레이스), 네트워크 요청 로그, 콘솔 에러 리포트를 생성한다. boolean 결과가 아니라 재현 가능한 증거를 남기는 것이다. 이 접근법은 앞서 오케스트레이션 루프의 4단계—Validation—와 정확히 맞물린다. 에이전트가 코드를 짠 다음, 다른 에이전트가 실제 UI 흐름을 검증하고 증거를 남긴다. CI/CD 파이프라인에 이 루프를 심으면 QA 전담 인력 없이도 품질 게이트를 유지할 수 있다.
비용 설계: 지금 싼 것이 나중에 가장 비싼 이유
오케스트레이션과 QA 자동화를 구축하는 팀이 놓치기 쉬운 세 번째 축이 비용이다. dev.to의 'Architect for the Cost Floor' 아티클은 불편한 숫자 하나로 시작한다. Claude Code의 월 $200 구독료 뒤에는 약 $5,000의 실제 컴퓨트 비용이 숨어 있다. 지금 우리가 쓰고 있는 건 가격이 아니라 보조금이다.
보조금 구조에서 팀이 자연스럽게 만드는 아키텍처는 토큰을 낭비한다. 에이전트에게 전체 파일 트리를 컨텍스트로 넘기고, 매 턴마다 같은 사실을 다시 fetch하고, 종료 조건 없이 루프를 돌린다. 지금은 싸니까 괜찮다. 하지만 보조금이 정상화되는 순간, 이런 구조를 가진 팀은 고통스러운 리라이트를 맞닥뜨린다. AWS 스팟 가격, VC 보조 SaaS, 클라우드 이그레스 요금—우리는 이 패턴을 이미 여러 번 봤다.
실용적인 처방은 다섯 가지다. ①에이전트에게 현재 태스크에 필요한 컨텍스트만 넘긴다. ②이미 아는 사실은 MEMORY.md 같은 구조화된 파일로 미리 제공해 재fetch를 막는다. ③제너럴리스트 에이전트 대신 단일 목적 에이전트를 쓴다—토큰 소비가 3~5배 차이난다. ④태스크마다 명확한 종료 조건을 정의한다. 루프는 토큰을 태운다. ⑤어느 에이전트가, 어느 태스크에서, 얼마를 썼는지 측정하고 귀속한다. 최적화는 가시성에서 시작된다.
시사점: 세 축을 동시에 설계해야 한다
오케스트레이션, QA, 비용—이 세 가지는 순서대로 해결하는 문제가 아니다. 에이전트 팀을 처음 설계할 때부터 동시에 고려해야 한다. 역할 분리 없는 오케스트레이션은 할루시네이션을 증폭시키고, 검증 아티팩트 없는 QA 자동화는 신뢰할 수 없으며, 비용 가시성 없는 에이전트 확장은 보조금이 끝나는 날 무너진다.
내일 당장 써먹을 수 있는 순서로 정리하면 이렇다. 먼저 역할별 SKILL.md로 에이전트 팀의 경계를 정의한다. 그다음 오케스트레이터 워크플로우에 검증 단계를 반드시 포함시키고, 그 단계에서 재현 가능한 아티팩트를 요구한다. 마지막으로 에이전트별 토큰 사용량을 측정하는 로깅을 처음부터 심는다. 세 축이 갖춰진 워크플로우만이 보조금이 사라진 이후에도 팀의 경쟁력이 된다.