한 번의 에이전트 평가는 수천 달러가 들고 며칠이 걸릴 수 있다. 이 병목을 줄이려는 시도가 나왔다. PACE는 14개 모델, 4개 에이전트 벤치마크, 19개 비에이전트 벤치마크를 묶어, 값싼 시험으로 비싼 시험의 결과를 얼마나 예측할 수 있는지 살핀다. 핵심 질문은 단순하다. 에이전트의 실력을 꼭 무거운 환경에서만 재야 하느냐는 것이다.

세 줄 요약

• PACE는 비에이전트 능력 평가로 에이전트 벤치마크 성능을 예측할 수 있는지 다루며, 공개된 요약 기준으로 LOOCV 평균절대오차 4% 미만, Spearman 상관 0.80 초과, **쌍대 모델 순위 정확도 약 85%**를 보고했다.
• 이 점은 중요하다. SWE-Bench나 GAIA 같은 평가는 비용, 시간, 인프라 부담이 커서 모델 개발 속도를 늦출 수 있다. 프록시가 통하면 평가 병목이 줄고 실험 회전율이 올라간다.
• 프록시 점수는 “출시 승인”보다 “선별 필터”에 가깝다. 프록시로 후보를 줄이고, 최종 선택은 실제 에이전트 벤치마크와 상호작용 테스트로 검증하라.

현황

에이전트 평가는 비싸다. PACE 논문 요약에 따르면, SWE-Bench와 GAIA 같은 에이전트 벤치마크 평가는 복잡한 인프라가 필요해 비용과 시간이 많이 들며, 한 번의 평가가 수천 달러와 며칠을 요구할 수 있다. 이유도 비교적 분명하다. 단순 질의응답이 아니라 툴 호출, 환경 실행, 장기 과제 수행, 복잡한 인프라가 함께 필요하기 때문이다.

PACE가 겨냥하는 지점도 여기다. 공개된 조사 결과에 따르면 이 연구는 14개 모델, 4개 에이전트 벤치마크, 19개 비에이전트 벤치마크를 바탕으로 프록시의 예측력을 측정했다. 요약 기준 성과는 다음과 같다. 에이전트 점수 예측의 LOOCV 평균절대오차는 4% 미만, 순위 상관은 0.80 초과, 두 모델을 짝지어 어느 쪽이 더 나은지 맞히는 정확도는 **약 85%**다.

무엇이 더 잘 맞았는지도 볼 필요가 있다. 조사 결과상 가장 강한 상관을 보인 축은 계획, 즉 planning 계열이다. 관련 요약은 PlanBench가 4개 에이전트 벤치마크 전체에서 가장 큰 기여를 했다고 전한다. 이는 에이전트 성능이 “코드를 잘 쓰는가” 하나로만 설명되기 어렵고, 단계 설계와 행동 순서를 세우는 능력과도 연결될 수 있음을 뜻한다.

그렇다고 프록시가 에이전트 평가를 대체한다는 뜻은 아니다. Dialogue SWE-Bench는 더 강한 코딩 모델이 항상 더 강한 대화형 코딩 에이전트로 이어지지 않는다고 적었다. DecisionBench 쪽 요약도 비슷하다. 평균 최종 과업 품질만 보면 구분이 잘 되지 않아도, 실제로는 orchestration signal, 즉 작업 조율 능력 차이가 숨어 있을 수 있다고 지적한다. 품질 점수 하나만 보면 놓치는 영역이 있다는 뜻이다.

분석

의사결정 관점에서 보면 PACE의 가치는 “대체”보다 “압축”에 있다. 비에이전트 평가가 실제 에이전트 순위를 약 85% 수준으로 가려낸다면, 팀은 모든 후보를 SWE-Bench급 환경에 올릴 필요가 줄어든다. 먼저 값싼 프록시로 후보군을 추리고, 그다음 상위 몇 개만 무거운 평가로 넘기면 된다. 이 구조는 모델 연구팀, 플랫폼 팀, 구매팀에 모두 실용적일 수 있다. 실험 속도는 빨라지고, 평가 예산과 인프라 대기 부담은 줄어든다.

다만 조건이 있다. 만약 당신의 에이전트가 정적 추론보다 대화, 툴 사용, 장기 실행, 역할 분담에 더 의존한다면, 그때는 프록시의 설명력이 약해질 수 있다. Dialogue SWE-Bench가 말하듯 코딩 실력과 대화형 에이전트 성능은 같은 축이 아닐 수 있다. DecisionBench가 지적하듯 최종 결과가 비슷해도 중간 조율 과정은 크게 다를 수 있다. 즉 PACE는 “누가 대체로 강한가”를 고르는 데는 도움이 되지만, “실전에서 왜 실패하는가”까지 풀어주지는 못한다.

트레이드오프도 분명하다. 프록시를 쓰면 비용과 시간을 줄일 수 있다. 대신 에이전트 고유 능력, 특히 환경 상호작용과 운영 중 예외 처리 같은 부분은 덜 보일 수 있다. 반대로 실제 에이전트 벤치마크는 비싸고 느리다. 대신 실패 양상이 더 잘 드러난다. 그래서 이 문제는 기술 우열보다 평가 설계에 가깝다. 무엇을 최적화할지 먼저 정해야 한다. 연구 속도인가, 배포 안전성인가, 아니면 두 목표 사이의 균형인가.

실전 적용

실무에서 가장 현실적인 접근은 2단계 게이트다. 1차에서는 비에이전트 벤치마크를 돌려 후보 모델을 압축한다. 이때 계획 능력과 추론, 코드 생성처럼 에이전트 과제와 닿아 있는 축을 함께 본다. 2차에서는 실제 업무와 닮은 에이전트 평가를 남긴다. 툴 실패, 멀티턴 대화, 장기 과제 완료율, 중간 조율 로그를 같이 본다. 프록시는 채용 공고의 서류 전형에, 에이전트 벤치마크는 실무 과제에 가깝다.

예: 코드 에이전트를 고르는 팀이라면, 먼저 비에이전트 시험으로 상위권만 추린 뒤 대화형 버그 수정 과제와 저장소 단위 작업을 별도로 돌리면 된다. 반대로 리서치 에이전트나 업무 자동화 에이전트라면, 정답률보다 계획 수정 능력과 툴 호출 실패 복구를 더 비중 있게 봐야 한다. 프록시 점수가 높아도 실제 운영형 워크플로에서 성능이 달라질 수 있기 때문이다.

오늘 바로 할 일 체크리스트:

• 현재 평가 파이프라인을 프록시용 1차 선별과 실제 에이전트용 2차 검증으로 분리하라.
• 비에이전트 지표를 볼 때 단일 점수 대신 계획 계열과 대화·상호작용 계열을 따로 기록하라.
• 최종 모델 선택 전에는 평균 점수뿐 아니라 실패 로그와 조율 과정을 샘플 단위로 검토하라.

FAQ

Q. PACE 같은 프록시가 있으면 SWE-Bench나 GAIA를 안 돌려도 됩니까?
아닙니다. 공개된 요약만 보면 프록시는 에이전트 성능을 꽤 잘 예측하지만, 완전한 대체물로 확인되지는 않았습니다. 최종 배포 결정에는 실제 에이전트 평가가 여전히 필요합니다.

Q. 어떤 능력이 프록시로 특히 중요합니까?
조사 결과 기준으로는 계획, 즉 planning 계열이 가장 강한 상관을 보였습니다. 다만 논문 본문에서 축 정의와 세부 수치가 어떻게 제시됐는지는 여기서 확인된 범위를 넘습니다.

Q. 그럼 코딩 점수만 높으면 좋은 에이전트입니까?
그렇지 않습니다. Dialogue SWE-Bench는 더 강한 코딩 모델이 항상 더 강한 대화형 코딩 에이전트로 이어지지 않는다고 적었습니다. 대화 능력, 상호작용, 조율 같은 요소를 따로 봐야 합니다.

결론

PACE가 던지는 메시지는 비교적 분명하다. 에이전트 평가는 꼭 무겁고 느려야만 하는 일은 아닐 수 있다. 다만 프록시는 지름길이지 종착점은 아니다. 비용을 줄이는 선별 장치로는 유망하지만, 실제 에이전트의 상호작용 능력까지 대신 재지는 못한다.

다음으로 읽기

• AI 자료 모음 (24h) - 2026-07-04
• LLM 성격보다 정렬이 핵심
• 콜드스타트 PPI의 5개 모달리티
• ReContext, 장문맥의 착시를 넘다
• 장문서 QA 근거추적의 조건

참고 자료

• PACE: A Proxy for Agentic Capability Evaluation - huggingface.co
• PlanBench: An Extensible Benchmark for Evaluating Large Language Models on Planning and Reasoning about Change - huggingface.co
• arxiv.org - arxiv.org
• Dialogue SWE-Bench: A Benchmark for Dialogue-Driven Coding Agents - arxiv.org
• DecisionBench: A Benchmark for Emergent Delegation in Long-Horizon Agentic Workflows - arxiv.org