AI 에이전트1인 개발을 위한 AI 에이전트 12개 구성과 운영
· 알고수
- #ai-dev
- #agent
- #orchestration
- #claude-code
직접 만들고 싶었던 플랫폼
알고리즘 스터디를 운영하면서 같은 불편함이 반복됐습니다. 문제 배정, 제출 확인, 코드 리뷰 요청. 매주 같은 일을 손으로 하고 있었죠.
스터디원이 늘수록 관리 비용은 기하급수적으로 커졌습니다. "이걸 자동화하는 플랫폼이 있으면 좋겠다"는 생각이 자연스럽게 들었습니다.
그즈음 AI 에이전트 오케스트레이션이라는 개념을 접했습니다. 여러 AI 에이전트에게 서로 다른 역할을 맡기고, 하나의 시스템처럼 협업시키는 방식입니다. 읽을수록 "이걸 실제 서비스 개발에 적용하면 어떻게 될까?" 하는 호기심이 커졌습니다.
그래서 직접 해보기로 했습니다. 여러 개의 작은 서비스로 나눈 구조(MSA, 마이크로서비스 아키텍처)로 스터디 플랫폼을 혼자 만들되, AI 에이전트들을 팀원처럼 운영하면서요.
문제
혼자 만들면 빠르지만, 서비스 6개를 오가며 생산성과 일관성을 함께 지키기에는 손이 부족했다.
결정
에이전트를 8개에서 12개로 늘리고 역할을 전문화했다. 공통 규칙은 모든 에이전트가 먼저 읽는 파일 하나(persona-base.md)에 모으고, 각 에이전트에게는 자기 분야 지식만 남겼다.
결과
DB 사고 방지, 남아 있던 보안 취약 코드 차단, 지난 결정을 다시 찾는 시간 단축(3개월 전 결정도 5초 만에)에서 효과를 봤다. 작업 순서, 그리고 통제와 자율의 균형은 계속 다듬는 숙제로 남았다.
혼자 만들 때의 한계
개발을 시작하니 금방 벽이 보였습니다. 코드를 못 짜서가 아니었습니다. 혼자서는 생산성과 일관성을 동시에 유지하기 어렵다는 문제였습니다.
생산성의 한계
마이크로서비스 6개(Gateway·Identity·Submission·Problem·GitHub Worker·AI Analysis)를 오가며 일하면, 머릿속 맥락을 갈아 끼우는 비용(컨텍스트 스위칭)이 큽니다.
오전에는 Saga 패턴(여러 서비스에 걸친 작업을 단계별로 진행하고, 실패하면 되돌리는 방식)을 설계합니다. 오후에는 서버가 브라우저로 실시간 알림을 보내는 SSE를 프론트엔드에 붙입니다. 저녁에는 쿠버네티스(k8s) 배포 설정 파일을 고칩니다.
다음 날 Saga로 돌아오면 어제 왜 그렇게 결정했는지가 흐릿합니다. 코드를 처음부터 다시 읽는 시간이 쌓이면서 실제 진척은 느려졌습니다.
일관성의 부재
혼자 개발하면 기준이 흔들립니다. "이번만 하드코딩하자", "테스트는 나중에". 막아줄 사람이 없으니 유혹에 쉽게 넘어갑니다.
커밋 컨벤션도, 파일 구조도, 에러 처리 방식도 날마다 조금씩 달라집니다. 서비스가 6개면 불일치도 6배로 늘어납니다.
두 문제는 결국 같은 곳을 가리키고 있었습니다. 한 사람의 머릿속에 전체 시스템의 맥락과 기준을 동시에 담아둘 수는 없다는 것.
첫 시도: 에이전트 8개
Anthropic의 코딩 에이전트 도구인 Claude Code로 에이전트 체계를 만들었습니다. 에이전트는 모두 Anthropic의 Claude 모델로 돌아갑니다. 처음에는 8개였습니다. 실제 개발 팀의 역할을 에이전트 하나에 하나씩 맡긴 구조입니다.
- Oracle: 총괄 에이전트. 일을 나누고 조율한다.
- Conductor: 코드 제출 흐름 담당
- Gatekeeper: 인증·보안 담당
- Librarian: DB 담당
- Architect: 인프라 담당
- Postman: GitHub 연동 담당
- Curator: 문제 관리 담당
- Herald: 프론트엔드 담당
이때는 각 에이전트에게 전체 페르소나를 통째로 줬습니다. 역할 설명, 행동 규칙, 코드 컨벤션, 보안 원칙까지 한 에이전트의 프롬프트에 전부 담았죠. "너는 이런 사람이야"라고 정체성을 만들어주면 알아서 잘하겠지, 하는 기대였습니다.
워크플로우를 어떻게 짜야 할까
에이전트를 만든 것까지는 좋았습니다. 문제는 어떤 순서로, 어떻게 협업시킬지였습니다. 처음에는 필요할 때마다 에이전트를 불렀는데, 금방 한계가 드러났습니다.
에이전트는 맥락을 이어가지 못했습니다. 같은 에이전트를 두 번 부르면, 첫 번째에 결정한 내용을 기억하지 못합니다. 이 문제는 뒤에서 기록을 남기는 방식으로 풀었습니다.
에이전트 사이의 작업 순서도 꼬였습니다. DB 담당 Librarian이 스키마를 바꾸기 전에 제출 흐름 담당 Conductor가 API를 먼저 고치면, 타입이 맞지 않는 일이 생겼죠.
페르소나에서 규칙으로
더 큰 문제는 일관성이었습니다. 8개에게 각자 전체 페르소나를 줬더니, 공통 규칙이 미묘하게 어긋나기 시작했습니다. Conductor는 함수를 20줄 이내로 쓰는데, 프론트엔드 담당 Herald는 30줄짜리 함수를 만듭니다. 커밋 메시지 형식도 에이전트마다 조금씩 달랐습니다.
결국 공통 규칙을 파일 하나로 뺐습니다. 모든 에이전트가 작업 전에 반드시 읽는 공통 규칙 파일, persona-base.md입니다. 코드 컨벤션, 보안 원칙, 보고 체계, 문제를 위로 올리는 경로(에스컬레이션)를 여기에 모았습니다. 각 에이전트의 프롬프트에는 자기 분야에 특화된 지식만 남겼습니다.
에이전트가 한 번에 읽는 분량(컨텍스트)이 줄어드는 효과도 있었습니다. 프롬프트가 짧아지니 핵심 지시를 더 잘 따랐습니다. 공통 규칙이 한 곳에 있으니 고칠 때도 한 번만 고치면 됐습니다.
8개에서 12개로
8개로 운영하다 보니 빈자리가 보이기 시작했습니다.
첫째, 문서가 쌓이는데 관리할 에이전트가 없었습니다. 스프린트(짧은 작업 주기)마다 남기는 결정 기록(ADR), 매 세션 자동으로 읽히는 기억 파일 MEMORY.md, 프롬프트 변경 이력. 이걸 DB 담당 Librarian이 겸하고 있었는데, DB 스키마 관리와 문서 관리는 성격이 다른 일이었습니다. 그래서 문서 담당 Scribe를 따로 뒀습니다.
둘째, AI 분석 기능을 붙이면서 AI 분석 담당 Sensei가 필요해졌습니다. Claude API 호출, 장애가 번지지 않게 호출을 끊는 Circuit Breaker 패턴, 응답 파싱. Herald가 프론트엔드와 AI를 함께 맡기엔 영역이 너무 넓었습니다.
셋째, 프론트엔드가 커지면서 비슷한 문제가 생겼습니다. Herald가 페이지 개발과 디자인 시스템을 함께 책임지고 있었는데, 컴포넌트 스펙과 페이지 로직은 나누는 게 맞았습니다. 디자인 시스템 담당 Palette가 디자인 시스템을 가져갔습니다.
마지막으로 사용자 관점 테스트 담당 Scout. 에이전트들이 만든 결과물을 사용자 입장에서 확인할 역할이 빠져 있었습니다. 기능은 동작하는데 사용 경험이 어색한 경우를 잡아줄 에이전트가 필요했습니다.
12개는 우선순위 단계(Echelon) 세 개로 나뉩니다.
1단계
Mission Critical
깨지면 서비스 전체가 멈추는 영역. 그래서 당시 가장 강력한 Claude 모델(Opus)을 씁니다. 총괄 Oracle과 Conductor·Gatekeeper·Librarian이 여기에 속합니다.
2단계
Core
기반 인프라와 핵심 비즈니스 로직. Architect·Postman·Curator·Scribe가 맡습니다.
3단계
Enhancement
서비스의 가치를 높이는 역할. 1·2단계가 안정된 뒤에 작업합니다. Sensei·Herald·Palette·Scout가 맡습니다.
12개의 에이전트와 우선순위 3단계(Echelon)
PM인 저는 Oracle하고만 대화합니다. Oracle이 작업을 분석해 알맞은 에이전트에게 맡기고, 결과를 모아서 보고합니다. 에이전트끼리는 직접 소통하지 않습니다. 충돌이 생기면 Oracle이 중재합니다.
실전에서 체감한 효과
DB 담당이 막아준 DB 사고
문제(Problem) 서비스의 DB 스키마를 바꿀 때였습니다. 컬럼 이름을 바꾸려고 했는데, Librarian의 규칙이 이를 막았습니다.
Expand-Contract 패턴 강제. 컬럼 삭제/rename은 반드시 3단계 배포.
Rolling Update 중 구/신 버전 공존 상황을 항상 가정.
서버를 하나씩 교체하는 배포(Rolling Update) 중에는 옛 버전과 새 버전 코드가 함께 돕니다. 그래서 이름을 바로 바꾸지 않고, 먼저 넓혔다가(Expand) 나중에 줄이는(Contract) 방식으로 가라는 규칙입니다.
단순 rename 대신 세 단계로 진행했습니다. (1) 새 컬럼 추가 → (2) 데이터 복사와 앱 코드 전환 → (3) 옛 컬럼 삭제. 번거롭다고 느꼈지만, 운영 중 다운타임 없이 끝낼 수 있었습니다. 혼자였다면 "그냥 rename하면 되지" 하고 넘어갔을 겁니다.
보안 담당이 잡아낸 보안 잔재
인증 로직을 리팩터링하면서, 토큰을 브라우저 localStorage에 저장하는 코드가 남아 있었습니다. 자바스크립트로 읽을 수 없는 httpOnly 쿠키로 바꾼 뒤에도, 옛 방식의 흔적이 곳곳에 숨어 있었죠. 인증·보안 담당 Gatekeeper의 규칙이 이를 잡아냈습니다.
SSE 인증:
EventSource(url, { withCredentials: true }). httpOnly Cookie 환경에서 localStorage 토큰 사용 불가.
민감 정보 절대 금지: JWT 원문, X-Internal-Key, OAuth 토큰.
(X-Internal-Key는 서비스끼리만 쓰는 내부 인증 키입니다.) 이 규칙 때문에 localStorage에서 토큰을 읽던 코드가 위반으로 걸렸습니다.
사람이라면 "예전에 고쳤으니 됐겠지" 하고 넘어갈 수 있는 부분입니다. 에이전트는 매번 전체를 검사합니다.
맥락이 사라지지 않는다는 것
67개 스프린트를 거치면서 "예전에 왜 이렇게 결정했지?" 하는 순간이 수없이 있었습니다. 문서 담당 Scribe가 관리하는 MEMORY.md와 스프린트별 결정 기록에 모든 결정이 남아 있었습니다. 덕분에 3개월 전 결정도 5초 만에 찾을 수 있었습니다.
혼자 개발할 때 가장 무서운 건 기능이 안 되는 게 아닙니다. 왜 이렇게 만들었는지 잊어버리는 것입니다. 맥락이 사라지면 같은 실수를 반복하거나, 이미 검토한 대안을 다시 고민하게 됩니다. 에이전트 체계는 이 문제를 구조로 해결해줬습니다.
워크플로우 설계의 시행착오
에이전트가 있어도 어떤 순서로 부를지를 잘못 짜면 소용없었습니다. 초기에는 필요한 에이전트를 그때그때 불렀습니다. 그러다 작업 순서가 꼬이면서, 한 에이전트의 결과물이 다른 에이전트의 전제를 깨뜨리는 일이 반복됐습니다.
결국 우선순위 단계를 실행 순서로도 쓰기로 했습니다.
- 1단계(Oracle·Conductor·Gatekeeper·Librarian)가 먼저 기반과 안전장치를 잡고,
- 2단계(Architect·Postman·Curator·Scribe)가 기능을 구현하고,
- 3단계(Sensei·Herald·Palette·Scout)가 마무리합니다.
이 순서를 지키자 의존성 충돌이 크게 줄었습니다.
1단계
인프라 · 안전장치 확보2단계
기능 구현 · 비즈니스 로직3단계
UX · 분석 · 마무리
앞으로의 방향
에이전트 체계를 운영하면서 계속 붙잡고 있는 질문이 있습니다. AI를 통제하면서 생산성을 높이되, 품질은 어떻게 지킬 수 있을까.
통제를 강화하면 생산성이 떨어집니다. 에이전트 결과물을 하나하나 검토하면 혼자 하는 것과 다를 바 없습니다. 반대로 자율을 높이면 품질이 흔들립니다. 에이전트가 혼자 내린 결정이 전체 아키텍처와 어긋나는 순간이 옵니다.
지금까지 찾은 균형점은 세 가지입니다. 역할 경계를 분명히 하고, 공통 규칙을 한 곳에서 관리하고, 위로 올리는 경로를 열어두는 것.
에이전트는 자기 영역 안에서는 스스로 판단합니다. 영역을 벗어나면 반드시 Oracle을 거칩니다. 규칙은 한 파일에서만 관리해(단일 원천, SSoT) 어긋남을 막습니다. 판단하기 어려운 건 사람에게 올라오게 합니다.
이게 완벽한 답인지는 아직 모릅니다. 스프린트가 쌓일수록 새 문제가 나타나고, 그때마다 체계를 조금씩 고쳐가고 있습니다. 확실한 건 하나입니다. 이런 고민 자체가 혼자서는 절대 하지 못했을 종류라는 점입니다.
직접 해 본 경험의 차이
AI 에이전트 오케스트레이션을 글로 읽는 것과 직접 해보는 건 완전히 다른 경험입니다. 글로는 "역할을 나누고 규칙을 만들면 된다"로 요약됩니다. 실제로는 워크플로우가 꼬이고, 맥락이 사라지고, 규칙이 어긋나는 상황을 수십 번 겪으면서 체계가 만들어졌습니다.
해보지 않았다면 "AI가 코드를 짜준다"는 얕은 이해에 머물렀을 겁니다. 해봤기 때문에 알게 된 것들이 있습니다. 에이전트에게 무엇을 맡기고 무엇을 직접 해야 하는지. 통제와 자율의 경계를 어디에 둬야 하는지. 한 사람의 판단력과 12개의 실행력을 어떻게 엮어야 하는지.
결국 중요한 건 시작하는 것이었습니다.