Claude Code 터미널: 파워 유저를 위한 워크플로 업그레이드 7가지

기본 설정의 Claude Code만으로도 충분히 유용합니다. 설치하고 프롬프트를 입력하면 원하는 것을 만들어 줍니다. 대부분의 사람들이 이렇게 바이브 코딩을 하고, 그 방식은 잘 작동합니다.

하지만 터미널을 커스터마이즈한 사람이 쓰는 Claude Code는 다른 도구에 가깝습니다. 신뢰하는 bash 명령을 사전에 승인해 두었기 때문에 Claude가 권한을 묻는 일은 거의 없습니다. CLAUDE.md가 프로젝트 루트에 있어 세션이 시작되는 순간부터 Claude는 해당 규칙을 이미 알고 있습니다. 그리고 세션이 혼란스러워지기 시작할 때, 그들이 사용하는 명령은 재시작이 아닙니다.

이 글은 두 가지 Claude Code 설정 사이의 간극을 일곱 가지 업그레이드로 메웁니다. 어느 것도 설정에 10분 이상 걸리지 않으며, 각각은 일주일 안에 보상을 돌려줍니다.

Claude Code를 한 번도 열어본 적이 없다면, 메인 Claude Code 가이드가 더 좋은 출발점입니다. 아래 내용은 이미 프롬프트를 입력하고 도구 호출을 승인할 수 있다고 가정합니다.

1. 같은 명령 재승인 그만하기

기본값에선 새 도구 호출마다 승인 요청이 뜹니다. 처음 pytest를 돌릴 땐 괜찮지만, 세 번째쯤 되면 귀찮아지고, 열 번째쯤엔 프롬프트도 안 읽고 Enter만 두드립니다. 이는 최악의 조합입니다. 안전 확인을 무시하는 습관을 들였고, 그 확인은 여전히 속도를 늦춥니다.

물론 "위험을 감수하고 권한 우회" 모드, 즉 "자동 모드"도 있습니다. 이에 따른 트레이드오프는 Claude Code 자동 모드와 채널 튜토리얼에서 자세히 다뤘습니다.

settings.json 파일에서 권한 정의하기

해결책은 프로젝트 루트의 .claude/settings.json 파일에 permissions 블록을 두고, 신뢰하는 패턴은 미리 승인하고 그렇지 않은 건 차단하는 것입니다:

{
  "permissions": {
	"allow": [
  	"Bash(pytest *)",
  	"Bash(uv run *)",
  	"Bash(ruff check *)",
  	"Read(~/.zshrc)"
	],
	"deny": [
  	"Bash(curl *)",
  	"Read(./.env)",
  	"Read(./.env.*)",
  	"Read(./secrets/**)"
	]
  }
}

규칙은 고정된 순서로 평가됩니다. 먼저 deny, 그다음 ask, 마지막으로 allow입니다. 처음 매칭되는 규칙이 승리하므로, deny 규칙은 이후 allow보다 항상 우선합니다.

스코프와 와일드카드 마스터하기

이런 규칙을 처음 쓸 때 사람들이 주로 헷갈리는 지점이 세 가지 있습니다.

1. 첫째는 스코프입니다. 프로젝트의 .claude/settings.json가 전역 ~/.claude/settings.json을 덮어씁니다. 전역에서 Bash(rm *)를 허용했더라도 프로젝트에서 이를 거부하면 프로젝트 규칙이 이깁니다. 올바른 기본값이지만, 전역 허용이 항상 유지되길 기대한 사람들에겐 의외일 수 있습니다.

2. 둘째는 네트워크 명령에 대한 와일드카드입니다. Bash(curl http://github.com/ *)는 제한적으로 보이지만 https://, URL 앞의 옵션, 리디렉션, 셸 변수 확장을 잡아내지 못합니다. 문서에서 권장하는 패턴은 Bash(curl *)을 전면 거부한 뒤, 실제로 허용할 도메인에 대해서만 WebFetch(domain:github.com)처럼 WebFetch 도구를 사용하는 것입니다.

3. 셋째는 공백입니다. Bash(ls *)는 ls -la엔 매칭되지만 lsof엔 매칭되지 않습니다. Bash(ls*)는 둘 다 매칭됩니다. 별표 앞의 공백이 실제로 의미를 가지므로, 어떤 것을 썼는지 의도적으로 선택하는 것이 좋습니다.

권한과 함께 알아두면 좋은 몇 가지 키 바인딩이 있습니다. 모두 "터미널과 싸우지 않기" 범주에 속하며, 첫날부터 배울 가치가 있습니다.

• Shift+Tab: 권한 모드 전환(기본, 자동 승인, 플랜)

• Esc+Esc: 되감기 선택기 열기(#3에서 자세히)

• Ctrl+R : bash와 zsh처럼 프롬프트 기록 역검색

• Ctrl+U: 커서부터 줄 시작까지 삭제

• Shift+Enter: 프롬프트 내에 새 줄 추가

대부분의 키 바인딩은 터미널에서 바로 작동합니다. 그렇지 않다면 /terminal-setup 슬래시 명령을 한 번 실행해 필요한 것을 모두 설치하세요.

2. Claude Code가 프로젝트를 기억하게 만들기

각 세션은 항상 새로운 컨텍스트 윈도우로 시작합니다.

기본적으로 Claude는 pip 대신 uv를 쓴다는 사실을 기억하지 못합니다. 테스트가 test/가 아니라 tests/에 있다는 것도 기억하지 못하죠. 어제 10턴 동안 설명해 준 API 규칙도 마찬가지입니다. 해결책은 프로젝트 루트의 CLAUDE.md 파일입니다. 해당 디렉터리(또는 하위 디렉터리)에서 Claude Code를 실행하면, 첫 프롬프트 전에 이 파일이 자동으로 컨텍스트에 로드됩니다.

가장 빠른 시작 방법은 /init입니다. 프로젝트 내부에서 실행하면 Claude가 코드베이스를 읽고, 빌드 명령과 테스트 방법, 추론 가능한 규칙을 담은 초안 CLAUDE.md를 작성해 줍니다. 이후엔 수정이 필요합니다. /init는 완성본보다는 작동 가능한 베이스라인을 제공하기 때문입니다.

Claude가 컨텍스트를 찾는 곳은 세 군데이며, 서로 누적됩니다.

프로젝트 CLAUDE.md는 ./CLAUDE.md 경로에 있으며 리포와 함께 배포됩니다. 모든 기여자에게 동일하므로, 프로젝트별 사실을 여기에 적으세요.

• 패키지 관리자와 언어 버전
• 테스트 명령과 테스트가 위치한 곳
• 디렉터리 레이아웃 및 직관적이지 않은 규칙
• 새 팀원이 첫날 알아야 할 모든 것

사용자 CLAUDE.md는 ~/.claude/CLAUDE.md 경로에 있으며, 내 머신의 모든 프로젝트에 적용됩니다. 개인 선호(코딩 스타일, 선호하는 독스트링 형식, 우선 사용하는 언어 등)는 여기에 적습니다. 프로젝트 사실은 여기 두지 마세요. 다른 리포에도 스며듭니다.

자동 메모리는 세 번째 레이어이며, Claude가 스스로 작성합니다. 세션 중에 교정하면(“여긴 camelCase가 아니라 snake_case 씁니다”) 해당 내용을 ~/.claude/projects/<project>/memory/MEMORY.md에 기록합니다. 이 파일의 처음 200줄 또는 25KB가 같은 프로젝트의 모든 대화 시작 시 로드됩니다. /memory로 무엇이 로드되는지 확인하고, 자동 메모리를 켜거나 끌 수 있습니다.

한 가지 크기 원칙: 각 CLAUDE.md는 200줄 이하로 유지하세요. 그 이상이면 매 턴마다 컨텍스트를 눈에 띄게 잡아먹고, 짧은 파일보다 긴 파일을 덜 신뢰성 있게 따릅니다. 길어지면 경로 스코프와 함께 .claude/rules/로 분리하세요. CLAUDE.md에 실제로 무엇을 넣어야 하는지 더 자세한 내용은 제 최적의 CLAUDE.md 작성 튜토리얼을 참고하세요.

3. 세션이 꼬였다고 매번 재시작하지 않기

세션이 이상하게 느껴지기 시작하면 /clear로 초기화하고 다시 시작하려는 본능이 듭니다. 대부분은 잘못된 선택입니다. 재시작하면 Claude가 편집하던 파일 경로나 추적하던 실패한 테스트, 초반에 명시한 제약을 버리게 됩니다. 새 세션은 이를 다시 학습해야 하고, 토큰과 시간으로 대가를 치르게 됩니다.

먼저 증상을 알아두세요. 이런 컨텍스트 부식은 눈에 띄는 신호가 몇 가지 있습니다.

• Claude가 다섯 턴 전에 편집한 파일 경로를 다시 묻는다
• 이미 거절한 제안을 반복한다
• 현재 브랜치를 놓친다
• 같은 지점을 한 세션에서 두 번 이상 교정하게 된다

이 신호가 보이면 선택지는 네 가지이며, 서로 대체 불가능합니다.

세션 압축하기

 /compact는 일부 사용자가 말하는 것만큼 나쁘지 않습니다.

프로젝트 CLAUDE.md는 영향을 받지 않습니다. 압축 후 Claude가 디스크에서 파일을 다시 읽어 들여 재주입하므로, 규칙이 사라지지 않습니다. /compact keep the auth refactor decisions, drop the failed test runs처럼 요약에 초점을 지시해 유용한 요약을 만들 수 있습니다. 일반적인 요약과 유용한 요약의 차이는 여기에 있습니다.

Claude Code의 “되돌리기” 옵션 사용하기

Esc+Esc 되감기 선택기는 대부분 사람들이 존재를 모르는 기능입니다. 세션의 모든 프롬프트 체크포인트 목록을 열어 줍니다. 하나를 고르면 세 가지 옵션이 나타납니다. 대화만 복원, 코드만 복원, 둘 다 복원.

대부분은 “코드와 대화 복원”을 원합니다. 형편없는 30분을 git을 열지 않고도 사라지게 만들 수 있습니다. 전체 세션을 위한 되돌리기와 가장 가까운 기능입니다.

재시작을 멈추면 다음 문제는 세션을 다시 찾는 일입니다.

세션 이름 지정과 다시 열기

claude -n <name>(또는 --name)은 이름 있는 세션을 시작하며, 이 이름은 /resume과 터미널 타이틀에 표시됩니다. 같은 리포에서 세 가지 작업(실험 브랜치, 리팩터, 디버그)을 동시에 진행할 때, 이름이 구분 기준입니다. /rename으로 세션 중간에 범위가 바뀌면 이름을 변경할 수 있습니다.

팁: 같은 터미널 창에서 여러 세션을 돌릴 때는 /color로 더 명확히 구분하세요.

세션을 다시 여는 방법은 두 가지 플래그입니다. claude --continue(또는 -c)는 현재 디렉터리의 가장 최근 대화를 로드합니다. 방금 여기서 하던 걸 이어갈 때 쓰세요.

claude --resume는 대화 선택기를 열고, claude --resume <name-or-id>는 특정 세션으로 바로 점프합니다. 세션을 git 브랜치처럼 다루세요. 작업 스트림이 다르면 각자 세션을 부여할 가치가 있습니다.

4. 어려운 건 계획하고, 쉬운 건 가볍게 처리하기

커스터마이즈된 설정의 가장 큰 비용은 에디터나 키 바인딩이 아닙니다. 눈앞의 작업 난이도에 맞춰 연산 자원을 쓰는 일입니다. 여기에 맞춰 함께 작동하는 세 가지 도구가 있습니다. 플랜 모드, /effort, 그리고 /model입니다.

Claude Code 플랜 모드 사용하기

플랜 모드는 파일을 건드리기 전에 접근 방식을 먼저 구상하도록 Claude에 지시합니다. 계획을 작성하면, 사용자가 읽고 승인하거나 피드백을 주고, 그다음에만 실행합니다.

제가 계획을 단단하게 만드는 데 자주 쓰는 간단한 프롬프트가 있습니다.

Red-team this plan from multiple angles using as many Opus 4.7 agents as you need.

이렇게 하면 여러 서브 에이전트를 띄워 다양한 관점에서 계획을 검토하고 개선점을 제안합니다. 500줄이 넘는 계획 파일을 다룰 때 좋은 방법입니다.

대신 비용이 듭니다. 계획 수립과 레드팀 검토로 코드가 적용되기 전에 두 턴이 추가되므로, 눈에 띄는 기능이나 버그 수정이 아니라면 과한 선택입니다.

플랜 모드에 들어가는 방법은 다섯 가지입니다.

인라인 형식(/plan refactor the auth module to use JWT)은 많은 분이 놓칩니다. 모드와 작업을 한 번에 설정합니다. 검토 우선 플랜 워크플로우의 자세한 흐름은 제 Claude Code 플랜 모드 튜토리얼에서 단계별로 확인하세요.

적절한 노력 수준 설정하기

다음은 노력 수준입니다. 각 턴에서 Claude가 얼마나 확장된 사고를 할지 제어합니다. 높을수록 더 깊게 추론하고, 더 많은 토큰을 쓰며, 응답이 느려집니다.

/effort <level>와 --effort <level> CLI 플래그는 다섯 값 모두를 받습니다. low, medium, high, xhigh는 세션 간에도 유지됩니다. max는 토큰 지출 제약을 없애므로 세션 단위로만 적용되며, 매번 의도적으로 설정해야 합니다. 일상 작업의 적절한 기본값은 low 또는 medium입니다. 진짜 어려운 문제에는 high나 xhigh를, 틀리느니 토큰을 더 태우겠다는 순간엔 max를 쓰세요.

반론 하나: 좋은 컨텍스트의 낮은 노력 모델이, 나쁜 컨텍스트의 최대 노력 모델보다 종종 낫습니다. 노력 수치를 올리기보다 프롬프트를 정리하는 편이 더 큰 이득인 경우가 많습니다.

올바른 모델 선택하기

모델 선택은 진짜 비용 절감이 일어나는 곳입니다. /model은 세션 중간에도 전환합니다. Option+P(macOS) / Alt+P(윈도우/리눅스)는 이미 입력한 내용을 지우지 않고 교체합니다. 알아둘 별칭은 다음과 같습니다.

• sonnet: 일상용 기본값

• opus: 가장 어려운 문제용(별칭 best도 opus로 연결)

• haiku: 속도가 필요할 때

• sonnet[1m] 및 opus[1m]: 1M 컨텍스트 변형

• opusplan: 계획은 Opus, 실행은 Sonnet으로 구성

• default: 재정의를 지우고 권장 모델로 복귀

모든 작업에 Opus를 기본으로 쓰고 있다면, 대부분의 일을 Sonnet으로 전환하는 것이 가장 큰 지출 절감입니다. 

막힌 어려운 문제에는 가장 똑똑한 모델인 Opus가 맞습니다. 그 외 거의 모든 것은 Sonnet이 처리합니다. 둘 사이의 비용 차이는 상당하기 때문에 “안전하게 Opus를 쓰자”는 습관을 자동 조종에 두는 것이 가장 비싼 선택입니다.

5. 손으로 하던 일 자동화하기

마찰을 없앴다면, 다음 레이어는 여전히 손으로 하는 일입니다.

예약 작업

안 하는 방법을 고민하는 것보다 훨씬 쉽습니다. 대부분은 두 기능으로 커버됩니다. /loop는 원래는 지켜봐야 하는 반복 점검을, 훅(hooks)은 CLAUDE.md 지시로는 보장할 수 없는 것을 책임집니다.

/loop는 프롬프트나 슬래시 명령을 일정에 따라 재실행합니다. 문법은 두 가지 형태가 있습니다.

• /loop 5m <prompt>: 5분마다 프롬프트 실행

• /loop <prompt>: 주기를 모델에 맡김. 모델이 다음 실행 시점을 결정

간격 단위는 s, m, h, d이며 최소 1분입니다. Claude Code v2.1.72 이상이 필요합니다.

예를 들어 테스트 워처를 설정할 수 있습니다. /loop 2m run the test suite and report failures. 매 변경 후 테스트를 실행해야 한다는 사실을 기억했다가(그리고 절반은 잊고), Claude가 다음 2분 틱에서 깨진 테스트를 잡아냅니다.

같은 패턴은 스테이징 배포 상태 폴링(/loop 10m check if the staging deploy is green)이나 불안정한 사고 중 로그 테일링(/loop 1m tail the last 50 lines of app.log and flag errors)에도 잘 맞습니다.

루프의 수명은 7일입니다.

7일째에 마지막으로 한 번 실행된 뒤 스스로 삭제됩니다. 세션 범위이므로, 닫았다 다시 열면 --continue나 --resume로 되살릴 수 있습니다. 루프를 일찍 멈추려면 Esc를 누르세요. 세션 종료 후에도 살아남는 스케줄링(야간 점검, 주간 다이제스트)이 필요하면 /schedule을 통한 루틴을 사용하세요.

훅(Hooks)

훅은 다른 절반입니다. Claude의 워크플로 특정 지점에서 셸 명령을 실행하며, .claude/settings.json에서 구성합니다. 

CLAUDE.md 지시 대신 훅을 써야 하는 이유는 단 하나입니다. CLAUDE.md는 조언 수준이고, 훅은 실행이 보장됩니다. 대표 사례는 “편집 후 항상 린터 실행” 규칙인데 Claude가 절반은 건너뛰는 경우입니다. 훅이 그 틈을 메웁니다.

여섯 가지 이벤트로 대부분의 경우를 커버합니다.

최소한의 예시로, 모든 파일 편집 후 린트를 실행하는 PostToolUse 훅은 다음과 같습니다.

{
  "hooks": {
	"PostToolUse": [
  	{
    	"matcher": "Edit|Write",
    	"hooks": [
      	{ "type": "command", "command": "/path/to/lint-check.sh" }
    	]
  	}
	]
  }
}

기억해 둘 함정 하나: 종료 코드 2만이 실제로 Claude를 차단합니다. 종료 코드 1은 비차단 오류로 처리되어, 유닉스에서 일반적인 실패 코드임에도 불구하고 Claude는 계속 진행합니다. 규칙을 강제하려는 훅이라면 2를 반환하세요.

훅을 직접 손으로 작성할 필요도 없습니다.

“모든 파일 편집 후 ruff를 실행하는 훅을 작성해 줘”라고 프롬프트하면 Claude가 JSON을 초안해 줍니다. /hooks는 활성 훅 구성을 모두 나열하므로, 예상치 못한 실행이 있을 때 설정 파일을 grep하지 않아도 됩니다. 전체 이벤트 카탈로그와 stdin/stdout JSON 스키마는 제 Claude Code 훅 튜토리얼을 확인하세요.

6. 이런 모든 것의 비용을 모니터링하기

루프, 긴 세션, 기본 Opus는 모두 토큰을 태웁니다. 세 가지 명령은 지출을 관리 가능한 수준으로 가시화하며, 필요한 습관은 복잡한 설정이 아니라 수시로 흘깃 보는 것입니다.

/usage는 요금제, 세션 합계, 모델별 비용 분해, 5시간 및 주간 레이트 리밋 창에 대한 진행 바를 보여줍니다.

/context는 현재 컨텍스트 윈도우를 색상 그리드로 시각화하며, 용량 경고와 어떤 도구나 파일이 공간을 쓰는지에 대한 제안을 제공합니다. 세션이 무거워졌다고 느낄 때, /compact와 /clear 사이에서 결정하는 데 도움을 줍니다.

/statusline은 터미널 하단에 상주 바를 설정합니다. 모델, 컨텍스트 사용률, 레이트 리밋 창, 그리고 세션 JSON에서 읽어올 수 있는 그 밖의 항목을 표시할 수 있습니다. 이 기능이 행동을 가장 많이 바꿉니다. 작업 중 주변 시야에 비용 관련 숫자를 배치하기 때문입니다.

/statusline을 실행해 표시하고 싶은 내용을 자연어로 설명하면, Claude가 스크립트를 생성하고 설정을 업데이트합니다. 다른 방법으로는 셸 스크립트를 직접 작성해 ~/.claude/settings.json에서 가리키는 것입니다.

{
  "statusLine": {
	"type": "command",
	"command": "~/.claude/statusline.sh"
  }
}

세션을 넘어선 장기 추적에는, npx ccusage가 토큰 소모를 시간에 따라 집계하는 커뮤니티 도구입니다. 써드파티이며 Anthropic 제작은 아니지만, 세션 범위의 /usage와 월별 청구 사이의 간극을 메워 줍니다.

7. 알아두면 좋은 세 가지

위 여섯 가지 업그레이드는 제가 매일 쓰는 것들입니다. 아래 세 가지는 사용 빈도는 낮지만, 존재를 알아두면 필요한 날 바로 꺼내 쓸 수 있는 기능입니다.

/voice로 푸시투토크 사용하기

/voice는 푸시투토크 받아쓰기를 켭니다. Space를 누르고 말한 뒤 떼면, 전사가 프롬프트 입력에 들어갑니다. v2.1.69 이상이 필요하며, 20개 언어를 지원합니다.

걷거나 생각을 소리 내어 정리할 때, 또는 작업 시작 시 의도가 아직 정리되지 않았을 때는 보통 키보드보다 음성이 빠릅니다. “47번째 줄을 …로 바꿔” 같은 라인 단위 수정에는 타이핑이 더 낫습니다.

/teleport로 클라우드 세션 가져오기

/teleport(별칭 /tp)는 클라우드 세션을 로컬 터미널로 끌어옵니다. 웹 앱이나 iOS 앱에서 긴 작업을 시작했다가 노트북으로 돌아온 상황을 떠올려 보세요. claude --teleport를 실행하면 선택기가 열리고, 해당 세션이 올바른 브랜치를 체크아웃한 상태로 터미널에 열립니다.

몇 가지 요구 사항이 맞아야 합니다.

• 깨끗한 git 상태
• 올바른 리포
• 클라우드 세션을 실행한 것과 동일한 claude.ai 계정
• 브랜치가 원격에 푸시되어 있을 것

--teleport와 --resume를 혼동하지 마세요. 후자는 이 머신의 로컬 히스토리에서만 세션을 다시 엽니다. 자세한 흐름은 우리의 Claude Code 원격 제어 튜토리얼에서 다룹니다.

/btw로 사이드 질문하기

/btw는 흐름을 끊지 않고 묻고 싶은 간단한 질문을 위한 기능입니다.

Claude가 작업 중이라고 가정해 봅시다. 긴 편집이나 도구 호출을 이미 시작했는데, 갑자기 IP를 매칭하는 정규식이나 X 플래그가 무엇인지 알아야 할 때가 있습니다. 

그럴 땐 /btw <question>만 입력하면 됩니다. 답변은 닫을 수 있는 오버레이로 표시됩니다. 진행 중인 작업은 계속 돌아가고, 답변은 대화 기록에 들어가지 않습니다. 단발 조회를 위해 새 세션을 만들 필요도 없고, 현재 세션을 오염시키지도 않습니다.

결론

이 글의 모든 내용을 하루에 한꺼번에 시도하는 것이 가장 빠르게 원점으로 돌아가는 방법입니다. 두세 가지를 골라 근육 기억으로 만들고, 처음 셋이 자동화되면 나머지를 추가하세요.

서로 다른 시간대에 쓸 수 있도록, 서로 간섭하지 않게 고를 만한 셋은 다음과 같습니다.

• 프로젝트용 탄탄한 CLAUDE.md와, 매 세션 재승인하는 bash 명령에 대한 두세 개의 와일드카드 권한 규칙을 .claude/settings.json에 추가하세요. 아침 셋업 습관으로, 방해가 사라질 때 효과를 체감합니다.

• /compact 대 /clear 선택과 Esc+Esc 되감기 선택기. 세션 중 습관으로, Claude가 한 시간 전에 알던 파일 경로를 다시 물을 때가 신호입니다.

• 이미 시간을 잡아먹는 반복 점검 하나에 /loop를 설정하세요. 백그라운드 습관으로, 한 번 돌기 시작하면 스스로 이득을 냅니다.

Sonnet, Opus, Haiku의 차이가 아직도 헷갈린다면, Introduction to Claude Models 코스가 각 모델의 적합 상황을 안내합니다. 그러면 /effort와 /model 호출이 훨씬 쉬워집니다.