4장. 추론과 다단계 작업

학습 목표

• 추론 모델, 추론 토큰, 추론 강도가 품질·비용·지연에 미치는 영향을 설명한다.
• 추론 강도를 작업 유형과 지연 요구에 맞게 고르고, 그 선택을 평가로 확인한다.
• 추론 모델에 맞게 지시문의 수준을 조정하고, 사고 과정 대신 검증 가능한 근거를 요구한다.
• 다단계 작업을 단계별 프롬프트로 나누고, 단계 사이의 입출력 계약과 관문을 설계한다.
• 나누는 것이 손해인 경우를 알아보고, 병렬과 순차를 구분한다.

들어가며

한 마케팅 대행사가 광고 문안을 만드는 프롬프트에 “단계별로 꼼꼼히 생각하라”를 넣고 가장 높은 추론 강도를 설정했습니다. 결과는 조금 나아졌지만 응답마다 수십 초가 걸렸고, 청구서는 세 배가 되었습니다. 반대로 계약서 검토 기능은 빠르게 만들려고 낮은 강도로 한 번에 처리했는데, 조건이 세 개 이상 얽힌 조항에서 판단이 자주 틀렸습니다. 광고팀은 응답을 기다리다 마감을 놓쳤고, 계약 검토팀은 틀린 판단을 믿고 위험한 조항 하나를 그냥 넘겼습니다. 두 팀은 정반대로 보였지만 같은 실수를 했습니다. 생각에 드는 비용을 작업의 성격과 맞추지 않은 것입니다.

이 장은 모델이 “생각한다”는 것이 무엇이고 그 비용이 어디서 나오는지에서 시작합니다. 이어서 추론 모델과 일반 모델의 차이, 추론 강도라는 손잡이와 그것을 맞추는 절차, 출력 한도와 추론 토큰의 관계, 추론 모델에 맞는 프롬프트, 사고 과정을 출력에 쓰게 하면 안 되는 이유를 봅니다. 후반은 작업을 나누는 법입니다. 워크플로 패턴, 단계 사이의 입출력 계약, 자기 검토를 구체적인 검사로 만드는 법, 병렬과 순차와 하위 에이전트를 다루고, 깊이 읽기에서 지나친 분할의 비용과 여러 컨텍스트 창에 걸친 작업을 봅니다.

핵심 개념

추론은 연습장이다

수학 시험에서 연습장에 풀이를 적어 가며 푸는 학생은 암산하는 학생보다 어려운 문제에 강하지만 시간이 더 걸립니다. 추론 모델도 답하기 전에 연습장에 생각을 씁니다. Anthropic 문서는 사고가 켜져 있으면 모델이 문제를 다시 정리하고, 여러 접근을 시도하고, 중간 결과를 확인하고, 맞지 않는 길을 버린다고 설명합니다.

이 연습장은 공짜가 아닙니다. 두 회사의 문서 모두 같은 구조를 설명합니다.

그래서 추론은 언제 얼마나 쓸지를 정하는 것이 설계의 일부가 됩니다. 추론은 가진 정보로 더 깊이 생각할 뿐, 컨텍스트에 없는 새로운 사실을 만들지는 않는다는 점도 기억해야 합니다.

추론 모델과 일반 모델

OpenAI 가이드는 추론 모델을 “선임 동료”, 일반 GPT 모델을 “신입 동료”에 비유합니다. 선임은 높은 수준의 지침만으로도 일하지만 신입에게는 명확한 지시가 필요하다는 것입니다. 추론 모범 사례는 추론 모델을 복잡한 다단계 문제를 계획하는 “기획자”, GPT 모델을 잘 정의된 작업을 빠르고 싸게 처리하는 “일꾼”에 비유하고, 대부분의 업무 흐름은 둘을 함께 쓴다고 말합니다.

Anthropic은 최신 모델에서 적응형 사고(adaptive thinking)를 씁니다. 모델이 요청의 복잡도와 추론 강도 설정을 보고 생각할지, 얼마나 생각할지를 스스로 정하는 방식으로, 쉬운 질문에는 생각 없이 바로 답합니다. 일부 최신 모델에서는 사고가 항상 켜져 있고 끌 수 없습니다. 이전의 확장 사고(extended thinking)에서 쓰던 budget_tokens는 Claude Opus 4.6과 Sonnet 4.6에서 아직 동작하지만 지원 중단 예정이고, Claude 4.7 이후 모델에서는 400 오류를 냅니다. 이제는 추론 강도가 주된 조절 수단입니다.

추론 강도라는 손잡이

두 회사 모두 낮은 강도는 속도와 비용에, 높은 강도는 철저한 추론에 유리하다고 설명합니다. Anthropic 문서는 강도가 사고뿐 아니라 설명 텍스트와 도구 호출을 포함한 모든 토큰에 영향을 주어, 낮은 강도에서는 도구 호출이 줄고 짧아진다고 밝힙니다. “행동 신호”라는 말은, 낮은 강도에서도 충분히 어려운 문제라면 모델이 생각하지만 같은 문제를 높은 강도에서보다 덜 생각한다는 뜻입니다. 정확한 상한이 필요하면 강도가 아니라 max_tokens를 씁니다.

강도는 길이 조절 손잡이가 아니라는 점도 알아 둡니다. Anthropic 문서는 일부 모델에서 강도를 바꿔도 보이는 응답의 길이가 믿을 만하게 바뀌지 않으므로, 길이는 지시로 정하라고 안내합니다.

추론 강도를 비용·지연과 맞추는 절차

강도는 감으로 고르지 않고 측정으로 고릅니다. Anthropic 문서의 모범 사례는 강도를 명시적으로 설정하고, 단순하거나 속도가 중요한 작업에는 낮은 강도를 쓰고, 자기 작업으로 시험하고, 작업 복잡도에 따라 강도를 달리하라는 것입니다. 이를 절차로 옮기면 다음과 같습니다.

1. 작업을 유형별로 나눈다. 같은 기능 안에서도 단순 조회, 정형 추출, 다조건 판단은 다른 유형이다.
2. 유형마다 허용 지연과 품질 하한을 정한다. “2초 안에, 정답률 95% 이상”처럼 숫자로.
3. 강도를 바꿔 가며 같은 평가 세트를 돌린다(스윕). 강도별 정답률, 평균·최대 응답 시간, 출력 토큰을 기록한다.
4. 품질 하한을 넘는 가장 낮은 강도를 고른다. 그 강도가 지연 요구를 못 맞추면 모델이나 작업 구조를 다시 본다.
5. 낮은 강도에서 특정 유형만 얕아지면 표적 지시를 더한다. Anthropic 문서는 지연 때문에 강도를 낮게 유지해야 할 때 “이 작업은 여러 단계의 추론이 필요하니 응답 전에 신중히 생각하라” 같은 표적 지시를 예로 든다.
6. 모델을 바꾸면 스윕을 다시 한다. 같은 이름의 강도라도 모델마다 생각하는 양이 다르다.

출력 한도와 추론 토큰

출력 한도에는 추론 토큰도 포함됩니다. OpenAI의 max_output_tokens는 추론 토큰, 보이는 출력, 보이지 않는 형식 토큰까지 모델이 생성한 모든 토큰의 상한이라, 한도를 너무 낮게 잡으면 추론 도중에 끊겨 응답 상태가 incomplete가 되고 보이는 답이 없을 수도 있습니다. OpenAI는 추론 모델을 처음 시험할 때 추론과 출력을 합쳐 25,000토큰 이상을 잡아 두고, 사용량을 보며 조정하라고 권합니다. Anthropic도 max_tokens가 사고와 응답 텍스트를 합친 총 출력의 엄격한 상한이므로, 높은 강도에서는 넉넉하게 잡으라고 안내합니다.

예: 출력 한도를 4,000토큰으로 잡았는데 모델이 생각에 3,600토큰을 썼다.
→ 보이는 답에 남은 자리는 많아야 400토큰. 답이 중간에 끊기거나 아예 없다.
→ 비용은 쓴 토큰만큼 청구된다.

답의 길이는 한도가 아니라 지시문으로 조절합니다. 한도는 사고가 끝없이 길어지는 것을 막는 안전장치로 씁니다.

추론 모델용 프롬프트

추론 모델에는 절차보다 목표를 줍니다. OpenAI 문서는 분명한 목표, 강한 제약, 명시적인 출력 형식을 주되 모든 단계를 처방하지 말라고 권하고, 추론 모범 사례는 추론이 내부에서 일어나므로 “단계별로 생각하라” 같은 문구가 불필요하며 때로 성능을 떨어뜨릴 수 있다고 설명합니다. Anthropic 문서도 “충분히 생각하라” 같은 일반적인 지시가 사람이 손으로 쓴 단계별 계획보다 나은 추론을 낳는 경우가 많다고 말합니다.

OpenAI 문서는 에이전트나 조사 작업에서 “완료”가 무엇인지, 모델이 자기 결과를 어떻게 검증할지 정의하라고 강조합니다. Anthropic 문서도 조사 작업에 분명한 성공 기준을 주고 여러 출처로 정보를 확인하게 하라고 권합니다. 범위가 열린 작업일수록 끝나는 조건이 프롬프트에 있어야 합니다.

사고 과정을 출력에 쓰게 하지 않는다

사고 기능이 없던 시절에는 “먼저 생각을 적고 그다음 답하라”는 지시가 흔한 기법이었습니다. Anthropic 문서는 지금도 사고가 꺼진 상황에서는 이 방법을 대안으로 쓸 수 있다고 말하지만, 사고가 켜진 최신 모델에서는 사정이 다릅니다. 모델의 내부 추론을 응답 텍스트에 재현하라고 요구하면 stop_reason이 refusal이고 범주가 reasoning_extraction인 응답이 돌아올 수 있습니다. 공식 문서가 꼽는 흔한 원인은 다음과 같습니다.

• 답하기 전에 채우게 하는 <thinking>, <reasoning>, 메모장 구획
• JSON 출력이나 도구 입력의 reasoning, thinking, trace 필드
• 모델의 사적인 메모나 추론 기록을 계속 적게 하는 지시
• 추론을 그대로, 또는 전부 쓰라는 요구

이런 문구는 시스템 프롬프트뿐 아니라 도구 설명에도 숨어 있을 수 있습니다. 이 범주에는 권장되는 대체 모델이 없으므로 재시도보다 프롬프트를 고쳐야 합니다. 그래도 근거는 받을 수 있습니다. 짧은 설명, 결과를 뒷받침하는 증거, 수행한 작업의 요약을 요구하면 됩니다. 모델이 어떻게 추론했는지 보고 싶으면 display를 summarized로 설정해 사고 블록의 요약을 읽습니다. 검토자가 확인해야 하는 것은 사고의 흔적이 아니라 결론을 받치는 근거, 사용한 가정, 확인 가능한 계산입니다.

작업 분해와 워크플로 패턴

긴 작업을 한 번에 시키는 대신 여러 호출로 나누는 것을 프롬프트 체이닝이라고 합니다. Anthropic의 에이전트 설계 글은 가장 단순한 해법에서 시작해 필요할 때만 복잡도를 높이라고 권하고, 자주 쓰는 패턴을 다음처럼 정리합니다.

적응형 사고와 하위 에이전트 조율이 대부분의 다단계 추론을 모델 안에서 처리하게 되면서 체이닝이 늘 필요한 것은 아닙니다. Anthropic 문서는 명시적 체이닝이 여전히 유용한 경우로 중간 결과를 검사해야 할 때와 특정 파이프라인 구조를 강제해야 할 때를 듭니다. 단계를 별도 호출로 나누면 단계마다 기록하고 평가하고 분기할 수 있고, 사람의 승인 같은 관문을 끼워 넣을 수 있습니다.

단계별 입출력 계약

단계를 나눴다면 단계 사이에 무엇이 오가는지를 계약처럼 정합니다. 계약이 없으면 앞 단계가 형식을 조금만 바꿔도 다음 단계가 무너지고, 근거가 중간에 사라집니다.

원칙은 셋입니다. 첫째, 다음 단계에 필요한 것만 넘기되 근거의 위치(문서 번호, 문단 번호)는 끝까지 따라가게 합니다. 둘째, 관문은 가능하면 코드로 검사합니다. 셋째, 단계마다 1장의 작업 유형을 밝혀, 추출 단계에서 다듬기가 일어나지 않게 합니다. 계약이 특히 막아 주는 것은 오류 전파입니다. 추출 단계에서 숫자 하나를 잘못 읽으면 뒤 단계는 그 숫자 위에 매끄러운 논리를 쌓고, 최종 문서만 보는 검토자는 오류를 알아채기 어렵습니다. 단계마다 중간 산출물을 원문 위치와 함께 남겨 두면, 결과가 틀렸을 때 처음부터 다시 돌리지 않고 오류가 시작된 단계부터 다시 수행할 수 있습니다.

자기 검토를 구체적인 검사로

가장 흔한 체이닝 패턴은 자기 검토입니다. Anthropic 문서는 초안을 만들고, 기준에 비추어 검토하고, 검토에 따라 고치는 세 단계를 각각 별도 호출로 나누라고 설명합니다.

호출 1: 체크리스트를 담은 지시로 초안 생성
호출 2: 같은 체크리스트로 초안을 항목별 검토(통과/실패와 위치)
호출 3: 실패 항목만 고쳐 수정본 생성

“다시 확인해”라는 막연한 요청은 효과가 약합니다. 요구사항 누락, 원문과 수치의 일치, 예외 조건과 반례, 그리고 “고칠 필요가 없는 조건”까지 적어야 합니다. 마지막 항목이 없으면 검토 단계가 멀쩡한 부분까지 바꿉니다. 한 호출 안에서 끝내야 한다면 “끝내기 전에 [시험 기준]에 비추어 답을 확인하라”를 덧붙입니다. 다만 Anthropic 문서는 일부 모델이 지시 없이도 자기 작업을 잘 검증해, 이전 모델용 검증 지시가 과잉 검증을 부를 수 있다고 경고합니다. 수정 횟수 상한을 정하고, 상한에 닿으면 남은 문제를 표시해 사람에게 넘깁니다.

병렬과 순차, 그리고 하위 에이전트

서로 의존하지 않는 작업은 동시에, 앞 결과가 필요한 작업은 차례로 처리합니다. Anthropic 문서는 최신 모델이 독립적인 도구 호출을 병렬로 실행하며, 이 행동을 지시로 조정할 수 있다고 설명합니다. 예시 지시는 의존성이 없는 호출은 모두 동시에 하되, 앞 호출의 결과가 매개변수를 정하는 경우에는 차례로 하고, 빠진 매개변수를 짐작하거나 자리표시자로 채우지 말라고 말합니다. 병렬은 지연을 줄이고, 순차는 정확성을 지킵니다. 둘을 가르는 기준은 의존성입니다.

하위 에이전트는 더 큰 단위의 병렬입니다. 깨끗한 컨텍스트에서 집중된 작업을 하고 요약만 돌려주므로 넓은 조사에 강하지만 비용이 큽니다. Anthropic의 멀티 에이전트 조사 시스템 글은 에이전트가 채팅보다 약 4배, 멀티 에이전트 시스템은 약 15배 많은 토큰을 쓴다고 보고하고, 단순한 사실 확인에는 에이전트 하나와 도구 호출 3~10번이면 충분하도록 규칙을 두었다고 설명합니다. Anthropic 문서도 일부 모델이 하위 에이전트를 지나치게 띄운다며, 병렬로 돌릴 수 있거나 컨텍스트를 분리해야 하는 독립 작업에만 쓰고 단순하거나 순차적인 작업은 직접 하라는 지시 예를 제공합니다.

깊이 읽기

지나치게 나눈 체인의 비용

나누면 좋아진다는 믿음은 위험합니다. 단계마다 왕복 지연이 생기고, 단계 사이에서 맥락이 잘리며, 관리할 프롬프트가 늘어납니다. OpenAI의 지연 최적화 가이드는 순차적인 단계를 하나의 프롬프트와 응답으로 합치면 왕복 지연이 사라진다고 설명하면서도, 작은 모델이 대부분의 일을 맡을 수 있다면 나누는 쪽이 이길 수도 있으니 실제 운영 예시로 둘 다 시험하라고 권합니다. 같은 가이드는 생성 토큰을 줄이는 것이 입력 토큰을 줄이는 것보다 지연에 훨씬 큰 영향을 준다고도 설명합니다.

나눌지 판단하는 질문은 다음과 같습니다.

여러 컨텍스트 창에 걸친 긴 작업

며칠에 걸친 작업은 하나의 컨텍스트 창에 담기지 않습니다. Anthropic 문서는 첫 창에서 틀(테스트, 준비 스크립트)을 세우고 이후 창에서 할 일 목록을 반복하라고 권합니다. 테스트 같은 구조화된 상태는 JSON 같은 정형 파일로, 진행 메모는 자유 텍스트로, 작업 이력은 git으로 남기고, 새 창은 이 기록들을 먼저 읽는 절차로 시작합니다. 압축 대신 새 창에서 파일로 상태를 되찾는 편이 나을 때도 있습니다. 또 테스트를 삭제하거나 손대서 통과를 만들어 내지 말라는 원칙을 처음부터 분명히 적으라고 권합니다.

실무 장면

단단금속: 견적 비교 보고서를 단계로 나누기

정밀 부품 제조사 ‘단단금속’ 구매팀은 원자재 공급사 견적서를 비교해 구매 품의서 초안을 만드는 기능을 쓰고 있다. 공급사마다 견적서 양식이 다르고, 한 건에 견적서가 네다섯 개씩 들어온다. 지금은 견적서를 모두 넣고 높은 강도로 “비교해서 품의서를 써라”를 한 번에 시킨다. 품의서 문장은 매끄럽지만 지난달 두 번, 단위가 kg인 견적과 톤인 견적을 같은 단위로 비교해 엉뚱한 공급사를 추천했다. 품의서만 본 팀장은 알아채지 못했다.

구매팀 정 대리는 작업을 세 단계로 나누고 입출력 계약을 썼다.

1. 추출(낮은 강도). 견적서마다 공급사, 품목, 단가, 단위, 납기, 유효 기간을 구조화 출력으로 뽑는다. 항목마다 견적서의 쪽 번호를 함께 남긴다. 단위는 원문 표기 그대로 둔다.
2. 관문(코드). 단위를 코드로 환산표에 맞춰 통일하고, 필수 항목이 빠진 견적서는 담당자에게 되돌린다. 환산표에 없는 단위가 나오면 멈춘다.
3. 비교와 작성(높은 강도). 통일된 표와 사내 구매 기준(가격, 납기, 거래 이력의 가중치)을 넣고, 공급사별 판정과 근거 쪽 번호를 받은 뒤 품의서 초안을 쓴다.

마지막으로 같은 체크리스트로 자기 검토 호출을 한 번 더 둔다. 체크리스트는 “추천 공급사의 단가가 표의 최저가인지, 아니라면 이유가 기준표에 있는지”, “모든 수치에 쪽 번호가 있는지”, “유효 기간이 지난 견적이 추천되지 않았는지”다. 고칠 필요가 없는 항목은 건드리지 말라고 적었다.

정 대리가 버린 선택지는 둘이다. 하나는 한 번에 처리하되 “단위에 주의하라”를 굵게 넣는 방법이다. 추출 오류가 최종 문장에 가려지는 구조는 그대로라서 받아들이지 않았다. 다른 하나는 다섯 단계로 더 잘게 나누는 안이었다. 중간 결과를 아무도 보지 않는 단계가 생기고 지연만 늘어 셋으로 멈췄다. 강도도 단계마다 다르게 정했다. 추출은 정형 작업이라 낮은 강도에서 평가 세트 정답률이 높은 강도와 같았고, 비교는 기준이 여럿 얽혀 높은 강도에서만 하한을 넘었다.

지난 석 달의 견적 묶음 40건으로 비교하자 단위 혼동은 관문에서 모두 걸렸고, 건당 처리 비용은 오히려 줄었다. 추출 단계가 싸졌기 때문이다. 품의서에 쪽 번호가 붙으면서 팀장의 검토 시간도 줄었다.

가람시 청년일자리센터: 질문마다 다른 생각의 양

‘가람시 청년일자리센터’는 청년 구직자의 질문에 답하는 상담 봇을 운영한다. 질문은 크게 셋이다. 운영 시간이나 위치 같은 단순 안내, 교육 프로그램 일정 조회, 그리고 지원금 자격 판단이다. 자격 판단은 나이, 거주 기간, 소득, 다른 지원금 중복 여부 같은 조건이 얽혀 있다. 처음에는 모든 질문을 가장 높은 강도로 처리했는데, 운영 시간을 묻는 질문에도 응답이 늦어 이용자가 창을 닫는 일이 많았다.

담당 주무관 하 주무관은 질문을 라우팅하기로 했다. 먼저 가벼운 분류 호출이 질문 유형을 정하고, 유형별 경로로 보낸다. 단순 안내는 미리 쓴 답변 목록에서 고르게 해서 모델 생성을 최소화했다. 일정 조회는 일정 도구를 부른 결과를 짧게 정리한다. 자격 판단은 자격 기준표와 이용자가 입력한 조건을 넣어 판정과 근거 조항, 부족한 정보 목록을 받는다.

강도는 스윕으로 정했다. 유형별 평가 질문 60개씩을 만들고, 지연 하한과 품질 하한을 먼저 적었다.

자격 판단에서 중간 강도로도 정답률 하한은 넘었지만, 조건이 넷 이상 얽힌 질문에서만 오답이 몰렸다. 하 주무관은 강도를 높이는 쪽을 택했다. 허용 지연이 넉넉했고, 틀린 자격 안내는 이용자가 지원 기회를 놓치는 결과로 이어지기 때문이다. 또 이전 프롬프트에 남아 있던 “생각 과정을 <생각> 태그에 모두 적어라”는 문장을 지우고, 대신 “판정의 근거가 된 기준표 조항 번호와 이용자 조건을 짧게 적어라”로 바꿨다. 상담원이 확인해야 하는 것은 근거였지 생각의 흔적이 아니었다.

검토 회의에서 “유형 분류가 틀리면 어떻게 하냐”는 질문이 나왔다. 하 주무관은 분류가 자신 없을 때 자격 판단 경로로 보내는 기본 규칙을 두었다. 느린 쪽으로 틀리는 편이 틀린 안내보다 낫기 때문이다. 도입 후 단순 안내의 응답은 체감할 만큼 빨라졌고, 자격 판단의 정확도는 유지됐다. 모델을 교체할 때마다 같은 평가 질문으로 스윕을 다시 하기로 운영 수칙에 적었다.

자주 틀리는 지점

• 최고 강도가 언제나 최선이다. 단순·대량 작업에서는 지연과 비용만 늘립니다. 작업별로 고르고 평가로 확인합니다.
• “단계별로 생각하라” 한 줄이면 된다. 추론 모델에는 불필요하거나 해로울 수 있고, 작업별 지연·정확도 요구를 맞추지도 못합니다.
• 사고 과정을 본문에 적게 하면 검증할 수 있다. 보이는 사고는 요약일 뿐이고, 사고 기능이 켜진 최신 모델에서는 추론 재현 요구가 거절될 수 있습니다. 근거, 가정, 계산을 요구합니다.
• 출력 한도를 낮추면 답이 짧아진다. 추론 모델에서는 추론 도중에 끊겨 빈 답이 나올 수 있습니다. 길이는 지시로 정합니다.
• 나눌수록 품질이 오른다. 아무도 보지 않는 중간 단계는 지연과 관리 비용만 늘립니다. 한 번에 처리한 버전과 비교합니다.
• 하위 에이전트를 쓰면 언제나 빨라진다. 토큰을 크게 더 쓰고, 단순 조회에는 오히려 느립니다.
• 의존하는 도구 호출도 병렬로 돌리면 빠르다. 앞 결과가 필요한 호출을 동시에 하면 모델이 값을 짐작하게 됩니다.

한눈에 정리

공식 문서로 확인하기

• OpenAI — Reasoning models: 추론 강도 값, 추론 토큰 과금, max_output_tokens와 25,000토큰 확보 권장을 읽는다.
• OpenAI — Reasoning best practices: 추론 모델과 GPT 모델의 역할 분담과 프롬프트 조언을 읽는다.
• Anthropic — Effort: 강도 수준별 설명, 도구 사용과의 관계, 모범 사례를 읽는다.
• Anthropic — Refusals and fallback: reasoning_extraction 거절의 원인과 대안을 읽는다.
• Anthropic — Prompting best practices: “Thinking and reasoning”, “Chain complex prompts”, “Subagent orchestration”, “Optimize parallel tool calling” 절을 읽는다.
• Anthropic — Building effective agents: 워크플로 패턴과 각각을 쓸 때를 읽는다.

셀프 체크

4-1. 추론 토큰이 비용과 컨텍스트에 미치는 영향을 두 가지 쓰고, 사고 블록에 보이는 텍스트가 원래의 사고 과정과 어떻게 다른지 설명하라.

4-2. Anthropic의 effort가 “엄격한 토큰 예산이 아니라 행동 신호”라는 말의 뜻을 설명하고, 정확한 출력 상한이 필요할 때는 무엇을 써야 하는지 답하라.

4-3. 사내 문서 검색 도우미의 질문을 단순 조회와 비교 분석 두 유형으로 나눠 추론 강도를 정하려 한다. 강도를 고르는 절차를 순서대로 쓰라.

4-4. 출력 한도를 작게 잡은 추론 모델 요청에서 보이는 답이 비어 돌아왔다. 원인을 설명하고 두 가지 대응을 쓰라.

4-5. 일반 모델용으로 쓴 프롬프트에 “1단계 문제를 읽는다 … 7단계 답을 쓴다”는 절차와 “단계별로 생각하라”가 들어 있다. 추론 모델로 옮길 때 무엇을 남기고 무엇을 바꿀지 쓰라.

4-6. 평가 결과 JSON에 thinking 필드를 두어 판정 이유를 길게 받자는 설계안이 올라왔다. 사고 기능이 켜진 최신 모델에서 생길 수 있는 문제를 설명하고, 목적을 살리는 다른 필드 설계를 제안하라.

4-7. 신제품 출시 보도자료를 (가) 제품 사양서에서 사실 추출, (나) 경쟁 제품과 비교, (다) 보도자료 작성의 세 단계로 만든다. 단계별 입출력 계약 표를 쓰고, 단계 사이에 둘 관문 하나를 제안하라.

실습 과제