RunningTab: AI가 읽은 근거와 아직 끝내지 못한 요구사항을 작업장에 기록하기

배경과 문제

조직의 지식 작업은 이미 보유한 파일들(보고서, 스프레드시트, 슬라이드, 메모)에서 새 산출물을 만드는 일이 많다. 예를 들어 이력서와 면접 노트에서 채용 요약을 만들거나, 1년치 월간 스프레드시트에서 예산 검토를 작성하는 식이다. LLM 에이전트가 컴퓨터를 자율적으로 조작할 수 있게 되면서, 에이전트가 관련 파일을 찾고 읽고 최종 문서를 쓰는 전체 과정을 맡길 수 있게 되었다. 이런 워크스페이스 과제는 단일 검색이 아니라 여러 파일에 흩어진 내용을 모아야 하는 장기 작업이다.

에이전트가 파일에 접근하는 방법으로 '직접 말뭉치 상호작용(direct corpus interaction)'이 있다. 미리 구축한 색인을 검색하는 대신, 에이전트가 터미널에서 ls, grep, cat 같은 표준 명령어를 원본 파일에 직접 적용한다. 이러면 색인이나 전처리 없이 워크스페이스의 어떤 파일이든 그대로 접근할 수 있다. 이 논문은 이 방식을 워크스페이스 과제에 적용한 '직접 워크스페이스 상호작용(DWI)'을 다룬다. DWI에서 에이전트는 여러 턴에 걸쳐 파일을 탐색하고 마지막에 산출물을 제출한다.

기존 접근의 한계

DWI의 핵심 문제는 파일에 도달하는 것만으로는 부족하다는 점이다. 에이전트는 워크스페이스 전체에 접근할 수 있지만, 과제가 무엇을 요구하는지, 어떤 파일을 읽었는지, 어떤 파일이 목록에만 나타나고 열리지 않았는지를 추적하는 기록이 없다. 이런 정보는 컨텍스트 창을 지나가면서 새로운 관찰에 밀려 사라진다. 결과적으로 에이전트가 올바른 연례 보고서를 열어 필요한 수치를 관찰에 담았는데도 최종 보고서에 그 수치를 빠뜨리거나, 관련 파일이 있는 폴더를 목록으로만 보고 열지 않는 일이 생긴다.

저자들은 이 문제를 정량적으로 확인했다. Workspace-Bench 100개 과제에서 GPT-5.4 nano로 DCI를 3회 실행하고, 실패한 루브릭을 LLM 주석자로 분류했다(인간 라벨과 Cohen's kappa 0.83). 실패 유형 중 '추출(extraction)'이 손실 점수의 51.1%를 차지했는데, 이는 다시 '보여졌지만 누락(Shown but Missing)' 12.3%와 '누락 또는 왜곡(Dropped or Distorted)' 38.9%로 나뉜다. 또한 산출물을 만든 시도 중 루브릭이 기대하고 에이전트 관찰에 나타난 891개 고유 수치의 약 19.8%가 최종 산출물에 없었다. 이는 읽기와 최종 산출물에 반영하기 사이에 간극이 있음을 보여준다. 누락된 모든 수치가 실제 컨텍스트에서 잘려 나갔다는 뜻은 아니며, 저자들도 남아 있는 내용이 활용되지 않을 수 있다고 설명한다.

연구방법을 단계별로

RunningTab은 환경이 에이전트 옆에서 유지하는 '환경 측 탭'을 도입한다. 탭은 세 가지 항목으로 구성된다. 첫째, 요구사항(requirements)은 과제가 요구하는 개별 사실·그림·요소로, 에이전트가 과제 시작 시 add 연산으로 추가한다. 둘째, 읽기 로그(read log)는 에이전트가 파일을 읽을 때마다 환경이 자동으로 기록하는데, 에이전트가 본 내용 그대로의 발췌문과 파일 경로·명령어 같은 출처(anchor)를 저장한다. 셋째, 후보(candidates)는 목록에 나타났지만 아직 열리지 않은 파일들로, 환경이 자동으로 기록하고 BM25로 과제와의 관련성을 기준으로 순위를 매긴다.

탭은 컨텍스트 창 밖에 저장되므로 새로운 관찰에 밀려나지 않는다. 에이전트는 네 가지 연산으로 탭에 접근한다. add는 요구사항을 추가하고, resolve는 요구사항을 done(읽기 로그 항목 인용) 또는 unavailable(이유 제시)로 닫는다. list는 요구사항·후보·읽기 로그를 나열하고, show는 읽기 로그 항목 하나를 다시 보여준다. 환경은 각 관찰에 탭 상태를 요약한 상태 줄을 덧붙여 에이전트가 탭을 보지 않아도 현재 열린 요구사항 수 등을 알 수 있게 한다.

과제를 마무리하기 전에 탭을 정리하는 세 가지 메커니즘이 있다. 첫째, 검토(review)는 에이전트가 list(kind=requirements)를 호출하면 각 열린 요구사항 옆에 가장 잘 맞는 읽기 로그 발췌문과 아직 열지 않은 후보 파일을 BM25 순위로 보여준다. 둘째, 증거 기반 해결(resolution on evidence)은 done으로 닫을 때 인용한 읽기 로그 항목의 경로와 발췌문이 요구사항과 공통 용어를 공유하는지 확인하여, 아무 어휘도 겹치지 않는 인용을 거부한다. 이는 간단한 어휘 검사이므로 의미상 올바른 근거인지까지 보장하지는 않는다. 셋째, 종료 검사(finish check)는 에이전트가 처음 멈출 때 열린 요구사항과 열지 않은 파일을 보고하고, 누락된 내용을 추가하도록 한 번만 요청한다.

결과와 숫자의 의미

세 가지 벤치마크(Workspace-Bench, TheAgentCompany, OfficeQA Pro)와 세 가지 LLM(GPT-5.4 nano, DeepSeek V4 Flash, Gemini 3.8 Flash)에서 RunningTab은 모든 지표에서 최고 성능을 보였다. 예를 들어 Workspace-Bench에서 GPT-5.4 nano의 루브릭 통과율(Pass Rate)은 DCI 41.63에서 RunningTab 44.73으로, TCR@70은 20.67에서 25.67로 향상되었다. DeepSeek V4 Flash는 Pass Rate 53.28→59.99, TCR@70 38.67→41.00으로, Gemini 3.8 Flash는 Pass Rate 31.42→46.91, TCR@70 23.33→36.33으로 개선되었다. TheAgentCompany와 OfficeQA Pro에서도 모든 모델에서 일관된 향상이 나타났다.

모델이 스스로 과제를 추적하는 기준선(TODO, Self-Refine, Self-Tracking)은 DCI보다 나아지는 경우도 있지만 더 나빠지는 경우도 있었고, RunningTab에는 미치지 못했다. 구성 요소 제거 실험에서는 GPT-5.4 nano의 Workspace-Bench 루브릭 통과율이 환경 캡처를 뺄 때 44.73에서 41.36으로 떨어져 DCI의 41.63과 비슷해졌고, 검토만 제거하면 41.87이었다. 다만 환경 캡처를 제거한 설정은 이를 쓰는 검토와 근거 검사도 함께 제거한다. 따라서 자동 기록을 포함한 기능 묶음의 기여를 보여주며, 기록 기능 하나의 독립 효과를 완전히 분리한 실험은 아니다.

탭이 실제로 무엇을 담고 있는지도 분석했다. Workspace-Bench에서 탭은 중앙값으로 요구사항 4~5개, 읽기 로그 항목 6~18개(5~11개 파일에서 추출, 12K~40K 문자), 열지 않은 후보 147~294개를 보유했다. 에이전트가 검토를 요청하면 열린 요구사항의 69.9%~88.0%가 요구사항 단어를 포함한 줄이 있는 읽기 로그 발췌문 옆에 표시되었다. 또한 RunningTab을 쓴 GPT-5.4 nano에서도 최종 산출물에서 빠진 수치가 있었다. 실패한 루브릭이 요구하고 관찰에는 나타난 누락 수치 중 94.8%가 해당 실행의 탭에 남아 있었다. 별도 복구 실험은 탭에 남은 값의 정답을 가리고 같은 LLM에 과제와 요구사항을 주었다. 탭 없이 8.4%, 검토와 에이전트가 선택해 연 항목으로 45.8%, 전체 읽기 로그로 78.1%를 복구했다. 실제 제출 결과에서 자동으로 그만큼 오류가 고쳐졌다는 수치는 아니다.

구체적인 예시

논문의 Figure 1은 작동 원리를 설명하기 위해 만든 가상 예를 보여준다. 과제가 '매출, 직원 수, 특허 수에 대한 브리핑'을 요구할 때, DCI에서는 에이전트가 연례 보고서에서 특허 수 3을, 직원 CSV에서 직원 수 128을 읽었지만, 이후 35턴이 지나면서 이 사실들이 컨텍스트 창에서 밀려나 최종 브리핑에 빠진다. RunningTab에서는 에이전트가 요구사항 r1(매출), r2(직원 수), r3(특허 수)를 추가하고, 환경이 읽은 내용을 로그로 기록하며, 에이전트가 각 요구사항을 해당 로그 항목으로 해결하여 세 가지 모두 브리핑에 포함된다.

부록의 실제 사례도 있다. 한 과제는 네 개의 출장 정책 파일에서 출장 승인, 요구사항, 환급 기준, 절차, 위반 처리 등 다섯 주제를 다루는 가이드를 작성하는 것이었다. RunningTab 에이전트는 첫 턴에 여섯 개 요구사항을 추가했고, 환경은 검색으로 나온 98개 파일을 후보로, 읽은 네 개 정책 파일을 읽기 로그 L1~L4로 기록했다. 턴 10의 검토에서 환급 기준(r3)이 L2의 '제7조 출장비 환급 기준' 줄 옆에 표시되었고, 에이전트는 가이드를 쓴 후 r3를 L2를 인용해 done으로 해결했다. 종료 검사에서 모든 요구사항이 해결되었음을 확인하고 가이드를 제출했다.

또 다른 사례는 구매 주문 10건을 공급자별로 표로 요약하는 과제다. DCI에서는 에이전트가 Supplier 15의 주문(금액 ¥55,000)을 읽었지만 최종 표에 한 행만 남겼다. RunningTab에서는 환경이 각 주문을 읽기 로그로 기록했고, 종료 검사가 요구사항이 없음을 알리자 에이전트가 공급자별로 요구사항을 추가하고 각각을 해당 로그 항목으로 해결했다. 결과적으로 10개 공급자 모두에 대한 행이 표에 포함되었고, 각 행이 탭에서 원본 주문과 연결되었다.

한계와 오해하기 쉬운 점

이 자료는 arXiv에 공개된 프리프린트의 최초 공개본(v1)이다. 벤치마크 전체를 그대로 평가한 것이 아니라 하위 집합을 사용했다. TheAgentCompany는 파일 서버만 필요한 88개 체크포인트, OfficeQA Pro는 외부 자료가 필요 없는 104문항만 사용했다. Workspace-Bench의 Pass Rate는 요구사항별 루브릭 통과율이고 TCR@70은 요구사항 70% 이상을 만족한 과제 비율이므로, 전체 과제 완벽 성공률과 혼동하면 안 된다. 예를 들어 Gemini 3.8 Flash의 Pass Rate 31.42→46.91은 루브릭 통과율이고, TCR@70 23.33→36.33은 70% 기준 통과 과제 비율이다.

모델은 GPT-5.4 nano, DeepSeek V4 Flash, Gemini 3.8 Flash이며 3회 실행 평균이다. 동일한 DCI-Agent-Lite/Pi 하네스에서 최대 300턴, 과제당 1시간, 컨텍스트 관리 level 3을 사용했고, 필요 시 GPT-5.4 mini 심판을 사용했다. 표준 편차가 일부 지표에서 크므로(예: Gemini의 TODO Pass Rate ±5.62) 단일 실행 결과는 변동이 있을 수 있다. 또한 탭이 읽은 파일의 발췌문을 저장하므로 실제 워크스페이스에서는 민감한 내용이 남을 수 있으며, 저자들은 워크스페이스와 동일한 접근 권한을 적용하고 산출물을 검토할 것을 권장한다.

탭이 '보여졌지만 누락'된 수치의 94.8%를 보유한다는 결과는 GPT-5.4 nano 기준이며, 읽기 로그는 파일 내용만 저장하므로 에이전트가 계산한 값(합계 등)이나 목록에서만 본 값은 저장하지 않는다. 또한 에이전트가 탭을 어떻게 사용하는지는 모델마다 달랐다. Gemini는 주로 검토를 통해 작업했고, GPT-5.4 nano는 종료 검사에 의존했으며, DeepSeek은 후보 파일을 더 많이 열었다. 이는 탭의 효과가 모델의 사용 방식에 따라 달라질 수 있음을 시사한다.

실제로 어떻게 활용할까

RunningTab은 기업의 파일 저장소에서 여러 문서를 종합해 보고서나 스프레드시트를 만드는 에이전트에 적용할 수 있다. 에이전트가 과제를 요구사항으로 분해하고, 환경이 읽은 내용과 후보 파일을 자동으로 기록하며, 종료 전에 검토와 종료 검사를 통해 누락을 방지한다. 이는 특히 읽는 양이 많은 과제에서 효과가 컸는데, 읽기량 기준 상위 1/3 과제에서 DCI 대비 이득이 하위 1/3의 약 2배였다.

실무에 도입할 때는 탭에 저장되는 발췌문이 민감한 내용을 포함할 수 있으므로 접근 권한을 워크스페이스와 동일하게 유지하고, 산출물을 사람이 검토하는 절차가 필요하다. 또한 이 연구는 특정 벤치마크 하위 집합과 세 가지 LLM에서 검증되었으므로, 다른 도메인이나 모델에서는 성능이 다를 수 있다. 그럼에도 불구하고 환경이 컨텍스트 창 밖에서 과제 상태를 기록한다는 아이디어는 장기 작업을 수행하는 에이전트의 신뢰성을 높이는 실용적인 접근으로 볼 수 있다.