에이전트를 여러 개 띄우면 생산성이 배로 오를 것 같지만, 실제로는 같은 파일을 서로 덮어쓰고 "완료했습니다"라는 보고가 사실인지 확인할 수 없는 상태가 먼저 찾아옵니다. 멀티에이전트에서 성패를 가르는 것은 모델의 성능이 아니라 역할 분리·검수·기록이라는 세 가지 운영 장치입니다. 이 글은 그 장치를 어떤 순서로 세우는지 정리합니다.
멀티에이전트는 왜 에이전트 하나보다 어려운가?
AI 에이전트 하나를 쓸 때는 사람이 모든 출력을 눈으로 확인합니다. 에이전트가 셋, 넷으로 늘어나면 그 확인이 물리적으로 불가능해지고, 여기서 세 가지 문제가 동시에 발생합니다.
첫째, 충돌입니다. 두 에이전트가 같은 파일을 동시에 고치면 나중에 저장한 쪽이 앞의 작업을 지웁니다. 둘째, 검증 불가입니다. 사람이 확인하지 못하는 완료 보고가 쌓이고, 그중 일부는 사실이 아닙니다. 셋째, 기억 소실입니다. 세션이 끊기면 무엇이 어디까지 진행됐는지 아무도 모릅니다.
모델을 더 좋은 것으로 바꿔도 이 세 문제는 그대로 남습니다. 구조의 문제이기 때문입니다.
1단계: 역할을 겹치지 않게 나눈다
부서를 나눌 때 흔한 실수는 능력 기준으로 나누는 것입니다. 실무에서 유효한 기준은 금지입니다. 각 에이전트 정의에 "무엇을 하는가"만 쓰지 말고 "무엇을 하지 않는가"를 함께 적으면 경계가 분명해집니다.
| 역할 | 하는 일 | 하지 않는 일 |
|---|---|---|
| 기획 | 우선순위 결정, 요구사항 정리 | 구현 |
| 개발 | 코드 작성·수정·배포 | 자기 작업의 완료 판정 |
| 감사 | 완료 보고 재검증 | 산출물 작성 |
시작 단계에서는 이 세 역할이면 충분합니다. 부서를 늘릴수록 지시서와 검수 비용이 함께 늘어나기 때문에, 새 역할은 "기존 역할이 반복적으로 못 하는 일"이 기록으로 확인될 때만 추가하는 편이 안전합니다.
2단계: 공통 규칙을 파일 하나에 고정한다
에이전트는 세션이 바뀌면 이전 대화를 기억하지 못합니다. 그래서 매 세션 자동으로 읽히는 규칙 파일이 필요합니다. Claude Code라면 CLAUDE.md가 그 역할을 합니다.
멀티에이전트 환경에서 특히 효과가 큰 조항은 협업 규칙입니다.
- 작업 시작 전 항상 최신화한다(git pull --rebase).
- 의미 있는 진전마다 커밋한다: [에이전트ID] 한 일 한 줄.
- 자기 영역 우선 — 같은 파일을 두 에이전트가 동시에 만지지 않는다.
- 공유 문서는 덮어쓰지 말고 덧붙인다(append).
- 충돌이 나면 임의로 합치지 말고 멈춰서 보고한다.
마지막 조항이 가장 중요합니다. 충돌 사고는 대부분 에이전트가 "알아서 잘 처리"하려다 발생합니다. 판단이 필요한 지점에서 멈추게 하는 것이 자동 병합보다 안전합니다.
규칙은 짧게 유지하고, 정말 중요한 것은 문서가 아니라 훅으로 강제하는 편이 확실합니다. 예를 들어 시크릿(토큰·키) 커밋 차단과 강제 푸시(force push) 차단은 규칙으로 적어두는 것보다 커밋 훅이 기계적으로 막게 하는 쪽이 훨씬 잘 지켜집니다.
3단계: 지시는 지시서로, 결과는 경로로 받는다
대화창으로 흘려보낸 지시는 세션이 끊기면 사라집니다. 작업마다 다음 형식의 지시서를 파일로 남기면 다른 에이전트가 그대로 이어받을 수 있습니다.
- 목표: 무엇을 만드는가
- 제약: 하지 말 것, 건드리지 말 파일
- 산출물 경로: 결과를 어디에 쓸 것인가
- 분량 상한: 지시서 자체의 길이 제한
분량 상한을 두는 이유는 두 가지입니다. 지시서가 길어지면 에이전트가 핵심을 놓치고, 동시에 컨텍스트 창을 낭비해 비용이 올라갑니다. 파일 내용을 지시서에 붙여넣지 말고 경로만 전달하는 것도 같은 이유입니다.
4단계: 완료 보고를 증거로 받는다
멀티에이전트 운영에서 가장 값비싼 실수는 "완료했습니다"를 그대로 수락하는 것입니다. 증거의 기준을 미리 정해두면 이 문제가 크게 줄어듭니다.
- 증거는 명령 원문과 출력 원문의 쌍으로만 인정한다. "확인했습니다"라는 서술은 증거가 아닙니다.
- 숫자를 요구한다. "빌드 성공"이 아니라 "빌드 10페이지·에러 0", "테스트 48/48"처럼 재현 가능한 형태로 받습니다.
- 검증 도구 자체를 의심한다. 통과(초록불)만 보지 말고, 데이터를 일부러 망가뜨렸을 때 실패(빨간불)가 뜨는지 확인합니다. 이것을 변이 검증이라고 부릅니다.
세 번째 항목이 낯설게 들릴 수 있지만, 실무에서는 자주 필요합니다. 검사 대상이 비어 있으면 검증 스크립트가 아무것도 확인하지 않은 채 성공 코드를 반환하는 일이 흔하기 때문입니다. 통과라는 결과 자체가 무의미할 수 있다는 뜻입니다. 에이전트가 환각으로 만들어낸 출처나 수치도 같은 방식으로 걸러야 합니다. 링크가 실제로 열리는지(HTTP 200) 기계가 확인하게 하는 것이 사람이 눈으로 보는 것보다 정확합니다.
5단계: 감사를 만든 쪽과 분리한다
작성한 에이전트에게 검수를 맡기면 자기 결과를 정당화하는 방향으로 결론이 납니다. 감사를 전담하는 에이전트를 따로 두고, 지시는 한 줄로 충분합니다.
이 보고가 거짓이라고 가정하고 무너뜨려 보세요.
감사가 지켜야 할 원칙도 하나 있습니다. 남이 만든 증거를 다시 읽는 것은 감사가 아닙니다. 직접 재현하거나 직접 망가뜨려서 같은 결과가 나오는지 확인해야 합니다. 사람이 검수 지점에 개입한다면, 모든 산출물을 읽는 대신 이 감사 결과만 확인하는 편이 시간 대비 효과가 큽니다.
6단계: 작업 기억을 폴더로 남긴다
세션은 반드시 끊깁니다. 작업 하나당 폴더 하나를 만들고 세 파일을 두면 어떤 에이전트가 새로 들어와도 이어받을 수 있습니다.
| 파일 | 내용 | 원칙 |
|---|---|---|
task.md | 목표·측정 가능한 완료 기준·상태 | 완료 기준은 숫자로 |
context.md | 현재 상태 스냅샷 | 히스토리 금지, 분량 상한 |
log.md | 진행·검수·결정 기록 | 덧붙이기만, 수정·삭제 금지 |
log.md를 수정 불가로 두는 것이 핵심입니다. 기록을 고칠 수 있으면 실패한 시도가 조용히 사라지고, 같은 실패를 반복하게 됩니다.
7단계: 비용을 계측한다
멀티에이전트의 비용은 감으로 관리되지 않습니다. 에이전트를 호출할 때마다 다음을 한 줄로 남기면 몇 주 뒤에 패턴이 보입니다.
완료 | model=<모델> tokens=<토큰> dur_ms=<소요> outcome=<결과> rework=<재작업 횟수>
여기서 가장 중요한 값은 **재작업 횟수(rework)**입니다. 싼 모델로 세 번 시킨 작업이 비싼 모델로 한 번에 끝낸 작업보다 비쌀 수 있고, 그 판단은 계측 없이는 불가능합니다. 참고로 커밋 수나 산출물 개수는 활동량 지표일 뿐 성과 지표가 아닙니다. 작은 커밋을 자주 남기라는 규칙이 있는 조직에서는 오히려 부풀기 쉽습니다.
계측이 쌓이면 라우팅 기준도 데이터로 정할 수 있습니다. 형식 변환이나 목록 수집 같은 기계적인 작업은 저렴한 모델로 충분하고, 검수·감사·설계는 비싼 모델이 결과적으로 저렴합니다. 놓친 결함 하나의 수습 비용이 검수 비용보다 크기 때문입니다. 토큰 단위로 비용을 보는 습관이 여기서 도움이 됩니다.
사람은 어디에 개입해야 하는가?
사람이 할 일은 실행이 아니라 승인 지점 설계입니다. 다음 세 곳만 남기고 나머지는 위임하는 기준이 실무에서 잘 작동합니다.
- 돈이 나가는 지점
- 외부에 공개되는 지점
- 되돌리기 어려운 지점
반복되는 승인은 정책으로 바꿀 수 있습니다. "매번 물어보기" 대신 "검수를 통과하면 진행, 그 외는 승인 대기"처럼 조건을 명문화하면 승인 지점이 줄어듭니다. 반대로 사람이 자리를 비웠을 때 에이전트가 승인 대기 상태로 조용히 멈춰 있는 것이 가장 큰 낭비이므로, 승인이 필요한 순간에는 알림이 가도록 연결해 두는 편이 좋습니다.
자주 묻는 질문
- Q. 에이전트는 몇 개부터 시작하는 게 좋나요?
- A. 만드는 역할, 검사하는 역할, 정하는 역할 세 개면 충분합니다. 역할이 늘어날수록 지시서와 검수 비용도 함께 늘어나므로, 기존 역할이 반복적으로 못 하는 일이 기록으로 확인될 때 추가하는 편이 안전합니다.
- Q. 감사 에이전트를 처음부터 둬야 하나요?
- A. 그렇습니다. 감사는 조직이 커진 뒤 추가하는 선택 사항이 아닙니다. 검증 없는 위임은 위임이 아니라 방치가 되고, 검증되지 않은 완료 보고가 쌓인 뒤에 되돌리는 비용이 훨씬 큽니다.
- Q. 에이전트끼리 어떻게 소통시키나요?
- A. 별도 메시지 채널을 만들기보다 저장소 하나를 공유하게 하는 방식이 단순하고 추적이 쉽습니다. 시작 전 최신화, 작은 커밋, 커밋 메시지에 담당 표기라는 세 규칙만으로도 누가 무엇을 했는지 추적할 수 있습니다.
- Q. "완료했습니다"를 어떻게 검증하나요?
- A. 명령 원문과 출력 원문을 함께 요구하고, 숫자로 받으세요. 여기에 검증 도구를 일부러 망가뜨려 실패가 뜨는지 확인하는 단계를 더하면, 아무것도 검사하지 않고 통과한 경우를 걸러낼 수 있습니다.
더 읽을거리
에이전트 개념 자체가 낯설다면 AI 에이전트 시작하기부터, 규칙 파일 작성이 궁금하다면 CLAUDE.md 작성법을 먼저 보세요. 에이전트가 외부 도구·데이터와 연결되는 방식은 MCP란 무엇인가에서 다룹니다.
이 글의 운영 방식을 실제 사례로 확인하고 싶다면, 이 사이트를 운영하는 1인 AI 회사의 기록을 정리한 전자책 『1인 AI 회사 실전기』를 참고할 수 있습니다. 위에서 다룬 감사·계측·게이트가 실제 운영 로그(파일명과 줄 번호를 병기한 원문 인용)와 함께 실려 있습니다.
이 글의 규약·작업 폴더·지시서 양식을 파일 형태로 바로 쓰고 싶다면 멀티에이전트 스타터 키트에 해당 파일 11개가 그대로 들어 있습니다. 30분 셋업 가이드와 단계별 통과 게이트가 함께 있습니다.