멀티 에이전트 AI는 준비되었습니다. 당신의 워크플로우 인프라는 아닙니다.

AI Learn Today 미니캐스트의 Datopian 창립자 Rufus Pollock과 CTO Anuar Ustayev 간의 대화입니다.

공지: 저희는 오픈 데이터 인프라를 구축하는 Datopian에서 근무하고 있습니다. 이 포스트는 실제 운영 환경에서 멀티 에이전트 (Multi-agent) AI 워크플로우를 사용한 저희의 경험을 바탕으로 작성되었습니다.

두 달 전, Datopian의 CTO인 Anuar Ustayev는 여러 AI 코딩 에이전트를 오케스트레이션 (Orchestrating)하기 위한 주요 도구로 Gastown을 채택했습니다. 이는 그의 작업 방식을 바꾸어 놓았습니다. 하지만 오늘날 그가 처음부터 다시 시작한다면, 그것을 선택하지 않을 수도 있습니다.

이는 Gastown에 대한 비판이 아닙니다. 도구 환경이 얼마나 빠르게 변화하고 있는지, 그리고 멀티 에이전트 AI 워크플로우를 둘러싼 인프라가 여전히 얼마나 미성숙한지를 보여주는 신호입니다.

이 포스트는 실제 멀티 에이전트 AI 개발이 어떤 모습인지에 대한 두 차례의 솔직한 대화를 요약한 것입니다. 즉, 워크플로우의 변화, 해결되지 않은 문제들, 그리고 대부분의 AI 콘텐츠가 회피하는 질문들에 대한 정직한 답변을 담고 있습니다.

병목 현상의 이동

1년 전, 소프트웨어 개발의 제약 사항은 실행 능력 (Execution capacity)이었습니다. 구현할 작업은 많은데 이를 실행할 시간이 부족했습니다. AI 코딩 어시스턴트 (AI coding assistants)는 자동 완성 (Autocomplete), 보일러플레이트 (Boilerplate), 빠른 수정 (Quick fixes) 등 주변적인 부분에서 도움을 주었습니다.

그 제약 사항은 사라졌습니다.

"이전에는 해야 할 작업은 많은데 이를 구현할 시간을 찾는 것이 문제였습니다. 이제 병목 현상은 단순히 작업을 생성하고 정의하는 단계에 있습니다. 아이디어는 있을 수 있지만, 이를 명세화 (Spec out)해야 하기 때문입니다."
— Anuar Ustayev

Claude Code, Codex, 그리고 Gastown과 같은 오케스트레이션 레이어 (Orchestration layers)를 통해, 이제 단 한 명의 개발자가 여러 에이전트를 병렬로 실행하여 각각 별도의 작업을 동시에 수행할 수 있습니다. 구현 레이어 (Implementation layer)는 상당 부분 범용화 (Commoditised)되었습니다.

새로운 제약 사항은 상류(Upstream)에 있습니다: 바로 작업 정의(Work definition)입니다. AI 에이전트가 올바른 것을 구현할 수 있을 만큼 명확하고 완전한 사양(Specification)을 작성할 수 있습니까?

이것은 사소한 조정이 아닙니다. 숙련된 인간의 노력이 어디로 향해야 하는지에 대한 근본적인 재구조화입니다.

Gastown이 실제로 하는 일

Gastown은 단일 터미널 인터페이스에서 여러 AI 에이전트를 오케스트레이션(Orchestrating)하기 위한 오픈 소스 도구입니다. 주요 개념은 다음과 같습니다:

Rigs — 각각 고유한 디렉토리, 컨텍스트(Context), 에이전트를 가진 프로젝트 워크스페이스(Workspaces)입니다. 수십 개를 동시에 실행할 수 있습니다.

The Mayor agent — 모든 Rigs를 관리하는 중앙 오케스트레이터(Orchestrator)입니다. 자연어를 통해 상호작용합니다: "프로젝트 X의 상태는 어때? 백로그(Backlog)의 다음 항목을 처리하도록 에이전트를 파견해줘."

Bits — 각 프로젝트 내부의 로컬 데이터베이스로 존재하는 AI 네이티브 이슈 트래커(Issue tracker)입니다. GitHub Issues나 Linear와 달리, Bits는 AI 에이전트가 직접 읽고 쓸 수 있도록 설계되었습니다.

Anuar가 몇 달 후 보고한 시간 배분은 다음과 같습니다: 80%는 계획 및 감독, 20%는 디버깅(Debugging). 그는 오랫동안 직접 코드를 작성하지 않았습니다.

설정: Subagents를 활용한 Claude Code

Gastown은 2025년 초 출시되었을 당시 진정으로 혁신적이었습니다. 그 이후 주요 AI 플랫폼들이 이를 따라잡았습니다. 이제 Claude Code는 서브에이전트(Subagent) 워크플로우를 기본적으로 지원합니다. Codex Desktop 또한 유사한 기능을 갖추고 있습니다.

오늘 시작하는 사람을 위한 Anuar의 현재 권장 사항은 다음과 같습니다:

실질적인 워크플로우:

사양(Spec) 작성을 지원받기 위해 Superwhisper 또는 유사한 도구로 계획 세션 시작
계획 모드(Plan mode)를 사용하여 거친 아이디어로부터 구조화된 사양(Spec) 생성
사양을 개별 작업(Bits, GitHub Issues 또는 로컬 마크다운)으로 분할
작업을 병렬로 실행하도록 에이전트 파견
검토, 병합(Merge), 반복

사양 품질 문제 (The Spec Quality Problem)

멀티 에이전트 AI의 약속은 매력적입니다. 작업을 한 번 정의하면, 에이전트들이 병렬로 실행하고, 결과물을 검토하기만 하면 됩니다. 하지만 실제로 에이전트가 생성하는 결과물의 품질은 입력된 사양(Spec)의 품질에 매우 민감하게 반응합니다.

"UI 문제나 다른 문제들을 다룰 때, AI가 해결할 수 있도록 명확한 사양을 만드는 과정이 상당히 고통스럽다는 것을 느낍니다. 지금은 인간 개발자라면 스크린샷을 보고 30초 만에 이해할 내용을, AI에게 사양으로 전달하기 위해 20분을 소비하곤 합니다."
— Rufus Pollock

현재 가장 좋은 접근 방식들은 다음과 같습니다:

대화형 사양 정교화 (Interactive spec refinement) — Superwhisper나 Claude의 플랜 모드(plan mode)와 같은 도구들은 구현이 시작되기 전에 후속 질문을 던지고 사양에 대한 결정을 강제합니다.

스크린샷-사양 변환 (Screenshot-to-spec) — UI 문제의 경우, 스크린샷을 찍고 문제를 한 문장으로 설명하면 AI가 요구사항 문서(Requirements document)를 생성하도록 합니다.

반복적 형상화 (Iterative shaping) — Basecamp의 Shape Up 방법론에서 차용했습니다: 거친 아이디어 → 형상화된 사양(Shaped spec) → 빌드 준비 완료. 작업이 형상화(Shaped)되기 전까지는 에이전트에게 작업을 넘기지 마세요.

⚠️ 불편한 진실: 대부분의 개발자는 형상화(Shaping) 단계가 오버헤드(Overhead)처럼 느껴지기 때문에 이를 건너뜁니다. AI 에이전트를 사용할 때 이를 건너뛰는 것은 비용이 많이 듭니다. 잘못 정의된 작업은 완료된 것처럼 보이지만 실제로는 완료되지 않은 결과물을 만들어내며, 이를 다시 풀어내는 데는 처음부터 다시 시작하는 것보다 더 많은 비용이 듭니다.

아무도 해결하지 않고 있는 파편화 문제 (The Fragmentation Problem Nobody Is Solving)

AI의 도움을 받는 현실적인 업무 일과는 다음과 같습니다: 휴대폰의 ChatGPT에서 리서치 스레드(Research thread)를 진행합니다. 노트북의 Claude에서 작업을 이어갑니다. 구현을 위해 Codex Desktop을 실행합니다. Claude의 사용량 제한(Rate-limited)에 걸리면 Gemini에 빠르게 질문을 던집니다.

각 세션은 고립된 상태로 존재합니다. 통합된 히스토리가 없습니다. 세션 간의 검색도 불가능합니다.

"내가 했던 모든 채팅 세션이 내가 검색할 수 있는 어딘가에 아카이브(Archive)되기를 바랍니다. 하지만 내 업무를 방해해서는 안 됩니다. 좋은 이슈 트래커(Issue tracker)가 과거 기록을 가지고 있으면서도 현재 작업에 집중할 수 있게 해주는 방식처럼 말이죠."
— Rufus Pollock

현재의 임시방편들:

하나의 도구에 집중하기 (Stick to one tool) — 단일 도구의 일관성을 유지하는 규율은 도구 전환(tool-switching)의 미미한 기능들보다 더 가치 있습니다.
체크포인트 문서 (Checkpoint documents) — 결정 사항, 막다른 길, 그리고 현재 상태를 기록하는 마크다운 (markdown) 파일입니다. 도구와 세션 간에 이동이 가능합니다.
로컬 우선 저장 (Local-first storage) — Bits의 로컬 데이터베이스 모델이 올바른 아키텍처입니다. 데이터의 진실의 원천 (source of truth)은 벤더의 SaaS 내부가 아닌 사용자의 디스크에 있어야 합니다.

Claude, ChatGPT, Codex, 그리고 Gemini 전반에 걸쳐 통합되고, 검색 가능하며, AI 세션을 인식하는 지식 계층 (knowledge layer)을 구축하는 도구가 진정으로 가치 있을 것입니다. 하지만 그러한 도구는 아직 존재하지 않습니다.

토큰 비용의 현실 (The Token Cost Reality)

멀티 에이전트 (Multi-agent) 워크플로우는 토큰을 많이 소모합니다. Anuar는 Claude, OpenAI, Gemini 구독을 동시에 사용하며, 세 서비스 모두에서 정기적으로 속도 제한 (rate limits)에 걸립니다.

완화 전략:

작업에 적합한 모델 라우팅 (Task-appropriate model routing) — 기계적인 작업에는 더 저렴한 모델 (Claude Haiku, GPT-4o Mini, Gemini Flash)을 사용하세요. 추론 집약적인 작업(reasoning-intensive work)을 위해 비싼 모델을 아껴두어야 합니다.

로컬 호스팅 모델 (Locally hosted models) — Ollama 또는 Cloudflare Workers AI를 통해 Llama 4, Mistral을 거의 제로에 가까운 한계 비용으로 사용하세요.

배치 처리 (Batching) — 긴급하지 않은 작업에 대한 백그라운드 에이전트는 의도적으로 속도 제한을 걸어 토큰 소비를 시간적으로 분산시킬 수 있습니다.

이것이 실무에서 의미하는 바

구현 중심의 작업에서 명세 및 감독 (spec-and-supervise) 중심의 작업으로의 전환은 다가오고 있는 것이 아닙니다. 이러한 도구들을 적극적으로 사용하는 개발자들에게는 이미 현실입니다.

명세 (spec)의 품질에 투자하세요. 10분간의 신중한 설계 (shaping)는 에이전트가 잘못된 방향으로 2시간 동안 작업하는 것을 방지할 수 있습니다.

체크포인트 습관을 기르세요. 모든 AI 세션의 의미 있는 시점에 요약 문서 (distillation documents)를 작성하세요. 이는 AI를 위한 것이 아니라 당신을 위한 것입니다.

하나의 오케스트레이션 (orchestration) 도구를 선택하고 깊게 파고드세요. 스스로 초래한 파편화는 파편화 문제를 더욱 악화시킵니다.

설계 파이프라인 (shaping pipeline)을 추적하세요. 어떤 아이디어가 가공되지 않은 상태인지, 어떤 것이 설계되었는지, 그리고 어떤 것이 에이전트에게 전달할 준비가 되었는지 파악해야 합니다.

** 토큰 비용을 계획하십시오. 모델 라우팅 (Model routing) 및 로컬 호스팅 (Local hosting)은 선택적인 최적화가 아니라 예산 관리의 핵심입니다.

다음 단계

도구는 워크플로우 (Workflows)보다 빠르게 진화하고 있습니다. 여기서 설명한 문제들 — 파편화된 세션 히스토리 (Session history), 수동 모델 라우팅 (Manual model routing), 미성숙한 스펙 툴링 (Spec tooling) — 은 주요 플랫폼들에 의해 부분적으로 해결될 것입니다.

플랫폼이 해결해주지 못할 것: 대규모로 AI 에이전트 (AI agents)와 잘 협업하기 위해 요구되는 인지적 규율 (Cognitive discipline)입니다. 현재 이러한 관행을 구축하고 있는 개발자들은 지속적인 우위를 점하게 될 것입니다.

심사숙고해 볼 가치가 있는 질문: 당신의 워크플로우에서 진짜 병목 현상 (Bottleneck)은 어디에 있습니까? 만약 여전히 구현 (Implementation) 단계에 있다면, 이 포스트의 도구들이 즉각적인 도움이 될 것입니다. 만약 이미 정의 (Definition) 단계로 넘어갔다면, 투자해야 할 곳은 완전히 다른 곳에 있습니다.

Datopian의 미니캐스트인 AI Learn Today의 두 에피소드를 바탕으로 작성되었습니다. 진행: Rufus Pollock 및 Anuar Ustayev.

Datopian은 오픈 데이터 인프라를 구축합니다. 우리는 2007년에 CKAN을 공동 제작했습니다.