Cline 64K 스타 — 오픈소스 코딩 에이전트의 구조가 말해주는 것
BUILD LOG · 2026-07-12
Cline 64K 스타 — 오픈소스 코딩 에이전트의 구조가 말해주는 것
VS Code 확장 하나가 64,600명의 스타를 받았다.
Cline은 원래 “Claude Dev”라는 이름의 VS Code 확장으로 시작했다. 지금은 CLI, SDK, JetBrains 플러그인, Kanban 보드까지 — 하나의 엔진이 네 개의 표면을 커버하는 풀스택 오픈소스 프로젝트다. 312번의 릴리즈, 6,500 커밋, 3,300+ 의존 프로젝트. 여기에 v4부터는 scheduled agent, multi-agent team, Slack/Telegram/Discord 연동까지 추가됐다.
처음 Cline 레포를 열었을 때 든 생각은 “이거 Drewgent랑 구조가 똑같네”였다.
그리고 그 사실이 꽤 의미 있다고 느꼈다. 독립적인 두 시스템이 같은 방향으로 수렴하고 있다면, 그 방향이 옳다는 증거이기 때문이다.
이 글이 다루는 것
- Cline의 SDK-first 아키텍처 — 하나의 엔진이 CLI, VS Code, JetBrains, Kanban을 커버하는 방식
- Kanban as orchestration — task board가 어떻게 multi-agent coordination layer가 되는가
- Rules/Skills 시스템 —
.clinerules가 모델 행동을 가이드하는 방식 - Scheduled agents — cron을 에이전트로 추상화한 설계
- Drewgent와의 구조적 수렴 — 독립적인 두 시스템이 같은 패턴에 도달한 이유
SDK-first: 하나의 엔진, 네 개의 표면
Cline의 가장 중요한 아키텍처 결정은 SDK를 최우선으로 한 것이다.
대부분의 코딩 에이전트는 VS Code 확장으로 시작한다. 그리고 CLI를 나중에 붙인다. Cline은 반대로 갔다. @cline/sdk가 코어 엔진이고, VS Code 확장과 CLI와 JetBrains 플러그인은 모두 그 SDK를 소비하는 클라이언트다.
npm install @cline/sdk
이 결정이 주는 실전적 이점은 세 가지다:
- 일관성 — 모든 표면이 같은 agent loop, 같은 tool system, 같은 provider routing을 공유한다
- 테스트 용이성 — SDK 단위로 테스트하고, 각 클라이언트는 thin layer만 검증하면 된다
- 서드파티 확장 — 누구나
@cline/sdk로 커스텀 에이전트를 만들 수 있다
Drewgent도 같은 패턴을 쓴다. opencode의 task()가 코어 엔진이고, 내 skill/plugin/mcp 레이어는 모두 그 위에서 도는 클라이언트다. “하나의 추상화, 여러 표면” — 이 패턴이 코딩 에이전트 아키텍처의 정답에 가까워지고 있다.
Kanban을 orchestration layer로
Cline v4의 가장 흥미로운 기능은 Kanban이다. 단순한 task board가 아니다. 각 카드가 자체 worktree를 가지고, auto-commit을 하며, dependency chain을 지원한다. 여러 에이전트가 동시에 같은 레포에서 작업할 때 충돌을 물리적으로 방지하는 구조다.
npm i -g kanban
이 설계는 Drewgent의 GJC Coordinator + office-autopilot과 거의 같은 패턴이다. 나도 몇 달 전에 같은 결론에 도달했다: 에이전트 오케스트레이션의 기본 단위는 task가 아니라 worktree다.
같은 레포에서 여러 에이전트가 동시에 작업하려면:
- 물리적 격리 (git worktree)
- 변경 사항의 독립적 추적 (auto-commit)
- 작업 간 의존성 관리 (dependency chain)
- 병렬 실행 (동시 spawn + 분리된 컨텍스트)
Cline과 Drewgent가 완전히 같은 네 가지 요구사항에 도달했다는 게 인상적이다.
Rules/Skills: .clinerules의 힘
Cline은 .clinerules 파일로 프로젝트별 규칙을 정의한다. 코딩 표준, 아키텍처 컨벤션, 배포 절차, 테스팅 요구사항 — 이 모든 것을 파일 하나에 담아서 CLI, VS Code, JetBrains 전 자동으로 적용된다.
Drewgent의 skill system과 같은 개념이다.
내 시스템에는 P0-brainstem/brain/rules.md부터 skills/ 아래 53개의 스킬 파일이 있다. 각 스킬은 특정 도메인의 작업을 위한 specialized instruction set이다. Cline의 .clinerules도 같은 역할을 한다 — 모델의 행동을 프롬프트가 아니라 파일로 구조화한다.
이 패턴이 중요한 이유는 모델이 바뀌어도 규칙은 남는다는 점이다. “프롬프트는 휘발된다, 패턴은 남는다” — Ep.51(Fabric)에서 다뤘던 원칙이 Cline에서도 독립적으로 검증되고 있다.
Scheduled agents: cron을 에이전트로
Cline v4는 scheduled agent를 지원한다. cron 표현식으로 에이전트를 예약 실행한다:
cline schedule create "PR summary"
--cron "0 9 * * MON-FRI"
--prompt "List all open PRs and their review status"
--workspace /path/to/repo
Drewgent에서 이 패턴을 launchd cron + drewgent_cron.py로 구현했다. n8n을 제거하고(Ep.13) 30개 cron을 12개로 줄인 후, 각 cron job이 opencode agent를 트리거하는 구조다. Cline은 이걸 제품 기능으로, 나는 인프라 레벨로 구현했다. 목표는 같다 — “정기적인 작업을 사람이 아닌 에이전트가 처리하게 하라.”
키 설계 결정 비교
| Cline의 결정 | Drewgent의 대응 | 비고 |
|---|---|---|
| SDK-first (@cline/sdk) | opencode task() + plugins | 같은 패턴, API 디자인 차이 |
| Kanban + worktree isolation | GJC Coordinator + office-autopilot | 완전한 구조적 수렴 |
| .clinerules 파일 | skills/ + P0-brainstem/rules.md | 같은 개념. 파일 기반 행동 가이드 |
| 모델 제공자 중립 | 3-tier model routing | 같은 목표, 라우팅 전략 차이 |
| Scheduled agents | launchd cron + opencode run | 같은 목적, 추상화 레벨 차이 |
| Chat integration | discord_bot.py gateway | 같은 패턴. Discord-우선 vs 멀티 플랫폼 |
두 시스템이 같은 방향을 가리킨다는 것
Cline과 Drewgent는 독립적으로 발전했다. 나는 내 시스템의 문제를 해결하면서 구조를 만들었고, Cline 팀은 Cline의 문제를 해결하면서 구조를 만들었다. 그런데 결과가 놀랍도록 비슷하다.
6개 항목 중 3개(kanban+worktree, rules/skills, chat integration)가 거의 동일한 구현 패턴을 보인다. 나머지 3개도 목표는 같고 구현 레벨만 다르다.
이 수렴이 말해주는 건 분명하다. 코딩 에이전트 아키텍처에는 자연스러운 수렴점이 존재한다. SDK-first 구조화, 파일 기반 행동 가이드, worktree 격리 기반 멀티 에이전트 — 이 패턴들은 선택이 아니라 요구사항에서 파생된 필연이다.
Cline이 64K 스타를 받은 이유는 기능이 많아서가 아니다. 구조가 단순해서, 그리고 그 단순함이 올바른 방향을 가리키고 있기 때문이다.
그리고 그 방향은 내가 이미 가고 있던 길과 같다. 그게 가장 큰 확신이다.
참고 링크
- Cline GitHub Repository — 64.6K ★, Apache 2.0
- Cline Docs — SDK, CLI, Kanban 가이드
- Cline Kanban — multi-agent task board
읽어줘서 고맙다. Cline에 대해 써볼까 말까 고민했는데, 직접 까보니 Drewgent와의 연결점이 너무 많아서 재미있었다. 구조가 좋은 방향으로 수렴하고 있다는 증거 — 이 하나면 충분하다.