Claude Code 101로 돌아가기Back to Claude Code 101
Module 04 — 효과적인 프롬프팅Module 04 — Effective Prompting

효과적인
프롬프팅
Effective
Prompting

같은 Claude인데 결과가 천지차이,
프롬프트가 답이다
Same Claude, but wildly different results —
the prompt is the answer

핵심 원칙 8가지8 Core Principles 레시피 모음 →Recipe Collection →
스크롤Scroll
01

프롬프트가 결과를 결정한다

Prompts Determine Results

같은 모델, 같은 도구인데 누구는 놀라운 결과를 뽑아내고, 누구는 "AI 별거 아니네"라고 합니다.
차이는 프롬프트에 있습니다.

Same model, same tools — yet some get amazing results while others say "AI is nothing special."
The difference is the prompt.

흔한 프롬프트Common prompt
할 일 앱 만들어줘
Make a todo app
효과적인 프롬프트Effective prompt
React + TypeScript로 할 일 앱을 만들어줘. 요구사항: - 할 일 추가/삭제/완료 토글 - localStorage로 데이터 영속화 - Tailwind CSS로 스타일링 - 모바일 반응형 먼저 컴포넌트 구조를 설계하고, 그 다음 하나씩 구현해줘.
결과: 모호한 프롬프트Result: Vague prompt
→ 어떤 기술 스택? 바닐라 JS? React? → 어떤 기능까지? 최소한만? 풍부하게? → 스타일은? 못생겨도 되나? → Claude가 추측해서 만듦 → 원하는 게 아닐 확률 높음 😥
→ Which stack? Vanilla JS? React? → How many features? Minimal? Rich? → Styling? Is ugly okay? → Claude guesses and builds → High chance it's not what you wanted 😥
결과: 구체적인 프롬프트Result: Specific prompt
→ 기술 스택 확정 (React + TS) → 기능 범위 명확 → 디자인 방향 제시 (Tailwind) → 작업 순서까지 지정 → 원하는 결과 한 번에! 🎉
→ Tech stack confirmed (React + TS) → Feature scope clear → Design direction given (Tailwind) → Work order specified → Desired result in one shot! 🎉

요리 주문에 비유하면

식당에서 "맛있는 거 주세요"라고 하면 셰프가 알아서 줍니다. 운이 좋으면 맛있고, 아니면 안 맞죠.

하지만 "매운맛 레벨 2의 토마토 파스타, 면은 알덴테로, 마늘은 많이, 치즈 토핑 추가요"라고 하면?
거의 100% 원하는 음식이 나옵니다.

Claude도 마찬가지입니다. 구체적으로 주문할수록, 원하는 결과가 나옵니다.

Like ordering food at a restaurant

If you say "something delicious please" at a restaurant, the chef decides. If you're lucky it's good, otherwise it might not suit you.

But if you say "tomato pasta, spice level 2, al dente noodles, lots of garlic, add cheese topping"?
You'll get exactly what you want nearly 100% of the time.

Claude is the same. The more specifically you order, the more you get what you want.

02

8가지 핵심 원칙

8 Core Principles

Anthropic 공식 모범 사례에서 정리한 8가지 원칙입니다. 이것만 지켜도 결과가 극적으로 달라집니다.

8 principles distilled from Anthropic's official best practices. Following just these will dramatically change your results.

1

처음부터 구체적으로 — 파일, 제약, 패턴까지

Be specific from the start — files, constraints, patterns

특정 파일을 참조하고, 제약 조건을 언급하고, 기존 패턴을 가리켜주세요. Claude는 의도를 추론할 수 있지만 마음을 읽을 수는 없습니다.

Reference specific files, mention constraints, point to existing patterns. Claude can infer intent but cannot read minds.

모호한 지시Vague instruction
로그인 버그 수정해줘
Fix the login bug
구체적 지시Specific instruction
체크아웃 흐름에서 만료된 카드를 가진 사용자에게 오류가 발생합니다. src/payments/에서 토큰 갱신 로직을 확인하고, 먼저 실패하는 테스트를 작성한 후 수정해주세요.
Users with expired cards get an error in the checkout flow. Check the token renewal logic in src/payments/, write a failing test first, then fix it.
💡
팁: 모호한 프롬프트가 유용할 때도 있습니다. "이 파일에서 무엇을 개선하시겠습니까?"처럼 열린 질문은 당신이 미처 생각하지 못한 것을 발견하게 해줍니다. 탐색 중이고 방향을 수정할 여유가 있을 때 효과적입니다.
Tip: Vague prompts can be useful too. Open questions like "What would you improve in this file?" can reveal things you hadn't thought of. Effective when you're exploring and have room to adjust direction.
2

검증할 수 있는 것을 제공하라 — 테스트, 예상 출력

Provide verifiable criteria — tests, expected output

Claude가 자신의 작업을 확인할 수 있도록 테스트, 스크린샷 또는 예상 출력을 포함하세요. 이것이 할 수 있는 가장 영향력 높은 단일 행동입니다.

Include tests, screenshots, or expected output so Claude can verify its own work. This is the single highest-impact thing you can do.

검증 기준 없음No verification criteria
이메일 주소를 검증하는 함수를 구현해주세요
Implement a function to validate email addresses
검증 기준 포함With verification criteria
validateEmail을 구현해주세요. 테스트 케이스: - 'user@example.com' → true - 'invalid' → false - 'user@.com' → false 구현 후 테스트를 실행해주세요.
🧪

테스트 케이스

Test Cases

구체적인 입력/출력 쌍을 제공해서 Claude가 결과를 스스로 검증하게 하세요.

Provide specific input/output pairs so Claude can verify results on its own.

📸

스크린샷 비교

Screenshot Comparison

UI 변경 시 목표 디자인 스크린샷을 붙여넣고, Claude가 결과와 비교하게 하세요.

For UI changes, paste the target design screenshot and have Claude compare its result to it.

🔧

빌드/린트 검증

Build/Lint Verification

"수정하고 빌드가 성공하는지 확인해주세요. 근본 원인을 해결하고 오류를 억제하지 마세요."

"After fixing, verify the build succeeds. Resolve the root cause and don't suppress errors."

3

구현 전에 먼저 탐색하라 — Plan Mode 활용

Explore before implementing — Use Plan Mode

Claude가 바로 코딩으로 뛰어들도록 하면 잘못된 문제를 해결하는 코드가 생성될 수 있습니다. 탐색과 실행을 분리하세요.

Letting Claude jump straight into coding can produce code that solves the wrong problem. Separate exploration from execution.

탐색 먼저 패턴
# 1단계: 탐색 (Plan Mode에서) src/auth/를 읽고 세션 처리 방식을 이해하세요. 코드는 수정하지 마세요. # 2단계: 계획 OAuth 지원을 추가하는 계획을 만들어주세요. 어떤 파일을 변경해야 하는지, 세션 흐름은 무엇인지 포함해서. # 3단계: 구현 (계획 확인 후) 계획대로 OAuth 흐름을 구현해주세요. 콜백 핸들러에 대한 테스트를 작성하고 실패를 수정해주세요.
4

위임하되 마이크로 관리하지 말라 — 방향만 제시

Delegate without micromanaging — just give direction

컨텍스트와 방향을 제공하고 세부 사항은 Claude가 파악하도록 믿으세요. 세세하게 지시하면 오히려 Claude의 능력을 제한합니다.

Provide context and direction, then trust Claude to figure out the details. Over-specifying actually limits Claude's capabilities.

마이크로 관리Micromanaging
payments.js 32번째 줄을 읽고, validateCard 함수를 찾고, 그 함수에서 만료일 체크 로직을 찾아서, 그 부분만 수정해줘...
Read line 32 of payments.js, find the validateCard function, find the expiry date check logic inside that function, and fix only that part...
방향만 제시Just direction
체크아웃 흐름에 버그가 있습니다. 관련 코드는 src/payments/에 있습니다. 조사하고 수정해주세요.
There's a bug in the checkout flow. Relevant code is in src/payments/. Investigate and fix it.
5

대화로 반복 개선하라 — 언제든 방향 수정

Iterate through conversation — redirect anytime

Claude Code는 챗봇이 아니라 에이전트입니다. 처음부터 완벽한 프롬프트를 짜려 하지 말고, 시작한 후 피드백으로 개선하세요.

Claude Code is an agent, not a chatbot. Don't try to craft the perfect prompt from the start — begin and improve through feedback.

Esc로 즉시 중단Instant stop with Esc

Claude가 잘못된 방향으로 가고 있다면 Esc를 눌러 즉시 멈추세요. 컨텍스트는 보존됩니다.

If Claude is heading in the wrong direction, press Esc to stop immediately. The context is preserved.

🔄 방향 수정Course correction

"정확하지 않아요. 문제는 세션 처리에 있습니다."처럼 피드백을 주면 됩니다. 처음부터 다시 시작할 필요 없습니다.

Just give feedback like "That's not right. The issue is in session handling." No need to start over from scratch.

🎯
경험 법칙: 같은 문제에 Claude를 두 번 이상 수정했다면 컨텍스트가 실패한 접근 방식으로 오염된 것입니다. /clear를 실행하고 배운 내용을 통합한 더 구체적인 프롬프트로 새로 시작하세요.
Rule of thumb: If you've corrected Claude twice on the same problem, the context is polluted with the failed approach. Run /clear and start fresh with a more specific prompt that incorporates what you've learned.
6

복잡한 문제엔 ultrathink — 확장 사고 모드

For complex problems, use ultrathink — extended thinking mode

아키텍처 설계, 복잡한 버그, 트레이드오프 분석처럼 깊은 사고가 필요한 문제에는 프롬프트에 ultrathink를 포함하세요.

For problems requiring deep thinking like architecture design, complex bugs, or trade-off analysis, include ultrathink in your prompt.

ultrathink 사용 예시
# 아키텍처 설계 시 ultrathink: 마이크로서비스로 전환하는 최적의 전략을 설계해주세요. 현재 모놀리식 구조는 @src/에 있습니다. # 복잡한 버그 분석 시 ultrathink: 이 경쟁 조건(race condition)이 왜 발생하는지 깊이 분석해주세요. @src/queue/processor.ts를 참조하세요.
🧠
언제 사용하나: ultrathink는 Claude의 확장 사고(extended thinking)를 활성화합니다. 단순한 작업에는 불필요하지만, 여러 트레이드오프를 고려해야 하거나 깊은 추론이 필요한 문제에서 결과 품질이 크게 향상됩니다.
When to use it: ultrathink activates Claude's extended thinking. Unnecessary for simple tasks, but significantly improves quality when multiple trade-offs need consideration or deep reasoning is required.
7

격리된 작업엔 Subagent — 컨텍스트 오염 방지

Use Subagent for isolated tasks — prevent context pollution

컨텍스트가 기본 제약입니다. Subagent는 별도의 컨텍스트 창에서 실행되고 요약만 보고하므로, 주요 대화를 깨끗하게 유지합니다.

Context is the fundamental constraint. Subagents run in a separate context window and report only a summary, keeping the main conversation clean.

Subagent 활용 패턴
# 조사 위임 subagent를 사용하여 인증 시스템이 토큰 갱신을 어떻게 처리하는지, 그리고 재사용해야 할 기존 OAuth 유틸리티가 있는지 조사해주세요. # 테스트 실행 위임 subagent를 사용하여 테스트를 실행하고 실패한 것만 보고해주세요. # 코드 리뷰 위임 subagent를 사용하여 이 코드를 보안 문제와 엣지 케이스에 대해 검토해주세요.
8

반복 컨텍스트는 CLAUDE.md로 — 한 번 쓰고 계속 활용

Repetitive context goes in CLAUDE.md — write once, reuse forever

매번 같은 규칙을 프롬프트에 넣고 있다면 CLAUDE.md에 옮기세요. Claude가 모든 대화 시작 시 자동으로 읽습니다.

If you're putting the same rules in every prompt, move them to CLAUDE.md. Claude reads it automatically at the start of every conversation.

매번 반복Repeated every time
TypeScript any 타입 금지, ESLint 규칙 따르기, 테스트는 Vitest 사용, 함수마다 JSDoc 주석 필수... [매 대화마다 반복]
No TypeScript any type, Follow ESLint rules, Use Vitest for tests, JSDoc comments for every function... [repeated every conversation]
CLAUDE.md에 한 번Once in CLAUDE.md
# CLAUDE.md - TypeScript any 타입 금지 - ESLint 규칙 항상 따를 것 - 테스트: Vitest 사용 - 함수마다 JSDoc 주석 필수 [자동으로 모든 세션에 적용]- No TypeScript any type - Always follow ESLint rules - Tests: use Vitest - JSDoc comments required for every function [Auto-applied to all sessions]
03

Plan Mode 4단계 워크플로우

Plan Mode 4-Step Workflow

Anthropic 공식 권장 워크플로우입니다. 탐색 → 계획 → 구현 → 커밋 4단계로 복잡한 작업을 안전하게 처리합니다.

Anthropic's officially recommended workflow. Safely handle complex tasks in 4 steps: Explore → Plan → Implement → Commit.

⌨️
Plan Mode 진입: Shift + Tab을 두 번 눌러 Plan Mode로 전환합니다. Plan Mode에서 Claude는 파일을 읽고 질문에 답하지만 변경을 수행하지 않습니다.
Enter Plan Mode: Press Shift + Tab twice to switch to Plan Mode. In Plan Mode, Claude reads files and answers questions but does not make changes.
1

탐색 (Plan Mode에서)

Explore (in Plan Mode)

Claude가 파일을 읽고 코드베이스를 이해합니다. 이 단계에서는 어떤 변경도 하지 않습니다.

Claude reads files and understands the codebase. No changes are made at this stage.

탐색 프롬프트 예시 (Plan Mode)Explore prompt example (Plan Mode)
src/auth/를 읽고 세션 및 로그인을 어떻게 처리하는지 이해하세요. 또한 비밀에 대한 환경 변수를 어떻게 관리하는지 살펴보세요.
2

계획 (Plan Mode에서)

Plan (in Plan Mode)

탐색을 바탕으로 상세한 구현 계획을 작성합니다. Ctrl+G를 눌러 계획을 텍스트 편집기에서 직접 편집할 수도 있습니다.

Write a detailed implementation plan based on exploration. You can also press Ctrl+G to edit the plan directly in a text editor.

계획 요청 예시 (Plan Mode)Plan request example (Plan Mode)
Google OAuth를 추가하고 싶습니다. 어떤 파일을 변경해야 합니까? 세션 흐름은 무엇입니까? 계획을 작성해주세요.
3

구현 (Normal Mode로 전환)

Implement (switch to Normal Mode)

계획을 검토하고 승인한 후 Normal Mode로 다시 전환합니다. Claude가 계획에 따라 코드를 작성하고 테스트를 실행합니다.

Review and approve the plan, then switch back to Normal Mode. Claude writes code and runs tests according to the plan.

구현 요청 예시 (Normal Mode)Implementation request example (Normal Mode)
계획에서 OAuth 흐름을 구현해주세요. 콜백 핸들러에 대한 테스트를 작성하고, 테스트 스위트를 실행하고 실패를 수정해주세요.
4

커밋

Commit

구현이 완료되면 Claude에게 설명적인 메시지로 커밋하고 PR을 생성하도록 요청합니다.

Once implementation is complete, ask Claude to commit with a descriptive message and create a PR.

커밋 요청Commit request
설명적인 메시지로 커밋하고 PR을 열어주세요.
바로 실행Execute immediately
"결제 로직 리팩토링해줘" → Claude가 바로 코드 수정 시작 → 의도와 다른 방향으로 갈 수 있음 → 되돌리기 어려움 → 큰 변경에서 실수 확률 높음
"Refactor the payment logic" → Claude starts modifying code immediately → May go in unintended direction → Hard to undo → High chance of mistakes in large changes
Plan Mode 활용Using Plan Mode
"결제 로직 리팩토링 계획 세워줘" → 변경 계획을 먼저 확인 → 방향 수정 가능 → 확인 후 실행 → 안전 → 복잡한 작업도 체계적으로
"Make a plan to refactor the payment logic" → Review the change plan first → Can adjust direction → Execute after review → safe → Even complex work handled systematically
🎯
언제 Plan Mode를 쓰나: 접근 방식이 불확실할 때, 변경이 여러 파일을 수정할 때, 또는 수정 중인 코드에 익숙하지 않을 때 가장 유용합니다. diff를 한 문장으로 설명할 수 있다면 계획을 건너뛰어도 됩니다.
When to use Plan Mode: Most useful when the approach is uncertain, when changes affect multiple files, or when you're unfamiliar with the code being modified. If you can describe the diff in one sentence, you can skip planning.
04

@ 멘션과 파일 참조

@ Mentions and File References

Claude에게 정확한 파일을 가리켜주면, 컨텍스트 정확도가 극적으로 올라갑니다.

Pointing Claude to the exact files dramatically increases context accuracy.

@ 멘션 기본 사용법@ mention basic usage
# 특정 파일 참조 @src/components/Button.tsx 이 컴포넌트에 loading 상태를 추가해줘 # 여러 파일 동시 참조 @src/api/auth.ts @src/middleware/auth.ts 를 비교해서 인증 로직이 중복되는 부분을 찾아줘 # 폴더 전체 참조 @src/utils/ 이 폴더의 유틸 함수들을 분석해서 사용되지 않는 함수를 찾아줘
📄

파일 참조 @파일경로

File reference @filepath

특정 파일을 Claude의 컨텍스트에 직접 로드합니다. Claude가 해당 파일의 전체 내용을 읽고 이해한 상태에서 작업합니다. 정확한 수정이 필요할 때 필수입니다.

Directly loads a specific file into Claude's context. Claude works with a full understanding of that file's content. Essential when precise modifications are needed.

📂

폴더 참조 @폴더/

Folder reference @folder/

폴더 내의 파일 구조를 Claude에게 보여줍니다. 전체적인 구조를 파악하거나, 여러 파일에 걸친 패턴을 찾을 때 유용합니다.

Shows Claude the file structure inside a folder. Useful for understanding the overall structure or finding patterns across multiple files.

실전 활용 패턴Real-world patterns
# 패턴 1: 기존 파일 스타일에 맞추기 @src/api/users.ts 이 파일의 패턴을 따라서 새로운 /api/products.ts를 만들어줘 # 패턴 2: 버그 위치 지정 @src/hooks/useAuth.ts 의 42번째 줄 근처에서 토큰 만료 시 무한 루프가 발생해. 고쳐줘 # 패턴 3: 설정 파일 참조 @tsconfig.json @package.json 을 확인하고 현재 프로젝트 설정에 맞는 테스트 환경을 구성해줘 # 패턴 4: 테스트와 소스 함께 참조 @src/utils/format.ts @tests/format.test.ts 를 보고 테스트가 커버하지 못하는 엣지 케이스를 찾아줘
🎯
핵심 원칙: Claude가 "알아서 찾겠지"라고 기대하지 마세요. 관련 파일을 @ 멘션으로 직접 지정해주면 정확도가 크게 올라갑니다. 특히 프로젝트가 클수록 @ 멘션의 효과가 큽니다.
Key principle: Don't expect Claude to "figure it out." Specifying relevant files directly with @ mention dramatically improves accuracy. Especially in large projects, the effect of @ mentions is significant.
05

컨텍스트 윈도우 관리

Context Window Management

Claude의 기억력에는 한계가 있습니다. /compact/clear로 효율적으로 관리하세요.

Claude's memory has limits. Manage it efficiently with /compact and /clear.

책상 위 공간에 비유하면

Claude의 컨텍스트 윈도우는 책상 위 공간과 같습니다.

대화가 길어질수록 책상 위에 서류가 쌓입니다. 처음에는 넓었던 공간이 점점 좁아지고, 새 서류를 놓으려면 오래된 서류가 밀려납니다.

/compact = 서류를 정리해서 핵심 내용만 요약 메모로 바꾸기. 공간은 확보되고, 중요한 맥락은 유지됩니다.
/clear = 책상을 완전히 치우기. 깨끗한 상태에서 새 작업을 시작합니다.

Like desk space

Claude's context window is like desk space.

As the conversation grows, papers pile up on the desk. The space that was once wide gets narrower, and old papers get pushed aside when new ones arrive.

/compact = Organize the papers into a summary note with just the key points. Space is freed, important context is preserved.
/clear = Clear the desk completely. Start fresh for a new task.

🤔 대화가 느려졌다면?🤔 If the conversation is slowing down?
✅ /compact 사용use

같은 주제를 계속 작업 중이라면 /compact를 사용하세요.
대화 내용을 요약하여 컨텍스트를 압축합니다. 이전 맥락을 유지하면서 공간을 확보합니다.

If you're still working on the same topic, use /compact.
Summarizes the conversation to compress context. Frees space while preserving previous context.

🔄 /clear 사용use

완전히 다른 주제로 전환한다면 /clear를 사용하세요.
이전 대화를 모두 지우고 깨끗한 상태에서 시작합니다. 이전 맥락이 오히려 방해가 될 때 유용합니다.

If switching to a completely different topic, use /clear.
Clears all previous conversation and starts fresh. Useful when previous context is actually a hindrance.

상황별 추천 커맨드

Recommended Commands by Situation

상황Situation 커맨드Command 설명Description
대화가 길어져서 느려짐Conversation is long and slow /compact 대화를 요약하여 컨텍스트 공간 확보Summarize conversation to free context space
완전히 다른 작업 시작Starting a completely different task /clear 이전 맥락을 지우고 깨끗하게 시작Clear previous context and start fresh
Claude가 이상한 답을 함Claude is giving strange answers /clear 오염된 컨텍스트를 리셋Reset polluted context
대규모 코드 리뷰 중During a large code review /compact 리뷰 진행 상황을 유지하면서 공간 확보Free space while preserving review progress
토큰 한도에 도달Reached token limit /compact 자동으로 요약이 실행되지만, 수동으로 하면 더 정확Summary runs automatically, but manually is more accurate
민감한 정보를 입력함Sensitive information was entered /clear 컨텍스트에서 완전히 제거Remove completely from context
💡
프로 팁: /compact에 커스텀 지시를 추가할 수 있습니다. /compact 현재 작업 중인 결제 모듈 관련 맥락은 반드시 유지해줘처럼 쓰면, 중요한 맥락을 더 잘 보존합니다.
Pro tip: You can add custom instructions to /compact. Writing something like /compact make sure to keep context related to the payment module I'm working on better preserves important context.

3계층 컨텍스트 관리 전략

3-Tier Context Management Strategy

긴 세션이 필요할 때 단순히 /compact만 쓰지 말고, 3계층 전략으로 체계적으로 관리하세요.

When long sessions are needed, don't just use /compact. Manage systematically with a 3-tier strategy.

📋

1계층: 선제적 분리Tier 1: Proactive Split

큰 작업을 시작하기 전에 세션 자체를 나누세요. "인증 모듈 분석" → /clear → "인증 모듈 구현". 하나의 세션 = 하나의 작업이 원칙입니다.

Split the session itself before starting big tasks. "Analyze auth module" → /clear → "Implement auth module." One session = one task is the principle.

🗜

2계층: 선택적 압축Tier 2: Selective Compact

세션 중간에 /compact "결제 API 관련만 유지"처럼 키워드를 지정하여 중요한 맥락만 보존합니다. 무지정 /compact보다 훨씬 정확합니다.

Mid-session, use /compact "keep only payment API context" to specify keywords and preserve only important context. Far more accurate than bare /compact.

🔄

3계층: 자동 압축 대비Tier 3: Auto-compact Prep

한계에 도달하면 하네스가 자동 압축합니다. 이때를 대비해 CLAUDE.md에 핵심 규칙을 적어두세요 — CLAUDE.md는 압축되지 않으므로 항상 살아남습니다.

When limits are reached, the harness auto-compresses. Prepare for this by writing key rules in CLAUDE.md — CLAUDE.md is never compressed, so it always survives.

작업 분해 유도 — 복잡한 작업의 완료율을 높이는 법

Task Decomposition — How to Boost Completion Rate for Complex Tasks

복잡한 작업을 줄 때, Claude에게 먼저 계획을 세우게 하면 완료율이 크게 올라갑니다. 계획 없는 에이전트는 방향을 잃습니다.

When giving complex tasks, having Claude plan first dramatically increases the completion rate. An agent without a plan drifts.

작업 분해 프롬프트 패턴Task Decomposition Prompt Pattern
나쁜 예: 한 번에 전부 요청Bad: requesting everything at once "이 프로젝트에 인증 시스템, 결제 모듈, 알림 기능을 추가해줘" 좋은 예: 계획 수립 → 단계별 실행Good: plan first → execute step by step "이 프로젝트에 인증 시스템을 추가하려고 해. 먼저 현재 코드를 분석하고 구현 계획을 세워줘. 계획이 확정되면 단계별로 하나씩 실행하고, 각 단계마다 테스트를 돌려서 검증해줘." 🎯 최고의 예: Plan Mode → 확인 → 실행Best: Plan Mode → confirm → execute 1. Shift+Tab → Plan Mode "인증 시스템 추가 계획을 세워줘" 2. 계획 확인 후After confirming plan → Shift+Tab → Normal Mode "위 계획대로 실행해줘. 각 단계 완료 시 진행 상황을 알려줘"
💡
왜 작업 분해가 중요한가: Claude는 내부적으로 TodoWrite라는 도구를 사용해 태스크 리스트를 관리합니다. "먼저 계획을 세워줘"라고 하면 Claude가 자체적으로 체크리스트를 만들고, 하나씩 완료하며 진행합니다. 연구에 따르면 계획을 세운 에이전트의 작업 완료율이 2배 이상 높습니다.
Why task decomposition matters: Claude internally uses a tool called TodoWrite to manage task lists. When you say "plan first," Claude creates its own checklist and completes tasks one by one. Research shows that agents with plans have 2x+ higher task completion rates.
06

프롬프트 레시피 모음

Prompt Recipe Collection

바로 복사해서 쓸 수 있는 실전 프롬프트 템플릿입니다. 상황에 맞게 수정해서 사용하세요.

Ready-to-use prompt templates you can copy immediately. Modify them to fit your situation.

#1

코드 리뷰 요청

Code Review Request

상황: 작성한 코드의 품질을 점검받고 싶을 때Situation: When you want to get quality feedback on code you wrote
프롬프트
@src/services/payment.ts 이 파일을 리뷰해줘. 다음 관점에서 검토해줘: 1. 에러 핸들링이 충분한가 2. 엣지 케이스를 놓친 게 있는가 3. 성능 개선 포인트가 있는가 4. 네이밍과 가독성은 괜찮은가 각 항목별로 구체적인 라인 번호와 개선 코드를 포함해줘.
왜 효과적인가: 리뷰 관점을 명시해서 Claude가 체계적으로 검토합니다. "코드 리뷰해줘"만 하면 피상적인 피드백만 나옵니다.Why it works: Specifying review perspectives makes Claude review systematically. Just saying "review my code" only produces superficial feedback.
#2

버그 수정

Bug Fix

상황: 특정 조건에서 발생하는 버그를 고쳐야 할 때Situation: When you need to fix a bug that occurs under specific conditions
프롬프트
버그 설명: 장바구니에서 수량을 0으로 바꾸면 음수가 되면서 결제 금액이 마이너스가 됨. 재현 경로: 1. 상품 추가 → 2. 수량 감소 버튼 연타 → 3. 수량이 -1이 됨 예상 동작: 수량은 최소 1이어야 하고, 0이 되면 항목을 삭제해야 함. 관련 파일: @src/hooks/useCart.ts @src/components/CartItem.tsx 수정하되, 기존 테스트가 깨지지 않게 해줘.
왜 효과적인가: 버그 설명, 재현 경로, 예상 동작, 관련 파일을 모두 제공해서 Claude가 정확한 위치에서 정확한 수정을 할 수 있습니다.Why it works: Providing bug description, reproduction path, expected behavior, and related files allows Claude to make precise fixes at the exact location.
#3

리팩토링

Refactoring

상황: 복잡해진 코드를 깔끔하게 정리하고 싶을 때Situation: When you want to clean up code that has become complex
프롬프트
@src/controllers/orderController.ts 이 파일을 리팩토링해줘. 문제: 하나의 함수가 200줄이 넘고, 주문 생성/검증/결제/알림을 전부 처리하고 있어. 목표: - 단일 책임 원칙에 따라 함수를 분리 - OrderService, PaymentService, NotificationService로 분리 - 각 서비스는 별도 파일로 제약 조건: - 외부 API 인터페이스는 변경하지 마 (컨트롤러의 라우트 시그니처 유지) - 먼저 계획을 보여주고, 승인 후 진행해줘
왜 효과적인가: 현재 문제, 리팩토링 목표, 제약 조건을 명확히 제시합니다. 특히 "외부 인터페이스 유지"와 "계획 먼저" 조건이 안전한 리팩토링을 보장합니다.Why it works: Clearly presents current problem, refactoring goals, and constraints. Especially the "keep external interface" and "plan first" conditions ensure safe refactoring.
#4

테스트 작성

Writing Tests

상황: 기존 코드에 대한 테스트를 추가하고 싶을 때Situation: When you want to add tests for existing code
프롬프트
@src/utils/validator.ts 에 대한 단위 테스트를 작성해줘. 테스트 프레임워크: Vitest 위치: src/utils/__tests__/validator.test.ts 포함할 케이스: - 정상 입력 (happy path) - 빈 값, null, undefined - 경계값 (최소/최대) - 잘못된 타입 입력 - 특수문자, 한글 입력 스타일: - describe/it 패턴 사용 - 테스트 이름은 한국어로 - AAA 패턴 (Arrange-Act-Assert)
왜 효과적인가: 테스트 프레임워크, 파일 위치, 케이스 목록, 코딩 스타일까지 지정해서 바로 실행 가능한 테스트가 나옵니다.Why it works: Specifying the test framework, file location, case list, and coding style produces immediately runnable tests.
#5

문서화

Documentation

상황: 코드에 대한 문서를 작성하거나, 주석을 추가하고 싶을 때Situation: When you want to write documentation for code or add comments
프롬프트
@src/api/ 폴더의 모든 API 엔드포인트를 분석해서 API 문서를 작성해줘. 포맷: - 각 엔드포인트별로: 메서드, 경로, 설명, 파라미터, 응답 예시 - 마크다운 테이블 형식 - 인증이 필요한 엔드포인트는 별도 표시 추가 작업: - 각 라우트 핸들러에 JSDoc 주석도 추가해줘 - 파라미터 타입과 반환 타입을 명시
왜 효과적인가: 문서화의 범위, 포맷, 추가 작업을 구체적으로 지정해서 일관된 품질의 문서가 생성됩니다.Why it works: Specifying the scope, format, and additional tasks for documentation produces consistently high-quality docs.
#6

API 엔드포인트 추가

Adding API Endpoints

상황: 기존 API에 새로운 엔드포인트를 추가하고 싶을 때Situation: When you want to add new endpoints to an existing API
프롬프트
@src/api/users.ts 의 패턴을 따라서 새로운 상품(Product) API를 만들어줘. 엔드포인트 목록: GET /api/products - 상품 목록 (페이지네이션) GET /api/products/:id - 상품 상세 POST /api/products - 상품 등록 (관리자만) PUT /api/products/:id - 상품 수정 (관리자만) DELETE /api/products/:id - 상품 삭제 (관리자만) 포함할 것: - Zod 스키마로 입력 검증 - 적절한 에러 코드 (400, 401, 404, 500) - 관리자 권한 미들웨어 적용 - 각 엔드포인트 테스트 코드
왜 효과적인가: 기존 패턴 참조(@), 엔드포인트 명세, 포함 사항을 명시해서 일관된 코드가 생성됩니다.Why it works: Referencing existing patterns (@), specifying endpoint specs and requirements produces consistent code.
#7

성능 최적화

Performance Optimization

상황: 앱이 느려져서 성능을 개선하고 싶을 때Situation: When the app is slow and you want to improve performance
프롬프트
@src/pages/Dashboard.tsx 이 페이지가 렌더링이 느려. 증상: 대시보드 진입 시 3초 이상 걸리고, 스크롤이 끊김. 데이터는 약 500개 항목. 분석해줘: 1. 불필요한 리렌더링이 있는지 2. 무거운 연산이 메인 스레드에서 돌고 있는지 3. 리스트 가상화가 필요한지 4. API 호출을 최적화할 수 있는지 개선 후 기대: - 초기 로딩 1초 이내 - 60fps 스크롤 - React.memo, useMemo, useCallback 적절히 활용
왜 효과적인가: 증상, 데이터 규모, 분석 관점, 개선 목표를 구체적으로 제시해서 실질적인 최적화를 받을 수 있습니다.Why it works: Presenting specific symptoms, data scale, analysis angles, and improvement goals gets you practical optimization.
#8

마이그레이션

Migration

상황: 기존 코드를 새로운 버전/프레임워크로 전환해야 할 때Situation: When you need to migrate existing code to a new version/framework
프롬프트
마이그레이션 대상: React Router v5 → v6으로 업그레이드 현재 상태: @src/App.tsx 에서 Switch, Route, useHistory 사용 중 @src/routes/ 폴더에 라우트 설정 파일들 작업 요청: 1. 먼저 변경 범위를 분석해줘 (영향받는 파일 목록) 2. v5 → v6 변경 사항 매핑표 만들어줘 3. 승인 후 파일별로 하나씩 수정 4. 각 수정 후 라우팅이 정상 동작하는지 확인 제약: - 한 번에 전체를 바꾸지 말고 점진적으로 - 각 단계에서 앱이 동작 가능한 상태를 유지
왜 효과적인가: 마이그레이션 대상, 현재 상태, 작업 순서, 점진적 접근 제약을 명시해서 안전한 마이그레이션이 가능합니다.Why it works: Specifying migration target, current state, task order, and incremental approach constraints enables safe migration.
#9

새 프로젝트 초기 설정

New Project Initial Setup

상황: 새 프로젝트를 처음부터 세팅하고 싶을 때Situation: When you want to set up a new project from scratch
프롬프트
새 프로젝트를 세팅해줘: 기술 스택: - Next.js 14 (App Router) - TypeScript (strict mode) - Tailwind CSS - Prisma + PostgreSQL - Vitest + Testing Library 프로젝트 구조: Feature 기반 폴더 구조 (src/features/) 포함할 설정: - ESLint + Prettier 설정 - husky + lint-staged (pre-commit) - 환경 변수 템플릿 (.env.example) - GitHub Actions CI 파이프라인 - Docker Compose (개발용 DB) 먼저 폴더 구조와 설정 파일만 만들어줘. 실제 기능 코드는 아직 작성하지 마.
왜 효과적인가: 기술 스택, 프로젝트 구조, 개발 환경 설정까지 한 번에 명시하고, "설정만 먼저"라는 제약으로 단계적 진행을 유도합니다.Why it works: Specifying tech stack, project structure, and dev environment setup all at once, with "setup only first" constraint guiding stepwise progress.
#10

디버깅 도움 요청

Debugging Help Request

상황: 에러의 원인을 모르겠고, 도움이 필요할 때Situation: When you don't know the cause of an error and need help
프롬프트
에러 메시지: TypeError: Cannot read properties of undefined (reading 'map') at UserList (UserList.tsx:23) 발생 상황: 페이지 첫 로딩 시 발생. 새로고침하면 정상 작동. 로컬에서만 재현, 프로덕션은 괜찮음. 시도한 것: - users?.map으로 옵셔널 체이닝 추가 → 에러는 사라지지만 빈 목록 - console.log로 확인 → 첫 렌더에서 users가 undefined 관련 파일: @src/components/UserList.tsx @src/hooks/useUsers.ts 근본 원인을 찾아서 올바른 방법으로 수정해줘. 옵셔널 체이닝으로 에러만 숨기는 건 원하지 않아.
왜 효과적인가: 에러 메시지, 발생 조건, 이미 시도한 것, 원하는 수정 방향까지 제공해서 Claude가 근본 원인을 파악하고 올바르게 수정합니다.Why it works: Providing error message, reproduction conditions, what you've already tried, and desired fix direction helps Claude identify the root cause and fix it correctly.
07

자주 묻는 질문

FAQ

프롬프팅에 대해 가장 많이 궁금해하는 것들

The most common questions about prompting

Claude는 한국어를 매우 잘 이해합니다. 일반적인 코딩 작업에서는 한국어와 영어의 결과 차이가 거의 없습니다. 다만 매우 전문적인 기술 용어나 특정 라이브러리의 API를 다룰 때는 영어 키워드를 섞어 쓰면 정확도가 약간 올라갈 수 있습니다. 예를 들어 "React의 useEffect에서 cleanup function을 구현해줘"처럼 기술 용어만 영어로 쓰는 하이브리드 방식이 실용적입니다. 중요한 것은 언어가 아니라 프롬프트의 구체성입니다.
Claude understands Korean very well. For general coding tasks, there is almost no difference in results between Korean and English. However, when dealing with very specialized technical terms or specific library APIs, mixing in English keywords can slightly improve accuracy. For example, a hybrid approach like "React의 useEffect에서 cleanup function을 구현해줘" (using English for technical terms only) is practical. What matters is not the language but the specificity of the prompt.
프롬프트가 길다고 나쁜 것은 아닙니다. 오히려 구체적인 긴 프롬프트가 모호한 짧은 프롬프트보다 훨씬 좋은 결과를 냅니다. 다만 "장황한" 프롬프트와 "구체적인" 프롬프트는 다릅니다. 불필요한 배경 설명이나 반복은 오히려 핵심을 흐릴 수 있습니다. 핵심은 필요한 정보를 빠짐없이, 구조적으로 전달하는 것입니다. 목적, 컨텍스트, 요구사항, 제약조건을 명확한 섹션으로 나눠서 쓰면 길어도 효과적입니다.
Long prompts are not bad. In fact, a specific long prompt produces much better results than a vague short one. However, "verbose" and "specific" prompts are different. Unnecessary background explanation or repetition can actually blur the key points. The key is to convey all necessary information, structured clearly. Writing purpose, context, requirements, and constraints as clear sections is effective even if it gets long.
네, 그게 Plan Mode의 핵심 장점입니다. Claude가 계획을 제시하면 실행 전에 자유롭게 수정할 수 있습니다. "2번 단계를 이렇게 바꿔줘", "3번 단계를 빼고 대신 이걸 추가해줘", "순서를 바꿔서 테스트부터 해줘" 등 원하는 만큼 조정할 수 있습니다. 계획이 만족스러울 때 "이대로 진행해줘"라고 하면 됩니다. 실행 중간에도 "잠깐, 여기서 멈춰"라고 하면 중단할 수 있습니다.
Yes, that's the core advantage of Plan Mode. When Claude presents a plan, you can freely modify it before execution. You can adjust as much as you want: "change step 2 like this", "remove step 3 and add this instead", "reorder to test first". When satisfied with the plan, just say "proceed as is." You can also stop mid-execution by saying "wait, stop here."
Claude Code는 같은 세션 내에서는 이전 대화를 기억합니다. 하지만 세션이 끝나면 (터미널을 닫거나 /clear를 하면) 대화 기록은 사라집니다. 이전 대화의 맥락을 유지하고 싶다면 두 가지 방법이 있습니다. 첫째, CLAUDE.md에 중요한 규칙을 적어두면 매 세션마다 자동으로 로드됩니다. 둘째, 새 세션에서 이전 작업의 맥락을 간단히 요약해서 알려주면 Claude가 이해합니다. 예: "어제 결제 모듈 리팩토링을 시작했고, PaymentService 분리까지 완료했어. 오늘은 NotificationService를 분리할 거야." 세 번째 방법으로 claude --continue로 가장 최근 대화를 재개하거나, claude --resume으로 최근 세션 목록에서 선택할 수도 있습니다.
Claude Code remembers previous conversation within the same session. But when a session ends (closing terminal or /clear), the conversation history disappears. To preserve context from previous conversations, there are two options: First, write important rules in CLAUDE.md and it loads automatically at the start of every session. Second, briefly summarize the previous work context in the new session and Claude will understand. Example: "Yesterday I started refactoring the payment module and completed separating PaymentService. Today I'll separate NotificationService." Third, you can resume the most recent conversation with claude --continue, or choose from recent sessions with claude --resume.
ultrathink를 프롬프트에 포함하면 Claude의 확장 사고(extended thinking)가 활성화됩니다. 이는 단순한 구현 작업에는 불필요하지만, 다음과 같은 상황에서 결과 품질을 크게 향상시킵니다: 아키텍처 설계, 여러 트레이드오프가 있는 기술 결정, 복잡한 경쟁 조건(race condition) 분석, 보안 취약점 검토 등 깊은 추론이 필요한 문제들입니다. 사용 예시: "ultrathink: 이 마이크로서비스 전환 전략의 트레이드오프를 분석해주세요."
Including ultrathink in your prompt activates Claude's extended thinking. This is unnecessary for simple implementation tasks, but greatly improves quality in: architecture design, technical decisions with multiple trade-offs, complex race condition analysis, security vulnerability review, and other problems requiring deep reasoning. Example: "ultrathink: analyze the trade-offs of this microservices migration strategy."
Subagent는 별도의 컨텍스트 창에서 실행됩니다. 즉, 주요 대화의 컨텍스트를 소비하지 않고 독립적으로 작업합니다. 코드베이스 조사나 탐색처럼 많은 파일을 읽어야 하는 작업에 특히 유용합니다. 예를 들어 Claude가 직접 100개 파일을 읽으면 컨텍스트 창이 빠르게 채워지지만, subagent에게 위임하면 주요 대화는 깨끗하게 유지됩니다. 사용법: "subagent를 사용하여 [작업]을 처리하고 결과를 요약해서 보고해주세요." 컨텍스트가 가득 찰 것 같거나, 조사/검증 작업을 주 대화에서 분리하고 싶을 때 활용하세요.
Subagents run in a separate context window — they work independently without consuming the main conversation's context. Especially useful for tasks that require reading many files, like codebase investigation or exploration. For example, if Claude directly reads 100 files the context window fills up fast, but delegating to a subagent keeps the main conversation clean. Usage: "Use a subagent to handle [task] and report results with a summary." Use it when the context might fill up, or when you want to separate investigation/verification tasks from the main conversation.
같은 문제에 대해 Claude를 두 번 이상 수정했다면, 컨텍스트가 실패한 접근 방식으로 오염된 것입니다. 이 때 계속 수정하는 것은 역효과입니다. 권장하는 접근: (1) /clear로 컨텍스트를 완전히 리셋합니다. (2) 지금까지 배운 내용, 실패한 접근 방식, 제약 조건을 통합한 더 나은 초기 프롬프트를 작성합니다. (3) 새 대화에서 더 구체적인 프롬프트로 시작합니다. 누적된 수정이 있는 긴 세션보다 좋은 프롬프트를 가진 깨끗한 세션이 항상 더 나은 성능을 발휘합니다.
If you've corrected Claude more than twice on the same problem, the context is polluted with the failed approach. Continuing to correct at that point is counterproductive. Recommended approach: (1) Completely reset context with /clear. (2) Write a better initial prompt incorporating what you've learned, the failed approaches, and constraints. (3) Start fresh in a new conversation with a more specific prompt. A clean session with a good prompt always outperforms a long session with accumulated corrections.

요약하면 이겁니다

The Bottom Line

처음부터 구체적으로 — 파일, 제약, 패턴까지
검증 기준 제공 — 테스트, 예상 출력 포함
탐색 → 계획 → 구현 — Plan Mode 4단계
위임하되 마이크로 관리 금지 — 방향만 제시
대화로 반복 개선 — Esc로 중단, 피드백으로 수정
ultrathink — 복잡한 문제에 확장 사고 활성화
Subagent — 격리된 작업에 별도 컨텍스트
CLAUDE.md — 반복 규칙은 한 번만 작성

Be specific from the start — files, constraints, patterns
Provide verification criteria — include tests, expected output
Explore → Plan → Implement — Plan Mode 4 steps
Delegate, don't micromanage — just give direction
Iterate through conversation — stop with Esc, correct with feedback
ultrathink — activate extended thinking for complex problems
Subagent — separate context for isolated tasks
CLAUDE.md — write repetitive rules just once

프롬프트는 연습할수록 좋아집니다.
위의 레시피부터 시작해서, 자신만의 패턴을 만들어보세요.

Prompting gets better with practice.
Start with the recipes above and build your own patterns.

이전: CLAUDE.mdPrev: CLAUDE.md 다음: MCP 서버 연결 →Next: MCP Server Connection →