많은 LLM은 코드를 작성하기 전에 명시적인 추론 과정(reasoning trace)을 출력하지만, 코드 생성 및 버그 수정에 대한 벤치마크 결과는 일반적으로 정확도만을 보고합니다. 따라서 추가적인 추론이 소비하는 토큰 대비 얼마나 기여하는지 불분명합니다. 우리는 HumanEval Pro, MBPP Pro, BugsInPy에서 가져온 866개의 Python 태스크를 다섯 가지 모델 설정 하에 이 질문을 검토했습니다. 우리는 추론의 정확도 향상과 토큰 오버헤드(token overhead), 추론 과정 내부에 나타나는 행동들, 그리고 추론 과정을 단축해도 여전히 올바른 해결책으로 이어지는지 등을 살펴보았습니다.
Qwen3-32B 모델에서 다섯 번의 실행 동안 추론 기능을 켜자 HumanEval Pro에서의 평균 pass@1이 71.1%에서 76.5%로 향상되었고, BugsInPy에서의 평균 테스트 통과율(mean tests pass)은 3.5%에서 7.9%로 향상되었습니다. MBPP Pro의 경우, 모델이 태스크당 중앙값 2,000개가 넘는 사고 토큰을 사용했음에도 불구하고 68.1%에서 69.5%로의 개선은 통계적으로 유의미하지 않았습니다. 전반적인 모델들을 통해 볼 때, 더 긴 중앙값 추론 과정이 반드시 높은 정확도를 의미하는 것은 아닙니다.
정성적 분석에 따르면, 추론 과정은 주로 코드 생성 시 구현을 선택하고 확인하는 데 사용되며, 버그 수정 시에는 주로 결함을 찾아내고 수리 계획을 세우는 데 사용되었습니다. 이후 우리는 저장된 추론 과정을 오프라인에서 잘라내어, 추론 기능을 끈 Qwen3-32B에게 남아있는 내용만으로 해결책을 생성하도록 요청했습니다. 추론 과정의 앞 절반을 유지하는 것은 정확도에 통계적으로 유의미한 하락을 가져오지 않았습니다. 추론 과정이 반복적이 될 때 중단하는 경우는 거의 발생하지 않았으며, 솔루션 코드가 처음 나타날 때 중단하는 것은 일부 모델에는 이점을 주지만 다른 모델에는 해를 끼쳤습니다. 어느 규칙도 단순 고정 길이 자르기(plain fixed truncation)보다 우수하지 않았습니다.
이러한 결과들은 더 많은 추론이 항상 더 좋지는 않으며, 연구에서는 정확도와 함께 추론 비용을 보고해야 함을 시사합니다.