TL;DR
- Cline 사용법의 특징은 승인이다. 파일을 읽고 쓰고 명령을 실행하는 모든 동작에 사용자의 명시적 승인이 필요하다.
- 확장 자체는 오픈소스이고 개인에게 무료다. 돈은 모델 추론에만 붙고, 자기 API 키를 쓰거나 자체 제공 경로를 고를 수 있다.
- 설치 경로가 넷이다. 에디터 확장, 터미널 CLI, 여러 에이전트를 보드로 관리하는 칸반, 그리고 SDK.
Cline 사용법을 알아보는 사람은 대개 이미 AI 코딩 도구를 하나쯤 써본 상태다.
그러다 두 가지가 걸린다.
구독료가 아깝거나, 도구가 무엇을 하는지 모르는 채로 파일이 바뀌는 게 불안하거나.
Cline은 두 지점을 정면으로 다룬다.
확장은 오픈소스로 무료이고 요금은 모델 사용량에만 붙는다.
그리고 모든 동작에 승인을 요구한다.
공식 자료 기준으로 설치가 800만 건을 넘겼고 깃허브 별이 6만 7천 개다.
아래는 설치 경로를 고르고 첫 작업을 시키는 순서, 승인 구조가 실제로 어떻게 작동하는지를 공식 문서 기준으로 정리한 것이다.
설치 경로가 넷으로 나뉜다
문서가 제시하는 설치 방식은 네 가지다.
자기 작업 방식에 맞는 걸 고르면 된다.
- IDE 확장: 에디터 안에서 쓴다. VS Code, Cursor, JetBrains, Windsurf, VSCodium 등을 지원한다.
- CLI: 터미널에서 쓴다.
npm i -g cline한 줄로 설치하고 맥·윈도우·리눅스에서 동작한다. - 칸반(미리보기): 여러 에이전트를 보드에서 관리한다. 동시에 여러 작업을 돌릴 때의 화면이다.
- SDK: 자기 제품에 붙여 넣는다.
@cline/sdk로 붙인다.
에디터 안에서 코드를 보며 작업하려면 첫 번째, 스크립트나 예약 작업에 넣으려면 두 번째다.
공식 홈은 CLI를 권장 경로로 표시한다.
Cline 사용법, 첫 작업까지의 순서
- 설치 경로를 고릅니다. 처음이라면 에디터 확장이 결과를 보기 쉽습니다.
- 확장을 설치하고 사이드바에서 엽니다.
- 모델 접근 방식을 정합니다. 자기 API 키를 넣거나 제공되는 경로를 쓰거나 둘 중 하나입니다.
- 작업할 프로젝트 폴더를 엽니다.
- 무엇을 할지 문장으로 설명합니다. 파일 이름을 구체적으로 적어주면 탐색 단계가 줄어듭니다.
- 제안된 동작을 하나씩 확인하고 승인합니다. 파일 수정, 명령 실행이 각각 확인을 거칩니다.
- 결과를 확인하고 필요하면 추가 지시를 줍니다.
6번이 이 도구의 성격이다.
다른 에이전트가 알아서 진행하고 결과만 보여주는 방식이라면, Cline은 매 단계에서 멈춰 묻는다.
처음에는 번거롭지만 무엇을 하는지 파악하는 데는 이쪽이 낫다.
승인 구조가 만드는 차이
공식 문서는 “모든 동작에 명시적 승인이 필요하다.
통제권은 항상 당신에게 있다”고 설명한다.
이게 마케팅 문구가 아니라 실제 동작 방식이다.
실무에서 의미가 큰 지점이 셋이다.
파일 수정: 어떤 파일을 어떻게 고칠지 보여주고 확인을 받는다.
예상하지 못한 파일이 목록에 들어오면 그 자리에서 막을 수 있다.
명령 실행: 터미널 명령을 실행하기 전에 무슨 명령인지 보여준다.
설치나 삭제처럼 되돌리기 어려운 명령을 걸러낼 수 있는 지점이다.
브라우저 사용: 웹을 열어 확인하는 동작도 승인 대상이다.
작업이 길어지면 승인 횟수가 늘어 피로해진다.
그래서 요청을 처음부터 좁게 주는 편이 낫다. “이 파일의 이 함수를 이렇게 고쳐줘”가 “버그 고쳐줘”보다 승인 횟수가 적다.
요금이 붙는 구조
Cline의 과금은 다른 도구와 방향이 다르다.
확장 자체는 오픈소스이고 개인 개발자에게 무료다.
공식 FAQ가 구독이 없고 벤더 종속이 없다고 명시한다.
돈이 나가는 건 모델 추론뿐이고, 방식이 둘로 나뉜다.
자기 API 키를 넣어 해당 제공사에 직접 내거나, Cline이 제공하는 경로로 사용량만큼 내는 방식이다.
정액 구독 옵션도 별도로 있다.
이 구조의 이점은 비용이 투명하다는 것이다.
얼마나 썼는지가 모델 제공사 대시보드에 그대로 남는다.
반대로 단점도 분명하다.
많이 쓰면 많이 나온다.
구독형이 주는 예측 가능성은 없다.
기업용 층에는 다른 항목이 붙는다.
SSO와 SLA, 전담 지원, 중앙 청구, 역할 기반 접근 제어, 사용 가능한 추론 제공사 제한, 팀 관리 대시보드, 인증 로그가 여기 있다.
조직에서 도입할 때 검토 대상이 되는 항목들이다.
오픈소스라는 점이 주는 것
소스가 공개돼 있다는 사실이 실무에서 몇 가지 차이를 만든다.
무엇을 보내는지 확인할 수 있다.
코드가 어디로 나가는지 민감한 조직이라면 이 점이 도입 판단의 근거가 된다.
공식 설명도 클라이언트 측 구조라는 점을 앞세운다.
확장도 가능하다.
MCP 마켓플레이스가 붙어 있어서 외부 도구를 에이전트에 연결할 수 있다.
여러 저장소를 한 작업 공간에서 다루는 구성도 지원한다.
블로그를 보면 이 팀이 오픈 가중치 모델 평가에 힘을 쓰는 것도 드러난다.
어떤 모델이 코딩 작업에서 얼마나 하는지 자체 평가를 공개하고, 그 결과를 모델 선택에 쓰라는 방향이다.
한계와 안 맞는 경우
- 승인 없이 알아서 끝내주길 바라는 경우. 이 도구의 설계 자체가 반대 방향이다.
- 비용 예측이 중요한 경우. 사용량 과금이라 작업량에 따라 요금이 움직인다.
- 모델 선택을 고민하고 싶지 않은 경우. 어떤 모델을 쓸지 스스로 정해야 한다.
- 아주 큰 저장소에서 맥락 없이 시작하는 경우. 관련 파일을 지정해주는 편이 결과가 낫다.
제품 만들 때 가져갈 설계
첫째는 무료의 경계를 도구와 추론으로 나눈 점이다.
도구는 열고 모델 비용만 받는다.
사용자가 “구독료를 왜 내는지” 묻지 않게 되고, 도구 자체의 채택은 빨라진다.
둘째는 승인을 기능이 아니라 기본값으로 둔 결정이다.
자동화 제품에서 통제권을 어디까지 넘길지는 취향 문제가 아니라 신뢰 문제다.
기본을 보수적으로 잡고 필요하면 완화하게 하는 순서가 안전하다.
셋째는 하나의 에이전트를 네 가지 표면으로 낸 방식이다.
에디터, 터미널, 보드, SDK가 같은 엔진을 쓴다.
사용자가 어디서 일하든 같은 도구를 만나게 하는 배치다.
실행 체크리스트
- 에디터에서 쓸지 터미널에서 쓸지 먼저 정합니다.
- 확장이나 CLI를 설치합니다.
- 모델 접근 방식을 정합니다. 자기 키를 쓸지 제공 경로를 쓸지 고릅니다.
- 첫 작업은 작은 범위로 시킵니다. 파일 이름을 구체적으로 지정합니다.
- 승인 화면에서 어떤 파일이 바뀌는지 확인하는 습관을 들입니다.
- 터미널 명령 승인 시 되돌릴 수 없는 명령인지 봅니다.
- 요청을 좁게 주어 승인 횟수를 줄입니다.
- 사용량 과금이므로 모델 대시보드에서 비용을 주기적으로 확인합니다.
- 팀 도입이면 SSO와 접근 제어가 있는 기업용 층을 검토합니다.
자주 묻는 질문
Cline은 무료인가요
오픈소스 확장은 개인 개발자에게 완전히 무료입니다.
구독이 없고 모델 추론 비용만 사용량 기준으로 나갑니다.
자기 API 키를 쓰거나 제공되는 경로를 쓸 수 있습니다.
어떤 에디터에서 쓸 수 있나요
VS Code, Cursor, JetBrains, Windsurf, VSCodium 등에서 확장으로 설치할 수 있습니다.
터미널용 CLI와 SDK도 따로 제공됩니다.
승인을 매번 해야 하나요
파일 수정과 명령 실행 같은 동작마다 명시적 승인을 받는 것이 기본 설계입니다.
요청 범위를 좁게 주면 승인 횟수가 줄어듭니다.
비용은 얼마나 나오나요
모델 사용량에 따라 달라집니다.
자기 API 키를 쓰면 해당 제공사 요금이 그대로 나오고, 사용량을 대시보드에서 확인할 수 있습니다.
정액 구독 옵션도 별도로 제공됩니다.
