Claude Code 3개월 사용 후, 이 9가지 베스트 프랙티스가 수많은 우회로를 막아줬습니다

Claude Code를 3개월 사용하면서 가장 큰 함정은 프롬프트 작성 실력이나 잘못된 모델 선택이 아니었습니다. 대부분의 사람들이 인식조차 하지 못하는 것이었죠: 바로 컨텍스트 윈도우입니다.

마치 방 안의 코끼리 같습니다. Claude가 점점 멍청해지는 것 같아서 모델 문제라고 생각하지만, 실제로는 화이트보드가 꽉 찬 것뿐입니다.

이 글에서는 "컨텍스트 초보"에서 "컨텍스트 관리 전문가"가 되기까지의 전체 경험을 공유하겠습니다. 모든 내용은 실전에서 검증되었습니다.

Claude Code를 사용하고 있다면, 이 글이 수십 시간의 낭비를 막아줄 수 있습니다.

자, 시작해보겠습니다.

먼저 한 가지를 이해하세요: 컨텍스트 윈도우가 정확히 무엇인가요?#

Claude의 두뇌에는 화이트보드가 있습니다.

보내는 모든 메시지, Claude가 읽는 모든 파일, 실행하는 모든 명령어가 이 화이트보드에 기록됩니다.

화이트보드가 가득 차면 Claude의 성능이 저하되기 시작합니다. 한 시간 전에 준 지시를 잊어버리고, 해서는 안 될 실수를 하며, 반복적인 행동을 보입니다.

그래서 가끔 "Claude가 멍청해졌다"고 느끼는 겁니다. 멍청해진 게 아니라, 기억을 못 하는 거예요.

Claude Code 창시자 Boris Cherny가 말했듯이:

Claude Code를 잘 사용하려면, 이 화이트보드를 관리하는 것이 핵심입니다.

이것을 이해하면 다음 모든 전략이 의미를 갖게 됩니다.

전략 1: Claude가 바로 코드를 작성하게 하지 마세요#

거의 모든 초보자가 빠지는 첫 번째 함정입니다.

요구사항을 설명하면 Claude가 즉시 코드를 작성하기 시작합니다. 15분 후에야 원했던 것과 완전히 다른 문제를 해결하고 있다는 것을 깨닫게 됩니다.

더 나쁜 것은, 그 15분 동안의 코드 생성이 이미 컨텍스트 공간의 상당 부분을 소모했다는 점입니다.

올바른 접근 방식: 먼저 Plan Mode로 전환하세요.

Claude Code에는 Plan Mode가 있으며, Shift+Tab을 눌러 활성화할 수 있습니다.

이 모드에서 Claude는 파일만 읽고 생각을 정리하며, 코드는 전혀 건드리지 않습니다.

제 현재 표준 워크플로우는 다음과 같습니다:

1️⃣ Plan Mode로 전환하여 Claude가 관련 파일을 읽고 연결 관계를 이해하게 합니다.

2️⃣ Claude가 완전한 계획을 작성하게 합니다: 어떤 파일을 변경할지? 단계 순서는? 문제가 발생할 수 있는 부분은?

3️⃣ 제가 직접 계획을 검토하고 필요하면 수정합니다.

4️⃣ 일반 모드로 전환하여 계획에 따라 개발을 진행합니다.

5️⃣ Claude가 명확한 커밋 메시지와 함께 코드를 커밋하게 합니다.

추가로 10분을 계획에 투자하면 수없이 많은 재작업을 피할 수 있습니다.

Boris의 팀에서는 어떤 사람이 한 Claude로 계획을 작성하고, 다른 Claude가 시니어 엔지니어 역할을 하여 계획을 검토하기도 합니다. 그만큼 계획 단계를 중요하게 생각합니다.

전략 2: 서브에이전트를 사용하여 메인 전장을 보호하세요#

화이트보드 비유로 돌아가겠습니다.

Claude가 문제를 조사할 때 많은 파일을 읽습니다. 로그, 설정, 코드 등 모든 것을 읽고 나면 화이트보드가 반쯤 찹니다. 연구를 마치고 코드를 작성할 준비가 되었을 때는 공간이 충분하지 않습니다.

서브에이전트가 이 문제를 완벽하게 해결합니다.

서브에이전트는 독립적인 Claude 인스턴스로, 자체 컨텍스트 윈도우 내에서 작업합니다. 결과를 보고하지만 메인 세션의 화이트보드 공간을 차지하지 않습니다.

사용법은 매우 간단합니다: 연구 작업 뒤에 "서브에이전트 사용"을 추가하기만 하면 됩니다.

"서브에이전트를 사용하여 결제 흐름이 실패한 트랜잭션을 어떻게 처리하는지 조사해줘."

서브에이전트가 모든 데이터를 읽고, 메인 세션은 깨끗하게 유지됩니다. 보고서를 받은 후에도 계속 개발할 충분한 공간이 남아 있습니다.

이것은 현재 제가 가장 자주 사용하는 트릭입니다. 단연코요.

Java 백엔드 개발자로서 복잡한 분산 시스템 문제를 해결해야 하는 경우가 많습니다. 과거에는 한 번의 문제 해결 작업이 전체 세션을 망칠 수 있었습니다. 이제는 "로그 읽기, 소스 코드 확인, 호출 체인 분석"과 같은 모든 작업을 서브에이전트에 넘기고, 메인 세션은 결정을 내리고 코드만 작성합니다.

효율성 차이가 엄청납니다.

전략 3: CLAUDE.md는 "살아있는 규칙집"입니다#

Claude Code를 매일 사용하면서 CLAUDE.md를 제대로 관리하지 않는다면, 많은 효율성을 낭비하고 있는 것입니다.

CLAUDE.md는 Claude가 시작할 때마다 읽는 파일입니다. 작성한 규칙에 따라 Claude가 여러분과 함께 작업합니다.

자주 반복하는 것들을 생각해보세요:

"ES 모듈을 사용하고 CommonJS는 사용하지 마"
"테스트에 모의 객체를 사용하지 마"
"코드 변경 후 린터를 실행해"
"브랜치 이름 형식은 feature/ticket-number야"

CLAUDE.md가 없으면 매번 말해야 합니다. CLAUDE.md가 있으면 한 번만 말하면 됩니다.

하지만 가장 중요한 트릭은 이것입니다:

Claude가 실수를 하고 여러분이 수정할 때마다, 마지막에 다음 줄을 추가하세요:

"이 실수를 다시 하지 않도록 CLAUDE.md를 업데이트해."

Claude는 교훈을 자신의 규칙에 기록할 것입니다. 시간이 지나면서 CLAUDE.md는 여러분에게 최적화된 "살아있는 문서"가 됩니다.

제 CLAUDE.md의 한 규칙은 이렇게 생겼습니다: Claude가 Obsidian Vault 내부에 .txt 파일을 계속 생성하는 것을 발견했습니다(Obsidian은 이를 표시하지 않습니다). 한 번 수정한 후 "Vault 내부에는 .md 파일만 생성해"라는 규칙을 추가했습니다. 그 이후로 같은 실수를 반복하지 않았습니다.

⚠️ 하지만 한 가지 주의할 점이 있습니다: CLAUDE.md는 너무 길면 안 됩니다.

500줄에 도달하면 Claude의 주의가 분산되어 일부 규칙이 무시됩니다. 모든 규칙은 다음 질문에 답해야 합니다: 이 규칙이 없으면 Claude가 실수를 할까? 그렇지 않다면 삭제하세요.

전략 4: Claude에게 자체 점검 기회를 주세요#

대부분의 사람들의 사용 패턴은 다음과 같습니다: 요구사항 설명 → Claude가 올바르게 작성하기를 기도 → 직접 한 줄씩 수동 확인.

이렇게 하면 여러분이 유일한 품질 검사자가 됩니다. 믿으세요, 정말 지치는 일입니다.

더 나은 접근 방식: 프롬프트에 검증 기준을 포함하세요.

예를 들어, 이메일 유효성 검사 함수를 작성하려면 "이메일 유효성 검사 함수를 작성해"라고만 말하지 마세요.

이렇게 말하세요:

"이메일이 유효한지 판단하는 함수를 작성해. 다음 케이스로 테스트해: hello@gmail.com은 통과해야 하고, hello@는 실패해야 하며, @domain.com은 실패해야 해. 작성 후 테스트를 실행해."

이제 Claude가 스스로 점검할 수 있으므로, 모든 줄을 지켜볼 필요가 없습니다.

시각적 작업에도 적용됩니다. 버튼 디자인을 변경해야 하나요? 스크린샷을 붙여넣고 이렇게 말하세요: "이렇게 보이게 만들어. 변경 후 스크린샷을 찍어서 무엇이 다른지 알려줘."

Claude에게 비교 기준을 제공하여 유일한 피드백 루프가 되는 것을 피하세요. 이 트릭은 수 시간을 절약할 수 있습니다.

전략 5: 기술 문서를 작성하듯 프롬프트를 작성하세요#

Claude는 컨텍스트에서 많은 것을 추론할 수 있지만, 여러분의 마음을 읽을 수는 없습니다.

차이를 비교해보세요:

❌ 모호함: "auth.py에 테스트를 추가해"

✅ 구체적: "사용자 세션이 요청 중간에 만료되는 시나리오를 다루는 auth.py 테스트를 작성해. 모의 객체를 사용하지 마. 토큰이 유효해 보이지만 실제로는 만료된 엣지 케이스에 집중해."

같은 작업이지만 결과는 완전히 다릅니다.

Claude가 어디를 봐야 하는지 직접 가리킬 수도 있습니다.

❌ "이 함수가 왜 이상하게 작동하지?"

✅ "이 파일의 git 히스토리를 살펴봐서 이 동작이 언제 추가되었고 왜 그런지 찾아봐."

차이는: Claude가 무작위로 추측하는가, 아니면 구체적인 답변을 제공하는가입니다.

백엔드 개발자로서 제 프롬프트 작성 습관은 이제 다음과 같습니다: 입력 지정, 출력 지정, 제약 조건 지정, 검증 방법 지정. API 문서를 작성하듯이 하세요.

전략 6: 30-45분마다 컨텍스트 리셋하기#

Claude와 한동안 대화하다 보면, 점차 주제에서 벗어나기 시작하는 것을 느낄 수 있습니다.

같은 말을 반복하고, 이전에 준 규칙을 잊어버리며, 답변 품질이 눈에 띄게 떨어집니다.

이것이 바로 컨텍스트 오염입니다. 화이트보드가 가득 차서 Claude가 기존 내용을 덮어쓰기만 할 수밖에 없게 된 것입니다.

Boris 팀은 복잡한 작업 중 30-45분마다 컨텍스트를 리셋합니다.

방법은 다음과 같습니다:

1️⃣ Claude에게 현재 진행 상황을 요약하도록 요청합니다: "지금까지 한 일, 남은 작업, 현재 존재하는 문제를 요약해줘."

2️⃣ 새 세션을 시작합니다.

3️⃣ 요약 내용을 붙여넣고 계속 진행합니다.

이렇게 하면 Claude의 사고를 명확하게 유지하고, 긴 세션으로 인한 "뇌 안개"를 방지할 수 있습니다.

많은 사람들이 "모든 컨텍스트가 거기에 있으니" 세션을 종료하는 것을 꺼려합니다. 하지만 실제로는, 비대해진 컨텍스트보다 정제된 요약이 훨씬 낫습니다.

전략 7: 병렬 세션 + Git Worktree#

이것은 Boris 팀이 인정한 생산성 킬러 앱입니다.

여러 개의 Claude Code 세션을 동시에 열고, git worktree(코드베이스의 독립적인 작업 복사본)와 함께 사용하면 서로 간섭하지 않습니다.

예를 들어:

🅰️ 세션 A는 새 기능 작성을 담당합니다.

🅱️ 세션 B는 A가 작성한 코드를 리뷰하는 역할을 합니다.

A의 결과물을 B에게 넘겨서 엣지 케이스와 결함을 찾게 합니다. 그런 다음 피드백을 다시 A에게 가져옵니다.

한 Claude가 작성하고, 다른 Claude가 리뷰합니다. 더 높은 코드 품질, 더 빠른 효율성.

어떤 사람들은 3-5개의 세션을 동시에 열고, worktree에 이름을 지정하고, 셸 별칭(za, zb, zc)을 설정하여 원클릭으로 전환합니다.

테스트 주도 개발에도 동일한 방법을 사용할 수 있습니다: 한 Claude가 먼저 테스트를 작성하고, 다른 Claude가 테스트를 통과하는 코드를 작성합니다. TDD이지만, 모든 무거운 작업은 Claude가 수행합니다.

전략 8: 반복 작업을 스킬로 캡슐화하기#

Claude Code에서 하루에 두 번 이상 동일한 작업을 반복한다면, 이를 스킬로 전환해야 합니다.

스킬은 기본적으로 저장된 워크플로우입니다. 단계를 작성하고 이름을 지정한 다음, 나중에 이름만 호출하면 됩니다.

저는 직접 12개 이상의 스킬을 캡슐화했습니다: 커버 이미지 생성, 글 게시, 이미지 압축, 웹페이지를 마크다운으로 변환...

각각은 "매번 전체 프롬프트를 수동으로 말하는 것"에서 "하나의 명령으로 끝내는 것"으로 진화했습니다.

Boris의 규칙은 채택할 가치가 있습니다: 하루에 두 번 이상 수행한다면, 스킬로 캡슐화하세요.

Boris 팀은 BigQuery용 스킬을 구축하여 팀원들이 SQL을 전혀 작성하지 않고도 Claude Code에서 직접 데이터 분석 쿼리를 수행할 수 있게 했습니다. 하나의 스킬로 모든 프로젝트에서 재사용 가능합니다.

전략 9: 추측이 아닌 실제 데이터 제공하기#

전통적인 버그 수정 프로세스는 다음과 같습니다:

버그를 말로 설명 → Claude가 몇 번 잘못 추측 → 몇 번 수정 → 마침내 해결.

그 사이에 낭비되는 컨텍스트 공간이 엄청납니다.

더 빠른 접근 방식: Claude에게 실제 오류 정보를 제공하고, 그냥 자리를 뜨세요.

Boris 팀은 Slack MCP를 통합했습니다. Slack에서 버그가 보고되면, 대화 내용을 그대로 Claude에 붙여넣고 "수정"이라는 한 단어만 던집니다.

추가 설명도, 세세한 지도도 필요 없습니다. Claude가 대화를 읽고 문제를 찾아 수정합니다.

또는 "실패한 CI 테스트를 수정해줘"라고 말하고 자리를 뜹니다. 어떤 테스트인지 알려주지 않고, 왜 실패했는지 설명하지 않아도 Claude가 알아서 파악합니다.

핵심은: Claude에게 실제 데이터(Slack 스레드, 오류 로그, Docker 출력)를 제공하고, 문제에 대한 여러분의 추측은 제공하지 말라는 것입니다.

Claude는 분산 시스템 로그를 읽고 실패 지점을 정확히 찾아내는 데 탁월합니다. 백엔드 개발자로서 이것은 저에게 기분 좋은 놀라움이었습니다.

모든 것을 하나로: 나의 일일 워크플로우#

이제 위의 모든 전략을 연결한 제 일반적인 일일 워크플로우를 공유하겠습니다:

작업 시작 전:

CLAUDE.md 업데이트가 필요한지 확인합니다.
Plan Mode가 필요한지 작업 복잡성을 평가합니다.

작업 실행 중:

복잡한 연구하위 에이전트에 위임합니다.
코드 작성메인 세션 + 특정 프롬프트 + 내장 검증.
코드 리뷰두 번째 세션을 엽니다.

30-45분마다:

Claude에게 진행 상황을 요약하도록 합니다.
컨텍스트 리셋이 필요한지 평가합니다.

작업 완료 후:

Claude가 저지른 실수CLAUDE.md 업데이트.
반복 작업스킬로 캡슐화합니다.

이 워크플로우는 제 효율성을 최소 3배 향상시켰습니다. Claude가 더 강력해져서가 아니라, Claude의 "두뇌"를 관리하는 방법을 배웠기 때문입니다.

마지막 말#

기사 서두의 비유로 돌아가 보겠습니다.

컨텍스트 윈도우는 Claude의 화이트보드입니다. 화이트보드의 크기는 고정되어 있지만, 무엇을 쓸지, 언제 지우고 다시 시작할지는 여러분이 결정합니다.

컨텍스트를 관리하는 것은 본질적으로 AI의 주의를 관리하는 것입니다.

이것은 새로운 기술입니다. 프로그래밍 능력이나 도메인 지식과는 관련이 없지만, AI로부터 얼마나 많은 가치를 얻을 수 있는지를 결정합니다.

빨리 익힐수록, 빨리 혜택을 볼 수 있습니다.

여러분이 경험한 가장 큰 컨텍스트 윈도우 함정은 무엇인가요? 댓글로 이야기 나눠요 👇

참고 자료:

Anthropic 공식 모범 사례 문서: https://code.claude.com/docs/en/best-practices
Boris Cherny (Claude Code 창시자) 공유: https://x.com/bcherny
@Meer_AIIT의 Claude Code 모범 사례 분석