CPN 한국어 자습서 · Claude Certified Developer — Foundations Prep
2-3 · 확장 사고
Extended Thinking: Turning reasoning on, calibrating effort, and reading it back correctly
프롬프팅 기법이 Claude가 무엇을 내놓을지를 다뤘다면, 확장 사고는 답하기 전에 모델이 얼마나 생각할지를 정합니다. 켜면 모델이 단계별 추론을 먼저 적어 낸 다음 최종 답을 내놓습니다. 이 레슨에서는 확장 사고를 언제 켜는 것이 좋은지, 강도를 어떻게 맞추는지, 그리고 돌려받은 추론을 어떻게 다뤄야 하는지를 차례로 살펴봅니다.
이 장에서 배우는 것What you'll learn
약 15분확장 사고를 켜면 무슨 일이 일어나는지 — thinking_block과 요약 표시 설정
요청마다 깊이를 정하는 적응형 추론과 effort(강도) 설정
폐기된 budget_tokens와 추론 토큰 비용
언제 켜고 언제 끄는지 — 과제 유형 세 가지
도구 루프의 캐리백 규칙과 signature
실수하기 쉬운 지점 — thinking block을 지우지 않기
400 오류가 난다.확장 사고를 켜면 모델이 답을 내기 전에 생각을 소리 내 적습니다. 이 추론은 API 응답 안에서 thinking_block이라는 자리에 담겨 돌아오고, 실제 답이 담긴 블록 바로 앞에 놓입니다. 최신 모델에서는 이 블록의 내용이 기본적으로 비워진 채 오기 때문에, 읽을 수 있는 요약을 보려면 표시 설정에서 따로 요청해야 합니다.
요즘 모델의 추론은 적응형입니다. 기본으로 켜져 있지 않은 경우 thinking 파라미터로 켜 주면, 요청마다 추론이 얼마나 필요한지는 모델이 스스로 정합니다. 깊이는 고정된 토큰 예산이 아니라 effort(강도) 설정으로 맞춥니다. 예전에 쓰던 budget_tokens 설정은 폐기됐고, 최신 세대 모델에서는 400 오류를 돌려줍니다.
추론이 공짜는 아닙니다. 추론 토큰은 출력 토큰과 같은 값으로 과금되기 때문에, 간단한 과제를 높은 강도로 돌리면 필요하지도 않은 정확도에 돈을 쓰는 셈이 됩니다. 여기서의 선택은 앞에서 이미 한 선택과 같습니다. 도구를 과제에 맞추는 것입니다. 확장 사고를 기본값처럼 켜 두기보다, 필요한 자리에 골라서 적용하는 편이 좋습니다.
확장 사고는 답을 내기 전에 모델이 머릿속 계산을 글로 풀어 보는 것과 비슷합니다. 어려운 문제에서는 이 과정이 정확도로 돌아오지만, 간단한 문제에서는 시간과 비용만 늘어납니다.
확장 사고를 늘 켜 두기보다, 과제의 성격을 보고 결정하는 것이 좋습니다. 아래 세 가지 유형이 판단의 기준이 됩니다.
TASK SHAPE → THINKING CALL — 과제 유형별 판단
| 과제 유형 | 확장 사고 판단 | 그렇게 하는 이유 |
|---|---|---|
| 여러 조건을 동시에 붙들어야 하는 다단계 추론. 수학 유도, 여러 단계를 거치는 논리 문제, 서로 의존하는 행동을 순서대로 계획하는 일. | 켠다. 강도를 문제의 깊이에 맞춘다. | 추론 단계는 모델이 그냥 지나쳤을 의존 관계까지 짚고 넘어가는 자리다. |
| 기계적이거나 찾아보기만 하면 되는 과제. 분류, 형식 변환, 필드 추출, 짧은 사실 답변. | 끈다. | 확장 사고를 켜도 답이 나아지지 않고, 필요 없는 토큰만 더 낸다. 출력 제약을 붙인 간단한 프롬프트가 맞는 도구다. |
| 여러 도구 호출에 걸쳐 계획을 세우는 에이전트 루프. | 켜되, 호출마다가 아니라 계획 단계에 비용을 잡아 둔다. | 계획을 세우기 전에 추론을 하면 뒤에서 잘못된 도구를 고르는 일이 줄어든다. 도구를 쓰는 루프에는 아래 캐리백 규칙이 늘 함께 적용된다. |
세 번째 유형인 에이전트 루프여러 번의 도구 호출을 오가며 모델이 스스로 다음 행동을 정하는 반복 구조.에는 조건이 하나 더 붙습니다. 도구를 쓰는 대화라면 다음 규칙이 늘 함께 따라오기 때문입니다.
확장 사고가 켜져 있고 대화에서 도구를 함께 쓴다면, 빠뜨릴 수 없는 규칙이 하나 있습니다. 돌려받은 thinking block은 다음 차례에 받은 그대로 API로 되돌려 보내야 합니다.
각 블록에는 signature가 붙어 있어서 추론이 중간에 바뀌지 않았음을 확인해 줍니다. 그래서 블록을 손대면 이 서명이 어긋나고, API는 그 요청을 거절합니다.
내용이 암호화돼 사람이 읽을 수 없는 redacted thinking block도 규칙은 같습니다. 사람이 읽도록 만든 블록은 아니지만, 그래도 손대지 않고 그대로 되돌려 보내야 합니다. 이것은 프롬프트를 어떻게 쓸지 고르는 선택이 아니라 구조적인 요구 사항입니다.
돌려받은 추론 블록은 다음 차례에 그대로 다시 넣어야 하는 조각입니다. 컨텍스트를 아끼려고 이 조각을 빼면, 다음 요청 자체가 막힙니다.
지금까지 본 내용을 짧게 묶어 봅니다. 확장 사고가 값을 하는 자리와 조심해야 하는 자리는 대체로 갈립니다.
WHERE IT FITS — 잘 맞는 곳 · 비용 · 다른 방법
| 잘 맞는 곳 | 답을 틀리면 손해가 큰 어려운 추론·계획 과제. 추가로 드는 토큰이 정확도로 돌아오는 경우입니다. |
|---|---|
| 비용·복잡도가 느는 곳 | 도구를 쓰는 루프에서 지켜야 하는 캐리백 규칙, 그리고 이제 직접 맞춰야 하는 effort 설정입니다. |
| 다른 방법이 나은 곳 | 분류·추출·형식 변환 과제에는 잘 다듬은 프롬프트가 더 싸고, 정확도도 같습니다. |
이 레슨은 추론을 켤지 말지와 강도를 어떻게 맞출지까지만 다룹니다. 어떤 모델을 돌릴지 고르는 문제는 결이 다르고, 이 앞에 놓인 기초 모듈(MSO Foundations)에서 따로 다룹니다.
budget_tokens는 쓰지 않습니다 — 추론 토큰은 출력 토큰과 같은 값으로 과금됩니다.세 가지 작업이 있습니다. 각 작업에 확장 사고를 켜야 할지, 꺼야 할지, 아니면 해서는 안 되는 일인지 하나씩 골라 보세요. 작업마다 맞는 판단은 하나입니다. 정답을 먼저 떠올려 본 뒤 선택하면, 맞혔을 때 설명이 나옵니다.
Q1지원 티켓 50,000건을 하룻밤 사이에 세 가지 라벨로 분류하는 작업입니다. 확장 사고는 어떻게 할까요?
한 단어짜리 라벨을 붙이는 데는 추론 단계가 필요 없습니다. 티켓마다 추론 토큰을 쓰면 5만 번의 호출에 걸쳐 출력 비용만 배로 늘고, 정확도가 나아지지는 않습니다.
Q2각 단계가 앞 단계에 의존하는 다단계 리팩터링(코드 구조 정리)을 계획하는 작업입니다. 확장 사고는 어떻게 할까요?
서로 의존하는 단계를 하나씩 풀어 가기 전에 계획을 먼저 확정하는 추론 단계가 없으면, 첫 번째 의존 단계부터 어긋나기 쉽습니다. 그래서 켜 두되 비용은 호출마다가 아니라 계획 단계에 잡아 둡니다.
Q3다음 도구 호출 전에 컨텍스트를 아끼려고, 대화 기록에서 thinking block을 빼내려 합니다. 이 선택은 어떤가요?
thinking block을 빼내면 signature가 더 이상 맞지 않아 다음 요청이 거절됩니다. 쌓이는 추론이 부담이라면 블록을 손대는 대신 컨텍스트 엔지니어링으로 관리합니다.
세 결정을 묶어 보면 방향이 분명해집니다. 대량 분류에는 확장 사고를 끄고, 서로 의존하는 다단계 계획에는 켜서 비용을 계획 단계에 잡아 두며, thinking block을 빼내는 일은 하지 않습니다. signature가 어긋나면 대화 자체가 이어지지 않기 때문입니다.
모듈 2의 다음 레슨은 도구 사용과 스키마 설계(Tool-use and Schema Design)를 다룹니다. → 도구 사용과 스키마 설계
전 코스는 계속 무료입니다. 등록하면 이 코스의 남은 38개 레슨을 끝까지 읽을 수 있습니다.
이미 등록하셨다면 그때 쓰신 이메일을 넣어 주세요.