Claude Code는 어디서 실행해야 할까 — 답은 "얼마나 위임할 것인가"에 있다

세 줄 요약

Claude Code는 터미널, VS Code, 데스크탑 앱, 웹, 모바일 어디서든 같은 엔진으로 돌고, 설정도 공유된다. 그래서 인터페이스 선택의 진짜 기준은 기능표가 아니라 작업을 얼마나 위임할 것인가다.

한 줄씩 같이 보면 IDE 확장, 옆에서 감독하면 터미널 CLI, 여러 작업을 병렬로 관리하면 데스크탑 앱, 위임하고 잊으면 웹에서 여는 클라우드 세션이 맞는다.

토큰 비용도 같은 기준을 따라 움직인다. 많이 위임할수록 Claude가 스스로 검증하는 횟수가 늘고, 그 검증이 곧 토큰 소모다.

Claude Code를 실행할 수 있는 곳이 너무 많아졌다. 터미널 CLI, VS Code 확장 프로그램, JetBrains 플러그인, 데스크탑 앱, 웹, 모바일. 여기에 orca나 cmux 같은 서드파티 도구까지 더하면 선택지는 더 늘어난다.

잘못 고르면 대가가 있다. 필요한 기능이 없어 작업 중간에 갈아타거나, 반대로 쓰지도 않는 자동 기능이 토큰을 소모한다. 그래서 다들 어디에 정착할지 고민한다.

그런데 기능표를 아무리 비교해도 답이 안 나온다. 이유가 있다. 공식 문서가 명시하듯 "Claude Code는 어디에서나 같은 엔진으로 동작"한다. CLAUDE.md와 권한 규칙, MCP 서버, 스킬 설정도 로컬 인터페이스 전체에 공유된다. (Platforms and integrations, Desktop — Shared configuration)

엔진도 설정도 같다면, 무엇이 다른가. 인터페이스마다 다른 건 사람이 개입하는 방식과 빈도다. 그래서 물어야 할 질문은 "어디서 실행할까"가 아니라 이 작업을 Claude에게 얼마나 위임할 것인가다.

이 위임 정도가 이 글 전체를 관통하는 기준이다. 위임이 낮으면 사람이 옆에서 감독하고 자주 개입하고, 위임이 높으면 그 반대다.

위임 정도로 보면 여섯 인터페이스가 하나의 스펙트럼 위에 깔끔하게 늘어서고, 토큰 비용까지 같은 기준으로 설명된다.

위임 스펙트럼 — 인터페이스는 위임 정도 순으로 늘어선다

단계	이 단계에서 하는 일	인터페이스	이런 작업
1	페어 프로그래밍 — 한 줄씩 같이 본다	VS Code, JetBrains 확장	익숙하지 않은 코드 수정, 민감한 변경, 배우면서 하는 작업
2	옆자리 감독 — 방향만 잡고 지켜본다	터미널 CLI	일상 개발, 자동화, 원격 서버 작업
3	병렬 관리 — 여러 세션의 결과를 돌아가며 검토한다	데스크탑 앱	독립적인 작업 여러 개를 동시에 진행
4	위임 — 맡기고 잊는다	클라우드 세션(웹)	대규모 리팩터링, 마이그레이션, 퇴근 후에도 돌아갈 작업
원격	밖에서 확인 — 스펙트럼 전체를 폰에서 조작	모바일 앱	자리를 비웠을 때 시작, 확인, 방향 수정

이 스펙트럼이 임의의 분류가 아니라는 근거가 있다. Claude Code의 권한 모드가 정확히 같은 방향으로 설계되어 있다.

Manual(모든 변경을 승인) → Accept edits(파일 수정 자동 승인) → Auto(백그라운드 안전 검사로 모든 동작을 실행) → Bypass(승인 생략) 순으로 개입이 줄어드는데, 각 인터페이스의 기본값이 이 순서와 맞물린다.

VS Code 확장은 인라인 diff로 변경을 하나씩 승인하는 흐름을 갖췄고, 클라우드 세션은 아예 Manual 모드가 없다. 파일 수정이 사전 승인된 상태로 시작한다. (Permission modes, Desktop — Choose a permission mode)

위임 정도가 올라갈수록 사람의 승인이 줄어든다. 그러면 그 빈자리를 무엇이 채우는가. Claude가 스스로 하는 검증이다.

공식 모범 사례 문서의 첫 항목은 "Claude에게 자기 작업을 검증할 수단을 주라"다. (Best practices) 인터페이스마다 제공하는 검증 수단이 다르고, 사실 그것이 인터페이스의 본질적 차이다. 단계별로 보자.

1단계. 페어 프로그래밍 — IDE 확장

어떤 작업인가. 코드를 내가 직접 읽고 이해하면서 옆에서 도움받는 작업. 변경 하나하나를 눈으로 확인해야 하는 민감한 코드, 아직 파악 중인 코드베이스가 여기에 해당한다.

왜 IDE인가. 검증의 주체가 사람이기 때문이다. VS Code 확장은 사람이 최대한 빠르게 검토하도록 돕는 데 집중한다. 변경 제안이 네이티브 diff 뷰어로 열리고, 계획 모드에서는 계획이 마크다운 문서로 열려 인라인 주석으로 피드백을 달 수 있다. 편집기에서 선택한 텍스트는 Claude에게 자동으로 보이고, Option+K로 @파일#5-10 형태의 줄 범위 참조를 넣을 수 있다. (VS Code)

Claude의 검증 수단. 언어 서버 진단이다. 확장이 내장한 IDE MCP 서버를 통해 Claude가 VS Code 문제 패널의 오류와 경고를 직접 조회한다. 컴파일러를 돌리지 않고도 타입 오류를 아는 셈이다. (VS Code — The built-in IDE MCP server)

알아둘 제약. 명령과 스킬은 CLI의 일부만 지원하고, MCP 서버 추가는 CLI에서 해야 한다. ! bash 단축과 탭 완성이 없고, 백그라운드 작업 가시성에 대해서는 공식 문서 스스로 "CLI에 비해 제한적"이라고 적는다. (VS Code extension vs. Claude Code CLI)

이 단계의 토큰. 스펙트럼에서 가장 예측 가능한 구간이다. 사람이 검증을 맡으니 자동 검증 호출이 없다. 대신 매 프롬프트에는 현재 선택 영역과 열린 파일 경로가 문맥으로 함께 실린다. 민감한 파일은 Read 거부 규칙으로 제외할 수 있다.

사용량 가시성은 이 단계에서 가장 좋다. /usage가 스킬, 하위 에이전트, MCP 서버별 사용량 귀속을 표로 보여주고, 캐시 미스 같은 요인이 전체의 10%를 넘으면 경고와 절감 팁을 띄운다. (VS Code — Check account and usage)

2단계. 옆자리 감독 — 터미널 CLI

어떤 작업인가. 방향은 내가 잡되 실행은 맡기는 일상 개발. 그리고 사람이 아예 개입할 수 없는 자동화 영역 전체.

왜 CLI인가. 공식 문서가 CLI를 "가장 완전한 인터페이스"로 규정하는 이유는 위임의 양 극단을 모두 다루기 때문이다. 대화형으로 지켜보다가 Esc 키로 즉시 개입할 수도 있고, --print 플래그로 비대화형으로 실행해 CI 파이프라인에 붙일 수도 있다. 다음 기능은 CLI에만 있다. (Platforms, Desktop — What's not available)

스크립트 실행(--print)과 Agent SDK
에이전트 팀 — 팀장 Claude가 팀원 인스턴스에 작업을 배분
dontAsk 권한 모드 — 사전 승인된 도구만 허용

여기에 더해 Amazon Bedrock, Google Cloud Agent Platform, Microsoft Foundry 같은 서드파티 모델 제공자 연결은 CLI와 IDE 확장(VS Code, JetBrains)에서 지원한다. 데스크탑은 기본적으로 Anthropic API로 연결된다.

Claude의 검증 수단. 테스트, 빌드 스크립트, 훅이다. 사람의 눈 대신 실행 결과가 검증한다. 공식 모범 사례가 권하는 "검증 목표를 함께 주기"(테스트 케이스, 기대 출력 명시)가 가장 잘 작동하는 환경이기도 하다.

알아둘 제약. 시각 검토 기능이 없고, 큰 표가 터미널 폭에 맞지 않아 잘리는 문제는 공식 트러블슈팅 문서에 등재된 항목이다. (Troubleshooting)

이 단계의 토큰. 기본값 기준으로는 부가 기능이 가장 적게 붙는다.

하지만 이 단계에는 스펙트럼 전체에서 가장 비싼 선택지도 함께 있다. 에이전트 팀이다. 팀원이 계획 모드로 돌 때 일반 세션 대비 약 7배의 토큰을 쓴다는 수치가 공식 문서에 명시되어 있다. 팀원 하나하나가 독립된 컨텍스트 창을 가진 별도 인스턴스이기 때문이다. (Manage costs — Agent team token costs)

같은 인터페이스 안에서도 "얼마나 위임하느냐"가 비용에 차이를 만든다는 사실을 이 숫자가 보여준다.

3단계. 병렬 관리 — 데스크탑 앱

어떤 작업인가. 독립적인 작업 여러 개를 동시에 돌리고, 각각의 결과를 돌아가며 검토하는 방식. 개별 작업에는 덜 붙어 있는 대신 전체를 관리한다.

왜 데스크탑인가. 병렬 관리에 필요한 격리와 검토 도구가 기본 장착이다.

자동 worktree 격리: 새 세션마다 git worktree로 격리된 사본이 자동 생성된다. 세션끼리 같은 파일을 동시에 건드리지 않는다. CLI에서 --worktree 플래그로 직접 하던 일이다. (Desktop — Work in parallel with sessions)
diff 뷰와 줄 단위 주석: 변경 파일을 훑으며 특정 줄에 의견을 달면 Claude가 반영한다.
보기 모드 전환: 여러 세션을 돌릴 때는 Summary 모드로 결과만 훑고, 왜 그렇게 했는지 따질 때만 Verbose로 내려간다.
세션 간 소통: "어느 세션이 인증 리팩터링을 건드렸지"라고 물으면 Claude가 다른 세션들의 진행 상황을 읽고 답하고, 세션 사이에 메시지도 전달한다.

Claude의 검증 수단. 이 단계의 핵심이자, 데스크탑이 토큰을 더 쓰게 되는 이유다. 사람이 세션 하나에 붙어 있지 않으니 Claude가 브라우저로 직접 검증한다.

자동 검증(autoVerify)이 기본으로 켜져 있다. 파일을 수정할 때마다 개발 서버 화면을 스크린샷으로 찍고, DOM을 검사하고, 요소를 클릭해 확인하고, 발견한 문제를 고친다. iOS 앱이라면 전용 시뮬레이터 창에서 같은 일을 한다.

PR을 만들면 CI 상태를 추적해 실패한 검사를 자동으로 고치는 Auto-fix로 이어진다. (Desktop — Auto-verify changes, Preview your app)

알아둘 제약. --print 기반 스크립팅과 에이전트 팀이 없고, 서드파티 모델 제공자는 별도 배포판이나 게이트웨이 경유가 필요하다. /permissions처럼 터미널 대화상자를 여는 명령은 동작하지 않아 설정 파일을 직접 편집해야 한다.

이 단계의 토큰. 데스크탑에서 사용량이 빨리 찬다면 원인은 화면 출력이 아니라 위의 검증 동작이다. 검증 하나하나가 도구 호출이고 그 결과가 컨텍스트에 쌓인다. 병렬 세션은 세션 수만큼 독립 컨텍스트를 키운다. 확장 사고(extended thinking)도 기본으로 켜져 있어 모델에 따라 사고 분량이 요청당 수만 토큰까지 출력 토큰으로 과금된다.

중요한 건 이 소모가 낭비가 아니라 검증 품질과 맞바꾼 비용이라는 점이다. 자동 검증이 사람이 직접 확인하고 다시 요청하는 과정을 줄여준다면 총 사용량은 오히려 줄 수 있다. 필요 없으면 프로젝트의 .claude/launch.json에서 "autoVerify": false로 끈다.

4단계. 위임 — 클라우드 세션(웹)

어떤 작업인가. 개입이 거의 필요 없는 큰 작업. 대규모 마이그레이션, 테스트 스위트 정비, 자는 동안 돌아야 하는 일.

왜 클라우드인가. Anthropic이 관리하는 인프라에서 돌기 때문에 앱을 닫아도, 컴퓨터를 꺼도 계속 실행된다. 데스크탑에서 환경을 Cloud로 고르거나 claude.ai/code에서 시작한다. 여러 저장소를 한 세션에 붙여 공유 라이브러리와 그것을 쓰는 저장소를 함께 고치는 작업도 된다. (Claude Code on the web, Desktop — Run long-running tasks remotely)

권한 구조가 이 단계의 성격을 그대로 보여준다. 클라우드 세션에는 Manual 모드가 없다. 파일 수정이 사전 승인된 상태로 시작하고, 반대로 Bypass 모드는 지원하지 않는다. 위임하되 안전장치는 유지하는 설계다.

Claude의 검증 수단. CI다. PR 리뷰 코멘트와 CI 실패에 Claude가 반응해 스스로 고친다.

이 단계의 토큰. 클라우드 세션 사용량은 구독 플랜 한도에 합산되며 별도의 컴퓨팅 요금은 없다. 대신 위임 작업 특성상 세션이 길어지므로, 긴 세션의 비용 구조를 알아야 한다. 바로 아래에서 다룬다.

원격 계층 — 모바일. 모바일 앱은 스펙트럼의 다섯 번째 단계가 아니라, 스펙트럼 전체를 밖에서 조작하는 계층이다. 클라우드 세션을 시작하고 모니터링한다. Remote Control로는 집 컴퓨터에서 돌던 로컬 세션을 폰에서 이어서 조종하고, Dispatch로 보낸 작업은 데스크탑 세션으로 만들어진다. (Mobile, Remote Control)

자율성의 가격 — 토큰은 검증 비용이다

여기까지 보면 토큰 이야기가 정리된다. 먼저 팩트 하나. 인터페이스별 토큰 사용량을 직접 비교한 공식 지표는 없다. "데스크탑이 CLI보다 몇 % 더 쓴다" 같은 숫자는 공식 문서에 존재하지 않는다.

대신 공식 문서의 수치들을 위임 스펙트럼 위에 놓으면 일관된 패턴이 나온다. 많이 위임할수록 검증이 자동화되고, 자동화된 검증이 토큰을 쓴다.

위임 정도	무엇이 늘어나는가	공식 근거
페어 프로그래밍	선택 영역과 열린 파일이 매 프롬프트에 포함	IDE MCP 서버
병렬 관리	수정마다 스크린샷과 DOM 검사, 세션 수만큼 컨텍스트	autoVerify
에이전트 팀	팀원마다 독립 인스턴스, 일반 세션의 약 7배	Agent team token costs
유휴 세션	백그라운드 요약 등 세션당 보통 0.04달러 미만	Background token usage

지출 규모를 가늠할 공식 수치도 있다. Anthropic이 비용 문서에 공개한 기업 배포 집계로, 개발자 1인당 하루 평균 약 13달러, 월 150~250달러, 사용자의 90%는 활동일 기준 하루 30달러 아래다. (Manage costs)

그리고 어느 단계에서든 비용을 최종 결정하는 것은 인터페이스가 아니라 컨텍스트 크기다. Claude Code는 매 요청마다 전체 대화를 다시 보내므로, 하루 종일 열어둔 세션에서는 한 줄 질문도 대화 전체 분량의 사용량을 만든다.

프롬프트 캐시가 이를 완화하지만 수명이 있다. 구독 계정 1시간, API 키 기본 5분. 휴식 후 첫 메시지는 캐시를 놓쳐 전체 컨텍스트를 재처리한다. (Why usage climbs in a long session, Prompt caching)

그래서 절감의 핵심은 어디서 실행하든 같다.

작업 전환 시 /clear — 남은 컨텍스트는 이후 모든 메시지에 비용을 더한다
모델을 작업에 맞추기 — 대부분의 코딩은 Sonnet, Opus는 복잡한 설계 판단에
장황한 작업은 하위 에이전트로 — 테스트 실행과 로그 분석은 별도 컨텍스트에서 돌리고 요약만 받기
훅으로 전처리 — 1만 줄 로그 대신 오류 줄만 걸러 넘기면 수만 토큰이 수백 토큰이 된다
CLAUDE.md는 200줄 아래로 — 본문 전체가 매 요청에 실리는 유일한 설정이다. 상세 지침은 필요할 때만 로드되는 스킬로 옮긴다 (Context cost by feature)

측정은 세 명령이면 된다. /usage(사용량 귀속과 행동 경고), /context(지금 컨텍스트를 무엇이 차지하는지), /insights(최근 세션의 작업 패턴 리포트).

하나만 고를 필요는 없다 — 작업에 따라 옮겨 다니기

위임 정도는 작업마다 다를 뿐 아니라, 한 작업 안에서도 변한다. 처음에는 붙어서 방향을 잡고, 궤도에 오르면 맡기고, 막히면 다시 붙는다. Claude Code는 이 이동을 위한 공식 경로를 전부 갖추고 있다.

이동	방법	상황
CLI → 데스크탑	`/desktop` 명령	터미널로 시작한 작업의 변경량이 커져 시각 검토가 필요할 때
데스크탑 → 클라우드	Continue in 메뉴	궤도에 오른 작업을 맡기고 퇴근할 때. 브랜치를 푸시하고 대화 요약과 함께 클라우드 세션 생성
클라우드 → 터미널	`--teleport`	위임한 작업이 막혀 직접 개입해야 할 때
클라우드 → VS Code	세션 기록의 Web 탭	클라우드 세션 대화를 내려받아 로컬에서 이어가기
VS Code 확장과 CLI 양방향	`claude --resume`	대화 기록을 공유하므로 어느 쪽에서든 이어짐
밖 → 로컬 세션	Remote Control	자리를 비운 사이 진행 중인 세션을 폰이나 브라우저에서 조종
폰 → 데스크탑	Dispatch	이동 중에 떠오른 작업을 집이나 사무실 데스크탑에 맡길 때

하루의 흐름으로 그리면 이렇다. 아침 출근길에 폰으로 클라우드 세션을 시작한다. 자리에 앉아 데스크탑에서 diff를 검토하고 방향을 수정한다. 까다로운 부분은 --teleport로 터미널에 가져와 직접 붙는다. 해결되면 Continue in으로 다시 클라우드에 넘기고 퇴근한다. 밤에 알림이 오면 폰에서 확인만 한다.

인터페이스를 고르는 게 아니라, 작업의 위임 정도가 변할 때마다 스펙트럼 위를 옮겨 다니는 것이다. 설정과 프로젝트 메모리가 공유되기에 가능한 그림이다.

스펙트럼을 더 넓히고 싶다면 — orca와 cmux

3단계의 병렬 관리를 공식 기능 너머로 확장하는 서드파티 도구들이 있다. 둘 다 Anthropic과 무관한 오픈소스라는 점을 먼저 밝혀둔다.

orca (github.com/stablyai/orca)는 Stably AI의 에이전트 개발 환경이다. Claude Code뿐 아니라 Codex, OpenCode 등 30여 종의 코딩 에이전트를 각자 격리된 worktree에서 나란히 돌린다. 같은 프롬프트를 여러 에이전트에 동시에 던져 결과를 비교하고 나은 쪽을 병합하는 흐름이 특징이고, 트래픽을 자체 서버로 중계하지 않아 기존 구독을 그대로 쓴다. 데스크탑 앱의 병렬 관리를 "에이전트 종류까지 병렬"로 확장한 셈이다.

cmux (cmux.com)는 macOS 네이티브 터미널 앱이다. Ghostty 렌더링 엔진 위에 세로 탭, 에이전트가 입력을 기다릴 때 울리는 알림, 세션 복원을 구현했다. 여러 CLI 세션을 돌릴 때 "어느 탭이 지금 나를 기다리는가"라는 2단계의 감독 문제를 푸는 도구다. 같은 이름의 별개 프로젝트인 craigsc/cmux(worktree 생성과 정리를 명령 하나로 감싸는 CLI)와 혼동하지 않도록 주의한다.

도입 전에 공식 기능을 먼저 확인하길 권한다. 최근의 Claude Code는 자동 worktree 격리, 터미널에서 여러 세션을 감독하는 agent view, 세션 간 메시지 전달, 스크립트 하나로 다수 하위 에이전트를 돌리는 동적 워크플로까지 병렬 기능을 자체적으로 갖췄다. (Agents and parallel work) 서드파티의 가치는 여러 종류의 에이전트를 섞거나 터미널 환경 자체를 바꾸고 싶을 때 커진다.

토큰 관점에서 이 도구들은 중립이다. 세션을 더 많이, 더 편하게 돌리게 해줄 뿐 세션 하나의 소모 구조는 그대로다. 병렬 세션 다섯 개는 어느 도구에서든 컨텍스트 다섯 개다.

자주 묻는 질문

Q. Claude Code는 CLI와 데스크탑 앱 중 어느 쪽이 좋은가?

작업을 얼마나 위임할지로 정한다. 방향을 잡으며 지켜보는 단일 작업과 자동화는 CLI, 여러 작업을 병렬로 돌리며 시각적으로 검토하는 방식은 데스크탑이다. 공식 문서의 권장 기준도 같다. 스크립팅이 필요하면 CLI, 병렬 세션 관리와 시각 검토가 필요하면 데스크탑. (Desktop — Coming from the CLI)

Q. 데스크탑 앱은 토큰을 더 소모하나?

인터페이스별 공식 비교 지표는 없다. 다만 데스크탑은 자동 검증(수정마다 스크린샷과 DOM 검사)과 확장 사고가 기본으로 켜져 있고 병렬 세션이 세션 수만큼 컨텍스트를 키우므로, 같은 작업이라도 검증 호출만큼 사용량이 더 잡힐 수 있다. 자동 검증은 .claude/launch.json에서 끌 수 있다.

Q. VS Code 확장만 설치하면 CLI는 필요 없나?

대화창만 쓴다면 필요 없다. 확장이 CLI 사본을 내장하고 있다. 다만 통합 터미널에서 claude 명령을 쓰거나 MCP 서버를 추가하려면 CLI를 별도로 설치해야 한다. (VS Code — Prerequisites)

Q. 인터페이스를 옮기면 설정을 다시 해야 하나?

아니다. CLAUDE.md, ~/.claude/settings.json의 권한 규칙, MCP 서버, 훅, 스킬이 로컬 인터페이스 전체에 공유된다. 대화도 이동 가능하다. CLI 세션은 /desktop으로 데스크탑에, 확장 대화는 claude --resume으로 CLI에 이어진다.

Q. 토큰을 아끼려면 어떤 인터페이스를 골라야 하나?

인터페이스보다 습관이 결정한다. 작업 전환 시 /clear, 작업에 맞는 모델 선택, CLAUDE.md 200줄 유지, 장황한 작업의 하위 에이전트 위임이 어느 인터페이스에서든 가장 큰 차이를 만든다. (Reduce token usage)