Claude Extended Thinking, 언제 켜야 손해가 아닌가 — 작업 유형별 판단 기준

지난달 저는 사내 문서 검색 에이전트를 만들다가 이상한 걸 발견했어요. Claude Extended Thinking을 켜놓았더니 단순한 질문에도 응답 시간이 세 배 가까이 늘어난 거예요. 사고 예산을 8000토큰으로 걸었던 요청에서 평균 4.2초였던 응답이 11초 넘게 걸렸습니다. 반면 복잡한 계약서 조항 충돌을 찾는 작업에서는 같은 설정이 오히려 정답률을 눈에 띄게 끌어올렸어요. 저는 확장 사고가 만능 스위치가 아니라 작업 유형에 따라 켜고 끄는 도구라고 생각해요. 사고 과정도 결국 청구되는 출력 토큰이기 때문이에요.

확장 사고를 켜면 정확히 뭐가 늘어나나

문서를 보면 사고 토큰 예산은 최소 1024토큰부터 시작하고, 이보다 작은 값을 넣으면 요청이 거부됩니다. 이 값은 그 턴의 최대 토큰 한도보다 작아야 하는데, 사고에 쓴 토큰도 같은 한도 안에 들어가기 때문이에요. 저는 이 제약을 몰라서 한도를 낮게 잡은 채 사고 예산을 4000으로 걸었다가 답변이 중간에 잘리는 걸 겪었습니다. 실측해보니 응답 필드에 실제 사고 토큰 수가 찍히는데, 이게 그대로 청구되더라고요. 제 로그를 열어보니 예산을 16000으로 걸었던 요청 20건 중 실제로 다 쓴 건 세 건뿐이었고 나머지는 평균 6200토큰 선에서 스스로 멈췄습니다. 이건 예산이 다 채워야 하는 값이 아니라 하나의 목표치라는 뜻이고, 출력을 실제로 막는 하드 상한은 최대 토큰 한도 쪽이에요.

어떤 작업에서 확장 사고가 본전을 뽑나요?

제가 세 달간 운영한 파이프라인에서 확장 사고가 확실히 이득이었던 작업은 세 가지였어요. 첫째는 다단계 논리 검증입니다. 여러 조건이 충돌하는지 찾는 작업인데, 사고 예산 16000 이상을 걸었을 때 오답률이 22퍼센트에서 6퍼센트로 줄었습니다. 둘째는 코드 리팩터링 계획 수립이에요. 300줄짜리 모듈을 쪼개는 작업에서 확장 사고 없이는 순환 의존성을 자주 놓쳤는데, 켜니 그런 실수가 거의 사라졌어요. 셋째는 도구 호출 사이 판단이 필요한 에이전트 작업입니다. 이건 사고 예산이 최대 토큰 한도를 넘어설 수 있는 유일한 예외라서 긴 추론 체인에도 안전하게 걸 수 있어요. 반면 단순 요약이나 분류 작업에서는 정답률 차이가 거의 없었습니다. 500건 표본으로 A/B를 돌려봤을 때 정확도 차이는 1퍼센트포인트 안쪽이었고 지연시간만 늘었어요.

반대로 손해였던 순간들

가장 뼈아팠던 경험은 실시간 챗봇에 사고 예산 32000을 걸었던 일이에요. 문서에는 3만2천 토큰 이상 사고를 시킬 때는 배치 처리를 쓰라는 권고가 있는데, 이를 무시하고 동기 요청으로 밀어붙였다가 타임아웃이 연쇄로 터졌습니다. 대기시간이 40초를 넘어가자 이탈률이 눈에 보이게 올라갔어요. 또 놓치기 쉬운 비용은 캐시예요. 사고 예산 값을 요청마다 바꾸면 프롬프트 캐시 지점이 매번 무효화됩니다. 예산을 유동적으로 조정하다가 캐시 적중률이 70퍼센트에서 12퍼센트로 떨어진 걸 뒤늦게 알아챘어요. 확장 사고 자체의 비용보다 이 캐시 무효화가 실제로는 더 큰 손실이었던 경우도 있었습니다.

확장 사고를 켜지 말아야 한다는 반론, 정말 맞을까요?

비용 관점에서 반대하는 사람들은 사고 토큰도 결국 청구되는 출력이니 무조건 아끼는 게 낫다고 말해요. 일리 있는 지적이지만, 이 주장은 오답으로 인한 재작업 비용을 빼놓고 계산한 경우가 많더라고요. 계약 검토 작업에서는 확장 사고 없이 놓친 조항 하나를 사람이 다시 찾는 시간이 API 비용 절감분보다 훨씬 컸습니다. 실무자 반론은 레이턴시 예측이 안 되면 서비스 응답 시간 약속을 못 지킨다는 거예요. 이건 전제를 다시 세워야 하는 지적이라고 봐요. 사고 예산은 앞서 봤듯 목표치일 뿐이라서, 짧게 끝나는 요청과 길게 끝나는 요청의 편차가 크다면 그 작업 자체가 확장 사고에 안 맞는다는 신호로 읽는 편이 맞습니다.

그래서 나는 이렇게 기준을 세웠다

제가 지금 쓰는 규칙은 단순해요. 결과가 틀렸을 때 사람이 다시 검토하는 비용이 API 토큰 비용보다 크면 켜고, 아니면 끕니다. 다단계 추론이나 도구 호출 판단처럼 실수가 연쇄로 번지는 작업엔 16000 이상으로 시작해서 점점 낮춰보고, 요약이나 분류처럼 되돌리기 쉬운 작업엔 최소값 근처만 씁니다. 3만2천을 넘길 일이 있다면 배치로 돌리고, 예산 값은 캐시가 깨지지 않도록 작업 유형별로 고정해둡니다. 팀 단위로 운영한다면 이번 주 로그부터 열어 실제 소비량과 설정값 사이 간극을 재보시길 권해요.

자주 묻는 질문

Q. 사고 예산은 어느 값부터 시작해야 하나요? A. 단순 작업은 최솟값 1024 근처에서 시작하고, 다단계 추론처럼 실수가 비싼 작업은 16000부터 잡아 지연시간과 품질의 균형점을 찾는 편이 안전합니다.

Q. 3만2천 토큰을 넘기면 무조건 배치로 돌려야 하나요? A. 동기 요청으로도 되긴 하지만 네트워크 타임아웃 위험이 급격히 커지므로, 이 구간부터는 배치 처리 전환을 권장합니다.

Q. 캐시 적중률이 떨어지는 걸 막을 방법이 있나요? A. 캐시 지점은 예산 값이 바뀔 때마다 무효화되므로, 이 값을 작업별로 못박아두면 손실을 크게 줄일 수 있습니다.

Q. 도구를 여러 번 호출하는 에이전트에서도 안전한가요? A. 네, 도구 결과를 받고 다음 행동을 정하기 전 단계에서는 예산이 원래 한도 밖으로 나갈 수 있게 예외 처리가 돼 있어서 긴 체인에서도 끊김 없이 쓸 수 있습니다.