[AI] Claude Code에서 멀티 에이전트는 언제 써야 할까
부수 작업이 메인 대화를 채우면 서브에이전트를 쓰고, 단계가 서로 의존하면 혼자 처리합니다. 여러 에이전트로 나누는 일은 병렬화할 부분이 많고 가치가 큰 작업에만 맞습니다. 토큰과 조율 비용이 크게 늘기 때문입니다.
서브에이전트와 멀티 에이전트는 층위가 다릅니다
서브에이전트는 Claude Code의 기능입니다. 자체 컨텍스트 윈도, 시스템 프롬프트, 도구 접근, 독립 권한을 가지고 작업한 뒤 요약만 돌려줍니다. 검색 결과, 로그, 파일 내용처럼 메인 대화를 채울 부수 작업을 맡길 때 씁니다(Claude Code 공식 문서).
멀티 에이전트는 여러 에이전트를 묶은 구조를 가리킵니다. Anthropic Research 기능은 lead agent가 계획을 세우고 서브에이전트를 병렬로 띄우는 구조를 씁니다(Anthropic 엔지니어링 블로그, 2025-06-13). 이 구조에서도 일을 나눠 맡는 각 일꾼이 서브에이전트입니다. 두 개념은 서로 대신 고르는 선택지가 아니라, 기능과 그 기능을 묶는 구조의 관계입니다.
여러 세션이 붙는 구조가 필요하면 Claude Code에도 별도 기능이 있습니다. 독립 세션을 병렬로 돌리려면 background agents, 세션끼리 메시지를 주고받으려면 cross-session messaging, Claude가 띄우고 감독하는 팀은 agent teams입니다.
서브에이전트가 값을 하는 경우
공식 문서가 드는 이점은 다섯 가지입니다.
- 메인 대화의 컨텍스트 보존
- 서브에이전트가 쓸 도구 제한
- 사용자 수준 서브에이전트로 여러 프로젝트에서 설정 재사용
- 도메인별 시스템 프롬프트로 특화
- Haiku 같은 더 빠르고 저렴한 모델로 보내 비용 제어
예를 들어 수천 줄 테스트 로그에서 실패 원인 파일을 찾는 작업이 여기에 맞습니다. 서브에이전트가 로그를 읽고 원인 파일과 근거만 요약해 돌려주면 메인 대화에는 요약만 남습니다. 코드를 고치지 않는 탐색이면 쓰기와 편집이 막힌 내장 Explore를 쓰면 되고, 같은 지시로 같은 작업자를 반복해서 띄운다면 커스텀 서브에이전트를 정의해 도구와 모델을 정해 둡니다.
비용은 남습니다. 서브에이전트의 요청도 메인 대화와 같은 사용량 한도에 포함되고, 내장 서브에이전트를 뺀 description 합계가 15,000 토큰을 넘으면 시작할 때 경고가 뜹니다. description은 짧게 쓰고 상세한 지시는 시스템 프롬프트에 두는 편이 좋습니다.
여러 에이전트로 나눌 때
작업이 서로 독립적인 조각으로 갈라지고, 필요한 정보가 한 컨텍스트 윈도에 들어가지 않고, 복잡한 도구가 많이 필요하면 나눌 만합니다. Anthropic은 이런 고가치 작업이 멀티 에이전트에 잘 맞는다고 씁니다. 예를 들어 서로 다른 세 라이브러리의 마이그레이션 방법을 각각 조사해 비교하는 작업입니다.
아래 수치는 Claude Code가 아니라 Anthropic Research 기능의 2025년 6월 글 기준입니다. 서브에이전트는 각자 컨텍스트 윈도에서 질문의 다른 측면을 동시에 탐색하고 핵심만 lead에 전달합니다. 서브에이전트마다 도구, 프롬프트, 탐색 방향이 달라 한 방향에 끌려가지 않고 따로 조사합니다. lead가 서브에이전트 35개를 병렬로 띄우고 각자 도구 3개 이상을 병렬로 쓰자 복잡한 질의의 연구 시간이 최대 90% 줄었습니다. 같은 글의 규모 가이드는 직접 비교에 서브에이전트 24개입니다.
나누기 전에 조각마다 목표, 출력 형식, 쓸 도구와 출처 지침, 작업 경계를 적어 둡니다. Research 사례에서는 이 지침이 없으면 같은 일을 두 번 하거나 빠뜨렸습니다.
나누면 손해인 경우
앞 단계의 결과가 다음 단계의 입력이 되면 나누지 않습니다. 예를 들어 함수 시그니처를 바꾸고 호출부를 고치고 그 변화에 맞춰 테스트를 고치는 작업은 한 컨텍스트에서 처리해야 합니다. Anthropic도 모든 에이전트가 같은 컨텍스트를 공유해야 하거나 의존성이 많은 영역은 멀티 에이전트에 맞지 않는다고 씁니다.
비용도 커집니다. Research 사례에서는 에이전트가 채팅 대비 약 4배, 멀티 에이전트 시스템이 약 15배 토큰을 썼습니다. 같은 사례에서 LLM 에이전트는 아직 실시간으로 다른 에이전트를 조율하고 위임하는 데 능숙하지 않았고, lead가 서브에이전트 묶음이 끝날 때까지 기다리는 동안 서브에이전트를 조정하지도 서로 조율하지도 못해 병목이 생겼습니다. 초기 버전에서는 단순 질의에 서브에이전트 50개를 만들고, 없는 출처를 끝없이 검색하고, 과도한 업데이트로 서로 방해했습니다.
판단 기준
- 다음 단계가 앞 단계 결과에 기대는가. 그렇다면 혼자 처리합니다.
- 읽은 내용을 다시 볼 일 없이 요약만 필요하고, 그 양이 메인 대화를 채울 만한가. 그렇다면 서브에이전트에 맡깁니다.
- 조각이 독립적이고, 정보가 한 컨텍스트에 들어가지 않고, 복잡한 도구가 많이 필요한가. 모두 그렇다면 병렬로 나눕니다.
- 나눠서 아끼는 시간과 검증 이득이 토큰과 조율 비용을 넘는가. 넘지 않으면 나누지 않습니다.
- 조각마다 목표, 출력, 도구, 경계를 쓸 수 있는가. 쓸 수 없으면 아직 나눌 단계가 아닙니다.