명령을 하나 실행한다. 빨간 오류가 뜬다. 원인을 짚어 코드를 한 줄 고친다. 다시 실행한다. 이번엔 다른 데서 막힌다. 로그를 거슬러 올라가 설정을 바꾸고, 또 돌린다. 개발이든 데이터 정리든, 실제 일은 대개 이 "확인하고 고치고 다시 실행하는" 반복으로 끝까지 간다.
이 모든 일이 벌어지는 화면이 터미널이다. 문자로 명령을 입력해 컴퓨터를 조작하는 화면이다. 그리고 명령과 결과와 다음 명령이 줄줄이 이어진 이 작업의 전체 기록을 "궤적(trajectory)"이라고 부른다. 사람으로 치면 문제를 푸는 동안 적어 둔 작업 일지에 가깝다.
알리바바 AMAP과 중국과학기술대(USTC) 연구진은 이 궤적에 주목했다. 터미널에서 일하는 AI 에이전트를, 짧은 시연을 넘어 몇 시간짜리 실제 업무까지 해내게 하려면 무엇을 바꿔야 할까. 이들의 답은 이렇다. 에이전트를 가르칠 때 중요한 건 "어떤 과제를 풀렸느냐"가 아니라 "어떤 궤적을 보고 배웠느냐"다. 그런데 지금 공개된 학습용 궤적은 대부분 너무 짧다. 그래서 연구진은 긴 궤적을 자동으로 찍어내는 엔진 TerminalHorizon을 만들었다.
먼저 분명히 해 둘 게 있다. 기록이 길다고 배울 것이 많은 건 아니다.
짧은 궤적은 명령을 치고 도구를 부르는 법은 보여준다. 하지만 에이전트가 일을 실제로 어떻게 끝내는지는 담지 못한다. 단서를 모으고, 판단을 내리고, 피드백을 받아 전략을 고치고, 중간 결과를 최종 산출물로 바꾸는 과정 말이다. 긴 작업에서는 이런 행동이 한두 스텝이 아니라 여러 단계에 걸쳐 나타난다.
그렇다고 길면 다 좋은 것도 아니다. 궤적이 길어지는 이유는 둘로 갈린다. 하나는 쓸데없는 재시도다. 같은 실수를 반복하거나 헤매서 기록만 늘어난 경우다. 다른 하나는 진짜 의존이다. 앞 단계에서 관측한 것이 다음 판단을 바꾸기 때문에 단계가 서로 맞물려 길어진 경우다. 앞은 걸러내야 할 노이즈고, 뒤가 바로 에이전트에게 배우게 하고 싶은 능력이다.
더 고약한 함정도 있다. 환경을 자동으로 만들다 보면, 정작 에이전트가 풀어야 할 핵심 작업을 환경이 미리 해결해 버린다. 예를 들어 "주문별 환불액을 합산하는 함수를 구현하라"는 과제를 냈다고 하자. 그런데 환경 안에 이미 그 합산 함수가 들어 있으면, 에이전트가 할 일은 숫자 상수 하나를 바꾸는 정도로 쪼그라든다. 겉보기엔 복잡한데, 의도했던 탐색도 구현도 검증도 일어나지 않는다. 궤적이 길어 보여도 알맹이가 없는 것이다.
그래서 데이터를 볼 때 던져야 할 질문은 "이 궤적이 긴가"가 아니라 "왜 길어졌나"다. 진짜 의존 때문인가, 아니면 환경이 덜 만들어졌거나 에이전트가 헤맸기 때문인가. TerminalHorizon은 이 구분을 데이터를 만드는 단계에서부터 강제한다.
문제를 낸 사람은 자기 문제의 빈틈을 잘 못 본다. 답을 이미 알기 때문이다. 시험지를 낸 교사는 "이건 지문만 봐도 답이 나오네" 싶은 문항을 스스로 걸러내지 못한다. 그 허점은 문제를 모르는 사람에게 미리 풀려 봐야 드러난다.
TerminalHorizon은 이 방식을 그대로 쓴다. 과제를 만든 쪽이 아니라, 그 과제를 처음 보는 제3자 에이전트("독립 챌린저")에게 실제로 풀려 본다. 그리고 "너무 쉽게 풀린" 구간을 거꾸로 추적해 환경을 다시 짠다. 엔진은 두 단계로 돈다. 앞서 꺼낸 환불 합산 함수 과제를 끝까지 따라가 보자.
먼저 과제를 하나 만든다. 에이전트 셋이 차례로 손을 댄다. 플래너가 아직 안 다뤄 본 행동을 끌어낼 주제를 정한다. 딥리서치 에이전트가 실제 문서와 코드 저장소, 이슈를 뒤져 현장의 요구와 제약, "무엇을 하면 완료로 볼지"의 근거를 모은다. 구축 에이전트가 이걸 실행 가능한 과제로 조립한다. 조립된 과제에는 공개 지시문, 에이전트가 조작할 실행 환경, 참조용 정답 풀이, 그리고 겉으로 안 보이는 채점기(정답 여부를 자동으로 판정하는 장치)가 들어간다. 에이전트는 공개된 부분만 보고 환경을 더듬으며 푼다.
과제를 만든 뒤에는, 정답 풀이도 채점기도 숨긴 채 독립 챌린저에게 공개 지시문만 주고 풀려 본다. 그 풀이 기록을 놓고 따진다. 오류가 났는가, 보여선 안 될 정보가 샜는가, 채점이 의도와 어긋나는가. 그리고 가장 중요하게, 애초에 의도한 핵심 작업이 과제 안에 살아 있는가.
환불 합산 함수로 돌아가자. 챌린저가 함수를 직접 짜지 않고도 통과했다면, 환경이 이미 그 함수를 제공하고 있다는 신호다. 연구진은 이렇게 "너무 쉽게 풀린 구간"이 어디서 왔는지 되짚는다. 처음에 깔아 둔 자료 탓인지, 미리 만들어 둔 도구의 동작 탓인지를 추적하는 것이다(논문은 이 작업을 "호라이즌 간극 분석"이라 부른다. 호라이즌은 한 작업을 끝내기까지의 길이, 곧 작업의 호흡을 가리킨다).
여기서 두 경우를 섞으면 안 된다. 에이전트가 효율적으로 잘 풀어서 짧게 끝난 건 그대로 둔다. 환경이 미리 풀어 놔서 할 일이 사라진 것만 골라 고친다. 환불 함수로 치면, 환경이 품고 있던 완성 함수를 걷어내 에이전트가 직접 짜고 디버깅하게 만들되, 그 일을 할 공개 명세는 남긴다. 고친 과제는 다시 챌린저에게 풀려, 되살린 작업이 이번엔 실제 풀이 과정에 들어오는지 확인한다.
통과한 과제는 끝이 아니라 출발점이다. 진화 에이전트가 같은 목표를 유지한 채 과제를 키운다. 규칙은 하나다. 새로 붙인 요구가 기존 풀이로 그냥 통과되면 안 된다. 반드시 추가 분석이나 구현, 검증을 불러와야 한다.
환불 합산 함수를 다시 꺼내자. 1단계를 통과한 그 함수에 예외 입력 처리를 요구로 더 얹는다. 환불 금액이 비어 있거나, 음수처럼 범위를 벗어난 값이 섞인 주문이다. 앞서 짠 풀이는 정상 입력만 처리했으니 그대로는 통과하지 못한다. 에이전트는 먼저 짠 함수를 돌려 보고, 예외 입력에서 터지는 지점을 눈으로 확인한 다음, 어디를 고칠지 정한다. 앞선 실행 결과가 다음 수정을 결정하는 것이다.
키우는 방향은 넷이고, 모두 이 함수 하나로 그려 볼 수 있다.
어느 방향이든 추가 작업이 앞선 작업에 기대도록 설계한다. 실행할 때마다 다루는 값이 바뀌게 만들기도 한다(논문은 이를 "인스턴스 변이"라 부른다. 외운 답이 안 통하게 하는 장치다). 이렇게 같은 행동 패턴이 한 궤적 안에서 여러 단계로 이어진다. 통과한 확장 과제는 다시 다음 확장의 부모가 된다.
흐름은 네 단계다. 과제를 생성하고 → 거기서 나온 풀이 기록을 걸러 선별하고 → 그 기록으로 모델을 학습시키고 → 벤치마크로 성능을 평가한다.
학습에는 강한 "교사 모델"의 풀이를 골라, 더 작은 "기반 모델"이 그대로 흉내 내게 하는 지도학습(SFT, 모범 답안을 보여 주며 따라 하게 하는 가장 기본적인 학습)을 썼다. 이렇게 큰 모델의 풀이를 작은 모델에 옮겨 담는 방식을 "증류"라고 부른다. 그 결과물이 TerminalHorizon-27B다.
과제마다 궤적을 두 개씩 뽑고, 세 가지 필터(부록 F)를 걸러 최종 2,852개를 남겼다(이름은 TerminalHorizon-3K). 학습 전에는 평가 문제가 학습 데이터에 섞이지 않도록 걸러내는 오염 제거도 거쳤다.
데이터가 실제로 길고 다양한지는 숫자로 드러난다. 영역은 칩·물리·천문을 포함한 25개 전문 분야를 하나의 터미널 형식에 담았다. 길이는 어떨까. 여러 오픈소스 합성 방법에서 과제를 300개씩 뽑아 같은 교사·같은 설정으로 돌려 비교했더니, TerminalHorizon 궤적의 평균 상호작용 길이는 52.8턴, 상위 10%는 98턴으로 비교군을 크게 웃돌았다. 터미널 피드백에 끊기지 않고 이어진 "가장 긴 연속 행동 사슬"의 중앙값은 25턴이었다. 길게 가는 동안 행동과 피드백이 토막 나지 않고 맞물렸다는 뜻이다.
결론부터 보자. 이 데이터로 학습한 TerminalHorizon-27B는 12개 벤치마크 전부에서 기반 모델 Qwen3.5-27B를 앞섰다. 특히 터미널을 직접 다루는 코딩 과제에서 폭이 컸다. Terminal-Bench 1.0·2.0·2.1에서 각각 +8.7, +14.2, +13.85포인트 올랐다. 긴 궤적으로 배운 것이 터미널 과제 자체를 더 잘 풀게 했다는 신호다.
반면 실무 자동화는 사정이 다르다. AutomationBench 통과율은 5.5%에서 17.2%로 뛰었다. 오른 폭은 분명 크다. 하지만 올라선 자리가 17.2%라는 점은 그대로 봐야 한다. 이 과제를 처음부터 끝까지 완수하는 비율은 여전히 낮다. 긴 실무 작업이 그만큼 어렵다는 뜻이고, 향상 폭만 보고 "이제 쓸 만하다"고 할 단계는 아니다.
추론력은 깎이지 않았다. MATH-500, GSM8K, AIME, KOR-Bench 모두 떨어지지 않고 오히려 소폭 올랐다. 에이전트 능력을 키우면서 기본 추론을 희생하지 않은 것이다. 다만 MATH-500과 GSM8K는 기반 점수가 이미 천장에 가까워, 오른 폭 자체의 의미는 작다.
데이터 양을 다른 방법과 맞대면 그림이 더 또렷하다. 같은 기반 모델, 같은 실행 틀을 쓰는 Terminal-Universe-27B는 Terminal-Bench 2.0에서 52.8%, TerminalHorizon-27B는 55.8%로 3.0포인트 앞선다. 그런데 학습에 쓴 궤적 수가 다르다. Terminal-Universe는 32.0k, TerminalHorizon은 2,852개로 10분의 1에도 못 미친다.
여기서 관측은 "적은 궤적으로 더 나은 점수가 나왔다"까지다. 그 이상은 조심해서 읽어야 한다. 궤적 수만으로는 전체 학습량이나 데이터 제작 비용까지 비교되지 않는다. 그러니 "무조건 적게 써도 된다"가 아니라, "긴 궤적의 밀도가 궤적 수를 상당 부분 대신했다" 정도로 읽는 게 맞다.
정리하면, 이 실험으로 분명히 말할 수 있는 것은 하나다. 긴 궤적을 골라 흉내 내게 했더니 터미널 과제 성능이 올랐고, 기본 추론은 유지됐다. 아직 가르지 못한 것도 분명하다. 이 모델은 강한 교사의 풀이를 걸러 흉내 낸 증류 모델이라, 점수가 오른 공을 데이터 설계와 교사 실력 중 어느 쪽에 돌릴지 깔끔히 나눌 수 없다. 길이가 올린 것인지, 행동의 다양성이 올린 것인지, 교사 품질이 올린 것인지도 아직 따로 떼어 내지 못했다. 이걸 가르려면 같은 교사로 만든 짧은 궤적과 나란히 비교하는 추가 대조가 필요하다.
저자들이 든 한계에 더해, 읽는 입장에서 짚어 둘 점이 있다.
합성 환경은 아무리 정교해도 현실의 지저분함을 다 담지 못한다. 독립 챌린저로 빈틈을 메우는 설계는 영리하지만, 과제를 내는 교사도 그걸 처음 풀어 보는 독립 챌린저도 LLM이다. 다만 성공 여부를 가리는 채점기는 과제마다 따로 붙는 비공개 검증기로, 정답 여부를 자동 판정하는 장치일 뿐 LLM이 아니다. 궤적을 들여다보는 LLM 심사자(부록 F)는 또 별개여서, 최종 보상도 성공 여부도 입력받지 않는다. 그래도 과제를 만들고 풀어 보는 이 LLM들이 같은 맹점을 공유하면, 그 맹점은 걸러지지 않고 데이터에 그대로 남는다. 게다가 "실행과 채점이 가능해야 한다"는 제약 자체가, 채점기로 깔끔히 판정되는 종류의 문제 쪽으로 데이터를 쏠리게 할 수 있다. 벤치마크 전반의 고른 향상이 정말 "긴 궤적 경험"이 옮겨 간 결과인지, 아니면 고품질·고난도 데이터면 으레 따라오는 효과인지도 더 따져 봐야 가린다.
점수가 못 재는 것도 있다. 벤치마크는 정해진 과제 묶음에서의 성공을 잴 뿐, 실제 운영의 끝없는 변주나 장시간 안정성까지 보장하지 않는다. 그 틈을 메우려는 장치가 RSI(재귀적 자기개선) 사례다. 과제마다 12시간의 연구 시간을 주고, 모델이 처음 떠올린 해법에 머무는지, 아니면 계속 실험하며 방법을 고쳐 가는지를 본다. 부록의 "2048 전략 최적화"처럼 점수를 끝까지 끌어올려야 하는 과제가 여기 쓰인다.
여기서 봐야 할 건 "몇 번 다시 시도했나"가 아니다. 핵심은 앞선 결과가 다음 행동을 실제로 바꿨는지다. 단순 재시도는 같은 전략을 조건만 조금 바꿔 또 돌리는 것이다. 피드백에 따른 수정은 지난 실행에서 나온 점수나 실패 신호를 읽고, 그걸 근거로 전략 자체를 틀어 다음 실행에 반영하는 것이다. 둘은 겉보기 길이가 비슷해도 성격이 다르다. 평균 점수로 환원되지 않는 이 "오래 일하는 능력"을 정성적으로 보려는 장치이니, 해석도 정성적으로 받는 편이 맞다.
한 장면으로 좁혀 보자. 소기업 사장님이 온틀의 AI PM에게 맡긴다. "지난달 공급사 정산 내역이랑 자사몰 주문 데이터가 안 맞는데, 원인 찾아서 맞춰 줘." 명령 한 줄로 끝날 일이 아니다. 두 시스템에서 데이터를 각각 꺼내 훑고, 어디서 어긋나는지 가설을 세우고, 대조 스크립트를 짜 돌리고, 숫자가 이상하면 원본으로 되돌아가 캐고, 맞춘 결과를 사장님이 열어 볼 리포트로 뽑는다. 여러 단계가 맞물린 긴 작업이다.
이 업무의 핵심은 중간에서 벌어진다. 대조 스크립트를 돌렸더니 한 공급사의 3월 정산액이 주문 합계보다 크게 튄다. 잘 배운 에이전트라면 여기서 멈추지 않는다. 그 어긋난 숫자가 다음에 무엇을 조사할지를 바꾼다. 환불 건이 정산에 반영됐는지, 날짜 경계에서 주문이 두 달에 걸쳤는지, 단위가 섞였는지를 새로 파고든다. 어긋난 숫자를 발견한 결과가 다음 조사 대상을 결정하는 것 — 이게 바로 논문이 말하는 "진짜 의존"이다.
온틀의 AI PM은 이미 이런 다단계 업무를 맡아 수행한다. 여기서 가져올 것은 결과 모델이 아니라 방법이다. 그래서 시범으로 검증해 볼 질문부터 처음에 정해 둔다. "짧은 궤적으로 학습한 모델이 이런 이상 신호를 더 자주 놓치는가." 이걸 확인하려면 평가의 눈을 최종 숫자에서 과정으로 옮겨야 한다. 정산 대사처럼 중간 결과가 다음 단계를 좌우하는 업무에서는, 에이전트가 이상 신호를 만났을 때 그 근거를 실제로 확인했는지, 그리고 필요하면 판단을 바꿨는지까지 기록으로 봐야 한다는 뜻이다.
다만 "중간에 뭔가 수정했는가"를 세는 것만으로는 부족하다. 그러면 한 번에 효율적으로 잘 푼 경우까지 "수정 안 했으니 나쁨"으로 깎인다. 이 함정은 논문의 1단계 구분과 똑같다. 그래서 첫 시범은 정산 대사 한 업무로 좁힌다. 과제를 던지고 "통과/실패"만 보는 대신, 그 과제를 처음 보는 별도 에이전트에게 먼저 풀려 보고 "어디서 너무 쉽게 풀렸는가"를 역추적하는 절차를 평가 파이프라인에 끼워 넣는 것부터 시작한다.
학습 방식을 가장 단순한 쪽으로 고정했기 때문입니다. SFT는 "모범 답안을 그대로 따라 한" 결과만 남깁니다. 강화학습처럼 학습 도중 스스로 전략을 바꾸는 요소를 빼 둔 셈이라, 학습 기법 자체의 영리함이 성능에 끼어드는 여지를 줄입니다. 다만 SFT를 썼다고 "데이터의 질"이라는 변수 하나만 또렷하게 떼어 관찰되는 건 아닙니다. 교사 품질, 궤적 길이, 데이터 구성, 학습 토큰량이 한꺼번에 얽혀 있고, 이 논문의 실험도 그것들을 분리해 입증하지는 않았습니다(본문 '결과'·'어디까지 믿을 수 있나'에서 짚은 한계 그대로입니다). SFT 고정은 '학습 기법'이라는 한 축을 단순하게 묶어 둘 뿐, 데이터 쪽 변수들까지 가려 주지는 않습니다.
긴 궤적은 한 건당 처리할 토큰이 많아 건당 비용이 더 듭니다. 이 논문의 반론은 건수를 줄였다는 쪽입니다. 건당 비용이 커지는 대신 건수가 10분의 1 이하로 줄어 상쇄할 여지가 있다는 것이죠. 다만 전체 학습량과 제작 비용까지 공개 비교된 건 아니어서, 실제 손익은 자기 환경에서 따져 봐야 합니다.
원리는 환경을 자동 생성하는 어떤 작업에도 옮길 수 있습니다. 단, 전제가 하나 있습니다. 과제가 실행되고 자동으로 채점될 수 있어야 독립 챌린저에게 풀려 보고 "너무 쉬운 곳"을 가려낼 수 있습니다. 채점이 애매한 영역(가령 글쓰기 품질)에서는 같은 틀을 그대로 쓰기 어렵습니다.