Claude를 잘 사용하는 것은 단순히 질문을 잘하는 것만을 의미하지 않습니다.
좋은 결과를 얻으려면 Claude에게 충분한 Context를 제공하고, 원하는 Task를 명확하게 정의하고, 복잡한 작업은 적절하게 나누고, 결과를 보면서 Prompt를 개선하는 과정이 필요합니다.
이번 글에서는 제가 Claude Foundations를 공부하면서 정리한 Prompting & Task Execution의 핵심 내용을 네 가지 주제로 나누어 설명합니다.
Effective Prompting → Task Decomposition → Iteration → Adapting Strategy by Task Type
단순히 개념만 외우기보다는 실제 업무에서 Claude를 어떻게 사용할 수 있는지 예제와 함께 정리해보겠습니다.
🐱 Vibe Code K-Mom Study Note
이 글은 제가 Claude Foundations를 공부하면서 만든 개인 학습 노트를 바탕으로 정리한 글입니다. 공식 학습 자료가 아닌 개인 Study Guide입니다.
1. 효과적인 프롬프트 작성
Claude에게 좋은 결과를 얻기 위한 첫 번째 단계는 명확하고 직접적인 Prompt를 작성하는 것입니다.
제가 공부하면서 가장 이해하기 쉬웠던 방법은 Prompt를 다음 다섯 가지 요소로 나누어 보는 것이었습니다.
Role → Context → Task → Constraints → Format
각 요소는 Claude에게 “어떤 상황에서, 무엇을, 어떤 기준으로, 어떤 형태로 해야 하는지” 알려주는 역할을 합니다.
Role — Claude는 누구인가?
Role은 Claude가 이번 작업에서 어떤 역할을 수행해야 하는지 정의합니다.
예를 들어:
너는 SaaS 계약 검토 경험이 10년 이상인 법무 담당자다.
Role을 지정하면 Claude가 사용할 어휘 수준, 분석의 깊이, 작업에서 전제로 삼아야 하는 배경지식의 범위를 설정하는 데 도움이 됩니다.
🐱 쉽게 기억하기:
Role = “너는 누구야?”
Context — 어떤 상황인가?
Context는 Claude가 스스로 알 수 없는 배경정보입니다.
예를 들어:
이 계약서는 이미 1차 협상이 끝난 최종안이고, 서명 전 마지막 법무 검토 단계다.
같은 정보입니다.
대상 독자, 현재 상황, 이전에 내려진 결정, 원본 자료 등이 Context에 해당합니다. 이런 정보가 빠지면 Claude는 사용자가 의도한 것과 다른 전제를 가지고 작업할 수 있습니다.
🐱 쉽게 기억하기:
Context = “지금 무슨 상황이야?”
Task — 무엇을 해야 하는가?
Task는 Claude에게 원하는 구체적인 행동입니다.
예를 들면:
요약해줘.
비교해줘.
식별해줘.
초안을 작성해줘.
가능하면 명확한 주 동사를 사용합니다.
만약
“검토하고, 요약하고, 문제점을 찾고, 개선안도 만들어줘.”
처럼 여러 작업이 한꺼번에 섞여 있다면 하나의 Prompt에 너무 많은 Task가 들어간 것일 수 있습니다.
이것은 뒤에서 설명할 Task Decomposition이 필요한 신호가 될 수 있습니다.
🐱 쉽게 기억하기:
Task = “뭘 해야 해?”
Constraints — 무엇을 지켜야 하는가?
Constraints는 작업의 경계조건입니다.
예를 들어:
원문을 반드시 인용한다.
추측하지 않는다.
계약서에 없는 내용은 “명시되지 않음”이라고 표시한다.
길이, 톤, 포함해야 할 내용, 제외할 내용, 피해야 할 표현 등도 Constraints가 될 수 있습니다.
🐱 쉽게 기억하기:
Constraints = “어떤 규칙을 지켜야 해?”
Format — 어떤 형태로 받을 것인가?
마지막은 결과물의 형식입니다.
예를 들어 단순히:
표로 만들어줘.
라고 하는 것보다:
조항명 / 원문 인용 / 위험도 / 이유의 4개 컬럼으로 표를 작성해줘.
라고 지정하면 원하는 결과에 훨씬 가까워집니다.
Format을 처음부터 명확하게 지정하면 결과를 받은 후 다시 “표로 바꿔줘”라고 요청하는 불필요한 iteration을 줄일 수 있습니다.
🐱 쉽게 기억하기:
Format = “어떤 모습으로 줄 거야?”
Before vs After
Before vs After: Prompt가 어떻게 달라질까?
이제 다섯 가지 요소를 실제 예제로 비교해보겠습니다.
❌ Before
이 계약서 좀 검토해줘.
이 Prompt에는 어떤 관점에서 무엇을 검토해야 하는지, 어떤 결과물을 원하는지가 명확하지 않습니다.
✅ After
너는 SaaS 계약 검토 경험이 10년 이상인 법무 담당자다. 아래
<contract>태그 안의 계약서에서 (1) 자동 갱신 조항, (2) 손해배상 상한, (3) 데이터 보안 조항을 찾아 각각 원문 인용과 함께 위험도(상/중/하)를 표로 정리해줘. 표는 조항명 / 원문 인용 / 위험도 / 이유 4개 컬럼으로 구성해.
이 Prompt에는 Role, Context/입력 범위, Task, Constraints, Format이 훨씬 구체적으로 들어가 있습니다.
🐱 Vibe Code K-Mom 암기법
저는 이렇게 정리하면 기억하기 쉽다고 생각합니다.
WHO → SITUATION → WHAT → RULES → OUTPUT
즉:
Role → Context → Task → Constraints → Format
입니다.
2. 복잡한 요청은 Task Decomposition으로 나누기
좋은 Prompt를 만들었다고 해서 모든 작업을 하나의 Prompt에 넣는 것이 좋은 것은 아닙니다.
여러 단계가 필요한 복잡한 요청이라면 하나의 거대한 Prompt보다 작업을 순서가 있는 작은 단계로 분해하는 것이 중요합니다.
예를 들어:
“이 세 벤더를 평가해서 어디를 선택해야 할지 알려줘.”
라고 요청하면 Claude는 평가 기준 설정부터 비교와 추천까지 한 번에 처리해야 합니다.
대신 다음과 같이 나눌 수 있습니다.
Step 1 — Derive Criteria
요구사항에서 평가 기준과 가중치를 도출합니다.
↓
Step 2 — Score Vendors
확정된 기준을 이용해 각 벤더를 평가합니다.
↓
Step 3 — Raise Trade-offs
벤더별 장단점과 중요한 trade-off를 분석합니다.
↓
Step 4 — Recommend
앞 단계에서 확인한 기준과 trade-off를 근거로 추천을 작성합니다.
이 순서가 중요한 이유는 앞 단계의 결과가 다음 단계의 입력이 되기 때문입니다.
왜 이렇게 나누는 걸까?
Task Decomposition의 장점 중 하나는 중간 결과를 검증할 수 있다는 것입니다.
예를 들어 첫 단계에서 평가 기준 자체가 잘못됐다면 최종 결과가 나온 후가 아니라 다음 단계로 넘어가기 전에 수정할 수 있습니다.
또 여러 결과물을 만들어야 한다면 공통으로 사용되는 중요한 정보를 먼저 추출하고 검증한 다음 각각의 결과물을 만드는 구조가 유용합니다.
원본 학습 노트의 정책 변경 예제에서는:
Extract → Validate → Announcement / FAQ / Executive Briefing
순으로 구성되어 있습니다
3. Iteration: 결과가 마음에 안 든다고 처음부터 다시 하지 말기
Claude의 첫 번째 결과가 항상 완벽할 필요는 없습니다.
중요한 것은 결과가 마음에 들지 않을 때 Prompt 전체를 버리고 다시 작성하는 것이 아니라 무엇이 부족했는지를 찾아 수정하는 것입니다.
예를 들어 결과가 너무 일반적이라면:
→ Context가 부족하지 않은지 확인
엉뚱한 질문에 답했다면:
→ Task가 모호하지 않은지 확인
길이나 Tone이 맞지 않는다면:
→ Constraints가 빠지지 않았는지 확인
형식이 원하는 것과 다르다면:
→ Format을 더 명확하게 지정
하는 식입니다.
실제 Iteration 예제
첫 Prompt:
고객에게 납기 지연에 대한 후속 이메일을 써줘.
결과가 너무 일반적이라면 Prompt 전체를 버리는 대신 부족한 Context와 Constraints를 추가합니다.
분석 결과물이 이틀 지연된 것에 대해 고객에게 후속 메일을 써줘. 원인은 데이터 품질 문제였고 지금은 해결됐어. 새 납품일은 목요일이야. 톤은 책임감 있게 하되 과도하게 사과하지 말고, 120단어 이내로 작성해줘.
결과가 좋아졌는데 Subject만 없다면:
좋아. 지연이 아니라 해결을 강조하는 제목을 추가해줘.
이렇게 문제가 있는 부분만 조금씩 수정합니다.
언제 Iteration을 멈출까?
수정할 때마다 큰 개선이 일어나는 것이 아니라 아주 작은 변화만 생기기 시작한다면 멈출 시점입니다.
목표는 완벽한 Prompt를 만드는 것이 아니라 실제로 사용할 수 있는 결과물을 만드는 것입니다.
4. 작업 유형에 따라 Prompting 전략 바꾸기
모든 작업에 똑같은 Prompt 전략을 사용할 필요는 없습니다.
학습 노트에서는 크게 다음 네 가지 작업 유형을 비교합니다.
Analysis / Research / Drafting / Brainstorming
Analysis
분석에서는 기준, 표준, 범위를 명확하게 설정하는 것이 중요합니다.
창의적인 자유도는 낮추고 무엇을 기준으로 판단할지 구체적으로 지정합니다.
Research
Research에서는 범위와 출처가 중요합니다.
무엇을 조사할지, 어디까지 조사할지, 최신 자료가 필요한지, 출처를 어떻게 제시할지를 명확하게 지정합니다.
Drafting
초안 작성에서는 독자, Tone, Format을 명확하게 지정합니다.
하지만 모든 문장을 지나치게 통제하기보다는 실제 문장 표현은 Claude에게 어느 정도 맡깁니다.
Brainstorming
Brainstorming에서는 반대로 자유도를 높여줍니다.
처음부터 조건을 너무 많이 지정하면 다양한 아이디어가 나오는 것을 막을 수 있습니다.
그래서 목표와 기본적인 경계만 지정하고 먼저 다양한 아이디어를 얻은 다음 좁혀가는 방식입니다.
한눈에 정리하면
| Task | 명확하게 지정할 것 | Claude에게 맡길 것 |
|---|---|---|
| Analysis | 기준, 표준, 범위 | 문장 표현 |
| Research | 질문, 출처, 인용 | 종합 방식 |
| Drafting | 독자, Tone, Format | 단어 선택 |
| Brainstorming | 목표와 기본 Guardrail | 아이디어의 수와 방향 |
핵심정리
Prompting & Task Execution에서 제가 기억하고 싶은 핵심은 네 가지입니다.
1️⃣ 좋은 Prompt의 기본 구조
Role → Context → Task → Constraints → Format
2️⃣ 복잡한 작업은 분해한다
Task Decomposition
큰 작업을 한 번에 요청하기보다 검증 가능한 작은 단계로 나눕니다.
3️⃣ 결과가 부족하면 원인을 찾아 수정한다
Iteration
모든 것을 처음부터 다시 쓰기보다 부족한 Context, Task, Constraints 또는 Format을 찾아 수정합니다.
4️⃣ 작업에 따라 Prompt 전략을 바꾼다
Analysis와 Brainstorming에 똑같은 수준의 Constraints를 적용할 필요는 없습니다.
Claude에게 어디까지 통제하고 어디까지 자유를 줄 것인지 판단하는 것이 중요합니다
🐱 Check Your Understanding
마지막으로 간단한 문제입니다.
다음 Prompt를 보세요.
“우리 회사의 새로운 서비스 아이디어를 20개 만들어줘. 각 아이디어를 비용, 개발기간, 예상매출, 리스크의 네 가지 기준으로 분석하고 가장 좋은 아이디어 하나를 선정해서 경영진 보고서까지 작성해줘.”
이 Prompt에는 여러 개의 작업이 한꺼번에 들어가 있습니다.
Q. 이 작업을 Claude에게 맡긴다면 어떤 단계로 나누는 것이 좋을까요?
Show Answer
Step 1 — 아이디어 생성 (Generate Ideas)
새로운 서비스 아이디어 20개를 먼저 생성합니다.
Step 2 — 평가 기준 확정 (Define Evaluation Criteria)
비용, 개발 기간, 예상 매출, 리스크를 어떻게 평가할지 기준을 명확히 합니다.
Step 3 — 아이디어 분석 (Evaluate Ideas)
확정한 기준으로 20개 아이디어를 각각 평가합니다.
Step 4 — Trade-offs 비교
점수가 높은 후보들의 장점, 단점, 비용과 리스크 등의 trade-off를 비교합니다.
Step 5 — 최종 후보 결정 및 보고서 작성
검증된 분석 결과를 바탕으로 최종 후보를 결정하고 경영진용 보고서를 작성합니다.
핵심은:
Generate → Define Criteria → Evaluate → Compare Trade-offs → Final Report