4. Context Management — Keeping Output Quality High Throughout a Session
이것은 가장 즉각적이고 측정 가능한 효과 중 하나를 가지고 있음에도 불구하고 가장 일반적으로 무시되는 기술입니다.
Claude Code 커뮤니티의 연구에 따르면 "멍청한 영역"은 컨텍스트 창 사용의 약 40 %를 시작합니다. 그 시점에서 출력 품질은 눈에 띄게 저하되기 시작합니다. 숙련 된 사용자는 적극적으로 컨텍스트를 30 % 이하로 유지하고 간단한 저위험 작업에 대해 60 %로 푸시하는 것이 좋습니다. 컨텍스트 썩음 - 실패한 시도의 축적, 관련없는 작업 및 단일 세션에서 오래된 정보 -는 바이브 코딩의 기본 실패 모드입니다.
근육 기억으로 가지고 있어야하는 명령 :
# Full context reset — use this when switching to a different task
/clear
# Compress context while keeping important information
/compact
# Compress with a specific hint - much better than letting auto-compact fire
/compact focus on the auth refactor, drop the test debugging thread
# Rewind to the state before a failed attempt
/rewind
# or press double-Esc
The habit that makes the biggest difference:
❌ BEFORE — The "kitchen sink" session
One long session mixing everything:
- Fix a bug in auth
- Add a new dashboard feature
- Refactor a database query
- Debug an unrelated error
→ Context fills with garbage, output gets progressively worse
✅ AFTER - Focused sessions
Session 1: /clear → fix auth bug → commit → /clear
Session 2: /clear → add dashboard feature → commit → /clear
Session 3: /clear → refactor query → commit
→ 각 세션은 깨끗하게 시작하고 출력은 지속적으로 고품질로 유지됩니다.
내면화 할 가치가있는 커뮤니티의 한 가지 통찰력 : 되감기 비트 보정. 클로드가 실수를 할 때, 실패한 시도 전에 되감고 배운 것을 다시 시작하는 것이 거의 항상 낫습니다. 실패한 시도와 수정을 문맥에서 떠나면서 다음과 같은 모든 것을 오염시키는 것이 좋습니다. 이것은 반 직관적 인 느낌이지만 지속적으로 더 효과적입니다.
5. Planning Mode — Plan First, Code Second
이것은 바이브 코딩으로 지속적으로 훌륭한 결과를 얻는 개발자와 그렇지 않은 개발자 간의 가장 큰 행동 차이입니다.
수십 개의 소스에서 모범 사례를 종합 한 후 한 가지 결론이 계속 나오고 있습니다. 코딩을하기 전에 계획하는 것은 생산 작업에 대해 협상 할 수 없습니다. “바이브 코딩”은 버리는 MVP와 프로토타입에 잘 작동합니다. 프로덕션 코드는 구현 코드의 줄이 작성되기 전에 구조화된 사고, 유효성 검사 및 문서화가 필요합니다.
Claude Code에는 활성화할 수 있는 계획 모드가 있으며 복잡한 기능에는 특히 효과적인 패턴이 있습니다.
# Activate planning mode in Claude Code
Shift+Tab → select "Plan" mode
# Or ask Claude to interview you before writing any code
A prompt that works extremely well for complex features:
I want to build [short description].
어떤 코드를 작성하기 전에, 자세히 나를 인터뷰한다.
Ask about:
- Technical implementation and architecture options
- UI/UX and user flow
- Edge cases that need to be handled
- Tradeoffs between different approaches
- Dependencies and integration with existing code
명백한 질문을하지 마십시오. 단단한 부분에 집중하십시오
그리고 내가 아직 고려하지 않았을 수도 있습니다.
인터뷰가 완료되면 전체 사양을 작성하십시오.
그리고 어떤 구현을 시작하기 전에 SPEC.md에 저장합니다.
사양이 완료되면 공식 Claude Code 문서는 구현을위한 새로운 세션을 시작할 것을 권장합니다. 새 세션은 전적으로 구축에 중점을 둔 컨텍스트를 가지고 있으며, 전체에 참조 할 서면 사양이 있습니다.
The full workflow looks like this:
Session 1 (Planning):
→ Planning prompt + interview
→ Claude writes SPEC.md
→ You review and approve SPEC.md
→ /clear
Session 2 (Implementation):
→ Load SPEC.md at the start of the session
→ Execute section by section
→ Test each section before moving to the next
→ Commit at each milestone
이것은 처음에는 느리게 느껴집니다. 실제로 전반적으로 지속적으로 더 빠릅니다. 계획없이 바이브 코딩에 바로 뛰어들 때 거의 항상 발생하는 대규모 재작업을 피하기 때문입니다.
6. Multi-Claude Pattern — Separate the Writer from the Reviewer
이것은이 목록에서 가장 적게 사용되는 기술이지만 가장 극적인 품질 향상을 생성합니다.
아이디어는 간단합니다. 하나의 Claude 인스턴스를 사용하여 코드를 작성하고 별도의 인스턴스를 사용하여 검토합니다. 글쓰기 과정에서 맥락이없는 신선한 클로드 (Claude)는 방금 코드를 작성한 클로드 (Claude)보다 문제를 찾는 데 훨씬 더 객관적이고 비판적 일 것입니다.
이 패턴은 "글과 검토를위한 별도의 컨텍스트"로 알려져 있습니다. Claude A는 코드를 작성한 다음 새 터미널을 / 클리어하거나 엽니 다. Claude B는 Claude A의 작업을 검토하고 Claude C는 코드와 리뷰 피드백을 읽고 최종 수정을합니다.
How to apply it in practice:
# Terminal 1 — Claude as "developer"
claude
> Implement a rate limiting middleware for this Express API.
Use Redis with a sliding window algorithm.
[code complete]
# Terminal 2 - Fresh Claude as "senior reviewer"
claude
> You are a senior security engineer.
Review this middleware with a focus on:
1. Potential bypass vulnerabilities
2. Edge cases that aren't handled
3. Performance impact under high traffic
4. Whether the Redis implementation is correct
[paste code from Terminal 1]
간단한 작업의 경우 단일 세션 내에서 자기 비평 패턴을 사용할 수 있습니다.
"Generate code for [task].
When done, critique your own output —
identify at least 3 weaknesses or edge cases
you may have missed, then refactor based on
that critique."
또한 더 직접적인 "도전"기술이 있습니다. 클로드에게 코드가 작동하는지 확인하도록 요청하는 대신 "이 작품을 나에게 증명하십시오"라는 것을 증명하고 클로드에게 메인 브랜치와 분기를 오라고 요청합니다. 이것은 즉시 명확하지 않은 회귀를 잡는 데 특히 효과적입니다.
7. Skills System & Slash Commands — Build a Reusable Playbook
이것은 클로드를 개별 생산성 도구에서 팀 전체에 걸쳐 확장하는 것으로 변환하는 기술입니다.
기술은 Claude가 동적으로 발견하고로드 할 수있는 지침, 스크립트 및 리소스의 폴더입니다. 그것들을 "전문 지식 팩"으로 생각하십시오. Claude에게 특정 수준의 작업에 대한 전문 플레이 북을 제공합니다. 모델이 관련 상황을 인식 할 때 자동으로 트리거됩니다.
그러나 전체 기술 시스템을 설정하지 않고도 CLAUDE.md에서 직접 사용자 정의 슬래시 명령을 정의하여 즉시 시작할 수 있습니다.
<!-- Inside CLAUDE.md -->
## Custom Commands
### /plan
Before starting any coding:
1. Ask clarifying questions until you fully understand all requirements
2. List every file that will be changed and why
3. Identify potential side effects on unrelated code
4. Write a step-by-step implementation plan
5. Wait for explicit approval before writing any code
### /review
Run a code review against this checklist:
1. Security: any injection risks, exposed secrets, or missing input validation?
2. Performance: N+1 queries, missing indexes, or unnecessary computation?
3. Edge cases: null handling, empty arrays, concurrent requests
4. Tests: is test coverage adequate for the new code?
5. Consistency: does this follow existing patterns in the codebase?
### /ship
Before pushing to production:
1. Run all tests and confirm everything passes
2. Scan for hardcoded secrets or credentials
3. Check for any console.log statements left behind
4. Review all changes with git diff
5. Write a descriptive commit message: type(scope): description
Using them in a session:
# At the start of any new feature
/plan Add PDF export for monthly reports
# Before merging
/review [paste the code to be merged]
# Before deploying
/ship
By codifying commands like /plan, /build-fix, /code-review, and /docs-sync, nobody on the team has to rewrite the same prompt scaffolding every time. Skills are how you turn "the way we do things here" into reusable assets that trigger on demand — and they're also one of the best onboarding tools you can build. New team members don't need to have the code standards and workflow explained from scratch because it's all already encoded in CLAUDE.md and the custom commands.
Putting It All Together
이 일곱 가지 기술은 별개의 것이 아니라 시스템으로서 가장 잘 작동합니다. 모든 것이 함께 실행될 때 전체 그림이 어떻게 보이는지는 다음과 같습니다.
XML prompting → more precise, consistent output from the very first response
Role assignment → technical depth calibrated to exactly what the task needs
CLAUDE.md → project context always present without manually pasting anything
Context management → output quality maintained from the start to the end of every session
Planning mode → solid architecture before a single line of implementation code is written
Multi-Claude pattern → objective, critical review from a fresh perspective
Skills & slash commands → repeatable workflows that scale to a full team
이 모든 것이 함께 달릴 때, 당신은 더 이상 순진한 의미에서 "바이브 코딩"이 아닙니다. 에이전트 엔지니어링을 실행하고 있습니다. AI는 프로젝트의 컨텍스트를 이해하고, 구축한 표준을 따르고, 모든 세션마다 일관된 코드를 생성하는 진정한 파트너입니다.
클로드 코드 사용의 수백 시간의 합성으로: 좌절과 생산력의 차이는 도구가 아닙니다 — 그것은 당신이 그것을 사용하는 방법입니다. "출력은 일회용입니다. 계획 및 프롬프트 화합물."
클로징 : Claude는 당신이 이야기하는 방법만큼만 좋습니다.
여기에 모든 것을 하나로 묶는 정신 모델이 있습니다. Claude를 코드 검색 엔진이 아니라 프로젝트에 대해 전혀 모르는 훌륭한 새로운 수석 엔지니어로 생각하십시오.
당신이 그들에게 맥락없이 무언가를하도록 요청한다면, 그들은 그들이 가장 좋다고 생각하는 방식으로 그것을 할 것입니다 - 당신이 실제로 필요로하는 것과는 매우 다를 수 있습니다. 그러나 컨텍스트, 표준 및 좋은 모습을 설명하기 위해 미리 시간을 투자하면 기대치를 초과하는 작업을 생성합니다.
위의 7 가지 기술은 체계적으로 그 투자를하는 방법입니다. 그리고 모든 좋은 투자와 마찬가지로, 수익은 시간이 지남에 따라 발생합니다.
행복한 분위기 코딩 - 올바른 기술을 가지고.
