Reasoning effort는 왜 품질 슬라이더가 아니라 예산 계약일까

• 카테고리: ai_dev
• 예상 읽기 시간: 10분
• 오늘의 질문: reasoning/thinking 옵션을 올리면 LLM 품질은 항상 좋아질까, 아니면 태스크별 예산과 평가 기준을 먼저 정해야 할까?
• 핵심 출처:
  • Reasoning models - OpenAI API - 게시일 미표기, 2026-06-19 확인
  • Building with extended thinking - Claude API Docs - 게시일 미표기, 2026-06-19 확인
  • Gemini thinking - generateContent API - 게시일 미표기, 2026-06-19 확인
  • Azure OpenAI reasoning models - 게시일 미표기, 2026-06-19 확인

1. 왜 지금 봐야 하나

요즘 LLM API를 보면 단순히 “모델을 고른다”에서 끝나지 않는다. OpenAI는 reasoning model에서 reasoning.effort를 제공하고, Anthropic Claude는 extended/adaptive thinking과 effort를 문서화하고, Gemini는 thinking level 또는 thinking budget을 제공한다. 이름은 다르지만 공통 메시지는 비슷하다. 모델이 최종 답을 내기 전에 더 많은 내부 계산을 쓰게 할 수 있고, 그만큼 지연·비용·품질의 균형이 달라진다.

문제는 이 옵션이 제품 코드에 들어오는 순간 “품질 슬라이더”처럼 오해되기 쉽다는 점이다. 답이 틀리면 effort를 high로 올리고, 비용이 비싸면 low로 내리는 식이다. 하지만 reasoning 옵션은 그렇게 단순하지 않다. 같은 high라도 쉬운 분류 작업에서는 낭비일 수 있고, 복잡한 코드 리뷰나 장기 에이전트 작업에서는 필요한 안전마진일 수 있다. 반대로 low를 쓰면 빠르지만, 도구 호출 순서·모호한 요구사항 해석·검증 루프가 약해질 수 있다.

개발자 관점에서 reasoning effort는 “더 똑똑하게 해줘” 버튼이 아니라 태스크에 허용할 사고 예산 계약이다. 어떤 요청에 내부 reasoning token을 얼마나 허용할지, 그 추가 비용이 어떤 실패를 줄여야 정당화되는지, 실패하면 어떤 단계로 escalation할지를 설계해야 한다.

2. 핵심 개념

Reasoning/thinking 옵션을 이해하려면 세 가지를 분리해서 봐야 한다.

첫째, 최종 출력 토큰과 reasoning token은 다르다. 사용자는 최종 답만 보지만, reasoning model은 답을 만들기 전에 내부 토큰을 사용할 수 있다. Google Gemini 문서는 thinking이 켜지면 가격이 output token과 thinking token의 합으로 계산되고, thoughtsTokenCount 같은 필드로 생성된 thinking token 수를 확인할 수 있다고 설명한다. Azure OpenAI 문서도 reasoning tokens가 응답 본문으로 반환되지는 않지만 completion token detail에 포함되는 숨은 토큰이라고 설명한다.

둘째, 예산은 보장값이 아니라 상한 또는 유도값에 가깝다. OpenAI 문서는 effort 값이 모델이 얼마나 생각할지 안내하며, 모델이 단순한 태스크에서는 적게 쓰고 복잡한 태스크에서는 더 쓸 수 있다고 설명한다. Gemini 2.5의 thinkingBudget도 모델별 범위가 있고, -1은 dynamic thinking을 의미한다. Claude의 budget_tokens도 최대 내부 reasoning token 수를 정하지만, 특히 큰 예산에서는 전체 예산을 다 쓰지 않을 수 있다고 문서화되어 있다.

셋째, thinking을 더 많이 한다고 항상 더 좋은 제품 경험이 되지는 않는다. 더 깊은 reasoning은 복잡한 계획·디버깅·수학·코드 리뷰에서 도움이 될 수 있다. 하지만 고객지원 라우팅, 짧은 요약, 단순 정보 추출, UI 자동완성처럼 지연이 중요한 작업에서는 과한 reasoning이 오히려 비용과 응답 시간을 늘린다. reasoning은 품질을 살 수도 있지만, 사용자의 대기 시간을 팔아서 사는 품질이다.

그래서 기본 구조는 이렇게 잡는 편이 안전하다.

태스크 난이도 분류
→ 기본 effort 선택
→ 실패 가능성이 큰 조건 감지
→ 필요할 때만 더 높은 effort로 재시도 또는 비동기 처리
→ eval과 비용 로그로 정책 조정

3. 최신 이슈와 연결

공급자별 API는 서로 다르지만 방향은 수렴하고 있다.

OpenAI reasoning guide는 none, minimal, low, medium, high, xhigh처럼 모델별 effort 값을 설명한다. 낮은 effort는 지연과 토큰 사용량을 줄이고, 높은 effort는 더 완전한 reasoning과 품질을 노리지만 비용과 지연이 커진다. 특히 xhigh는 eval이 명확한 이득을 보일 때만 쓰라고 안내한다는 점이 중요하다. 즉 “가장 높은 값이 기본값”이 아니라 “평가로 정당화되는 경우의 선택지”다.

Anthropic Claude 문서는 manual extended thinking의 budget_tokens와 newer model의 adaptive thinking을 구분한다. Claude Opus 4.7/4.8 계열처럼 manual budget을 더 이상 받지 않고 adaptive thinking과 effort를 쓰도록 하는 모델도 있다. 또한 budget_tokens는 max_tokens보다 작아야 하는 등 출력 예산과도 얽힌다. 개발자가 배워야 할 점은 “벤더마다 파라미터 이름이 다르다”가 아니라, reasoning 예산이 모델 버전·출력 제한·tool use 방식과 함께 변한다는 점이다.

Gemini thinking 문서는 Gemini 3 계열은 thinking level, Gemini 2.5 계열은 thinking budget을 사용한다고 설명한다. Gemini 2.5 Flash는 thinkingBudget=0으로 thinking을 끌 수 있지만, 2.5 Pro는 thinking을 끌 수 없다는 식으로 모델별 제약도 다르다. 또한 thinking summary는 raw thought 자체가 아니라 요약이며, budget은 summary가 아니라 raw thought에 적용된다.

이 흐름은 한 가지 운영 현실을 보여준다. reasoning은 프롬프트 문구 하나로만 제어되는 행동이 아니라, API 파라미터·모델 버전·요금·컨텍스트·도구 호출과 연결된 서빙 정책이 되고 있다.

4. 개발자 관점 해석

실무에서 가장 위험한 패턴은 모든 요청을 같은 effort로 보내는 것이다. “우리는 품질이 중요하니까 high” 또는 “비용이 중요하니까 low” 같은 전역 설정은 초반에는 편하지만, 곧 서로 다른 실패를 만든다.

예를 들어 고객 문의를 카테고리로 나누는 작업은 대개 짧고 반복적이다. 여기서 high reasoning을 기본값으로 두면 정확도가 조금 오르더라도 비용 대비 효과가 작을 수 있다. 반면 “환불 가능 여부를 정책 문서와 주문 이력, 예외 규칙, 고객 메시지를 보고 판단하라”는 작업은 단순 분류가 아니다. 검색, 정책 충돌 해석, 근거 제시, 안전한 거절 문구가 필요하다. 이런 작업은 low로 빠르게 처리하면 잘못된 자동 승인이나 근거 없는 답변으로 이어질 수 있다.

또 다른 실패 모드는 overthinking이다. 모델이 단순한 요청에도 긴 계획을 세우거나, 필요 없는 도구 호출을 하거나, 확실한 답을 지나치게 의심할 수 있다. Anthropic의 Opus 4.6 발표 자료에서도 harder problem에는 더 깊은 thinking이 도움되지만 simpler problem에서는 비용과 지연이 늘 수 있고, overthinking이면 effort를 낮추라고 안내한다. 제품에서는 이것이 UX 문제로 보인다. 사용자는 “이 버튼 이름을 추천해줘”라고 했는데 시스템이 몇 초 동안 고민하면 품질보다 답답함을 먼저 느낀다.

반대로 underthinking도 있다. agent가 파일을 수정하거나 결제 상태를 바꾸거나 운영 명령을 실행하는 경우, 낮은 effort는 빠른 첫 답을 줄 수 있지만 작업 분해와 검증이 약해질 수 있다. 특히 tool use가 들어가면 모델은 “무슨 도구를 어떤 순서로, 어떤 인자로, 언제 멈출지”를 판단해야 한다. reasoning 예산은 여기서 단순 답변 품질이 아니라 권한 있는 작업의 안전성과 연결된다.

따라서 reasoning effort 정책은 모델 선택표가 아니라 라우팅 규칙이어야 한다.

• 단순 추출·분류·짧은 변환: 낮은 effort 또는 thinking off 후보
• 검색 결과 요약·간단한 도구 호출: low/medium 후보
• 코드 변경·장애 분석·보안 리뷰·정책 판단: medium/high 후보
• 긴 research, 비동기 agent, 고가치 감사 작업: high 이상 후보, 단 eval 통과 시에만

5. 내 프로젝트에 적용할 체크포인트

1. 요청 타입을 먼저 나눴는가?
   모든 프롬프트를 하나의 “chat”으로 보지 말고 classification, extraction, rewrite, retrieval answer, tool planning, code review, long-running agent처럼 나눠라.

2. effort별 목표 지표가 있는가?
   high를 쓸 이유는 “더 좋아 보임”이 아니라 정확도, 근거 충실도, tool-call success rate, 재시도 감소, human review 감소 같은 지표로 보여야 한다.

3. 숨은 reasoning token을 로그로 보고 있는가?
   최종 출력 토큰만 보면 비용 원인을 놓친다. 가능하다면 reasoning token 또는 thought token count, 총 latency, TTFT, tool call 횟수를 함께 저장하라.

4. 간단한 요청이 과하게 생각하는지 샘플링하는가?
   low로 충분한 요청이 medium/high로 처리되고 있으면 비용 최적화 여지가 크다. 특히 짧은 UI 요청, 단순 JSON 변환, 정형 분류부터 보라.

5. 실패 시 escalation이 있는가?
   처음부터 모든 요청을 high로 보내지 말고, 낮은 effort 결과가 confidence·validator·eval rule을 통과하지 못할 때만 높은 effort로 재시도하는 구조를 고려하라.

6. 모델 버전 변경에 대비했는가?
   reasoning 옵션의 지원값과 기본값은 모델마다 다르다. “기본값이 medium일 것” 같은 가정을 코드에 숨기지 말고 설정 파일과 릴리스 체크리스트에 드러내라.

6. 오늘 10분 액션

오늘은 새 기능을 만들지 말고, 이미 쓰는 LLM 호출 하나를 골라 reasoning budget 표를 만들어보자.

요청 이름: 예) 고객 문의 자동 분류
현재 모델/옵션: 예) gpt-5.5, reasoning=medium
사용자 기대 지연: 예) 1초 이내
실패 비용: 예) 잘못된 카테고리 → 상담원 재분류
평가 샘플: 최근 문의 30개
비교할 설정: none/low/medium
기록할 값: 정확도, 평균 latency, reasoning tokens, 재시도율
결정 규칙: low가 medium 대비 정확도 -1%p 이내면 low로 변경

핵심은 한 번에 전사 정책을 정하는 것이 아니다. 작은 호출 하나에서 “effort를 올리면 무엇이 얼마나 좋아지는가?”를 숫자로 확인하는 감각을 만드는 것이다. 이 감각이 생기면 reasoning model을 도입할 때마다 감으로 파라미터를 고르지 않게 된다.

7. 더 볼 자료

• Reasoning models - OpenAI API: effort 단계와 reasoning model prompting 기준을 볼 수 있다.
• Building with extended thinking - Claude API Docs: Claude의 thinking mode, budget token, summary/display 제약을 확인할 수 있다.
• Gemini thinking - generateContent API: Gemini의 thinking level/budget, thought summary, thinking token 과금 기준을 볼 수 있다.
• Azure OpenAI reasoning models: reasoning token이 completion token detail에 어떻게 반영되는지와 모델별 지원 옵션을 확인할 수 있다.

중복 회피 메모

최근 ai_dev 글은 prompt/context caching, structured outputs, speculative decoding, LLM-as-judge, 도구 선택 파인튜닝, KV cache 양자화, Tool Search, RAG retrieval, prefill/decode 지연, 에이전트 권한과 장기 컨텍스트를 다뤘다. 이번 글은 캐시·출력 스키마·서빙 최적화 자체가 아니라 reasoning/thinking token을 태스크별 비용·지연·신뢰성 예산으로 운영하는 정책 설계에 집중한다.