Cline 프로젝트 분석: 에디터 안에 사는 코딩 에이전트는 코어를 어떻게 호스트에서 떼어냈나요?

분석 일자: 2026-06-30 대상 패키지: claude-dev(Cline VS Code 확장) 4.0.0, @cline/cli 3.0.33 대상 커밋: 64fc3f372e9d1f8eaffd636b8cf00d64d9d83d95 (main 브랜치) 저장소: https://github.com/cline/cline 로컬 분석 경로: ~/workspace/opensources/cline

This article is partially written by Claude Code

목차

1. 왜 Cline인가요?
2. 기존 글들과 어디에 놓이나요?
3. 프로젝트를 한 문장으로 이해하기
4. 기술 스택과 규모
5. 전체 그림: 코어 하나, 호스트 둘
6. 코드베이스 지도
7. 호스트 추상화: 코어를 에디터에서 떼어냅니다
8. Task 실행 루프와 도구
9. Plan/Act와 사람 승인: Cline의 정체성
10. Checkpoints: 되돌릴 수 있는 에이전트
11. LLM provider 계층
12. MCP, 브라우저, Skills, Subagents
13. CLI와 Kanban: 에디터 밖으로
14. OpenCode와 비교: 같은 분리, 다른 무게중심
15. 코드를 읽는 추천 순서
16. 인상적인 설계 포인트
17. 주의해서 볼 지점
18. 결론

1. 왜 Cline인가요?

Cline은 README에서 자신을 이렇게 소개합니다. "The open source coding agent in your IDE and terminal." 출발점은 VS Code 확장입니다. 에디터 안에서 코드를 읽고, 고치고, 명령을 실행하고, 브라우저를 조작하는 에이전트입니다.

겉으로는 Qwen Code나 OpenCode 같은 또 하나의 코딩 에이전트로 보입니다. 하지만 저장소를 열면 Cline을 다른 프로젝트와 구별 짓는 두 가지가 보입니다.

첫째, Cline은 사람을 루프 안에 둡니다. 에이전트가 파일을 고치거나 명령을 실행하기 전에, 기본적으로 사람이 그 행동을 승인합니다. 계획만 세우는 Plan 모드와 실행하는 Act 모드를 나눠, "먼저 합의하고 그다음 실행한다"를 구조로 만들었습니다. 게다가 매 단계를 체크포인트로 스냅샷해 두어 마음에 들지 않으면 작업 트리를 언제든 되돌릴 수 있습니다.

둘째, Cline은 코어를 호스트에서 떼어냈습니다. 에이전트의 본체(LLM 호출, 도구 실행, 상태 관리)는 VS Code API에 직접 묶여 있지 않습니다. 그 사이에 protobuf/gRPC로 정의한 서비스 경계가 있습니다. 덕분에 같은 코어가 VS Code 안에서도, 터미널 CLI에서도, 다른 에디터에서도 똑같이 돕니다.

그래서 Cline을 "VS Code용 AI 코딩 확장"이라고만 보면 절반만 본 셈입니다. 더 정확하게는 사람의 승인과 되돌리기를 1급 기능으로 두고, 코어를 호스트에서 분리한 코딩 에이전트입니다.

2. 기존 글들과 어디에 놓이나요?

최근 분석한 코딩 에이전트 글들과 나란히 놓으면 Cline의 위치가 또렷해집니다.

핵심은 Cline이 "VS Code에서 돌아가는 또 하나의 코딩 에이전트"로 설명되지 않는다는 점입니다. OpenCode 글에서 경계는 models.dev와 HTTP 계약이었습니다. Cline에서 그 경계는 23개의 .proto 서비스 정의, HostProvider 추상화, 사람 승인을 강제하는 Plan/Act 흐름입니다.

3. 프로젝트를 한 문장으로 이해하기

Cline은 VS Code 확장을 출발점으로 삼는 TypeScript 코딩 에이전트로, LLM 호출·도구 실행·상태 관리를 담은 코어를 protobuf/gRPC 경계(ProtoBus + HostBridge)로 호스트에서 떼어내고, 그 위에 Plan/Act 사람 승인과 체크포인트 되돌리기를 1급 기능으로 올린 에이전트입니다. 같은 코어가 VS Code·터미널 CLI·다른 에디터에서 돕니다.

질문으로 바꾸면 이렇습니다.

4. 기술 스택과 규모

로컬 체크아웃 기준 규모는 이렇습니다.

5. 전체 그림: 코어 하나, 호스트 둘

Cline의 큰 그림은 "하나의 코어가 두 종류의 호스트 위에서 돈다"입니다.

flowchart TD
    WV["React 웹뷰 (VS Code)"] --> PB["ProtoBus (gRPC)<br/>cline/*.proto"]
    CLI["@cline/cli (터미널)"] --> PB
    PB --> CORE["Cline 코어<br/>task / controller / api / context"]

    CORE --> LOOP["Task 실행 루프<br/>LLM → 도구 → 사람 승인 → 결과"]
    LOOP --> LLM["sdk/packages/llms<br/>vendors + AI SDK + gateway"]
    LOOP --> TOOLS["도구<br/>read/write/edit/execute/browser/mcp"]

    CORE --> HB["HostBridge (gRPC)<br/>host/*.proto"]
    HB --> VSC["VS Code 호스트<br/>파일·diff·터미널·환경"]
    HB --> EXT["Standalone 호스트<br/>CLI / 다른 에디터"]

    CORE --> CP["Checkpoints<br/>git 그림자 스냅샷"]

화살표를 두 방향으로 보면 됩니다. 위쪽에서 웹뷰와 CLI가 ProtoBus로 코어를 호출하고, 아래쪽에서 코어가 HostBridge로 호스트 환경(파일·diff·터미널)을 부립니다. 코어는 자신이 VS Code 안에 있는지 CLI 안에 있는지 알 필요가 없습니다. 그 차이는 HostBridge 너머에 숨습니다.

6. 코드베이스 지도

Cline은 Bun 워크스페이스 모노레포입니다. 핵심은 apps/와 sdk/입니다.

가장 먼저 읽을 곳은 apps/vscode/src/standalone/cline-core.ts입니다. 코어가 VS Code 없이 어떻게 기동하는지, ProtoBus와 HostBridge가 어디서 붙는지가 여기 다 보입니다.

7. 호스트 추상화: 코어를 에디터에서 떼어냅니다

Cline의 구조에서 가장 중요한 결정이 여기 있습니다. 코어는 VS Code API를 직접 호출하지 않습니다. 대신 apps/vscode/src/hosts/host-provider.ts의 HostProvider 싱글턴을 거칩니다. 주석이 의도를 그대로 적어 둡니다. "나머지 코드는 host provider 인터페이스로 플랫폼별 기능에 접근한다."

HostProvider는 호스트별 팩토리를 내줍니다.

• createDiffViewProvider() — 변경을 diff로 보여주는 방법
• workspace / window / env — 작업 공간·창·환경 접근
• 터미널 매니저 — VS Code의 TerminalManager 또는 standalone의 StandaloneTerminalManager

이 추상화 위에서 통신은 두 갈래의 gRPC로 갈립니다.

• ProtoBus — 웹뷰(또는 CLI)가 코어를 호출하는 방향입니다. apps/vscode/proto/cline/*.proto에 task, state, ui, mcp, browser, checkpoints, models, web, worktree 같은 서비스가 정의돼 있습니다. React 웹뷰는 이 서비스를 호출해 메시지를 보내고 상태를 구독합니다.
• HostBridge — 코어가 호스트 환경을 호출하는 방향입니다. apps/vscode/proto/host/*.proto(diff, env 등)로 파일 diff·환경 정보 같은 플랫폼 작업을 요청합니다.

flowchart LR
    UI["웹뷰 / CLI"] -- "ProtoBus (gRPC)" --> CORE["Cline 코어"]
    CORE -- "HostBridge (gRPC)" --> HOST["호스트<br/>VS Code 또는 standalone"]
    CORE --> HP["HostProvider<br/>diff / terminal / workspace 팩토리"]
    HP --> HOST

apps/vscode/src/standalone/cline-core.ts가 이 그림의 standalone 쪽을 조립합니다. IS_STANDALONE === "true" 빌드에서 ExternalDiffViewProvider·ExternalWebviewProvider·StandaloneTerminalManager를 끼우고, ProtoBus 서비스를 띄운 뒤 HostBridge가 준비되기를 기다립니다. 즉 코어 코드는 한 벌인데, 호스트 구현만 갈아끼우면 VS Code 확장도 되고 CLI도 됩니다.

8. Task 실행 루프와 도구

사용자의 한 메시지는 하나의 Task가 됩니다. 코어는 모델 응답을 스트리밍으로 받아 텍스트와 도구 호출로 파싱하고(presentAssistantMessage), 도구를 실행한 뒤(ToolExecutor), 결과를 다시 모델에 돌려주는 식으로 루프를 돕니다. assistant가 도구를 더 부르는 동안 루프가 이어지고 attempt_completion이 나오면 마무리합니다.

도구 목록은 apps/vscode/src/shared/tools.ts에 모여 있습니다. 성격별로 묶으면 이렇습니다.

여기서 눈여겨볼 대목은 plan_mode_respond와 act_mode_respond가 도구로 들어 있다는 사실입니다. 모드 전환이 프롬프트 관례가 아니라 도구 수준의 계약입니다. condense·summarize_task·focus_chain은 긴 작업에서 컨텍스트를 줄이고 초점을 유지하는 장치입니다.

9. Plan/Act와 사람 승인: Cline의 정체성

Cline을 다른 코딩 에이전트와 가장 분명히 가르는 지점이 사람 승인입니다.

• Plan 모드: 에이전트는 코드를 바로 고치지 않습니다. 무엇을 할지 설명하고 사용자와 합의합니다(plan_mode_respond). 읽기와 탐색은 하되, 편집은 미룹니다.
• Act 모드: 합의된 계획을 실제로 실행합니다(act_mode_respond). 파일 편집·명령 실행이 일어납니다.

그리고 Act 모드에서도 위험한 도구(파일 쓰기, 셸 명령, 브라우저 조작)는 기본적으로 사람의 승인을 거칩니다. 사용자는 자동 승인 범위를 설정으로 넓힐 수 있지만, 출발점은 "에이전트가 함부로 행동하지 않는다"입니다.

이 설계는 OpenHands가 sandbox로 위험을 가두는 방향과 대비됩니다. OpenHands는 격리된 환경에서 에이전트를 자유롭게 두고, Cline은 사용자의 실제 작업 공간에서 돌되 매 행동을 사람의 손을 거치게 합니다. 둘 다 "에이전트가 망치는 것"을 막지만, 한쪽은 격리로, 다른 쪽은 승인과 되돌리기로 막습니다.

10. Checkpoints: 되돌릴 수 있는 에이전트

승인이 "하기 전에 막는" 장치라면, 체크포인트는 "한 뒤에 되돌리는" 장치입니다.

Cline은 작업을 진행하면서 단계마다 작업 트리를 git 그림자(shadow) 저장소에 스냅샷합니다(apps/vscode/src/core/controller/checkpoints). 사용자의 실제 git 히스토리를 건드리지 않으면서, 에이전트가 만든 변경을 별도로 추적합니다. 그래서 몇 단계 전 상태가 더 나았다면 그 체크포인트로 작업 트리를 복원할 수 있습니다.

이 기능이 중요한 이유는 신뢰 비용을 낮추기 때문입니다. 되돌리기가 보장되면, 사용자는 에이전트에게 조금 더 과감하게 일을 맡길 수 있습니다. 승인이 신뢰의 앞문이라면, 체크포인트는 안전망입니다.

11. LLM provider 계층

Cline의 모델 계층은 sdk/packages/llms에 따로 빠져 있습니다. 구성은 세 겹입니다.

• vendor 어댑터 (src/providers/vendors/) — anthropic, bedrock, google, vertex, mistral, openai, openai-compatible, minimax, community까지 9종입니다. openai-compatible은 임의의 OpenAI 호환 엔드포인트(로컬 모델 포함)를 받습니다.
• AI SDK + gateway — ai-sdk.ts는 Vercel AI SDK를 쓰고, gateway.ts는 Cline이 운영하는 gateway provider를 다룹니다. 사용자는 자기 API 키를 직접 넣거나 Cline 계정을 거칠 수 있습니다.
• model registry / catalog — model-registry.ts·catalog/가 모델 메타데이터(컨텍스트 길이, 가격, 능력)를 관리합니다.

OpenCode가 모델 메타데이터를 외부 models.dev로 완전히 빼냈다면, Cline은 같은 일을 저장소 안의 model registry와 catalog로 처리합니다. 둘 다 "모델을 데이터로 다룬다"는 방향은 같지만, OpenCode는 그 데이터를 바깥에 두고 Cline은 안에 둡니다.

12. MCP, 브라우저, Skills, Subagents

Cline은 확장할 수 있는 갈래가 넓습니다.

• MCP — use_mcp_tool·access_mcp_resource로 외부 MCP 서버의 도구·리소스를 끌어옵니다. 마켓플레이스(controller/marketplace)로 MCP 서버를 찾아 설치하는 흐름도 있습니다.
• 브라우저 — browser_action으로 헤드리스 브라우저를 띄워 클릭·입력·스크린샷을 합니다. 에이전트가 자기 변경을 웹에서 직접 확인할 수 있습니다.
• Skills — use_skill로 재사용 가능한 절차를 호출합니다. Superpowers에서 본 "지연 로딩되는 skill"과 같은 결입니다.
• Subagents — use_subagents로 서브에이전트를 띄웁니다(core/task/tools/subagent). 큰 작업을 좁은 권한의 보조 에이전트에 위임합니다.

13. CLI와 Kanban: 에디터 밖으로

Cline은 더 이상 VS Code 안에만 있지 않습니다.

• CLI (@cline/cli, npm i -g cline) — "터미널에서 Cline을 돌린다. 대화형 채팅 또는 CI/CD·스크립트용 완전 헤드리스." 7번에서 본 호스트 추상화 덕분에 가능합니다. CLI는 standalone 코어를 띄우고 ProtoBus로 대화합니다.
• Kanban (별도 저장소, npm i -g kanban) — 웹 작업 보드에서 여러 에이전트를 병렬로 돌립니다. 카드마다 자체 worktree, 자동 커밋, 의존성 체인을 갖춥니다.

즉 같은 코어가 세 가지 모습으로 나타납니다. 에디터 안의 짝꿍, 터미널의 헤드리스 일꾼, 보드 위의 병렬 일꾼입니다.

14. OpenCode와 비교: 같은 분리, 다른 무게중심

이 글의 출발점이 "OpenCode와의 대조"였으니 정리해 두겠습니다. 흥미롭게도 두 프로젝트는 같은 발상에서 출발합니다. 코어(엔진)를 프런트엔드·호스트에서 떼어내자는 것입니다. 다만 도구와 무게중심이 다릅니다.

요지는 이렇습니다. OpenCode는 "엔진을 어디에든 붙일 수 있게"에 무게를 싣고, Cline은 "사람이 에디터 안에서 믿고 맡길 수 있게"에 무게를 싣습니다. 둘 다 코어와 껍데기 사이에 타입이 있는 경계를 두지만, OpenCode는 그 경계를 네트워크 표준(HTTP)으로, Cline은 스키마 우선(protobuf)으로 그었습니다.

15. 코드를 읽는 추천 순서

1. README.md — CLI·Kanban까지 포함한 제품 전체 그림
2. apps/vscode/src/standalone/cline-core.ts — 코어가 호스트 없이 기동하는 방식
3. apps/vscode/src/hosts/host-provider.ts — 호스트 추상화의 진입점
4. apps/vscode/proto/cline/task.proto·state.proto — ProtoBus 서비스 계약
5. apps/vscode/src/shared/tools.ts — 도구 목록과 Plan/Act 도구
6. apps/vscode/src/core/controller/checkpoints — 체크포인트 구현
7. sdk/packages/llms/src/providers/vendors/ — provider 어댑터
8. apps/cli — 터미널에서 코어에 붙는 방식

16. 인상적인 설계 포인트

1. 코어와 호스트 사이에 스키마 경계를 둡니다.

23개의 .proto로 ProtoBus(코어↔UI)와 HostBridge(코어↔호스트)를 정의했습니다. 덕분에 코어는 VS Code를 몰라도 되고 새 호스트(CLI·다른 에디터)를 붙이는 일이 "호스트 구현 한 벌 추가"로 끝납니다.

2. 사람 승인을 프롬프트가 아니라 모드로 만듭니다.

Plan/Act가 plan_mode_respond·act_mode_respond라는 도구로 박혀 있습니다. "합의 먼저, 실행 나중"이 권고가 아니라 실행 경로입니다.

3. 되돌리기를 1급 기능으로 둡니다.

git 그림자 체크포인트로 매 단계를 스냅샷합니다. 사용자의 진짜 git을 건드리지 않으면서, 에이전트의 실험을 안전하게 되돌릴 안전망을 줍니다.

4. 모델을 데이터로 다룹니다.

vendor 어댑터 + model registry로 provider를 데이터처럼 관리합니다. OpenCode가 같은 일을 바깥(models.dev)에서 한다면, Cline은 안에서 합니다.

17. 주의해서 볼 지점

1. "IDE 전용"이라는 인상은 옛말입니다.

이름과 마켓플레이스 때문에 VS Code 전용으로 보이지만, 호스트 추상화·CLI·Kanban까지 보면 이미 에디터 밖으로 나왔습니다. 코드를 읽을 때 "지금 보는 게 코어인지 호스트 구현인지"를 먼저 구분해야 합니다.

2. gRPC/proto 파이프라인이 진입 장벽입니다.

23개 proto와 생성 코드, ProtoBus·HostBridge 두 채널은 강력하지만, 단순한 함수 호출보다 따라가기 어렵습니다. 흐름을 읽으려면 proto 정의부터 잡아야 합니다.

3. 승인은 안전하지만 마찰입니다.

매 행동 승인은 신뢰를 주는 대신 흐름을 끊습니다. 자동 승인 범위를 어떻게 설정하느냐가 실사용 경험을 크게 좌우합니다. 안전과 속도의 균형점을 사용자가 직접 정해야 합니다.

4. 저장소 곳곳에 VS Code의 흔적이 남아 있습니다.

코어를 떼어냈다지만, apps/vscode 아래에 코어가 있고 확장 이름도 claude-dev입니다. 호스트 분리는 진행 중인 방향이지 완결된 상태는 아니라고 읽는 편이 안전합니다.

18. 결론

Cline은 "VS Code용 AI 코딩 확장"보다 훨씬 큰 프로젝트입니다. 실제 구조는 코어를 호스트에서 떼어내고, 그 위에 사람의 승인과 되돌리기를 1급으로 올린 코딩 에이전트입니다.

OpenCode가 코어를 HTTP로 노출해 어디에든 붙일 수 있게 만든다면, Cline은 같은 분리를 protobuf/gRPC로 하면서 무게중심을 다른 곳에 둡니다. 에디터 안에서 사람이 매 행동을 승인하고, 마음에 들지 않으면 체크포인트로 되돌립니다.

Cline을 볼 때 가장 중요한 질문은 "어떤 모델을 쓰나요?"가 아닙니다. 더 중요한 질문은 이것입니다.

코딩 에이전트가 사용자의 진짜 작업 공간에서 일할 때, 그 신뢰를 어떤 구조로 만들어 내나요? 그리고 그 코어를 호스트에서 어떻게 떼어내야 한 벌로 에디터·터미널·보드를 다 덮을 수 있나요?

Cline의 답은 HostProvider와 23개의 proto, Plan/Act 승인과 git 그림자 체크포인트입니다. 이 경계들을 이해하면, Cline이 단순한 에디터 확장이 아니라 사람의 신뢰를 구조로 설계한 코딩 에이전트임을 알 수 있습니다.