Skip to content
Published on

더 생각한다고 더 맞는 것은 아니다: 테스트타임 컴퓨트와 과잉사고

공유하기
Authors

들어가며 — "일단 추론 토큰을 더 태워라"라는 기본값

지난 한두 해 동안 추론 모델의 성능을 끌어올리는 가장 손쉬운 레버는 "더 오래 생각하게 하는 것"이었습니다. 긴 사고 사슬(chain of thought), 더 큰 추론 토큰 예산, 여러 번 다시 생각하기. 벤치마크 점수는 올랐고, "테스트타임 컴퓨트를 스케일링하라"는 말은 어느새 반박하기 어려운 기본값이 되었습니다.

2026년 4월, Shu Zhou, Rui Ling, Junan Chen, Xin Wang, Tao Fan, Hao Wang은 "When More Thinking Hurts: Overthinking in LLM Test-Time Compute Scaling"에서 바로 그 기본값을 겨냥합니다. 저자들의 지적은 단순하지만 뼈아픕니다. 기존 연구는 "더 길게 생각하면 항상 더 낫다"를 은연중에 전제해 왔고, 그 전제는 사실상 제대로 검증된 적이 없다는 것입니다.

이 글은 그 논문의 초록을 근거로, "더 태우면 더 맞는다"는 반사적 믿음이 어디서 무너지는지, 그리고 실무에서 무엇을 바꿔야 하는지를 정리합니다. 초록만으로 확인할 수 있는 범위는 좁으니, 저는 저자들이 보고한 방향만 옮기고 나머지는 열어 두겠습니다.

논문이 실제로 보고하는 것

저자들은 컴퓨트 예산이 커질 때 "추가 추론 토큰의 한계 효용"이 어떻게 변하는지를 체계적으로 조사했다고 밝힙니다. 초록이 내놓는 결론은 크게 세 가지입니다.

첫째, 한계 수익은 예산이 높아질수록 크게 줄어듭니다. 흔히 말하는 수확 체감이지만, 저자들은 이를 "상당히(substantially)" 줄어든다고 표현합니다. 토큰을 두 배로 늘려도 정확도는 두 배는커녕 미미하게만 돌아온다는 이야기입니다.

둘째, 그리고 이 논문의 핵심입니다. 모델은 "과잉사고(overthinking)"를 보입니다. 저자들의 표현으로는, 추론을 늘리는 것이 "이전에 맞혔던 답을 버리는 것과 연관"됩니다. 즉 수익이 0으로 수렴하는 데 그치지 않고 어떤 구간에서는 음수가 됩니다. 더 생각했더니 오히려 틀린 답으로 갈아탄다는 뜻입니다.

셋째, 최적 사고 길이는 문제 난이도에 따라 달라집니다. 따라서 모든 문제에 같은 컴퓨트를 균일하게 배분하는 방식은 최적이 아니라고 저자들은 말합니다. 덧붙여, 이들의 "비용 인식 평가 프레임워크"는 적당한 예산에서 멈추면 정확도를 거의 유지하면서 계산량을 크게 줄일 수 있음을 보여 준다고 합니다.

여기서 진짜 새로운 부분을 구분해 둘 필요가 있습니다. 수확 체감 자체는 스케일링 법칙이 이미 오래 말해 온 이야기입니다. 이 논문이 불편하게 만드는 지점은 곡선이 평평해지는 데 그치지 않고, 어떤 구간에서 아래로 꺾인다는 더 강한 주장입니다. 성능이 단조적으로 좋아진다는 암묵적 가정이 깨지는 것이야말로 초록에서 가장 눈여겨볼 대목입니다.

정직하게 덧붙이자면, 초록은 어떤 모델을 썼는지, 벤치마크가 무엇인지, 효과의 크기가 정확히 얼마인지는 밝히지 않습니다. 그러니 위 문장들은 저자들이 보고한 방향으로 읽어야 하고, 구체적인 수치는 본문을 직접 확인해야 합니다.

왜 더 생각하면 맞은 답을 버리는가

초록은 현상을 보고할 뿐 메커니즘을 단정하지 않습니다. 여기서부터는 제 해석이니 그렇게 읽어 주세요.

가장 그럴듯한 그림은 이렇습니다. 추론 사슬이 길어질수록 모델은 자기 자신의 중간 결과를 더 오래, 더 많이 다시 검토합니다. 이 자기 수정 능력은 어려운 문제에서는 이득입니다. 그러나 이미 정답에 도달한 쉬운 문제에서는, 계속 "정말 맞나?"를 되묻는 과정이 멀쩡한 답에 의심을 주입하는 꼴이 됩니다. 근거가 약한 재고가 근거가 강한 첫 판단을 밀어내는 것입니다.

이것이 "과잉사고"라는 이름이 잘 붙은 이유입니다. 사람에게도 익숙한 실패 양상이니까요. 시험에서 처음 고른 답이 맞았는데, 시간이 남아 자꾸 들여다보다 결국 틀린 답으로 고쳐 쓰는 경험 말입니다. 저자들이 보고한 "맞은 답을 버림"은 이 인간적 실수의 기계 버전처럼 보입니다.

한 가지는 분명히 해 두겠습니다. 초록의 표현은 "연관된다(associated with)"이지 "유발한다"가 아닙니다. 저자들이 보고한 것은 상관이며, 인과의 메커니즘을 증명했다고 읽어서는 안 됩니다. 제가 위에서 그린 그림도 어디까지나 그 상관을 설명하려는 하나의 가설일 뿐입니다.

중요한 함의가 하나 있습니다. 만약 손해가 단순한 수확 체감뿐이라면, 최악의 경우라도 "돈을 더 쓰고 본전"입니다. 그러나 과잉사고가 실재한다면, 더 많은 컴퓨트는 낭비를 넘어 능동적으로 해로울 수 있습니다. "일단 예산을 넉넉히 잡아 두면 나쁠 것 없다"는 안전해 보이는 기본값이, 실제로는 안전하지 않다는 뜻입니다.

그래서 무엇을 바꿔야 하나 — 난이도 인식 예산

논문에서 곧장 따라 나오는 실무 지침은 "더 많이"가 아니라 "적절히, 그리고 멈출 때를 알기"입니다.

  • 균일 예산을 버리기: 모든 요청에 같은 토큰 상한을 주는 설정은, 저자들의 관찰대로라면 쉬운 문제에는 과하고 어려운 문제에는 모자랍니다. 예산은 문제에 붙어야지 파이프라인에 붙으면 안 됩니다.
  • 난이도를 먼저 추정하기: 짧은 사전 판단으로 문제의 난이도를 가늠하고, 그에 맞춰 사고 예산을 배분하는 적응형 추론이 자연스러운 다음 수순입니다. 최근의 "적응형 추론 강도(adaptive reasoning effort)" 흐름과 정확히 맞닿습니다.
  • 멈추는 기준을 설계하기: 초록이 말하는 "적당한 예산에서 멈추기"를 실제 정지 규칙으로 옮겨야 합니다. 답이 일찍 수렴하면 더 태우지 않는 조기 종료, 반복 사이의 답이 요동치기 시작하면 개입하는 감시 장치 같은 것들입니다.
  • 정확도만이 아니라 비용까지 함께 보기: 저자들의 평가가 "비용 인식(cost-aware)"이라는 점이 핵심입니다. 정확도 곡선만 보면 더 태우는 편이 늘 이겨 보이지만, 비용을 같은 축에 올리는 순간 최적점은 훨씬 왼쪽으로 옮겨 갑니다.

이 지침들이 매력적인 이유는 서로 강화하기 때문입니다. 난이도를 추정할 수 있으면 예산을 나눌 수 있고, 예산을 나눌 수 있으면 멈출 곳을 정할 수 있으며, 그 모든 것이 비용 축 위에서 정당화됩니다.

다만 솔직한 어려움이 남습니다. 이 처방들은 모두 "문제가 얼마나 어려운지"를 미리 알 수 있다고 전제합니다. 그런데 추론에 들어가기 전에 난이도를 정확히 추정하는 일 자체가 아직 풀리지 않은 문제입니다. 논문은 방향을 가리키지만, 그 방향으로 가는 데 필요한 난이도 신호는 공짜로 주어지지 않습니다.

마치며

"테스트타임 컴퓨트를 스케일링하라"는 여전히 강력한 레버입니다. 이 논문은 그 레버를 부정하지 않습니다. 다만 레버에 끝이 있고, 어떤 구간에서는 당기는 방향이 뒤집힌다는 것을 저자들의 관찰로 보여 줍니다.

제가 이 결과에서 배우는 교훈은 소박합니다. "더 생각하기"는 공짜도 아니고 언제나 옳지도 않으며, 그 자체로 하나의 하이퍼파라미터라는 것입니다. 튜닝해야 할 대상이지, 무한정 올려야 할 값이 아닙니다.

물론 초록만으로는 이 현상이 얼마나 넓게, 어떤 모델과 과제에서 나타나는지 알 수 없습니다. 그 부분은 열어 두겠습니다. 그러나 "일단 더 태워라"를 반사적으로 기본값 삼는 습관에 대해서는, 이 논문이 건강한 제동을 겁니다. 언제 멈출지를 아는 것이, 얼마나 더 갈지를 아는 것만큼 중요해졌습니다.

참고 자료