멀티 에이전트 작업 설계: 메인과 작업자 나누기, 한 작업의 크기

🤔 작업자를 다섯 개 띄웠는데 합치는 데 더 오래 걸릴 때

코딩 에이전트 여러 개를 동시에 돌리는 도구가 늘면서, 큰 기능 하나를 다섯 조각으로 나눠 다섯 에이전트에게 맡기는 방식을 시도하는 경우가 많아졌습니다. 그런데 막상 해 보면 각자 끝낸 결과를 합치는 단계에서 막힙니다. 두 에이전트가 같은 파일을 서로 다르게 고쳐 놓았고, 한쪽은 다른 쪽이 만들 함수 이름을 짐작해서 썼고, 셋째는 맡긴 범위를 넘어 테스트 설정까지 바꿔 놓았습니다. 혼자 순서대로 했을 때보다 오히려 시간이 더 걸립니다.

원인은 에이전트의 실력이 아니라 나누는 방식에 있는 경우가 대부분입니다. 멀티 에이전트 구조의 기본 원리는 멀티 에이전트 오케스트레이션에서 다뤘고, 이 편에서는 실제로 일을 나눌 때 내려야 하는 설계 판단을 다룹니다. 누가 무엇을 소유하는지, 무엇을 병렬로 돌리고 무엇을 순서대로 잇는지, 한 작업을 얼마나 크게 자를지입니다.

🔑 멀티 에이전트 작업 설계의 정의

멀티 에이전트 작업 설계는 하나의 목표를 여러 코딩 에이전트에게 맡기기 전에 누가 무엇을 소유하고 어떤 순서로 돌며 결과를 어떻게 합칠지를 정하는 일입니다.

여기서 메인은 전체 목표를 받아 일을 쪼개고 결과를 합치는 에이전트나 사람이고, 작업자는 나눠 받은 한 조각만 맡는 에이전트입니다. 앤트로픽은 이 구조를 오케스트레이터-워커 패턴이라 부르며, 가운데의 모델이 일을 동적으로 쪼개 작업자에게 맡기고 결과를 합친다고 설명합니다.

🧭 메인과 작업자가 맡는 일

설계의 첫 결정은 메인이 무엇을 하고 무엇을 하지 않을지입니다.

메인이 직접 구현에 들어가지 않는 이유는 컨텍스트 때문입니다. 클로드 코드 문서는 서브에이전트가 자기 컨텍스트에서 일하고 요약만 돌려준다고 설명하며, 다시 볼 일 없는 검색 결과나 로그가 메인 대화를 채울 때 쓰라고 권합니다. 메인이 구현 세부를 붙들고 있으면 전체 상태를 판단할 여유가 줄어들고, 결과를 합치는 단계에서 필요한 정보가 이미 요약되어 사라져 있기도 합니다. 공사 현장의 반장이 벽돌을 직접 쌓기 시작하면 현장 전체를 보는 사람이 없어지는 것과 같습니다.

✂️ 일을 나누는 세 가지 기준

1. 소유권: 파일이 겹치지 않게 나눕니다

가장 먼저 볼 기준입니다. 두 작업자가 같은 파일을 고치게 두면 한쪽 변경이 다른 쪽 변경을 덮거나, 합칠 때 충돌이 납니다. 그래서 작업을 기능 단위가 아니라 파일과 폴더 단위로 먼저 그어 봅니다. 화면 컴포넌트는 A, 데이터 조회 함수는 B, 설정 파일은 누구도 건드리지 않음처럼 소유 범위를 명세에 적습니다. 각 작업자를 따로 된 작업 폴더에서 돌리는 방법은 워크트리와 병렬 세션에서 다룹니다.

2. 의존 관계: 병렬과 순서를 구분합니다

서로의 결과가 필요 없는 작업은 동시에 돌리고, 결과가 필요한 작업은 순서대로 잇습니다. 여러 작업을 동시에 내보냈다가 끝나면 모으는 형태를 팬아웃과 팬인(fan-out, fan-in)이라 부르고, 앞 작업의 결과가 다음 작업의 입력이 되는 형태를 파이프라인이라 부릅니다. 자세한 모양은 AI 그래프 엔지니어링에 정리되어 있습니다.

까다로운 것은 숨은 의존입니다. 화면 수정과 API 수정처럼 파일은 다르지만 한쪽이 다른 쪽의 응답 형식을 알아야 하는 경우입니다. 이때는 메인이 약속, 즉 응답 형식이나 함수 이름을 먼저 정해 양쪽 명세에 똑같이 적어 두면 병렬로 돌릴 수 있습니다. 약속을 미리 정하기 어렵다면 순서대로 잇는 편이 안전합니다.

3. 검수 단위: 한 번에 판정할 수 있는 크기로 자릅니다

작업 하나가 끝났는지 한 번의 검수로 판정할 수 없다면 너무 큰 것입니다. 테스트 명령 하나, 빌드 하나, 화면 확인 하나처럼 완료 증거가 분명한 크기로 자르면 결과를 받았을 때 합칠지 돌려보낼지를 바로 정할 수 있습니다.

📏 한 작업은 얼마나 크게 자를까요?

작업이 너무 작으면 명세를 쓰고 결과를 합치는 비용이 일보다 커지고, 너무 크면 에이전트가 중간에 흐트러집니다.

큰 쪽의 한계는 공개된 측정으로 확인됩니다. 사람이 중앙값 1.6시간 걸리는 업무로 이뤄진 OSWorld 2.0에서는 163분을 넘는 과제를 끝까지 해낸 모델이 없었습니다. 앤트로픽도 긴 작업 하네스를 소개하며 에이전트가 한 번에 전부 만들려다 흐트러지는 실패를 들고, 한 번에 기능 하나만 다루게 한 방식이 결정적이었다고 적었습니다. 긴 작업이 끊기는 원리는 장기 과제와 컴퓨터 조작의 한계에 있습니다.

작은 쪽의 기준은 앤트로픽 리서치 시스템의 안내가 참고가 됩니다. 간단한 사실 확인은 에이전트 하나가 도구를 3번에서 10번 부르는 것으로 충분하고, 작업자를 10개 넘게 쓰는 것은 복잡한 조사에서만이라는 설명입니다. 정리하면 이렇게 자르는 편이 무난합니다.

🗺️ 설계 예시: 글 목록에 태그 필터 추가

가상의 예로 블로그 글 목록에 태그 필터를 붙이는 기능을 나눠 보겠습니다.

3과 4는 파일이 겹치지 않고 2에서 정한 약속만 공유하므로 병렬로 돕니다. 조사를 맡은 1단계 작업자에게는 파일을 고칠 권한을 주지 않습니다. 이 표의 각 줄이 그대로 작업 명세가 되며, 명세에 들어갈 항목은 작업 명세 쓰기에서 다룹니다.

💰 나눌수록 늘어나는 비용

나누면 시간은 줄어도 쓰는 양은 늘어납니다. 앤트로픽은 리서치 시스템에서 에이전트가 일반 채팅의 약 4배, 멀티 에이전트 구성이 약 15배의 토큰을 썼다고 밝혔고, 클로드 코드 문서는 에이전트 팀이 팀원들이 계획 단계에 있을 때 일반 세션의 약 7배까지 쓴다고 적었습니다. 구독으로 쓰는 경우에도 같은 계정으로 세션 세 개를 동시에 돌리면 사용량이 그만큼 빨리 줄어듭니다.

돈만이 아닙니다. 명세를 쓰는 시간, 결과를 기다렸다 합치는 시간, 충돌을 푸는 시간이 모두 메인의 몫입니다. 작업자를 늘리기 전에 나눠서 줄어드는 시간이 이 비용을 넘는지 따져 봅니다. 앤트로픽도 모든 에이전트가 같은 맥락을 공유해야 하거나 의존이 많은 일은 멀티 에이전트 구성에 맞지 않고, 코딩 작업은 대부분 조사보다 병렬로 나눌 부분이 적다고 설명합니다.

⚠️ 작업을 나눌 때 자주 하는 실수

• 기능 단위로만 나눕니다: 파일이 겹치는 두 기능을 동시에 맡기면 충돌이 납니다. 소유 파일을 먼저 적어 봅니다
• 메인이 구현에 빠집니다: 메인의 컨텍스트가 구현 세부로 차면 통합과 판단이 흐려집니다
• 숨은 의존을 놓칩니다: 파일은 달라도 함수 이름이나 데이터 형식을 공유하면 약속을 먼저 정합니다
• 처음부터 많이 띄웁니다: 둘로 나눠 합치는 과정이 매끄러운지 확인한 뒤에 늘리는 편이 낫습니다

❓ 자주 묻는 질문

작업자는 몇 개로 시작하는 것이 좋나요?

서로 겹치지 않게 나눌 수 있는 만큼만 만듭니다. 클로드 코드 문서는 에이전트 팀을 대부분 팀원 3명에서 5명으로 시작하라고 권합니다. 처음에는 둘로 나눠 결과를 합치는 과정을 한 번 돌려 보고, 병목이 명세 작성인지 통합인지 확인한 뒤 늘리는 편이 안전합니다.

메인은 사람이 맡는 편이 나은가요, 에이전트가 맡는 편이 나은가요?

쪼개기와 통합이 반복되는 정형 작업이라면 에이전트가 메인을 맡아도 됩니다. 요구가 모호하거나 되돌리기 어려운 결정이 섞인 작업이라면 사람이 메인을 맡고, 에이전트 메인을 쓰더라도 약속을 정하는 단계와 최종 통합 단계에는 사람이 확인하는 구간을 둡니다.

여러 도구의 에이전트를 섞어 써도 되나요?

됩니다. 오르카나 파세오 같은 도구는 클로드 코드와 코덱스를 한 화면에서 함께 돌리게 해 줍니다. 다만 도구마다 지침 파일과 권한 설정 방식이 달라서, 공통 규칙은 여러 도구가 함께 읽는 AGENTS.md 같은 파일 한곳에 두는 편이 설계를 단순하게 만듭니다.

📋 3줄 요약

1. 멀티 에이전트 작업 설계는 하나의 목표를 여러 코딩 에이전트에게 맡기기 전에 누가 어떤 파일을 소유하고 어떤 순서로 돌며 결과를 어떻게 합칠지를 정하는 일입니다.

2. 서로의 결과가 필요 없는 작업은 병렬로 나누고 결과가 필요한 작업은 순서대로 이으며, 한 작업은 완료 증거를 명령 하나로 확인할 수 있는 크기로 자릅니다.

3. 앤트로픽 리서치 시스템에서 멀티 에이전트 구성은 일반 채팅의 약 15배 토큰을 썼으므로 작업자를 늘리기 전에 나눠서 얻는 시간이 비용과 통합 시간을 넘는지 따집니다.

📚 참고 자료

• 앤트로픽, How we built our multi-agent research system: https://www.anthropic.com/engineering/multi-agent-research-system
• 앤트로픽, Building effective agents: https://www.anthropic.com/engineering/building-effective-agents
• 앤트로픽, Effective harnesses for long-running agents: https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents
• 클로드 코드 문서, Subagents: https://code.claude.com/docs/en/sub-agents
• 클로드 코드 문서, Agent teams: https://code.claude.com/docs/en/agent-teams
• XLANG Lab, OSWorld 2.0: https://osworld-v2.xlang.ai/