제가 꽤 영리하게 코드를 짰다고 생각했습니다. AI 파이프라인을 위해 컨텍스트 윈도우의 정확히 30%를 사고 예산(thinking budget)으로 예약하는 헬퍼 함수를 작성했거든요. 코드는 깔끔하고 예측 가능했으며, Opus 4.5에서는 아주 완벽하게 작동했습니다. 하지만 Opus 4.8로 전환하자마자 모든 요청이 400 에러와 함께 죽어버렸습니다. 제가 정성껏 만든 토큰 계산 방식이 하룻밤 사이에 쓰레기가 되어버린 것입니다.
기존 패턴은 간단했습니다. budget_tokens 값을 설정하면 모델이 그 한도 내에 맞게 사고량을 조절했습니다. 만약 128K 컨텍스트를 넘겨주면, 제 코드는 추론을 위해 약 38,000개의 토큰을 할당하고 나머지를 답변용으로 남겨두었습니다. 마치 자동차를 제한 속도 내에서 운행하는 것처럼 책임감 있는 방식이라고 느꼈습니다.
하지만 그 모델은 이제 사라졌습니다. Opus 4.7이나 4.8 같은 최신 릴리스는 적응형 사고(adaptive thinking)를 사용합니다. 더 이상 숫자를 직접 선택하지 않습니다. 대신 effort knob을 전달합니다. 이름만 바뀐 것처럼 들릴 수도 있지만, 이 두 제어 방식은 완전히 다릅니다. budget_tokens가 모델이 사고할 수 있는 양에 엄격한 천장을 설정했다면, effort는 모델이 사고하고 행동하는 방식 자체를 제어합니다. 하나가 주유기 미터기라면, 다른 하나는 엔진 맵입니다.
Effort를 실제 작업에 매핑하기
제어 방식이 바뀌자 기존의 직관이 더 이상 통하지 않았습니다. 각 설정이 실제로 무엇을 가져다주는지 다시 배워야 했습니다. 저는 내부 트래픽을 대상으로 테스트를 수행하여 각 effort 레벨이 실제 환경에서 어떻게 작동하는지 찾아냈습니다.
분류 및 라우팅(Classification and routing) 작업에는 거의 항상 low effort를 사용해야 합니다. 이러한 작업은 빠른 결정이 필요합니다. 이것이 환불 요청인가요, 아니면 판매 관련 질문인가요? 이 로그 항목을 에스컬레이션해야 하나요? 긴 독백은 필요 없습니다. low effort는 지연 시간을 낮게 유지하고 비용을 거의 제로에 가깝게 만듭니다.
대부분의 앱 트래픽(Most app traffic), 즉 요약, 재작성, 고객 지원 답변, 콘텐츠 추출과 같은 일상적인 작업은 medium에서 high effort가 적합합니다. 이것이 균형점입니다. 모델이 긴 사고 체인(chain of thought)이 필요 없는 작업에 토큰을 낭비하지 않으면서도, 실제 모호성을 해결할 수 있는 충분한 여유를 갖게 됩니다.
**코딩 및 에이전트 루프(Coding and agentic loops)**에는 xhigh effort가 필요합니다. 이곳은 실수가 눈덩이처럼 불어나는 곳입니다. 만약 모델이 툴 호출(tool-calling) 루프의 첫 번째 단계에서 잘못된 계획을 세우면, 다음 세 단계는 그 피해를 복구하는 데 소비될 것입니다. 더 나쁜 경우, 잘못된 툴을 호출하거나 파라미터를 환각(hallucinate)하여 사용자가 망가진 워크플로우를 멍하니 바라보게 만들 수도 있습니다. 초기에 더 나은 추론을 수행하는 것이 이러한 악순환을 방지합니다.
**중요 작업(Critical tasks)**에는 max effort를 할당해야 합니다. 모든 것에 이 설정을 사용하지는 마십시오. 잘못된 답변의 비용이 그 어떤 토큰 비용보다 큰 순간을 위해 아껴두어야 합니다. 재무 정산, 안전 점검, 아키텍처 결정, 의료 트리아지(medical triage) 등이 적합한 사례입니다. 오류가 발생했을 때 사람이 몇 시간 동안 문제를 해결해야 한다면, 추가적인 사고 비용을 지불하십시오.
비용의 반전
제 사고 모델을 깨뜨린 부분은 바로 이것입니다. 저는 max effort를 사용하면 항상 비용이 폭등할 것이라고 가정했습니다. 단일 턴(turn)에서는 그렇습니다. 추론 과정(reasoning trace)이 더 길어지니까요. 하지만 다단계 에이전트 작업(multi-step agentic tasks)에서는 오히려 전체 비용이 줄어드는 경우가 많았습니다.
모델이 첫 시도에 더 나은 계획을 세웁니다. 툴 호출 횟수가 줄어듭니다. 막다른 길로 빠지는 것을 스스로 방지합니다. 저는 평소에 다섯 번의 주고받는 과정이 필요했던 데이터 추출 에이전트가 단 두 번 만에 작업을 끝내는 것을 목격했습니다. 모델이 시작 단계에서 스키마를 정확하게 파싱할 수 있을 만큼 충분한 추론 공간을 가졌기 때문입니다. 비용을 측정할 때는 요청(request) 단위가 아니라 작업 완료(job completion) 단위를 기준으로 보십시오. 단계당 더 큰 사고 예산을 사용하는 것이 전체 단계 수를 줄이는 결과를 가져올 수 있습니다.
다른 기능을 망가뜨리지 않고 마이그레이션하는 방법
코드베이스에 여전히 budget_tokens가 남아 있다면, 다음과 같은 정확한 탈출 경로를 따르십시오. 3단계와 5단계를 건너뛰지 마십시오. 저도 건너뛰었다가 오후 내내 디버깅을 해야 했습니다.
코드에서 budget_tokens를 검색하십시오. 모든 인스턴스를 제거해야 합니다. 이 파라미터는 최신 모델에서 더 이상 지원되지 않으며 400 에러를 유발합니다.
budget 객체를 adaptive thinking 블록으로 교체하십시오. thinking: { type: "adaptive" }를 사용하십시오.
각 호출에 명시적인 effort 레벨을 포함한 output_config를 추가하십시오. 트래픽이 혼합되어 있다면 이를 전역 기본값에 맡기지 마십시오. 가벼운 분류 엔드포인트가 코딩 에이전트와 동일한 effort 설정을 실수로 상속받아서는 안 됩니다. 호출 지점에서 명시적으로 지정하십시오.
기존의 budget 계산 헬퍼 함수를 삭제하십시오. 알고 있습니다. 아마 유닛 테스트도 있을 것입니다. 제 것도 그랬습니다. 하지만 이제는 불필요한 짐일 뿐입니다. 플랫폼은 여러분의 토큰 계산 방식을 원하지 않습니다. 모델이 스스로의 속도를 조절합니다.
temperature, top_p, top_k를 제거하세요. Opus 4.7 및 4.8에서는 이러한 샘플링 파라미터가 400 에러를 발생시킵니다. 플랫폼에서 이번 세대부터 이 파라미터들을 삭제했습니다. 기존의 temperature 튜닝 방식은 여기에서 적용되지 않으며, 이를 그대로 두면 마이그레이션 과정에서 조용히 오류가 발생할 수 있습니다.
각 모델을 개별적으로 테스트하세요. Opus 4.5와 4.8은 완전히 다른 모델입니다. 한 모델에서 작동하는 설정이 다른 모델에서도 반드시 작동하는 것은 아닙니다. 여러 버전을 지원해야 한다면, 로직을 분기하거나 각각 별도의 백엔드로 취급하세요.
UI 프리징 현상 해결하기
적절히 처리하지 않으면 사용자를 혼란스럽게 만들 수 있는 스트리밍 동작이 하나 있습니다. 새로운 모델에서는 thinking block이 스트리밍되지만, 기본적으로 텍스트는 비어 있습니다. 인터페이스상에서는 가시적인 진행 상황 없이 길고 어색한 일시 정지 상태처럼 보일 것입니다. 사용자는 앱이 멈췄다고 생각할 것입니다.
이를 해결하려면 thinking: { type: "adaptive", display: "summarized" }를 전달하세요. 이렇게 하면 가공되지 않은 사고 과정(thought stream)을 채팅창에 그대로 쏟아내지 않으면서도 가시적인 진행 표시기를 보여줄 수 있습니다. 프론트엔드는 응답성을 유지하고, 사용자는 내부적으로 무언가 진행되고 있음을 알 수 있습니다.
진짜 교훈
저는 벤더가 영구적으로 유지할 의도가 없었던 파라미터를 기반으로 전체 추상화 계층을 구축했습니다. 제가 플랫폼보다 트레이드오프를 더 잘 이해하고 있다고 생각했기에, 그들의 설정을 저만의 로직으로 감싸버렸습니다. 하지만 제 착각이었습니다. Adaptive thinking이 더 나은 선택인 이유는 모델이 스스로 언제 깊이 추론해야 하고 언제 가볍게 처리해도 되는지를 결정하기 때문입니다. 이제 제 코드베이스는 더 간결해졌고, 결과는 더 날카로워졌습니다. 때로는 영리한 코드를 삭제하고 플랫폼이 제 역할을 하도록 내버려 두는 것이 올바른 엔지니어링 결정일 수 있습니다.
원본 마이그레이션 노트를 읽고 싶다면 여기에서 확인할 수 있습니다. 이와 같은 실무적인 논의를 더 원하신다면, Telegram의 GyaanSetu AI 커뮤니티에 참여하세요.