터미널 에이전트 기록을 재사용 가능한 환경으로 바꿉니다 | DAKER 커뮤니티

터미널 에이전트 기록을 재사용 가능한 환경으로 바꿉니다 썸네일
터미널 에이전트 기록을 재사용 가능한 환경으로 바꿉니다

원문: https://arxiv.org/abs/2609.04148

논문: Terminal-Universe: Turning Agent Trajectories into Scalable Terminal Environments

저자: Jie Wu, Zhenru Zhang, Beichen Zhang, Xuwu Wang, Yuhui Su, Mouxiang Chen, Peng Wang, Zhihai Wang, Que Shen, Hao Zhou, An Yang, Fei Huang, Yujiu Yang, Dayiheng Liu

제출: 2026년 9월 3일 17:41:05 UTC

확인한 사실

빌더가 볼 지점

두 번째 논문은 코딩 에이전트가 남긴 터미널 기록을 훈련 데이터 이상의 자산으로 바꾸려는 작업입니다. 제목은 Terminal-Universe: Turning Agent Trajectories into Scalable Terminal Environments입니다. 저자는 Jie Wu, Zhenru Zhang, Beichen Zhang, Xuwu Wang, Yuhui Su, Mouxiang Chen, Peng Wang, Zhihai Wang, Que Shen, Hao Zhou, An Yang, Fei Huang, Yujiu Yang, Dayiheng Liu입니다. arXiv v1 제출 이력은 2026년 9월 3일 17:41:05 UTC입니다.

논문이 보는 문제는 trajectory와 environment의 차이입니다. 에이전트 trajectory는 한 번 실행된 시연입니다. 반면 environment는 다시 질의할 수 있고, 여러 검증 가능한 과제를 만들 수 있으며, 실행 피드백을 제공합니다. 코딩 에이전트를 post-training하려면 단순한 대화 기록보다 실제로 실행되는 환경이 더 유용합니다. 하지만 현실적인 실행 환경은 만들기 어렵고 부족합니다.

Terminal-Universe의 출발점은 기존 기록 안에 환경을 복원할 단서가 있다는 관찰입니다. 에이전트가 어떤 파일을 읽고, 쓰고, 삭제하고, 테스트했는지 남아 있다면 작업 전후의 workspace 구조를 어느 정도 되돌릴 수 있습니다. 논문은 기록된 file operation을 재생해 에이전트가 수정하기 전 각 파일 상태를 복원하고, completion agent가 누락 파일과 dependency를 채우는 방식을 설명합니다.

그 다음 단계가 빌더에게 흥미롭습니다. 복원된 workspace에서 원래 intent task를 다시 만들 뿐 아니라, 새로운 과제도 합성합니다. breadth 방향으로는 관련 환경 사이의 directional dependency relation을 찾아 여러 codebase를 넘나드는 query를 만듭니다. depth 방향으로는 초기 single-turn query를 multi-round session으로 확장해 사용자 피드백과 요구사항 변경을 반영합니다. 실제 개발이 단일 요청으로 끝나지 않는다는 점을 훈련 환경 쪽에 반영한 셈입니다.

논문은 public terminal agent trajectory에 적용해 37.3k task-sufficient environment를 만들었다고 보고합니다. 그리고 이 corpus로 Qwen3.5-27B를 supervised fine-tuning했을 때 Terminal-Bench 2.1 single-round 성능이 11.9 points 개선됐고, EvoCode-Bench v2 MT@4 multi-round 성능이 13.8 points 개선됐다고 밝힙니다. 이 숫자는 단순히 로그를 많이 모으는 것보다 실행 가능한 환경으로 바꾸는 처리가 성능 신호를 강화할 수 있음을 보여 줍니다.

오늘 팀이 가져갈 질문은 명확합니다. 우리 코딩 에이전트 로그는 다시 실행할 수 있습니까. 단순 transcript만 남으면 학습이나 평가에 쓰기 어렵습니다. 반대로 파일 snapshot, 명령, exit code, 테스트 결과, dependency 정보를 함께 남기면 나중에 같은 실패를 재현하거나 새로운 regression task로 바꿀 수 있습니다. 자동화 로그 설계가 곧 다음 학습 데이터 설계가 됩니다.

바로 할 일은 에이전트 작업 기록 형식을 점검하는 것입니다. 작업 시작 시 repository 상태, 주요 파일 목록, 설치 명령, 테스트 명령, 실패 로그, 최종 diff를 같은 폴더에 남기십시오. 민감한 토큰과 개인 정보는 저장하지 않아야 합니다. 대신 재현에 필요한 dependency와 명령은 충분히 남겨야 합니다. 로그를 사람이 읽는 보고서로만 만들면 이 논문이 말하는 environment 전환에는 부족합니다.

평가 쪽에서도 의미가 있습니다. 지금 많은 코딩 에이전트 평가는 이미 준비된 benchmark에 새 모델을 돌리는 방식입니다. 하지만 실제 서비스에서는 우리 코드베이스의 반복 실패가 더 중요합니다. Terminal-Universe식 사고를 적용하면 과거 실패 세션을 작은 실행 환경으로 복원하고, 같은 유형의 요구사항 변경을 여러 번 던져 보는 내부 벤치마크를 만들 수 있습니다.

주의할 점도 있습니다. completion agent가 누락 파일과 dependency를 채우는 과정은 편향을 만들 수 있습니다. 복원된 환경이 원래 환경과 다르면 평가가 쉬워지거나 어려워질 수 있습니다. 따라서 내부 적용에서는 원본 로그에서 확실한 부분과 보완된 부분을 분리해 표시해야 합니다. 실행 가능한 환경을 만드는 목표가 로그 미화를 뜻하면 안 됩니다.

팀 내부에서 시작하려면 과거에 실패한 에이전트 세션 세 개만 골라도 충분합니다. 각 세션에서 원본 repository 상태, 사용자 요청, 실행 명령, 실패한 테스트, 최종 수정 파일을 모으십시오. 그런 뒤 새 에이전트에게 같은 과제를 다시 주고 성공 여부를 비교하십시오. 환경을 완전히 복원하지 못해도 어떤 정보가 부족한지 알 수 있습니다. 그 부족 목록이 다음 로그 포맷 개선안입니다.

multi-round 평가도 잊지 마십시오. 실제 사용자는 처음부터 완벽한 요구사항을 주지 않습니다. 첫 결과를 보고 추가 조건을 붙이고, 이전 조건 일부를 바꾸고, 실패를 보고 방향을 좁힙니다. Terminal-Universe가 depth 방향으로 session을 확장하는 이유도 여기에 있습니다. 내부 평가에서도 첫 요청만 던지지 말고 두세 차례 피드백을 넣어야 에이전트의 유지 능력을 볼 수 있습니다.

보안과 프라이버시 기준도 먼저 정해야 합니다. terminal trajectory에는 파일 경로, 내부 패키지 이름, 환경 변수 이름, 테스트 데이터 일부가 들어갈 수 있습니다. 재사용 가능한 환경으로 바꾸기 전에 제거할 값과 보존할 값을 분리하십시오. 실험용 benchmark를 만든다는 이유로 운영 비밀을 학습 데이터에 섞으면 안 됩니다.

환경 복원 품질을 평가하는 표도 만드십시오. 파일 복원률, dependency 설치 성공률, 테스트 실행 가능 여부, 원래 실패 재현 여부, 새 과제 합성 가능 여부를 나눠 적으면 됩니다. 복원 자체가 흔들리면 그 위에서 학습한 성능 개선도 믿기 어렵습니다. 학습 성과를 말하기 전에 환경 품질을 먼저 증명해야 합니다.

이 논문은 로그를 많이 남기라는 단순한 메시지가 아닙니다. 다시 실행할 수 있는 형태로 남기라는 메시지입니다. 대화 내용만 저장하는 팀과 workspace 상태까지 함께 저장하는 팀은 나중에 만들 수 있는 평가 자산이 다릅니다. 코딩 에이전트를 오래 쓸 계획이라면 지금 로그 스키마부터 바꾸는 편이 좋습니다.

한 줄 요약은 이것입니다. 에이전트 기록은 읽는 보고서가 아니라 다시 실행할 수 있는 평가 환경으로 남겨야 합니다.

원문은 아래 arXiv 링크에서 확인할 수 있습니다.