AI 가이드

세션이 지나는 시간

1. 도구와 설정을 갖출 때

   팁 2

   • CLAUDE.md는 200줄 아래로 유지하고, 가끔 쓰는 워크플로는 스킬로 옮긴다.

     CLAUDE.md는 세션 시작마다 통째로 실린다 — PR 리뷰나 마이그레이션 절차를 적어 두면 무관한 일을 할 때도 그 토큰을 낸다. 스킬은 부를 때만 올라온다. Claude Code Docs — Manage costs effectively

   • GitHub·AWS 같은 외부 서비스는 MCP 서버 대신 gh·aws 같은 CLI로 부른다.

     CLI는 도구 목록을 컨텍스트에 한 줄도 안 얹는다. 안 쓰는 MCP 서버는 /mcp로 꺼 두고, 무엇이 자리를 먹는지는 /context로 본다. Claude Code Docs — Manage costs effectively

2. 모델과 추론 강도를 고를 때

   팁 2

   • 모델과 추론 강도(effort)는 세션 맨 앞에서 정하고 도중에 바꾸지 않는다.

     모델마다·강도마다 캐시가 따로다. 중간에 바꾸면 다음 요청이 대화 전체를 캐시 없이 다시 읽는다 — 내용이 한 글자도 안 바뀌었어도 그렇다. 모델은 예외가 없고 강도는 대부분의 모델에서 갈린다(Opus 5.5와 Fable 5.1은 API 키·구독에서 강도를 바꿔도 캐시가 남는다). Claude Code Docs — How Claude Code uses prompt caching

   • 대화가 길어진 뒤에는 쉬운 질문이라도 싼 모델로 갈아타지 않는다 — 갈아타는 쪽이 더 비싸다.

     모델을 바꾸면 그 시점까지의 전체 대화를 캐시 없이 다시 읽는다. 쌓인 컨텍스트가 클수록 갈아타는 값이 그냥 비싼 모델로 답하는 값을 넘는다. Anthropic 블로그 — Lessons from building Claude Code: Prompt caching is everything

3. 자료를 넣거나 일을 나눌 때

   팁 2

   • 테스트 실행·문서 수집·로그 처리처럼 출력이 긴 일은 서브에이전트에 맡긴다.

     장황한 중간 출력이 자식 컨텍스트에 남고 본 대화에는 요약만 돌아온다. 본 대화는 그 요약만 이후 모든 턴에 다시 싣는다. Claude Code Docs — Manage costs effectively

   • 대화에 남길 필요 없는 곁가지 질문은 /btw로 묻는다.

     답이 대화 기록에 아예 안 들어가므로, 하나 확인하자고 컨텍스트를 불리지 않는다. Claude Code Docs — Best practices for Claude Code

4. 대화가 길어지거나 일이 바뀔 때

   팁 3

   • 관계없는 일로 넘어가면 /clear로 대화를 비우고 새로 시작한다.

     남은 옛 맥락은 이후 모든 메시지마다 다시 실려 나간다. 두 번 고쳐 줬는데도 안 되면 그때도 이어 붙이지 말고 /clear 뒤에 배운 것을 넣어 다시 묻는 편이 싸다. Claude Code Docs — Manage costs effectively

   • 이어 갈 일에서 컨텍스트 창이 차오르면 자동 압축을 기다리지 말고 /compact을 직접 친다.

     압축은 대화 층의 캐시를 반드시 깨므로 비용이 어차피 한 번은 든다. 그 비용을 일의 한가운데가 아니라 작업과 작업 사이에 치르게 고르는 것이다. Claude Code Docs — How Claude Code uses prompt caching

   • 가던 길을 통째로 버릴 때는 /compact 대신 /rewind로 되감는다.

     되감기는 이미 캐시에 있는 접두사까지 잘라 내는 것이라 캐시를 그대로 탄다. 압축은 없던 접두사를 새로 만든다. Claude Code Docs — How Claude Code uses prompt caching

고치는 값이 커지는 순서

1. 일을 처음 넘길 때

   팁 2

   • 접근이 불확실하거나 파일 여럿을 건드리는 일은 Shift+Tab으로 계획 모드에 들어가 계획부터 받는다.

     곧바로 코딩에 들어가면 엉뚱한 문제를 푼 코드가 나온다. 계획 모드에서는 파일을 안 고치고 읽고 답하기만 하므로 방향을 먼저 바로잡을 수 있다. 다만 계획에도 값이 붙는다 — 한 문장으로 diff를 설명할 수 있으면 건너뛴다. Ctrl+G를 누르면 계획을 에디터에서 직접 고친 뒤 실행시킬 수 있다. Claude Code Docs — Best practices

   • 큰 기능은 곧바로 시키지 말고 나를 인터뷰하게 해 SPEC.md를 받고, 실행은 그 파일만 든 새 세션에서 한다.

     인터뷰는 내가 아직 안 정한 것을 묻는다 — 구현·UI·엣지 케이스·트레이드오프. 쓸 만한 스펙은 자족적이다: 관련 파일과 인터페이스를 이름으로 적고, 범위 밖을 못 박고, 끝에 동작을 증명할 검증 단계를 둔다. 그러면 실행 세션은 인터뷰 기록 없이 그 파일만 들고 시작한다. Claude Code Docs — Best practices

2. 완료를 확인하게 할 때

   팁 2

   • 일을 맡길 때 통과·실패가 나오는 확인 수단을 같이 준다 — 세션 내내 걸려면 /goal에 조건으로 둔다.

     확인이 없으면 「다 된 것 같다」가 유일한 신호라 사람이 검증 고리를 대신한다. 테스트·빌드 종료 코드·스크린샷 비교처럼 Claude가 대화에서 읽을 수 있는 통과·실패를 주면 스스로 돌려 보고 고치기를 되풀이한다. 한 프롬프트 안에 「돌려 보고 고쳐라」로 붙이는 것이 가장 싸고, 세션 내내 걸려면 /goal 조건이 매 턴 다시 검사한다. Claude Code Docs — Best practices

   • 끝났다고 치기 전에 /code-review로 diff만 보는 새 컨텍스트의 리뷰어를 한 번 붙인다.

     리뷰어는 그 변경을 만든 추론을 못 보고 diff와 내가 준 기준만 본다 — 만든 쪽이 채점하지 않는다. 계획 대비로 볼 때는 리뷰 프롬프트를 직접 쓴다. 다만 빈틈을 찾으라 시키면 멀쩡한 코드에서도 찾아내므로 「정확성이나 적어 둔 요구사항에 걸리는 것만」이라고 못 박는다. Claude Code Docs — Best practices