단일 에이전트에서 멀티 에이전트로: 실전 마이그레이션 가이드

오늘날 AI 코딩 도구를 쓰는 대부분의 개발자는 한 번에 하나의 에이전트만 돌립니다. Claude Code를 열고, 작업을 주고, 끝날 때까지 기다린 뒤, 다음 작업을 줍니다. 잘 동작합니다. 하지만 순차적입니다.

두 개의 에이전트를 병렬로 돌리는 순간, 무언가 바뀝니다. 당신은 출력만 기다리는 타이피스트가 아니라, 작업을 배분하고 결과를 라우팅하고, 중요한 곳에 주의를 두는 오케스트레이터가 됩니다.

이 글은 단일 에이전트에서 멀티 에이전트 개발로 넘어가는 실질적인 단계를 설명하고, 그에 따라 필요한 사고방식의 변화를 다룹니다.

단일 에이전트의 병목

어떤 에이전트가 아무리 강력해도, 한 번에 하나의 일만 할 수 있다는 근본적인 제약은 같습니다. Claude Code가 인증 모듈을 리팩터링하는 동안 API 계층의 테스트를 동시에 작성할 수는 없습니다. 당신은 기다립니다.

수학은 단순합니다. 각 작업이 에이전트 작업 시간 5분이 걸리고 10개의 작업이 있다면, 단일 에이전트는 50분이 걸립니다. 두 에이전트면 25분입니다. 하지만 진짜 이득은 단순한 총 소요 시간이 아니라 피드백 루프입니다.

관련된 코드에서 두 에이전트가 함께 작업하면, Agent A의 리팩터링 결과를 즉시 Agent B의 리뷰에 넣을 수 있습니다. 문제는 더 빨리 드러나고, 문맥은 더 신선하며, 통합 문제를 몇 시간 대신 몇 분 만에 잡아냅니다.

1단계: 병렬화 가능한 작업 찾기

모든 작업이 병렬화의 이득을 보는 것은 아닙니다. 좋은 후보는 다음과 같습니다.

• 독립 모듈 - 인증을 리팩터링하면서 새 API 엔드포인트를 빌드
• 순차 단계 - 한 에이전트가 코드를 쓰고, 다른 에이전트가 리뷰
• 보완적 관점 - 한 에이전트는 구현에 집중하고, 다른 에이전트는 테스트에 집중

반대로, 서로 강하게 결합된 작업은 좋지 않습니다. 두 에이전트가 같은 파일을 편집하면 병합 충돌이 생깁니다.

간단한 규칙은 이렇습니다. 두 명의 다른 개발자에게 나눠 맡길 수 있는 일이라면, 두 개의 다른 에이전트로도 돌릴 수 있습니다.

2단계: 공간적 구성

탭 기반 워크플로는 여러 에이전트를 다루기 시작하면 한계가 옵니다. 세 개의 터미널 탭을 동시에 스캔할 수는 없습니다. 겹치고, 문맥을 잃고, 어떤 탭이 무엇을 하는지 잊어버립니다.

이때 공간 배치가 중요해집니다. 캔버스에서는 에이전트를 눈에 보이는 곳에 두면 됩니다. 왼쪽에 Terminal A, 오른쪽에 Terminal B, 가운데에는 계획을 추적하는 노트 타일을 둡니다. 한눈에 모든 상태를 알 수 있습니다.

공간 모델은 단지 보기 좋기 때문이 아닙니다. 인지적입니다. 외적 인지 연구에 따르면 정보의 공간적 배열은 작업 기억 부담을 줄여줍니다. 캔버스는 당신의 ذهن적 모델을 화면 위로 확장한 것입니다.

3단계: 정보 흐름 정의

여러 에이전트가 있으면 정보가 어떻게 이동하는지 계획이 필요합니다. 흔한 패턴은 세 가지입니다.

파이프라인

Agent A → Agent B → Agent C

각 에이전트의 출력이 다음 에이전트의 입력이 됩니다. 예: A가 코드를 쓰고 → B가 리뷰하고 → C가 테스트를 작성.

Fan-out / Fan-in

        → Agent B →
Agent A                 Agent D
        → Agent C →

한 에이전트가 작업을 분배하고, 여러 에이전트가 병렬로 실행되며, 결과가 다시 합쳐집니다. 예: A가 작업을 하위 작업으로 나누고 → B와 C가 각각 처리 → D가 결과를 통합.

리뷰 루프

Agent A ⇄ Agent B

두 에이전트가 같은 작업을 반복 개선합니다. A가 쓰고, B가 리뷰하고, A가 수정합니다. 생각보다 빠르게 수렴합니다. 보통 2-3라운드면 충분합니다.

4단계: 핸드오프 자동화

멀티 에이전트 작업에서 가장 큰 마찰은 핸드오프입니다. Agent A의 출력을 복사하고, 프롬프트로 다시 써서, Agent B에 붙여 넣는 일은 번거롭고 실수도 많습니다.

자동 라우팅은 이 마찰을 없앱니다. Agent A가 끝나면 시스템이:

1. 완료를 감지합니다(출력 패턴 또는 유휴 감지).
2. 필요한 출력을 추출합니다.
3. Agent B에 맞는 프롬프트로 변환합니다.
4. 전달합니다.

변환 단계가 중요합니다. 터미널 원시 출력은 ANSI 코드, 진행 바, 장황한 로그 때문에 지저분합니다. 좋은 라우팅 시스템은 의미를 추출해 실행 가능한 지시로 바꿉니다.

5단계: 모니터링하고 개입하기

멀티 에이전트 작업은 다른 주의 패턴을 요구합니다. 한 에이전트의 출력을 깊게 보는 대신, 여러 에이전트를 훑으며 다음을 찾게 됩니다.

• 막힌 에이전트 - 권한이나 입력을 기다리는 중
• 완료된 에이전트 - 다음 작업이나 전달을 기다리는 중
• 엇나간 에이전트 - 잘못된 방향으로 가는 중

시각적 표시가 큰 도움이 됩니다. 작업 중, 대기 중, 중지 같은 색상 상태 표시만 봐도 주의를 분배할 수 있습니다. 펄스 애니메이션은 활성 에이전트에 시선을 끌고, 화면 가장자리의 글로우는 캔버스 밖 활동을 알려줍니다.

목표는 모니터링의 인지적 부담을 줄여, 무엇을 만들지, 어떻게 설계할지, 어디에 주의를 투자할지 같은 창의적 결정을 더 잘 내릴 수 있게 하는 것입니다.

사고방식의 변화

멀티 에이전트 작업에서 가장 깊은 변화는 기술이 아닙니다. 당신의 역할을 어떻게 생각하느냐입니다.

단일 에이전트에서는 당신이 페어 프로그래머입니다. 당신과 에이전트가 하나의 일에 집중합니다.

여러 에이전트에서는 당신이 테크 리드입니다. 방향을 정하고, 작업을 배분하고, 결과를 리뷰하고, 아키텍처 결정을 내립니다. 실행은 에이전트가 맡습니다.

처음에는 이 변화가 낯설 수 있습니다. 각 에이전트의 출력을 한 줄씩 다 보고 싶어집니다. 하지만 그렇게 해서는 확장되지 않습니다. 대신 과정을 신뢰하고, 필요할 때만 개입하고, 실제로 당신의 판단이 필요한 결정에 집중하게 됩니다.

시작하기

지금 단일 에이전트를 쓰고 있다면 이렇게 해보세요.

1. 같은 에이전트를 두 번째 터미널에서 다른 작업으로 실행합니다.
2. 두 창이 모두 보이도록 나란히 배치합니다.
3. 첫 번째가 끝나면 핵심 결과를 두 번째에 수동으로 보냅니다.
4. 그 문맥 덕분에 두 번째 작업이 얼마나 빨라지는지 느껴보세요.

이것이 멀티 에이전트 개발의 가장 단순한 형태입니다. 자동 라우팅, 캔버스 구성, 상태 감지는 이 기본 패턴을 거의 무의식적으로 만들기 위한 인프라입니다.