AI 에이전트AI 에이전트 12개의 요청 창구·우선순위·공통 규칙 설계
· 알고수
- #ai-dev
- #agent
- #governance
문제
12개를 팀으로 운영하려니 통제가 무너졌다. 누가 누구의 코드를 검증하고, 충돌은 누가 중재하며, 공통 규칙은 어떻게 유지하나?
결정
세 가지를 했다. 소통 창구를 총괄 에이전트 Oracle 하나로 좁혔고, 에이전트를 우선순위 3단계(Echelon)로 나눴고, 공통 규칙을 파일 하나(persona-base.md)에 모았다.
결과
67번째 스프린트(짧은 작업 주기)까지 일관된 품질로 이어 왔다. 대신 규칙을 매번 읽는 컨텍스트 비용과 Oracle 병목이 남았고, 도메인 직관은 여전히 사람의 몫이었다.
에이전트 12개를 팀으로
에이전트를 하나씩 부르는 건 어렵지 않았습니다. 문제는 12개를 팀으로 운영하려 할 때 생겼습니다.
핵심 질문은 세 가지였습니다. 누가 누구의 코드를 검증하나? 충돌이 생기면 누가 중재하나? 공통 규칙은 어떻게 유지하나?
통제 없이 각자 코드를 쏟아내면 기술 부채가 사람이 만들 때보다 빠르게 쌓였습니다. 12개가 각자 판단으로 코드를 쓰면 스타일도 품질도 방향도 제각각이었죠. "빠르게 만들 수 있다"는 장점이 오히려 위험이 되는 순간이었습니다.
단일 창구 Oracle
12개 모두와 대화하는 건 불가능했습니다. 에이전트가 8개이던 처음에는 하나씩 불러도 괜찮았지만, 12개가 되니 누구에게 뭘 시켰는지조차 헷갈렸습니다. 그래서 소통 창구를 하나로 좁혔습니다.
총괄 에이전트 Oracle이 PM인 저와 대화하는 유일한 에이전트가 됐습니다. 나머지 11개는 Oracle이 지휘합니다.
흐름은 한 방향입니다. PM → Oracle → 담당 에이전트 → Oracle → PM. 에이전트끼리는 직접 대화하지 않습니다.
에이전트가 맡은 서비스끼리 HTTP로 통신하는 것과 에이전트끼리 대화하는 것은 다릅니다. 예를 들어 제출 서비스(제출 흐름 담당 Conductor가 맡은 코드)가 문제 서비스(문제 관리 담당 Curator가 맡은 코드)에 마감 시간을 묻는 건 프로그램 사이의 내부 HTTP 호출입니다. 그걸 만드는 에이전트들은 서로 직접 말을 주고받지 않습니다.
PM (사람)
작업 요청Oracle
분석 · 누구에게 맡길지 결정담당 에이전트
자기 영역 실행Oracle
결과 취합 · 검증PM (사람)
최종 확인
Oracle은 "무엇을" 할지 정하고, "어떻게"는 각 에이전트가 정합니다. Saga(여러 서비스에 걸친 작업을 단계별로 진행하고 실패하면 되돌리는 방식)를 어떻게 구현할지는 Conductor가, 쿠버네티스(k8s) 배포 설정을 어떻게 쓸지는 인프라 담당 Architect가 판단합니다.
결정에는 우선순위가 있었습니다. 서비스 안정성 > 개발 속도 > 기능 완성도. 프론트엔드 담당 Herald가 "새 UI 컴포넌트가 필요해요"라고 요청하는데, 동시에 인증·보안 담당 Gatekeeper가 "JWT 검증에 취약점이 있어요"라고 보고하면, Oracle은 주저 없이 보안 문제부터 처리했습니다.
Oracle에게도 금지사항이 있었습니다.
- 직접 코드를 쓰지 않는다.
- 핵심 설계 원칙을 깨는 결정을 하지 않는다. 서비스마다 자기 DB를 두고 그 DB를 기준으로 삼는다(Database per Service), 여러 서비스에 걸친 작업은 Saga로 조율한다.
- 특정 에이전트의 편을 들지 않는다.
Oracle은 에이전트 사이의 심판이니까요.
에셜론: 우선순위 단계
12개를 평등하게 두면 우선순위가 없어집니다. 그래서 멀티 에이전트 시스템(MAS) 연구에서 쓰는 에셜론(echelon) 개념을 빌려 3단계로 나눴습니다.
에셜론은 지휘와 위임 관계를 담은 말입니다. 서버 구조를 말하는 3계층(3-Tier Architecture)과 헷갈리지 않으면서, 에이전트 사이의 우선순위와 실행 순서를 자연스럽게 나타낼 수 있었습니다.
1단계
Mission Critical
총괄 Oracle, 제출 흐름 담당 Conductor, 인증·보안 담당 Gatekeeper, DB 담당 Librarian. 이 넷이 깨지면 서비스 전체가 멈춥니다. 모든 에이전트는 Anthropic의 Claude 모델로 돌았고, 1단계에는 당시 가장 강력한 Claude 모델(Opus)을 썼습니다.
2단계
Core
인프라 담당 Architect, GitHub 연동 담당 Postman, 문제 관리 담당 Curator, 문서 담당 Scribe. 기반 인프라와 핵심 비즈니스 로직을 맡습니다.
3단계
Enhancement
AI 분석 담당 Sensei, 프론트엔드 담당 Herald, 디자인 시스템 담당 Palette, 사용자 관점 테스트 담당 Scout. 서비스의 가치를 높이는 역할로, 1·2단계가 안정된 뒤에 작업합니다.
이 분류는 단순한 라벨이 아니라 실행 순서이기도 했습니다. 1단계가 먼저 안전장치를 잡고, 2단계가 구현하고, 3단계가 마무리했습니다. 이 순서를 지키니 의존성 충돌이 크게 줄었습니다.
12개의 에이전트와 우선순위 3단계(Echelon)
12개를 통제하는 단일 원천
12개가 일관되게 움직이려면 공통 규칙이 필요했습니다. persona-base.md라는 파일 하나가 그 역할을 했습니다. 단일 원천(SSoT, 기준을 한 곳에서만 관리하는 것)이었습니다.
에이전트마다 따로 있는 정의 파일에는 모두 같은 문구가 들어 있었습니다.
공통 규칙: 참조:
agents/_shared/persona-base.md(착수 전 필수 Read)
이 파일의 핵심 규칙은 셋이었습니다. 아래 시간 기준(4시간, 24시간)도 이 공통 규칙 파일에 적혀 있던 규칙입니다. 사람 팀의 규칙을 본떠 적은 기준이라, 실제로 시간을 쟀다기보다 "혼자 오래 붙잡지 말고 보고하라", "바꾸기 전에 먼저 알려라"는 순서 규칙으로 작동했습니다.
에스컬레이션(위로 올리기): 자기 판단 범위를 넘거나 에이전트끼리 충돌하면 Oracle에게 올립니다. 4시간 안에 판단이 안 서면 PM에게 보고합니다. 에이전트도 모르는 게 있고, 그럴 때 대충 판단하지 않고 위로 올리는 것이 핵심이었습니다. 실제로 디자인 시스템 담당 Palette와 프론트엔드 담당 Herald가 컴포넌트 스펙을 두고 의견이 갈렸을 때 Oracle이 중재했습니다.
인터페이스 계약: API 스펙을 바꿀 때는 24시간 전에 관련 에이전트에게 알립니다. 하위 호환이 우선이고, 호환을 깨는 변경은 Oracle의 승인이 필요합니다. 마이크로서비스 환경에서 한 서비스의 변경이 다른 서비스를 깨뜨리지 않게 하려는 규칙이었습니다.
코드 작성 규칙: 함수는 한 가지 책임만, 20줄 이내, DRY, SOLID. 파일 맨 위 설명 주석(헤더 어노테이션) 필수. 값을 코드에 바로 박아 넣는 하드코딩 금지. 이 규칙이 12개 모두에게 똑같이 적용됐습니다. Conductor가 쓴 코드든 Herald가 쓴 코드든 같은 스타일, 같은 품질 기준을 따랐습니다.
persona-base.md를 고치면 12개의 행동이 한 번에 바뀌었습니다. 이것이 통제의 핵심이었습니다.
통제 구조
이 구조가 준 것과 못 준 것
67개 스프린트를 이 구조로 운영했습니다. 준 것도, 못 준 것도 있었습니다.
일관된 코드 품질을 줬습니다. persona-base.md가 단일 원천으로 작동한 덕에 주석 규칙, 이름 짓는 규칙, 에러 처리 패턴이 처음부터 끝까지 같았습니다. 대신 컨텍스트 비용이 들었습니다. 에이전트가 작업을 시작할 때마다 공통 규칙과 자기 정의 파일을 읽느라 한 번에 다룰 수 있는 분량(컨텍스트 윈도우)을 써버렸습니다.
맥락 유실 방지를 줬습니다. 세 가지 기록이 맥락을 지켰습니다. 스프린트별 결정 기록(ADR), 매 세션 자동으로 읽히는 기억 파일 MEMORY.md, 직전 스프린트와 진행 중인 스프린트만 담아 매 세션 가장 먼저 읽는 sprint-window.md. 덕분에 3개월 전 결정도 5초 만에 찾을 수 있었습니다. 대신 Oracle 병목이 생겼습니다. 모든 일이 Oracle을 거치므로, 여러 에이전트에게 동시에 일을 맡길 수는 있어도 최종 검증은 하나씩 순서대로였습니다.
안전한 변경을 줬습니다. DB 담당 Librarian은 DB 변경을 3단계로 나눠 배포하게 했고, Gatekeeper는 보안 규칙을 검증했고, Architect는 리소스 제한을 확인했습니다. 하지만 도메인 직관의 부재는 풀리지 않았습니다. "이 기능이 사용자에게 정말 필요한가?"는 에이전트가 답할 수 없는 질문이었습니다. 기술 결정의 실행은 에이전트에게 맡길 수 있어도, 방향을 정하는 건 여전히 사람의 몫이었습니다.
통제된 AI의 유용함
AI에게 코드를 맡기는 것 자체는 어렵지 않았습니다. 어려운 건 그 AI가 프로젝트의 규칙을 지키고, 다른 영역과 충돌하지 않고, 실수했을 때 되돌릴 수 있게 만드는 것이었습니다.
심판 역할의 Oracle이 판단하고, 우선순위 단계가 순서를 정하고, 파일 하나가 일관성을 지킵니다. 완벽한 체계는 아니었지만, 67번째 스프린트까지 일관된 품질로 이어 오게 해준 구조였습니다. 통제 없는 AI는 위험하지만, 통제된 AI는 흔들림 없이 일관성을 지켜냈습니다.