LLM 추론 예산은 언제 늘려야 하나: 적응형 계산과 검증 설계

LLM이 어려운 문제를 만나면 더 오래 생각하게 해야 할까, 여러 답을 만든 뒤 골라야 할까? 추론 비용을 어디에 쓰고 검증 결과를 얼마나 믿을지가 핵심이다. 같은 모델로도 답을 개선할 수 있지만, 계산을 늘리는 방식에 따라 성과와 비용이 달라진다. (proceedings.iclr.cc)

답을 더 만들면 정답을 발견할 기회가 늘어난다

추론 시점 계산량을 늘리는 가장 단순한 방법은 한 문제에 답을 여러 번 생성하는 것이다. 재학습 없이 후보를 늘리고, 그중 답을 고르는 방식이다. 클코단 논의에서도 모델 크기뿐 아니라 문제에 맞춰 추론 자원을 배분해야 한다는 의견이 나왔다. (arxiv.org)

*Large Language Monkeys* 연구는 반복 생성으로 정답 후보를 발견하는 범위가 넓어진다고 보고했다. 코드와 형식 증명처럼 답을 자동으로 확인할 수 있는 영역에서는 그 이득을 활용하기 쉽다. 반대로 자동 검증이 어려운 영역에서는 다수결이나 보상 모델의 선택 성능이 정체됐다. 정답이 후보 목록에 들어오는 일과 그 답을 찾아내는 일은 별개다. (arxiv.org)

공개 노트 저장소 Self-Improving Agent Systems도 두 단계를 분리해 설명한다. 여기서 Best-of-N은 후보 N개를 생성하고 점수를 매겨 하나를 고르는 구조다. 저장소는 Stanford CS329A를 출발점으로 삼은 독립 연구 노트이며, 특정 방법의 성능을 입증한 제품 문서는 아니다. 사례의 가치는 후보 생성과 선택을 서로 다른 병목으로 표시한 데 있다. (github.com)

쉬운 문제까지 여러 번 풀 필요는 없다

후보 수를 고정하면 간단한 질문에도 어려운 문제와 같은 비용을 쓴다. ICLR 2025의 추론 계산 연구는 효과적인 전략이 문제 난도에 따라 달라진다고 분석했다. 수학 문제 실험에서는 문제별 계산 배분이 Best-of-N 기준선보다 계산 효율을 네 배 넘게 높였다. 모든 작업에서 같은 폭의 개선을 보장한다는 결과는 아니다. (proceedings.iclr.cc)

2026년 ICML에 발표된 연구는 배분 단위를 더 세밀하게 다뤘다. 에이전트가 계획과 추론 도구, 탐색 전략을 고르고 후보 경로를 생성한다. 과정 보상 모델인 PRM은 중간 단계의 점수를 이용해 경로를 줄이거나 확장한다. 연구진은 수학 벤치마크에서 고정 방식보다 나은 결과를 보고했다. (proceedings.mlr.press)

시간도 비용이다. 써본 사람들 사이에선 단순한 작업에 긴 추론이 붙으면 응답 지연이 부담스럽다는 반응도 있다. 그런 체감은 벤치마크 결과를 대신하지 않지만, 한 요청의 정답률만으로는 운영 품질을 판단하기 어렵다는 점을 드러낸다. 별도 연구는 일부 평가 과제에서 추론을 길게 할수록 정확도가 떨어지는 사례도 제시했다. (arxiv.org)

검증기가 승인해도 답이 맞는 것은 아니다

후보를 많이 생성할수록 검증기의 판단은 중요해진다. ICLR 2026의 검증기 연구는 문제 난도와 생성 모델의 능력에 따라 오류 탐지 효과가 달라진다고 밝혔다. 더 강한 검증기를 써도 검증 성과가 크게 개선되지 않는 경우가 있었다. 클코단에서 검증 결과 자체를 의심해야 한다는 의견은 바로 이 선택 단계에 관한 문제 제기다. (proceedings.iclr.cc)

검증 방법도 구별해야 한다. 정답과 비교할 수 있는 테스트는 실제 산출물을 검사한다. 최종 답에 점수만 주는 방식은 완성된 결과를 평가하고, PRM은 생성 과정의 단계에도 점수를 준다. OpenAI의 과정 감독 연구는 수학 문제에서 중간 단계의 오류를 살피는 접근을 조사했다. 어느 방식이든 점수와 실제 정답률을 같은 값으로 취급해서는 안 된다. (openai.com)

가령 코드 수정 에이전트라면 그럴듯한 설명보다 실행 결과가 중요하다. 모델이 제안한 패치를 격리된 환경에 적용하고, 기존 테스트와 해당 오류의 재현 테스트를 돌릴 수 있다. 테스트가 통과해도 확인 범위 밖의 문제는 남으므로, 통과율과 사람이 확인한 실패 사례를 함께 기록해야 한다. 추가 추론이 정답을 찾았는지, 검증기를 통과하는 답만 늘렸는지를 구분하기 위해서다. (arxiv.org)

하네스는 생성·검사·중단을 연결한다

모델 밖의 설계는 추론 호출을 업무 흐름으로 묶는다. Archon 연구는 반복 생성, 순위화, 비평, 검증, 단위 테스트 등을 조합할 수 있는 추론 구조를 제안했다. 어떤 조합이 좋은지는 대상 과제와 계산 예산에 맞춰 평가한다. 방에서 하네스 엔지니어링의 비중이 커졌다는 의견은 이런 설계 선택을 가리킨다. (arxiv.org)

작은 팀이 시험한다면 입력은 재현 가능한 작업 묶음이어야 한다. 예를 들어 실패하는 테스트가 포함된 코드 수정 과제를 준비하고, 같은 모델의 단일 응답을 기준선으로 남긴다. 다음에는 각 과제에서 패치를 여러 개 생성해 테스트를 실행하고, 통과한 후보만 검토한다. 산출물은 선택된 패치뿐 아니라 후보별 테스트 결과, 호출 횟수, 소요 시간 기록이다. (arxiv.org)

그 기록으로 어려운 작업에만 후보를 추가할지 판단할 수 있다. 첫 시도가 테스트를 통과하면 멈추고, 실패하면 정해 둔 예산 안에서 다시 생성하는 식이다. 이는 앞선 연구를 소규모 작업에 적용해 볼 수 있는 설계 예시이지, 검증된 최적 설정은 아니다. 반복 생성에 쓴 비용만큼 해결 과제가 늘었는지 확인해야 한다. (proceedings.iclr.cc)

추론 능력과 행동 권한은 따로 정해야 한다

Self-Improving Agent Systems는 계산량 확대와 에이전트의 행동 권한을 구분한다. 저장소의 설계 노트에서는 허용된 선택지 안에서 판단을 반복해도 새로운 권한이 생기지 않는다. 추론을 더 시키는 일은 답을 고르는 방법이고, 무엇을 실행해도 되는지는 별도의 경계다. 저장소 역시 이 연결을 구현 권고가 아닌 검토 대상으로 표시한다. (github.com)

클코단에서는 수학·기존 ML·강화학습의 개념을 추론 설계에 다시 쓸 수 있다는 의견도 나왔다. 검색, 보상, 중단 조건은 유용한 설계 언어다. 그러나 좋은 점수를 받은 답을 자동으로 실행해도 된다는 허가는 그 어디서도 나오지 않는다. 추론 예산을 늘릴 가치가 있는지는 검증된 해결률로, 실행 가능 여부는 권한 규칙으로 판단해야 한다. (arxiv.org)