서브에이전트 위임의 기준 — 조직도가 아니라 작업 경계

AI 페어 프로그래밍

에이전트를 늘리면 개발이 빨라질까

서브에이전트 위임의 기준 — 조직도가 아니라 작업 경계

핵심 요약

• 멀티에이전트는 분명한 트렌드지만, "많이 띄울수록 좋다"는 입증된 적이 없다. 같은 연구 안에서도 독립적으로 쪼개지는 작업은 최대 +80.8%, 순차 의존이 강한 작업은 39~70% 악화됐다 — 성패를 가르는 건 에이전트 수가 아니라 작업의 구조다.
• 서브에이전트는 새로운 전문가가 아니다 — 부모의 대화도, 읽은 파일도 모르는 빈 컨텍스트에서 시작하는 임시 워커다. "20년 경력 전문가" 역할극은 전문성을 만들지 않는다.
• 위임 전 네 가지 게이트: 독립성 · 압축 가능성 · 검증 가능성 · 경제성. 하나라도 막히면 직접 하는 게 낫다.
• 가장 잘 맞는 건 읽기 위주 작업(코드 탐색·로그 분석·독립 리뷰). 최악은 같은 파일·같은 계약을 여러 에이전트가 병렬로 고치는 것.

1.조직도를 복제하고 싶은 유혹

AI 코딩 도구들이 서브에이전트를 지원하기 시작하면서 어디서나 보이는 패턴이 하나 있다. PM 에이전트, 설계자 에이전트, 백엔드 개발자 에이전트, QA 에이전트 — 사람 회사의 조직도를 그대로 복제한 "AI 개발팀"이다. 직관적으로 그럴듯하다. 사람은 분업으로 생산성을 올렸으니, AI도 그러지 않을까?

그런데 사람의 분업이 작동하는 전제가 AI에겐 없다. 사람 팀이 강한 건 구성원마다 서로 다른 경험, 서로 다른 장기 기억, 서로 다른 관점을 갖고 있어서다. 같은 기반 모델로 만든 에이전트들은 직함이 달라도 같은 사전지식과 같은 맹점을 공유한다 — 같은 자리에서, 같이 틀린다. 역할 이름을 늘리는 건 검토 관점을 늘리는 게 아니라 같은 검토자를 여러 벌 복사하는 것에 가깝다. 이 유혹의 정체를 이해하려면 먼저 서브에이전트가 실제로 뭔지부터 봐야 한다.

2.서브에이전트의 실체 — 빈 컨텍스트에서 시작하는 임시 워커

서브에이전트는 대부분의 도구에서 격리된 새 컨텍스트로 시작한다. 부모 에이전트가 나눈 대화 전체, 이미 읽은 파일, 도구를 쓰며 얻은 중간 결과 — 아무것도 자동으로 물려받지 않는다. 위임 메시지와 프로젝트 지침 파일 정도가 출발점의 전부다. 그래서 "설계자 에이전트"를 만들어도 새 전문가가 고용되는 게 아니다 — 같은 모델이, 더 적은 맥락으로, 별도 창구에서 일을 시작할 뿐이다.

❌ 흔히 만드는 persona 에이전트 — 전문성이 아니라 토큰 낭비agent 정의

너는 20년 경력의 시니어 백엔드 전문가다.
항상 최고 품질의 코드를 작성하고, 모범 사례를 따르라.
# 기반 모델이 이미 아는 일반론의 반복 — 행동이 달라질 근거가 없다

전문 에이전트라는 이름값을 하려면 persona 문구가 아니라 운영상의 차이가 최소 하나는 있어야 한다 — 다른 도구·데이터 접근, 다른 권한 경계(예: 읽기 전용), 다른 정본 문서, 반복되는 입·출력 계약, 부모의 추론에 오염되지 않아야 하는 독립 검증 관점. 이 중 아무것도 다르지 않다면, 그 에이전트는 프롬프트 한 단락으로 충분했다.

3.숫자로 보는 명암

"멀티에이전트가 낫다"는 주장과 "낭비다"라는 주장 모두 실측 근거가 있다. 나란히 놓고 보면 조건이 갈릴 뿐이다.

사례	작업 구조	결과
병렬 리서치 시스템 (Anthropic 내부 평가)	독립 검색 경로, 결과는 짧게 압축	단일 대비 +90.2% — 단, 토큰 15배
금융 분석 벤치마크 (구글·MIT 연구진)	독립적으로 분해 가능	최대 +80.8%
순차 계획 벤치마크 (같은 연구)	단계가 서로 의존	39~70% 악화
실제 코드 수정 벤치마크 (같은 연구)	공유 상태·순차 의존 혼재	단일 대비 평균 2~15% 낮음
동일 예산 비교 연구	추론 토큰 총량을 고정	단일 에이전트가 같거나 더 좋음

마지막 행이 특히 아프다 — 멀티에이전트가 좋아 보였던 결과의 일부는 에이전트 구조 덕이 아니라 그냥 compute를 더 썼기 때문일 수 있다는 뜻이다. (이 수치들 대부분은 동료평가 전 연구이고 표본도 작으니 숫자 자체보다 방향을 읽어야 한다.) 방향은 일관된다 — 에이전트 수가 아니라, 작업이 독립적으로 쪼개지는지가 성패를 결정한다. 쪼개지는 작업에선 크게 이기고, 안 쪼개지는 작업에선 조율 비용만 낸다.

4.위임 전 네 개의 게이트

그래서 "이 작업을 서브에이전트에 맡길까?"는 네 개의 게이트로 판단할 수 있다. 하나라도 막히면 직접 하는 쪽이 보통 낫다.

서브에이전트 스폰 판단 게이트체크리스트

Gate A 독립성    다른 작업의 결과를 기다리지 않는가?
              같은 파일·스키마·API 계약을 동시에 고치지 않는가?
Gate B 압축성    수십 파일을 읽어도 결과는 짧게 요약해 돌아오는가?
Gate C 검증성    테스트·diff·공식 문서 같은 외부 기준으로 판정 가능한가?
Gate D 경제성    병렬로 아낀 시간이 중복 탐색·통합·리뷰 비용보다 큰가?

이 게이트를 작업 유형에 대입하면 기본 선택지가 나온다.

작업 특성	기본 선택
짧고 공유 맥락이 큼	직접 수행
길고 순차적, 상태 의존이 큼	직접, 끝까지
읽기 위주, 탐색량이 크고 요약 가능	서브에이전트
독립 가설·후보 여러 개 비교	서브에이전트 2~3개 → 직접 합성
같은 파일을 병렬 수정	금지 — 또는 격리 작업공간 + 명시적 소유권
독립 리뷰	새 컨텍스트 + 명세·diff·테스트 증거 제공

5.read부터 맡겨라 — 그리고 보고서를 믿지 마라

게이트를 가장 쉽게 통과하는 건 읽기 위주 작업이다. 관련 코드·의존성 탐색, 공식 문서 조사, 긴 테스트 로그 분석, 변경 후 누락 찾기 — 중간 탐색은 크지만 반환물은 짧고, 저장소를 건드리지 않으니 실패해도 피해가 없다. 반대로 쓰기 작업의 병렬 위임은 훨씬 엄격하게 다뤄야 하는데, 여기엔 직접 겪은 수업료가 있다.

한번은 큰 파일의 모듈 분리를 서브에이전트에 맡겼다. 결과 보고는 깔끔했다 — "분리 완료". 실제로는 새 파일만 만들고, 원본 파일이 그걸 사용하도록 바꾸는 일은 하지 않았다. 같은 클래스가 두 벌 공존하는 dead code가 생긴 것이다. import를 직접 검색하고서야 발견했다. 또 한번은 리뷰를 맡겼더니 이미 고쳐진 버그를 다시 지적했다 — 예전 시점의 코드 기억과 패턴 매칭으로 만든 그럴듯한 finding이었다. 검증 없이 받아들였다면 멀쩡한 코드를 "고치는" 재작업을 했을 거다.

⚠ 요약만 보고 통합하지 마라

서브에이전트의 성공 보고는 판단 근거가 아니다. 실제 diff와 테스트 결과가 근거다. 워커가 "완료"라고 하면 결론이 아니라 가설로 받고, 최소한 변경 파일 목록과 검증 명령의 실제 출력을 확인한다. 이게 게이트 C(검증성)를 위임 후에도 계속 지키는 방법이다.

6.독립 리뷰를 진짜 독립으로 만드는 법

서브에이전트가 구조적으로 가장 빛나는 자리는 독립 리뷰다 — 구현 과정의 추론에 오염되지 않은 새 눈. 단, 여기엔 흔한 오해가 있다. 독립성은 정보를 차단하는 게 아니라 편향을 차단하는 것이다.

• 주지 말아야 할 것: 구현자의 "잘 됐다"는 요약, 구현 중의 추론 과정. 이걸 주면 리뷰가 아니라 설명에 대한 동의가 된다.
• 반드시 줘야 할 것: 원래 요구사항(명세), 실제 diff, 관련 계약 문서, 실행된 테스트 결과. 리뷰어는 이걸 직접 확인해야 한다.

그리고 리뷰어를 여럿 두더라도 같은 모델 여럿의 다수결은 정확성의 근거가 아니다 — 상관된 오류는 투표로 제거되지 않는다. 관점을 진짜로 다르게 하려면 숫자가 아니라 조건을 바꿔야 한다: 다른 검증 도구, 다른 근거 자료, 실행된 테스트, 원본 diff 직접 대조. 결과를 무엇으로 판정할지(검증 사다리)와 실수를 시스템 개선으로 바꾸는 설계는 짝이 되는 글에서 다뤘다.

함께 읽기 →

프롬프트를 고치지 말고 시스템을 고쳐라

결과를 "완료 보고"가 아니라 외부 증거로 판정하는 검증 사다리, 그리고 실수를 재발 불가능하게 만드는 하네스 설계.

7.위임 메시지는 요약이 아니라 명세다

서브에이전트는 부모의 히스토리를 모르므로, 좋은 위임 메시지는 대화의 요약문이 아니라 독립 실행 가능한 작은 명세여야 한다. 표준 형식을 하나 정해두면 위임 품질이 확 오른다.

위임 메시지(context packet) 표준Markdown

# 목표 — 이 작업에서 확인하거나 만들어야 하는 것
# 배경 — 사용자 요구와 이 작업이 필요한 이유
# 이미 결정된 사항 — 채택한 설계 / 기각한 대안 / 바꾸면 안 되는 계약
# 범위 — 읽을 경로 / 수정 가능한 경로 / 건드리면 안 되는 경로
# 기대 산출물 — 출력 형식, finding마다 필요한 근거
# 검증 — 실행할 명령, 성공 조건, 실패 시 보고할 내용

특히 "이미 결정된 사항"이 핵심이다. 이게 빠지면 워커가 이미 기각된 설계를 다시 제안하거나, 임시로 정한 인터페이스를 확정된 계약으로 오해한다 — 멀티에이전트 실패 사례 분석들이 공통으로 지목하는 지점도 모델의 능력 부족이 아니라 이런 인수인계(handoff)와 검증의 구멍이었다.

8.정리 — 병목은 생성이 아니라 검증이다

마지막 반례 하나는 남겨두자. 강한 테스트가 이미 있고 실패 항목이 서로 독립적인 작업 — 예컨대 신규 프로젝트의 대량 반복 작업 — 에서는 수십 개 병렬 에이전트가 실제로 유효했다는 사례들도 있다. 병렬화가 틀린 게 아니라 조건부라는 얘기다. 그리고 그 조건의 끝에는 항상 같은 병목이 있다 — 에이전트가 코드를 만드는 속도가 아니라 사람이 그걸 이해하고 검증하는 속도. 리뷰 못 한 diff가 쌓이는 속도는 생산성이 아니다.

그래서 유지할 가치가 있는 멀티에이전트 워크플로우인지는 체감이 아니라 기록으로 판단한다 — 성공 1건당 토큰, 재작업률, 충돌 횟수, 리뷰 시간. 늘어난 게 생성량뿐이라면 줄이는 게 맞다.

한 문장으로 줄이면 — 서브에이전트는 전문가 고용이 아니라 컨텍스트 격리다. 독립성이 자산이면 위임하고, 공유 맥락이 자산이면 직접 하라.

바이브코딩 · AI와 더 잘 일하는 법