Workspace-Bench 1.0: Benchmarking AI Agents on Workspace Tasks with Large-Scale File Dependencies
https://arxiv.org/abs/2605.03596
Zirui Tang, Xuanhe Zhou, Yumou Liu, Linchun Li, Weizheng Wang, Hongzhang Huang, Jun Zhou, Jiachen Song, Shaoli Yu, Jinqi Wang, Zihang Zhou, Hongyi Zhou, Yuting Lv, Jinyang Li, Jiashuo Liu, Ruoyu Chen, Chunwei Liu, GuoLiang Li, Jihua Kang, Fan Wu | Shanghai Jiao Tong University, ByteDance, MIT, Tsinghua University, Independent Researcher | arXiv:2605.03596 | 2026년 5월
1. 서론: 업무공간 전체를 평가 단위로 바꾸는 문제의식
Workspace-Bench 1.0은 에이전트가 단일 문서 질문에 답하는 수준을 넘어, 한 지식 노동자의 실제 업무 폴더처럼 얽힌 파일 생태계 안에서 필요한 자료를 찾고, 파일 사이의 의미적·시간적 관계를 해석하며, 결과물을 갱신할 수 있는지를 평가하려는 벤치마크다. 논문이 말하는 Workspace Learning은 단순 검색을 넘어 의존성 식별, 의존성 추론, 의존성 활용, 그리고 작업 결과에 따른 갱신까지 포함한다.
기존 에이전트 벤치마크는 크게 네 흐름으로 나뉜다. 모든 정보가 프롬프트 안에 들어 있는 Prompt-Driven 유형, 웹·API·GUI 환경에서 도구 사용을 보는 Open-Source 또는 Environment-Driven 유형, 태스크별 파일 묶음을 제공하는 Task-File-Driven 유형, 그리고 실제 파일 시스템에 가까운 Workspace-Relevant 유형이다. 이 논문은 네 유형 모두가 실제 사무 공간의 핵심인 파일 간 관계를 충분히 평가하지 못한다고 본다.
논문의 중요한 전제는 “에이전트가 GUI를 누를 수 있다”와 “에이전트가 업무를 끝낼 수 있다” 사이에 큰 간극이 있다는 점이다. 오늘날 에이전트는 MCP, 장기 상태, 메모리, 도구 호출, 평가 루프를 갖추었지만, 수십 개의 관련 파일 중 어느 파일이 최신인지, 어떤 보고서가 어떤 스프레드시트에서 파생되었는지, 어떤 회의록이 결과물을 뒷받침하는지 추적하는 데 여전히 취약하다.
논문은 ByteDance의 Lark 플랫폼에서 수집한 154개 실제 업무 시나리오를 분석하며 문제의식을 구체화한다. 예컨대 맞춤형 제안서를 작성하려면 고객 프로필, 과거 커뮤니케이션, 내부 지식 베이스, 시장 자료, 이전 제안서 버전이 서로 연결되어야 한다. 이때 실패는 단순 오답보다 넓게 핵심 정보 누락, 논리 불일치, 사실 오류, 잘못된 버전 사용으로 나타난다.
따라서 Workspace-Bench의 관점에서 좋은 에이전트는 “파일을 읽었다”에 머물지 않고 정확한 파일을 찾아야 하고, “요약했다”에 그치지 않고 의존 관계를 보존한 채 결과를 만들어야 하며, “출력했다”에서 끝나지 않고 요구된 경로와 형식, 근거 파일, 중간 판단을 함께 만족해야 한다. 이 차이가 논문 전체의 평가 철학을 결정한다.
이 벤치마크는 다섯 직무 페르소나, 74개 파일 형식, 총 20,476개 파일, 최대 20GB 규모의 워크스페이스를 구성하고, 그 위에 388개 태스크와 7,399개 루브릭을 얹는다. 평균적으로 한 태스크는 4.7개 파일과 5.1개 의존성 간선을 요구하며, 평가 루브릭은 태스크당 평균 19.1개다. 숫자 자체가 “단일 정답 QA”에서 벗어나려는 설계를 보여준다.
논문은 또한 Workspace-Bench-Lite를 함께 제공한다. Lite는 100개 태스크로 구성된 부분집합이지만, 원본 벤치마크의 직무, 난이도, 능력 차원 분포를 보존하도록 선별되었다. 연구팀은 이를 통해 평가 비용을 약 70% 줄이면서도 빠른 비교 실험을 가능하게 만들었다고 설명한다.
결과적으로 이 논문은 새로운 모델을 제안하기보다, 현재 에이전트가 어디에서 무너지는지 드러내는 평가 인프라 논문에 가깝다. 특히 “강한 LLM + 좋은 하네스”가 어느 정도 우위를 보이지만, 인간 전문가와의 격차가 여전히 크고, 파일 간 의존성 간선 인식은 노드 인식보다 더 어렵다는 점을 체계적으로 보여준다.
핵심 요약만 먼저 말하면, 평균 에이전트 성능은 47.4% 수준이고, 최고 조합도 약 68%대에 머문다. 인간 기준선은 80.7%로 더 높다. 난이도별 평균은 Easy 57.6%, Medium 49.2%, Hard 40.5%로 단계적으로 하락한다. 이는 난이도 설계가 임의적 분류를 넘어 실제 에이전트 실패 양상과 맞닿아 있음을 시사한다.
1.1 실패 단위를 정답에서 근거 체인으로 옮기기
Workspace-Bench가 흥미로운 이유는 실패를 최종 문장 하나의 오답으로만 보지 않는다는 데 있다. 같은 결과물이라도 핵심 파일을 누락한 경우, 오래된 버전을 인용한 경우, 표 계산은 맞지만 슬라이드에 잘못 옮긴 경우, 요구 형식을 지키지 못한 경우가 서로 다른 실패로 분해된다. 이 분해가 가능하려면 태스크마다 필요한 파일 집합과 파일 간 관계, 그리고 결과물의 부분 기준이 함께 정의되어야 한다.
이 관점은 실제 사무 자동화에 가깝다. 사람이 에이전트에게 보고서 작성을 맡길 때 기대하는 것은 자연스러운 문장과 함께 어떤 자료를 보았고 어떤 자료를 제외했으며 어떤 중간 판단으로 결론을 만들었는지까지 포함한다. 논문은 이를 workspace-aware reasoning으로 부르며, 에이전트 평가가 정답률 중심에서 근거 체인 중심으로 이동해야 한다고 주장한다.
따라서 이 벤치마크의 점수는 모델 지식의 암기 정도보다 환경 안에서의 정보 조직 능력을 더 많이 반영한다. 파일 수가 많고 폴더가 깊으며 형식이 다양할수록, 에이전트는 검색 결과를 곧바로 답으로 바꾸기 어렵다. 먼저 후보 파일을 좁히고, 관련 파일의 최신성과 파생 관계를 확인하고, 결과 파일에 어떤 근거가 들어가야 하는지 결정해야 한다.
아래 표는 논문이 기존 벤치마크와 Workspace-Bench를 구분할 때 사용하는 축을 한국어로 압축한 것이다. 원 논문 표는 더 많은 벤치마크를 다루지만, 여기서는 구조·파일 형식·의존성·계보 관계라는 핵심 차이를 중심으로 재구성했다.
Table 1. 기존 에이전트 벤치마크와 Workspace-Bench의 관점 차이
| 분류 | 대표 예시 | 주요 입력 | 한계 | Workspace-Bench의 보강점 |
|---|---|---|---|---|
| Prompt-Driven | OneMillion-Bench, CL-Bench | 프롬프트 안의 완결 정보 | 실제 파일 탐색과 갱신을 우회 | 복잡한 폴더와 파일 의존성에서 필요한 정보를 직접 찾게 함 |
| Environment-Driven | OSWorld, WebArena, CRMArena-Pro | 웹, API, GUI, 운영체제 도구 | 행동 접지는 보지만 사무 파일 생태계는 얕게 다룸 | 대규모 로컬 워크스페이스에서 파일 간 의미 관계를 평가 |
| Task-File-Driven | OfficeQA-Pro, GDPVal | 태스크별 선별 파일 | 독립 문서 QA에 가까워 검색·필터링 부담이 낮음 | 태스크가 필요한 파일을 에이전트가 스스로 식별해야 함 |
| Workspace-Relevant | OfficeBench, TheAgentCompany, SWE-Bench | 제한된 파일 시스템 또는 코드 저장소 | 페르소나와 파일 형식 다양성이 부족하고 계보 관계가 약함 | 5개 직무, 74개 파일 형식, 명시적 파일 의존성 그래프를 제공 |
Figure 1: Workspace-Bench-Lite에서 네 하네스와 일곱 백본 모델 조합의 성능 순위.
이 그림은 Lite 100개 태스크에서 28개 에이전트 조합의 루브릭 통과율을 비교한다. 상위권은 모두 Opus-4.7을 사용하지만, 하네스에 따라 순위와 안정성이 달라진다. 평균 47.4%, 인간 80.7%라는 간격은 강력한 모델만으로 실제 워크스페이스 작업을 신뢰하기 어렵다는 점을 한눈에 보여준다. 또한 Pass@100이 낮다는 사실은 부분 성공과 완전 제출 가능 상태가 다름을 강조한다. 이 차이는 하네스별 orchestration 품질과 모델 자체의 reasoning 능력을 분리해서 봐야 함을 알려주며, 리더보드 상위권도 사람 검수를 대체하기에는 아직 제한적임을 시사한다.
2. 배경 및 관련 연구: 기존 에이전트 벤치마크가 놓친 파일 의존성
Workspace-Bench는 하나의 추상 폴더를 넘어 운영 매니저, 물류 매니저, AI 제품 매니저, 백엔드 개발자, 연구자라는 다섯 직무의 업무 공간을 별도로 구성한다. 이 선택은 중요하다. 직무가 달라지면 폴더 구조, 파일 이름 관습, 자주 등장하는 형식, 결과물 종류, 파일 간 관계의 성격이 모두 바뀌기 때문이다.
예를 들어 백엔드 개발자 워크스페이스는 코드, 테스트, 문서, 설정 파일이 많은 반면, 연구자 워크스페이스는 논문, 실험 결과, 표, 그림, 분석 스크립트, 참고 문헌이 중심이 된다. 운영·물류·제품 매니저의 공간은 보고서, 스프레드시트, 프레젠테이션, 이메일, 회의록, 고객 데이터가 섞인다. 논문은 이 다양성을 통해 페르소나 의존적 파일 생태계를 평가하고자 한다.
전체 규모는 20,476개 파일과 3,299개 디렉터리다. 평균 파일 수는 워크스페이스당 4,095개이며, 가장 큰 워크스페이스는 11,020개 파일을 포함한다. 최대 디렉터리 깊이는 8이다. 파일 형식은 74개이며, 출력 형식도 16종 이상이다. 이는 에이전트가 단순히 텍스트 파일 몇 개를 읽는 수준을 넘어, 실제 지식 노동 환경처럼 파일 형식의 이질성을 견뎌야 함을 뜻한다.
논문이 강조하는 또 다른 포인트는 “노이즈”다. 실제 업무 폴더에는 최종본만 존재하지 않는다. 초안, 검토본, 오래된 버전, 중복 폴더, 애매한 파일명, 압축 해제된 자료, 자동 생성 산출물, 사람이 임시로 복사한 파일이 공존한다. Workspace-Bench는 이런 환경을 재현하기 위해 구조적 노이즈와 의미적 노이즈를 의도적으로 넣는다.
이 환경에서 에이전트는 파일 이름만으로 답을 찾기 어렵다. 어떤 파일이 결과물에 직접 기여하는 result-providing file인지, 어떤 파일이 해석 맥락을 제공하는 task-supporting file인지, 어떤 파일이 이전 버전이나 파생 파일인지 구분해야 한다. 논문의 파일 의존성 그래프는 바로 이 구분을 명시화하기 위한 장치다.
원 논문은 파일 구성 비율도 제시한다. 스프레드시트와 문서가 각각 37.5%와 35.3%로 가장 큰 비중을 차지한다. 코드와 설정 파일은 12.7%이며, 백엔드 개발자 공간에서 특히 많이 나타난다. 이 수치는 벤치마크가 코드 작업을 넘어 일반 사무, 분석, 전략 문서 작성, 데이터 통합까지 다루려는 설계를 반영한다.
다섯 페르소나의 태스크 수는 운영 매니저 122개, 물류 매니저 115개, 연구자 67개, 백엔드 개발자 43개, AI 제품 매니저 41개다. 업무 유형의 균형이 완전히 같지는 않지만, 실제 기업 업무의 빈도와 자료 복잡도를 반영하려는 선택으로 읽힌다. 특히 운영과 물류는 다수 파일을 종합해 의사결정 문서를 작성하는 요청이 많다.
2.1 파일 규모보다 중요한 것은 관계의 밀도
20,476개 파일이라는 숫자는 크지만, 논문이 더 강조하는 축은 관계의 밀도다. 워크스페이스 안의 파일은 독립 샘플처럼 배치되지 않는다. 한 회의록이 제품 요구사항 문서의 근거가 되고, 그 요구사항 문서가 스프레드시트의 필터 기준을 바꾸며, 다시 그 스프레드시트가 발표 자료의 그래프를 만든다. 에이전트는 이 체인을 따라가야 최종 산출물을 일관되게 만들 수 있다.
이 관계 밀도는 일반 RAG 평가와도 차이를 만든다. RAG에서는 관련 passage 몇 개를 찾아 답변에 반영하는 것이 핵심인 경우가 많다. Workspace-Bench에서는 passage보다 파일 객체가 중요하고, 파일 객체 사이에는 버전, 파생, 참조, 요약, 집계, 승인 같은 여러 관계가 붙는다. 그래서 단순 top-k retrieval만으로는 충분하지 않고, 검색 이후의 구조화가 필요하다.
직무 페르소나 역시 관계 밀도를 바꾼다. 개발자 워크스페이스의 의존성은 테스트와 코드, 설정과 문서 사이에서 비교적 명시적으로 드러나는 반면, 제품 매니저나 운영 매니저의 의존성은 회의 맥락, 과거 의사결정, 시장 자료, 고객 데이터의 느슨한 연결로 나타난다. 논문이 페르소나를 나누는 이유는 이처럼 관계의 표면 형태가 직무마다 달라지기 때문이다.
아래 표는 논문 Table 2의 주요 통계를 한국어 독자를 위해 정리한 것이다. 단순한 크기와 함께 평가 루브릭, 파일 형식, 디렉터리 깊이, 전문가 주석 시간까지 함께 제시되기 때문에, 이 벤치마크가 데이터셋보다는 평가용 워크스페이스 시뮬레이터에 가까움을 알 수 있다.
Table 2. Workspace-Bench 1.0 전체 규모와 핵심 통계
| 지표 | 값 | 해석 |
|---|---|---|
| 직무 워크스페이스 | 5개 | 운영, 물류, 제품, 개발, 연구 페르소나를 분리해 구성 |
| 전체 태스크 | 388개 | 각 태스크는 자연어 요청과 파일 의존성 그래프를 가짐 |
| 전체 파일 | 20,476개 | 최대 20GB급 워크스페이스 규모를 시뮬레이션 |
| 파일 형식 | 74개 | 문서, 표, 코드, 설정, 이메일, 통계 데이터, 이미지 등 포함 |
| 전체 루브릭 | 7,399개 | 최종 결과와 함께 과정과 기본 형식까지 세밀하게 평가 |
| 평균 루브릭 | 태스크당 19.1개 | 정답 하나에 그치지 않고 부분 만족도를 진단할 수 있음 |
| 평균 의존성 | 4.7개 파일, 5.1개 간선 | 파일 간 관계를 찾지 못하면 점수 손실이 발생 |
| Lite 버전 | 100개 태스크 | 분포를 보존하면서 평가 비용을 약 70% 절감 |
Figure 2: Workspace-Bench의 전체 개요와 여섯 가지 워크스페이스 학습 능력.
이 개요도는 Workspace-Bench가 단순한 파일 모음을 넘어 페르소나별 워크스페이스, 태스크, 의존성 그래프, 루브릭 평가를 하나의 흐름으로 연결한다는 점을 요약한다. 특히 탐색, 지원 파일 활용, 결과 파일 활용, 내용 관계, 이질 파일 이해, 계보 추적이라는 여섯 능력이 평가 축으로 분해된다. 따라서 점수는 단일 정답률보다 업무 공간을 읽고 쓰는 전 과정을 반영한다. 또한 데이터 구축, 실행 샌드박스, 파일 의존성 주석, 루브릭 평가가 분리되지 않고 연결되어 있어, 벤치마크가 단순 문제집보다 운영 평가 시스템에 가깝다는 점이 드러난다.
3. 방법론: Workspace-Bench 수집과 큐레이션 파이프라인
Workspace-Bench의 데이터 구축은 완전 자동 생성이 아니다. 논문은 현실성과 재현성을 동시에 확보하기 위해 페르소나 기반 구조 생성, 실제 공개 자료 수집, 근거 기반 합성, 태스크 주석, 전문가 검증을 결합한다. LLM은 보조 도구로 쓰이지만, 태스크 논리와 평가 기준은 사람이 통제한다.
첫 단계는 직무별 파일 구조를 만드는 것이다. 개발자는 src, tests, docs 같은 디렉터리를 자주 갖고, 연구자는 literature, experiments, results 같은 폴더를 갖는다. 운영 매니저나 물류 매니저는 시장 보고서, 주문 기록, 재고표, 회의록, 고객 커뮤니케이션이 섞인다. 연구팀은 이런 관습을 페르소나 프로필에 반영해 트리형 디렉터리를 생성한다.
두 번째 단계는 콘텐츠 채우기다. 논문은 semantic-driven agentic crawler를 사용해 arXiv 논문, GitHub 저장소, 기술 문서, 보고서, 스프레드시트, 발표 자료 등 공개 자원을 수집한다. 이후 LLM이 수집 자료에 근거한 이메일, 회의록, 파생 보고서 같은 보조 산출물을 생성한다. 중요한 점은 생성물이 무작위 텍스트를 피하고 이미 수집된 파일과 관계를 갖도록 설계된다는 것이다.
세 번째 단계는 구조와 내용의 일관성 검토다. 전문가들은 디렉터리가 해당 직무의 업무 흐름과 맞는지, 파일 내용이 위치와 어울리는지, 주입된 관계가 실제 태스크를 만들 수 있을 만큼 의미 있는지 확인한다. 이 과정은 벤치마크가 “그럴듯한 폴더”에 머물지 않고 작업 가능한 폴더가 되도록 만든다.
태스크 큐레이션은 별도로 진행된다. 연구팀은 내부 설문으로 실제 업무 흐름을 수집하고, 도메인 전문가가 사소하거나 모호한 사례를 제거한다. 여기서 154개의 대표 업무 시나리오가 정리된다. 이후 다섯 직무와 맞춘 25명의 annotator가 구체적인 자연어 요청, 필요한 입력 파일, 기준 출력, 루브릭을 작성한다.
논문은 평가 가능성을 높이기 위해 모호한 기준을 데이터 기반 단언으로 바꾼다. 예컨대 “계산이 맞는가?”라는 기준은 “최종 값이 특정 값과 일치하는가?”처럼 검증 가능한 문장으로 변환된다. 이때 보조 에이전트가 문구 정제에 사용되지만, 최종 루브릭과 기준 출력은 사람이 교차 검증한다.
각 태스크에는 file dependency graph가 붙는다. 이 그래프는 정답을 만들기 위해 접근해야 할 최소 파일 경로와 파일 간 방향 관계를 나타낸다. 단순히 어떤 파일을 열었는지와 함께, 어떤 파일이 어떤 결과 파일 또는 중간 산출물의 근거가 되었는지를 평가할 수 있게 한다.
논문이 제시한 설계 원칙은 네 가지다. 첫째, 현실적인 관계형 워크스페이스를 만들 것. 둘째, 독립 파일 대신 의존성 중심의 reasoning을 요구할 것. 셋째, 실제 업무 시나리오에서 출발한 진짜 주석을 사용할 것. 넷째, 최종 결과와 함께 중간 결정과 파일 선택 과정을 보는 process-aware evaluation을 제공할 것이다.
이 접근은 벤치마크의 해석 가능성을 높인다. 예를 들어 어떤 에이전트가 최종 보고서를 만들었지만 최신 버전이 아닌 report_v1을 사용했다면, 단순 BLEU나 exact match는 이를 잡아내기 어렵다. 반면 파일 의존성 그래프와 과정 루브릭은 잘못된 근거를 사용한 성공처럼 보이는 실패를 별도로 포착할 수 있다.
3.1 합성 워크스페이스가 현실성을 얻는 조건
합성 벤치마크가 설득력을 얻으려면 파일 내용이 그럴듯한 수준을 넘어, 태스크를 해결하는 데 실제로 필요한 구조적 제약을 가져야 한다. Workspace-Bench는 공개 자료를 먼저 수집하고, 그 자료를 바탕으로 파생 문서와 커뮤니케이션 파일을 생성한다. 이 순서는 중요하다. 근거 없는 합성 문서는 표면적으로 자연스러워도, 파일 간 추적 가능한 관계를 만들기 어렵기 때문이다.
전문가 검증은 생성 데이터의 가장 취약한 지점을 보완한다. 폴더 구조가 직무와 맞는지, 파일 내용이 경로와 어울리는지, 태스크 요청이 실제 업무처럼 모호하면서도 해결 가능한지, 루브릭이 판정 가능한지 확인한다. 이런 수작업 단계가 들어가야 벤치마크가 단순 프롬프트 모음에서 장기 실행 평가 환경으로 확장된 구조이 된다.
논문의 설계는 데이터 구축 비용도 숨기지 않는다. 비교 표에서 Workspace-Bench는 2,500시간 이상의 labeling time을 사용한 것으로 표시된다. 이는 대규모 에이전트 벤치마크가 점점 데이터셋 작성보다 평가 환경 공학에 가까워지고 있음을 보여준다. 파일 구조, 샌드박스, 주석, 루브릭, 복구 스크립트가 모두 품질을 결정한다.
아래 표는 논문에서 설명한 구축 흐름을 단계별로 재정리한 것이다. 이 표를 보면 Workspace-Bench의 핵심이 “많은 파일” 그 자체보다, 파일을 업무 시나리오와 루브릭으로 연결하는 주석 체계에 있음을 확인할 수 있다.
Table 3. Workspace-Bench 구축 파이프라인 요약
| 단계 | 주요 작업 | 품질 통제 포인트 |
|---|---|---|
| 페르소나 정의 | 직무 책임, 작업 흐름, 파일 사용 패턴, 도메인 용어를 정의 | 직무별 폴더 구조와 태스크 유형이 구분되는지 확인 |
| 구조 생성 | 트리형 디렉터리와 중첩 폴더, 아카이브, 임시 폴더 생성 | 실제 업무 폴더처럼 깊이와 노이즈를 갖는지 검토 |
| 콘텐츠 수집 | 공개 문서, 코드, 논문, 표, 발표 자료를 의미 기반으로 수집 | 파일 내용이 폴더명과 업무 맥락에 맞는지 확인 |
| 근거 기반 합성 | 이메일, 회의록, 파생 보고서, 요약 자료를 생성 | 합성 파일이 기존 파일과 의미 관계를 갖는지 검증 |
| 태스크 주석 | 자연어 요청, 기준 출력, 의존성 그래프, 루브릭을 작성 | 정답 가능성, 모호성, 평가 가능성을 전문가가 교차 검토 |
| 루브릭 정제 | 모호한 기준을 검증 가능한 단언으로 변환 | Agent-as-a-Judge가 실제 파일 근거로 판단 가능한지 확인 |
Figure 3: Workspace-Bench의 데이터 수집 및 큐레이션 파이프라인.
이 그림은 벤치마크 구축이 단일 LLM 생성으로 끝나지 않음을 보여준다. 페르소나 기반 폴더 구조를 먼저 만들고, 공개 자료 수집과 근거 기반 합성을 결합한 뒤, 사람이 태스크·의존성·루브릭을 주석한다. 마지막 전문가 검증은 현실성, 일관성, 평가 가능성을 동시에 점검하는 관문 역할을 한다. 이 단계 덕분에 생성 데이터의 무작위성이 줄고 재현성도 높아진다. 특히 공개 자료 수집과 근거 기반 합성이 먼저 이루어진 뒤 전문가 주석이 붙기 때문에, 태스크가 파일 구조와 느슨하게 연결되는 문제를 줄이고 평가 가능한 의존성 체인을 만들 수 있다.
4. 실험 설정: 태스크, 의존성 그래프, 루브릭 구성
Workspace-Bench의 388개 태스크는 모두 자연어 요청으로 제시된다. 하지만 요청은 일부러 완전히 친절하지 않다. 사용자가 실제 업무에서 “지난 분기 자료와 회의록을 반영해 전략 보고서를 만들어 달라”고 말하듯, 태스크는 필요한 파일 경로를 전부 열거하지 않는다. 에이전트는 폴더를 탐색해 관련 파일을 찾아야 한다.
논문은 태스크 난이도를 Easy, Medium, Hard로 나눈다. Easy는 주로 워크스페이스 탐색과 결과 제공 파일 활용이 중심인 작업이다. Medium은 태스크 지원 파일과 내용 관계 이해가 중요하다. Hard는 이질 파일 이해와 계보 추적이 포함된다. 즉 난이도는 작업 길이와 함께 필요한 파일 관계의 복잡도와 연결된다.
여섯 능력 차원은 multi-label로 붙는다. 하나의 태스크가 탐색, 지원 파일 활용, 결과 파일 활용, 내용 관계, 이질 파일 이해, 계보 추적을 동시에 요구할 수 있다. 논문에 따르면 Workspace Exploration은 262개 태스크, Task-Supporting Files Utilization은 238개, Result-Providing Files Utilization은 211개에 등장한다.
나머지 세 능력도 중요하다. Content Relations Understanding은 170개 태스크, Semantic Heterogeneous File Understanding은 140개, Lineage Tracing은 136개에 등장한다. 특히 이질 파일 이해와 계보 추적은 실험에서 반복적으로 하위 성능을 보이는 영역이므로, 벤치마크의 가장 날카로운 진단 축으로 볼 수 있다.
파일 의존성은 그래프 $G_t=(V_t,E_t)$로 이해할 수 있다. 여기서 $V_t$는 태스크 $t$를 해결하는 데 필요한 파일 노드이고, $E_t$는 파일 간 의존 관계다. 예컨대 한 슬라이드가 특정 스프레드시트에서 만들어졌고, 그 스프레드시트가 원본 CSV와 회의록의 해석에 의존한다면, 그 관계가 방향 간선으로 표현된다.
논문은 의존성 간선 수에 따라 edge density도 해석한다. 0~2개 간선은 Low, 3~5개는 Moderate, 6개 이상은 High로 본다. Low가 33.8%, Moderate가 36.9%, High가 29.4%다. 평균 5.1개 간선이라는 숫자는 많은 태스크가 단순 파일 합치기보다 관계 추적을 요구한다는 뜻이다.
루브릭은 크게 세 유형이다. Result-oriented 루브릭은 최종 산출물의 정확성과 완전성을 본다. Foundation 루브릭은 파일명, 형식, 저장 위치, 기본 요구사항 준수를 확인한다. Process-oriented 루브릭은 올바른 파일을 찾았는지, 최신 버전을 사용했는지, 필요한 중간 과정을 거쳤는지를 평가한다.
7,399개 루브릭 중 Result-oriented가 54.8%, Foundation이 25.0%, Process-oriented가 20.2%다. 이 비율은 논문이 최종 품질을 가장 크게 보면서도, 기본 형식과 과정 판단을 따로 떼어 실패 원인을 분석할 수 있게 설계했음을 보여준다. 실제 업무에서는 산출물의 내용, 형식, 근거가 모두 중요하기 때문이다.
대표 예시로 논문은 글로벌 시장 제품 전략을 생성하는 운영 매니저 태스크를 보여준다. 이 작업은 9개 핵심 파일을 식별하고, 시장·제품·물류 데이터를 다차원적으로 합성해야 한다. 최종 출력은 25개 루브릭으로 평가되며, 그중 2개는 foundation, 21개는 result, 2개는 process 항목이다.
이 구조는 에이전트 실패를 더 세밀하게 읽게 해준다. 어떤 시스템은 필요한 파일을 잘 찾았지만 계산에서 실패할 수 있고, 어떤 시스템은 답을 그럴듯하게 만들지만 근거 파일을 빠뜨릴 수 있다. 또 어떤 시스템은 결과 형식은 맞지만 오래된 버전을 참조할 수 있다. Workspace-Bench는 이 차이를 루브릭과 그래프로 분해한다.
4.2 의존성 그래프가 만드는 과정 평가
의존성 그래프는 Workspace-Bench를 일반 문서 QA와 갈라놓는 핵심 장치다. 최종 문서가 좋아 보여도, 정답 그래프의 핵심 노드를 찾지 못했다면 그 산출물은 우연히 맞았거나 근거가 불완전한 결과로 볼 수 있다. 반대로 일부 문장 점수는 낮더라도 정답 파일과 관계를 대부분 찾은 에이전트는 검색·탐색 모듈 측면에서 개선 가능성이 높다.
그래프 기반 평가는 디버깅에도 유용하다. Node F1이 낮으면 파일 탐색, 인덱싱, 경로 추론, 파일명 해석 문제가 의심된다. Node F1은 높지만 Edge F1이 낮으면 파일을 찾은 뒤 관계를 해석하는 단계, 즉 최신성 판단, 파생 파일 구분, 표와 보고서의 연결, 회의록과 요구사항의 매핑에서 실패했을 가능성이 크다. 이런 분리는 하네스 개선 방향을 더 명확히 만든다.
또한 루브릭은 그래프를 사람이 읽을 수 있는 평가 문장으로 바꾼다. 파일 의존성은 구조적 정답이고, 루브릭은 사용자가 기대한 결과의 부분 조건이다. 두 층이 함께 있을 때, 에이전트가 근거를 찾았지만 표현에 실패했는지, 근거를 놓친 상태에서 그럴듯하게 작성했는지, 형식 요구를 어겼는지 구분할 수 있다.
Table 4. 태스크 분포와 능력 차원의 핵심 수치
| 항목 | 수치 | 의미 |
|---|---|---|
| Operations Manager | 122 tasks, 31% | 시장, 운영, 전략 문서 통합이 많음 |
| Logistics Manager | 115 tasks, 30% | 재고, 배송, 표 기반 의사결정이 중심 |
| Researcher | 67 tasks, 17% | 논문, 실험, 표, 스크립트 연계가 중요 |
| Backend Developer | 43 tasks, 11% | 코드, 테스트, 설정, 문서 변경을 함께 다룸 |
| AI Product Manager | 41 tasks, 11% | 요구사항, 사용자 조사, 전략 자료 연결이 필요 |
| Easy / Medium / Hard | 14% / 53% / 33% | 중간 난이도가 가장 많고 Hard도 큰 비중을 차지 |
| 주요 능력 | 탐색 262, 지원 파일 238, 결과 파일 211 | 다수 태스크가 파일 발견과 근거 통합을 동시에 요구 |
| 고난도 능력 | 내용 관계 170, 이질 파일 140, 계보 136 | 실험에서 에이전트가 가장 취약한 축으로 관찰됨 |
Figure 4: 워크스페이스 구성과 태스크 분포, 능력 차원 및 난이도 분포.
이 그림은 파일 형식, 직무별 워크스페이스, 태스크 능력, 난이도가 어떻게 분포하는지 한 화면에 보여준다. 문서와 스프레드시트가 큰 비중을 차지하지만 코드·설정·이메일·이미지·통계 파일도 포함된다. 또한 태스크가 하나의 능력에 고정되지 않고 여러 능력 차원을 동시에 요구한다는 점이 드러난다. 분포 자체가 실제 업무의 혼합성과 불균형을 반영하며 태스크 설계의 편향도 확인하게 한다. 파일 형식과 태스크 난이도의 불균형이 함께 표시되기 때문에, 특정 조합의 성능을 볼 때 어떤 직무와 어떤 파일 형식에서 점수가 나왔는지 따로 확인해야 한다.
Figure 5: 운영 매니저 워크스페이스에서 가져온 대표 태스크 예시.
이 예시는 자연어 요청, 필요한 파일, 의존성 그래프, 루브릭이 어떻게 연결되는지 보여준다. 에이전트는 명시된 경로만 따라가면 되는 수준을 넘어 시장 자료, 제품 정보, 물류 데이터 등 여러 파일을 찾아 종합해야 한다. 루브릭은 최종 전략 문서의 내용과 파일 선택 과정 모두를 평가한다. 그래서 겉보기 문서 완성도와 근거 충실도를 분리해 볼 수 있고 감사 가능성도 높인다. 이 예시가 중요한 이유는 최종 답변 텍스트보다 어떤 파일을 사용했고 어떤 파일 관계를 따라갔는지가 점수에 직접 반영된다는 점이며, 실제 사무 자동화의 검수 절차와도 맞닿아 있다.
4.1 평가 프레임워크: 샌드박스 실행, 결과 수집, 복구, Agent-as-a-Judge
Workspace-Bench는 데이터셋만 제공하지 않고, 에이전트를 실행하고 결과를 채점하기 위한 평가 프레임워크를 함께 설계한다. 실제 에이전트 평가는 느리고 비싸며, 파일을 변경하고 예측 불가능한 경로에 산출물을 저장하기 때문에, 실행 환경 관리와 결과 회수가 벤치마크의 핵심 요소가 된다.
평가의 첫 단계는 에이전트 초기화다. 각 에이전트 구성은 통합 YAML 설정으로 선언되고, Inference Manager가 태스크를 스케줄링한다. 이후 Sandbox Pool에서 해당 직무 워크스페이스의 격리 복제본을 할당한다. 에이전트는 이 샌드박스 안에서만 파일을 읽고 쓰며 태스크를 수행한다.
두 번째 핵심은 병렬화다. 논문은 워크스페이스 수준과 태스크 수준의 이중 병렬화를 사용한다. 다섯 사용자 프로필 워크스페이스를 독립적으로 운용해 5배에 가까운 처리량을 얻고, 같은 워크스페이스의 복제 이미지를 여러 개 만들어 태스크 단위로도 병렬 실행한다. 비용이 큰 에이전트 평가에서 이 설계는 매우 실용적이다.
세 번째는 결과 파일 추출이다. 실제 에이전트는 산출물을 항상 같은 위치에 저장하지 않는다. 논문은 세 전략을 병렬로 쓴다. 첫째, 최종 응답에서 결과 경로를 명시하게 한다. 둘째, 지정된 중앙 디렉터리에 복사본을 저장하게 한다. 셋째, 태스크 메타데이터의 예상 파일명과 특징으로 전체 샌드박스를 fuzzy search한다.
네 번째는 워크스페이스 복구다. 태스크가 끝난 뒤 샌드박스는 baseline snapshot과 비교된다. 논문은 병렬 BFS 방식으로 디렉터리 트리를 비교하고, 빠진 파일은 복사하고, 새로 생긴 불필요한 파일은 삭제하며, 해시가 다른 수정 파일은 원본으로 되돌린다. 이 복구 없이는 한 태스크의 흔적이 다음 태스크 평가를 오염시킬 수 있다.
채점은 Agent-as-a-Judge 방식이다. Judge agent는 후보 에이전트의 출력 파일, 원 입력 파일, 루브릭, 실행 궤적을 받아 각 루브릭의 만족 여부를 이진 점수로 판단한다. 또한 오류 유형, 근거, confidence를 기록한다. 의존성 그래프 인식률을 계산할 때는 실행 궤적에서 예측 그래프를 추출해 ground truth 그래프와 비교한다.
주요 성능 지표는 다섯 가지다. 첫째, Rubric Pass Rate는 전체 루브릭 중 통과한 비율이며 $R_{acc}=N_{passed}/N_{total}$로 볼 수 있다. 둘째, Task Completion Rate는 한 태스크의 루브릭 통과율이 특정 임계값 이상인 태스크 비율이다. 예를 들어 TCR@70은 루브릭의 70% 이상을 만족한 태스크의 비율이다.
셋째, Dependency Graph Recognition Rate는 예측한 파일 노드와 간선이 정답 그래프와 얼마나 일치하는지를 F1로 계산한다. 여기서 흥미로운 점은 파일 노드 식별과 파일 간 간선 식별을 분리해서 볼 수 있다는 것이다. 실험에서는 노드보다 간선이 훨씬 어렵게 나타난다.
넷째, 평균 토큰 소비량은 한 태스크를 수행하는 데 사용한 입력과 출력 토큰의 평균이다. 다섯째, 평균 턴 수는 도구 호출, 대화 라운드, 계획 및 실행 반복의 수를 나타낸다. 논문은 성능과 함께 추론 효율성도 함께 보며, 비용이 큰 에이전트가 반드시 더 좋은 결과를 내지는 않는다는 점을 강조한다.
평가 프레임워크를 읽을 때 주의할 점은 Judge 자체도 에이전트라는 사실이다. 논문은 엄격한 프롬프트와 파일 근거 기반 판정을 사용하지만, Agent-as-a-Judge는 여전히 판정 모델의 한계를 갖는다. 그럼에도 7천 개가 넘는 루브릭을 사람이 모두 반복 채점하는 비용을 고려하면, 이 방식은 대규모 평가의 현실적 절충안이다.
4.2 실행 환경이 점수에 미치는 영향
샌드박스 평가는 Workspace-Bench에서 부수 기능이 아니다. 에이전트가 파일을 실제로 수정하고 결과물을 저장하기 때문에, 이전 태스크의 부산물이 다음 태스크에 남으면 점수가 오염된다. 논문이 baseline snapshot, 해시 비교, 불필요 파일 삭제, 수정 파일 복원을 평가 프레임워크에 포함한 이유는 이 실행 환경의 상태 관리가 평가 신뢰성을 좌우하기 때문이다.
결과 파일 추출도 난도가 높다. 에이전트가 최종 답변에 경로를 적지 않거나, 지정 폴더 대신 하위 폴더에 저장하거나, 파일명을 조금 바꾸면 채점기가 산출물을 놓칠 수 있다. 논문은 직접 경로, 중앙 디렉터리, 전체 샌드박스 검색을 함께 사용해 이 문제를 줄인다. 이는 실제 업무 에이전트 제품에서도 결과물 회수와 provenance 저장이 중요하다는 신호다.
Table 5. Workspace-Bench 평가 지표와 해석
| 지표 | 정의 | 진단하는 능력 |
|---|---|---|
| Rubric Pass Rate | $R_{acc}=N_{passed}/N_{total}$ | 전체 부분 기준을 얼마나 많이 만족했는지 |
| TCR@p | 루브릭 통과율이 $p$ 이상인 태스크 비율 | 태스크 단위 완성도와 엄격한 성공률 |
| Node F1 | 예측 파일 노드와 정답 노드의 F1 | 필요한 파일을 찾아냈는지 |
| Edge F1 | 예측 파일 의존성 간선과 정답 간선의 F1 | 파일 간 관계와 파생 관계를 이해했는지 |
| Average Tokens | 태스크당 입력·출력 토큰 평균 | 비용 효율성과 retry loop 여부 |
| Average Turns | 태스크당 상호작용 또는 실행 단계 평균 | 장기 실행 안정성과 계획 효율성 |
Figure 6: Workspace-Bench 평가 프레임워크의 실행과 채점 흐름.
이 그림은 태스크 배정, 샌드박스 실행, 결과 파일 추출, 워크스페이스 복구, 루브릭 채점이 이어지는 전체 평가 파이프라인을 도식화한다. 평가가 단순 API 호출을 넘어 파일 시스템을 실제로 변경하는 실행 실험이기 때문에, 복제 환경과 롤백, 다중 결과 추출 전략이 신뢰성의 핵심 요소로 배치된다. 이는 재현 가능한 에이전트 실험의 운영 기반이며 반복 평가 품질도 좌우한다. 특히 결과 파일 추출과 워크스페이스 복구가 별도 단계로 표시되므로, 에이전트 평가에서 환경 상태 관리가 모델 호출만큼 중요하다는 점을 확인할 수 있다.
5. 주요 실험 결과: 4개 하네스와 7개 모델이 보여준 68%의 벽
실험은 Workspace-Bench-Lite 100개 태스크를 중심으로 진행된다. 비교 대상은 네 개 하네스와 일곱 개 foundation model의 조합이다. 하네스는 OpenClaw, ClaudeCode, DeepAgent, Hermes이며, 모델은 Opus-4.7, GLM-5.1, Gemini-3.1-Pro, GPT-5.4, Kimi-2.5, MiniMax-M2.7, Seed-2.0-Code다.
OpenClaw는 고수준 계획과 저수준 도구 호출을 분리하는 dual-loop 실행 구조를 사용한다고 설명된다. 논문은 이 구조가 장기 작업에서 deadlock을 줄이고, 구조화 지식 저장과 semantic routing을 통해 컨텍스트 망각을 완화한다고 본다. 실험상 OpenClaw는 Opus-4.7과 결합했을 때 최고권 성능을 낸다.
ClaudeCode는 Anthropic의 개발·워크스페이스 지향 하네스로 소개된다. MCP와 skill을 활용하고, 긴 컨텍스트를 다루기 위해 정적 프로젝트 지시와 동적 압축을 함께 사용한다. 특히 연구자와 개발자 페르소나에서 강한 모습을 보이며, Opus-4.7 결합에서는 전체 66.6으로 OpenClaw와 거의 비슷한 상위권이다.
DeepAgent는 LangGraph 기반의 white-box 하네스로, task decomposition과 명시적 파일 I/O, planning tool을 통해 실행 경로를 추적 가능하게 만든다. 흥미롭게도 DeepAgent+GLM-5.1은 전체 62.3으로 매우 안정적이다. 반면 DeepAgent+Opus-4.7은 성능은 높지만 토큰과 턴 수가 커지는 비용 문제가 관찰된다.
Hermes는 MCP, 서브에이전트 orchestration, 다층 메모리, skill library 기반 학습 루프를 갖춘 하네스로 설명된다. Hermes+Opus-4.7은 Easy 68.6, Medium 66.9, Hard 63.1, Total 66.0으로 난이도 상승에도 비교적 완만하게 하락한다. 이는 파일 탐색과 상태 관리에서 일부 장점이 있음을 시사한다.
전체 평균 Rubrics Pass Rate는 47.4%다. 최고 조합은 논문 요약에서는 약 68%대, 상세 표에서는 OpenClaw+Opus-4.7의 Total 67.7로 나타난다. 인간 전문가가 에이전트를 보조 도구로 사용한 기준선은 80.7%다. 즉 최고 에이전트조차 인간 협업 기준선과 두 자릿수 격차를 보인다.
난이도별 평균도 중요하다. Easy는 57.6%, Medium은 49.2%, Hard는 40.5%다. 쉬운 태스크에서는 파일 몇 개의 요약이나 간단한 편집이 가능하지만, Hard로 갈수록 동적 파일 관계 발견, 장기 계획, 중간 상태 추적, 오류 회복, 최신 버전 구분이 필요해진다. 이때 하네스와 모델의 약점이 동시에 드러난다.
상위 세 조합은 모두 Opus-4.7을 사용한다. OpenClaw+Opus-4.7은 Easy 80.0, Medium 67.3, Hard 62.5, Total 67.7이다. ClaudeCode+Opus-4.7은 Total 66.6이고, Hermes+Opus-4.7은 Total 66.0이다. 하지만 Pass@100은 각각 24.0, 17.0, 18.0에 그친다. 엄격한 완전 성공은 여전히 어렵다.
Pass@30, Pass@50, Pass@70, Pass@90, Pass@100의 하락은 루브릭 기반 평가의 장점을 보여준다. 어떤 에이전트가 부분적으로는 꽤 잘 수행해도, 모든 기준을 완벽히 만족하는 태스크는 급격히 줄어든다. 실제 업무에서 “대체로 맞는 보고서”와 “검수 없이 제출 가능한 보고서”가 다르다는 점과 같다.
아래 표는 논문 부록의 상세 결과 중 상위권 및 비교에 중요한 행을 뽑아 재작성한 것이다. 모든 28개 조합을 싣지는 않았지만, 하네스와 모델 선택이 난이도별 성능 및 엄격한 태스크 완료율에 어떤 영향을 주는지 읽을 수 있다.
Table 6. 주요 에이전트 조합의 상세 성능
| Harness + Model | Easy | Medium | Hard | Total | Pass@30 | Pass@50 | Pass@70 | Pass@90 | Pass@100 |
|---|---|---|---|---|---|---|---|---|---|
| OpenClaw + Opus-4.7 | 80.0 | 67.3 | 62.5 | 67.7 | 90.0 | 71.0 | 51.0 | 36.0 | 24.0 |
| ClaudeCode + Opus-4.7 | 77.7 | 68.0 | 58.6 | 66.6 | 87.0 | 76.0 | 49.0 | 31.0 | 17.0 |
| Hermes + Opus-4.7 | 68.6 | 66.9 | 63.1 | 66.0 | 89.0 | 72.0 | 48.0 | 25.0 | 18.0 |
| DeepAgent + GLM-5.1 | 63.0 | 62.5 | 61.6 | 62.3 | 84.0 | 63.0 | 45.0 | 29.0 | 16.0 |
| 평균 전체 조합 | 57.6 | 49.2 | 40.5 | 47.4 | - | - | - | - | - |
5.1 최고 점수보다 엄격한 완료율을 함께 봐야 하는 이유
상위권 평균 점수만 보면 현재 에이전트가 이미 복잡한 사무 태스크를 상당히 처리하는 것처럼 보일 수 있다. 그러나 Pass@90과 Pass@100을 보면 다른 그림이 나온다. OpenClaw+Opus-4.7도 Pass@100은 24.0에 머물고, ClaudeCode+Opus-4.7은 17.0, Hermes+Opus-4.7은 18.0이다. 루브릭 대부분을 만족하는 부분 성공과 모든 조건을 만족하는 완전 성공 사이에는 큰 간격이 있다.
이 차이는 실무 배포에서 매우 중요하다. 자동으로 보고서를 제출하거나 고객 파일을 갱신하는 환경에서는 70% 루브릭 성공률만으로 충분하지 않다. 누락된 30%가 핵심 규정 준수 항목, 최신 수치, 고객명, 산출물 저장 위치, 보안 검토일 수 있기 때문이다. Workspace-Bench의 TCR@p 지표는 이 위험을 평균 점수 뒤에 숨기지 않게 해준다.
따라서 논문 결과를 읽을 때는 Total, Pass@70, Pass@100을 함께 보는 편이 안전하다. Total은 일반적인 품질을 보여주고, Pass@70은 부분 완성 태스크의 규모를 보여주며, Pass@100은 검수 없는 자동 제출 가능성에 가깝다. 세 값의 차이가 클수록 사람 검수나 후처리 rule이 더 많이 필요하다.
이 표에서 특히 주목할 점은 Hermes+Opus-4.7의 Hard 성능이 63.1로 OpenClaw+Opus-4.7의 Hard 62.5보다 약간 높다는 것이다. 반면 OpenClaw는 Easy에서 80.0으로 매우 강하고 Total 67.7로 전체 1위권이다. ClaudeCode는 Medium 68.0과 Pass@50 76.0이 높아 중간 난이도 안정성이 두드러진다.
DeepAgent+GLM-5.1은 Total 62.3으로 상위권이지만 더 흥미로운 것은 난이도별 편차가 작다는 점이다. Easy 63.0, Medium 62.5, Hard 61.6으로 거의 평평하다. 논문은 GLM-5.1이 DeepAgent의 instruction-following 구조와 잘 맞는 시스템 시너지를 보인다고 해석한다.
6. 추가 분석 및 Ablation Study: 난이도, 의존성 인식, 비용 효율성
논문의 세부 분석은 다섯 finding으로 정리된다. 첫째, 에이전트는 난이도가 높아질수록 일관되게 하락한다. 둘째, 여섯 능력 중 세 축이 병목이다. 셋째, 직무 페르소나별로 하네스와 모델의 편차가 다르다. 넷째, 많은 턴과 많은 토큰이 좋은 성능을 보장하지 않는다. 다섯째, 인간 전문가와 에이전트 협업은 완전 자율 에이전트를 여전히 크게 앞선다.
난이도별 하락은 가장 직관적이다. Easy 57.6에서 Medium 49.2, Hard 40.5로 내려간다. Easy에서는 단순 검색과 일부 파일 편집만으로도 점수를 얻을 수 있지만, Hard에서는 계보 관계, 이질 파일 파싱, 장기 상태 유지, 중간 결과 검증이 필요하다. 이는 base LLM의 추론력과 하네스 orchestration이 동시에 시험받는 구간이다.
논문은 같은 LLM이라도 하네스가 달라지면 능력 분포가 바뀐다고 관찰한다. 예컨대 GLM-5.1은 DeepAgent에서는 여러 워크스페이스 능력에서 비교적 고르게 분포하지만, Hermes에서는 분산이 커질 수 있다. 이는 하네스가 단순 wrapper에 머물지 않고, 모델의 탐색 전략과 상태 관리 방식을 실제로 재구성한다는 의미다.
능력 축에서 특히 약한 것은 Heterogeneous File Understanding과 Lineage Tracing이다. OpenClaw+Opus-4.7은 일부 탐색 능력에서 높은 성능을 보이지만, 이질 파일 이해에서는 약 20% 수준으로 떨어지는 사례가 보고된다. 이는 파일을 찾는 능력과 파일 내용을 올바른 형식으로 해석하고 연결하는 능력이 다르다는 점을 보여준다.
의존성 그래프 분석도 같은 결론을 강화한다. Node F1은 Edge F1보다 높다. 즉 에이전트는 “어떤 파일이 관련 있는지”는 어느 정도 찾지만, “그 파일이 다른 파일과 어떤 생성·참조·의미 관계를 갖는지”는 훨씬 더 자주 틀린다. 실제 업무에서는 이 차이가 최신 보고서와 오래된 초안의 혼동, 표와 슬라이드의 불일치로 이어진다.
직무 페르소나별 결과에서는 Backend Developer와 Researcher에서 상대적으로 높은 성능이 나온다. 코드 실행, 구조적 데이터, 논문·실험 자료는 도구 사용과 명시적 근거 추적이 비교적 잘 맞기 때문이다. 반면 Product Manager와 Operations Manager는 전략적 판단, 모호한 요구, 여러 부서 자료의 의미 통합이 필요해 평균 성능이 낮아지는 경향이 있다.
비용 분석은 특히 실무적으로 중요하다. 논문은 평균 토큰 소비량이 550.7K이고 평균 턴 수가 36.6이라고 보고한다. DeepAgent+Opus-4.7은 거의 60턴에 가까우며, DeepAgent+Opus-4.7과 OpenClaw+Kimi-2.5는 태스크당 1M 토큰을 넘는다. 그런데 이런 높은 비용이 항상 최고 성능으로 이어지지는 않는다.
실패 유형은 크게 Constraint Error, Missing Content, Reasoning Error, Process Error, Format Error로 나뉜다. 논문은 실패 루브릭에서 Missing Content와 Reasoning Error가 다수를 차지한다고 본다. 이는 에이전트가 기본 형식은 어느 정도 맞추지만, 깊은 폴더 안의 핵심 근거를 놓치거나 여러 파일의 수치를 잘못 결합하는 경우가 많다는 뜻이다.
인간 기준선은 단순 수동 작업 조건이 아니라 20명의 도메인 전문가가 에이전트를 보조 도구로 사용할 수 있는 human-in-the-loop 설정이다. 이 조건에서 80.7%가 나온다. 논문은 인간 성능이 난이도 상승에도 크게 하락하지 않는다고 해석한다. 사람은 파일 사이의 숨은 관계를 유연하게 추론하고, 모호한 업무 요청을 재구성할 수 있기 때문이다.
Table 7. 성능 외 비용 및 병목 신호
| 관찰 항목 | 논문이 보고한 신호 | 해석 |
|---|---|---|
| 평균 토큰 소비 | 태스크당 550.7K | 워크스페이스 태스크는 짧은 벤치마크보다 훨씬 비싸다 |
| 평균 턴 수 | 36.6 turns | 장기 실행에서 상태 유지와 종료 판단이 중요하다 |
| 고비용 조합 | DeepAgent+Opus-4.7, OpenClaw+Kimi-2.5가 1M 토큰 초과 | 더 많은 탐색이 항상 더 좋은 답을 보장하지 않는다 |
| 고턴 조합 | DeepAgent+Opus-4.7이 거의 60턴 | 계획 투명성은 높지만 비용과 지연이 커질 수 있다 |
| 주요 오류 | Missing Content, Reasoning Error가 다수 | 파일 발견 실패와 cross-file 계산 실패가 핵심 병목이다 |
| 인간 협업 | Human-in-the-loop 80.7% | 복잡한 업무에서는 검수와 의사결정 개입이 아직 필수적이다 |
Figure 7: 에이전트 구성별 루브릭 성공률과 난이도별 성능 비교.
이 그림은 Easy, Medium, Hard로 갈수록 대부분 조합의 루브릭 성공률이 내려가는 패턴을 보여준다. Opus-4.7 기반 상위 조합은 하락폭이 작지만, 일부 모델과 하네스 조합은 Hard에서 급격히 무너진다. 난이도는 단순 라벨보다 파일 관계 발견과 장기 계획 부담을 반영한다. 특히 Hard 성능은 배포 전 검수 강도를 정하는 데 유용하다. 따라서 평균 점수만 보면 놓치기 쉬운 난이도별 실패 경사를 확인할 수 있고, Hard 태스크 성능은 실제 배포에서 사람 승인과 후속 검증을 얼마나 강하게 둘지 판단하는 근거가 된다.
Figure 8: 에이전트 구성별 의존성 그래프 노드와 간선 인식률 비교.
이 그림은 관련 파일 노드를 찾는 것보다 파일 간 의존성 간선을 맞히는 일이 더 어렵다는 점을 분명히 보여준다. 노드 F1이 상대적으로 높더라도 Edge F1은 낮게 나타나는 경우가 많다. 이는 현재 에이전트가 파일 존재는 발견하지만, 파생·참조·의미 연결을 안정적으로 모델링하지 못함을 뜻한다. 업무 자동화에서는 이 간선 실패가 설명 가능성 저하로 이어진다. 이 결과는 검색 인덱스가 관련 파일을 잘 찾아도 충분하지 않으며, 파일 간 파생·참조·버전 관계를 별도 구조로 표현하고 검증하는 하네스 설계가 필요하다는 점을 보여준다.
Figure 9: 여섯 가지 워크스페이스 학습 능력별 TCR@70 비교.
이 그림은 탐색과 결과 파일 활용보다 이질 파일 이해와 계보 추적이 더 낮은 성능을 보인다는 점을 능력 차원별로 보여준다. 특히 강한 모델을 사용해도 파일 형식이 섞이고 버전 관계가 들어가면 정확도가 떨어진다. 이는 에이전트 개선이 검색 정확도만으로 끝나지 않고 파일 변환, 표 구조 복원, 버전 판단, 관계 추론까지 포함해야 함을 의미한다. 특히 능력 차원별 분해는 평균 점수 뒤에 숨은 병목을 보여 주므로, 하네스 개선에서 어떤 파서와 어떤 관계 추론 모듈을 먼저 손봐야 하는지 결정하는 기준이 된다.
Figure 11: 평균 턴 수, 평균 루브릭 정확도, 토큰 소비량의 관계.
이 산점도는 오래 실행하고 많은 토큰을 쓴 구성이 항상 높은 정확도를 내지 못함을 보여준다. ClaudeCode+Opus-4.7과 Hermes+Opus-4.7은 상대적으로 적은 턴과 비용으로 높은 정확도를 보이는 반면, 일부 DeepAgent 조합은 많은 반복과 큰 토큰 비용에도 중간 성능에 머문다. 장기 에이전트에서는 탐색량보다 잘못된 루프를 빨리 끊는 능력이 중요하다. 이 그림은 비용 통제를 단순한 예산 문제를 넘어 품질 문제로 읽게 만든다. 잘못된 탐색 루프가 길어지면 토큰 비용뿐 아니라 산출물의 근거 일관성도 함께 나빠질 수 있다.
Figure 13: 실패한 루브릭에서 관찰된 오류 유형 비율.
오류 분석 그림은 실패가 단일한 형태로 나타나지 않음을 보여준다. Missing Content는 필요한 파일이나 근거 항목을 놓친 경우이고, Reasoning Error는 찾은 자료를 잘못 결합한 경우다. Format Error와 Process Error는 산출물 형식이나 절차 요구를 어긴 사례다. 이 분류 덕분에 모델 개선, 파일 검색 개선, 결과 검수 개선을 서로 다른 과제로 나눌 수 있다. 따라서 오류 유형을 기록하면 모델 교체, 검색 인덱스 보강, 파일 형식 파서 개선, 결과 형식 validator 추가 중 어느 조치가 필요한지 더 빠르게 좁힐 수 있다.
7. 한계점 및 향후 연구 방향: 벤치마크를 읽을 때 놓치지 말아야 할 것
Workspace-Bench의 가장 큰 장점은 현실적인 복잡성을 평가로 끌고 왔다는 점이지만, 동시에 그 복잡성은 한계이기도 하다. 실제 기업 워크스페이스는 개인정보, 권한, 사내 시스템, 실시간 업데이트, 비공개 문서, 사람 간 의사소통을 포함한다. 논문은 공개 자료 수집과 합성을 통해 이를 근사하지만, 완전한 실세계 복제는 아니다.
또한 Agent-as-a-Judge 방식은 확장성을 제공하지만, 판정 모델의 오류 가능성을 없애지는 않는다. 루브릭이 매우 구체적일수록 자동 채점은 안정적이지만, 전략 보고서의 질, 근거 정렬, 요약의 적절성 같은 항목은 여전히 판정 모델의 해석에 의존한다. 따라서 이 벤치마크 점수는 절대 진리라기보다 비교 가능한 진단 지표로 읽어야 한다.
Lite 100개 태스크의 비용 절감도 장단점이 있다. 약 70% 비용 감소는 빠른 리더보드와 하네스 실험에 적합하지만, 전체 388개 태스크가 제공하는 분포의 꼬리와 희귀 실패를 모두 포착하지는 못할 수 있다. 에이전트 제품을 실제 배포 전에 평가한다면 Lite로 빠르게 탐색하고, 중요한 조합은 Full로 재검증하는 식이 적절하다.
하네스 비교를 해석할 때도 주의가 필요하다. 논문은 네 하네스를 대표적으로 선택했지만, 각 하네스의 프롬프트, 도구 목록, 파일 파서, timeout, retry 정책, 메모리 정책은 성능에 큰 영향을 준다. 즉 결과는 백본 모델 성능과 함께 시스템 통합 품질의 평가이기도 하다.
모델 이름 자체보다 더 중요한 것은 실패 프로필이다. 어떤 조합은 Easy에서 강하고 Hard에서 급락한다. 어떤 조합은 평균은 낮지만 특정 페르소나에서 강하다. 어떤 조합은 높은 점수를 내지만 토큰 비용이 과도하다. 실무에서는 최고 평균 점수 하나보다, 자신이 맡길 업무 유형에 맞는 failure mode를 보는 것이 더 유용하다.
특히 파일 의존성 그래프 인식률은 제품 평가에서 강하게 참고할 만하다. 결과물이 그럴듯해도 어떤 파일을 근거로 했는지 설명하지 못하는 에이전트는 감사, 규정 준수, 재현성이 중요한 업무에 부적합하다. Workspace-Bench는 Node F1과 Edge F1을 분리해 이 문제를 드러내므로, 단순 pass rate보다 더 운영 친화적인 신호를 준다.
개발자 입장에서는 이 논문이 세 가지 구현 과제를 암시한다. 첫째, 파일 검색은 단순 키워드 검색을 넘어 role-aware index와 lineage-aware metadata가 필요하다. 둘째, 장기 실행 하네스는 무작정 컨텍스트를 늘리기보다 근거 압축과 상태 검증을 해야 한다. 셋째, 결과 생성 직전에는 사용한 파일과 최신성, 형식 요구를 별도 체크리스트로 재검사해야 한다.
연구자 입장에서는 Workspace-Bench가 앞으로 더 어려운 질문을 열어준다. 예컨대 멀티에이전트 협업이 파일 의존성 추적을 개선하는지, RAG 인덱스가 계보 관계를 잃지 않는지, 도구 사용 로그가 루브릭 채점의 근거로 얼마나 충분한지, self-learning 하네스가 반복 평가에서 실제로 향상되는지 등을 체계적으로 실험할 수 있다.
마지막으로, 이 벤치마크는 “에이전트가 어느 정도 사무 자동화를 할 수 있는가”보다 “에이전트에게 어떤 자동화를 맡기면 위험한가”를 판단하는 데 더 강하다. Missing Content와 Reasoning Error가 지배적인 실패 유형이라면, 자동화 파이프라인에는 결과 검수, 근거 표시, 파일 계보 확인, 인간 승인 단계를 반드시 넣어야 한다.
실무 적용 관점에서 첫 번째 체크포인트는 파일 인덱싱 정책이다. Workspace-Bench가 보여준 실패는 단순 검색 누락과 함께 최신성, 파생 관계, 지원 문맥을 놓치는 문제다. 따라서 기업 환경에서 에이전트를 붙일 때는 파일명, 경로, 생성일, 수정일, 작성자, 버전 태그, 참조 관계, 원본 데이터 출처를 함께 색인해야 한다. 텍스트 chunk만 저장하는 RAG는 계보 추적을 잃기 쉽다.
두 번째 체크포인트는 작업 전 계획의 검증이다. 에이전트가 바로 결과물을 만들기 전에 “필요하다고 판단한 파일 목록”과 “각 파일을 쓰는 이유”를 먼저 산출하게 하면, 사람이나 별도 검증 모듈이 잘못된 파일 선택을 조기에 잡을 수 있다. Workspace-Bench의 Node F1과 Edge F1은 이 사전 계획 품질을 수치화할 수 있는 좋은 후보 지표다.
세 번째 체크포인트는 출력 직전의 근거 재확인이다. 많은 실패가 Missing Content와 Reasoning Error로 나타난다면, 최종 답변 생성 직전에 사용한 수치, 표, 인용, 파일 버전을 다시 확인하는 단계가 필요하다. 이는 단순 self-reflection 문구보다 구체적이어야 한다. 예를 들어 각 주장마다 source file, row 또는 section, 변환 방식, 계산식을 명시하게 해야 한다.
네 번째 체크포인트는 파일 형식별 파서 품질이다. 논문은 74개 파일 형식을 포함하지만, 실제 조직에는 보안 문서, 스캔 PDF, 깨진 인코딩 CSV, 매크로가 포함된 Excel, 사내 템플릿 PPT가 더 많이 존재한다. 에이전트의 LLM 성능이 높아도 파서가 표 구조를 잃거나 이미지 안 텍스트를 놓치면 결과 품질은 급격히 떨어진다.
다섯 번째 체크포인트는 샌드박스와 권한 경계다. Workspace-Bench는 격리된 워크스페이스를 전제로 하지만, 실제 배포 환경에서는 읽기 권한, 쓰기 권한, 외부 네트워크, 개인정보 접근, 사내 API 호출이 섞인다. 평가 벤치마크 점수가 높더라도 권한 경계가 명확하지 않으면 에이전트는 잘못된 파일을 수정하거나 민감 정보를 결과물에 포함할 수 있다.
여섯 번째 체크포인트는 비용 상한과 종료 조건이다. 논문에서 일부 조합은 많은 턴과 토큰을 쓰면서도 낮은 정확도에 머문다. 이는 “더 오래 생각하면 나아진다”는 직관이 항상 맞지 않음을 보여준다. 실무 하네스에는 최대 탐색 파일 수, 최대 retry 횟수, 중간 검증 실패 시 중단, 비용 대비 기대 개선치 계산 같은 정책이 필요하다.
일곱 번째 체크포인트는 사람 검수 위치다. 인간 협업 기준선이 80.7%라는 결과는 사람이 모든 작업을 직접 해야 한다는 뜻이 아니다. 오히려 에이전트가 초안, 파일 후보, 근거 표, 계산 중간값을 빠르게 만들고, 사람이 의존성 선택과 최종 판단을 검수하는 hybrid workflow가 가장 현실적이라는 뜻으로 읽을 수 있다.
여덟 번째 체크포인트는 태스크 유형별 리더보드다. 평균 점수는 편리하지만, 조직의 업무는 균일하지 않다. 재무 정산, 코드 수정, 연구 요약, 물류 계획, 제품 전략은 실패 비용과 요구 능력이 다르다. Workspace-Bench의 페르소나와 능력 태그를 활용하면, 전체 평균 대신 특정 업무군에 맞춘 내부 리더보드를 만들 수 있다.
아홉 번째 체크포인트는 계보 추적의 제품화다. 실제 사무 환경에서 “final”, “final_v2”, “reviewed”, “approved”, “old” 같은 파일명은 흔하다. 에이전트가 파일명 패턴만 보고 최신성을 추정하면 위험하다. 문서 내부 날짜, 메타데이터, 참조 링크, 수정 이력, 사용자 승인 기록을 함께 읽어 계보 그래프를 구성해야 한다.
열 번째 체크포인트는 평가 로그의 감사 가능성이다. Workspace-Bench의 루브릭 채점은 큰 장점이지만, 조직에서 실제로 쓰려면 점수와 함께 왜 통과했는지, 어떤 파일을 봤는지, 어떤 파일을 보지 않았는지, 어떤 근거가 부족했는지가 남아야 한다. 이는 사후 책임 소재와 모델 개선 모두에 필요하다.
연구 확장 관점에서는 memory architecture 평가가 추가될 수 있다. 현재 결과는 하네스별 메모리와 컨텍스트 압축 정책이 성능에 영향을 준다는 점을 암시한다. 그러나 어떤 정보가 장기 메모리에 저장되어야 하는지, 어떤 정보는 태스크-local 상태로 남아야 하는지, 오래된 관찰을 어떻게 폐기해야 하는지는 별도 실험이 필요하다.
또 다른 확장 방향은 active clarification이다. 실제 업무에서 사람은 파일 관계가 모호하면 동료에게 묻거나, 승인권자에게 기준을 확인한다. 벤치마크 태스크가 완전 자율 실행을 전제로 할수록 이런 능력은 감춰진다. 후속 버전에서는 제한된 질문 예산을 주고, 어떤 질문을 해야 성능과 비용이 좋아지는지 평가할 수 있다.
세 번째 확장 방향은 collaborative workspace다. 현재 Workspace-Bench는 한 지식 노동자의 워크스페이스 학습에 초점을 둔다. 그러나 기업 업무는 여러 사람의 드라이브, 채팅, 승인 문서, 공유 폴더를 오간다. 파일 의존성 그래프에 사용자, 권한, 시간, 승인 상태를 추가하면 멀티유저 업무 자동화의 난이도를 더 현실적으로 반영할 수 있다.
네 번째 확장 방향은 temporal evaluation이다. 논문은 버전과 계보를 다루지만, 평가 자체가 시간이 흐르는 환경에서 반복되지는 않는다. 실제 워크스페이스는 매일 변하고, 어제의 정답 파일이 오늘은 폐기될 수 있다. 에이전트가 이전 실행에서 배운 지식을 갱신하고, 오래된 메모리를 무효화하는 능력을 별도로 재야 한다.
다섯 번째 확장 방향은 counterfactual robustness다. 특정 파일명을 바꾸거나, 오래된 초안을 추가하거나, 일부 표의 열 순서를 바꾸거나, 같은 내용의 PDF와 PPT를 동시에 넣었을 때 에이전트가 같은 결론을 유지하는지 확인할 수 있다. 이는 벤치마크 점수가 실제 환경의 사소한 변화에 얼마나 민감한지 보는 데 유용하다.
여섯 번째 확장 방향은 judge calibration이다. Agent-as-a-Judge가 대규모 평가를 가능하게 하지만, 판단 기준이 너무 관대하거나 너무 엄격하면 리더보드가 왜곡된다. 일부 태스크를 사람 채점 gold set으로 유지하고, judge의 confidence와 실제 일치율을 정기적으로 보정하면 루브릭 평가의 신뢰도를 더 높일 수 있다.
일곱 번째 확장 방향은 artifact-level unit test다. 코드 벤치마크에는 테스트가 있지만, 사무 문서 벤치마크에는 테스트가 부족하다. 예를 들어 생성된 Excel의 특정 셀 값, PPT의 슬라이드 수, 보고서의 필수 섹션, CSV의 행 수, 계산식 검증을 자동 unit test로 분리하면 judge 판단과 결정적 검증을 결합할 수 있다.
여덟 번째 확장 방향은 model-harness co-design이다. 결과는 강한 모델과 좋은 하네스가 서로 보완될 때 성능이 오른다는 점을 보여준다. 따라서 후속 연구는 모델 단독 benchmark보다, 도구 설명 방식, 파일 요약 방식, 메모리 주입 방식, 실패 회복 정책을 모델 학습과 함께 최적화하는 방향으로 가야 한다.
아홉 번째 확장 방향은 privacy-preserving benchmark generation이다. 실제 기업 데이터를 공개하기 어렵기 때문에, 공개 자료와 합성 파일의 조합은 계속 중요하다. 다만 합성 워크스페이스가 실제 업무의 민감도, 불완전성, 권한 제약, 비공식 커뮤니케이션을 얼마나 잘 근사하는지 측정하는 메타 평가가 필요하다.
열 번째 확장 방향은 evaluation economics다. 평균 550.7K 토큰은 대규모 리더보드를 매우 비싸게 만든다. 앞으로는 전체 루브릭 평가와 저비용 proxy 평가의 상관관계를 분석하고, 어떤 태스크 subset이 전체 순위를 가장 잘 예측하는지 연구해야 한다. Workspace-Bench-Lite는 이 방향의 첫 단계로 볼 수 있다.
정리하면 Workspace-Bench는 에이전트 평가를 더 어렵게 만든 논문이지만, 그 어려움은 실제 업무 자동화의 어려움과 맞닿아 있다. 에이전트가 복잡한 폴더 안에서 잘못된 파일을 고르고, 오래된 버전을 참고하고, 근거 없는 문장을 작성하는 문제를 평가하지 않는다면, 높은 데모 성능은 운영 신뢰성으로 이어지기 어렵다.
Figure 14: Workspace Learning의 다섯 단계 진화 모델.
이 그림은 데이터 비민감 지시에서 시작해 사용자 지정 파일 실행, 파일 간 의존성 추론, 태스크 기반 파일 발견, 워크스페이스 네이티브 자기 진화로 이어지는 단계를 정리한다. 논문은 현재 에이전트가 L2와 L3 사이에서 Data Association Gap을 겪는다고 본다. 단계론은 리더보드 점수보다 제품 로드맵을 세분화하는 데 더 직접적으로 쓰일 수 있다. L0부터 L4까지의 구분은 제품 설명에도 유용하다. 현재 시스템이 파일 경로 지정형 보조 도구인지, 자율 탐색형 업무 에이전트인지, 장기 적응형 동료인지 명확히 나눌 수 있기 때문이다.
논문 후반의 Five Stages of Workspace Learning도 활용 지침으로 읽을 만하다. L0는 데이터 비민감 실행으로, 에이전트가 단지 절차적 조언을 제공하고 실제 데이터 조작은 사용자가 담당하는 단계다. 이 단계에서는 모델이 똑똑해 보여도 업무 파일을 직접 다루지 않으므로, Workspace-Bench가 측정하려는 핵심 능력과는 거리가 있다.
L1은 User-Specified File Execution이다. 사용자가 파일 경로와 처리 순서를 지정하면 에이전트가 그 파일을 처리한다. 오늘날 많은 GUI 에이전트나 문서 자동화 도구가 이 수준에 머문다. 문제는 사용자가 어떤 파일이 필요한지 이미 알고 있어야 한다는 점이다. 실제 업무에서는 바로 이 파일 선택 부담을 줄이는 것이 자동화의 가치다.
L2는 File-to-File Dependency Reasoning이다. 사용자가 제공한 파일들 안에서 명시적·암묵적 관계를 찾아야 한다. 예를 들어 표가 보고서의 근거인지, 발표 자료가 어떤 원본 데이터에서 파생되었는지, 두 문서가 같은 프로젝트의 다른 버전인지 판단해야 한다. 논문은 이 단계부터 하네스의 역할이 점점 커진다고 본다.
L3는 Task-to-File Dependency Discovery다. 사용자가 파일을 지정하지 않아도, 에이전트가 전체 워크스페이스를 탐색해 태스크와 관련된 자료를 스스로 찾아야 한다. Workspace-Bench의 Hard 태스크가 주로 이 단계의 능력을 요구한다. 논문이 말하는 Capability Singularity는 에이전트가 end-to-end로 업무를 처리할 수 있는 전환점을 가리킨다.
L4는 Workspace-Native Self-Evolution이다. 에이전트가 한 번의 태스크를 끝내는 데 그치지 않고, 사용자의 업무 공간 변화와 과거 실행 경험을 계속 학습한다. 새 도구가 설치되면 이를 인식하고, 반복되는 문서 패턴을 기억하며, 이전 실패에서 얻은 지식을 다음 실행에 반영해야 한다. 이는 현재 벤치마크보다 더 장기적인 평가를 요구한다.
이 단계론에서 중요한 개념은 Data Association Gap이다. 현재 에이전트는 독립 파일 처리에는 어느 정도 능숙하지만, 태스크와 파일, 파일과 파일, 파일과 과거 실행 기억을 연결하는 지속적 데이터 연합 능력이 부족하다. Workspace-Bench의 성능 하락과 Edge F1 약점은 바로 이 간극을 실험적으로 드러낸다.
또 하나의 개념은 orchestration singularity다. L2 이후에는 foundation model 자체의 언어 추론력보다 하네스가 어떤 순서로 탐색하고, 어떤 정보를 기억하며, 어떤 파일 관계를 명시화하는지가 성능에 더 큰 영향을 미칠 수 있다. 이 관점은 에이전트 연구가 모델 크기 경쟁만으로는 충분하지 않다는 메시지를 준다.
따라서 Workspace-Bench를 내부 평가에 도입한다면, 결과표만 복사하는 데 그치지 말고 에이전트가 어느 단계에 머무는지 분류하는 것이 좋다. 경로를 알려주면 잘하지만 스스로 찾지 못하면 L1, 파일 묶음 안의 관계는 파악하지만 전체 폴더 탐색이 약하면 L2, 전체 워크스페이스에서 관련 파일을 찾지만 반복 학습이 없으면 L3에 가깝다.
이 단계 분류는 로드맵 작성에도 유용하다. 제품팀은 “완전 자율 업무 에이전트”라는 큰 목표 대신, 우선 L1의 안정적 파일 처리, 다음으로 L2의 관계 추론, 그다음 L3의 자율 탐색, 마지막으로 L4의 장기 적응을 순차적으로 목표화할 수 있다. 각 단계마다 필요한 로그, 권한, 검수 방식도 달라진다.
평가 설계자에게는 각 단계별 실패 샘플을 따로 모으는 것이 중요하다. L1 실패는 파일 형식 파싱이나 명령 준수 문제일 수 있고, L2 실패는 관계 누락일 수 있으며, L3 실패는 검색 전략과 비용 제어 문제일 수 있다. 같은 낮은 점수라도 원인이 다르므로, 모든 실패를 하나의 “에이전트 실패”로 합치면 개선 방향이 흐려진다.
Workspace-Bench가 제시한 단계론은 블로그 독자에게도 실용적 질문을 남긴다. 내가 쓰는 에이전트는 경로를 알려주지 않아도 필요한 파일을 찾는가, 찾은 파일의 최신성과 파생 관계를 설명하는가, 결과물마다 근거 파일을 남기는가, 이전 실행에서 배운 규칙을 다음 작업에 적용하는가. 이 네 질문에 답하면 현재 도구의 실제 수준을 꽤 정확히 가늠할 수 있다.
결국 이 논문의 가치는 특정 리더보드 순위보다 평가 언어를 제공한다는 데 있다. “파일을 읽을 수 있다”는 표현을 탐색, 지원 파일 활용, 결과 파일 활용, 내용 관계, 이질 파일 이해, 계보 추적으로 쪼개고, 다시 L0부터 L4까지의 발전 단계로 배치한다. 이 언어가 있어야 모델과 하네스 개선을 같은 좌표계에서 비교할 수 있다.
블로그 독자에게 권하고 싶은 읽기 순서는 세 단계다. 먼저 Figure 1과 Table 6으로 최고 성능과 인간 기준선의 간격을 확인한다. 다음으로 Figure 8에서 Node F1과 Edge F1의 차이를 본다. 마지막으로 Section 6의 단계론을 읽으면 왜 단순 파일 읽기 성능이 업무 자동화 신뢰성으로 곧장 이어지지 않는지 이해하기 쉽다.
제품 평가 체크리스트로 바꾸면 더 명확하다. 에이전트가 결과물을 낼 때 사용한 파일 목록을 반환하는가, 각 파일이 결과물의 어느 부분에 기여했는가, 오래된 버전을 제외한 이유를 설명하는가, 누락된 근거가 있을 때 중단하거나 질문하는가, 결과 저장 위치와 형식을 엄격히 지키는가를 별도 항목으로 평가해야 한다.
연구 재현성 측면에서는 공개된 HTML 이미지와 프로젝트 저장소가 유용하지만, 실제 리더보드 재현에는 실행 비용과 하네스 설정이 큰 변수다. 같은 백본 모델이라도 파서, timeout, 메모리 압축, 도구 설명, 시스템 프롬프트가 달라지면 점수가 변할 수 있다. 그러므로 결과 비교에는 구성 파일과 실행 로그 공개가 함께 필요하다.
마지막으로 이 논문은 에이전트 안전성 논의에도 연결된다. 잘못된 파일을 근거로 만든 보고서는 표면적으로 자연스럽지만, 의사결정에는 위험하다. Workspace-Bench식 평가는 이런 조용한 실패를 수치화한다. 향후 업무 에이전트의 안전성 평가는 독성 출력과 함께 파일 근거, 계보, 수정 이력의 정확성까지 포함해야 한다.
8. 내 해석: SWE-chat, 커밋 연결 평가, 컴퓨터 사용 신뢰성과의 접점
나는 이 논문을 기존 wiki에서 다룬 SWE-chat, commit-linked agent evaluation, computer-use-agent-reliability와 이어서 읽는 편이 유익하다고 본다. 세 주제는 모두 에이전트가 단순히 말로 답하는 수준을 넘어, 실제 작업 흔적과 환경 변화 속에서 신뢰 가능한 결과를 남겨야 한다는 문제의식을 공유한다.
SWE-chat 관점에서 보면 Workspace-Bench는 대화형 문제 해결을 코드 저장소 밖으로 확장한다. SWE-chat이 개발자의 대화, 이슈, 코드 변경, 리뷰 맥락을 다룬다면, Workspace-Bench는 사무 문서, 표, 이메일, 발표 자료, 연구 자료를 대상으로 같은 질문을 던진다. 에이전트가 “대화를 이해했다”는 주장은 결국 어떤 파일을 어떻게 갱신했는지로 검증되어야 한다.
commit-linked agent evaluation과의 접점도 선명하다. 커밋 연결 평가는 에이전트의 답변을 실제 diff, 테스트, 커밋 메타데이터와 연결하려는 접근이다. Workspace-Bench도 파일 의존성 그래프와 루브릭을 사용하지만, 산출물 변경을 git commit 수준의 명시적 provenance로 연결하지는 않는다. 이 점은 내가 보는 약점 1개다.
구체적으로 말하면, Workspace-Bench는 후보 출력 파일과 실행 궤적을 Judge가 읽어 채점하지만, 모든 중간 파일 읽기·쓰기·변환이 검증 가능한 변경 이력으로 표준화되지는 않는다. 따라서 어떤 파일이 어떤 이유로 최종 결과에 기여했는지 추론은 가능하지만, commit-linked 방식처럼 변경 단위, 근거 단위, 검증 단위를 엄밀하게 묶는 데에는 아직 여지가 있다.
computer-use-agent-reliability 관점에서는 샌드박스 복구와 결과 추출 전략이 특히 흥미롭다. 실제 컴퓨터 사용 에이전트는 예상치 못한 경로에 파일을 저장하고, 중간 작업물을 남기고, 때로는 반복 실패에 빠진다. 논문은 이를 평가 프레임워크 차원에서 다루지만, GUI 불안정성, 파일 잠금, 외부 앱 상태 같은 더 넓은 reliability 요인을 완전히 분리해 측정하지는 않는다.
내가 제안하고 싶은 후속 제안 1개는 trace-to-artifact provenance schema를 추가하는 것이다. 각 태스크 실행마다 대화 메시지, 도구 호출, 읽은 파일, 생성·수정 파일, 파일 해시, 의존성 간선 후보, 루브릭 판정 근거를 하나의 signed manifest로 저장한다면, Workspace-Bench는 commit-linked 평가와 computer-use 신뢰성 평가를 더 직접적으로 연결할 수 있다.
이 manifest는 단순 로그를 넘어 평가 대상이 되어야 한다. 예를 들어 루브릭 하나가 통과되려면 최종 파일 내용과 함께 해당 내용을 지지하는 파일 노드와 간선이 manifest 안에서 확인되어야 한다. 이렇게 하면 에이전트가 우연히 맞힌 결과, 오래된 파일을 근거로 만든 결과, 근거 없는 재작성 결과를 더 강하게 구분할 수 있다.
나는 이 방향이 Workspace-Bench의 강점을 약화하지 않고 오히려 확장한다고 본다. 현재 논문은 대규모 파일 의존성 평가의 데이터와 프레임워크를 제시했다. 다음 단계는 에이전트의 작업 인과성을 더 기계적으로 검증하는 것이다. 그러면 SWE-chat의 대화 맥락, commit-linked 평가의 변경 증거, computer-use-agent-reliability의 실행 안정성이 하나의 벤치마크 언어로 만날 수 있다.
9. 결론: 업무 에이전트 평가는 파일 관계를 설명할 수 있어야 한다
Workspace-Bench 1.0은 에이전트 평가의 기준을 한 단계 더 운영 환경 쪽으로 옮긴다. 논문이 제시한 핵심 메시지는 현재의 에이전트가 텍스트를 생성하고 도구를 호출하는 능력은 빠르게 좋아졌지만, 실제 업무 공간에서 필요한 파일을 찾고, 파일 간 관계를 설명하고, 최신성과 파생 관계를 보존하며, 검수 가능한 산출물을 남기는 능력은 아직 충분히 안정적이지 않다는 것이다.
가장 설득력 있는 결과는 평균 47.4%, 최고 약 68%대, 인간 협업 80.7%라는 간격이다. 이 간격은 모델 지능의 부족만을 뜻하지 않는다. 하네스가 어떤 순서로 탐색하고, 어떤 중간 상태를 유지하고, 어떤 파일 파서를 쓰고, 어떤 종료 조건을 갖는지가 함께 성능을 만든다. 따라서 업무 에이전트 개발은 모델 선택과 하네스 공학을 함께 다루어야 한다.
논문이 보여준 Edge F1의 취약성은 특히 중요하다. 관련 파일을 발견하는 것과 파일 간 관계를 정확히 해석하는 것은 다른 문제다. 실제 조직에서 위험한 자동화 실패는 대개 눈에 잘 띄지 않는 관계 오류에서 나온다. 오래된 파일을 최신본으로 착각하거나, 표와 슬라이드의 출처를 뒤섞거나, 회의록의 조건을 결과 문서에 반영하지 않는 식의 실패가 여기에 해당한다.
따라서 Workspace-Bench를 읽고 나면 에이전트 제품의 평가표도 바뀌어야 한다. 단순 성공률 옆에 사용 파일 목록, 파일 의존성 그래프, 최신성 판단, 루브릭별 근거, 토큰 비용, 턴 수, 실패 유형을 함께 기록해야 한다. 이런 로그가 없으면 높은 평균 점수도 실제 배포 신뢰성으로 해석하기 어렵다.
이 논문은 새로운 알고리즘을 제안하는 논문이라기보다, 앞으로 어떤 알고리즘과 하네스가 필요한지 보여주는 평가 기반이다. 향후 연구가 lineage-aware retrieval, provenance manifest, active clarification, artifact-level unit test, judge calibration을 결합한다면, Workspace-Bench는 단순 리더보드를 넘어 업무 에이전트의 안전한 배포 기준으로 발전할 수 있다.
9.1 운영 평가 프로토콜로 옮겼을 때의 결론
이 논문을 실제 팀 평가 프로토콜로 옮긴다면 첫 단계는 태스크를 업무 유형별로 나누는 일이다. 보고서 작성, 표 갱신, 코드 수정, 리서치 요약, 고객 자료 통합은 필요한 파일 형식과 실패 비용이 다르다. Workspace-Bench의 페르소나와 능력 태그를 활용하면 전체 평균 점수보다 더 좁은 내부 평가표를 만들 수 있다. 예를 들어 백엔드 개발 업무에는 코드·테스트·설정 파일의 최신성, 운영 업무에는 스프레드시트와 회의록의 근거 정렬을 더 높은 가중치로 둘 수 있다.
두 번째 단계는 결과물 제출 전에 근거 체인을 강제로 남기는 것이다. 에이전트가 최종 문서를 만들었다면 사용한 파일 경로, 각 파일이 지지하는 주장, 제외한 유사 파일, 오래된 버전을 배제한 이유, 산출물 저장 위치를 함께 반환해야 한다. 이 정보가 없으면 사람 검수자는 결과 텍스트를 다시 처음부터 따라가야 한다. Workspace-Bench의 Node F1과 Edge F1은 이 근거 체인 품질을 수치로 감시하는 지표가 될 수 있다.
세 번째 단계는 하네스별 비용 상한을 점수와 함께 관리하는 것이다. 논문이 보여준 것처럼 일부 조합은 많은 토큰과 턴을 쓰면서도 낮은 정확도에 머문다. 내부 운영에서는 태스크당 최대 파일 열람 수, 최대 도구 호출 수, 최대 토큰, 중간 검증 실패 시 중단 조건을 정해야 한다. 성능이 조금 높더라도 비용이 과도하고 실패 루프가 길다면, 반복 업무 자동화에는 부적합할 수 있다.
네 번째 단계는 사람 개입 지점을 명시하는 것이다. 인간 협업 기준선 80.7%는 완전 수동 작업의 우월성을 말하기보다, 복잡한 파일 관계를 다룰 때 사람의 판단이 어느 위치에서 필요한지 알려준다. 에이전트가 파일 후보와 초안을 만들고, 사람은 파일 선택·최신성·고위험 결론을 승인하는 구조가 현재 성능 수준에서는 가장 현실적이다. 이때 승인 로그도 평가 산출물에 포함되어야 한다.
다섯 번째 단계는 벤치마크를 한 번의 리더보드로 끝내지 않는 것이다. 워크스페이스는 시간이 지나며 바뀌고, 에이전트 하네스도 프롬프트와 도구 정책이 자주 바뀐다. 따라서 같은 태스크 묶음을 주기적으로 다시 실행하고, 점수 변화가 모델 업데이트 때문인지, 파일 파서 개선 때문인지, 메모리 정책 변경 때문인지 분리해야 한다. Workspace-Bench는 이런 장기 운영 평가의 출발점으로 사용할 수 있다.
10. 요약 정리: Workspace-Bench 1.0이 남기는 체크포인트
Workspace-Bench 1.0은 에이전트 평가를 독립 파일 QA나 단순 GUI 조작에서 대규모 파일 의존성 업무로 확장한 벤치마크다. 논문이 남기는 핵심 메시지는 다음처럼 정리할 수 있다.
- 평가 대상의 변화: Workspace-Bench는 프롬프트 안의 완결 정보에 머무르지 않고, 20,476개 파일과 74개 형식이 섞인 업무 공간에서 필요한 파일과 관계를 찾는 능력을 평가한다.
- 데이터 구성: 다섯 직무 페르소나, 388개 태스크, 7,399개 루브릭, 태스크당 평균 4.7개 파일과 5.1개 의존성 간선으로 실제 사무 작업의 복잡성을 근사한다.
- 평가 방식: Rubric Pass Rate, TCR@p, Node F1, Edge F1, 평균 토큰, 평균 턴 수를 함께 사용해 최종 결과, 과정, 의존성 인식, 비용 효율성을 동시에 본다.
- 주요 결과: 28개 에이전트 조합의 평균 성능은 47.4%이고, 최고권 조합도 약 68%대에 머물러 인간 협업 기준선 80.7%와 뚜렷한 격차가 있다.
- 난이도 효과: 평균 성능은 Easy 57.6%, Medium 49.2%, Hard 40.5%로 하락하며, 이질 파일 이해와 계보 추적이 특히 어려운 병목으로 나타난다.
- 하네스의 역할: 같은 LLM도 OpenClaw, ClaudeCode, DeepAgent, Hermes 중 어떤 하네스와 결합되는지에 따라 탐색, 비용, 안정성, 페르소나별 성능이 달라진다.
- 비용의 함정: 평균 550.7K 토큰과 36.6턴이라는 비용 신호는 워크스페이스 태스크가 비싸다는 점을 보여주며, 많은 턴과 토큰이 반드시 높은 정확도로 이어지지는 않는다.
- 후속 방향: 파일 의존성 그래프에 더해 대화, 도구 호출, 파일 diff, 해시, 루브릭 근거를 연결하는 provenance 체계를 넣으면 신뢰 가능한 업무 에이전트 평가로 더 발전할 수 있다.