Reasoning Model 프롬프팅 완전 정복 — o1, o3, Claude Extended Thinking 활용법

들어가며: 13편이 남긴 질문

13편에서 멀티 에이전트 시스템을 다루며 이런 예고를 남겼습니다.

"이 에이전트들이 더 복잡한 추론을 하게 하려면 어떻게 해야 할까?"

지금까지 이 시리즈에서 배운 프롬프트 기법들이 있습니다. 명확한 지시, CoT로 단계별 생각 유도, Few-shot 예시 제공, XML 태그로 역할 구분. 이 모든 기법은 하나의 전제를 깔고 있습니다.

"모델은 내가 유도하는 대로 생각한다."

그런데 최근 등장한 AI 모델들은 이 전제를 뒤집습니다.

답을 내놓기 전에 스스로 길게, 때로는 수천 토큰을 써가며 생각합니다. 사람이 시키지 않아도요. 이 모델들을 Reasoning Model이라고 부릅니다. OpenAI의 o1·o3, Claude의 Extended Thinking이 대표적입니다.

그리고 이 모델들은 기존 프롬프트 방식이 잘 통하지 않습니다. 심지어 잘 쓰던 기법이 오히려 성능을 떨어뜨리기도 합니다.

이번 편에서는 Reasoning Model이 무엇인지, 왜 기존 방식이 안 통하는지, 그리고 어떻게 프롬프팅해야 하는지를 처음부터 끝까지 다룹니다.

---

1. Reasoning Model이란 무엇인가

1.1. 기존 모델과 한 줄 차이

가장 단순하게 설명하면 이렇습니다.

# 기존 모델 (GPT-4o, Claude Sonnet 등)
입력 → [한 번의 순전파] → 출력

# Reasoning Model (o1, o3, Extended Thinking)
입력 → [내부 추론 과정 (수백~수천 토큰)] → 출력

기존 모델은 입력을 받으면 바로 출력을 생성합니다. 마치 즉흥적으로 말하는 사람처럼요.

Reasoning Model은 출력하기 전에 먼저 "생각"합니다. 이 생각 과정은 사용자에게 보이지 않거나(o1), 또는 별도의 "thinking" 블록으로 보여주기도 합니다(Claude Extended Thinking). 생각을 마친 뒤에야 최종 답변을 내놓습니다.

1.2. 내부에서 무슨 일이 일어나는가

Reasoning Model이 "생각하는" 과정은 우리가 5편에서 다뤘던 Chain-of-Thought와 비슷해 보입니다. 실제로 원리는 연결되어 있지만 중요한 차이가 있습니다.

CoT는 우리가 시켜서 모델이 단계적으로 생각하게 만드는 기법입니다.
Reasoning Model의 내부 추론은 모델 자체에 학습된 행동입니다.

# CoT 프롬프트 — 사람이 지시한다
"다음 문제를 단계별로 풀어라.
 1단계: 조건 파악
 2단계: 수식 세우기
 3단계: 계산"

# Reasoning Model — 스스로 한다
사용자: "문제를 풀어줘"
내부 추론: (모델이 알아서 조건 파악 → 수식 → 계산을 반복)
출력: "답은 42입니다."

사람으로 비유하면 이렇습니다. 기존 모델에게 "차근차근 생각해봐"라고 말해서 깊게 생각하게 만드는 것이 CoT입니다. Reasoning Model은 따로 말 안 해도 원래 그렇게 생각하는 사람입니다.

1.3. 주요 Reasoning Model 현황

---

2. 기존 프롬프트 기법이 왜 안 통하는가

2.1. "단계별로 생각해" — 이미 하고 있다

CoT의 핵심은 "Let's think step by step"처럼 모델이 단계적으로 생각하도록 유도하는 것입니다. 하지만 Reasoning Model에 이 지시를 추가하면 어떻게 될까요?

# 기존 모델에게 CoT 적용 — 효과 있음
"이 코드의 버그를 찾아라. 단계별로 분석하라."
→ 모델이 줄 단위로 분석하기 시작함 ✅

# Reasoning Model에게 CoT 적용 — 의미 없거나 역효과
"이 코드의 버그를 찾아라. 단계별로 분석하라."
→ 모델이 이미 내부에서 단계별로 분석 중
→ 외부 지시가 내부 추론과 충돌할 수 있음 ⚠️

Reasoning Model은 이미 스스로 단계적으로 추론합니다. CoT 지시를 추가해도 추가 효과가 없거나, 오히려 모델의 내부 추론 흐름을 방해합니다.

2.2. Few-shot 예제 — 독이 될 수 있다

Few-shot은 원하는 답변 형식을 예시로 보여주는 기법입니다. 기존 모델에서는 매우 효과적입니다. 하지만 Reasoning Model에 상세한 추론 과정이 담긴 Few-shot을 넣으면 문제가 생깁니다.

# 기존 모델에 Few-shot — 효과적
예시:
Q: 5 × 7은?
A: 5를 7번 더하면 됩니다. 5+5+5+5+5+5+5 = 35. 정답: 35
---
Q: 8 × 6은?
→ 모델이 예시 형식을 따라 단계별로 풀어냄 ✅

# Reasoning Model에 동일한 Few-shot
→ 모델의 내부 추론이 이미 훨씬 복잡하고 정교함
→ 단순한 예시 추론 패턴을 강제하면 오히려 성능 저하 ❌

Reasoning Model에는 Few-shot을 아예 쓰지 않거나, 쓴다면 추론 과정 없이 입출력 형식만 보여주는 방식이 낫습니다.

# Reasoning Model용 Few-shot — 형식만 보여준다
예시 (형식 참고용):
Q: 계약서 분석
A: {"위험_조항": [...], "권장_수정": [...], "전체_리스크": "중"}
---
Q: 아래 계약서를 분석하라.
[계약서 내용]

2.3. 과도한 지시 — 모델의 추론을 방해한다

기존 모델에게는 "이렇게 생각하고, 저렇게 분석하고, 이 순서로 답하라"는 상세한 지시가 도움이 됩니다. 하지만 Reasoning Model에 이런 지시를 주면 어떻게 될까요?

# 기존 모델 — 상세한 지시가 도움됨
"다음 순서로 분석하라:
 1. 문제 정의
 2. 가설 설정
 3. 증거 검토
 4. 결론 도출
 각 단계를 ## 헤딩으로 구분해서 출력하라."
→ 모델이 지시대로 구조화된 분석을 함 ✅

# Reasoning Model — 과도한 지시가 역효과
동일한 지시
→ 모델의 내부 추론이 외부 지시에 얽매임
→ 유연한 추론 경로가 막혀 오히려 답이 단순해짐 ❌

Reasoning Model에는 목표만 명확히 주고, 과정은 모델에게 맡기는 것이 핵심입니다.

---

3. Reasoning Model 프롬프트 전략

3.1. 원칙: Less is More

Reasoning Model 프롬프팅의 핵심 원칙입니다.

# 기존 모델 스타일 — 길고 상세한 프롬프트
당신은 시니어 소프트웨어 엔지니어입니다.
코드를 검토할 때는 다음 순서를 따르세요:
1. 먼저 전체 구조를 파악하세요
2. 각 함수의 역할을 확인하세요
3. 버그 가능성이 있는 부분을 표시하세요
4. 최종적으로 개선 방안을 제시하세요
반드시 한국어로 답하세요.

# Reasoning Model 스타일 — 짧고 명확한 프롬프트
시니어 소프트웨어 엔지니어로서 이 코드를 검토하고 버그와 개선 방안을 한국어로 제시하라.

두 번째 프롬프트가 더 짧지만, Reasoning Model에서는 오히려 더 나은 결과가 나옵니다. 모델이 자체적으로 가장 적합한 추론 경로를 찾기 때문입니다.

3.2. 목표를 명확히, 과정은 맡긴다

# ❌ 과정을 지시하는 방식
"먼저 데이터를 파싱하고, 그다음 이상값을 탐지하고,
 마지막으로 통계 요약을 내라."

# ✅ 목표만 명확히 주는 방식
"이 판매 데이터에서 이상값을 탐지하고 통계 요약을 내라."

# ❌ 사고 방식을 지정하는 방식
"귀납적으로 접근하여 개별 사례부터 분석한 뒤 일반 원칙을 도출하라."

# ✅ 원하는 결과만 지정하는 방식
"이 10개 사례에서 공통 패턴을 찾아 원칙으로 정리하라."

3.3. 출력 형식은 명확히 지정한다

과정을 맡기되, 결과물의 형식은 구체적으로 지정해야 합니다. 이 부분은 기존 모델과 동일합니다.

# 형식 지정 없음 — 모델이 임의로 결정
"이 계약서의 위험 요소를 분석하라."
→ 어떤 때는 목록, 어떤 때는 서술, 어떤 때는 표로 나옴

# 형식 명확히 지정
"이 계약서의 위험 요소를 분석하라.
 결과는 반드시 아래 JSON 형식으로만 출력하라:
 {
   '고위험': ['조항명 및 이유', ...],
   '중위험': ['조항명 및 이유', ...],
   '권장사항': ['수정안', ...]
 }"

3.4. 어려운 문제를 줘야 진가가 나온다

Reasoning Model은 간단한 작업에는 오버스펙입니다. 진가는 복잡한 문제에서 나옵니다.

# Reasoning Model에 맞지 않는 작업
"안녕하세요를 영어로 번역하라."
"이 텍스트를 요약하라."
"파이썬에서 리스트를 정렬하는 방법은?"
→ 기존 모델로 충분. Reasoning Model은 비용·시간 낭비

# Reasoning Model이 빛나는 작업
"이 시스템의 보안 취약점을 모든 공격 벡터 관점에서 분석하라."
"이 비즈니스 로직에서 발생 가능한 엣지 케이스를 모두 도출하라."
"다음 알고리즘의 시간 복잡도를 수학적으로 증명하라."
→ 복잡한 추론이 필요한 작업에서 기존 모델과 격차가 벌어짐

---

4. Claude Extended Thinking 실전 사용법

Claude Extended Thinking은 API에서 thinking 블록을 명시적으로 제어할 수 있습니다. 이 부분은 다른 Reasoning Model과 차별화된 특징입니다.

4.1. 기본 구조

import anthropic

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-opus-4-5",
    max_tokens=16000,
    thinking={
        "type": "enabled",
        "budget_tokens": 10000  # 내부 추론에 쓸 최대 토큰
    },
    messages=[{
        "role": "user",
        "content": "이 암호화 알고리즘의 취약점을 분석하라."
    }]
)

# thinking 블록과 최종 답변이 분리되어 반환됨
for block in response.content:
    if block.type == "thinking":
        print("내부 추론:", block.thinking)
    elif block.type == "text":
        print("최종 답변:", block.text)

4.2. budget_tokens 설정 기준

budget_tokens는 모델이 내부 추론에 쓸 수 있는 최대 토큰입니다. 문제의 복잡도에 따라 조정합니다.

# 단순 작업 — 작은 budget
response = client.messages.create(
    model="claude-opus-4-5",
    max_tokens=4000,
    thinking={"type": "enabled", "budget_tokens": 2000},
    messages=[{"role": "user", "content": "피보나치 수열의 점화식을 설명하라."}]
)

# 복잡한 작업 — 큰 budget
response = client.messages.create(
    model="claude-opus-4-5",
    max_tokens=20000,
    thinking={"type": "enabled", "budget_tokens": 15000},
    messages=[{"role": "user", "content": "이 분산 시스템의 장애 시나리오를 모두 도출하고 대응 방안을 설계하라."}]
)

4.3. Extended Thinking에서 피해야 할 것

# ❌ thinking 활성화 상태에서 temperature 변경 시도
# Extended Thinking은 temperature=1 고정. 변경 불가.
response = client.messages.create(
    model="claude-opus-4-5",
    thinking={"type": "enabled", "budget_tokens": 5000},
    temperature=0.5,  # 오류 발생
    ...
)

# ❌ streaming 없이 매우 큰 budget 사용
# 응답 시간이 수십 초 이상 걸릴 수 있음 → streaming 사용 권장
response = client.messages.create(
    model="claude-opus-4-5",
    thinking={"type": "enabled", "budget_tokens": 30000},
    stream=True,  # 긴 추론 시 streaming 필수
    ...
)

---

5. Reasoning Model 실패 패턴

5.1. 간단한 일에 쓰는 낭비

Reasoning Model은 기존 모델보다 느리고 비쌉니다. 간단한 작업에 쓰면 시간과 비용을 낭비합니다.

# 이런 질문에는 Reasoning Model이 오버스펙
"파이썬에서 print 함수 사용법은?"
"JSON이 뭔지 한 줄로 설명해줘"
"이 코드에서 오타 찾아줘"

# 이런 질문에 써야 한다
"이 코드베이스의 아키텍처 결함과 장기적 유지보수 위험을 분석하라"
"다음 조건을 모두 만족하는 알고리즘을 설계하고 증명하라"

5.2. 여전히 CoT를 추가하는 실수

습관적으로 "단계별로", "차근차근", "먼저 X를 하고, 그다음 Y를"을 붙이는 경우입니다.

# ❌ CoT 지시를 추가한 프롬프트
"이 수학 증명을 검토하라.
 1단계: 전제 조건 확인
 2단계: 각 단계의 논리 검토
 3단계: 반례 탐색
 4단계: 결론 도출"

# ✅ 목표만 명확히
"이 수학 증명이 올바른지 검토하고, 오류가 있다면 반례와 함께 제시하라."

두 번째 프롬프트가 더 짧지만 Reasoning Model에서는 더 나은 결과가 나옵니다.

5.3. 비용을 무시하는 설계

Reasoning Model의 내부 추론 토큰도 비용이 발생합니다. 모든 요청에 무조건 Reasoning Model을 쓰도록 설계하면 비용이 폭발합니다.

# ❌ 모든 요청에 Extended Thinking 적용
def handle_request(user_message: str) -> str:
    return claude_extended_thinking(user_message)  # 간단한 질문에도 동일

# ✅ 복잡도에 따라 분기
def handle_request(user_message: str) -> str:
    if needs_deep_reasoning(user_message):
        return claude_extended_thinking(user_message)  # 복잡한 추론 필요 시
    else:
        return claude_standard(user_message)  # 간단한 작업은 기존 모델

5.4. 출력 형식을 지정하지 않는 실수

과정은 맡기되, 형식은 반드시 지정해야 합니다. 형식이 없으면 매번 다른 구조로 답이 나옵니다.

# ❌ 형식 미지정
"이 코드의 문제점을 분석하라."
→ 어떤 때는 번호 목록, 어떤 때는 서술형, 어떤 때는 표

# ✅ 형식 명확히 지정
"이 코드의 문제점을 분석하라.
 결과는 다음 형식으로만 출력한다:
 **심각도**: 상/중/하
 **문제점**: (목록)
 **수정 제안**: (코드 포함)"

---

6. 언제 Reasoning Model을 쓰고, 언제 쓰지 않을까

6.1. Reasoning Model이 적합한 경우

✅ 수학 증명, 복잡한 수식 계산
✅ 멀티스텝 코드 디버깅 (여러 파일에 걸친 버그 추적)
✅ 보안 취약점 전수 분석
✅ 복잡한 비즈니스 로직의 엣지 케이스 도출
✅ 여러 조건이 얽힌 의사결정 분석
✅ 긴 문서에서 모순·논리 오류 탐지

6.2. 기존 모델이 더 나은 경우

❌ 단순 번역, 요약, 형식 변환
❌ 짧은 코드 작성 (함수 하나 정도)
❌ FAQ 답변, 정보 검색
❌ 감성적 글쓰기, 창작
❌ 속도가 중요한 실시간 응답 (챗봇 등)
❌ 비용 제약이 있는 대량 처리

6.3. 결정 기준 한 줄

"이 문제가 사람 전문가도 시간을 들여 생각해야 하는가?"

그렇다면 Reasoning Model. 아니라면 기존 모델이 낫습니다.

---

7. 기존 모델 vs Reasoning Model 완전 비교

---

결론: 도구의 전제를 이해하라

1편부터 13편까지 프롬프트를 잘 쓰는 법을 다뤘습니다. 명확하게 지시하고, 구조를 잡아주고, 예시를 들어주는 것이 좋은 프롬프트였습니다.

Reasoning Model은 이 전제를 바꿉니다. 지시를 줄이고, 구조를 강요하지 않고, 목표만 명확히 주는 것이 더 좋은 결과를 냅니다. 같은 AI 모델이지만 작동 방식이 근본적으로 다르기 때문입니다.

프롬프트 엔지니어링에서 가장 위험한 실수는 도구의 전제를 이해하지 못한 채 쓰던 방식을 그대로 적용하는 것입니다. 망치로 나사를 박는 것처럼요.

Reasoning Model을 쓸 때의 핵심은 단순합니다. 모델이 스스로 깊이 생각한다는 것을 신뢰하고, 목표만 명확히 주고, 결과 형식만 지정하는 것입니다.

핵심 원칙 요약

15편을 향하여

Reasoning Model까지 다뤘다면, 프롬프팅의 대상이 텍스트에서 이미지·오디오·동영상으로 확장되는 영역이 남아있습니다.

"텍스트가 아닌 이미지나 영상으로 AI에게 지시할 때는 어떻게 다를까?"

[15편: 멀티모달 프롬프팅 — 이미지·오디오·영상을 활용하는 AI 활용법] 에서는 텍스트를 넘어선 멀티모달 환경에서의 프롬프트 전략을 다룹니다.