Agent를 붙인 팀에서 반복해서 보는 장면이 있다. 성능이 부족하면 rollout을 늘린다. 같은 과업을 여러 번 풀게 하고, 그중 좋아 보이는 답을 고른다. 처음에는 잘 먹힌다. 곧 비용이 튄다. 더 큰 문제는 판단이다. 전체 로그를 judge에게 다시 넣으면 길고 시끄러운 trajectory가 그럴듯한 답을 이긴다.
2026년 4월 공개된 Agentic Coding test-time scaling 논문도 같은 문제를 짚는다. 긴 agent 시도는 action, observation, error, partial progress가 섞인 extended trajectory가 되며, 핵심은 더 많이 생성하는 것이 아니라 prior experience를 선택·재사용 가능한 표현으로 바꾸는 일이라고 정리한다. 이 글에서 말하는 trajectory sketch re-ranking은 그 운영형 해석이다. https://arxiv.org/abs/2604.16529
Rollout 증가는 곧 로그 폭증이다
일반적인 best-of-N은 짧은 답안에는 단순하다. 답안 N개를 놓고 고르면 된다. Agent 업무는 다르다. 중간에 파일을 읽고, API를 호출하고, 실패한 가설을 버리고, 우회 경로를 만든다. 최종 답만 보면 왜 맞았는지 모른다. 전체 로그를 붙이면 context가 비싸지고 judge가 흔들린다.
2026년 AggAgent 논문은 long-horizon agentic task에서 parallel trajectory가 길고, multi-turn이며, tool-augmented라고 설명한다. 최종 답만 aggregate하면 trajectory의 정보가 버려지고, 전체 trajectory를 concat하면 context window를 넘는 문제가 생긴다는 지적도 같다. https://arxiv.org/abs/2604.11753
운영 현장에서는 이 문제가 더 직접적이다. 로그는 감사와 재현을 위해 보존해야 한다. 그러나 매번 의사결정에 전체 로그를 투입하면 안 된다. 로그는 원장이고, ranking 입력은 별도로 만들어야 한다.
Agent scaling의 비용은 rollout 수가 아니라 rollout을 비교하는 방식에서 터진다.
Sketch는 요약이 아니라 상태 변화 계약이다
trajectory sketch를 단순 요약으로 만들면 실패한다. 요약은 문장이다. 문장은 누락을 숨긴다. re-ranking에 필요한 것은 compact state delta다. 시작 상태에서 무엇이 바뀌었고, 그 변화가 검증 가능한지 적는 계약이다.
| 구분 | 전체 로그 비교 | trajectory sketch re-ranking |
|---|---|---|
| 입력 | 모든 thought, tool call, observation | 상태 변화, 근거 pointer, 실패 mode |
| 판정 기준 | 긴 서사를 읽고 종합 판단 | delta 품질을 rubric으로 비교 |
| 비용 구조 | rollout 수와 로그 길이에 비례 | sketch 생성 후 top-k만 원장 확인 |
| 운영 리스크 | judge drift와 장문 편향 | schema 누락과 delta 왜곡 |
우리가 권하는 sketch schema는 작다. 과업마다 다르지만 기본 골격은 같다.
- state_before / state_after: 바뀐 산출물, 값, 의사결정
- delta_claims: 이번 rollout이 만든 핵심 변화
- evidence_pointers: 원장 로그, 파일 diff, tool result 위치
- failure_modes: 버린 가설, 막힌 경로, 남은 위험
- cost_metadata: step 수, tool 호출, latency, 재시도 여부
핵심은 thought를 저장하지 않는 것이 아니다. thought를 ranking의 주재료로 쓰지 않는 것이다. 판정은 상태 변화와 검증 근거를 본다. 원장 로그는 dispute가 생겼을 때만 연다.
Re-ranking은 토너먼트보다 운영 계약이 먼저다
Agentic Coding 논문은 rollout trajectory를 structured summary로 바꾸고, Recursive Tournament Voting과 Parallel-Distill-Refine 같은 scaling 방식을 제안한다. 논문의 표현을 운영에 그대로 옮기면 안 된다. 먼저 조직의 상태 계약을 정해야 한다. 무엇이 진척이고, 무엇이 위험이며, 무엇이 rollback 사유인지 합의해야 한다. https://arxiv.org/abs/2604.16529
AX Ops에서는 이 순서로 설계한다.
- state contract를 고정한다. 업무 산출물의 변경 단위를 먼저 정의한다.
- sketch generator를 agent와 분리한다. 실행 agent가 자기 성과를 과장하지 못하게 한다.
- ranker는 delta만 본다. 필요할 때 evidence pointer로 원장을 연다.
- top-k 이후에만 full trace review를 건다. 비용은 넓게 쓰지 않고 깊게 쓴다.
이 구조는 비용 절감 장치이면서 통제 장치다. 여러 rollout을 허용하되, 운영팀은 모든 시행착오를 읽지 않는다. 대신 delta 품질이 높은 후보만 검토한다. 신뢰는 긴 설명에서 나오지 않는다. 재현 가능한 상태 변화에서 나온다.
참고
- Joongwon Kim et al., 2026, “Scaling Test-Time Compute for Agentic Coding” — compact rollout representation, RTV, PDR 논의. https://arxiv.org/abs/2604.16529
- Yoonsang Lee et al., 2026, “Agentic Aggregation for Parallel Scaling of Long-Horizon Agentic Tasks” — 긴 tool-augmented trajectory aggregation 문제. https://arxiv.org/abs/2604.11753
- Litu Ou et al., 2025, “BrowseConf: Confidence-Guided Test-Time Scaling for Web Agents” — 고정 예산 TTS 대신 confidence로 재시도와 token 사용을 조절하는 접근. https://arxiv.org/abs/2510.23458
요약하면, trajectory sketch re-ranking은 agent를 더 똑똑하게 보이게 하는 장식이 아니다. rollout을 늘려도 운영비와 판정 리스크가 같이 폭증하지 않게 만드는 AX Ops 장치다. PoC 단계에서는 전체 로그를 사람이 읽어도 버틴다. 운영 단계에서는 state delta, evidence pointer, ranking rubric으로 바꿔야 한다. 이 전환을 설계하지 않으면 test-time scaling은 곧 비용 확대가 된다. 실행 구조까지 함께 잡으려면 AX Ops 방법론 →