AI 에이전트 오케스트레이션 실전기

직접 만들어보고 싶었습니다

알고리즘 스터디를 운영하면서 반복되는 불편함이 있었습니다. 문제 배정, 제출 확인, 코드 리뷰 요청 — 매주 같은 일을 수작업으로 하고 있었죠. 스터디원이 늘어날수록 관리 비용이 기하급수적으로 커졌고, "이걸 자동화하는 플랫폼이 있으면 좋겠다"는 생각이 자연스럽게 들었습니다.

마침 AI 에이전트 오케스트레이션이라는 개념을 접했습니다. 여러 AI 에이전트에게 각각 다른 역할을 맡기고, 하나의 시스템처럼 협업시키는 방식. 읽으면 읽을수록 "이걸 실제 서비스 개발에 적용하면 어떻게 될까?"라는 호기심이 커졌습니다.

고민만 하고 있을 수는 없었습니다. 직접 해보기로 했습니다. 혼자서 MSA 기반의 스터디 플랫폼을 만들되, AI 에이전트들을 팀원처럼 운영하면서.

혼자 만들 때 부딪히는 벽

개발을 시작하니 금방 벽이 보였습니다. 코드를 못 짜서가 아니라, 혼자서는 생산성과 일관성을 동시에 유지하기 어렵다는 문제였습니다.

생산성의 한계

6개 마이크로서비스를 오가며 작업하면 컨텍스트 스위칭 비용이 큽니다. 오전에 Saga 패턴을 설계하다가, 오후에 프론트엔드 SSE 연동으로 넘어가고, 저녁에 k8s 매니페스트를 수정합니다. 다음 날 다시 Saga로 돌아오면 어제의 결정 이유가 흐릿해져 있습니다. 코드를 처음부터 다시 읽는 시간이 쌓이면서 실제 진척은 느려졌습니다.

일관성의 부재

혼자 개발하면 기준이 흔들립니다. "이번만 하드코딩하자", "테스트는 나중에". 막아줄 사람이 없으니 유혹에 쉽게 넘어갑니다. 커밋 컨벤션도, 파일 구조도, 에러 핸들링 방식도 날마다 조금씩 달라집니다. 서비스가 6개면 불일치가 6배로 늘어납니다.

이 두 가지가 결국 같은 문제를 가리키고 있었습니다. 한 사람의 머릿속에 전체 시스템의 맥락과 기준을 동시에 담아둘 수 없다는 것.

첫 번째 시도: 에이전트 8명

Claude Code 기반으로 에이전트 오케스트레이션 체계를 만들었습니다. 처음에는 8명으로 시작했습니다.

Oracle(심판관), Conductor(지휘자), Gatekeeper(관문지기), Librarian(기록관리자), Architect(기반설계자), Postman(배달부), Curator(출제자), Herald(전령). 실제 개발 팀의 역할을 AI 에이전트에게 대응시킨 구조였습니다.

이때는 각 에이전트에게 전체 페르소나를 통째로 부여했습니다. 역할 설명, 행동 규칙, 코드 컨벤션, 보안 원칙까지 한 에이전트의 프롬프트에 전부 담았죠. "너는 이런 사람이야"라고 정체성을 만들어주면 알아서 잘 하겠지, 하는 기대였습니다.

워크플로우를 어떻게 짜야 할까

에이전트를 만든 것까지는 좋았는데, 어떤 순서로, 어떻게 협업시킬지가 문제였습니다. 처음에는 필요할 때마다 에이전트를 호출하는 방식이었는데, 금방 한계가 드러났습니다.

에이전트가 컨텍스트를 유지하지 못했습니다. 같은 에이전트를 두 번 호출하면 첫 번째 호출에서 결정한 내용을 기억하지 못합니다. 에이전트 간 작업 순서도 꼬였습니다. Librarian이 스키마를 바꾸기 전에 Conductor가 API를 수정하면 타입이 맞지 않는 상황이 생겼죠.

페르소나에서 규칙으로

더 큰 문제는 일관성이었습니다. 8명의 에이전트에게 각각 전체 페르소나를 부여했더니, 공통 규칙이 미묘하게 어긋나기 시작했습니다. Conductor는 함수를 20줄 이내로 쓰는데 Herald는 30줄짜리 함수를 만듭니다. 커밋 메시지 포맷도 에이전트마다 조금씩 달랐습니다.

결국 공통 규칙을 하나의 파일로 분리했습니다. persona-base.md — 모든 에이전트가 작업 시작 전에 반드시 읽는 공통 행동 규칙 파일. 코드 컨벤션, 보안 원칙, 보고 체계, 에스컬레이션 경로를 여기에 모았습니다. 각 에이전트의 개별 프롬프트에는 자기 도메인에 특화된 지식만 남겼습니다.

컨텍스트 최적화 효과도 있었습니다. 에이전트 프롬프트가 짧아지니 핵심 지시를 더 잘 따랐고, 공통 규칙이 한 곳에 있으니 수정할 때도 한 번만 고치면 됐습니다.

8명에서 12명으로

8명 체계로 운영하면서 빈 자리가 보이기 시작했습니다.

문서가 쌓이는데 관리할 에이전트가 없었습니다. Sprint ADR, MEMORY.md, 프롬프트 변경 이력 — 이런 것들을 Librarian이 겸임하고 있었는데, DB 스키마 관리와 문서 관리는 성격이 다른 일이었습니다. Scribe(서기관)를 분리했습니다.

AI 분석 기능을 붙이면서 Sensei(분석가)가 필요해졌습니다. Claude API 호출, Circuit Breaker 패턴, 응답 파싱 — Herald가 프론트엔드와 AI를 동시에 맡기엔 영역이 너무 넓었습니다.

프론트엔드가 커지면서 비슷한 문제가 생겼습니다. Herald가 페이지 개발과 디자인 시스템을 동시에 책임지고 있었는데, 컴포넌트 스펙과 페이지 로직은 분리하는 게 맞았습니다. Palette(팔레트)가 디자인 시스템을 가져갔습니다.

마지막으로 Scout(정찰병). 에이전트들이 만든 결과물을 사용자 관점에서 검증할 역할이 빠져 있었습니다. 기능은 동작하는데 UX가 어색한 경우를 잡아줄 에이전트가 필요했습니다.

저(PM)는 Oracle하고만 대화합니다. Oracle이 작업을 분석해서 적절한 에이전트에게 위임하고, 결과를 취합해서 보고합니다. 에이전트들은 서로 직접 소통하지 않고, 충돌이 생기면 Oracle이 중재합니다.

실전에서 체감한 순간들

Librarian이 막아준 DB 사고

Problem 서비스의 스키마를 변경할 때였습니다. 컬럼 이름을 바꾸려고 했는데, Librarian의 규칙이 이를 막았습니다.

Expand-Contract 패턴 강제. 컬럼 삭제/rename은 반드시 3단계 배포. Rolling Update 중 구/신 버전 공존 상황을 항상 가정.

단순 rename 대신 (1) 새 컬럼 추가 → (2) 데이터 복사 + 앱 코드 전환 → (3) 구 컬럼 삭제의 3단계로 진행했습니다. 번거롭다고 느꼈지만, 운영 중 다운타임 없이 완료할 수 있었습니다. 혼자였다면 "그냥 rename하면 되지"라고 넘어갔을 겁니다.

Gatekeeper가 잡아낸 보안 잔재

인증 로직을 리팩터링하면서 localStorage에 토큰을 저장하는 코드가 남아 있었습니다. httpOnly Cookie로 전환한 뒤에도 이전 방식의 잔재가 곳곳에 숨어 있었죠. Gatekeeper의 규칙이 이를 잡아냈습니다.

SSE 인증: EventSource(url, { withCredentials: true }) — httpOnly Cookie 환경에서 localStorage 토큰 사용 불가. 민감 정보 절대 금지: JWT 원문, X-Internal-Key, OAuth 토큰.

사람이라면 "이전에 고쳤으니까 됐겠지"하고 넘어갈 수 있는 부분입니다. 에이전트는 매번 전체를 검사합니다.

컨텍스트가 사라지지 않는다는 것

67개 스프린트를 거치면서 "이전에 왜 이렇게 결정했지?" 하는 순간이 수도 없이 있었습니다. Scribe가 관리하는 MEMORY.md와 Sprint ADR에 모든 결정 기록이 남아 있었기 때문에, 3개월 전 결정도 5초 만에 찾을 수 있었습니다.

혼자 개발할 때 가장 무서운 건 기능이 안 되는 게 아니라, 왜 이렇게 만들었는지 잊어버리는 것입니다. 맥락이 사라지면 같은 실수를 반복하거나, 이미 검토한 대안을 다시 고민하게 됩니다. 에이전트 체계는 이 문제를 구조적으로 해결해줬습니다.

워크플로우 설계의 시행착오

에이전트가 있어도 어떤 순서로 호출할지를 잘못 짜면 소용없었습니다. 초기에는 필요한 에이전트를 그때그때 호출했는데, 작업 순서가 꼬이면서 한 에이전트의 결과물이 다른 에이전트의 전제를 깨뜨리는 일이 반복됐습니다.

결국 에셜론 기반 실행 순서를 도입했습니다. Echelon 1(Conductor, Gatekeeper, Librarian)이 먼저 인프라와 안전장치를 잡고, Echelon 2(Architect, Postman, Curator, Scribe)가 기능을 구현하고, Echelon 3(Sensei, Herald, Palette, Scout)가 마감합니다. 이 순서를 지키면 의존성 충돌이 크게 줄었습니다.

앞으로의 방향

에이전트 체계를 운영하면서 계속 고민하는 질문이 있습니다. AI를 통제하면서 생산성을 높이되, 퀄리티는 어떻게 유지할 수 있을까.

통제를 강화하면 생산성이 떨어집니다. 모든 에이전트 결과물을 일일이 검토하면 혼자 하는 것과 다를 바 없습니다. 반대로 자율성을 높이면 퀄리티가 흔들립니다. 에이전트가 독자적으로 내린 결정이 전체 아키텍처와 어긋나는 순간이 옵니다.

지금까지 발견한 균형점은 이렇습니다. 역할 경계를 명확히 하고, 공통 규칙을 한 곳에서 관리하고, 에스컬레이션 경로를 열어두는 것. 에이전트가 자기 영역 안에서는 자율적으로 판단하되, 영역을 벗어나면 반드시 Oracle을 거치게 합니다. 규칙은 SSoT(Single Source of Truth)로 관리해서 불일치를 막고, 판단이 어려운 건 사람에게 올라오도록 합니다.

이게 완벽한 답인지는 아직 모릅니다. 스프린트가 쌓일수록 새로운 문제가 나타나고, 그때마다 체계를 조금씩 고쳐나가고 있습니다. 확실한 건 하나 있습니다 — 이 고민 자체가 혼자서는 절대 하지 못했을 종류의 것이라는 점.

해보는 것과 해보지 않은 것의 차이

AI 에이전트 오케스트레이션을 글로 읽는 것과 직접 해보는 건 완전히 다른 경험입니다. 글로는 "역할을 나누고 규칙을 만들면 된다"로 요약되지만, 실제로는 워크플로우가 꼬이고, 컨텍스트가 유실되고, 규칙이 어긋나는 상황을 수십 번 겪으면서 체계가 만들어졌습니다.

해보지 않았다면 "AI가 코드를 짜준다"는 피상적인 이해에 머물렀을 겁니다. 해봤기 때문에 알게 된 것들이 있습니다. 에이전트에게 뭘 맡겨야 하고, 뭘 직접 해야 하는지. 통제와 자율의 경계를 어디에 놓아야 하는지. 한 사람의 판단력과 12명의 실행력을 어떻게 조합해야 하는지.

결국 중요한 건 시작하는 것이었습니다.