Devlery
Blog/AI

Cline Kanban 출시로 본 멀티에이전트 오케스트레이션, 새로운 전쟁이 시작됐다

Cline이 CLI-agnostic 멀티에이전트 오케스트레이션 도구 Kanban을 출시했습니다. 에이전트 5개를 동시에 돌리는 시대, 개발자 워크플로우의 구조적 전환을 분석합니다.

3월 26일, Cline이 Cline Kanban을 출시했습니다. CLI 에이전트를 가리지 않는 멀티에이전트 오케스트레이션 앱입니다. Claude Code, OpenAI Codex, Cline 중 어떤 에이전트든 하나의 칸반 보드에서 병렬로 실행하고 관리할 수 있습니다. 각 작업 카드마다 독립적인 git worktree와 터미널이 할당되어, 머지 충돌 없이 여러 에이전트를 동시에 돌릴 수 있습니다. npm i -g cline && cline 한 줄이면 설치가 끝납니다. 무료 오픈소스, Apache 2.0 라이선스입니다.

이 뉴스가 중요한 이유는 Cline Kanban이라는 단일 도구 때문이 아닙니다. 3월 한 달 동안 JetBrains Central, Vibe Kanban, Code Conductor가 동시다발적으로 등장했습니다. "멀티에이전트 오케스트레이션"이 하나의 도구 범주로 굳어지고 있다 는 신호입니다. 터미널 하나에 에이전트 하나를 돌리던 시대가 끝나고, 에이전트 팀을 지휘하는 시대가 열린 것입니다.

에이전트가 터미널을 점령한 이후

왜 지금 멀티에이전트 오케스트레이션 도구가 쏟아지는 걸까요? 배경에는 두 가지 구조적 병목이 있습니다.

첫 번째는 추론 대기 시간(inference-bound waiting) 입니다. AI 코딩 에이전트를 실행하면 개발자는 응답을 기다립니다. 복잡한 작업일수록 대기 시간이 길어집니다. 에이전트가 코드를 생성하는 동안 개발자의 터미널과 주의력은 묶여 있습니다. 에이전트 하나만 돌리면 그 시간이 순수한 유휴 시간이 됩니다.

두 번째는 머지 충돌 기반 병렬 처리의 한계 입니다. 이 문제를 해결하려고 여러 터미널을 열어 에이전트를 동시에 돌리면, 같은 코드베이스를 여러 에이전트가 수정하면서 충돌이 발생합니다. 수동으로 브랜치를 나누고, worktree를 설정하고, 결과를 머지하는 과정이 오히려 병목이 됩니다.

이 두 병목은 AI 코딩 에이전트가 "1개 돌리는 시대"에서 "5~20개 동시에 돌리는 시대"로 전환되면서 더 선명해졌습니다. Latent.Space의 2026년 3월 "Everything is CLI" 특집이 정확히 이 흐름을 짚었습니다. CLI가 에이전트 통합의 표준 인터페이스로 부상하면서, Stripe, Ramp, ElevenLabs, Google Workspace 등 주요 플랫폼이 CLI를 에이전트 친화적 인터페이스로 내놓고 있습니다. Andrej Karpathy도 백엔드 서비스 프로비저닝에서 CLI가 MCP보다 더 직관적이라는 견해를 밝힌 바 있습니다.

CLI 에이전트 생태계가 팽창하자, 그 위에 올라갈 "시각적 오케스트레이션 레이어"의 필요성이 자연스럽게 대두됩니다. Cline Kanban은 이 틈을 정면으로 파고든 첫 번째 주요 도구입니다.

Cline Kanban이 풀어내는 방식

Cline Kanban의 핵심 메커니즘을 살펴보겠습니다. 기술적 세부사항이 이 도구의 경쟁력을 결정짓기 때문입니다.

Git Worktree 기반 완전 격리

각 작업 카드에 독립적인 ephemeral git worktree와 전용 터미널이 할당됩니다. 작업 카드에서 "Play"를 누르면 Kanban이 자동으로 worktree를 생성하고 에이전트를 시작합니다. 각 에이전트는 완전히 격리된 환경에서 실행되므로, 앞서 말한 머지 충돌 문제가 구조적으로 해결됩니다.

흥미로운 점은 symlink 최적화 입니다. node_modules 같은 gitignored 디렉토리를 worktree 간 공유하여 디스크 공간과 설치 시간을 절약합니다. 프로젝트 규모가 클수록 이 최적화의 효과가 커집니다. 작업이 완료되면 자동으로 커밋하고 PR을 생성할 수도 있습니다.

의존성 체이닝으로 파이프라인 구성

단순히 여러 에이전트를 병렬로 돌리는 것이 아닙니다. 작업 카드 간 의존성을 링크할 수 있습니다. Cmd+클릭 으로 카드 간 의존성을 연결하면, 부모 작업이 완료될 때 자식 작업이 자동으로 시작됩니다.

예를 들어 대규모 리팩토링을 생각해봅시다. "DB 스키마 마이그레이션" 카드가 완료되면 "API 엔드포인트 업데이트" 카드가 자동으로 시작되고, 그것이 끝나면 "통합 테스트 작성" 카드가 뒤따르는 식입니다. 연쇄적으로 대규모 작업을 자율적으로 완료하는 파이프라인을 구성할 수 있습니다. 이것이 단순한 "에이전트 런처"와 "오케스트레이터"의 차이입니다.

CLI-agnostic 에이전트 호환

Cline Kanban이 "CLI-agnostic"을 표방하는 이유가 있습니다. 현재 Cline, Claude Code, OpenAI Codex를 완전 지원하며, 추가 에이전트도 예정되어 있습니다. 하나의 보드에서 작업 특성에 따라 최적의 에이전트를 선택할 수 있는 구조입니다. 코드 생성은 Claude Code에, 테스트 작성은 Codex에, 리팩토링은 Cline에 맡기는 식의 혼합 전략이 가능합니다.

공식 문서에 따르면, 실험적 기능을 활용하여 권한 요청과 런타임 훅을 우회함으로써 에이전트의 자율성을 높인다고 합니다.

실시간 Diff 리뷰와 인라인 코멘트

에이전트가 작업한 변경사항을 실시간 diff로 확인할 수 있습니다. PR 리뷰와 유사한 방식으로 인라인 코멘트를 달아 에이전트에 피드백을 전달합니다. 체크포인트 기반 비교로 변경 이력을 추적하고, 에이전트의 메시지와 도구 호출 내역을 카드에서 직접 모니터링할 수 있습니다.

Addy Osmani(Google Chrome 팀)의 분석이 이 기능의 의미를 잘 설명합니다.

"병목은 더 이상 코드 생성이 아닙니다. 검증(verification)입니다."

(원문: "The bottleneck is no longer code generation. It's verification.")

에이전트가 코드를 만드는 속도가 사람이 평가하는 속도를 넘어선 시점에서, 오케스트레이션 도구의 핵심 가치는 "더 많이 돌리는 것"이 아니라 "효율적으로 검증하는 것"입니다. Cline Kanban의 diff 리뷰 워크플로우는 이 검증 과정을 체계화하려는 시도입니다.

Cline Kanban 워크플로우

칸반 카드 생성

Git worktree 할당

에이전트 실행

ClaudeCodexCline

실시간 diff 모니터링

인라인 코멘트 피드백

의존성 체이닝 자동 시작

자동 커밋 / PR 생성

멀티에이전트 오케스트레이션 경쟁 지형도

Cline Kanban은 홀로 등장하지 않았습니다. 2026년 3월은 멀티에이전트 오케스트레이션 도구가 동시다발적으로 출시된 시기입니다. 이 경쟁 구도를 정리하면 시장이 어디로 향하는지가 보입니다.

도구타겟실행 환경에이전트 호환격리의존성가격
Cline Kanban개인 개발자로컬 터미널모든 CLI 에이전트Git worktree무료 오픈소스
JetBrains Central기업IDE 통합JetBrains AI 등가상 공간유료 (미정)
Claude Code Teams터미널 (tmux)Claude 전용subagentAnthropic 유료
Vibe Kanban개인웹 UI더 많은 CLI 에이전트Git worktree무료 오픈소스
Cursor Parallel개인IDE 통합Cursor AI 전용탭 기반유료

JetBrains Central: 기업의 길

JetBrains Central은 Cline Kanban과 같은 주에 발표되었지만, 방향이 완전히 다릅니다. Central의 핵심은 기업 거버넌스 입니다. 정책 집행, IAM(Identity and Access Management), 감사 추적, 비용 귀속 기능을 통해 조직이 AI 에이전트를 통제할 수 있게 합니다. Claude Code, Codex, Gemini CLI, Junie 등 다양한 에이전트를 지원하며, 클라우드와 온프레미스 모두 대응합니다. Q2 2026 Early Access가 예정되어 있습니다.

Cline 공식 블로그의 한 문장이 두 도구의 철학적 차이를 선명하게 보여줍니다.

"우리는 터미널을 대체하려는 것이 아닙니다. 당신의 주의력을 돌려주려는 것입니다."

(원문: "We're not trying to replace the terminal. We're trying to give you back your attention.")

JetBrains Central이 조직의 통제력 을 돌려주려 한다면, Cline Kanban은 개인 개발자의 인지 과부하 를 해결하려 합니다.

Claude Code Teams: 프로세스 내 접근

Claude Code의 Agent Teams 기능은 다른 각도에서 접근합니다. tmux 기반으로 리드 에이전트 1명과 팀원 에이전트 3명이 공유 태스크 리스트와 P2P 메시징으로 협업하는 구조입니다. 별도 앱이 아니라 Claude Code 내부에서 동작하며, CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 환경변수로 활성화합니다.

Addy Osmani는 이런 접근을 Tier 1(프로세스 내) 으로 분류합니다. 에이전트 내부에서 서브에이전트를 생성하는 방식입니다. Cline Kanban 같은 로컬 오케스트레이터는 Tier 2, 클라우드 비동기 에이전트(Claude Code Web, GitHub Copilot Agent)는 Tier 3 으로 분류됩니다.

Vibe Kanban: 가장 가까운 경쟁자

기능적으로 Cline Kanban과 가장 유사한 도구는 Vibe Kanban입니다. worktree 격리, 의존성 체이닝, diff 리뷰까지 핵심 기능이 거의 동일합니다. 차이점은 에이전트 호환 범위입니다. Vibe Kanban은 Claude Code, Codex, Gemini CLI, Amp, Cursor Agent CLI까지 더 넓은 에이전트를 지원합니다. 반면 Cline Kanban은 Cline CLI 생태계와의 깊은 통합, 그리고 49회에 달하는 활발한 릴리스 주기가 강점입니다.

Cursor Parallel: IDE 내장형

Cursor Parallel은 Cursor IDE에 내장된 병렬 에이전트 기능입니다. Git worktree 기반 격리를 지원하지만, Cursor 에이전트만 사용할 수 있고 의존성 체이닝은 지원하지 않습니다. IDE 안에서 완결되는 경험을 원하는 Cursor 사용자에게는 자연스러운 선택입니다.

Paperclip과의 철학적 차이

이전에 다루었던 Paperclip과도 비교해볼 수 있습니다. Paperclip은 "무인 회사" 모델로, 20개 에이전트가 CEO, CTO, 개발자 역할을 맡아 자율 운영합니다. Cline Kanban은 "인간 중심" 모델로, 개발자가 보드를 보며 직접 에이전트를 관리합니다. 완전 자율 vs 인간-에이전트 협업이라는 철학적 분기점에 서 있는 두 도구입니다.

개발자 워크플로우가 바뀐다

멀티에이전트 오케스트레이션 도구가 실무에 미치는 영향을 구체적으로 생각해보겠습니다.

대규모 리팩토링 시나리오

100개 파일에 걸친 API v1에서 v2로의 마이그레이션을 상상해봅시다. 기존 방식이라면 하나의 에이전트에게 전체를 맡기거나, 개발자가 수동으로 작업을 분할해 여러 브랜치에서 작업합니다. Cline Kanban 방식이라면 칸반 보드에 작업을 카드로 분해하고, 각 카드에 에이전트를 배치하며, 의존성 체이닝으로 순서를 정한 뒤 동시에 실행합니다. 각 에이전트는 격리된 worktree에서 작업하므로 충돌이 없고, 완료되는 대로 다음 작업이 자동으로 이어집니다.

사이드바 에이전트 기능을 활용하면, 프롬프트 하나로 대규모 프로젝트의 백로그를 작업 카드로 자동 분해하는 것도 가능합니다. Linear MCP 통합을 통해 기존 프로젝트 관리 도구의 티켓을 직접 가져올 수도 있습니다.

"에이전트 하네스 엔지니어링"의 등장

Latent.Space의 분석이 흥미롭습니다. 모델 품질만으로는 충분하지 않으며, 에이전트 하네스(미들웨어, 메모리, 작업 오케스트레이션, 도구 인터페이스, 안전 정책, 평가 루프)가 점점 더 진짜 제품이 되고 있다는 것입니다. Cline Kanban은 이 "하네스 엔지니어링" 카테고리의 대표적 사례입니다.

이것은 DevOps가 개발과 운영 사이의 간극을 메우며 하나의 전문 영역으로 성장한 것과 유사한 패턴입니다. 에이전트를 잘 만드는 것(모델 개발)과 에이전트를 잘 다루는 것(하네스 엔지니어링)이 별개의 역량으로 분화하고 있습니다.

설치부터 실행까지

Cline Kanban의 진입장벽은 낮습니다. Node.js 18 이상이 설치된 환경에서 git 저장소 루트로 이동한 뒤 실행하면 됩니다.

npm i -g cline
cline

또는 npx로 직접 실행할 수도 있습니다.

npx kanban

로컬 브라우저에서 칸반 보드가 열리고, 여기서 작업 카드를 생성하고 에이전트를 할당합니다. 계정이 필요 없고, 모든 데이터는 로컬에 저장됩니다. Research Preview 단계이므로 안정성에 주의가 필요하지만, 4일 만에 GitHub Stars 381개, v0.1.53(49번째 릴리스)에 도달한 개발 속도는 프로젝트의 활력을 보여줍니다.

Cline Kanban — 보드 예시
To Do
통합 테스트 작성
Codex대기 중
문서 업데이트
Cline대기 중
In Progress
API 엔드포인트 v2 마이그레이션
worktree: feature/api-v2
Claude Code

실행 중

DB 스키마 최적화
worktree: feature/db-schema
Codex

실행 중

Done
타입 정의 리팩토링
Claude CodePR #42 ✓
린트 규칙 설정
ClinePR #41 ✓

커뮤니티는 어떻게 보고 있는가

X(Twitter) 반응

Cline 공식 계정은 출시를 이렇게 소개했습니다.

"Cline Kanban을 소개합니다. CLI에 구애받지 않는 멀티에이전트 오케스트레이션을 위한 독립형 앱입니다. Claude와 Codex를 지원합니다."

(원문: "Introducing Cline Kanban: A standalone app for CLI-agnostic multi-agent orchestration. Claude and Codex compatible.")

개발자들의 반응에서 몇 가지 패턴이 보입니다. 여러 개발자가 Cline Kanban을 "멀티에이전트 인터페이스의 사실상 표준(default)"이 될 가능성이 있는 도구로 평가했습니다. 추론 대기 시간과 머지 충돌이라는 두 가지 실질적 병목을 정면으로 해결한다는 평가도 있었습니다.

업계 분석가들의 시선

TestingCatalog은 Cline Kanban을 "CLI 코딩 에이전트를 위한 로컬 병렬 실행 도구"로 평가하며, Anthropic/OpenAI/Google/Mistral API 키뿐 아니라 무료 모델도 지원 가능하다는 점을 언급했습니다.

Latent.Space는 더 거시적인 관점에서 분석합니다.

"멀티에이전트 worktree 오케스트레이션이 비정상적으로 강한 개발자 관심을 받았다."

모델 품질보다 에이전트 하네스가 진짜 제품이 되는 전환점으로 평가한 것입니다. 이것은 단순히 Cline Kanban에 대한 평가가 아니라, 도구 범주 전체에 대한 진단입니다.

Addy Osmani의 3단계 분류

Addy Osmani(Google)는 "The Code Agent Orchestra"라는 분석글에서 멀티에이전트 오케스트레이션을 3단계로 분류했습니다. 이 분류가 현재 경쟁 구도를 이해하는 데 유용합니다.

Tier 1: 프로세스 내(In-process) 에이전트 내부에서 서브에이전트를 생성하는 방식입니다. Claude Code의 subagents와 Agent Teams가 대표적입니다. 설정이 간단하고 에이전트 간 통신이 빠르지만, 특정 에이전트에 종속됩니다.

Tier 2: 로컬 오케스트레이터(Local orchestrators) Cline Kanban, Vibe Kanban, Code Conductor, Gastown이 여기에 속합니다. 에이전트에 구애받지 않고, 시각적 인터페이스로 관리하며, 로컬에서 실행됩니다.

Tier 3: 클라우드 비동기(Cloud async) Claude Code Web, GitHub Copilot Agent처럼 클라우드에서 비동기로 실행되는 방식입니다. 로컬 리소스를 사용하지 않지만, 실시간 피드백이 제한됩니다.

현재 가장 활발한 경쟁이 벌어지는 곳은 Tier 2입니다. 개인 개발자가 직접 에이전트를 관리하면서도 CLI의 유연성을 유지할 수 있는 지점이기 때문입니다.

회의적 시각도 존재한다

HN과 Reddit에서는 Cline Kanban 전용 스레드가 아직 활발하지 않지만, 관련 주제("Agent orchestration for the timid" 등)에서 멀티에이전트 오케스트레이션에 대한 회의적 시각도 있습니다. 에이전트 하나의 출력도 충분히 검증하기 어려운 상황에서, 여러 에이전트를 동시에 돌리면 검증 부담이 기하급수적으로 늘어난다는 우려입니다. Research Preview 단계인 도구에 실무 워크플로우를 맡기는 것에 대한 신중론도 있습니다.

Addy Osmani의 멀티에이전트 오케스트레이션 3단계 분류

1
Tier 1
프로세스 내 (In-process)
Claude Code subagents
Claude Code Teams
가장 빠른 에이전트 간 통신
설정 단순
특정 에이전트에 종속
유연성 낮음
현재 가장 경쟁 치열
2
Tier 2
로컬 오케스트레이터
Cline Kanban
Vibe Kanban
Gastown
에이전트 무관 (CLI 호환)
시각적 인터페이스
속도와 유연성의 균형
로컬 리소스 소비
3
Tier 3
클라우드 비동기
Claude Code Web
GitHub Copilot Agent
로컬 리소스 불필요
높은 확장성
실시간 피드백 제한
높은 지연 시간

에이전트 오케스트레이션이 다음 전선인 이유

지금 우리가 목격하고 있는 것은 AI 코딩 도구 시장의 경쟁 축 이동 입니다. 2024년은 "어떤 모델이 코드를 더 잘 짜는가"의 시대였습니다. 2025년은 "어떤 에이전트가 더 자율적으로 작업하는가"의 시대였습니다. 2026년, 경쟁의 초점이 "에이전트를 얼마나 잘 다루는가"로 이동하고 있습니다.

단기적으로 주목할 포인트

Cline Kanban은 Research Preview 상태이므로, 안정 버전으로의 전환이 첫 번째 관문입니다. 추가 에이전트 통합(Gemini CLI, Amp 등)도 예상됩니다. JetBrains Central의 Q2 2026 Early Access 출시는 기업 시장과의 경쟁 구도를 본격화할 것입니다.

도구 범주의 수렴

현재 난립하는 오케스트레이션 도구들은 몇 개로 수렴할 가능성이 높습니다. Addy Osmani의 3단계 분류가 시사하듯, 각 Tier에서 1-2개의 도구가 사실상 표준으로 자리잡을 것입니다. Tier 1은 Claude Code와 각 에이전트 자체 기능으로 수렴하고, Tier 2에서 Cline Kanban과 Vibe Kanban의 경쟁이 핵심이 될 것이며, Tier 3은 대형 플랫폼(Anthropic, GitHub)이 주도할 것입니다.

더 큰 그림

에이전트 오케스트레이션이 IDE의 핵심 기능으로 흡수될 가능성도 있습니다. JetBrains가 Central을 독립 플랫폼으로 내놓은 것, Cursor가 Parallel을 IDE에 내장한 것은 이미 그 방향을 보여줍니다. 장기적으로 "에이전트 오케스트레이션을 지원하지 않는 IDE"는 경쟁력을 잃게 될 수 있습니다.

개인 개발자의 관점에서, 이것은 한 명이 에이전트 팀을 지휘하여 팀급 생산성을 내는 시대 의 시작점입니다. Cline Kanban이 그 첫 번째 대중적 인터페이스를 제공하고 있습니다. 아직 Research Preview이고, 에이전트 출력의 검증 문제도 해결되지 않았지만, 방향은 분명합니다. 터미널 하나에 에이전트 하나를 돌리던 시대는 끝나가고 있습니다. 이제 우리가 준비해야 할 것은 "에이전트를 잘 쓰는 법"이 아니라 "에이전트 팀을 잘 지휘하는 법"입니다.