테스트 타임 스케일링과 에이전트 검증: 마이크로소프트 리서치 세션이 짚은 추론 비용 문제

핵심 메시지

• 추론 시점에 계산을 더 쓰면 정확도가 오르지만, 어떤 과제에서는 출력 토큰이 52배까지 늘어나 지연과 에너지 비용으로 되돌아온다.
• 매 단계 검증(빔 서치)과 완성 후 검증(베스트 오브 N) 사이의 고정된 선택은 최적이 아니며, 문제 난이도에 따라 검증 주기를 바꾸면 계산량을 절반 이상 줄이면서 정확도를 높일 수 있었다.
• 검증기 자체가 시스템 병목이 된다. 매 단계 검증에 표본 수가 커지면 실행 시간에서 검증이 생성을 압도한다.
• 두 번째 발표는 정확성이 아니라 '규정 준수'를 겨냥한다. 정책 문서를 사전에 검증 코드로 바꿔두고, 실행 중에는 작은 모델이 인자만 뽑아 그 코드를 돌리는 구조다.
• 이 방식으로 에이전트 벤치마크 점수가 32%에서 87.7%로 올랐고, 비교로 제시된 상용 프런티어 모델의 기본 점수 47.4%를 크게 넘어섰다.

쉽게 이해하기

마이크로소프트 리서치 인도의 2026년 학술 서밋 추론 세션에는 서로 다른 각도에서 같은 문제를 겨냥한 두 발표가 올랐다. 하나는 '생각을 더 하게 만드는 비용을 어떻게 감당할 것인가'이고, 다른 하나는 '그렇게 나온 결과가 규칙을 지켰는지 어떻게 확인할 것인가'다. 첫 발표자인 임페리얼 칼리지 런던의 홍샹 판 교수는 알고리즘과 시스템, 칩 설계를 함께 보는 교차 계층 최적화를 기조로 삼는다며, 모델은 계속 커지는데 CPU 성능 향상은 둔화됐고 전력과 토큰 비용이라는 청구서가 남는 상황을 배경으로 제시했다. 그는 버트 모델을 처음부터 학습시킬 때의 탄소 배출이 자동차 다섯 대의 생애 배출량과 맞먹는다는 보고를 인용하며, 이제는 '모두가 AI 비용을 감당할 수 있는가'가 성능만큼 중요해졌다고 말한다.

테스트 타임 스케일링, 즉 추론 시점에 계산을 더 쓰는 기법은 작은 모델의 성능을 끌어올리는 데 특히 효과적이다. 하지만 대표적인 방식인 긴 사고 사슬, 베스트 오브 N, 빔 서치는 모두 검증 시점의 세분화 정도가 고정돼 있다. 연구팀은 정답을 알고 있다고 가정한 상한선 실험으로 이 고정값이 최적이 아님을 보였고, 난이도에 따라 검증 주기를 바꾸는 '가변 세분화 탐색'을 제안했다. 어려운 문제는 단계마다 검증하고 쉬운 문제는 완성 후 한 번만 확인하는 방식으로, 기존 기법 대비 정확도는 약 3% 올리면서 계산량은 52% 줄였다.

그는 이어 오픈소스 소형 모델을 노트북에서 돌리며 클라우드 모델의 정확도를 따라잡는 시나리오를 검토했다. 정확도는 근접시킬 수 있었지만 응답 지연이 문제였다. 원인을 프로파일링해 세 가지 비효율을 찾았고, 짧게 끝난 추론 경로가 다른 경로를 기다리지 않고 미리 진행하는 투기적 빔 서치, 캐시를 비울 때 실행 순서를 고려하는 접두어 인지 스케줄링, 생성기와 검증기 사이의 메모리 배분을 성능 모델로 정하는 기법을 제안했다.

두 번째 발표자인 마이크로소프트 리서치 인도의 나가라잔 나타라잔은 다른 질문을 던진다. 에이전트가 수십에서 수백 단계의 도구 호출을 거쳐 일을 끝낼 때, 해야 할 일을 했는지뿐 아니라 '하지 말아야 할 일을 하지 않았는지'를 어떻게 보장할 것인가다. 그는 환불은 원결제 수단으로만 처리한다는 고객 응대 규정이나, 특허 거절 대응서에서 모든 청구항을 빠짐없이 다뤄야 한다는 변리사의 암묵적 규칙을 예로 들었다.

그의 접근은 작업을 사전과 실행 시점으로 나누는 것이다. 사용자가 오기 전에 정책 문서를 개별 규칙으로 쪼개고, 각 규칙을 명세로 옮긴 뒤 이를 검사하는 코드로 만들어 두되, 결제 수단 값처럼 실행 시점에만 알 수 있는 부분은 '구멍'으로 남긴다. 실행 중에는 작은 언어 모델이 대화 기록에서 그 값을 뽑아 채워 넣고, 나머지는 CPU에서 도는 코드가 판정한다. 읽기 작업은 검증을 기다리지 않고 진행하다가 실패가 나면 그 지점부터 되돌리는 비동기 처리도 함께 쓴다.

주요 인사이트

• 검증은 공짜라는 암묵적 전제가 이 세션의 공통 표적이다. 상용화를 염두에 두면 검증 비용을 학습 단계에서부터 계산에 넣어야 한다는 것이 첫 발표의 결론이다.
• '무엇을 검증할까'만큼 '언제 검증할까'가 성능을 좌우한다. 검증 주기 하나만 난이도에 맞춰 조절해도 계산량이 절반으로 줄었다는 결과는, 아직 손대지 않은 최적화 여지가 많다는 신호다.
• 규정 준수 검증을 코드로 내리면 GPU가 아니라 CPU에서 돌릴 수 있다. 결정론적 실행이 보장되고 지연도 예측 가능해진다는 점이 LLM에게 판정을 맡기는 방식과 갈리는 지점이다.
• 검증기의 건전성과 완전성은 다른 문제다. 맞는 실행을 틀렸다고 판정하지 않는 것은 보장할 수 있지만 틀린 실행을 놓치지 않기는 어렵고, 주관적 조항이나 앞뒤가 어긋나는 문구, 국가마다 다른 법령을 코드로 옮기는 자동 형식화는 수학·코드 바깥에서 여전히 공개 과제로 남아 있다.
• 검증 신호를 실행 중 교정에만 쓰지 않고 학습 보상으로 되돌리는 방향이 다음 목표로 제시됐다. 도구 호출이 수백 번 이어지는 긴 과제에서는 최종 결과만 보는 보상보다 중간 피드백이 더 유효하다는 관찰이 근거다.

자주 묻는 질문

관련 AI 소식