Terminal-Universe가 보여준 것: 에이전트 궤적을 실행 가능한 터미널 환경 3.73만 개로 복원한 방법 | DAKER 커뮤니티

2026년 9월 4일 arXiv에 공개된 Terminal-Universe는, 쌓여 가는 터미널 기반 코드 에이전트 궤적을 어떻게 다시 학습 가능한 실행 환경으로 바꿀 수 있는지를 다룹니다. 궤적 데이터는 많아도, 실제로 다시 실행해 보고 질문을 던질 수 있는 환경은 부족하다는 문제가 출발점입니다.

이 논문이 지금 흥미로운 이유는 분명합니다. 에이전트 학습에서 필요한 것은 단순한 로그가 아니라, 다시 열어 보고 실행해 볼 수 있는 워크스페이스이기 때문입니다. Terminal-Universe는 도구 실행 이력을 바탕으로 당시 환경의 구조와 내용을 복원하고, 그 위에서 원래 과제와 새로운 과제를 다시 만들어 냅니다.

논문은 2026-09-04 arXiv에 올라왔습니다. 초록은 arXiv:2609.04148에서 확인할 수 있고, 영문 제목은 Terminal-Universe: Turning Agent Trajectories into Scalable Terminal Environments입니다. 저자는 Jie Wu, Zhenru Zhang, Beichen Zhang 외 11명입니다. PDF는 https://arxiv.org/pdf/2609.04148입니다. 이 글은 제공된 사실과 초록에서 확인되는 범위만 바탕으로 정리합니다.

궤적을 다시 실행 가능한 환경으로 바꾸는 접근

논문의 핵심은, 에이전트 궤적에 남은 도구 실행 이력이 단순한 기록이 아니라 환경 복원의 단서라는 점입니다. 파일 연산을 리플레이해 에이전트가 수정하기 전 상태로 파일을 되돌리고, 부분적으로만 복원된 워크스페이스는 completion agent가 누락된 파일과 의존성을 채우는 방식입니다.

궤적 한 줄이 아니라, 다시 물을 수 있고 실행 피드백을 주는 환경이 학습의 핵심 자산입니다.

이렇게 복원된 워크스페이스에서는 원래 의도된 과제를 다시 구성할 수 있고, 여기에 더해 새로운 과제도 합성할 수 있습니다. 논문은 과제 확장을 두 축으로 설명합니다. 하나는 관련 환경 사이의 방향성 의존을 찾아 여러 코드베이스를 넘는 질의를 만드는 너비 축이고, 다른 하나는 초기 단일 턴 질의를 user agent를 통해 다중 라운드 세션으로 확장하는 깊이 축입니다.

보고된 규모와 성능 변화

논문 초록에 따르면, 공개 터미널 에이전트 궤적에 이 방법을 적용해 task-sufficient 환경 37.3k개를 만들었다고 보고합니다.

공개 터미널 에이전트 궤적에서 과제 수행에 충분한 환경 37.3k개를 복원했다고 적습니다.

또한 이 말뭉치로 Qwen3.5-27B를 지도 학습(SFT)했을 때, Terminal-Bench 2.1의 단일 라운드 성능이 11.9포인트, EvoCode-Bench v2의 MT@4 다중 라운드 성능이 13.8포인트 상승했다고 설명합니다.

Qwen3.5-27B를 이 말뭉치로 학습했을 때 Terminal-Bench 2.1은 11.9포인트, EvoCode-Bench v2 MT@4는 13.8포인트 올랐다고 보고합니다.

다만 원본 궤적 수, 필터 기준의 세부 표, 절대 점수, 학습 하이퍼파라미터는 초록에 없으므로 이 글에서도 덧붙이지 않습니다. 코드 URL 역시 초록에는 제시되지 않습니다.

데이터 파이프라인을 어떻게 다시 볼 것인가

이 논문이 주는 실질적인 시사점은, 에이전트 데이터를 단순한 궤적 아카이브로만 다루지 말아야 한다는 점입니다. 복원 가능한 환경을 중심에 두면 데이터 파이프라인은 자연스럽게 리플레이, 보완, 과제 합성으로 나뉘게 됩니다.

특히 completion agent가 어떤 파일과 의존성을 채웠는지 별도로 남겨 두는 것이 중요합니다. 복원된 부분과 보완된 부분이 구분되어야 이후 감사와 재현이 가능하기 때문입니다. 또한 교차 워크스페이스 질의와 다중 라운드 세션은 같은 종류의 데이터가 아니므로, 서로 다른 태그나 구분으로 관리하는 편이 좋습니다.

문서화할 때 섞지 말아야 할 것들

논문에서 제시한 37.3k, +11.9, +13.8은 그대로 인용할 수 있는 수치이지만, 어디까지나 논문이 보고한 결과입니다. 실제 운영 문서나 README에 옮길 때는 논문 수치와 팀의 실측 수치를 분리해 적는 것이 좋습니다.

마찬가지로 복원 성공률과 SFT 성능도 한 항목으로 합치지 않는 편이 낫습니다. 환경 복원 단계의 병목과 학습 단계의 병목은 다를 수 있기 때문입니다. 단일 라운드 벤치와 다중 라운드 벤치 역시 같은 숫자로 평균 내거나 합산하지 않고, 각각의 이름과 조건을 유지한 채 적어야 합니다.

환경 복원 수와 벤치 성능 상승은 같은 줄에 놓을 수 있어도, 같은 의미의 숫자는 아닙니다.

이 글에서 확인하지 않는 것

몇 가지는 분명히 선을 그을 필요가 있습니다. 모든 공개 궤적이 그대로 37.3k 환경으로 바뀐다는 뜻은 아닙니다. 이는 논문이 적용 결과로 보고한 규모입니다.

또한 이 글이 SFT 하이퍼파라미터를 확정하는 것도 아닙니다. 초록에 없는 항목은 다루지 않았습니다. 코드가 이미 공개되었다는 주장도 아닙니다. 초록에는 코드 URL이 없습니다.

결국 이 글은 Terminal-Universe가 제시한 방법과 초록에 적힌 수치를, 확인 가능한 범위 안에서 구조적으로 정리한 글입니다.

참고 자료

arXiv:2609.04148 — Terminal-Universe: Turning Agent Trajectories into Scalable Terminal Environments
PDF

여러분은 에이전트 궤적을 보관할 때, 로그 자체보다 복원 가능한 환경을 함께 남기는 방식이 앞으로 더 중요해질 것이라고 보시나요?