Claude Code에 프롬프트를 던집니다. 에이전트가 일할 때면 저는 기다리는 게 일이 됩니다. 기능 A가 끝나야 기능 B를 시킬 수 있으니까요. 내 손은 키보드 위에 있지만 다음 지시를 줄 타이밍만 재고 있고는 합니다. 성능 좋은 에이전트를 써도 작업 구조는 싱글 스레드이기 때문입니다. 이 똑똑한 에이전트를 써도 개발 프로세스는 여전히 대기열로 굴러가는 셈입니다.

그런데 현실의 개발은 원래 이렇게 안 굴러갑니다. 백엔드는 API를 만들고, 프론트엔드는 화면을 붙이고, 테스트는 케이스를 짜고, 문서는 사용법을 정리합니다. 이 일들은 서로 완전히 끝날 때까지 기다릴 필요가 없습니다. 오히려 동시에 움직일 때 속도가 나고 병목도 빨리 드러납니다. 그러니까, 개발은 원래 멀티플레이가 기본이죠.

그래서 필요한 게 에이전트를 여러 명 동시에 굴리게 해주는 관리자입니다. 이 역할을 하는 도구를 에이전트 오케스트레이터(Agent Orchestrator)라고 부릅니다. 어쩌면 앞으로는 에이전트가 코딩한다는 말보다 오케스트레이터가 팀을 굴린다는 말이 더 자주 나올지도 모릅니다. 그만큼 중요해질지도 모른다는 뜻입니다.

이 글에서는 오케스트레이터가 왜 필요한지부터 짚고, 어떤 문제를 해결해 주는지 정리해보려고 합니다. 그리고 코딩 에이전트를 여럿 동시에 쓰게 해주는 오케스트레이터 도구 3가지를 비교해 보겠습니다.

오케스트레이터가 ‘병렬 개발’하게 만드는 3가지 핵심 기능

막연히 코딩 에이전트를 여러 명 붙이면 속도가 빨라질 것 같나요? 현실은 다를 수도 있습니다. 무작정 같은 브랜치, 같은 폴더를 동시에 만지는 순간 충돌이 기하급수적으로 늘어나기 때문입니다. 게다가 미친듯이 쏟아내는 결과물을 사람이 판단할 수 없다면 꽝이기도 하니까요. 그래서 오케스트레이터는 이런 역할들을 해야 합니다.

격리(Isolation): 에이전트마다 코드 작업 공간 분리하기

병렬 개발의 기본은 격리입니다. 에이전트별로 별도 환경을 만들어, 각자 독립 작업 공간에서만 일하게 해야 합니다. Git 워크트리를 가를 수도 있고, 폴더를 다르게 배정할 수도 있습니다. 쉽게 말해 서로의 코드를 건드리지 않게 환경부터 갈라주는 겁니다. 그래야 한 에이전트의 수정이 다른 에이전트의 작업을 망치지 않습니다.

비유로 보면 더 단순합니다. 한 주방에서 요리사 5명이 칼 하나로 요리하면 속도는커녕 사고만 나고 난리가 나겠죠. 그래서 오케스트레이터는 애초에 도마, 칼, 재료를 각자 세팅해 주는 역할부터 합니다. 작업 공간을 분리해 주면, 그제야 진짜 병렬이 됩니다.

가시성(Visibility): 지금, 누가, 뭘 하는지 보여주기

에이전트가 늘어날수록 더 무서운 건 충돌보다 깜깜함입니다. 지금 누가 뭘 하는지, 어디서 막혔는지 안 보이면 사람이 통제할 수 없습니다. 그래서 좋은 오케스트레이터의 기준은 가시성입니다. 한눈에 에이전트별 상태를 보여줘야 합니다.

예를 들면 이런 식입니다. 어떤 에이전트는 작업 중이고, 어떤 에이전트는 대기 중이며, 어떤 에이전트는 에러로 멈춰 있습니다. 또 어떤 결과물은 리뷰를 기다리고 있을 수 있죠. 원래 개발팀이라면 손이라도 들거나 메시지라도 보낼 텐데, 에이전트는 그것마저 시키지 않으면 잘 못합니다. 결국 지금 상황을 한 번에 파악하게 해주는 게 핵심입니다.

리뷰와 머지(Review & Merge): 작성자에서 통합자로 이동하기

이렇게 오케스트레이터가 잘 돌아가면 사람의 역할이 바뀝니다. 코드를 직접 치는 시간보다, 변경점 확인에 더 많은 시간을 쓰게 됩니다. 방향이 틀어지면 코멘트로 수정하고 충돌을 정리해 머지합니다. 마지막엔 “지금 릴리스해도 되는가”를 판단하겠죠.

그래서 오케스트레이터를 단순히 "에이전트 추가 버튼" 정도로 여겨서는 안 됩니다. 엄밀히 말하면 이는 개인에게 개발 팀 리드 수준의 역할을 부여하는 도구에 가깝습니다. 여러 에이전트가 만든 결과물을 모아 한 제품으로 만드는 책임이 생기니까요. 병렬 개발의 끝은 결국, 리뷰와 통합의 품질에서 갈립니다.

그럼 이제 본격적으로 이러한 일을 해주는 도구 3가지를 알아보겠습니다. 지금은 초기 단계인 만큼 각자 특성이 뚜렷하게 드러나는 편입니다. 게다가 지금 막 새로 등장한 영역인 만큼 모두가 깃헙 레포 수준으로 존재하기도 합니다. 그러니 오케스트레이터들이 어떤 방향으로 나아가고 있는지, 바라본다는 관점에서 살펴봐도 좋겠습니다.

Conductor: GUI 대시보드로 여러 에이전트를 지휘하기

Conductor는 여러 코딩 에이전트를 한 화면에서 지휘하게 해주는 도구입니다. Claude Code나 Codex를 병렬로 띄워 두고, 각 에이전트가 지금 뭘 하는지 GUI에서 확인하며 조율합니다. 터미널 창을 여러 개 띄워 감으로 관리하던 일을 관제탑 화면으로 바꿔주는 방식입니다.

이 도구를 쓰면 뭐가 어떻게 편해질까?

오케스트레이터의 핵심은 결국 여럿을 동시에 굴리는 것이죠. Conductor는 그중에서도 가시성(대시보드)에 강점이 있습니다. 누가 어떤 작업을 맡았고, 어디서 멈췄는지 한눈에 보이면 자연스럽게 다음 지시가 빨라질 겁니다. 결과적으로 사람은 코드를 치기보다 흐름을 점검하고 우선순위를 바꾸는 쪽에 더 가까워집니다.

좋은 점은 기존 Claude Code 로그인 방식을 그대로 쓴다는 겁니다. API 키를 쓰든, Pro/Max 같은 구독을 쓰든, 익숙한 인증 흐름 위에서 돌아갑니다. 새로 계정을 파거나 별도의 복잡한 연결을 요구하지 않는 쪽에 가깝습니다.

설정도 “설치 → 바로 병렬 실행”에 가깝습니다. 처음부터 스크립트를 짜거나, tmux 세션을 설계하지 않아도 됩니다. 그래서 병렬화를 ‘한 번이라도’ 해보고 싶은 사람에게 진입 장벽이 낮습니다.

누가, 언제 쓰면 좋은가

이런 특징으로 Conductor는 터미널이나 스크립트보다, 작업을 시각적으로 관리하고 싶은 개발자에게 잘 맞습니다. 특히 “지금 뭐가 돌아가고 있지?”를 계속 확인해야 하는 상황에서요. 화면이 곧 상태판이 되니 머릿속으로 컨텍스트를 붙잡는 부담이 줄어듭니다.

예를 들어 백엔드, 프론트, 테스트처럼 서로 다른 일을 동시에 굴릴 때가 그렇습니다. 각각의 진행 상황을 ‘눈으로’ 확인하며, 막힌 곳부터 풀어주고 작업을 재배치할 수 있습니다. 인간 세상에서 Jira와 Notion으로 갖은 고생을 하며 확인하는 이유, 누가 어디까지 했지?가 덜해집니다.

만능은 아닌 Conductor의 단점

물론 만능은 아닙니다. 첫 번째 제약은 macOS 전용이라는 점입니다. 팀이 Windows나 Linux를 섞어 쓰면 도입 자체가 어려울 수 있습니다. 개인은 괜찮아도, 팀 단위 표준 도구로 삼기엔 환경 장벽이 생깁니다.

두 번째는 비용 곱셈입니다. 에이전트를 늘리면 그만큼 API 사용도 늘어납니다. 더 무서운 건, 대시보드가 편할수록 병렬 작업을 과하게 켤 유혹이 커진다는 점입니다. 별 생각없이 딸깍딸깍 켜다보면 비용이 새는 습관으로 옮겨가기 쉽습니다.

정리하면 Conductor는 병렬화를 가장 쉽게 시작하는 버튼에 가깝습니다. 대신 플랫폼과 비용이라는 현실적인 제약을 감수해야 합니다. 내 작업이 정말 병렬에 어울리는지, 그리고 그 병렬이 얼마짜리인지부터 같이 계산해보는 게 안전합니다.

Claude Squad: tmux 기반으로 터미널에서 ‘멀티플렉싱’하기

Claude Squad는 tmux 위에서 여러 개의 Claude Code를 동시에 띄웁니다. 쉽게 말해, 한 터미널 화면을 여러 칸으로 쪼개고 각 칸에 에이전트를 한 명씩 앉히는 방식입니다. 그래서 백엔드 작업을 시키는 동안 옆 칸에서는 프론트엔드 수정도 같이 굴릴 수 있습니다.

이 도구를 쓰면 뭐가 어떻게 편해질까?

오케스트레이터가 보통 해결하는 건 격리·가시성·리뷰/머지 세 가지라고 했습니다. Claude Squad는 그중에서도 특히 운영의 단순함에 무게가 실려 있습니다. 별도 서버나 복잡한 UI를 올리기보다 tmux라는 이미 익숙한 도구 위에 얹는 쪽을 택했기 때문입니다. 대신 한눈에 보는 가시성 측면에서는 대시보드 대신 사용자가 터미널 화면을 관찰하며 확보하는 방식을 택했습니다.

Claude Squad에는 GUI 대시보드가 없습니다. 그런데 터미널이 익숙한 개발자라면, 이게 오히려 장점이 될 수 있습니다. 마우스로 창을 찾고 클릭하는 대신 키보드로 패널을 휙휙 넘기며 컨텍스트 스위칭(작업 맥락 전환)을 빠르게 할 수 있기 때문입니다. 관리 화면을 배우는 비용이 거의 없다는 뜻이기도 합니다.

따지자면 Claude Squad는 큰 화면 한 장 대신 여러 개의 무전 채널을 동시에 듣는 쪽에 가깝습니다. 각 에이전트의 대화와 로그가 패널마다 흘러가고, 나는 필요한 채널로 바로 들어가서 지시를 바꿉니다. 상황판은 없지만 대신 손이 빠르면 운영이 빨라집니다.

지원 환경도 실용적입니다. Mac·Linux를 지원하니 팀 내 개발 환경이 섞여 있어도 도입 장벽이 낮습니다. 게다가 오픈소스 무료라서 일단 몇 명만 써보자 같은 실험에 부담이 적습니다. 에이전트를 늘려보는 단계에서 도구 비용이 발목을 잡지 않는다는 점이 큽니다.

만능은 아닌 Claude Squad의 단점

대신 단점도 분명합니다. 상태를 한눈에 보는 대시보드가 없기 때문에 에이전트가 늘어날수록 사람의 관리 능력이 성능을 좌우합니다. 누가 무엇을 하고 있는지, 어디서 막혔는지, 지금 개입해야 하는지 등을 사용자가 직접 정리해야 합니다. 팀이 커지거나 에이전트 수가 많아지면 이 부담은 생각보다 빨리 커집니다.

또 하나는 리뷰/머지 흐름입니다. 여러 에이전트가 동시에 코드를 만들면, 결국 사람은 합치기 전에 검토하고 충돌을 정리해야 합니다. Claude Squad가 이 과정을 자동으로 매끈하게 이어준다고 기대하면 곤란합니다. 필요하다면 별도의 도구나 팀 규율로 리뷰와 머지의 리듬을 따로 설계해야 합니다.

Agent Orchestrator: 에이전트를 로컬이 아니라 ‘CI/CD 프로세스’에 붙이기

Agent Orchestrator는 에이전트를 내 로컬에서 부리는 도구에서 꺼내 CI/CD 프로세스에 붙입니다. 사람이 시키기 전에 무언가 일을 해야 할 ‘사건’이 먼저 에이전트를 부르는 구조입니다. 그래서 자동화가 필요한 팀일수록 체감이 크게 옵니다.

이 도구는 외부 서비스를 AI 에이전트에 붙여주는 Composio를 만든 ComposioHQ에서 공개한 오픈소스 레포지토리입니다. Composio 서비스 전체를 사지 않아도 쓸 수 있으니 걱정 마세요.

이 도구를 쓰면 뭐가 어떻게 편해질까?

이 오케스트레이터를 쓴 다음, CI가 실패하면 에이전트가 먼저 로그를 읽고 원인을 찾습니다. 그리고 수정안을 만들어 PR에 반영하거나 다음 실행을 위한 커밋을 준비합니다. 사람은 왜 깨졌나 확인하는 일부터 시작하지 않아도 됩니다.

한편 리뷰어가 코멘트를 남기면, 그 코멘트가 다시 에이전트를 호출하기도 합니다. 에이전트는 지적받은 부분을 고치고, 변경 이유를 설명하는 식으로 반영합니다. 리뷰가 대화로 끝나는 대신 수정으로 이어지기 쉬워집니다. 정리하면, 사람이 에이전트에게 시키는 구조에서 이벤트가 에이전트를 호출하는 구조로 이동시켜주는 도구입니다. CI 실패, 리뷰 코멘트 같은 신호가 트리거가 됩니다. 오케스트레이터의 역할이 더 강해지는 지점이죠.

Agent Orchestrator는 YAML 양식으로 개발 자동화 흐름을 정의합니다. 그러니까 버튼을 눌러 설정하는 대신 “이런 일이 생기면 이렇게 해”를 글로 적어두는 방식입니다. 선언적으로 적어두면 팀이 커져도 흐름이 덜 흔들립니다.

지원하는 에이전트 폭도 넓습니다. Claude Code만이 아니라 Codex, Aider까지 연결해 쓸 수 있습니다. 팀이 이미 쓰는 에이전트가 제각각이어도 한 흐름으로 묶기 좋습니다.

누가, 언제 쓰면 좋은가

테스트/린트/빌드/리뷰가 어느 정도 표준화된 팀에 잘 맞습니다. 반복 작업이 많고, 깨지면 고치고 다시 돌리는 루틴이 잦을수록 효과가 큽니다. 이런 코드 수정의 자동화는 결국 반복이 많을 때 가장 빨리 이득이 납니다.

특히 “실패 처리”가 많은 프로젝트에서 빛을 봅니다. 예를 들어 레거시, 의존성 지옥, flaky test처럼 자주 흔들리는 환경입니다. 이런 곳은 사람의 집중력이 먼저 닳기 때문입니다.

만능은 아닌 Agent Orchestrator의 단점

물론 당연히 모든 일을 처리해 주지는 않겠죠. CI/CD에 자동으로 개입한다는 건 범위가 넓은 일입니다. 그만큼 당연히 초기 설정이 복잡해질 수 있습니다. 처음에 흐름을 잘못 잡으면, 자동화가 오히려 혼란을 키울 거고요. 그래서 도입 초반에는 작은 범위부터 시작하는 편이 안전합니다.

또 프로덕션/조직 환경에서는 권한 관리가 더 중요합니다. 에이전트가 무엇을 어디까지 수정할 수 있는지를 명확히 해야 합니다. 접근 범위를 넓게 주는 순간, 잠시 편의성이 생길지 몰라도 리스크가 무지막지하게 커집니다.

물론 오케스트레이터를 무조건 써야 하는 건 아닙니다

오케스트레이터 도입의 ROI는 결국 “도구가 좋아서”가 아닙니다. 내가 하는 일 중에서 병렬로 쪼개도 되는 일의 비율이 얼마나 되느냐에 달려 있습니다. 동시에 돌려야 하는 덩어리가 많으면 Conductor나 Claude squad가 빛을 봅니다. 반면 쪼갤 게 적으면 오케스트레이터를 도입하는 체감이 없습니다. 오히려 비용과 운영 복잡도만 늘 수 있죠.

병렬화는 공짜가 아니다

많이들 오케스트레이터나 코딩 에이전트의 하네스를 얹어주는 도구를 볼때, 그 도구 자체의 가격부터 봅니다. 그런데 실제로 더 크게 튀는 건 코딩 에이전트 그 자체의 사용 가격입니다. 에이전트가 늘수록 호출이 곱셈으로 늘어나기 때문입니다. 도구 비용이 아니라 돌리는 만큼 나가는 비용이 핵심입니다.

중간 규모 기능 하나만 잡아도 수동 대비 호출이 한참 더 나올 수도 있습니다. 사람이 한 번에 끝낼 흐름을 에이전트는 더 잘게 쪼개 확인할 수 있으니까요. 그 과정에서 요청과 응답도 계속 쌓입니다. 에이전트를 5개 돌리면, 비용도 사실상 확실히 커진다는 뜻입니다.

물론 항상 정확히 5배는 아닙니다. 하지만 아무리 정해진 Max 요금제를 써도 토큰이 선형으로 증가한다는 감각이 오를지도 모릅니다. 병렬화는 속도를 사는 대신 호출을 더 사는 구조입니다.

왜 호출이 늘어나며 머리가 아파오는가

사람 1명이 하던 생각과 탐색 과정을 떠올려 보겠습니다. 코드를 읽고, 가설을 세우고, 한 번 고치고, 다시 확인하죠. 병렬화에서는 이 과정이 에이전트마다 각자 반복됩니다. 즉, 한 사람이 한 번 하던 루프가 여러 번 돌아갑니다.

게다가 에이전트는 보통 격리된 작업 공간에서 일합니다. 그러면 각자 빌드하고, 각자 테스트하고, 각자 컨텍스트를 다시 확인합니다. 같은 저장소라도, 서로 다른 방에서 따로 작업하는 셈입니다. 이게 안정성을 주는 대신, 호출과 로그를 폭증시킵니다.

한편, 이를 다루는 사람의 입장도 생각해야 합니다. 이렇게 복잡한 사고 흐름을 모두 따라가는 건 당연히 매우 어렵습니다. 더 많은 일을 시키지 못하는 것보다 두려운 건 어느 순간 그 일을 따라잡지 못하는 겁니다.

비용을 통제하는 운영 팁

첫 번째는 모델 분배입니다. 이를테면 복잡한 추론은 Opus에 맡기고, 단순 수정은 Sonnet/Haiku로 내립니다. 쉽게 말해 어려운 일은 비싼 사람, 쉬운 일은 저렴한 사람한테 부탁하는 거죠. 이 한 가지만 해도 비용 곡선이 달라집니다. 꼭 오케스트레이터가 아니어도 비슷할 겁니다.

두 번째는 무조건 병렬을 버리는 겁니다. 병렬화 가치가 큰 작업부터 쪼개야 합니다. 예를 들어 아래처럼 경계가 명확한 것부터 나누는 식입니다.

프론트 UI 작업
백엔드 API 작업
테스트 작성 작업

이렇게 나누면 오케스트레이터의 장점이 바로 나옵니다. 서로 코드가 덜 부딪히고 합치는 과정도 단순해집니다. 반대로 경계가 흐린 작업을 억지로 병렬화하면 호출만 늘고 머지만 어려워집니다. 물론 이를 명확하게 설계하고 분배하는, 소위 말해 "기획" 단의 일이 더 중요해 지겠죠.

마치며

오케스트레이터를 단순 ”에이전트를 한 명 더 고용하는 도구”로 보면, 기대가 자주 어긋납니다. 핵심은 에이전트 수를 늘리는 게 아니라 여럿이 만든 결과물을 충돌 없이 통합하는 데 있습니다. 다섯 명이 동시에 코드를 만지면 생산성보다 먼저 “누가 뭘 했지?”와 “어디서 꼬였지?”가 문제로 떠오르거든요. 오케스트레이터는 그 혼선을 줄여서 사람이 마지막에 깔끔하게 합칠 수 있게 돕습니다.

그런 관점에서 가시성이 필요하면 Conductor가 잘 맞습니다. 화면에서 에이전트들이 뭘 하고 있는지, 어디서 막혔는지 흐름을 잡기 쉽습니다. 터미널 중심으로 일한다면 Claude Squad가 더 자연스럽습니다. GUI 대신 터미널에서 여러 Claude Code 세션을 병렬로 다루는 방식이라 손이 덜 바뀝니다. 한편 CI까지 묶어 PoC를 잡고 싶다면 Agent Orchestrator로 시작하는 편이 낫습니다. 단순히 에이전트를 띄우는 걸 넘어 자동화 흐름 자체를 붙일 수 있기 때문입니다.

그 무엇이든 오케스트레이터의 진가는 여러 기능을 동시에 개발할 때, 대규모 리팩토링처럼 할 일이 산더미인 경우에 좋습니다. 바꾸어야 할 파일이 많고, 작업 단위가 반복적일수록 병렬화 이득이 커집니다. 이때 오케스트레이터는 속도를 올리는 도구라기보다, 합치는 비용을 통제하는 도구가 되니까요.

다시 한 번 돌이켜 보지만, 결국 중요한 건 에이전트 숫자가 아니라 통합할 수 있는 작업의 구조를 먼저 만드는 일입니다.