이 글의 기술 정보는 2026년 4월 16일 기준으로 검증되었습니다. AI·LLM 분야는 변화가 빠르므로, 6개월 이상 경과 시 공식 문서를 재확인하세요.
이런 분이 읽으면 좋습니다
요약: Claude Code 데스크톱 앱이 2026년 4월 14일에 멀티 세션 사이드바, 드래그앤드롭 레이아웃, Side Chat, Routines 를 들고 리디자인됐다. CLI 에서 “하나 끝나면 다음” 식으로 작업하던 병목이 해소되지만, 50개 파일을 한 번에 고치는 대규모 실행에는 여전히 CLI 가 낫다. 둘 다 쓰되, 역할을 나눠라.
이 글은 Claude Code CLI 를 이미 써본 개발자가 데스크톱 앱으로 전환할지 판단하는 데 필요한 정보를 정리한다. Anthropic 의 공식 블로그 포스트와 릴리스 노트, 그리고 이 글을 쓰면서 직접 사용한 경험을 기반으로 한다. 2026년 4월 16일 기준이다.
무엇이 바뀌었나 — 핵심 5가지
1. 멀티 세션 사이드바
CLI 는 터미널 하나 = 세션 하나였다. tmux 나 탭을 열면 여러 세션을 돌릴 수 있지만, 각 세션의 상태(진행 중·완료·에러)를 한눈에 볼 수 없었다.
리디자인된 데스크톱 앱은 왼쪽 사이드바에 모든 세션을 표시한다. 상태별 필터, 프로젝트별 그룹핑이 되고, 세션 간 전환이 클릭 한 번이다. “프런트엔드 버그 수정” 세션이 에이전트를 돌리는 동안 “백엔드 API 리팩터링” 세션을 열어 리뷰하는 게 자연스러워졌다.
2. 드래그앤드롭 레이아웃
터미널, 프리뷰 팬, diff 뷰어, 채팅을 그리드로 자유 배치할 수 있다. CLI 에서는 코드 변경을 확인하려면 git diff 를 따로 치거나 에디터를 옆에 두고 전환해야 했는데, 데스크톱에서는 diff 뷰어와 채팅을 나란히 놓고 실시간으로 볼 수 있다.
실감이 큰 지점은 프리뷰 팬이다. HTML 파일, PDF, 로컬 개발 서버 화면을 앱 안에서 바로 확인할 수 있어서, 프런트엔드 작업 시 “변경 → 빌드 → 브라우저 전환 → 확인” 루프가 짧아진다.
3. Side Chat (⌘ + ; / Ctrl + ;)
이게 가장 체감이 큰 기능이다. 에이전트가 파일 20개를 수정하고 있는 도중에 “이 함수의 타입 시그니처가 맞는지” 같은 질문을 하고 싶을 때가 있다. CLI 에서는 두 가지 선택지가 있었다:
- 메인 세션에 질문을 던진다 → 에이전트의 컨텍스트가 오염되고, 진행 중인 작업이 중단될 수 있다
- 새 터미널을 열고
claude를 다시 실행한다 → 프로젝트 컨텍스트를 처음부터 로드해야 한다
Side Chat 은 메인 태스크의 컨텍스트를 읽되, 메인 히스토리에는 기록하지 않는 분기 대화를 연다. “읽기 전용 분기”라고 생각하면 된다. 메인 작업 흐름을 방해하지 않으면서 빠른 질문을 할 수 있다.
4. 인앱 도구 통합
- 파일 에디터: 작은 수정을 위해 VS Code 로 전환할 필요 없음
- diff 뷰어: 대규모 changeset 에 맞게 리빌드 — CLI 의 텍스트 diff 보다 가독성이 높다
- 통합 터미널: 테스트·빌드를 앱 안에서 바로 실행
- 3가지 뷰 모드: Verbose(모든 도구 호출 표시), Normal(요약), Summary(결과만) — CLI 에서는
--verbose플래그로만 조절할 수 있었던 걸 실시간 전환
5. Routines (리서치 프리뷰)
프롬프트 + 리포 + 커넥터를 묶어서 스케줄 또는 이벤트 트리거로 실행하는 자동화 단위다. 예를 들면:
- 매일 09:00: 어제 머지된 PR 의 코드 리뷰 요약을 Slack 에 게시
- PR 생성 시: 자동으로 테스트 실행 + 리뷰 코멘트 작성
- 주 1회: 의존성 업데이트 확인 + 보안 취약점 스캔
CLI 에서는 이런 자동화를 cron + 셸 스크립트 + GitHub Actions 조합으로 만들어야 했다. Routines 는 이걸 하나의 설정으로 통합한다. 현재 리서치 프리뷰이므로 프로덕션에 전면 적용하기는 이르지만, 방향성은 분명하다.
CLI 에서 불편했던 것 — 실무 페인포인트 4가지
”한 번에 하나” 병목
Claude Code CLI 는 한 터미널에서 하나의 태스크만 처리한다. 에이전트가 리팩터링을 실행하는 동안 30초~2분을 대기하는 시간이 누적되면, 하루에 30분 이상이 “기다림”으로 사라진다. tmux 탭을 여러 개 열 수 있지만, 각 탭의 상태를 기억하고 전환하는 인지 비용이 있다.
컨텍스트 오염
한 세션에서 “리팩터링 → 버그 발견 → 질문 → 다시 리팩터링”을 반복하면, 에이전트의 히스토리가 비대해지고 응답 품질이 떨어진다. 세션을 새로 열면 컨텍스트를 처음부터 로드해야 하니 프로젝트가 크면 2~3분이 걸린다.
시각적 피드백 부재
CLI 의 diff 출력은 터미널 폭에 맞춰 잘리고, 색상 지원이 터미널 에뮬레이터에 의존한다. 10개 파일에 걸친 변경을 리뷰할 때, CLI diff 로는 전체 그림을 잡기 어렵다. 대부분의 개발자가 변경 후 VS Code 의 Source Control 탭이나 git diff --stat 을 추가로 확인한다.
자동화 파편화
정기적인 작업(코드 리뷰·의존성 체크·성능 벤치마크)을 CLI 로 자동화하려면 cron, GitHub Actions, 셸 래퍼 스크립트를 각각 관리해야 한다. 프롬프트가 바뀌면 세 곳을 동시에 수정해야 하는 “동기화 지옥”이 생긴다.
데스크톱 앱이 해결하는 것
| CLI | 데스크톱 앱 | |
|---|---|---|
| 멀티 세션 | tmux/탭 수동 관리 | 사이드바 한눈에 관리 |
| 작업 중 질문 | 새 터미널 or 컨텍스트 오염 | Side Chat (⌘+;) |
| diff 리뷰 | 터미널 텍스트 diff | 리빌드된 시각적 diff 뷰어 |
| 프리뷰 | 별도 브라우저 전환 | 인앱 프리뷰 팬 |
| 자동화 | cron + Actions + 스크립트 | Routines 단일 설정 |
| 뷰 상세도 | --verbose 플래그 | Verbose/Normal/Summary 실시간 전환 |
여전히 CLI 가 나은 경우
1. 대규모 무인 실행. 에이전트에게 “이 리포 전체에서 deprecated API 를 교체하라”고 지시하고 30분 동안 다른 일을 할 때. CLI 는 가볍고 SSH 서버에서 돌리기 좋다. 데스크톱 앱은 GUI 리소스를 소비한다.
2. 셸 파이프라인 조합. claude --print "이 코드 리뷰해" | jq '.issues[]' | sort -k2 -rn 같은 파이프를 짤 때 CLI 의 stdin/stdout 이 훨씬 자연스럽다.
3. CI/CD 통합. GitHub Actions 워크플로우 안에서 claude 명령어를 직접 호출하는 경우. 데스크톱 앱은 CI 환경에서 돌릴 수 없다 — 여기는 CLI 또는 Routines 의 영역이다.
4. 리소스 제약 환경. 원격 서버에 SSH 로 접속해서 작업할 때. 데스크톱 앱은 로컬 GUI 가 필요하지만, CLI 는 어디서든 돌아간다.
전환 판단 기준
결론은 양쪽 다 쓰되 역할을 나누는 것이다.
- 코드 실행·생성이 주 작업 → CLI 유지. 에이전트가 파일을 고치고, 테스트를 돌리고, 커밋하는 “실행 루프”에서는 CLI 가 오버헤드 없이 빠르다.
- 리뷰·관리·멀티 태스크가 주 작업 → 데스크톱 전환. diff 리뷰, 여러 세션 동시 감독, 팀 공유에서는 시각적 도구가 생산성을 높인다.
- 정기 자동화가 필요 → Routines 를 시험. 아직 리서치 프리뷰이므로 크리티컬 워크플로우보다는 코드 리뷰 요약, 의존성 체크 같은 보조 태스크에 먼저 적용한다.
이 글을 쓰는 세션 자체가 CLI 로 진행됐다. Astro 프로젝트 스캐폴딩, 30개 파일 생성, Playwright 테스트 실행, Cloudflare Pages 배포까지 CLI 한 세션에서 처리했다. 하지만 중간에 “이 컴포넌트의 props 가 맞는지 확인하고 싶다” 같은 순간에는 Side Chat 이 있었으면 컨텍스트를 덜 오염시킬 수 있었을 것이다. 둘 다 필요하다.
피해야 할 상황
다음에 읽을 글
- RAG 파이프라인 설계: 청킹부터 검색 품질 모니터링까지 — Claude Code 로 RAG 시스템을 구축할 때의 아키텍처 판단
- LLM 구조화 출력: JSON 모드 vs 함수 호출 vs 제약 디코딩 — 에이전트의 출력 포맷을 제어하는 세 가지 방법
- 프로덕션 AI 서비스의 프롬프트 버전 관리 — Routines 에 넣을 프롬프트를 어떻게 버전 관리할 것인가