Claude Code /cd - 세션을 재시작하지 않고 디렉터리를 옮기며 프롬프트 캐시를 지키는 법
코딩 에이전트를 오래 붙잡고 일하다 보면 디렉터리를 옮겨야 하는 순간이 반드시 옵니다. 공유 라이브러리에서 코어 모듈을 고친 다음, 그 모듈을 쓰는 서비스로 넘어가 통합을 확인해야 하는 모노레포 작업이 대표적입니다. 지금까지는 이럴 때 세션을 닫고 새 디렉터리에서 다시 열거나 /clear로 맥락을 비워야 했습니다. 그러면 여태 쌓은 대화 맥락이 사라지는 것은 물론이고, 눈에 잘 보이지 않는 비용 하나가 더 발생합니다. 바로 프롬프트 캐시가 통째로 무효화되어 다음 요청이 캐시 쓰기 요율로 다시 청구되는 것입니다. Claude Code v2.1.169에 조용히 들어온 /cd 명령은 이 두 손실을 동시에 막습니다. 이 글은 그 한 줄이 왜 단순한 편의 기능이 아니라 코딩 에이전트 운영 비용의 문제인지, 문서에 공개된 요율을 근거로 짚습니다.
개요
/cd <경로>는 실행 중인 Claude Code 세션을 다른 작업 디렉터리로 옮깁니다. 세션을 재시작하지 않으므로 대화 기록, 모델 선택, 권한 설정이 모두 새 디렉터리로 그대로 넘어갑니다. 여기까지는 흔한 편의 기능처럼 들립니다. 진짜 핵심은 그다음입니다. /cd는 프롬프트 캐시를 깨지 않습니다. 디렉터리를 옮긴 직후에 보내는 메시지가 캐시 쓰기 가격이 아니라 캐시 읽기 가격으로 청구됩니다.
이 차이가 사소하지 않은 이유는 캐시 요율 자체에 있습니다. Anthropic이 공개한 프롬프트 캐싱 요율에서 캐시 읽기는 표준 입력 단가의 약 10퍼센트, 즉 0.1배입니다. 반대로 캐시에 새로 쓰는 것은 기본 입력 단가의 1.25배가 붙습니다. 세션을 재시작하면 시스템 프롬프트, 도구 정의, 그리고 프로젝트의 CLAUDE.md가 모두 새 캐시로 다시 쓰여야 합니다. 큰 프로젝트일수록 이 프리픽스는 수만 토큰에 달합니다. /cd는 이 프리픽스를 다시 쓰지 않고 그대로 읽어 재사용합니다.
ThakiCloud는 멀티테넌트 환경에서 여러 고객의 에이전트와 배치 작업을 같은 인프라 위에서 돌립니다. 이런 환경에서 토큰 경제성은 곧 서비스 원가입니다. 코딩 에이전트가 디렉터리를 옮길 때마다 프리픽스를 다시 캐싱한다면, 그 비용은 세션 수와 전환 횟수에 비례해 누적됩니다. /cd처럼 캐시를 보존하는 동작 하나가 대규모 운영에서는 무시할 수 없는 절감으로 이어집니다. 그래서 이 기능은 “편한 단축키”가 아니라 “비용 위생”의 문제로 보는 편이 정확합니다.
이 기술은 무엇인가
프롬프트 캐시가 어떻게 작동하는지 먼저 짚어야 /cd의 가치가 보입니다. Claude Code는 매 턴마다 시스템 프롬프트, 도구 정의, CLAUDE.md를 자동으로 캐싱합니다. 별도 설정이 필요 없습니다. 이 캐시된 프리픽스가 대화 앞부분을 차지하고, 그 뒤에 매번 새로운 메시지가 붙습니다. 캐시가 살아 있으면 이 프리픽스는 읽기 요율로만 청구됩니다. 캐시가 깨지면 프리픽스 전체를 다시 써야 합니다.
세션을 재시작하거나 /clear로 맥락을 비우면 캐시가 무효화됩니다. 그런데 디렉터리를 옮기는 작업의 함정은, 새 디렉터리에 다른 CLAUDE.md가 있다는 점입니다. 상식적으로는 시스템 프롬프트에 들어가는 CLAUDE.md가 바뀌면 캐시가 깨져야 할 것 같습니다. /cd의 영리한 부분이 여기입니다. 목적지 디렉터리의 CLAUDE.md를 시스템 프롬프트에 다시 써 넣는 대신, 대화의 다음 메시지로 덧붙입니다. 시스템 프롬프트를 다시 쓰지 않으니 캐시된 프리픽스가 그대로 유지되고, 새 CLAUDE.md는 그저 뒤에 붙는 사용자 메시지 하나로 처리됩니다. 이것이 캐시를 지키면서도 새 디렉터리의 규칙을 반영하는 방법입니다.
아래 도표는 디렉터리를 옮길 때 두 경로가 캐시에 어떻게 다르게 작동하는지를 보여 줍니다.
flowchart TB
A["디렉터리 A에서<br/>세션 진행 중<br/>(프리픽스 캐시 활성)"] --> B{"디렉터리 B로<br/>이동 필요"}
B -->|"재시작 또는 /clear"| C["시스템 프롬프트·도구·<br/>CLAUDE.md 캐시 무효화"]
C --> D["프리픽스 전체를<br/>다시 캐시 쓰기<br/>(1.25배 요율)"]
D --> E["대화 맥락 손실"]
B -->|"/cd 경로"| F["시스템 프롬프트 유지<br/>새 CLAUDE.md는<br/>메시지로 덧붙임"]
F --> G["프리픽스 캐시 읽기<br/>(0.1배 요율)"]
G --> H["대화·모델·권한<br/>그대로 유지"]
이 그림의 핵심은 오른쪽 경로가 시스템 프롬프트를 건드리지 않는다는 점입니다. 왼쪽 경로는 프리픽스를 다시 쓰면서 그동안 쌓은 대화까지 함께 버립니다. 같은 목적지에 도착하지만 지불하는 비용이 완전히 다릅니다.
왜 뒤에 붙이면 캐시가 살아남는지는 프롬프트 캐싱이 프리픽스 단위로 동작하기 때문입니다. 캐시는 대화의 앞부분, 즉 접두부가 이전과 동일한 만큼을 재사용합니다. 접두부의 한 글자라도 바뀌면 그 지점부터 뒤는 전부 다시 계산해야 합니다. 그래서 자주 바뀌는 내용을 앞에 두면 캐시 적중률이 떨어지고, 안정적인 내용을 앞에 두고 변하는 내용을 뒤에 붙이면 적중률이 올라갑니다. /cd가 새 CLAUDE.md를 시스템 프롬프트가 아니라 대화 끝에 메시지로 덧붙이는 것은 정확히 이 원리를 지키는 설계입니다. 캐시된 접두부는 손대지 않고, 변화는 캐시 경계 바깥에서 흡수합니다.
설치 및 통합
/cd는 별도 설치가 필요 없습니다. Claude Code v2.1.169 이상이면 바로 쓸 수 있습니다. 이 명령은 2026년 6월 8일에 릴리스되었습니다. 사용법은 단순합니다.
# 세션 안에서 다른 디렉터리로 이동
/cd ../consuming-service
# 절대 경로도 가능
/cd /Users/me/repo/apps/web
# 홈 기준 경로
/cd ~/repo/packages/core
명령을 실행하면 Claude Code는 작업 디렉터리를 갱신하고, 새 위치의 CLAUDE.md를 읽어 대화에 덧붙인 뒤, 하던 작업을 이어 갑니다. 대화 기록과 지금까지 내린 결정이 그대로 남아 있으므로, “방금 코어 모듈에서 고친 인터페이스를 이 서비스에서 검증해 줘” 같은 요청이 자연스럽게 이어집니다.
구체적인 예를 들어 보겠습니다. ThakiCloud의 플랫폼 워크스페이스는 Go 백엔드, 프론트엔드, GitOps 배포, 멀티클러스터 메시 등 일곱 개의 제품 리포지터리를 git 서브모듈로 묶어 둡니다. 백엔드 API의 응답 스키마를 바꾼 뒤 그 스키마를 소비하는 프론트엔드에서 화면이 제대로 나오는지 확인하는 작업은 이 구조에서 일상입니다. 예전 방식이라면 백엔드 세션을 닫고 프론트엔드 디렉터리에서 새 세션을 열어야 했고, 그러면 방금 무엇을 왜 바꿨는지를 새 세션에 다시 설명해야 했습니다. /cd를 쓰면 흐름이 끊기지 않습니다.
# 백엔드 서브모듈에서 스키마 수정 작업 진행 중
# ...
# 그 스키마를 소비하는 프론트엔드로 이동 (맥락·캐시 유지)
/cd ../ai-suite/apps/web
# 이어서 바로 물어봄: 방금 바꾼 필드명을 이 화면이 참조하는지 확인
이동 직후 프론트엔드 디렉터리의 CLAUDE.md가 대화에 덧붙으므로, 그 리포지터리의 규칙(FSD 경계나 TDS 토큰 사용 같은)이 즉시 반영됩니다. 동시에 백엔드에서 쌓은 맥락, 즉 어떤 필드를 왜 바꿨는지가 그대로 살아 있어 곧장 검증으로 넘어갈 수 있습니다.
캐시 경제성을 이해하려면 요율 표를 봐야 합니다. 아래는 Anthropic이 공개한 프롬프트 캐싱 요율을 정리한 것입니다.
| 항목 | 표준 입력 대비 요율 | 설명 |
|---|---|---|
| 캐시 읽기 | 0.1배 | 캐시된 프리픽스 재사용, 90퍼센트 할인 |
| 캐시 쓰기(5분 TTL) | 1.25배 | 새 프리픽스를 캐시에 기록, 첫 읽기가 회수 |
| 캐시 쓰기(1시간 TTL) | 2.0배 | ENABLE_PROMPT_CACHING_1H=1 설정 시 |
| 캐시 미사용 입력 | 1.0배 | 기준 단가 |
한 가지 주의할 맥락이 있습니다. Anthropic은 2026년 3월에 기본 캐시 TTL을 60분에서 5분으로 조용히 줄였습니다. 5분 안에 다음 요청이 없으면 캐시가 만료되어 다시 쓰기 비용을 냅니다. 긴 간격으로 작업한다면 1시간 옵션을 켜는 것을 고려할 수 있지만, 쓰기 프리미엄이 2.0배로 올라가므로 트레이드오프를 따져야 합니다. /cd는 이 TTL 안에서 세션을 이어 갈 때 캐시를 살려 두는 역할이라, 짧은 TTL 시대에 오히려 더 중요해졌습니다.
실제 실험 결과
정직하게 밝히자면, /cd는 대화형 슬래시 명령이라 이 글을 작성한 헤드리스 환경에서는 실제 세션을 띄워 상호작용 벤치마크를 돌릴 수 없었습니다. 그래서 측정값을 지어내는 대신, 공개된 요율만으로 계산할 수 있는 비용 모델을 제시합니다. 아래 수치는 측정값이 아니라 문서 기준 요율 계산이며, 그 사실을 분명히 표시합니다.
디렉터리를 옮긴 직후 첫 요청에서 캐시된 프리픽스가 어떻게 청구되는지 두 경로를 비교해 보겠습니다. 재시작이나 /clear 경로에서는 프리픽스가 캐시 쓰기(1.25배)로 다시 기록됩니다. /cd 경로에서는 같은 프리픽스가 캐시 읽기(0.1배)로 재사용됩니다. 프리픽스 크기가 같다고 놓으면, 전환 직후 프리픽스에 대해 지불하는 비용의 비율은 1.25 나누기 0.1, 즉 12.5배입니다. 다시 말해 재시작 경로는 /cd 경로보다 프리픽스 재청구에서 약 12.5배 비쌉니다.
이 비율은 프리픽스의 절대 토큰 수와 무관하게 성립합니다. 다만 절대 절감액은 프리픽스가 클수록 커집니다. 대규모 프로젝트에서 시스템 프롬프트와 도구 정의, 그리고 두툼한 CLAUDE.md를 합친 프리픽스가 수만 토큰에 이르는 경우가 흔한데[추정], 이런 세션에서 하루에 디렉터리를 여러 번 오가면 재캐시 비용이 빠르게 쌓입니다. /cd는 그 전환마다 붙는 12.5배 프리미엄을 읽기 요율로 눌러 줍니다.
한 가지 더 짚을 점은, /cd가 지키는 것이 비용만이 아니라는 사실입니다. 재시작 경로에서 잃는 대화 맥락은 토큰으로 환산하기 어려운 비용입니다. 방금 고친 코드의 의도, 앞서 세운 가설, 이미 배제한 접근을 다시 설명해야 한다면 사람의 시간과 추가 토큰이 모두 듭니다. /cd는 이 재설명 비용까지 함께 제거합니다.
ThakiCloud 제품 적용 시사점
이 기능은 ThakiCloud의 두 제품 관점에서 모두 의미가 있습니다.
Paxis 관점에서 보면 /cd는 코딩 에이전트의 세션 위생 문제를 정확히 건드립니다. Paxis는 ThakiCloud의 Agent-Native Cloud로, 스킬과 도구, 정책, 감사 로그를 일급 리소스로 다루며 격리된 샌드박스에서 에이전트를 실행합니다. 코딩 에이전트가 여러 리포지터리와 서브모듈을 오가며 작업하는 것은 Paxis에서 흔한 시나리오입니다. 이때 전환마다 세션을 재시작해 프리픽스를 다시 캐싱한다면, 큰 스킬 하니스와 정책 컨텍스트를 매번 재청구하게 됩니다. /cd처럼 프리픽스를 보존하며 디렉터리 규칙만 메시지로 덧붙이는 방식은, 스킬 선택과 정책 게이트를 유지한 채로 작업 경로만 바꾸는 Paxis의 오케스트레이션 모델과 잘 맞습니다. 시스템 프롬프트를 다시 쓰지 않고 뒤에 컨텍스트를 덧붙인다는 발상 자체가, 상시 로딩되는 규칙 레이어를 캐시 안정성 관점에서 관리하는 원칙과 동일합니다.
ai-platform 관점에서는 캐시 경제성이 곧 멀티테넌트 서빙 원가입니다. ThakiCloud의 ai-platform은 K8s와 Kueue 기반 GPU 스케줄링 위에서 여러 고객의 추론 워크로드를 서빙합니다. 프롬프트 캐싱은 반복되는 프리픽스를 재사용해 입력 비용을 줄이는 핵심 레버인데, /cd가 보여 주는 원리, 즉 캐시를 깨지 않도록 컨텍스트를 앞이 아니라 뒤에 추가한다는 설계는 자체 서빙 스택에서도 그대로 적용됩니다. 캐시 무효화 지점을 최소화하도록 프롬프트 구조를 설계하면, 낮은 서빙 비용에서 경쟁력을 얻습니다. 두 렌즈는 서로를 보완합니다. 낮은 서빙 비용(ai-platform)이 에이전트 경제성(Paxis)을 만들고, 캐시를 지키는 에이전트 동작(Paxis)이 다시 인프라 부하를 낮춥니다.
한계 및 반론
/cd가 만능은 아닙니다.
먼저 캐시 보존은 5분 TTL 안에서만 의미가 있습니다. 디렉터리를 옮긴 뒤 오래 손을 놓으면 캐시가 만료되어, /cd를 썼든 안 썼든 다음 요청은 쓰기 비용을 냅니다. 짧은 TTL을 감안하면 /cd의 절감은 연속 작업 흐름에서 가장 크고, 간헐적 작업에서는 효과가 줄어듭니다.
둘째로, CLAUDE.md를 시스템 프롬프트가 아니라 메시지로 덧붙이는 방식에는 미묘한 함정이 있습니다. 세션 도중에 원본 프로젝트의 CLAUDE.md를 편집해도 그 변경은 캐시를 깨지 않는 대신, /clear나 /compact 또는 재시작 전까지는 적용되지 않습니다. 즉 규칙을 바꿨는데 세션이 이를 반영하지 않는 상황이 생길 수 있으므로, 규칙 변경 후에는 의도적으로 세션을 갱신해야 합니다.
셋째로, 캐시 절감 비율 12.5배는 어디까지나 전환 직후 프리픽스 재청구에 대한 문서 기준 계산입니다. 실제 세션 전체 비용에서 프리픽스가 차지하는 비중, 대화 길이, 전환 빈도에 따라 체감 절감폭은 달라집니다. 이 글의 비율을 “세션 비용이 12.5배 싸진다”로 확대 해석하면 안 됩니다. 정확히는 “전환 시점에 프리픽스를 다시 캐싱하지 않아도 된다”는 절감입니다.
그럼에도 결론은 분명합니다. 모노레포나 다중 리포지터리 작업에서 디렉터리를 오갈 일이 잦다면, /cd는 대화 맥락과 프롬프트 캐시를 동시에 지키는 가장 값싼 방법입니다. 코딩 에이전트를 비용까지 고려해 운영하는 팀이라면, 이 한 줄을 습관으로 만들 이유가 충분합니다.
