Claude Code system prompt를 줄이면 뭐가 달라질까 2026

2026년 4월 16일 기준 Claude Code 공식 문서는 output style이 system prompt를 직접 바꾸고, CLAUDE.md는 system prompt 뒤의 user message로 들어가며, status line은 로컬에서 실행돼 API 토큰을 쓰지 않는다고 설명한다.

그러니까 무엇이든 prompt에 더 넣는다고 Claude Code가 무조건 더 똑똑해지는 구조는 아니다.

그럼 질문이 하나 남는다.

system prompt를 길게 붙일수록 Claude Code가 더 좋아질까.

내 경험은 대체로 반대다.

처음엔 다들 이렇게 한다.

답변 길이를 줄이고 싶으면 prompt를 더 붙인다.

커밋 규칙을 고정하고 싶으면 prompt를 더 붙인다.

브랜치 이름 규칙, 리뷰 형식, 실험 루틴, 세션 핸드오프, 작업 분리 기준까지 전부 prompt에 몰아넣는다.

근데 오래 쓸수록 문제가 생긴다.

항상 보여줘야 할 실시간 정보와, 가끔만 쓰는 절차와, 병렬 작업용 격리 규칙이, 전부 한 덩어리로 섞이기 때문이다.

그 순간부터 prompt는 지침서가 아니라 잡동사니 창고가 된다.

이번 글은 prompt를 짧게 쓰세요 같은 교양 수업이 아니다.

무엇을 system prompt에 남기고 무엇을 statusline으로 빼고 무엇을 slash command나 skill로 빼고 무엇을 worktree로 빼야 하는가 를 운영 기준으로 정리한다.

핵심만 먼저 말하면 이렇다.

system prompt에는 매 턴 지켜야 하는 응답 성향과 형식만 남기고,
실시간 관측값은 statusline으로,
반복 절차는 slash command나 skill로,
병렬 작업 격리는 worktree로 빼는 편이 Claude Code를 오래 쓸수록 덜 느리고 덜 꼬인다.

지금 결론

무엇을 정하려는가	어디에 두는 편이 맞나	왜 거기가 맞나
매 턴 같은 말투, 형식, 응답 길이	output style 또는 append-system-prompt	system prompt 레벨에서 바로 적용된다
프로젝트 규칙, 빌드 명령, 팀 합의	CLAUDE.md	세션 시작 시 함께 읽히는 팀 공용 문맥이다
항상 보고 싶은 실시간 정보	statusline	로컬 실행이라 토큰을 쓰지 않고 계속 보인다
반복되는 여러 단계 절차	slash command 또는 skill	필요할 때만 로드돼 startup context를 덜 먹는다
브랜치 분리, 병렬 작업, 충돌 회피	worktree	prompt가 아니라 파일시스템 격리 문제다
조직 정책, 권한, 보안 강제	settings / managed settings	문맥이 아니라 설정 우선순위 문제다

이 표의 포인트는 system prompt를 줄여라 자체가 아니다.

prompt에 들어가면 안 되는 것까지 자꾸 밀어 넣지 마라 에 가깝다.

Claude Code 운영이 지저분해지는 이유는 대개 prompt가 약해서가 아니라 레이어가 섞여서다.

이런 상황이면 지금부터 읽는 편이 낫다

Claude Code를 오래 쓸수록 CLAUDE.md가 점점 길어지고 있다
매번 같은 절차를 chat에 복붙하고 있다
branch, cost, context %, worktree 이름을 계속 직접 확인한다
prompt를 더 붙였는데도 세션이 덜 선명해졌다고 느낀다
slash command와 skill과 CLAUDE.md의 역할이 섞여 있다
병렬 작업을 하면서도 아직 한 워킹트리에서 다 처리한다
.claude/ 폴더가 커지는데 무엇이 startup에 먹히는지 감이 없다

반대로 아직 Claude Code를 딱 한두 번만 테스트하는 단계라면 이 글이 과할 수 있다.

그럴 땐 project CLAUDE.md 하나와 가벼운 permissions만 있어도 충분하다.

이번 글은 이제부터는 장난감이 아니라 운영 도구로 쓰겠다 는 사람에게 맞는다.

왜 system prompt가 자꾸 비대해질까

이건 이상한 일이 아니다.

Claude Code를 쓰다 보면 사람이 겪는 불편이 비슷하기 때문이다.

예를 들면 이런 식이다.

답변이 너무 길다
비용이 얼마나 쌓였는지 안 보인다
지금 어느 브랜치인지 자꾸 헷갈린다
같은 절차를 매번 다시 설명한다
병렬 작업하다가 충돌 난다

이 다섯 개는 진짜로 자주 겪는 문제다.

근데 해결 방식이 자주 틀린다.

전부 prompt에 붙이기 때문이다.

답변 짧게

항상 branch 보여줘

커밋 전에 lint 돌려

테스트 루틴은 이 순서로

작업 하나당 브랜치 분리

이런 걸 하나씩 다 붙이다 보면 prompt가 길어지는 건 당연하다.

문제는 이 다섯 개가 같은 종류의 문제가 아니라는 점이다.

답변 길이는 응답 성향 문제다.

branch 가시성은 관측 문제다.

커밋 전 lint는 절차 문제다.

작업 하나당 브랜치 분리는 실행환경 문제다.

종류가 다른 걸 전부 system prompt로 밀면 설명은 길어지는데 운영은 별로 나아지지 않는다.

오히려 어떤 건 매 턴 필요 없는데도 매 턴 문맥을 먹게 된다.

공식 문서 기준으로 뭐가 어디에 로드되는지 먼저 구분하자

Anthropic Claude Code 문서를 기준으로 레이어를 이렇게 나누면 훨씬 선명해진다.

1. output style은 system prompt를 직접 바꾼다

output styles 문서는 아주 선명하게 적고 있다.

output style은 Claude가 어떻게 응답할지 바꾸는 기능이고, system prompt를 직접 수정한다.

역할, 톤, 출력 형식 같은 걸 여기에 둔다.

그리고 프로젝트 규칙은 CLAUDE.md에 두라고 안내한다.

즉 항상 bullet 4개로 답해 같은 건 output style 쪽이고, 이 프로젝트는 pnpm을 쓴다 같은 건 CLAUDE.md 쪽이다.

이 둘을 섞으면 답변 형식과 프로젝트 사실이 충돌한다.

2. CLAUDE.md는 system prompt 자체가 아니다

memory 문서는 CLAUDE.md가 system prompt 뒤의 user message로 전달된다고 설명한다.

이건 꽤 중요하다.

많은 사람이 CLAUDE.md를 거의 프로젝트용 system prompt 처럼 생각한다.

근데 문서상 구조는 그보다 약하다.

Claude는 CLAUDE.md를 읽고 따르려고 하지만, 모호하거나 충돌하는 지시에는 엄격한 보장이 없다.

그래서 CLAUDE.md는 길고 장황한 선언문보다 구체적인 규칙 문장 모음에 가깝게 써야 한다.

3. CLAUDE.md는 startup context를 먹는다

context window 문서는 세션 시작 전에 CLAUDE.md, auto memory, MCP tool names, skill descriptions가 문맥에 로드된다고 설명한다.

memory 문서는 CLAUDE.md를 200줄 이하로 유지하는 편이 좋고, 200줄이 넘으면 context를 더 먹고 adherence가 떨어질 수 있다고 적는다.

더 무서운 건 CLAUDE.md는 길이와 상관없이 전부 로드된다는 점이다.

즉 한 번 비대해진 CLAUDE.md는 매 세션 startup에서 계속 비용을 먹는다.

한 번만 길면 되지 가 안 된다.

4. skill은 필요할 때만 로드된다

skills 문서는 같은 절차를 자꾸 복붙하거나 CLAUDE.md 일부가 사실이 아니라 절차가 되었을 때 skill을 만들라고 설명한다.

그리고 중요한 문장이 하나 있다.

skill body는 사용될 때만 로드되기 때문에 긴 참고 자료도 필요하기 전까진 startup cost가 거의 없다.

이건 system prompt slimming에 엄청 중요한 포인트다.

항상 필요한 사실 과 가끔 호출하는 절차 를 분리할 수 있기 때문이다.

5. statusline은 로컬에서 실행되고 토큰을 안 쓴다

status line 문서는 status line이 쉘 스크립트를 로컬에서 실행하고, JSON session data를 stdin으로 받아, 출력한 텍스트를 하단에 보여준다고 설명한다.

그리고 더 좋은 문장이 있다.

status line은 로컬에서 돌아가고 API 토큰을 소비하지 않는다.

그러니까 매 턴 보고 싶은 정보는 prompt에 넣지 말고 statusline으로 보내는 편이 훨씬 낫다.

6. worktree는 prompt가 아니라 격리 문제를 푼다

CLI reference 문서는 --worktree가 <repo>/.claude/worktrees/<name> 아래에 격리된 git worktree로 Claude를 시작한다고 설명한다.

settings 문서는 worktree용 symlinkDirectories와 sparsePaths를 지원하고, 대형 monorepo에서는 disk usage와 startup time을 줄일 수 있다고 적는다.

이 말은 곧 병렬 작업 충돌은 prompt 문장 몇 줄로 푸는 문제가 아니라 작업공간 격리 문제라는 뜻이다.

내가 잡는 분리 기준은 아주 단순하다

한 줄 기준으로 줄이면 이렇다.

매 턴 반드시 지켜야 하는 응답 규칙인가

그러면 system prompt 계열이다.

항상 보고 싶은 실시간 상태인가

그러면 statusline이다.

가끔 호출하는 절차인가

그러면 slash command 또는 skill이다.

실행공간을 분리해야 하는가

그러면 worktree다.

이 질문 네 개로 대부분 정리된다.

괜히 철학 세우지 않아도 된다.

분류만 잘해도 prompt는 확 줄어든다.

system prompt에 남겨야 하는 것

내 기준에서 system prompt에 남겨도 되는 건 세 가지다.

1. 응답 형식

예를 들면 이런 거다.

항상 짧게 시작하기
변경점, 리스크, 다음 액션 순서 고정
코드 예시는 fenced block로
한국어로 답하되 코드 식별자는 원문 유지

이건 매 턴 영향을 줘야 하니까 system prompt 계열에 남는 게 맞다.

2. 역할과 톤

reviewer 모드
teacher 모드
operator 모드
terse 모드

이건 output style에 두는 편이 깔끔하다.

Anthropic 문서도 output style이 역할, 톤, 형식을 바꾸는 용도라고 설명한다.

즉 오늘은 설명형 오늘은 학습형 같은 건 output style이 맞고, project facts가 아니다.

3. automation에서 매번 강제할 것

interactive보다는 script나 automation에서 이 호출에서는 반드시 이 규칙을 붙여야 한다 가 있으면 --append-system-prompt 가 맞다.

memory 문서도 system prompt 레벨 지시는 --append-system-prompt가 더 낫고, 이건 interactive보다 automation에 잘 맞는다고 설명한다.

그러니까 CI나 batch job에서 매번 같은 강한 제약을 걸 때는 append-system-prompt가 좋다.

반대로 매일 터미널에서 쓰는 대화형 세션에 자주 바뀌는 운영 규칙을 붙이기엔 불편하다.

system prompt에 남기면 안 좋은 것

1. 비용과 context 사용량

이건 행동 규칙이 아니다.

관측값이다.

statusline 문서는 context window used percentage, cost.total_cost_usd, rate limits, output_style.name까지 statusline JSON에 넣어준다.

즉 이걸 prompt에 써둘 이유가 거의 없다.

항상 context 60% 넘으면 조심해 같은 추상 문장보다, 하단에 실제 숫자가 보이는 편이 더 낫다.

2. branch 이름과 git 상태

이것도 마찬가지다.

statusline 문서에는 workspace.current_dir, workspace.git_worktree, worktree.name, worktree.branch 같은 필드가 있다.

매 턴마다 너는 지금 feature-x 브랜치에 있고 를 prompt에 반복 주입하는 것보다 statusline이 훨씬 정확하다.

3. 커밋 전 절차

이건 절차다.

예를 들면

lint
typecheck
test
commit message template
PR checklist

이런 건 slash command나 skill이 더 잘 맞는다.

항상 읽히는 규칙이 아니라 실행 시점에 불러오는 playbook이기 때문이다.

4. 병렬 작업 분기 규칙

기능마다 브랜치 따로 파 같은 문장을 prompt에 써도 충돌 자체가 사라지진 않는다.

실제로 필요한 건 worktree다.

환경을 나눠야 한다.

이건 지시 품질 문제가 아니라 디렉터리와 브랜치 격리 문제다.

statusline으로 빼야 하는 것

statusline은 Claude에게 지시하는 곳이 아니라 내가 Claude를 관찰하는 곳이다.

이 차이가 중요하다.

내가 statusline으로 빼는 건 보통 다섯 가지다.

1. context 퍼센트

이건 제일 먼저 넣을 만하다.

context window 문서는 startup에 CLAUDE.md, auto memory, skill descriptions가 들어온다고 설명한다.

긴 세션에선 읽은 파일, assistant 응답, subagent 요약이 계속 쌓인다.

그런데 많은 사람이 언제 위험해지는지 숫자로 안 본다.

statusline에 used_percentage만 보여줘도 세션 운영 감각이 달라진다.

2. 비용

cost.total_cost_usd가 statusline JSON에 있다.

이건 꽤 쎄다.

비용이 보이면 prompt를 더 붙일지, 세션을 갈아탈지, subagent로 보낼지, compact할지 판단이 빨라진다.

반대로 비용이 안 보이면 사람은 시스템 prompt를 계속 만지다가 정작 세션 구조 문제를 놓친다.

3. worktree 이름과 branch

병렬 작업을 하다 보면 지금 어느 worktree인지 헷갈리는 순간이 온다.

특히 여러 Claude Code 세션을 동시에 띄우면 더 그렇다.

statusline이 worktree.name이나 workspace.git_worktree를 보여주면 실수가 줄어든다.

이건 prompt보다 훨씬 낫다.

prompt는 기억을 요구하고, statusline은 시야를 준다.

4. output style 이름

statusline 문서는 output_style.name도 제공한다.

이게 왜 좋냐면, 지금 세션이 default인지 explanatory인지 눈에 보여야 답변 길이나 톤이 왜 다른지 바로 이해할 수 있기 때문이다.

output style을 바꿨는데 세션을 재시작 안 해서 반영 안 된 경우도 눈치채기 쉬워진다.

5. added_dirs

추가 디렉터리를 붙여 쓰는 사람이라면 added_dirs도 꽤 중요하다.

특히 monorepo나 docs repo를 함께 열어두는 경우, 어떤 디렉터리가 붙어 있는지 보이면 왜 Claude가 특정 파일을 읽는지 감이 빨라진다.

slash command나 skill로 빼야 하는 것

Anthropic 문서는 이제 custom commands가 skills로 합쳐졌다고 설명한다.

.claude/commands/deploy.md 도 여전히 작동하지만, skill이 더 많은 기능을 지원하니 새로 만들 거면 skill을 우선 권한다.

그래도 현업 감각에선 사람들이 여전히 /무언가라고 부르니까 여기선 slash command와 skill을 같이 묶어 말하겠다.

내 기준으로 아래에 해당하면 system prompt에서 빼고 slash command나 skill로 보내는 게 맞다.

1. 매번 똑같은 절차

/commit
/ship
/review
/retro
/postmortem
/lint-fix

이런 건 프로젝트 facts가 아니라 재사용 절차다.

skills 문서도 같은 playbook, checklist, multi-step procedure를 자꾸 붙여넣는다면 skill을 만들라고 한다.

그리고 중요한 장점이 하나 더 있다.

skill body는 사용될 때만 로드된다.

즉 길고 자세한 절차를 CLAUDE.md에서 빼도 된다.

2. 긴 참고자료가 붙는 절차

예를 들어

배포 템플릿
보안 체크리스트
PR 설명 예시
장문의 에러 대응 흐름

이런 건 한 번 불릴 때는 길어도 괜찮다.

대신 모든 세션 startup에서 계속 읽힐 필요는 없다.

skill은 바로 이럴 때 좋다.

3. 자동 호출돼도 괜찮은 절차

skills 문서는 description을 통해 Claude가 관련 상황에서 자동으로 불러올 수 있게 한다.

즉 이 상황이면 이 playbook을 쓰는 게 맞다 가 분명하다면, skill이 잘 맞는다.

system prompt보다 더 좁고, user가 매번 직접 복붙하지 않아도 된다.

4. 프로젝트별로 갈리는 절차

user-level preference와 달리 project마다 다른 절차는 project skill로 분리하는 편이 낫다.

Anthropic 문서는 project .claude/skills/<skill-name>/SKILL.md 를 지원한다.

팀 공용 레포라면 개인 취향은 user scope에, 프로젝트 playbook은 project skill에 두는 편이 덜 싸운다.

worktree로 빼야 하는 것

여기서 제일 많이 헷갈리는 게 이거다.

작업 분리 규칙을 prompt에 쓰면 병렬 운영도 해결되겠지

아니다.

충돌 문제는 문장보다 환경이 먼저다.

CLI reference는 --worktree가 격리된 git worktree를 만들어 준다고 설명한다.

settings 문서는 대형 monorepo에서는 symlinkDirectories와 sparsePaths로 disk usage와 startup time을 줄일 수 있다고 적는다.

이건 곧 worktree가 단순 branch 분리 얘기가 아니라 운영 성능까지 연결된다는 뜻이다.

내 기준에서 아래 셋 중 하나면 prompt보다 worktree를 먼저 본다.

1. 파일 충돌 가능성이 높다

한 세션은 auth, 다른 세션은 billing, 세 번째는 docs.

이렇게 명확히 갈린다면 worktree가 맞다.

같은 디렉터리에서 세 세션이 한꺼번에 edit하면 사람도 헷갈리고 git도 헷갈린다.

2. 병렬로 오래 돌린다

몇 분짜리 짧은 작업은 한 워킹트리에서도 버틸 수 있다.

근데 두 시간, 반나절, 하루 이상 길어지면 worktree의 이점이 커진다.

세션마다 브랜치, 변경 파일, 실험 상태가 섞이지 않기 때문이다.

3. monorepo라 startup 비용이 크다

settings 문서가 worktree.symlinkDirectories, worktree.sparsePaths를 따로 둔 이유가 여기 있다.

대형 repo라면 병렬 작업에서 매번 풀체크아웃하는 것보다 symlink와 sparse path를 써서 startup time과 disk usage를 줄이는 편이 낫다.

즉 worktree는 단순 clean branch 강박이 아니라 속도 레버이기도 하다.

이 볼트에서 보면 더 선명하다

지금 이 Obsidian 볼트만 봐도 분리 기준이 왜 필요한지 바로 보인다.

내가 방금 셈해보니 이 볼트의 .claude/CLAUDE.md는 현재 330줄이다.

그리고 .claude/commands 아래에는 28개 파일이 있다.

이 숫자는 꽤 상징적이다.

만약 이 28개의 절차를 전부 CLAUDE.md에 몰아넣는다고 생각해 보자.

startup context는 더 무거워지고, 규칙과 절차가 섞이고, 어떤 건 매 턴 필요 없는데도 계속 읽히게 된다.

memory 문서가 CLAUDE.md는 200줄 이하를 권장하고, 길어질수록 adherence가 떨어질 수 있다고 적는 이유가 바로 이런 구조 때문이다.

반대로 playbook은 command나 skill로, 실시간 수치와 상태는 statusline으로, 병렬 작업은 worktree로 보내면 CLAUDE.md는 정말 공유해야 할 사실과 기준만 남길 수 있다.

그러면 Claude가 덜 멍해진다기보다 우리가 덜 멍해진다.

이게 더 정확하다.

어디에 무엇을 두면 좋나

내 기준 운영표를 한 장으로 적으면 이렇다.

항목	system prompt / output style	CLAUDE.md	statusline	slash command / skill	worktree
답변 톤	O	△	X	X	X
출력 형식	O	△	X	△	X
프로젝트 규칙	X	O	X	△	X
빌드·테스트 절차	X	△	X	O	X
비용/컨텍스트 가시성	X	X	O	X	X
branch / worktree 표시	X	X	O	X	O
병렬 충돌 회피	X	X	X	X	O
긴 참고자료	X	X	X	O	X

여기서 △는 못 두는 건 아니지만 1순위는 아니라는 뜻이다.

예를 들어 출력 형식을 CLAUDE.md에 쓸 수도 있다.

근데 Anthropic 문서상 그건 system prompt보다 약한 층이다.

그러니 정말 매 턴 적용돼야 하는 형식이면 output style이 더 자연스럽다.

반대로 프로젝트 규칙을 system prompt에 강제로 붙이는 건 자동화 스크립트가 아니라면 불편해질 수 있다.

10분 안에 system prompt를 슬림하게 만드는 순서

여기서부터는 말만 번지르르하면 의미 없으니까 실전 순서를 적겠다.

1단계. 지금 prompt에 있는 문장을 종류별로 나눈다

각 문장을 보고 이 질문만 하면 된다.

응답 성향인가
프로젝트 사실인가
실시간 상태인가
절차인가
환경 격리 문제인가

이렇게 나눠보면 벌써 절반은 빠진다.

2단계. 매 턴 안 필요한 절차를 빼낸다

커밋, 릴리즈, 리뷰, 포스트모템, 디버깅 루틴.

이런 건 command나 skill로 보낸다.

skills 문서가 말한 keep pasting the same playbook 상황이면 거의 무조건 대상이다.

3단계. 실시간 숫자와 위치 정보를 prompt에서 지운다

현재 branch
현재 worktree
cost
context %
rate limit

이건 statusline으로 옮긴다.

문서 기준으로 로컬 실행이고 토큰도 안 쓴다.

4단계. 병렬 작업 규칙은 worktree로 바꾼다

작업 하나당 branch 분리 같은 문장을 그냥 지시로만 남기지 말고 실제로 --worktree나 git worktree 운영으로 바꾼다.

문제를 말로 해결하지 말고 환경으로 해결하는 단계다.

5단계. 남은 것만 output style과 CLAUDE.md에 다시 적는다

마지막까지 남는 건 정말 중요한 것뿐이어야 한다.

예를 들면 이런 정도다.

짧고 구조화된 답변 선호
프로젝트 기본 빌드 도구
팀 공용 테스트 진입점
코드 리뷰 시 반드시 짚을 보안 규칙

그 이상이면 대개 다른 레이어가 더 맞다.

6단계. 새 세션에서만 확인한다

output style 문서는 system prompt가 세션 시작 시 고정되고, 변경은 새 세션에서 반영된다고 설명한다.

그러니까 중간에 파일만 고치고 왜 안 바뀌지 하면 안 된다.

새 세션에서 다시 봐야 한다.

내가 실제로 남기는 최소 세트

내가 Claude Code를 오래 돌릴 때 system prompt 계열에 남기는 건 정말 적다.

예를 들면 이런 수준이다.

답변은 짧고 운영형으로
변경점, 리스크, 다음 액션을 분리
불확실하면 질문 또는 보수적 판단
코드 블록과 명령은 명확히 구분

그리고 프로젝트 쪽 CLAUDE.md에는 이 정도를 둔다.

이 repo에서 쓰는 빌드 도구
테스트 진입점
금지 경로
팀 공용 naming / branch / review 기준

그 밖의 것들, 예를 들면 배포 루틴, 문서화 루틴, 블로그 초안 생성 루틴, 하네스 점검 루틴 같은 건 command나 skill로 뺀다.

그리고 지금 얼마 썼지 어느 worktree지 같은 건 statusline으로 본다.

이렇게 하면 세션이 한결 덜 시끄럽다.

흔한 실수 7개

1. CLAUDE.md를 system prompt랑 같은 걸로 본다

공식 문서상 둘은 다르다.

CLAUDE.md는 system prompt 뒤의 user message다.

이 차이를 무시하면 왜 어떤 지시는 잘 먹고 어떤 지시는 흔들리는지 이해가 안 된다.

2. 200줄 넘어도 그냥 둔다

memory 문서는 200줄을 넘는 CLAUDE.md가 context를 더 먹고 adherence를 낮출 수 있다고 말한다.

한 번 넘었다고 망하진 않는다.

근데 계속 커지는 구조는 거의 항상 문제가 된다.

3. statusline에 지시를 넣으려 한다

statusline은 관측용이다.

스크립트가 출력하는 텍스트를 보여주는 거지, Claude 행동 규칙을 저장하는 곳이 아니다.

4. slash command나 skill에 사실을 넣는다

프로젝트 사실은 필요할 때만 불리는 절차가 아니다.

그러니까 이 repo는 bun을 쓴다 같은 기본 사실은 CLAUDE.md가 더 낫다.

5. 병렬 작업 충돌을 prompt로 해결하려 한다

이건 진짜 자주 본다.

항상 다른 파일만 만져 라고 써도 실제 충돌 가능성이 사라지진 않는다.

환경 격리가 필요하면 worktree를 써야 한다.

6. output style 변경 후 같은 세션에서 결과를 판단한다

문서 기준으로 output style은 새 세션에서 반영된다.

같은 세션에서 왜 그대로지 하면 진단이 틀어진다.

7. command와 skill을 둘 다 중복으로 만든다

Anthropic 문서는 custom commands가 skills에 합쳐졌다고 설명한다.

같은 이름을 양쪽에 다 두면 헷갈리기 쉽다.

새로 만드는 건 skill 쪽으로 정리하는 편이 낫다.

FAQ

Q1. 그럼 system prompt는 최대한 짧을수록 좋은가

무조건 그렇진 않다.

짧은 게 목적이 아니라 레이어가 맞는 곳에 들어가는 게 목적이다.

응답 형식, 역할, 톤처럼 매 턴 지켜야 하는 건 system prompt 계열에 남는 게 맞다.

문제는 절차, 실시간 상태, 환경 격리까지 전부 넣어버릴 때다.

Q2. CLAUDE.md를 비우고 전부 skill로 옮기면 되나

그것도 아니다.

프로젝트 공용 사실과 기준은 여전히 CLAUDE.md가 맞다.

skills 문서도 절차가 된 부분을 skill로 빼라고 설명한다.

즉 fact와 procedure를 나누는 게 핵심이다.

Q3. slash command보다 skill이 더 나은 이유는 뭐야

공식 문서 기준으로 custom commands는 skills에 합쳐졌다.

skill은 supporting files, frontmatter, automatic loading, subagent execution 같은 추가 기능이 있다.

기존 .claude/commands/도 계속 작동하지만, 새 구조는 skill 쪽이 더 풍부하다.

Q4. statusline을 꼭 써야 하나

필수는 아니다.

근데 비용, context, branch, worktree를 자꾸 직접 확인하는 사람이라면 statusline이 생각보다 빨리 값을 한다.

게다가 로컬에서 돌고 토큰도 안 쓴다.

이 장점이 꽤 크다.

Q5. worktree는 언제부터 진짜 필요해지나

내 기준으로는 두 세션 이상이 같은 repo에서 한 시간 이상 병렬로 돌기 시작하면 필요성이 확 커진다.

특히 edit가 겹치거나 branch 분기를 자주 타는 팀이면 prompt보다 worktree가 먼저다.

Q6. output style, CLAUDE.md, append-system-prompt 중 뭘 먼저 써야 하나

interactive 세션 기준이면 보통 이 순서가 편하다.

output style로 응답 형식과 톤
CLAUDE.md로 프로젝트 사실과 규칙
append-system-prompt는 automation이나 script 호출에만

문서도 append-system-prompt는 interactive보다 automation에 더 잘 맞는다고 설명한다.

Q7. 큰 monorepo라 worktree가 무겁다면 어떻게 해

settings 문서에 worktree.symlinkDirectories와 worktree.sparsePaths가 있다.

대형 repo에선 이 두 개를 같이 보면 disk usage와 startup time을 꽤 줄일 수 있다.

Q8. `.claude/commands`를 이미 많이 쓰고 있으면 다 갈아엎어야 하나