09. 단계적 사고 유도 (chain-of-thought)

이 장은 이 안내서의 "반미신" 원칙이 가장 선명하게 드러나는 곳입니다. 한때 만능 주문처럼 퍼졌던 기법이, 모델 세대가 바뀌며 어떻게 달라졌는지를 통해 "어제의 정답이 오늘의 오답이 되는" 이 분야의 본질을 보여줍니다.

단계적 사고란

복잡한 문제를 풀 때, 답을 곧장 내놓는 대신 중간 추론 과정을 거치게 하는 기법입니다. "단계별로 생각해보자(let's think step by step)" 같은 문구를 붙이거나, 풀이 과정을 먼저 쓰게 한 뒤 결론을 내게 하는 식입니다. 영어로 chain-of-thought(사고 사슬, 줄여서 CoT)라 부릅니다.

[단계적 사고 없이]
Q: 사과 3개에 2400원, 5개 사면 얼마?
A: 4000원   ← 곧장 답 (틀릴 수도)

[단계적 사고]
Q: 사과 3개에 2400원, 5개 사면 얼마? 단계별로 풀어줘.
A: 사과 1개 = 2400 ÷ 3 = 800원.
   5개 = 800 × 5 = 4000원.
   답: 4000원   ← 과정을 거쳐 답

왜 통하는가 — 원리

2장의 직관으로 설명됩니다. 모델은 다음 토큰을 순차적으로 생성합니다. 답을 곧장 내라고 하면, 모델은 복잡한 계산·추론을 "머릿속에서 한 번에" 끝내고 결과 토큰만 내야 합니다. 그런데 모델에는 우리 같은 별도의 작업 기억이 없습니다. 생성하는 토큰의 흐름 자체가 곧 사고 과정입니다.

중간 과정을 글로 쓰게 하면, 그 과정 토큰들이 컨텍스트에 쌓여 다음 토큰의 근거가 됩니다. 즉 모델이 "생각할 공간"을 텍스트로 확보하는 셈입니다. 그래서 talking through(말로 풀어가기)로 풀 수 있는 작업, 즉 사람이 단계를 설명할 수 있는 문제라면 단계적 사고가 잘 듣습니다. 한 가이드의 표현처럼, 단계를 설명할 수 있는 문제면 일단 시도해볼 만합니다.

📌 핵심: 단계적 사고는 모델에게 "생각을 펼칠 종이"를 주는 것입니다. 곧장 답하면 그 종이가 없어, 복잡한 추론에서 실수가 잦아집니다.

그런데 — 최신 모델에서는 달라졌다

여기가 핵심 반전입니다. 위 원리는 여전히 유효하지만, 최신 모델들은 이 "생각할 공간"을 스스로 만들도록 이미 훈련되어 있습니다. 이런 모델을 흔히 추론 모델(reasoning model)이라 부릅니다.

추론 모델에게 "단계별로 생각해"를 굳이 덧붙이면 어떻게 될까요?

⚠️ 흔한 실수·미신 (이 장의 핵심): 추론이 내장된 모델에 "think step by step"을 추가하는 것은 불필요하거나 오히려 성능을 해칠 수 있습니다. 한 제공자는 자사 추론 모델(o1·o3 계열 등)에 대해 "이미 내부적으로 단계별 사고를 하므로 'think step by step'을 추가하지 말라"고 명시합니다. 또 다른 사례로, 라우터 기반 모델에서는 "hard하게 생각해" 같은 문구가 문자 그대로 추론 모드를 켜는 트리거로 작동해, 잘못 쓰면 의도와 다른 동작을 유발하기도 합니다.

이것이 1장에서 예고한 "어제의 정답이 오늘의 오답"의 가장 깨끗한 사례입니다. 한 세대 전 거의 보편적으로 권장되던 문구가, 다음 세대에서는 군더더기이거나 역효과가 된 것입니다.

그래서 어떻게 판단하나 — 모델 유형별 접근

flowchart TB
    task["복잡한 추론 작업인가?"] -->|아니오| simple["단계적 사고 불필요<br/>(단순 작업엔 토큰 낭비)"]
    task -->|예| type{"쓰는 모델이<br/>추론 모델인가?"}
    type -->|일반 모델| cot["단계적 사고가<br/>도움될 가능성 높음<br/>→ 과정을 쓰게 유도"]
    type -->|추론 모델| builtin["대개 불필요<br/>→ 문제를 명확히 기술하고<br/>곧장 맡겨라"]
    builtin --> verify["단, 직접 검증으로 확인"]
    cot --> verify

    classDef dec fill:#fef9c3,stroke:#eab308,color:#713f12
    classDef tech fill:#dbeafe,stroke:#3b82f6,color:#1e3a8a
    classDef warn fill:#fee2e2,stroke:#ef4444,color:#7f1d1d
    classDef good fill:#dcfce7,stroke:#22c55e,color:#14532d
    class task,type dec
    class cot,builtin tech
    class simple warn
    class verify good

💡 팁: 모델이 추론 모델인지 모르겠다면, 그 모델 공식 문서의 프롬프팅 가이드를 확인하세요. 추론 모델은 보통 "프롬프트를 단순하게 유지하라", "단계 지시를 빼라"는 안내가 있습니다.

단계적 사고를 쓸 때의 형태

일반 모델에 단계적 사고가 유효하다고 판단했다면, 몇 가지 형태가 있습니다.

형태 A — 단순 유도
"...단계별로 풀어줘."

형태 B — 구조 지정 (과정과 결론을 분리)
"먼저 <풀이> 안에 추론 과정을 쓰고,
그다음 <답> 안에 최종 결론만 써줘."

형태 C — 근거 먼저 (결론 전에 증거 요구)
"결론을 내기 전에, 관련 근거를 먼저 나열해줘."

형태 B·C의 장점은, 과정과 결론을 분리하면 결론만 따로 뽑아 쓰기 쉽고, 과정을 검토해 오류를 잡기도 좋다는 것입니다. 한 가이드는 "결론보다 증거를 먼저 요구하라"를 고임팩트 기법으로 꼽습니다.

🔧 개발자 노트: 추론 모델 중에는 내부 사고 과정을 별도로 노출하는(thinking/reasoning 토큰) 경우가 있습니다. 이때 사고 과정은 모델이 알아서 생성하므로, 프롬프트로 "단계별로"를 강제하기보다 사고의 깊이(thinking level/effort)를 파라미터로 조절하는 편이 맞습니다. 지연이 중요하면 사고 수준을 낮추고, 어려운 문제면 높이는 식입니다. 자세한 조절법은 모델마다 다르니 공식 문서를 확인하세요.

🧪 직접 검증법: 자신이 쓰는 모델에 복잡한 추론 문제(논리 퍼즐, 다단계 계산 등)를 (a) 곧장 답 요청, (b) "단계별로" 추가 두 가지로 각각 여러 번 풀려보세요. 정확도가 (b)에서 오르면 그 모델엔 단계적 사고가 유효, 차이 없거나 떨어지면 추론 내장형일 가능성이 큽니다. 이 검증이 이 장 전체보다 당신의 실무엔 더 정확한 답입니다.

사고 과정을 믿어도 되나

한 가지 미묘한 주의. 모델이 보여주는 "단계별 풀이"가 실제로 답에 이른 경로라는 보장은 없습니다. 그럴듯해 보이는 사후 정당화일 수도 있습니다. 그러니 단계적 사고의 과정은 "검토에 참고할 자료"로 보되, "이 과정이 맞으니 답도 맞다"고 맹신하지는 마세요. 정확성 확보는 4부에서 별도로 다룹니다.

이 장에서 배운 것

• 단계적 사고는 모델에게 "생각을 펼칠 종이"를 주는 기법으로, 사람이 단계를 설명할 수 있는 복잡한 작업에서 잘 듣는다.
• 그러나 최신 추론 모델은 이 과정을 내장하고 있어, "단계별로 생각해"를 추가하면 불필요하거나 역효과일 수 있다. 이것이 이 분야의 "어제의 정답이 오늘의 오답" 대표 사례다.
• 판단 기준: 단순 작업엔 불필요, 일반 모델 + 복잡 작업엔 유효 가능, 추론 모델엔 대개 불필요하니 문제를 명확히 주고 맡긴다.
• 쓸 때는 과정과 결론을 분리하면 결론 추출·오류 검토에 유리하다. "결론 전 근거 먼저"도 효과적이다.
• 모델이 보여주는 풀이가 실제 경로라는 보장은 없으므로, 참고하되 맹신하지 않는다.

✍️ 확인 문제

1. "단계별로 생각해"라는 문구가 한때는 거의 보편적으로 권장되다가 최신 모델에선 역효과가 될 수 있게 된 이유를, 2장의 "생각할 공간" 개념과 "추론 내장"을 사용해 설명해보세요.

1. 다음 작업 중 단계적 사고가 불필요할 것을 모두 고르고 이유를 적어보세요.
   • (a) "이 영어 문장을 한국어로 번역해줘"
   • (b) "이 가계부에서 항목별 합계를 구하고 예산 초과 여부를 판단해줘"
   • (c) "이 단어의 동의어 3개를 알려줘"
   • (d) "이 논리 퍼즐의 범인을 추론해줘"

1. (실습) 일반 모델로 다단계 계산 문제를 풀게 하되, 과정과 최종 답을 분리해 받고 싶습니다. 형태 B를 활용한 프롬프트를 작성해보세요.

다음 → 10. 제약과 금지의 명시
이전 ← 08. 출력 형식 지정 · 목차