12명의 AI를 통제하는 법

에이전트 12명을 팀으로 만들려면

에이전트를 하나씩 호출하는 건 어렵지 않았습니다. 문제는 12명을 팀으로 운영하려 할 때 생겼습니다.

핵심 질문은 세 가지였습니다. 누가 누구의 코드를 검증하나? 충돌이 생기면 누가 중재하나? 공통 규칙은 어떻게 유지하나?

통제 없이 각자 코드를 쏟아내면 기술부채가 사람보다 빠르게 쌓였습니다. 12명이 각자의 판단으로 코드를 작성하면 스타일도 품질도 방향도 제각각이었죠. "빠르게 만들 수 있다"는 장점이 오히려 위험이 되는 순간이었습니다.

소통 창구를 하나로 — Oracle과 단방향 흐름

12명 전부와 대화하는 건 불가능했습니다. 에이전트가 3명일 때는 각각 호출해도 괜찮았지만, 12명이 되니 누구에게 뭘 시켰는지조차 헷갈렸습니다. 소통 채널을 1개로 좁혔습니다.

Oracle이 PM(저)과 대화하는 유일한 에이전트가 됐습니다. 나머지 11명은 Oracle이 오케스트레이팅합니다.

흐름은 단방향입니다. PM → Oracle → 에이전트 → Oracle → PM. 에이전트끼리 직접 소통하지 않습니다. Conductor가 Curator에게 마감 시간을 조회할 때도 그건 서비스 간 내부 HTTP 통신이지 에이전트 간 직접 소통이 아닙니다.

Oracle은 "무엇을" 결정하고, "어떻게"는 각 에이전트의 전문 영역입니다. Saga 로직을 어떻게 구현할지는 Conductor가 판단하고, k8s 매니페스트를 어떻게 작성할지는 Architect가 결정합니다.

의사결정에는 우선순위가 있었습니다. 서비스 안정성 > 개발 속도 > 기능 완성도. Herald가 "새 UI 컴포넌트가 필요해요"라고 요청하고, 동시에 Gatekeeper가 "JWT 검증에 취약점이 있어요"라고 보고하면 — Oracle은 주저 없이 보안 이슈를 먼저 처리했습니다.

Oracle에게도 금지사항이 있었습니다. 직접 코드를 작성하지 않고, 핵심 원칙(자체 DB SSoT, Database per Service, Saga Orchestration)을 훼손하는 결정을 하지 않고, 특정 에이전트의 편을 들지 않습니다. 심판관이니까요.

에셜론 — 지휘 계통 기반 계층

12명을 평등하게 두면 우선순위가 없어집니다. 멀티 에이전트 시스템(MAS) 문헌에서 쓰이는 에셜론(echelon) 개념을 차용해 3단계로 분류했습니다. 에셜론은 지휘 위임 관계를 내포하는 용어로, 인프라 계층(3-Tier Architecture)과 혼동되지 않으면서 에이전트 간 우선순위와 실행 순서를 자연스럽게 표현합니다.

Echelon 1(Mission Critical) — Oracle, Conductor, Gatekeeper, Librarian. 이 네 명이 깨지면 서비스 전체가 멈춥니다. 가장 강력한 모델(Opus)을 사용했습니다.

Echelon 2(Core) — Architect, Postman, Curator, Scribe. 기반 인프라와 핵심 비즈니스 로직을 담당합니다.

Echelon 3(Enhancement) — Sensei, Herald, Palette, Scout. 서비스의 가치를 높이는 역할. Echelon 1·2가 안정된 후에 작업합니다.

이 분류는 단순한 라벨이 아니라 실행 순서이기도 했습니다. Echelon 1이 먼저 안전장치를 잡고, Echelon 2가 구현하고, Echelon 3가 마감했습니다. 이 순서를 지키니 의존성 충돌이 크게 줄었습니다.

하나의 파일이 12명을 통제한다 — SSoT

12명이 일관되게 동작하려면 공통 규칙이 필요했습니다. persona-base.md라는 단일 파일이 그 역할을 했습니다. SSoT(Single Source of Truth)였습니다.

모든 에이전트는 작업 시작 전에 이 파일을 반드시 읽었습니다. 에이전트 파일마다 동일한 문구가 있었죠.

공통 규칙: 참조: agents/_shared/persona-base.md (착수 전 필수 Read)

이 파일에 담긴 핵심 규칙들이 있었습니다.

에스컬레이션 원칙 — 판단 범위를 초과하거나 에이전트 간 충돌이 생기면 Oracle에게 올렸습니다. 4시간 내 판단이 불가하면 PM에게 보고했습니다. 에이전트도 모르는 게 있고, 그럴 때 "대충 판단"하지 않고 상위로 올리는 것이 핵심이었습니다. 실제로 Palette와 Herald 사이에 컴포넌트 스펙 의견 차이가 있을 때, Oracle이 중재하는 구조였습니다.

인터페이스 계약 — API 스펙을 바꿀 때 24시간 전 관련 에이전트에게 공지했습니다. 하위 호환 우선이고, 파괴적 변경은 Oracle 승인이 필수였습니다. 마이크로서비스 환경에서 한 서비스의 변경이 다른 서비스를 깨뜨리는 것을 방지하기 위해서였습니다.

코드 작성 규칙 — 함수 단일 책임, 20줄 이내, DRY, SOLID. 파일 헤더 어노테이션 필수. 인라인 하드코딩 금지. 이 규칙들이 12명 전체에 동일하게 적용됐습니다. Conductor가 작성한 코드든 Herald가 작성한 코드든 동일한 스타일, 동일한 품질 기준을 따랐습니다.

persona-base.md를 수정하면 12명의 행동이 한 번에 바뀌었습니다. 이것이 통제의 핵심이었습니다.

이 구조가 준 것과 못 준 것

67개 스프린트를 이 구조로 운영했습니다. 준 것과 못 준 것이 둘 다 있었습니다.

일관된 코드 품질을 줬습니다. persona-base.md가 SSoT로 작동했기 때문에 어노테이션 규칙, 네이밍 컨벤션, 에러 핸들링 패턴이 처음부터 끝까지 동일했습니다. 하지만 컨텍스트 윈도우 비용을 가져왔습니다. 에이전트가 작업을 시작할 때마다 공통 규칙, 에이전트 파일, 도구 파일을 읽으면서 컨텍스트를 소비했습니다.

맥락 유실 방지를 줬습니다. Sprint ADR + MEMORY.md + sprint-window.md 3중 구조가 맥락을 보존했고, 3개월 전 결정을 5초 만에 찾을 수 있었습니다. 하지만 Oracle 병목이 생겼습니다. 모든 작업이 Oracle을 거치므로, 동시에 여러 에이전트에게 작업을 할당할 수 있지만 최종 검증은 순차적이었습니다.

안전한 변경을 줬습니다. Librarian이 DB 변경을 3단계로 강제하고, Gatekeeper가 보안 규칙을 검증하고, Architect가 리소스 제한을 확인했습니다. 하지만 도메인 직관의 부재는 해결되지 않았습니다. "이 기능이 사용자에게 정말 필요한가?"는 에이전트가 답할 수 없는 질문이었습니다. 기술 결정의 집행은 에이전트에게 맡길 수 있지만, 방향 결정은 여전히 사람의 몫이었습니다.

통제된 AI가 유용한 AI다

AI에게 코드를 맡기는 것 자체는 어렵지 않았습니다. 어려운 건 그 AI가 프로젝트의 규칙을 지키고, 다른 영역과 충돌하지 않고, 실수했을 때 되돌릴 수 있도록 만드는 것이었습니다.

심판관이 판단하고, 에셜론이 우선순위를 정하고, 하나의 파일이 일관성을 유지합니다. 완벽한 체계는 아니었지만, 67개 스프린트를 일관된 품질로 완주할 수 있게 해준 구조였습니다. 통제 없는 AI는 위험하지만, 통제된 AI는 흔들림 없이 일관성을 지켜냈습니다.