지난 글에서 사고 예산을 어떻게 줄지 다뤘는데, 그 앞에 놓인 질문을 아직 안 했다. 애초에 추론 모델이 필요한가 하는 것이다. 단계적으로 생각하게 만드는 방법은 예전부터 있었다. 프롬프트 끝에 "단계별로 생각해 봐"를 붙이는 것, 즉 chain-of-thought 프롬프팅이다. 그것도 정확도를 올려 준다. 그런데 추론 모델은 그것과 무엇이 다른가. 둘을 같이 쓰면 더 좋아지는가. 실무에서 이 둘을 헷갈리면 돈은 추론 모델 값을 내면서 품질은 프롬프팅 수준으로 받는 일이 생긴다.
사고가 놓이는 자리가 다르다
겉으로 보면 둘 다 "모델이 중간 과정을 거쳐 답한다"는 같은 그림이다. 차이는 그 중간 과정이 어디에 기록되고 누가 그 형식을 정했느냐에 있다.
CoT 프롬프팅에서 추론 과정은 그냥 출력 토큰이다. 모델은 평소처럼 다음 토큰을 예측할 뿐이고, 프롬프트가 그 예측을 "먼저 조건을 정리하고, 그다음에…" 하는 문체로 유도할 뿐이다. 이 과정은 응답 본문 안에 그대로 담기므로 사용자에게 노출되고, 출력 토큰 단가로 과금되며, JSON 스키마 같은 출력 형식과 자리를 다툰다.
추론 모델에서 사고는 답변 앞에 따로 있는 구간이다. 모델이 사후 훈련 단계에서 "답하기 전에 길게 검토한다"는 습관 자체를 학습했고, API는 그 구간을 별도 필드로 분리해 준다. 대개 사용자에게는 보여 주지 않고, 과금은 되지만 출력 형식과 섞이지 않는다.
이 구조 차이가 실무에서 갈리는 지점을 만든다.
프롬프팅으로 얻는 것과 못 얻는 것
CoT 프롬프팅은 여전히 유효하다. 특히 모델이 원래 할 줄 아는데 성급하게 답하는 경우에 잘 듣는다. 세 자리 곱셈, 조건이 몇 개 붙은 필터링, 단위 변환이 낀 계산 같은 것들이다. 프롬프트 한 줄로 정확도가 눈에 띄게 오르고, 추가 비용은 늘어난 출력 토큰만큼이다.
한계는 세 가지다.
첫째, 문구에 흔들린다. "단계별로 생각해 봐"와 "차근차근 풀어 봐"의 결과가 다르고, 같은 문구도 모델을 바꾸면 효과가 달라진다. 프롬프트를 다듬는 작업이 끝나지 않는다.
둘째, 깊이를 정할 수 없다. 모델이 세 줄 쓰고 끝낼지 스무 줄 쓸지는 그때그때 다르다. 어려운 문제에서 더 오래 생각하게 만들 손잡이가 없다. "아주 자세히"를 붙이면 쉬운 문제에서도 장황해진다.
셋째, 자기 답을 되짚지 않는다. CoT 프롬프팅의 출력은 대체로 한 방향으로 흘러간다. 3단계에서 틀렸으면 4단계는 그 틀린 값을 그대로 받아 쓴다. 되돌아가서 "잠깐, 아까 그건 틀렸다"라고 하는 서술은 학습 데이터에 흔치 않기 때문이다. 반면 강화학습으로 훈련된 추론 모델은 그 되짚기 자체가 보상을 받은 행동이라 자연스럽게 나온다.
추론 모델에 CoT 프롬프트를 겹치면
가장 흔한 실수가 이것이다. 추론 모델을 붙여 놓고 프롬프트에는 예전에 쓰던 "단계별로 생각하고, 각 단계를 번호로 적은 뒤, 마지막에 답을 써라"를 그대로 둔다.
이러면 세 가지가 동시에 나빠진다.
- 답변이 장황해진다. 모델은 이미 사고 구간에서 검토를 끝냈는데, 프롬프트가 그 과정을 답변에도 다시 쓰라고 시킨 셈이다. 같은 내용이 두 번 생성되고 출력 토큰이 두 배가 된다.
- 사고가 얕아질 수 있다. 프롬프트가 사고의 형식을 지정하면 모델이 훈련으로 익힌 자기 방식 대신 지시받은 틀을 따라간다. 훈련된 습관 쪽이 대개 더 낫다.
- 형식 지시가 무시되기 쉽다. 사고 구간이 켜진 상태에서 출력 형식 지시가 여러 겹이면 지켜지는 비율이 떨어진다.
추론 모델의 프롬프트는 무엇을 원하는지와 답변 형식만 적는 것이 맞다. 어떻게 생각할지는 적지 않는다.
# 일반 모델에 쓰던 프롬프트
아래 로그를 분석해라. 단계별로 생각해 봐.
1) 먼저 시간순으로 정리하고
2) 이상 패턴을 찾고
3) 원인을 추론한 뒤
4) 마지막 줄에 결론을 써라.
# 추론 모델에 쓸 프롬프트
아래 로그에서 장애 원인을 찾아라.
결론 한 문단과 근거가 된 로그 줄 번호만 출력해라.무엇을 언제 쓰나
| 기준 | CoT 프롬프팅 | 추론 모델 |
|---|---|---|
| 추론이 놓이는 곳 | 출력 본문 안 | 답변 앞 별도 구간 |
| 사용자 노출 | 그대로 보임 | 보통 비노출 |
| 깊이 조절 | 프롬프트 문구로 간접 유도 | 예산 파라미터로 직접 지정 |
| 되짚기·자기 수정 | 거의 안 나옴 | 훈련된 기본 행동 |
| 지연 | 답변이 길어진 만큼 | 사고 구간이 통째로 추가 |
| 적용 범위 | 모든 모델 | 지원 모델에서만 |
| 잘 맞는 문제 | 절차가 정해진 얕은 계산 | 탐색이 필요한 문제 |
| 안 맞는 상황 | 여러 갈래를 비교해야 할 때 | 단순 분류·추출·요약 |
기준을 하나로 압축하면 이렇다. 정답으로 가는 길이 이미 정해져 있고 모델이 그 길을 알고 있으면 프롬프팅으로 충분하다. 길을 찾아야 하는 문제, 즉 여러 가설을 세워 보고 틀린 것을 버려야 하는 문제에서만 추론 모델이 값을 한다.
요약, 번역, 분류, 정보 추출은 전자에 속한다. 이런 작업에 추론 모델을 붙이면 비용과 지연만 늘고 품질은 그대로거나 오히려 나빠진다. 사고 구간에서 원문에 없는 해석을 만들어 내고 그게 답변에 스며들기 때문이다.
겹치지 않게 나누는 실무 형태
한 서비스 안에서 두 방식이 같이 있는 편이 보통이다. 요청 유형으로 갈라 놓고 프롬프트도 각각 따로 둔다.
import anthropic
client = anthropic.Anthropic()
# 사고 형식을 지시하지 않는다. 원하는 결과와 출력 형식만.
REASONING_PROMPT = "{task}\n\n결론과 근거만 출력해라."
# 일반 모델에는 절차를 명시한다.
COT_PROMPT = (
"{task}\n\n"
"먼저 필요한 값을 정리하고, 계산 과정을 적은 뒤, "
"마지막 줄에 `답: <값>` 형식으로 결론을 써라."
)
def solve(task: str, hard: bool) -> str:
if hard:
resp = client.messages.create(
model="claude-opus-5",
max_tokens=8000,
thinking={"type": "enabled", "budget_tokens": 4000},
messages=[{"role": "user", "content": REASONING_PROMPT.format(task=task)}],
)
else:
resp = client.messages.create(
model="claude-haiku-4-5-20251001",
max_tokens=1500,
messages=[{"role": "user", "content": COT_PROMPT.format(task=task)}],
)
return "".join(b.text for b in resp.content if b.type == "text")포인트는 두 프롬프트가 같은 문자열이 아니라는 것이다. 하나의 프롬프트를 두 경로에 재사용하면 어느 한쪽에서 반드시 손해를 본다.
프롬프팅 쪽을 먼저 끝까지 밀어 본다
도입 순서에 대해 한 가지만 덧붙인다. 정확도가 부족할 때 곧바로 추론 모델로 갈아타는 것은 대개 비싼 선택이다. 그 전에 해 볼 것이 남아 있다.
- 소수 예시를 붙인다. 원하는 추론의 모양을 두세 개 보여 주는 것이 "단계별로 생각해"보다 강하다.
- 문제를 쪼갠다. 한 번의 호출로 다섯 가지를 하게 하는 대신 두 번의 호출로 나눈다. 각 호출이 쉬워지면 얕은 CoT로도 맞는다.
- 필요한 값을 직접 준다. 모델이 계산으로 유도하던 값을 코드로 계산해 프롬프트에 넣는다. 추론할 것이 줄면 틀릴 여지도 준다.
이 셋을 다 하고도 정답률이 목표에 못 미치고, 그 미달이 탐색 부족 때문이라는 근거가 있을 때 추론 모델을 켠다. 근거는 실패 사례를 읽어 보면 나온다. 실패가 "중간에 계산을 틀렸다"면 위의 세 가지로 해결되고, "접근 자체를 잘못 잡았다"면 추론 모델이 필요하다.
측정 없이 고르지 않는다
두 방식을 비교할 때는 정확도만 보면 안 된다. 최소한 네 개를 같이 본다. 정답률, 요청당 총 비용, p95 지연, 그리고 출력 형식 준수율이다. 마지막 항목이 자주 빠지는데, 추론 모델로 옮긴 뒤 JSON 파싱 실패율이 올라 전체 성공률이 오히려 떨어지는 경우가 실제로 있다.
같은 100문항을 두 경로에 각각 흘려 이 넷을 표로 만들면 결정이 5분이면 끝난다. 그 표 없이 하는 논쟁은 대개 문구 취향 다툼으로 흐른다.
두 방식은 대체재가 아니라 다른 문제를 푸는 다른 도구다. 어느 쪽이 우월한지가 아니라, 지금 앞에 놓인 요청이 어느 쪽에 속하는지를 묻는 것이 맞는 질문이다.
지난 글: 사고 예산 제어: 얼마나 생각하게 할 것인가
다음 글: 추론 증류: 큰 모델의 사고를 작은 모델에 옮긴다
읽어주셔서 감사합니다. 😊