프롬프트 마지막에 이렇게 적고 계시지 않나요?

마지막으로, 단계별로 생각해주세요.
Let's think step by step.

솔직히 말하면, 얼마 전까지만 해도 이것이 「정답」이었습니다. AI에게 생각하는 절차를 밟게 하면 정답의 정밀도가 올라갑니다. 그래서 우리 모두는 주문처럼 이 문장을 덧붙여 왔습니다.

하지만 지금의 추론 모델 (Reasoning Models) 에 대해서는, 이 문장이 오히려 역효과를 낼 때가 있습니다. 그렇게 들으니 조금 놀랍지 않으신가요?

왜 그럴까요?

이유는 간단합니다. 추론 모델은 「답하기 전에, 머릿속에서 알아서 생각해 주기」 때문입니다. 생각하는 절차를 외부에서 지시하지 않아도, 내부에서 초안을 작성하고, 검토한 뒤에 답을 내놓습니다. 따라서 「단계별로 생각하라」고 말하는 것은, 이미 스스로 단계를 밟을 수 있는 동료에게 굳이 「먼저 손을 씻고, 그다음 재료를 썰고...」라고 귓가에 계속 속삭이는 것과 같습니다. 이른바 '가는 말이 고와야 오는 말이 곱다'는 식의 번거로운 참견인 셈입니다.

여기서 정말 중요해진 것은 프롬프트의 세세한 말투보다, 「어떤 AI에게, 어느 정도 생각하게 할 것인가」를 스스로 설계하는 것이라고 생각합니다. 빠르지만 얕은 모드가 있는가 하면, 느리지만 깊은 모드도 있습니다. 그 조절 다이얼을 태스크(Task)마다 돌리는 것입니다.

이 기사에서는,

「빠른 AI」와 「생각하는 AI」는 도대체 무엇이 다른가
「생각하는 시간」을 선택하는 다이얼 (reasoning effort / thinking budget)의 정체
추론 모델을 위해 프롬프트를 어떻게 다시 쓸 것인가
「너무 많이 생각해서」 오히려 틀리는, 최근 밝혀진 함정
태스크를 노력 수준(effort level)에 따라 분류하는, 바로 사용할 수 있는 라우팅 (Routing) 설계

를 AI 개발에 아직 익숙하지 않은 분들도 따라올 수 있도록, 용어를 하나씩 풀어서 써 내려가겠습니다. 코드 예시와 프롬프트 예시도 복사해서 바로 테스트할 수 있는 수준으로 준비해 두겠습니다.

⚠️ 이 기사의 API 파라미터 명칭이나 설정값은,

2026년 6월 시점의 각사 문서를 참조한 예시입니다. 모델의 버전이 올라가면 이름도 기본값도 변합니다. 구현 전에 반드시 각사의 공식 문서에서 최신 정보를 확인해 주세요. 「생각하는 방식의 틀」을 가져가신다면 오랫동안 사용하실 수 있을 것입니다.

먼저, 가장 기초적인 부분부터 시작하겠습니다.

AI 모델에는 대략 두 가지 타입이 있다고 생각하시면 됩니다.

하나는 즉답형. 질문을 받으면 거의 지체 없이 바로 답합니다. 채팅에서 척척 대화할 수 있는 것은 이 타입입니다.

다른 하나가 이번의 주인공인 숙고형 = 추론 모델 (Reasoning Models) 입니다. 이쪽은 답하기 전에 일단 **「머릿속에서 생각하는 시간」**을 갖습니다. 질문을 받고 바로 입을 여는 대신, 내부에서 「음, 우선 여기가 이렇고, 아니 잠깐, 이쪽의 가능성도 있겠는데」라며 초안을 작성하고 검토한 뒤에야 비로소 답을 돌려줍니다.

이 「머릿속의 초안」을 내부 사고 (thinking / reasoning) 라고 부릅니다. 그리고 답하기 전에 이 생각하는 시간을 듬뿍 사용하는 방식을 업계에서는 test-time compute (테스트 타임 컴퓨트) 라고 부르기도 합니다. 직역하면 「추론 시의 계산」입니다. 요컨대 **「답하는 순간에, 생각하기 위한 계산을 얼마나 추가할 것인가」**라는 이야기입니다. 어려워 보이는 이름이지만, 내용은 「즉시 답할 것인가, 아니면 잠시 고민한 뒤에 답할 것인가」 그뿐입니다.

친숙한 예로, 직장의 두 동료를 상상해 보세요.

즉답 씨: 「이거 어떻게 생각해?」라고 물으면 0.5초 만에 「아, 그건 A가 좋다고 생각합니다」라고 답합니다. 빠릅니다. 대화가 활기찹니다. 다만, 복잡한 문제라면 기세로 대답했다가 틀릴 때도 있습니다.
숙고 씨: 같은 질문에 「음... 잠시만 기다려 주세요」라며 팔짱을 끼고 침묵합니다. 30초 후에 「정리하자면, 논점은 3가지가 있고 결론은 B입니다. 이유는...」라고 답해옵니다. 느립니다. 하지만 어려운 문제일수록 믿음직스럽습니다.

누가 더 훌륭하다는 이야기가 아닙니다. 잡담에 숙고 씨를 부르면 대화가 진전되지 않고, 경영 판단을 즉답 씨에게만 맡기면 무섭습니다. 적재적소의 문제일 뿐입니다.

여기서 초보자들이 빠지기 쉬운 포인트를 하나 보충하겠습니다. 추론 모델이 보여주는 '생각한 흔적', 이른바 사고 트레이스 (thinking trace) 는 디버깅의 참고 자료는 될 수 있지만, 그대로 전적으로 믿어도 되는 감사 기록은 아닙니다. 요약되어 있거나 실제 내부 처리 과정과 완전히 일치하지 않는 경우도 있습니다. "음, 이렇게 생각했구나" 하고 바라보는 정도는 괜찮지만, "이 트레이스에 적혀 있으니 무조건 옳다"라고까지 생각하지 않는 것이 안전합니다. 이 부분은 후반부의 '함정' 섹션에서 다시 한번 다루겠습니다.

이 장의 요약: 추론 모델 = "답변하기 전에 머릿속으로 초안을 작성한 뒤 답변하는 AI". 빠른 즉답형과, 느리지만 깊은 숙고형. 어느 쪽을 호출할지가 첫 번째 갈림길입니다.

여기서부터가 흥미로운 지점입니다.

조금 전까지만 해도 "즉답형 모델"과 "추론 모델"은 별개의 제품으로서 선택하는 것이었습니다. 하지만 지금은 같은 모델 안에서 "얼마나 생각하게 할 것인가"를 우리가 직접 지정할 수 있는 시대가 되어가고 있습니다.

저는 이것을 "노력의 다이얼 (effort dial)" 이라고 부릅니다. 오디오의 볼륨 노브처럼 "생각의 깊이"를 저·중·고... 단계로 돌리는 이미지입니다. 낮추면 빠르고 저렴하며, 높이면 깊지만 느리고 비쌉니다.

각 회사마다 명칭은 다르지만 방식은 같습니다. 2026년 6월 시점의 예시를 나열해 보겠습니다.

여기서 가장 중요한 감각은, "노력은 공짜가 아니다" 라는 점입니다.

숙고 씨에게 30초 동안 생각하게 하면, 그 30초 분량의 "생각한 언어"가 백그라운드에서 생성됩니다. 이것이 사고 토큰 (thinking token) 이며, 보통 여러분의 API 이용료로 과금됩니다. 게다가 생각하는 만큼 답변도 늦어집니다. 즉, 높은 effort는 "품질을 높이는 대신, 돈과 시간을 지불하는" 트레이드오프 (trade-off) 관계입니다.

따라서 다이얼을 돌릴 때 던져야 할 질문은 언제나 다음과 같습니다.

이 태스크는,

추가로 돈과 시간을 지불해서라도 깊게 생각하게 할 가치가 있는가?

단순한 분류 태스크에 high를 적용하는 것은, 편의점에 도시락을 사러 가는데 택시를 타고 왕복하는 것과 같습니다. 도착은 하겠지만, 낭비입니다. 반대로, 실제 운영 DB 스키마 설계를 minimal로 즉답하게 하는 것은, 중요한 계약서를 1초 만에 쓰게 하는 것과 같아서 이 또한 위험합니다.

첫 번째 값의 결정 방법으로는 다음과 같은 순서를 추천합니다.

1. 우선 기본값(대부분 medium 또는 동적 설정)부터 시작한다.
2. 자신의 태스크에서 품질을 측정해 본다.
3. 품질이 부족할 때만 effort를 높인다 / 속도나 비용이 신경 쓰일 때는 낮춘다.

처음부터 전력(최대 effort)을 다하지 마세요. 이것만으로도 불필요한 지출과 짜증 나는 대기 시간을 상당히 줄일 수 있습니다.

이 장의 요약: "생각의 깊이"는 우리가 선택할 수 있는 다이얼이다. 하지만 깊게 생각하게 할수록 토큰 비용과 대기 시간을 지불해야 한다. 기본값부터 시작해서 필요할 때만 돌려라.

자, 그럼 서두에서 언급한 think step by step 이야기로 돌아가 보겠습니다.

즉답형 모델의 시대에 우리는 프롬프트에 「생각하는 절차」를 추가함으로써 정밀도를 높여왔습니다. "단계별로(step-by-step)", "먼저 근거를 제시한 뒤 결론을 내줘", "일단 심호흡하고"... 이른바 Chain-of-Thought (사고의 연쇄, 줄여서 CoT) 입니다. 절차를 입 밖으로 내뱉게 함으로써 모델이 논리에서 벗어나지 않도록 하는 기술이죠.

하지만 추론 모델은 그 「절차를 밟는」 과정을 내부에서 알아서 수행합니다. 따라서 외부에서 "생각해"라고 지시하면 다음과 같은 상황이 발생합니다.

• 이미 하고 있는 일을 이중으로 지시하게 되어冗長(중복)해짐
• 모델 본연의 사고 방식을 우리의 미숙한 절차로 구속함
• 결과적으로 오히려 정밀도가 떨어질 수 있음

OpenAI의 추론 모델용 권장 사항에서도 명확하게 **"CoT적인 지시("think step by step" 등)는 사용하지 말고, 프롬프트는 심플하고 직접적으로 작성하라"**고 명시되어 있습니다 (2026년 시점).

즉, 추론 모델에 대한 프롬프트는 **「덧셈」이 아니라 「뺄셈」**입니다. 절차를 추가하는 것을 그만두고, **목표(Goal)·제약 사항(Constraints)·출력 형식(Output Format)**만을 명확하게 전달합니다. "어떻게 생각할 것인가"는 모델에 맡기고, **"무엇을 달성하고 싶은가", "지켜야 할 규칙", "어떤 형태로 내보내길 원하는가"**에 집중하는 것입니다.

구체적인 예로 살펴보겠습니다.

❌ Before (즉답형 시대의 습관이 남은 프롬프트)

당신은 우수한 엔지니어입니다. 다음 코드의 버그를 찾아주세요.
먼저, 코드를 한 줄씩 주의 깊게 읽어주세요.
그다음, 가능한 원인을 단계별(step-by-step)로 나열해 주세요.
...

✅ After (추론 모델에 맞춰 뺄셈을 적용한 프롬프트)

<task>
다음 코드에는 특정 입력에서 크래시가 발생하는 버그가 하나 있다.
원인과 수정안을 제시한다.
...

차이가 느껴지시나요? After는 「어떻게 생각하라」는 말을 일절 하지 않았습니다. 대신 <task>, <constraints>, <code>와 같은 **구분 태그(Delimiter Tags)**를 사용하여 「지시」와 「재료」를 깔끔하게 나누었습니다. 이러한 구분(Markdown 헤더든 XML 스타일의 태그든 상관없음)은 모델에게 "여기서부터는 명령이고, 여기서부터는 대상 데이터이다"라는 표식이 되어 오독을 줄여줍니다.

다만, 여기서 성급하게 판단하지 않으셨으면 합니다. 걱정이 많은 제가 한마디 주의를 드릴게요.

이것은 「추론 모델에 대해서는」 그렇다는 이야기입니다. 세상의 모든 프롬프트에서 CoT를 없애라는 뜻이 아닙니다. 즉답형 모델을 사용하고 있거나, 「일부러 절차를 밟게 하여 그 과정을 보여주고 싶을 때」(교육 용도나 사람이 리뷰하는 것을 전제로 할 때)는 CoT가 여전히 매우 유효합니다. 사용하는 모델이 숙고형(Reasoning model)인지에 따라, 더할지 뺄지를 전환하면 됩니다. 그 부분만 틀리지 않으면 괜찮습니다.

이 장의 요약: 추론 모델에는 절차를 「더하지 않는다」. 목표·제약 사항·출력 형식을 구분자로 정리하여 전달한다. CoT를 없애는 것은 「추론 모델에 대해서는」이라는 한정된 규칙이다.

여기까지 읽으면, "그럼 어려운 태스크는 전부 high로 설정하면 되겠네"라고 생각하실지도 모릅니다. 저도 처음에는 그렇게 생각했습니다.

하지만 여기에 최근 밝혀진, 꽤 중요한 함정이 있습니다.

생각하게 하면 할수록 정밀도가 올라가는 것은 아니다. 오히려 생각하는 시간을 늘리면 반대로 성적이 떨어지는 태스크가 있다는 사실이 연구를 통해 밝혀졌습니다.

이름을 조금 언급하자면, Anthropic 팀이 주도한 논문 「Inverse Scaling in Test-Time Compute」(arXiv:2507.14417, 2025년)에서는 추론을 길게 할수록 정밀도가 낮아지는 태스크를 실제로 만들어 보여주었습니다. 「inverse scaling (역 스케일링)」이란, 보통은 늘리면 좋아져야 하는 것(생각하는 시간)을 늘렸음에도 불구하고 오히려 나빠지는 것을 의미합니다.

어떤 일이 벌어지느냐 하면,

• 옳았던 첫 직관을 너무 많이 생각한 나머지 스스로 의심하기 시작함 (사람도 그렇듯, 너무 깊이 고민하다 답을 바꿔서 틀리는 경우)
• 무관한 정보나 함정에 집착하여, 심층 분석하는 방향을 잘못 잡음
• 길게 생각할수록 중간의 작은 실수가 연쇄적으로 작용하여 크게 어긋남

또한 「Evaluating Over and Underthinking in LLMs」(arXiv:2508.13141, 2025년)라는 연구에서는, 단순한 질문에 대해 700토큰 이상을 「생각」하고도 정작 정확도는 올라가지 않는 (오히려 떨어지는) 케이스가 보고되었습니다. 간단한 질문에는 즉답형(instant response) 모델이 훨씬 효율적이었다는 것입니다.

이 점은 매우 시사하는 바가 크다고 생각합니다. 「전력을 다해 생각하는 것」이 항상 정의는 아닙니다. 간단한 태스크에 높은 노력(high effort)을 쏟는 것은, 비용과 시간을 지불하면서 오히려 정확도를 떨어뜨리러 가는 행위일 가능성조차 있습니다.

그렇기 때문에 각 사의 모델은 「적응적 사고 (adaptive thinking)」 ——간단한 질문에는 알아서 적게 생각하고, 어려운 질문에는 많이 생각하는—— 방향으로 진화하고 있습니다. 그리고 사용하는 우리들이 해야 할 일은 그 적응을 더욱 도와주는 것입니다. 즉, 태스크의 난이도에 맞춰 노력을 배분하는 설계입니다.

이 장의 요약: 높은 노력(high effort) = 항상 높은 정확도는 아니다. 간단한 태스크에 너무 많이 생각하게 하면 오히려 틀린다 (inverse scaling). 따라서 「노력을 태스크에 맞춰 배분하는」 설계가 필요하다.

여기가 이 기사의 가장 핵심적인 실무 파트입니다.

「생각의 깊이」를 태스크마다 다르게 하는 것, 그 분류 작업을 **라우팅 (routing)**이라고 부릅니다. 짐을 분류하는 이미지와 같습니다. 들어온 태스크를 보고, "이것은 즉답형으로 충분하다", "이것은 높은 노력의 숙고형으로 보낸다"라고 분류하는 것입니다.

먼저, 분류의 판단 기준을 가지고 있으면 헤매지 않습니다. 제가 사용하는 기준은 다음 5가지입니다.

이 기준을 바탕으로 대략 살펴보면, 태스크는 자연스럽게 다음과 같이 나열됩니다.

포인트는, 「헤매겠다면 medium부터 시작해서, 부족할 때만 높인다」 입니다. 처음부터 high로 고정하지 마세요. 이전 장에서 보았듯이, 간단한 태스크에 대한 과도한 노력은 역효과를 낼 수 있기 때문입니다.

그리고 또 하나, 잊어서는 안 될 선긋기가 있습니다. 「어떤 다이얼을 어떻게 돌릴지」를 결정하는 것은 인간의 일입니다. AI에게 "너는 얼마나 생각했으면 좋겠어?"라고 묻는 것은 본질적으로 이상한 일이죠. 노력의 배분은 설계 판단의 영역이며, 이 부분은 인간이 쥐고 있어야 합니다. AI는 그 다이얼 안에서 실제로 손을 움직여 생각하는 담당입니다. 이 역할 분담이 아마 가장 중요한 부분일 것입니다.

이 장의 요약: 5가지 기준(다단계성 · 모호성 · 실패 비용 · 레이턴시 · 검증 가능성)으로 태스크를 노력 수준으로 분류한다. 기본값에서 시작하여 필요할 때만 높인다. 다이얼을 결정하는 것은 인간이다.

생각하는 법을 이해했다면, 다음은 구현입니다. 어렵지 않습니다. 「태스크의 종류를 보고, effort를 선택해서, 호출한다」뿐입니다.

거듭 말씀드리지만, 아래 코드의 파라미터 이름과 값은 2026년 6월 시점의 예시입니다. 최신 정보는 각 사의 공식 문서를 확인해 주세요. 분위기와 구조를 파악하는 것만으로도 충분합니다. 코드 내의 user_id 등은 모두 더미 데이터입니다.

먼저, 노력 수준을 전환하며 모델을 호출하는 이미지(OpenAI 계열의 Responses API 스타일 · Python)입니다.

from openai import OpenAI
client = OpenAI()
def ask(task_prompt: str, effort: str = "medium") -> str:
...

다음으로, Anthropic (Claude)의 확장 사고 (Extended Thinking)에서 "생각할 상한 토큰 (thinking budget tokens)"을 전달하는 이미지입니다.

import anthropic
client = anthropic.Anthropic()
def ask_claude(task_prompt: str, thinking_budget: int = 4000) -> str:
...

그리고 핵심인 라우터 함수 (Router Function) 입니다. 태스크의 종류를 받아 노력 수준 (effort level)을 결정하고, 각각을 구분하여 호출합니다. 판정 로직은 "우선 단순하게" 시작해도 충분합니다. 점차 키워나가면 됩니다.

from dataclasses import dataclass
@dataclass
class Task:
...

이 라우터의 장점은 "어떤 태스크에 얼마나 생각하게 할 것인가"에 대한 판단이 코드 한 곳에 모인다는 점입니다. 여기저기 프롬프트에 effort="high"가 흩어져 있으면, 나중에 "왜 여기가 높게 설정되어 있었지?"라는 질문에 아무도 답할 수 없게 됩니다. 다이얼의 설계도를 한 장으로 모아두는 발상입니다.

마지막으로, 사소하지만 가장 효과적인 한 마디를 덧붙입니다. effort를 변경했다면, 반드시 "품질(Quality) · 비용(Cost) · 레이턴시(Latency)" 세 가지를 측정하세요. "왠지 high가 더 똑똑할 것 같아서"라는 막연한 느낌으로 결정하지 마세요. 간단한 평가라도 좋으니,

# 의사 코드: 동일한 태스크를 effort 차이를 두어 실행하고 비교
for effort in ["minimal", "medium", "high"]:
    result = ask(task_prompt, effort=effort)
...

이렇게 "품질이 정체되기 직전의 effort"를 찾아내면, 과도한 비용 지불이나 너무 적게 생각하게 만드는 실수를 피할 수 있습니다. 이는 이전에 작성했던 평가 주도 (Eval-Driven) 방식의 사고방식과도 맥을 같이 합니다.

이 장의 요약: effort 전환은 "종류를 보고 골라서 호출"하는 것뿐입니다. 판단은 라우터 한 곳으로 집약합니다. 변경 시에는 품질 · 비용 · 레이턴시를 반드시 측정하세요.

이 부분은 바로 가져다 쓰실 수 있도록 준비했습니다. 복사해서 붙여넣은 뒤, [ ] 부분만 채워서 사용하세요. 모두 최종 판단은 인간이 한다는 전제하에 작성되었습니다.

당신은 AI 시스템의 설계 리뷰어입니다.
다음 태스크에 대해 추론 노력 (reasoning effort)의 권장 수준을 판정하십시오.
# 판정 축 (각 항목을 low/mid/high로 평가)
...

다음 프롬프트는 단계를 세세하게 지시하는 "덧셈형"입니다.
추론 모델을 위해, 내부 사고에 맡기는 "뺄셈형"으로 다시 작성하십시오.
# 규칙
...

당신은 비용 의식이 높은 SRE입니다.
다음 "태스크 유형 → effort 설정" 목록을 리뷰하십시오.
# 관점
...

저나 주변 사람들이 빠졌던(혹은 빠질 뻔했던) 사례들을 대책과 함께 정리해 두었습니다.

• 일단 전부 max effort로 설정 $\rightarrow$ 비용과 레이턴시가 조용히 불어납니다. 게다가 간단한 태스크에서는 오히려 정확도가 떨어지기도 합니다. 대책: 기본값 (medium / 동적 설정)에서 시작하여, 품질이 부족할 때만 높입니다.
• 간단한 태스크에 고(high) effort 할당 $\rightarrow$ 역스케일링 (inverse scaling) 현상으로 오히려 성능이 저하됩니다. 대책: 분류 · 정제 · 추출은 minimal/low로 고정합니다.
• 추론 모델에 CoT (Chain of Thought)를 과하게 적용 $\rightarrow$ "단계별로 생각하라"를 추가하여 내용이 장황해지고 정확도가 떨어집니다. 대책: 추론 모델에서는 단계 지시를 뺍니다 (뺄셈형). CoT는 즉답형 모델이나 "과정을 보여주고 싶을 때"로 한정합니다.
• 사고 토큰의 과금과 레이턴시를 고려하지 않음 $\rightarrow$ 월말에 청구서를 보고 경악하게 됩니다. 대책: effort별로 토큰 수와 응답 시간을 로그에 남기고 정기적으로 모니터링합니다 (이는 가관측성 (Observability)의 문제와도 연결됩니다).
• 사고 트레이스 (Thinking Trace)를 맹신함 $\rightarrow$ "이렇게 생각한다고 적혀 있으니 맞겠지"라고 오해합니다. 트레이스는 요약된 설명일 뿐, 완전한 감사 추적 (Audit Trail)이 아닙니다. 대책: 트레이스는 참고용으로만 활용하고, 최종적인 정확성은 출력 결과 그 자체와 별도의 검증 (테스트 · 인간 리뷰)을 통해 확인합니다.
• effort 설정이 코드 곳곳에 흩어져 있음 $\rightarrow$ 어디가 왜 높은지 아무도 추적할 수 없습니다. 대책: 라우터 함수나 설정 파일 한 곳으로 집약하고, "왜 이 effort인가"를 주석으로 남깁니다.

그리고, 철수 라인(여기까지 오면 일단 멈춘다는 선)도 정해두면 안심할 수 있습니다.

• effort를 높여도 품질이 개선되지 않는다면(한계에 도달했다면), 그 이상 높이는 것을 중단합니다. 이는 문제의 원인이 모델의 노력량이 아니라, 프롬프트(Prompt)나 컨텍스트(Context) 설계에 있다는 신호입니다.
• 비용이나 레이턴시(Latency)가 허용 범위를 초과한다면, 해당 태스크를 저(low) effort + 인간 리뷰(Human Review)의 조합으로 전환합니다.
• 실패가 불가역적인(운영 DB, 결제, 공개, 삭제 등) 태스크는 effort가 얼마이든 관계없이 반드시 인간의 승인 게이트(Approval Gate)를 통과해야 합니다. 이는 생각의 깊이 문제가 아니라, 중단할 수 있느냐의 문제이기 때문입니다.

마지막으로, 이 기사 전체를 한 장으로 요약하면 역할 분담은 다음과 같습니다.

보시는 바와 같이, "무엇을·왜(What/Why)"는 인간이, "어떻게(How)"는 AI라는 선으로 깔끔하게 나뉩니다. 노력의 다이얼을 설계하는 것은 바로 "무엇을·왜"의 영역입니다. 이 부분을 놓치지 않는 것이 AI에 휘둘리지 않고 AI를 활용하는 비결이라고 생각합니다.

여기까지 긴 글을 읽어주셔서 감사합니다.

마지막으로, 조금 더 추상적인 이야기를 해보고 싶습니다.

"어떤 AI에게 얼마나 생각하게 할 것인가"를 설계한다는 오늘의 주제. 이것을 파고들면 결국 **"생각한다는 자원을 어디에 배분할 것인가"**의 문제입니다. 생각하는 힘에도, 돈에도, 시간에도 한계가 있습니다. 그러니 모든 곳에 전력을 다하는 것이 아니라, 정말로 깊게 생각할 가치가 있는 곳에 제대로 노력을 집중하는 것. 그 외의 것들은 가볍고 빠르게 처리하는 것입니다.

이는 AI 설정에 관한 이야기일 뿐만 아니라, 우리의 일하는 방식 그 자체에도 적용되는 사고방식이라고 생각합니다. 간단한 업무에 필요 이상으로 고민하며 시간을 허비하기보다, 결정적인 순간에 머리를 쓰는 것. AI에게 "생각하게 하지 않을 용기"를 가진 사람은 아마 자신의 시간도 잘 사용하는 사람일 것입니다.

그리고 이렇게 "태스크별 노력 수준"을 라우터 하나에 적어두는 것은 미래의 자신과 팀에게 남기는 메시지가 됩니다. 반년 뒤의 내가 "왜 여기가 high였지?"라며 고민하지 않게 해줍니다. 새로 합류한 사람이 설계도를 보고 판단 기준을 이어받을 수 있습니다. 이것은 일종의 배려라고 생각합니다. 내일의 내가 오늘의 나에게 "고마워"라고 말할 수 있도록 말이죠. 그런 작은 축적이 길게 효과를 발휘합니다.

만드는 비용이 점점 낮아지는 시대이기에, 차이를 만드는 것은 "어떻게 만드는가"보다 "무엇을·어디까지·왜 하는가"를 설계하는 능력일 것입니다. 노력의 다이얼을 설계하는 것은 그 능력을 기르기 위한 매우 구체적인 연습 도구라고 생각합니다.

마지막으로, 오늘부터 실천할 수 있는 4가지 단계입니다.

• 지금 사용 중인 프롬프트에서 (추론 모델을 사용 중이라면) think step by step 계열의 문구를 하나 지워보기
• 자신의 태스크를 하나 골라, effort를 minimal / medium / high로 돌려보며 품질·비용·속도를 비교하기
• "태스크 유형 → effort"의 대응 관계를 메모 형식으로라도 한 장에 적어두기
• 불가역적인 작업에는 effort와 상관없이 인간의 승인 게이트를 두기

작게 시도해 보며 자신의 태스크에서 측정해 보세요. 다이얼의 최적점은 사람마다, 태스크마다 다르기 때문입니다.

그럼, 다음 기사에서 뵙겠습니다. 읽어주셔서 감사합니다.

이 기사가 참고한 1차 정보 및 연구 (2026년 6월 기준):

• OpenAI / Anthropic / Google 각사의 reasoning, extended thinking, thinking 관련 문서
• 「Inverse Scaling in Test-Time Compute」(arXiv:2507.14417)
• 「Evaluating Over and Underthinking in LLMs」(arXiv:2508.13141)
• 「Stop Overthinking: A Survey on Efficient Reasoning for LLMs」
  ※ API 사양은 업데이트가 매우 빠른 영역입니다. 구현 전에 반드시 최신 공식 문서를 확인하시기 바랍니다.