Claude Code Ultra Plan 살펴보기: 로컬 CLI를 넘어 클라우드에서 계획을 세우는 방식

Claude Code를 조금만 써도 금방 드러나는 패턴이 있습니다.
짧은 수정이나 단순 생성은 잘하는데, 일이 커질수록 코딩보다 계획이 더 중요해진다는 점입니다.

여러 컴포넌트가 얽히고 구조를 바꾸고 선택지를 비교해야 할 때, “바로 구현”은 생각보다 자주 실패합니다.
에이전트가 엇나가는 원인도, 구현 능력보다 계획 없이 너무 빨리 들어간 경우가 많습니다.

그 지점을 겨냥한 기능이 Ultra Plan입니다.

이름만 보면 “더 오래 생각하는 모드”처럼 들리기 쉽습니다.
다만 공식 설명에 가깝게 보면, Ultra Plan은 추론 시간을 늘리는 옵션이라기보다 로컬 CLI에서 시작한 planning을 Claude Code on the web ↗의 plan mode ↗ 세션으로 넘겨 클라우드에서 초안을 잡고, 브라우저에서 검토한 뒤 실행 위치를 고르는 handoff에 가깝습니다.

공식 문서의 제품명은 Ultraplan(한 단어)이고, CLI에서는 /ultraplan으로 시작합니다. 이 글에서는 읽기 통일을 위해 Ultra Plan이라고 부릅니다.

흥미로운 점은, 모델을 한순간에 똑똑하게 만든다기보다 일의 순서를 바로잡으려는 제품 설계로 읽힌다는 것입니다.

Ultra Plan은 무엇인가요?

Anthropic 공식 설명을 한 문장으로 옮기면 이렇습니다. CLI에서 plan을 시작하고, 웹의 Claude Code에서 초안을 다듾은 다음, 원격(웹)이나 다시 터미널에서 실행한다는 흐름입니다. (공식 문서 ↗)

현재는 연구 프리뷰(research preview)이며, Claude Code v2.1.91 이상이 필요하고 동작은 피드백에 따라 바뀔 수 있다고 명시되어 있습니다.

전제 조건도 문서에 분명합니다. Claude Code on the web ↗ 계정과 GitHub 저장소가 필요합니다. 클라우드 인프라에서 돌아가기 때문에 Amazon Bedrock, Google Cloud Vertex AI, Microsoft Foundry로 Claude Code를 쓰는 환경에서는 Ultraplan을 쓸 수 없습니다. 계정의 기본 cloud environment에서 세션이 실행되며, 아직 환경이 없으면 첫 실행 시 자동으로 만들어집니다.

한 줄로 정리하면 이렇습니다.

시작은 로컬 CLI
설계·계획이 무거운 작업은 클라우드/웹 plan session으로 이어짐
터미널을 길게 붙잡지 않음
계획을 검토한 뒤 실행 흐름으로 다시 연결

즉, “한 번 더 깊게 생각해” 수준이 아니라 planning 작업을 별도 환경으로 분리하는 쪽에 가깝습니다.

그래서 “추론 강화”와는 결이 다릅니다.

왜 이 기능이 중요한가요?

코딩 에이전트를 실제로 많이 써본 사람이라면, 구현보다 계획이 더 어려운 순간이 자주 온다는 걸 알 겁니다.

예를 들면 이런 상황입니다.

어떤 구조로 리팩터링할지 정해야 할 때
큰 기능을 어떻게 나눠서 구현할지 고민할 때
여러 선택지를 비교해야 할 때
레거시 코드 영향 범위를 먼저 파악해야 할 때
팀과 공유할 설계 초안이 필요할 때

이런 일은 “코드를 잘 쓰는 모델”만으로 잘 해결되지 않습니다.
오히려 중요한 건 다음입니다.

더 큰 맥락을 붙잡기
구조적으로 정리하기
선택지를 비교하기
실행 가능한 계획으로 바꾸기

Ultra Plan은 바로 이 영역을 겨냥합니다.
즉, Claude Code를 즉답형 코딩 도우미에서 조금 더 나아가 계획형 개발 파트너 쪽으로 밀어주는 기능이라고 볼 수 있습니다.

“더 오래 생각한다”보다 “계획을 분리한다”가 핵심입니다

Ultra Plan을 설명할 때 흔히 “deep planning”, “longer reasoning”, “think longer” 같은 표현이 붙습니다.
완전히 틀린 말은 아니지만, 핵심을 충분히 설명하진 못합니다.

진짜 포인트는 생각 시간을 늘리는 게 아니라,
계획 작업을 따로 떼어낸다는 데 있습니다.

flowchart TB
    A["로컬 CLI<br/>planning 시작"]
    B["Ultraplan<br/>handoff"]
    C["웹 plan mode<br/>클라우드 초안"]
    D["브라우저에서<br/>검토·수정"]
    E["웹에서 구현·PR"]
    F["터미널로<br/>teleport"]
    A --> B --> C --> D
    D --> E
    D --> F

이 구조가 의미 있는 이유는 공식 문서가 강조하는 방향과 맞닿습니다.

구간 단위 피드백: 계획 전체에 한 번에 답하기보다, 섹션·문단에 코멘트를 달아 다듬기 쉬움
터미널 부담 감소: 초안 작성은 클라우드에서 진행되고, 로컬은 다른 작업에 쓸 수 있음
실행 위치 선택: 같은 초안을 웹에서 이어 구현할지, 승인 뒤 터미널로 되돌릴지 고를 수 있음

그래서 Ultra Plan은 “생각을 더 많이 하게 한다”기보다 planning 워크플로우를 재배치한 기능에 가깝습니다.

왜 굳이 클라우드에서 계획을 세우게 할까

CLI만으로 끝내지 않고 웹·클라우드로 넘기는 이유를 나눠 보면 이렇습니다.

1. 터미널을 덜 막기 위해

긴 planning이 시작되면 CLI는 쉽게 “붙잡힌 느낌”을 줍니다.
사용자는 그동안 다른 걸 하고 싶을 수도 있습니다.
계획이 무거워질수록 이 문제는 더 커집니다.

2. 더 큰 planning UX를 만들기 위해

복잡한 계획은 단순한 터미널 출력보다 웹 UI에서 더 잘 다룰 수 있습니다.
섹션 구조, 검토 흐름, 수정, 재정리 같은 작업은 웹 쪽이 훨씬 자연스럽습니다.

3. 계획과 실행을 분리하기 위해

가장 본질에 가깝습니다.
계획과 구현은 같은 종류의 작업이 아니고, Ultra Plan은 둘을 한 세션에 섞지 않고 단계를 나누려는 설계로 읽힙니다.

에이전트가 계획과 실행을 너무 빨리 뒤섞는 문제를, 제품 차원에서 줄이려는 시도라고 볼 수 있습니다.

CLI에서 어떻게 시작하나

문서에 따르면 시작 경로는 세 가지입니다.

/ultraplan 뒤에 원하는 작업을 프롬프트로 넣기 (예: /ultraplan migrate the auth service from sessions to JWTs)
일반 프롬프트 아무 곳에나 **ultraplan**이라는 단어를 넣기
로컬에서 plan을 마친 뒤 뜨는 승인 대화에서 **「No, refine with Ultraplan on Claude Code on the web」**을 고르기

1·2번은 시작 전 확인 대화가 한 번 더 뜨고, 3번은 그 선택 자체가 확인 역할이라 대화가 생략됩니다.

Remote Control을 쓰고 있다면 Ultraplan이 시작될 때 연결이 끊깁니다. 두 기능이 같은 claude.ai/code 인터페이스를 점유하기 때문에 동시에 연결할 수 없다는 설명입니다.

터미널에 보이는 상태 표시

원격 세션이 돌아가는 동안 입력 줄 근처에 상태가 뜹니다.

표시	의미
`◇ ultraplan`	코드베이스를 조사하며 계획 초안을 작성 중
`◇ ultraplan needs your input`	추가로 확인할 질문이 있음 — 세션 링크를 열어 응답
`◆ ultraplan ready`	브라우저에서 계획을 검토할 수 있음

/tasks에서 ultraplan 항목을 고르면 세션 링크, 에이전트 활동, Stop ultraplan이 보입니다. 중지하면 클라우드 세션이 아카이브되고 터미널 표시도 사라지며, 문서 기준으로는 그 중지 동작만으로 터미널에 무언가 저장되지는 않습니다.

브라우저에서 검토하고, 어디서 실행할지 고르기

◆ ultraplan ready가 되면 링크로 들어가 전용 검토 화면에서 계획을 봅니다. 문서에 나온 UI 요소는 대략 다음과 같습니다.

인라인 코멘트: 구절을 하이라이트하고 Claude가 반영할 피드백을 남김
이모지 반응: 긴 글 없이 섹션 단위로 동의·우려 표시
아웃라인 사이드바: 섹션 사이를 빠르게 이동

코멘트를 주면 계획이 수정된 초안으로 다시 올라오고, 만족할 때까지 반복할 수 있습니다.

실행은 두 갈래

웹에서 이어가기
**「Approve Claude’s plan and start coding」**을 고르면 같은 웹 세션에서 구현이 시작됩니다. 터미널에는 확인만 뜨고 상태 표시는 정리되고, 끝나면 웹에서 diff를 검토한 뒤 PR을 만드는 식의 흐름으로 이어집니다.

터미널로 되돌리기
**「Approve plan and teleport back to terminal」**은 CLI에서 Ultraplan을 시작했고 터미널이 아직 폴링 중일 때 선택할 수 있습니다. 웹 세션은 아카이브되어 웹과 로컬이 동시에 같은 일을 계속하지 않도록 막힙니다.

터미널에는 「Ultraplan approved」 대화상자가 뜨고, 선택지는 세 가지입니다.

Implement here: 지금 대화에 계획을 주입해 이어서 구현
Start new session: 대화를 비우고 계획만 컨텍스트로 새 세션 시작 (이전 대화로 돌아올 claude --resume 명령이 출력됨)
Cancel: 실행 없이 파일로만 저장 — Claude가 저장 경로를 출력

실제 개발 워크플로우에서는 언제 유용할까

모든 작업에 켤 필요는 없고, 짧은 수정에는 오히려 무겁게 느껴질 수 있습니다.

아래처럼 “먼저 정리할 일”이 클 때가 잘 맞습니다.

1. 리팩터링 전 설계 정리

바로 코드를 건드리기 전에, 영향 범위와 작업 순서를 먼저 잡고 싶을 때 유용합니다.

2. 큰 기능 구현 전 작업 분해

기능은 큰데 어디서부터 손대야 할지 애매할 때, 단계를 잘게 쪼개는 데 도움을 줍니다.

3. 여러 선택지 비교

상태관리, 파일 구조, 데이터 흐름, API 설계처럼 “어떤 방식이 맞는가”를 먼저 따져야 할 때 의미가 큽니다.

4. 팀 공유용 초안 만들기

혼자 머릿속에서만 정리하는 게 아니라, PR 설명이나 설계 초안처럼 남길 수 있는 계획 문서가 필요할 때 더 잘 맞습니다.

즉, Ultra Plan은 “바로 실행하는 도구”라기보다
큰 일을 시작하기 전에 생각을 구조화하는 도구에 가깝습니다.

Claude Code 사용자 입장에서 체감될 변화

사용 감각이 조금 바뀝니다.

기존에 익숙한 흐름

질문 → 답 → 수정 → 다시 보기

Ultra Plan이 끼어든 흐름

큰 작업 제시 → 계획을 별도로 생성 → 검토 → 실행

실패 원인이 구현 능력보다 계획 없이 구현으로 들어간 경우인 일이 많다는 점에서, 이 차이는 작지 않습니다.

Tip 코딩 에이전트를 잘 쓰는 사람들은 보통 “지금은 구현 단계인지, 계획 단계인지”를 분리합니다. Ultra Plan은 그 분리를 제품 차원에서 도와주는 기능으로 보입니다.

일반적인 계획 요청과는 무엇이 다를까

공개된 설명을 보면 Ultra Plan은 단순히 “더 긴 plan”이 아닙니다.
핵심은 handoff 구조가 있는 planning experience라는 점입니다.

이를 단순하게 비교하면 이렇습니다.

구분	일반 계획 요청	Ultra Plan
실행 위치	로컬 CLI	웹 plan 세션
사용 감각	세션 안 즉시 응답	planning 분리 처리
목적	짧은 정리·즉답형	큰 계획·검토 가능한 초안
장점	빠르고 단순	구조적·터미널 부담 감소
단점	큰 일에 복잡해짐	작은 일엔 과함

즉, Ultra Plan은 같은 기능의 상위호환이라기보다
planning을 다른 레벨의 UX로 끌어올리는 시도에 가깝습니다.

한계도 분명합니다

물론 이 기능을 너무 이상적으로 볼 필요는 없습니다.

1. 작은 작업엔 과합니다

파일 하나 고치고 끝날 일을 Ultra Plan까지 태우면 오히려 느립니다.

2. 계획의 질은 여전히 입력에 좌우됩니다

Ultra Plan이 있다고 해도, 요청이 모호하면 결과도 모호할 수 있습니다.

3. 계획과 실행은 다릅니다

좋은 계획이 좋은 구현을 자동으로 보장하진 않습니다.
즉, Ultra Plan은 실행기가 아니라 좋은 출발점에 가깝습니다.

4. 클라우드 handoff는 취향을 탑니다

어떤 사람은 모든 걸 로컬에서 끝내고 싶어할 수 있습니다.
그래서 이 구조는 분명 호불호가 갈릴 가능성이 있습니다.

5. 계정·인프라 조건이 맞아야 합니다

GitHub 저장소와 웹 계정 전제는 앞에서 정리한 대로이고, Bedrock·Vertex·Foundry 경로에서는 아예 쓸 수 없습니다. Remote Control과도 동시 사용이 안 되므로, 워크플로를 짤 때 충돌을 염두에 두는 편이 좋습니다.

6. 연구 프리뷰라 변할 수 있습니다

버전 요건·UI 문구·세부 동작은 공지와 릴리스에 따라 바뀔 수 있다고 문서에 적혀 있습니다.

주의 Ultra Plan(Ultraplan)은 “생각을 더 잘해주는 버튼”보다는 planning 워크플로를 분리해 주는 기능으로 이해하는 편이 낫습니다. 작은 작업에 남용하면 리듬이 끊길 수 있고, 웹·GitHub·버전 전제도 함께 확인해야 합니다.

왜 이 기능이 앞으로 더 중요할까

코딩 에이전트의 경쟁 축이 “더 빨리 코드” 하나로만 좁혀지지는 않을 겁니다.

앞으로 더 자주 묻게 될 질문은 예를 들면 이런 쪽입니다.

더 나은 계획을 세우는가
큰 작업을 구조화하는가
계획과 실행을 덜 섞는가
검토 가능한 산출물을 남기는가

이 관점에서 Ultra Plan은 단순한 신기능이라기보다 제품이 어디로 가려는지 보여 주는 신호에 가깝습니다.
“코드를 대신 쓰는 도구”에서 복잡한 일을 먼저 정리하는 도구 쪽으로 옮겨 가는 흐름으로 읽을 수 있습니다.

마무리

이름은 “초강화 추론”처럼 들릴 수 있지만, Ultra Plan의 핵심은 계획을 별도 흐름으로 분리했다는 점에 있습니다.

로컬 CLI에서 시작 (/ultraplan 등)
웹 plan mode에서 클라우드 초안
브라우저에서 코멘트·수정 반복
웹 구현·PR 또는 터미널 teleport로 실행

단순한 reasoning 강화라기보다 워크플로우 분리와 planning UX에 가까운 변화입니다.
작은 일에는 과하지만, 복잡한 일 앞에서는 체감이 클 수 있습니다.

코딩 에이전트는 “더 빨리 쓰기”만이 아니라, 더 큰 일을 먼저 잘 계획하는 쪽으로도 진화할 가능성이 높다.

그 전제를 가정하면 Ultra Plan은 그 방향의 이른 시도로 읽히는 편이 자연스럽습니다.

참고 자료

Ultraplan 공식 문서: https://code.claude.com/docs/en/ultraplan ↗
Claude Code on the web: https://code.claude.com/docs/en/claude-code-on-the-web ↗
Plan mode(로컬 세션에서의 계획): https://code.claude.com/docs/en/permission-modes#analyze-before-you-edit-with-plan-mode ↗
Ultrareview(머지 전 코드 리뷰 쪽 짝): https://code.claude.com/docs/en/ultrareview ↗
Remote Control: https://code.claude.com/docs/en/remote-control ↗
사용자 테스트/분석 글: https://www.mejba.me/blog/claude-code-ultra-plan-tested ↗
사용자 가이드: https://claudefa.st/blog/guide/mechanics/ultraplan ↗

Claude Code Ultra Plan 살펴보기: 로컬 CLI를 넘어 클라우드에서 계획을 세우는 방식

Ultra Plan은 무엇인가요?

왜 이 기능이 중요한가요?

“더 오래 생각한다”보다 “계획을 분리한다”가 핵심입니다

왜 굳이 클라우드에서 계획을 세우게 할까

1. 터미널을 덜 막기 위해

2. 더 큰 planning UX를 만들기 위해

3. 계획과 실행을 분리하기 위해

CLI에서 어떻게 시작하나

터미널에 보이는 상태 표시

브라우저에서 검토하고, 어디서 실행할지 고르기

실행은 두 갈래

실제 개발 워크플로우에서는 언제 유용할까

1. 리팩터링 전 설계 정리

2. 큰 기능 구현 전 작업 분해

3. 여러 선택지 비교

4. 팀 공유용 초안 만들기

Claude Code 사용자 입장에서 체감될 변화

일반적인 계획 요청과는 무엇이 다를까

한계도 분명합니다

1. 작은 작업엔 과합니다

2. 계획의 질은 여전히 입력에 좌우됩니다

3. 계획과 실행은 다릅니다

4. 클라우드 handoff는 취향을 탑니다

5. 계정·인프라 조건이 맞아야 합니다

6. 연구 프리뷰라 변할 수 있습니다

왜 이 기능이 앞으로 더 중요할까

마무리

관련 글

참고 자료