에이전트를 설계할 때 "역할마다 서브에이전트를 하나씩 두고 오케스트레이터가 조율한다"는 구조를 먼저 떠올리기 쉬워요. 그런데 Anthropic Applied AI 팀은 기업 고객 사례를 보면서 반대 방향의 결론에 도달했어요. 라우터·플래너·도메인 서브에이전트를 하나의 메인 에이전트 루프로 합쳤더니, 품질은 오르고 비용과 지연 시간은 줄어든 경우가 많았다는 거예요.
이 글은 Anthropic이 2026년 10월 22일에 공개한 글을 읽고 핵심만 한국어로 정리한 것이에요.
서브에이전트가 여전히 필요한 경우
서브에이전트는 자체 컨텍스트·도구·지시문을 가진 에이전트이고, 검증·병렬 작업·권한 분리에 유용해요. 원문은 다음 상황이라면 서브에이전트를 유지할 만하다고 말해요.
- 단일 루프에서 컨텍스트가 비대해져 성능 저하가 실제로 측정될 때
- 여러 작업을 새 컨텍스트 창에서 병렬로 돌리고 결과만 받은 뒤 버려도 될 때
- 단일 에이전트가 도구를 잘못 고르거나, 시스템 프롬프트 안의 지시가 서로 충돌할 때
반대로 "팀마다 서브에이전트 하나씩"은 피하라고 해요. 그러면 아키텍처가 조직도를 그대로 복사하게 돼요 (콘웨이의 법칙).
대규모 조직에서 생기는 문제
팀별로 서브에이전트를 붙여 나가면 다음 문제가 반복돼요.
- 컨텍스트 손실: 에이전트 사이를 넘어갈 때마다 세부 정보가 빠져요.
- 서브에이전트 난립: 역할이 겹치고 주인이 없는 서브에이전트가 수백 개로 늘어나요.
- "프랑켄프롬프트": 서로 충돌하는 규칙이 쌓이고 일관된 말투가 사라져요.
- 국소적 평가: 팀마다 자기 하위 작업만 최적화해서, 전체 품질 점수는 흐려져요.
- 지연 시간: 한 고객은 단일 루프로 바꾼 뒤 실행 속도가 약 2배 빨라졌어요.
점진적 공개를 갖춘 단일 에이전트 루프
핵심은 스킬과 도구 설명을 짧게만 보여 주고, 필요할 때 전체를 불러오는 점진적 공개(progressive disclosure)예요. 이 방식이 잘 동작하는 이유는 세 가지예요.
- 공유 컨텍스트: 서브에이전트가 돌려주는 요약보다 원본 컨텍스트를 그대로 보는 편이 더 좋은 답을 내요.
- 점진적 공개: 컨텍스트 비대화를 막아요. Anthropic은 최신 모델용 Claude Code 시스템 프롬프트를 80% 이상 줄였어요.
- 모델 역량: Opus 4.5 이후 모델이 충분히 강해져서, 하네스가 하던 판단을 모델에게 더 넘길 수 있어요.
다만 규율이 필요해요. 시스템 프롬프트를 관리하고, 스킬·도구 설명이 제때 호출되도록 다듬고, 컨텍스트·메모리·메모 작성을 의도적으로 설계해야 해요. 전체 품질과 시스템 프롬프트는 중앙 팀 한 곳이 책임지는 구조를 권해요.
여러 에이전트가 꼭 필요하다면 생성자-검증자(generator-verifier)나 오케스트레이터-서브에이전트 같은 가장 단순한 패턴부터 시작하고, 문제 유형이 아니라 컨텍스트 기준으로 나누라고 해요. 문제 유형으로 나누면 넘겨줄 때마다 정보가 흐려지는 "전화 게임"이 돼요.
서브에이전트를 메인 루프로 합치는 방법
목표 구조는 모델 하나, 컨텍스트 창 하나, 열린 도구 루프예요. 턴 수·비용 예산과 쓰기 게이트는 하네스에서 정해요.
[모델] 첫 턴: 계획 작성
│
▼
[모델] 도구 호출 묶음 생성 ──▶ [하네스] 병렬 실행 → 원본 결과 반환
▲ │
└──────── 결과 보고 계획 수정 ◀──────┘
│
▼
답변 또는 예산 소진 → (선택) 목표·검증 체크플래너와 실행자가 같은 모델이라서, 결과가 들어올 때마다 계획을 스스로 고쳐요. 기존 구성 요소는 이렇게 옮겨요.
| 기존 구성 | 옮길 곳 |
|---|---|
| 라우팅 코드 | 모델의 판단 |
| 도메인 절차 | 스킬 |
| 검증·승인 게이트·메모리 조회 | 도구 |
| 거의 항상 필요한 가벼운 로딩 (엔티티 해석 등) | 코드에 그대로 유지 |
단계별로 이전하기
1. 작업 완료 평가부터 만들기
중앙 팀이 관리하는 엔드투엔드 평가 세트와, 스킬마다 함께 배포하는 작은 평가 세트를 준비해요. 골든 예시 10개만 있어도 시작할 수 있어요. 오케스트레이터가 있는 동안은 라우팅 정확도를, 합친 뒤에는 스킬·도구 선택 정확도를 추적해요. 이벤트 타임스탬프를 기록해 두면 나중에 평가로 재생할 수 있어요.
2. 도메인 에이전트 합치기
서로의 출력을 이어 받거나, 데이터를 공유하거나, 자주 함께 호출되는 전문 에이전트부터 합쳐요.
3. 서브에이전트를 도구로 바꾸기
서브에이전트를 남기더라도 메인 에이전트가 도구로 호출하게 바꾸면, 응답 스키마가 통일되고 비교 기준선이 생겨요. 서브에이전트가 사용자와 직접 대화해야 할 때만 완전한 핸드오프를 써요. 그래도 프롬프트와 담당자가 따로 있고, 요약에서 정보가 빠지고, 모델 루프가 중첩돼 느려지는 문제는 남아요.
4. 한 번에 하나씩 접어 넣기
서브에이전트의 프롬프트는 스킬로, API 호출은 MCP 도구로 바꾼 뒤, 서브에이전트가 있을 때와 없을 때의 평가를 비교해요. 원문의 고객 지원 에이전트 예시에서는 서브에이전트 하나를 합쳤더니 지연 시간은 줄었지만, 원래 통과하던 프로세스 하나가 깨졌어요. 그래서 전체 점수만 보지 말고 어떤 작업의 결과가 뒤집혔는지 확인하라고 해요. 실패가 간헐적일 수 있으니 각 작업은 여러 번 돌려요.
여러 팀이 기여하는 방법
- MCP 도구: 동작, 실시간 데이터 조회, 형태가 고정된 결과에 써요. API마다 도구를 하나씩 만들지 말고 사용자 의도 기준으로 묶어요. 도구 정의가 30~50개를 넘으면 선택 정확도가 떨어지므로, 지연 로딩과 도구 검색을 활용해요. 사용자별 권한은 각 도구 안에서 강제할 수 있어요.
- 스킬: 팀이 일하는 방식, 즉 절차·규칙·판단 기준을 담아요. 스킬은 각 팀이 소유하고,
/skill-creator·/skill-doctor로 작성·정리·점검해요. - 지식 베이스: 참고 자료는 검색·조회 도구로 가져오거나 스킬 안의 참조 파일로 넣어요. 코드가 컨텍스트를 프롬프트에 직접 붙여 넣는 방식은 권하지 않아요.
작업을 빠르게 해 주는 도구
| 명령 | 하는 일 |
|---|---|
/claude-api build-eval | 엔드투엔드 또는 스킬별 평가 생성 |
/claude-api prompt-audit | 예전 모델용으로 쓰인 낡은 지시를 찾아 수정 diff 제안 |
/claude-api hillclimb | 평가 기준으로 앱을 반복 개선 (합친 스킬이 서브에이전트만큼 좋은지 검증 포함) |
/claude-api cost-optimize | 호출을 분석해 캐싱·토큰 절감·effort·모델 선택 등 절감안을 하나씩 제안 |
이 과정을 하나의 흐름으로 묶은 마이그레이션 키트(anthropics/single-agent-loop-kit)도 공개돼 있고, 모의 시스템으로 해 볼 수 있는 데모가 들어 있어요.
마무리
어떤 아키텍처가 최선인지는 모델이 발전하면서 계속 바뀔 거예요. 원문이 남기는 원칙은 하나예요. "측정하고, 한 번에 하나만 바꾸고, 버티는 것만 남겨라."
작은 엔드투엔드 평가를 만들고, 서브에이전트 하나를 메인 루프에 합쳐 보고, 합친 쪽 점수가 더 나쁠 때만 서브에이전트로 남겨 두세요. 이 과정을 반복하면 조직도가 아니라 실제 작업에 맞는 에이전트 구조가 남을 거예요.