13,000건의 에이전트 실행 속에서 본 OfficeQA 성공과 실패의 이유

OfficeQA Public Challenge에서는 782개의 채점된 제출물에서 73,000건 이상의 에이전트 실행이 생성되었습니다. 우리는 대표 표본 20%에 해당하는 156개 제출물, 총 13,483개의 개별 실행을 추출해 분석했습니다. 이 표본은 Goose, OpenAI의 Codex, OpenHands, OpenCode 네 가지 하네스를 모두 포함합니다. 목표는 정답에 도달한 실행과 그렇지 못한 실행을 가르는 차이가 무엇인지 파악하는 것이었습니다.

TL;DR

에이전트의 성공은 결국 에이전트가 과제를 얼마나 효율적으로 수행하는지, 그리고 과제 자체가 어떤 유형인지에 달려 있습니다.

• 과제가 해결되는지 여부는 대부분 에이전트가 아니라 과제 자체에 의해 결정됩니다. 네 가지 하네스는 어떤 문제가 쉽고 어떤 문제가 어려운지에 대해 약 90% 수준으로 유사하게 판단합니다.
• 에이전트가 오답으로 향하고 있을 때는 정답에 도달하는 경우보다 50% 더 많은 단계를 거치며, 그 과정에서 더 많은 토큰과 비용을 소모합니다.
• 실행 중 발생하는 오류는 실패를 예측하지 못합니다. 성공한 실행과 실패한 실행은 거의 동일한 비율로 오류를 경험했습니다.
• 다양한 도구를 사용하는 것은 도움이 되지만, 생각만큼 큰 영향을 주지는 않습니다.

에이전트 성공과 실패를 분석한 방법

OfficeQA에서 모든 에이전트는 미국 재무부 공보 697개 문서로 구성된 코퍼스를 바탕으로 94개의 어려운 수치형 질문에 답해야 했습니다. 예를 들어 "1974년 6월의 총 미상환 공공부채는 얼마였는가?"와 같은 질문입니다. 모든 과정은 인터넷 없이 완전히 오프라인으로 진행되었으며, 동일한 모델을 기준으로 서버 측에서 강제되었습니다. 참가자들은 Goose, Codex, OpenHands, OpenCode 네 가지 오픈소스 하네스 중 하나를 사용해 경쟁했습니다.

이번 연구에서는 채점 대상 전체의 20%에 해당하는 156개 제출물을 샘플링했습니다. 샘플은 네 가지 하네스와 상·중·하위권 팀을 균형 있게 포함하도록 구성했으며, 각 실행의 전체 궤적을 추출해 에이전트가 어떤 도구를 호출했는지, 무엇을 읽었는지, 무엇을 계산했는지, 그리고 정답에 도달했는지를 분석했습니다. 이는 총 13,483개의 완전한 에피소드에 해당합니다.

Finding 1: 난이도는 하네스가 아니라 과제에 있다

94개의 각 질문에 대해 에이전트가 얼마나 자주 정답을 맞혔는지, 그리고 서로 다른 하네스들이 어떤 질문을 더 어렵게 보는지에 대해 얼마나 일치하는지를 측정했습니다.

질문들은 명확한 난이도 구간으로 나뉘었습니다.

• 36%는 대체로 해결되는 문제였고,
• 36%는 매우 어려운 문제였으며,
• 26%는 실제로 결과가 갈리는 문제였습니다. 그리고 몇몇 문제는 사실상 모든 에이전트에게 불가능에 가까웠습니다.

94개 OfficeQA 질문의 난이도 분포.

하네스 쌍별로 과제 단위의 성공/실패 일치율은 88–93%였습니다. 즉, 에이전트들은 어떤 문제가 어렵고 쉬운지에 대해 압도적으로 비슷하게 판단했습니다.

과제 단위 성공/실패에 대한 하네스 간 일치율은 모든 쌍에서 88–93% 수준입니다.

쉽게 말해, 어떤 질문이 어렵다면 모두에게 어렵습니다. 혼란스러운 표나 까다로운 단위 변환은 하네스 프레임워크 선택의 문제가 아니라 질문 자체의 속성입니다. 오직 약 26%의 결과가 갈리는 질문들에서만 에이전트의 전략이 결과를 좌우합니다.

다음으로 우리는 하네스들이 서로 어떤 차이를 보이는지, 그리고 특정 하네스만이 다른 하네스가 풀지 못하는 과제를 고유하게 해결할 수 있는지 검증했습니다.

우리는 세 가지 기준으로 이를 분석했습니다.

1. 속도. 일반적인 실행에서는 하네스 간 속도가 비슷했습니다(중앙값 약 4분). 그러나 긴 꼬리 구간에서는 큰 차이가 나타났습니다. Codex는 가장 느린 하네스로, 95번째 백분위 실행 시간이 약 36분에 달했으며 일부 실행은 1시간을 넘겼습니다. 반면 OpenHands와 OpenCode는 약 15–17분 수준이었습니다. Goose의 실행 기록에는 단계별 타임스탬프가 없어 이 기준으로는 시간 측정이 불가능했습니다.
2. 가장 어려운 과제를 처리하는 능력. 어려운 문제에서 압도적으로 뛰어난 하네스는 없었습니다. 전체 해결률이 35% 미만인 가장 어려운 36개 과제에서 하네스 간 성능은 경쟁적으로 비슷했으며, Goose가 약간 앞섰습니다.
3. 능력은 공유되어 있으며, 특정 하네스에만 독점적으로 존재하지 않았습니다. 94개 과제 중 37개는 네 가지 하네스 모두가 해결했으며, 단 하나의 과제만이 특정 하네스(OpenHands)에 의해 단독으로 해결되었습니다. 나머지 어려운 과제들은 대부분 모두를 어렵게 만들었습니다. 42개 과제는 어떤 하네스에서도 안정적으로 해결되지 않았으며, 이는 다시 한 번 난이도가 하네스가 아니라 과제 자체에 있음을 보여줍니다.

Finding 2: 실패하는 실행은 훨씬 더 많은 단계를 거치며, 더 많은 비용을 발생시킨다

모든 하네스에서 실패한 실행은 성공한 실행보다 훨씬 더 많은 단계를 거쳤습니다.

실패한 에피소드는 유의미하게 더 많은 단계를 사용합니다 — Codex의 +11%에서 Goose의 +50%까지.

이는 단순히 단계 수의 문제가 아닙니다. 실패한 실행은 더 많은 토큰을 소모했으며, 실행별 비용 데이터가 있는 한 하네스에서는 오답 실행의 평균 비용이 $0.120인 반면 정답 실행의 평균 비용은 $0.086이었습니다. 즉, 실패한 실행은 약 40% 더 비쌌습니다.

실패한 에피소드는 더 많은 단계와 토큰, 비용을 소모합니다.

에이전트가 오답으로 향하고 있을 때는 빠르게 실패하지 않습니다. 대신 같은 자리에서 헤매며, 진전을 만들지 못한 채 훨씬 더 많은 행동을 반복합니다. 이는 유용한 조기 경고 신호가 됩니다. 단계 수가 급격히 늘어나는 실행은 실패하고 있을 가능성이 더 높습니다. 그리고 이는 단순한 시간 낭비가 아닙니다. 실패는 실제로 에피소드당 더 많은 컴퓨트와 비용을 발생시킵니다.

Finding 3: 실행 중 발생하는 오류는 경고 신호가 아니다

하지만 직관과 달리, "파일을 찾을 수 없음", 실패한 명령어, 빈 검색 결과와 같은 오류를 더 많이 경험한 실행이 더 자주 실패하는 것은 아니었습니다. 실행의 어떤 시점에서도 성공한 에피소드와 실패한 에피소드는 거의 동일한 오류율을 보였습니다. 예를 들어 5번째 단계에서 오류율은 약 5.5% 대 5.3%였습니다. 두 선은 거의 겹쳐 있었습니다.

실행이 진행됨에 따른 오류율입니다. "성공"과 "실패" 라인은 거의 겹쳐 있으며, 에이전트가 최종적으로 정답에 도달하는지와 관계없이 오류는 비슷한 비율로 발생합니다.

오류를 만나는 것은 이러한 에이전트가 작동하는 방식의 정상적인 일부입니다. 에이전트는 탐색하고, 오류를 만나고, 조정한 뒤 다시 진행합니다. 오류가 발생했다는 사실만으로 해당 실행이 실패할 것이라고 볼 수는 없습니다. 따라서 "오류 개수 세기"는 직관적으로는 그럴듯해 보이지만, 실제로는 실패를 예측하는 나쁜 방법입니다.

Finding 4: 다양한 도구를 시도하는 것은 도움이 되지만, 효과는 제한적이다

도구 다양성은 실행에서 에이전트가 얼마나 많은 서로 다른 도구를 사용했는지를 의미하며, 엔트로피로 측정합니다. 값이 높을수록 여러 도구를 혼합해 사용했다는 뜻이고, 값이 낮을수록 같은 도구를 반복 사용했다는 뜻입니다.

우리는 도구 다양성이 에이전트 성공과 상관관계가 있는지 검증하고자 했습니다. 분석 결과, 네 가지 하네스 모두에서 성공한 실행은 실패한 실행보다 약간 더 다양한 도구를 사용했습니다. 신호의 방향은 맞았지만 강도는 약했습니다. 통계적으로 보면 실패를 예측하는 능력은 동전 던지기보다 조금 나은 정도였습니다.

따라서 에이전트가 같은 도구만 계속 두드리는 것은 막혀 있다는 약한 신호일 수 있습니다. 그러나 "더 많은 도구를 사용하라"는 것이 성공을 보장하는 마법 같은 해결책은 아닙니다.

Finding 5: 반복적인 도구 호출은 에이전트가 막혀 있음을 보여준다

우리는 에이전트가 같은 도구를 연속으로 두 번 호출하는 경우, 즉 "재시도"가 얼마나 자주 발생하는지와 이것이 실패와 어떤 상관관계를 가지는지 측정했습니다.

어려움을 겪는 실행은 다른 방식을 시도하기보다 같은 행동을 반복해서 재시도하는 경향이 있었습니다. Finding 2("실패한 실행은 훨씬 더 많은 단계를 거치고 비용도 더 많이 든다")와 Finding 4("실패한 실행은 도구 다양성이 낮다")를 함께 보면 일관된 그림이 나타납니다. 실패하는 실행은 오류를 만나고 멈추는 실행이 아닙니다. 실패하는 실행은 루프에 갇혀, 여러 단계에 걸쳐 같은 행동을 반복하지만 진전을 만들지 못하는 실행입니다.

심층 분석: 모든 하네스에는 고유한 지문이 있지만, 단 하나의 승리 공식은 없다

성공/실패 여부를 넘어, 각 하네스는 도구를 사용하는 방식에서 뚜렷한 차이를 보였습니다.

• Codex는 가장 셸 중심적인 하네스입니다. 거의 모든 작업이 하나의 커맨드라인 도구를 통해 실행되며, 실행당 약 20회의 셸 호출을 사용하고 전용 검색/읽기 도구는 거의 사용하지 않습니다.
• OpenCode는 가장 도구 다양성이 높은 하네스입니다. 원시 셸보다 전용 검색과 읽기 도구를 훨씬 더 많이 사용합니다. 이는 Finding 4에서 나타난 높은 도구 다양성 점수와도 일치합니다.
• Goose와 OpenHands는 그 중간에 위치합니다. 둘 다 셸을 많이 사용하지만, 검색과 편집 도구도 실제로 혼합해 사용합니다.

다음은 성공률과 실패율로 나누어, 실행당 평균 도구 호출 수를 도구 계열별로 정리한 표입니다.

히트맵은 실행당 각 도구 유형의 평균 호출 수를 보여줍니다. 다양한 도구를 셸, 검색, 읽기와 같은 계열로 그룹화해 네 가지 프레임워크를 공정하게 비교할 수 있도록 했습니다.

각 하네스는 어떻게 성공하는가

이번 연구의 대부분은 실패에 초점을 맞췄습니다. 반대로 성공한 실행만 따로 살펴보니, 하네스들이 서로 다른 방식으로 성공한다는 점이 뚜렷하게 나타났습니다.

goose의 실행 기록에는 타임스탬프가 없습니다.

각 하네스의 승리 방식은 다음과 같습니다.

• OpenCode는 "외과적으로" 승리합니다. 가장 적은 단계(중앙값 18단계)로, 가장 다양한 도구 세트를 활용하고, 같은 행동을 거의 반복하지 않습니다.
• Codex는 "무차별 대입" 방식으로 승리합니다. 거의 모든 것을 하나의 셸 도구로 처리하며, 도구 다양성은 거의 0에 가깝고, 행동을 자주 반복하며, 가장 많은 단계를 거칩니다. 결국 정답에 도달하기는 하지만 덜 세련된 방식입니다.
• OpenHands와 Goose는 그 중간에 위치합니다. 둘 다 정답에 도달하지만, 그 과정은 서로 완전히 다르게 보입니다.

속도도 같은 패턴을 따릅니다. 일반적인 성공 실행은 모든 하네스에서 빠른 편이며 중앙값은 약 3분입니다. 그러나 긴 꼬리 구간에서는 차이가 크게 벌어집니다. Codex의 95번째 백분위 성공 실행은 약 23분까지 늘어나며, 어려운 실행에서는 더 길어집니다. 성공을 위한 단 하나의 하네스나 단 하나의 공식은 없습니다. OpenCode처럼 간결하고 다양한 접근 방식도, Codex처럼 반복적이고 셸 중심적인 방식도 모두 정답에 도달할 수 있습니다. 다만 그 과정은 완전히 다르게 나타납니다.

정리: 에이전트 실패를 예측하는 신호

우리는 각 신호가 실패한 실행과 성공한 실행을 얼마나 잘 구분하는지 하네스별로 점수화했습니다. 척도는 단순합니다. 0.50 = 쓸모없는 수준이며, 점수가 높을수록 더 좋은 신호입니다.

가장 신뢰할 수 있는 단일 신호는 에이전트가 얼마나 오래 계속 작업하는지였습니다. 이는 Finding 2에서 확인한 "헤매는 신호"입니다. 가장 직관적인 후보였던 오류율은 사실상 동전 던지기와 다르지 않았습니다. 이는 패턴을 확인시켜줍니다. 오류를 볼 것이 아니라, 에이전트의 작업량과 헤매는 정도를 봐야 합니다.

결론

모든 내용을 종합하면 이야기는 단순합니다.

1. 문제가 풀리는지 여부는 대부분 질문 자체가 결정합니다. 에이전트들은 어떤 문제가 어려운지에 대해 대체로 같은 판단을 내립니다.
2. 성공하는 에이전트는 빠르고 저렴하게 실패합니다. 실패하는 에이전트는 헤맵니다. 더 많은 단계를 거치고, 더 많이 반복하며, 진전 없이 비용만 소모합니다.
3. 겉보기 쉬운 신호를 믿어서는 안 됩니다. 오류 메시지는 실패를 예측하지 못합니다. 가장 강력한 신호는 에이전트가 얼마나 오래 헤매고 있는지입니다.

에이전트를 만드는 모든 사람들에게 실질적인 교훈은 명확합니다. 에이전트가 헤매고 있다는 신호를 조기에 감지하고, 그 흐름을 끊어야 합니다. 단계 수가 계속 쌓이고 같은 행동을 반복하는 실행이야말로 개입해야 할 대상입니다. 단순히 오류를 한 번 만난 실행보다 훨씬 더 중요합니다.

다음 단계

이 13,483개의 실행 궤적은 전체 OfficeQA trace 데이터셋이 가능하게 할 일들의 일부를 보여주는 미리보기입니다. 이를 통해 실패 분석, 스스로 막혔음을 감지하는 자기수정형 에이전트, 그리고 덜 헤매는 모델을 위한 학습 데이터를 만들 수 있습니다.

• Sentient Arena 웹사이트를 확인해보세요.
• 최종 OfficeQA 리더보드를 살펴보세요.
• OfficeQA Public Challenge 우승자 소개 아티클을 읽어보세요.
• Arena YouTube 플레이리스트도 확인해보세요.