[arXiv 2604.19572] TACO: 터미널 에이전트의 관찰 로그를 자기진화형 규칙으로 압축하는 방법

A Self-Evolving Framework for Efficient Terminal Agents via Observational Context Compression

https://arxiv.org/abs/2604.19572v1

Jincheng Ren, Siwei Wu, Yizhi Li, Kang Zhu, Shu Xu, Boyu Feng, Ruibin Yuan, Wei Zhang, Riza Batista-Navarro, Jian Yang, Chenghua Lin | University of Manchester, MAP, HKUST(GZ), HKUST, Beihang University | arXiv:2604.19572 | 2026년 4월

---

1. 서론: 장기 터미널 에이전트의 컨텍스트 병목

논문은 이 문제를 해결하기 위해 TACO(Terminal Agent Compression)라는 플러그인형 프레임워크를 제안한다. 이름 그대로 핵심은 터미널 에이전트가 매 단계 받는 관찰을 무작정 자연어로 요약하는 것이 아니라, 명령 유형과 과업 문맥에 맞는 구조화된 규칙으로 압축한다는 데 있다. 저자들은 TACO가 기존 agent scaffold를 갈아엎는 시스템이 아니라, 에이전트와 실제 shell 실행 사이에 삽입되는 가벼운 adapter라고 설명한다. 이 점이 중요하다. 실제 배포 환경에서는 backbone을 바꾸는 것보다 관찰 인터페이스를 바꾸는 편이 훨씬 현실적이기 때문이다.

또한 TACO는 고정 휴리스틱에서 멈추지 않는다. 태스크 도중 기존 규칙이 다루지 못하는 장문 출력이 나타나면 새 규칙을 만들고, 압축이 지나쳐 에이전트가 다시 원문을 요구하는 징후가 보이면 더 보수적인 대체 규칙으로 수정한다. 다시 말해 이 논문은 "로그를 줄이는 법"을 제시하는 것이 아니라, 로그를 어떻게 읽어야 다음 단계 추론에 유리한지를 태스크 수행 과정에서 계속 학습하는 외부 계층을 설계한다. 이 글에서는 그 구조가 왜 필요한지, 실제로 어떤 규칙 공간을 쓰는지, 그리고 성능 이득이 단순 token 절감 이상의 의미를 갖는지 차례로 정리하겠다.

이 논문이 겨냥하는 대상은 일반적인 질의응답 챗봇이 아니라, 명령을 실행하고 그 결과를 읽으며 다음 행동을 결정하는 터미널 중심 에이전트다. 소프트웨어 디버깅, 빌드 실패 수정, 패키지 설치, 저장소 탐색, 바이너리 분석 같은 실제 작업에서는 에이전트가 한 번의 답변으로 끝나지 않는다. 수십 번의 명령을 순차적으로 실행하고, 각 명령이 돌려준 터미널 출력을 바탕으로 다시 판단한다. 이때 관행적으로 가장 쉬운 구현은 직전까지의 command-observation pair 전체를 다음 프롬프트에 다시 넣는 방식인데, 논문은 바로 이 습관이 성능과 비용을 동시에 갉아먹는다고 본다.

핵심 이유는 간단하다. 터미널 환경의 출력은 사람이 직접 읽을 때도 대부분 기계적 반복에 가깝다. 예를 들어 apt install은 수백 개 패키지의 Unpacking, Setting up, Get 라인을 길게 늘어놓고, pip install은 Collecting, Downloading, Requirement already satisfied를 반복한다. make나 cmake는 수백 줄짜리 컴파일 명령, 파일 복사 목록, 생성 중간 산출물을 뿜어내며, objdump -d는 해석에 꼭 필요하지 않은 장문의 hex dump를 쏟아낸다. 에이전트가 다음 결정을 위해 진짜로 필요한 정보는 보통 훨씬 적다. 성공 여부, 마지막 상태, 경고, 예외, 특정 심볼, 최종 컴파일 옵션, 실패 지점 같은 일부 신호만 있으면 되는 경우가 많다.

문제는 이런 출력이 한 번만 들어오는 것이 아니라는 점이다. 첫 번째 명령의 로그가 두 번째 단계의 문맥에 다시 들어가고, 첫 번째와 두 번째 로그가 세 번째 단계에 다시 들어가며, 이런 식으로 누적된다. 논문은 이 누적 구조 때문에 총 token cost가 step 수에 대해 사실상 quadratic하게 증가한다고 설명한다. 다시 말해 개별 명령 하나는 그럭저럭 감당할 수 있어도, 장기 과제에서는 이전의 무의미한 로그가 미래의 모든 추론 단계에 계속 비용과 잡음을 남긴다. 단순히 돈이 더 드는 문제에 그치지 않는다. 중요한 에러 한 줄, 핵심 디버깅 신호, 마지막 링크 옵션 같은 정보가 이전 단계의 거대한 진행 로그 사이에 묻히면서 모델의 주의 집중 자체가 흐려진다.

그렇다고 해서 무조건 잘라내면 되느냐 하면 그렇지도 않다. 논문이 강조하는 지점은 터미널 출력의 이질성이다. 어떤 과제에서는 반복되는 줄이 순수 노이즈지만, 다른 과제에서는 같은 형태의 줄이 핵심 단서일 수 있다. 예를 들어 장문의 컴파일 로그는 대부분 제거 가능해 보이지만, 마지막에 남는 -fprofile-arcs나 -ftest-coverage 같은 플래그는 이후 행동을 바꿀 만큼 중요할 수 있다. 바이너리 역공학에서는 수십 줄짜리 어셈블리 중 대부분이 반복이지만, call instruction과 심볼 라벨은 그대로 남아야 한다. 따라서 고정된 휴리스틱, 고정된 요약 프롬프트, 공격적인 truncate는 모두 중요 신호까지 함께 버릴 위험을 안고 있다.

이 논문이 설득력 있는 이유는 여기서 압축을 단순한 절약 기법으로 보지 않고, 에이전트 성능을 올릴 수 있는 인지적 전처리로 재정의하기 때문이다. 저자들의 주장은 직관적이다. 터미널 출력에서 정말 중요한 것만 남겨 주면 같은 모델이라도 더 긴 과제를 안정적으로 풀 수 있고, 동일한 token budget에서도 더 높은 정확도를 낼 수 있다. 즉 이 논문은 "어떻게 더 짧게 만들 것인가"보다 "어떻게 덜 버리고도 더 유효하게 남길 것인가"를 묻는다. 이 차이가 TACO를 일반 요약기와 구분한다.

Figure 1: TACO가 raw history, 시드 규칙, human-curated rules 대비 token 절감과 성능 개선을 함께 보이는 전체 비교

Figure 1의 메시지는 두 겹으로 읽을 수 있다. 첫째, 장기 터미널 궤적에는 사람이 보더라도 덜 중요한 줄이 생각보다 많다. 둘째, 단순히 사람이 규칙을 더 많이 써서 정적으로 관리한다고 자동으로 최적이 되지 않는다. 논문은 6개의 범용 시드 규칙만 둔 Seed Rules, 200개 사람이 손으로 만든 High-Quality Rules도 동기부여 수준에서 함께 비교하지만, 결국 가장 강한 것은 태스크를 수행하는 동안 새 규칙을 만들고, 이후 다른 태스크에 전이시키는 자기진화 구조라고 주장한다.

출력 유형	대표 명령	터미널이 과도하게 늘어나는 이유	에이전트가 실제로 필요한 정보	단순 truncate가 위험한 이유
패키지 설치 로그	apt, apt-get, pip	다운로드 진행률, 패키지별 Unpacking, Setting up, 이미 설치됨 안내가 반복된다.	오류 여부, 최종 성공 여부, 현재 진행 상태, 누락 의존성	마지막 성공 요약이나 E:, ERROR:, Traceback이 뒤쪽에 있는 경우 함께 잘릴 수 있다.
빌드/컴파일 로그	make, cmake, gcc, clang	긴 컴파일 명령행과 다수 파일 복사 목록이 반복된다.	경고, 에러, 링크 실패, 최종 빌드 플래그, 마지막 단계의 산출 메시지	앞쪽만 남기면 중요한 마지막 링크 라인을 잃고, 뒤쪽만 남기면 맥락이 사라진다.
바이너리 분석 로그	objdump, strings, 역공학 도구	의미가 낮은 hex dump와 반복적 명령어 나열이 길게 이어진다.	심볼 라벨, call target, 분기 주소, anti-debugging 단서	중요 심볼은 일부 줄에만 섞여 있으므로 균일한 잘라내기로는 보존이 어렵다.
전송/에코 노이즈	git clone, heredoc, ssh-keygen, openssl	진행률 퍼센트, echo back, 점과 더하기로 된 진행 표시가 길다.	실패 신호, 저장 위치, fingerprint, 실제 작성 성공 여부	진행 노이즈와 오류 신호가 같은 형태의 출력 덩어리 안에 섞일 수 있다.

이 표에서 보듯 저자들이 말하는 문제는 단순히 "터미널이 길다"가 아니다. 더 정확히 말하면 긴 로그 안에서 정보 가치의 밀도가 매우 낮고, 그 낮은 밀도가 미래 단계마다 반복 주입된다는 점이 병목이다. 따라서 좋은 해법은 로그 전체를 뭉뚱그려 요약하는 것이 아니라, 명령 유형과 현재 과업 맥락을 함께 보면서 무엇을 남기고 무엇을 지울지 구조적으로 결정해야 한다.

2. 배경 및 관련 연구: 정적 압축과 자기진화 에이전트의 간극

2.1 Raw history와 정적 압축이 부딪히는 한계

이 논문이 던지는 질문은 비교적 선명하다. 터미널 출력 압축이 단순 비용 절감이 아니라 실제 문제 해결률을 올리는 방향으로 작동할 수 있는가, 그리고 그 압축기를 사람이 일일이 손보지 않고도 태스크 중에 스스로 개선하게 만들 수 있는가가 핵심이다. 저자들은 기존 접근을 크게 세 부류로 바라본다. 첫째는 아무 압축도 하지 않는 raw history 방식이고, 둘째는 고정 프롬프트 기반 또는 사람이 만든 정적 규칙 기반 압축이며, 셋째는 SWE-Pruner 같은 학습 기반 pruning 방식이다. TACO는 이 셋 어디에도 완전히 속하지 않는다.

TACO가 내세우는 첫 번째 차별점은 plug-and-play다. 이미 존재하는 터미널 에이전트 프레임워크 사이에 어댑터를 삽입하는 식으로 붙일 수 있어야 하며, 별도의 모델 재학습 없이도 작동해야 한다. 저자들은 Terminus-2, Mini-SWE-Agent 같은 실제 agent scaffold에 TACO를 통합해 평가하면서, 압축 프레임워크가 본체 에이전트를 대체하는 것이 아니라 관측 인터페이스를 바꾸는 보조 계층이라는 점을 일관되게 유지한다. 이 점은 실무적으로 중요하다. 현장에서 에이전트를 개선하려 할 때 가장 큰 장벽은 backbone을 다시 학습시키는 비용이 아니라, 기존 파이프라인을 유지하면서 얼마나 작은 수정으로 효과를 볼 수 있는가이기 때문이다.

두 번째 차별점은 self-evolving이다. 정적 휴리스틱은 출발점으로는 유용하지만, 새로운 저장소나 낯선 출력 패턴이 등장하면 금방 한계를 드러낸다. 반대로 사람이 200개의 고급 규칙을 미리 만들어 두는 방식은 범용성이 높아 보일 수 있으나, 실제로는 어떤 명령이 어떤 과제 맥락에서 중요한지를 모두 사전에 열거하기 어렵다. TACO는 이를 해결하기 위해, 현재 태스크에서 긴 출력이 발생했는데 기존 규칙이 잡지 못하면 새 규칙을 생성하고, 압축이 너무 공격적이어서 정보 손실이 발생한 정황이 보이면 더 보수적인 대체 규칙으로 수정한다. 즉 규칙 집합 자체가 interaction 중에 살아 움직인다.

세 번째 차별점은 task-aware knowledge reuse다. 논문은 각 태스크에서 얻은 좋은 규칙을 Global Rule Pool에 저장하고, 다음 태스크를 시작할 때 여기서 상위 규칙을 가져와 초기화에 사용한다. 이 구조는 두 종류의 적응을 합친다. 하나는 task 내부 적응이고, 다른 하나는 task 간 전이다. 전자는 지금 당장 맞닥뜨린 출력 패턴에 대응하기 위한 온라인 진화이고, 후자는 과거 태스크에서 검증된 압축 지식을 미래 태스크에 재사용하는 축적 메커니즘이다. 저자들이 보기에 터미널 환경은 너무 이질적이기 때문에 어느 한 축만으로는 부족하다. 한 태스크 안에서만 잘 적응하면 경험이 다음 과제로 넘어가지 않고, 전역 규칙만 믿으면 현재 과제의 세부 패턴을 놓치기 쉽다.

여기서 중요한 것은 TACO가 "요약 모델"을 대체하려는 것이 아니라는 점이다. 요약 모델은 일반적으로 자연어 문장으로 출력을 다시 서술한다. 하지만 터미널 에이전트에서는 원문에 가까운 구조적 흔적이 남는 편이 더 안전할 때가 많다. 예외 메시지, 심볼명, 명령행 옵션, 패키지명, 경로, 에러 코드 같은 것들은 자유 서술로 바뀌는 순간 오히려 해상도가 떨어진다. TACO는 이 때문에 요약문 생성을 전면에 세우지 않고, 정규식 트리거와 보존/삭제 패턴을 갖는 구조화된 규칙 공간을 선택한다. 이 선택이 논문의 성격을 강하게 규정한다.

접근	압축 지식의 원천	장점	약점	논문 속 TACO와의 차이
Raw history	압축 없음	정보 손실 우려가 가장 적고 구현이 단순하다.	중복 로그가 계속 누적되어 긴 과제에서 비용과 잡음이 폭증한다.	TACO는 raw를 기본값으로 두지 않고, critical bypass만 raw 유지한다.
정적 시드 규칙	사람이 만든 범용 휴리스틱	설명 가능하고 빠르게 배치 가능하다.	낯선 출력 패턴에서 coverage가 부족하고 태스크별 세밀 적응이 어렵다.	TACO는 시드 규칙을 쓰되 거기서 멈추지 않고 온라인으로 확장한다.
대규모 human-curated rules	사람이 장기간 구축한 정적 규칙 집합	특정 도메인에서는 강한 품질을 낼 수 있다.	유지보수 비용이 크고 새로운 패턴을 즉시 흡수하기 어렵다.	TACO는 작은 seed에서 시작해 작업 과정 자체를 데이터 수집 장치로 바꾼다.
학습 기반 pruning	추가 학습된 필터	특정 벤치마크에 맞춰 강한 분별력을 얻을 수 있다.	학습 비용이 필요하고 도메인 전이가 제한될 수 있다.	TACO는 training-free를 유지하며 더 넓은 터미널 환경을 노린다.
TACO	시드 규칙 + 태스크 중 진화 + 전역 재사용	설명 가능성, 적응성, 전이성, 비용 절감을 함께 노린다.	초기 진화 비용과 규칙 관리 복잡성이 남는다.	정적 압축기가 아니라 자기증식하는 규칙 프론티어를 만든다.

2.2 Context compression과 self-evolving agent의 접점

관련 연구 맥락에서 보면 이 논문은 두 줄기의 교차점에 선다. 하나는 context compression 계열 연구다. 이 흐름은 긴 입력을 더 짧게 만드는 데 초점을 맞추지만, 대부분은 문서 요약이나 코드베이스 포장처럼 입력 이전 단계의 압축을 다룬다. 다른 하나는 self-evolving agent 계열 연구다. 이 흐름은 에이전트가 스킬이나 정책, 메모리, 도구 선택 규칙을 점진적으로 개선하는 구조에 관심이 있다. TACO는 이 둘을 연결해, 행동 정책이 아니라 관찰 해석 규칙 자체를 진화 대상으로 삼는다.

이 배치가 흥미로운 이유는 터미널 출력이 일반 문서보다 훨씬 조작하기 까다로운 형식이라는 데 있다. 일반 텍스트 요약은 의미 보존이 조금 느슨해도 읽는 사람이 복원할 수 있지만, 터미널 로그는 패키지명, 에러 코드, 플래그, 경로, 심볼, call target처럼 사소해 보이는 토큰 하나가 다음 행동을 갈라놓는다. 그래서 TACO는 요약문 생성보다 원문 보존 규칙을 갖는 반구조화 압축을 택한다. 이 점이 정적 프롬프트 요약이나 단순 truncation과 갈라지는 핵심 차이다.

정리하면 TACO가 답하려는 질문은 압축 기술 자체보다 더 넓다. 이 논문은 관측을 어떻게 메모리로 바꿀 것인가라는 문제를 다룬다. raw observation을 그대로 보존하는 대신, 태스크가 진행되는 동안 점점 더 잘 작동하는 압축 규칙군을 외부 기억으로 축적하면, 에이전트는 같은 모델과 같은 툴셋을 써도 더 적은 잡음 속에서 더 오래 일관되게 추론할 수 있다는 것이 논문의 핵심 주장이다.

3. 방법론: TACO가 에이전트와 터미널 사이에 들어가는 방식

논문은 먼저 문제를 비교적 정석적인 agent notation으로 정리한다. 터미널 관련 태스크를 T, 에이전트를 A, 시점 t에서 실행되는 명령을 C_t, 그 결과 관측을 O_t라고 두면, 다음 명령은 과제 설명과 누적 상태를 바탕으로 생성된다. 저자들이 강조하는 상태 S_t는 이전의 command-observation pair가 시간순으로 쌓인 기록이다. 일반적인 에이전트는 여기서 raw O_t를 그대로 다음 프롬프트에 넣지만, TACO는 이를 압축된 관측으로 바꾼다. 즉 개념적으로는 $C_{t+1}=A(T, S_t)$ 구조를 유지하되, S_t 안의 observation을 $\tilde{O}_t$로 치환하는 방식이다.

이때 중요한 점은 TACO가 본체 에이전트의 planner나 tool-calling 로직을 대체하지 않는다는 것이다. 논문이 제안하는 TACO Adapter는 에이전트와 실제 터미널 실행 사이에 위치한 중간 계층이다. 명령이 실행되면 먼저 raw output을 수집하고, 해당 명령과 현재 active rule set을 기준으로 압축을 수행한 뒤, 그 결과만 에이전트에게 돌려준다. 이 구조는 실용적이다. 기존 터미널 에이전트가 이미 잘 만들어져 있다면, planner를 전부 다시 설계하지 않고도 관측 인터페이스만 개선해 장기 추론 품질을 끌어올릴 수 있기 때문이다.

파이프라인의 시작점은 Rule Initialization이다. 새 태스크가 들어오면 TACO는 전역 규칙 저장소인 Global Rule Pool에서 ranking score가 높은 규칙을 top-k 방식으로 retrieval한다. 논문 기본 설정은 k = 30이다. 여기서 끝이 아니라, LLM이 현재 태스크 설명, 목표, 터미널 상태를 읽고 가져온 규칙들 중 무엇을 그대로 쓸지, 무엇을 수정할지, 무엇을 새로 만들지를 결정한다. 그 결과 실제 태스크 동안 활성화되는 task-specific rule set R_t가 만들어진다. 부록 프롬프트를 보면 실질적인 active rule 수는 대체로 3개에서 7개 범위로 관리된다. 이 설계는 retrieval만으로는 부족한 태스크 특이성을 LLM이 보정하도록 만든다.

실제 압축 단계에서 저자들이 가장 강하게 반복하는 원칙은 Critical bypass다. syntax error, exception trace, 명시적 failure signal처럼 중요한 출력은 압축하지 않고 그대로 남긴다. 논문 표현대로 말하면 error output은 절대 압축하지 않으며, 애매하면 제거보다 보존을 택한다. 이 보수성은 TACO의 안전장치다. 많은 압축 기법이 비용 절감을 위해 지나치게 공격적으로 설계될 때 실패하는데, TACO는 의도적으로 중요한 오류 신호를 건드리지 않는 쪽으로 bias를 둔다. 그래서 TACO의 성공은 "많이 지운다"가 아니라 안전하게 지우고, 덜 위험하게 남긴다는 방향에서 이해하는 편이 맞다.

논문은 또한 이 프레임워크를 단순한 필터 체인으로 설명하지 않는다. active rule set은 태스크를 수행하는 동안 계속 수정될 수 있고, 태스크 종료 후 검증된 규칙은 다시 Global Rule Pool로 환류된다. 따라서 TACO는 한 번 압축하고 끝나는 장치가 아니라, 현재 태스크의 성능과 미래 태스크의 초기화 품질을 동시에 결정하는 순환 루프다. 바로 이 구조 덕분에 논문 제목의 self-evolving이라는 표현이 단순 수사가 아니라 실제 알고리즘의 핵심 동작이 된다.

Figure 2: TACO의 규칙 검색, 압축, complaint, write-back 루프를 보여 주는 전체 구조

Figure 2를 보면 TACO가 왜 규칙 기반인지도 드러난다. 요약문 생성 방식이었다면 태스크 간 재사용이 어렵고, "이 요약이 왜 이렇게 만들어졌는가"를 추적하기도 힘들다. 반면 규칙 기반 구조에서는 어떤 명령 패턴이 어떤 보존 규칙과 삭제 규칙에 의해 처리되었는지를 계속 누적할 수 있다. 다시 말해 TACO는 출력 내용을 압축할 뿐 아니라, 압축 경험 자체를 구조화된 자산으로 저장한다. 이 그림을 메모리 관점에서 읽으면 더 분명하다. TACO는 로그 원문을 단순히 줄이는 것이 아니라, 다음 태스크에서 재사용 가능한 압축 지식을 따로 축적해 관찰 처리 방식 자체를 외부 기억으로 승격한다.

단계	입력	핵심 연산	산출물	의미
Global retrieval	전역 규칙 풀, 태스크 설명	ranking score 기준 top-k 규칙을 가져온다.	후보 규칙 집합	과거 태스크의 검증된 압축 지식을 초기값으로 활용한다.
Task-specific initialization	후보 규칙, 태스크 목표, 현재 상태	LLM이 규칙 선택, 수정, 신규 생성	active rule set R_t	같은 전역 규칙이라도 현재 과제에 맞게 재배치한다.
Critical check	명령 C_t와 raw output O_t	오류, 예외, 실패 신호 여부 판단	raw 유지 또는 압축 경로 선택	안전성이 필요한 경우 압축기를 우회한다.
Rule-based compression	비critical output, active rules	trigger, keep, strip, line budget 적용	compressed observation	다음 단계 컨텍스트를 더 밀도 높은 형태로 만든다.
Intra-task evolution	미포착 장문 출력 또는 과압축 불만 신호	새 규칙 생성 또는 더 보수적인 규칙으로 교체	갱신된 active rules	태스크 안에서 즉시 적응한다.
Global write-back	태스크 종료 후 성능 통계	효과적 규칙만 전역 풀에 저장, 불만 규칙은 제거	업데이트된 Global Rule Pool	다음 태스크의 초기화 품질이 점차 좋아진다.

이 구조를 한 문장으로 줄이면, TACO는 observation을 더 짧게 만드는 시스템이 아니라 observation을 어떻게 기억할지 학습하는 외부 계층이다. 논문의 실험이 설득력을 가지는 이유도 여기에 있다. TACO는 에이전트의 IQ를 바꾸지 않지만, 그 에이전트가 매 단계 읽게 되는 환경 피드백의 밀도를 올려 준다.

3.1 구조화된 규칙 공간과 보수적 압축 설계

TACO 방법론에서 가장 중요한 설계 선택 하나를 꼽으라면 나는 규칙을 자유 코드가 아닌 구조화된 specification으로 제한한 점을 들고 싶다. 논문 부록을 보면 규칙은 JSON 형태의 스키마로 저장되며, 대표 필드로는 rule_id, trigger_regex, description, keep_patterns, strip_patterns, keep_first_n, keep_last_n, max_lines, summary_header, priority, 그리고 confidence나 usage count 같은 통계값이 포함된다. 이 설계는 규칙 공간을 충분히 표현력 있게 유지하면서도, 임의 코드 실행이나 지나치게 불투명한 압축 로직으로 흘러가는 것을 막는다.

이 구조의 장점은 세 가지다. 첫째, 해석 가능성이다. 어떤 규칙이 왜 발동했고 무엇을 남겼는지 사람이 읽을 수 있다. 둘째, 재사용 가능성이다. 특정 태스크에서 얻은 규칙을 전역 풀에 저장했다가 다른 태스크에서 다시 쓸 수 있다. 셋째, 안전성이다. 자유 요약은 표현이 바뀌는 순간 정확한 에러 문자열이나 경로 정보가 사라질 수 있지만, 규칙 기반 압축은 원문 줄을 지우거나 남기는 방식에 가까워서 의미 보존 경계가 더 명확하다. 따라서 TACO는 요약기가 아니라 구조적 필터이면서, 동시에 태스크 적응형 규칙 생성기이기도 하다.

각 필드의 역할도 명확하다. trigger_regex는 어떤 명령이 이 규칙의 적용 대상인지 판별한다. keep_patterns는 반드시 살려야 할 문자열 패턴이다. 예를 들어 fatal, error, warning, Traceback, Successfully installed 같은 신호가 여기에 들어간다. strip_patterns는 제거 가능한 줄 패턴을 지정한다. keep_first_n과 keep_last_n는 앞부분과 뒷부분의 일부 줄을 보존하여 맥락을 유지한다. max_lines는 출력이 지나치게 길어졌을 때 최종 line budget을 제한한다. summary_header는 사용자와 에이전트 모두가 지금 일부 로그가 압축되었다는 사실을 알 수 있게 해 주는 짧은 표시다. 이런 필드 조합은 매우 보수적인 필터를 설계하기에 적합하다.

필드	의미	실무적 역할	왜 중요한가
rule_id	규칙 고유 이름	사용 통계와 전역 풀 관리에 쓰인다.	어떤 규칙이 반복적으로 효과를 냈는지 추적할 수 있다.
trigger_regex	적용 명령 식별	apt, pip, git, make, objdump 같은 명령 패턴에 맞춰 발동한다.	압축은 출력만이 아니라 명령 유형과 함께 봐야 정확하다.
keep_patterns	반드시 남길 줄 패턴	에러, 경고, 최종 성공 요약, 특정 심볼을 보호한다.	과압축을 막는 핵심 안전장치다.
strip_patterns	제거 가능한 줄 패턴	진행률, 다운로드, 반복 파일 목록, 점 진행 표시를 없앤다.	길이 절감의 직접적 원천이다.
keep_first_n / keep_last_n	앞뒤 일부 줄 보존	출력의 시작과 끝 맥락을 최소한 유지한다.	단순 필터로 생기는 문맥 단절을 줄여 준다.
max_lines	최종 line budget	너무 긴 출력이 남지 않도록 상한을 둔다.	규칙이 발동하더라도 무한정 길어지는 일을 막는다.
summary_header	압축 안내 표시	"git output compressed" 같은 짧은 헤더를 남긴다.	압축 사실을 숨기지 않고 노출해 해석 가능성을 높인다.
priority, confidence, usage	적용 우선순위와 품질 통계	전역 풀 정렬과 write-back 판단에 활용된다.	좋은 규칙을 더 자주 불러오게 만드는 기억 장치다.

논문은 전역 풀의 초기값으로 완전한 zero-start를 택하지 않고, 6개의 seed rule을 사용한다. 범주는 git noise, heredoc echo, pip install, apt install/update/upgrade, compiler output, openssl 또는 ssh-keygen 또는 gpg progress다. 여기서 중요한 포인트는 저자들이 초기 변동성을 줄이기 위해 최소한의 범용 규칙만 두었다는 점이다. 다시 말해 TACO는 아무 준비 없이 모든 것을 그 자리에서 발견하게 만드는 방식이 아니라, 가장 흔한 패턴 몇 가지를 출발점으로 깔고 그 위에서 진화한다.

시드 규칙	대상 명령/출력	주로 지우는 것	반드시 남기는 것	설계 의도
seed_git_noise	git clone, fetch, pull, push, checkout, submodule	Enumerating, Counting, Compressing, Receiving, Resolving deltas, hint 블록	fatal, error, warning, Cloning into, branch 전환 결과	전송 진행 노이즈는 지우되 저장소 상태 변화는 남긴다.
seed_heredoc	cat 또는 tee 기반 heredoc 작성	터미널이 echo back 하는 > 프롬프트 줄	bash 오류, syntax error, No such file or directory	파일 쓰기 중복 에코를 제거하되 실패 신호는 살린다.
seed_pip_install	pip install	Collecting, Downloading, Requirement already satisfied, Using cached	ERROR, error, Successfully installed, Traceback, WARNING	설치 진행률은 없애고 결과 판단에 필요한 줄은 유지한다.
seed_apt_install	apt install, update, upgrade	Setting up, Unpacking, Get, Preparing to unpack	E:, Err:, dpkg error, Unable to locate package, Reading package lists	수백 패키지 진행 로그를 줄여도 실패 진단 가능성을 보존한다.
seed_compiler_output	gcc, g++, clang, cc, make, cmake	200자 이상 긴 컴파일 명령행	error, warning, undefined reference, fatal error, ld 메시지	장문의 명령행을 줄이되 실패 지점을 절대 버리지 않는다.
seed_openssl	openssl, ssh-keygen, gpg	점과 더하기로 구성된 진행 표시	error, key fingerprint, identification saved, generating 메시지	암호키 생성의 장문 진행 노이즈를 숨기고 결과 정보는 남긴다.

부록의 진화된 예시 규칙도 흥미롭다. 예를 들어 7z extraction 규칙은 압축 해제 성공 또는 Wrong password 같은 핵심 신호를 남기면서 파일 목록과 진행 정보를 제거하고, nginx setup 관련 규칙은 서버 시작 여부, 인증서 생성 실패, service failed 같은 줄은 살리면서 openssl 진행 노이즈와 주변 부가 출력을 줄인다. 이런 예시는 TACO가 단순히 "길면 자른다"가 아니라, 명령이 수행하는 의미론적 역할에 맞춰 무엇이 중요한지를 학습 가능한 규칙 형태로 축적한다는 점을 보여 준다.

또 하나 인상적인 부분은 규칙 생성 프롬프트 자체가 상당히 보수적이라는 점이다. 논문은 high-output command에 대해서만 규칙을 만들고, ls, cat, echo, pwd, cd처럼 짧은 출력 명령에는 규칙을 만들지 말라고 명시한다. 여기에 더해 에러는 절대 압축하지 말 것, 확신이 없으면 keep 할 것이라는 공통 제약을 건다. 이 철학 덕분에 TACO는 적극적인 압축기라기보다, 안전을 우선하는 선별적 압축기에 가깝다.

3.2 uncovered output, complaint, global write-back이 만드는 온라인 진화

TACO의 진짜 차별점은 규칙 형식 그 자체보다 규칙이 어떻게 태스크 중에 진화하는가에 있다. 첫 번째 트리거는 uncovered output이다. 현재 긴 출력이 발생했는데 어떤 active rule도 적용되지 않았다면, 논문은 이를 "새로운 패턴을 만났다"는 신호로 본다. 이때 LLM이 그 출력을 읽고 신규 규칙을 만들어 이후 step부터 바로 사용한다. 즉 TACO는 긴 로그를 처음 보는 순간 단순히 당황하는 것이 아니라, 그 로그를 미래에 더 잘 다루기 위한 규칙으로 전환한다. 이 메커니즘 덕분에 한 태스크 안에서도 규칙 집합이 점점 해당 과업의 문법에 가까워진다.

두 번째 트리거는 더 흥미로운데, 바로 implicit over-compression complaint다. 논문은 에이전트가 압축된 출력을 보고 나서 full output을 다시 요구하거나, 누락된 정보를 찾으려 같은 명령을 재실행하거나, 명백히 정보 부족을 드러내는 행동을 하면 이를 압축 실패 신호로 해석한다. 그러면 해당 출력을 실제로 바꾼 규칙을 추적해 freeze 또는 suppress하고, LLM에게 더 보수적인 replacement rule을 생성하게 한다. 이 설계는 human feedback 없이도 규칙을 더 안전한 방향으로 수정할 수 있게 해 준다. 다시 말해 TACO는 성공적 압축뿐 아니라 잘못된 압축의 흔적에서도 배운다.

세 번째 단계는 태스크가 끝난 뒤의 Global Rule Pool Evolution이다. 모든 규칙을 전역 풀에 무조건 저장하는 것은 아니다. 논문에 따르면 적어도 한 번 이상 성공적으로 적용되었고, 태스크 종료 시 confidence가 임계값 이상인 규칙만 write-back된다. 반대로 complaint를 받은 규칙은 해당 태스크에서 confidence가 0으로 처리되며, 전역 풀에서도 제거 대상으로 취급된다. 저자들이 이 구조를 택한 이유는 분명하다. 전역 저장소는 무한한 기억창고가 아니라, 많이 쓰였고 안전성이 검증된 규칙만 살아남는 진화적 메모리여야 한다는 것이다.

이 전역 풀에서 규칙을 불러오는 기준은 ranking score다. 논문은 이를 $R_{gs}(r)=c_r^g (n_r + 1)$ 형태로 정의한다. 여기서 c_r^g는 global confidence, n_r는 누적 성공 적용 횟수다. 직관적으로 보면, 자주 쓰였고 안전했던 규칙일수록 다음 태스크에서 다시 불려올 가능성이 커진다. 이 점이 중요한 이유는 TACO가 태스크 간 전이를 "벡터 임베딩 검색"이나 "유사 과제 retrieval"에만 의존하지 않고, 사용 이력과 안전성 통계를 결합한 간단한 운영 규칙으로 처리한다는 데 있다. 상당히 실용적인 설계다.

논문은 자기진화를 한두 번의 데이터셋 순회로 끝내지 않는다. 같은 데이터셋을 여러 round 반복 실행하며 rule frontier를 점차 안정화시키는데, 병렬 배치 크기 N이 여기서 중요한 역할을 한다. 작은 N은 새 규칙이 더 빨리 다음 태스크에 전파되어 정확도 면에서 유리하고, 큰 N은 병렬 처리량과 시간 효율에서 유리하다. 즉 TACO는 단순한 online adaptation이 아니라, 온라인 적응과 오프라인 축적을 섞은 느린 자기개선 시스템으로 보는 편이 맞다.

이 과정이 언제 수렴했는지 판단하기 위해 저자들은 Retention이라는 지표를 도입한다. 연속 두 번의 run에서 Global Rule Pool의 Top-30 규칙이 얼마나 겹치는지를 비율로 측정하는 방식이다. 식으로 쓰면 $\mathrm{Retention}_K^{(i)}=\frac{|\mathrm{TopK}(R_g^{(i-1)}) \cap \mathrm{TopK}(R_g^{(i)})|}{K}$이며, 본문에서는 K = 30을 쓴다. 성능 지표 자체의 상승 여부보다, 효과적인 규칙 프론티어가 더 이상 크게 바뀌지 않는지가 자기진화 수렴의 더 직접적 신호라는 해석이다. 이 관점은 꽤 흥미롭다. 모델 정확도는 데이터셋 변동과 샘플링 노이즈의 영향을 크게 받지만, 전역 규칙 집합의 상위 구성이 안정화되는 순간은 시스템이 더 이상 새로운 압축 지식을 많이 발견하지 못한다는 뜻이기 때문이다.

트리거 또는 통계	무엇을 의미하는가	TACO의 반응	시스템 차원의 효과
긴 출력인데 적용 규칙 없음	현재 active rules가 새로운 패턴을 커버하지 못함	LLM이 새 규칙 생성	태스크 내부 적응이 시작된다.
full output 재요청 또는 명령 재실행	과압축으로 정보 손실이 발생했을 가능성	문제 규칙 freeze, 더 보수적 replacement rule 생성	실수한 압축 규칙이 장기적으로 축적되는 것을 막는다.
성공 적용 횟수 증가	해당 규칙이 실제 태스크에서 유용했음	confidence와 usage 통계를 갱신	향후 retrieval 우선순위가 올라간다.
complaint 발생	안전성이 낮은 규칙일 수 있음	confidence를 낮추거나 제거 후보로 처리	전역 풀 오염을 줄인다.
Retention 상승	상위 규칙 집합이 run 사이에서 덜 바뀜	자기진화 수렴 신호로 사용	추가 round의 기대 이득을 판단할 수 있다.
작은 batch size N	새 규칙 전파가 빠름	정확도 측면에서 유리	학습은 빠르지만 처리량은 낮아질 수 있다.

이 메커니즘을 종합하면 TACO는 단순한 압축기가 아니라 압축에 실패하는 방식까지 포함해 규칙 품질을 업데이트하는 자기교정 시스템이다. 터미널 에이전트 연구에서 이런 설계가 중요한 이유는, 환경 출력을 모델 내부에서 end-to-end로 통제하기 어렵기 때문이다. 관측의 질을 올리는 외부 계층이 스스로 개선되면, 본체 에이전트는 같은 reasoning capability를 써도 더 나은 작업 조건을 얻는다.

방법론을 조금 더 추상화하면 TACO는 세 층으로 분해된다. 첫째는 태스크 시작 전 전역 규칙 검색과 초기화다. 둘째는 실행 중 observation compression과 online rule evolution이다. 셋째는 태스크 종료 후 검증된 규칙을 전역 기억으로 환류하는 과정이다. 이 세 층을 함께 보면 TACO는 단순 압축기가 아니라, 에이전트의 실행 로그를 다루는 일종의 memory formation policy처럼 읽힌다. 무엇을 그대로 남길지, 무엇을 버릴지, 그리고 어떤 경험을 다음 태스크의 prior로 축적할지를 규칙 형태로 결정하기 때문이다.

수식 수준에서도 이 구조는 꽤 단정하다. 명령 생성은 $C_{t+1}=A(T, S_t)$로 표현되고, non-critical observation은 $ ilde{O}_t=F_{R_t}(O_t\mid C_t)$로 압축된다. 전역 규칙 순위는 $R_{gs}(r)=c_r^g (n_r+1)$처럼 confidence와 누적 성공 횟수를 함께 반영하며, 자기진화의 수렴은 $\mathrm{Retention}_K^{(i)}=rac{|\mathrm{TopK}(R_g^{(i-1)})\cap\mathrm{TopK}(R_g^{(i)})|}{K}$로 본다. 논문의 중요한 메시지는 이 식들이 복잡해서가 아니라, 압축을 비용 절감 휴리스틱이 아니라 추적 가능한 운영 상태로 다룬다는 데 있다.

4. 실험 설정: TerminalBench와 추가 벤치마크를 어떻게 구성했는가

4.1 데이터셋 및 벤치마크: 왜 여러 종류의 CLI 과제를 함께 봤는가

실험은 비교적 폭넓다. 메인 벤치마크는 TerminalBench 1.0과 TerminalBench 2.0이며, 여기에 SWE-Bench Lite, CompileBench, DevEval, CRUST-Bench를 추가한다. 메인 메시지는 분명하다. TACO가 특정 데이터셋 하나에서만 먹히는 꼼수가 아니라, 코드 수정, 빌드, 개발 도구 사용, 저장소 탐색, 바이너리 과제 등 서로 다른 터미널 과제에서도 작동해야 한다는 것이다. 이 벤치마크 구성이 중요한 이유는 압축 규칙의 전이성을 시험하기 때문이다. apt나 pip에서 배운 규칙이 다른 개발 과제에서도 유효한지, 컴파일 로그를 줄이는 기술이 장문 바이너리 출력에서도 원리를 공유하는지, 논문은 여러 벤치마크를 통해 이를 검증하려고 한다.

4.2 구현 세부사항: scaffold, 모델군, 진화 비용

에이전트 scaffold는 두 종류가 중심이다. Terminus-2는 TerminalBench, CompileBench, DevEval, CRUST-Bench 평가에 사용되고, Mini-SWE-Agent는 SWE-Bench Lite에 사용된다. 이 배치는 TACO가 특정 host agent와 묶여 설계된 것이 아니라는 점을 뒷받침한다. 한편 본문 메인 표에는 GPT-5.2, Claude-Opus-4.5, Gemini-3-Pro-Preview 같은 강한 폐쇄형 모델들의 leaderboard 성능도 함께 제시되지만, TACO를 실제로 붙여서 비교한 핵심 결과는 주로 6개의 강한 오픈 모델에서 나온다. 즉 논문은 "우리 모델이 최고다"보다, 같은 backbone에 TACO를 붙였을 때 어떻게 바뀌는가를 보여 주는 데 초점을 둔다.

실험에 사용된 주요 오픈 모델은 Qwen3-Coder-480B, MiniMax-M2.5, DeepSeek-V3.2, Qwen3-32B-Instruct, Qwen3-14B-Instruct, Qwen3-8B-Instruct다. 크고 강한 모델에서뿐 아니라 상대적으로 작은 모델에서도 개선되는지를 보여 주려는 구성이다. 이 선택은 합리적이다. 큰 모델은 본래 긴 컨텍스트를 어느 정도 견디지만, 여전히 중복 로그의 부담을 받는다. 작은 모델은 더 짧은 컨텍스트 여유와 약한 견고성을 가지기 때문에, 좋은 압축이 되면 오히려 상대적 이득이 더 크게 나타날 수 있다.

하이퍼파라미터는 논문 전체 메시지와 잘 맞아떨어진다. 전역 규칙 retrieval은 top-k = 30, 병렬 batch size는 N = 4, convergence 분석도 K = 30 retention을 사용한다. 성능 안정성 계산에는 W = 3 runs의 rolling standard deviation 창을 사용한다. 또 self-evolution을 한 full round 돌리는 데 약 4일이 걸린다고 밝히는데, 이는 TACO가 training-free이지만 결코 공짜는 아니라는 점을 보여 준다. 즉 비용 구조가 학습 비용에서 진화 비용으로 이동한 셈이다.

4.3 베이스라인과 평가 축: 무엇을 얼마나 공정하게 비교했는가

평가 지표도 다층적이다. 단순 정확도만 보는 것이 아니라, step당 token 수, 동일 token budget에서의 정확도, pass@k, 추가 벤치마크로의 전이 성능, ablation, convergence 검증, 하이퍼파라미터 선택까지 포괄한다. 이런 설계는 좋다. 만약 압축이 정확도는 올리지만 token 비용을 더 키운다면 실용성이 떨어지고, 반대로 token은 줄지만 성능이 깨진다면 의미가 없다. 논문은 이 균형을 전면에 내세운다.

평가 축	벤치마크 또는 설정	주요 에이전트 scaffold	논문이 여기서 확인하려는 것
메인 정확도	TB 1.0, TB 2.0	Terminus-2	TACO가 주력 터미널 벤치마크에서 실제 성공률을 올리는가
소프트웨어 이슈 해결	SWE-Bench Lite	Mini-SWE-Agent	저장소 수정 중심 환경에도 전이되는가
컴파일 중심 과제	CompileBench	Terminus-2	빌드/컴파일 로그 압축이 효율을 높이는가
개발 환경 상호작용	DevEval	Terminus-2	다양한 CLI 작업에도 일반화되는가
보안/역공학 관련 과제	CRUST-Bench	Terminus-2	장문 역공학 출력에서도 의미 있는 압축이 가능한가
동일 예산 분석	TB 2.0, 14M~120M budget	Terminus-2	단순 더 많이 쓰는 것이 아니라 같은 예산 안에서 더 잘 푸는가
Best-of-K	TB 2.0, k = 4~8	Terminus-2	탐색 다양성과 잠재적 해답 품질도 좋아지는가
수렴 검증	Retention vs rolling std	Self-evolution 반복 실행	규칙 프론티어 안정화가 실제 성능 안정화와 연결되는가

하이퍼파라미터	기본값	의미	실무적 해석
top-k retrieval	30	전역 풀에서 태스크 초기화에 가져오는 규칙 수	너무 작으면 coverage가 부족하고, 너무 크면 선택 비용이 늘어난다.
active rules	대체로 3~7개	실제 태스크 동안 켜지는 규칙 수	규칙 수를 제한해 선택 비용과 오작동 범위를 함께 통제한다.
batch size N	4	병렬 self-evolution 실행 단위	정확도와 처리량의 균형점으로 제시된다.
Retention K	30	수렴 판정에 쓰는 상위 규칙 집합 크기	너무 작으면 변동성이 크고, 너무 크면 핵심 프론티어 감지가 흐려질 수 있다.
stability window W	3 runs	rolling std 계산 창	성능 안정화를 너무 단기 잡음에 휘둘리지 않게 본다.
self-evolution round cost	약 4일	한 full round 실행 시간	TACO가 training-free여도 운영 비용은 존재함을 보여 준다.

비교 축을 더 풀어 쓰면, 논문이 핵심적으로 겨냥하는 베이스라인은 원본 agent scaffold다. 여기에 동기부여 그림에서는 Seed Rules와 High-Quality Rules 같은 정적 규칙 압축도 함께 제시되지만, 메인 표의 중심 비교는 어디까지나 "같은 backbone + 같은 scaffold에서 TACO만 붙였을 때"다. 이 때문에 TACO의 효과를 순수하게 보기에는 좋지만, 동시에 학습 기반 pruning이나 강한 요약형 압축기와의 직접 대결은 아직 남는다고 볼 수 있다. 저자들이 평가지표를 accuracy, step당 token, 동일 예산 정확도, pass@k, transfer, ablation, convergence로 넓게 가져간 것도 이 지점을 보완하기 위한 선택으로 읽힌다.

이처럼 실험 설정은 TACO를 단순한 논문 아이디어로 포장하지 않고, 실제 운영 가능한 시스템 구성으로 다룬다. 어느 규칙을 어떻게 불러오고, 얼마나 오래 돌리고, 수렴을 어떻게 판단할지까지 모두 명시했기 때문에, 이 논문은 아이디어 제안뿐 아니라 운영 정책 제안의 성격도 갖는다.

실험 설계에서 눈에 띄는 점은 저자들이 TACO를 특정 단일 에이전트 벤치마크용 트릭으로 보이게 하지 않으려 애쓴다는 것이다. 메인 평가는 TerminalBench 1.0과 2.0이지만, 추가로 SWE-Bench Lite, CompileBench, DevEval, CRUST-Bench까지 넣어 코드 수정, 빌드, 디버깅, 장기 셸 상호작용 전반으로 전이되는지 확인한다. 즉 "터미널 로그 압축"이 한 데이터셋에서만 먹히는 편법이 아니라, 다양한 CLI 작업에서 공통 병목을 건드리는지 보여 주려는 설계다.

또 하나의 포인트는 backbone을 바꾸지 않고 여러 모델에 꽂아 본다는 점이다. Qwen3-Coder-480B, MiniMax-M2.5, DeepSeek-V3.2 같은 큰 모델뿐 아니라 Qwen3-32B, 14B, 8B 같은 비교적 작은 모델도 포함된다. 이렇게 해야 TACO의 효과를 "강한 모델만 더 강하게 만든다"가 아니라, 관찰 인터페이스를 바꾸면 모델 규모와 무관하게 decision loop의 효율이 달라진다는 주장으로 읽을 수 있다.

5. 주요 실험 결과: TerminalBench와 동일 예산 비교에서 드러난 TACO의 이득

5.1 TerminalBench 메인 결과: 6개 모델 전부에서 정확도 상승

메인 결과는 명확하다. TB 1.0과 TB 2.0에서 TACO는 표에 제시된 6개 오픈 모델 전부를 개선한다. 향상폭은 모델마다 다르지만, 논문이 본문에서 강조하듯 대체로 1%에서 4% 수준의 안정적 개선이 나타난다. 특히 강한 모델인 MiniMax-M2.5와 DeepSeek-V3.2도 꾸준히 올라가고, 상대적으로 작은 Qwen3-14B와 Qwen3-32B 계열에서는 향상폭이 더 크게 나타난다. 이는 압축이 단순 비용 절감이 아니라, 중소형 모델에서 특히 더 중요한 문맥 정리 효과를 줄 수 있음을 시사한다.

모델	TB 1.0 Baseline	TB 1.0 TACO	TB 1.0 변화	TB 2.0 Baseline	TB 2.0 TACO	TB 2.0 변화
Qwen3-Coder-480B	37.50	38.50	+1.00	23.90	25.86	+1.96
MiniMax-M2.5	42.30	45.25	+2.95	42.80	44.16	+1.36
DeepSeek-V3.2	43.93	46.25	+2.32	40.62	42.77	+2.15
Qwen3-32B-Instruct	11.25	14.13	+2.88	3.92	7.48	+3.56
Qwen3-14B-Instruct	5.23	11.25	+6.02	4.04	6.15	+2.11
Qwen3-8B-Instruct	8.86	9.22	+0.36	1.43	3.67	+2.24

이 표에서 특히 읽을 만한 지점은 두 가지다. 첫째, 향상폭이 모델 크기와 단순히 정비례하지 않는다. Qwen3-14B가 TB 1.0에서 +6.02로 가장 큰 개선을 보이는 반면, Qwen3-Coder-480B는 +1.00에 그친다. 이는 TACO의 가치가 절대적으로 성능이 낮은 모델을 끌어올리는 것만이 아니라, 모델이 이미 가지고 있는 능력이 더 잘 발휘되도록 관측 공간을 정리하는 데 있음을 보여 준다. 둘째, 모든 모델에서 일관되게 플러스라는 점이 중요하다. 압축이 본질적으로 정보 손실을 수반한다면 일부 모델에서는 반드시 역효과가 나와야 하는데, 여기서는 전반적으로 그렇지 않다.

5.2 토큰 효율과 동일 예산 비교: 더 짧게 써서가 아니라 더 밀도 높게 써서 이긴다

정확도 개선만으로는 충분하지 않다. TACO가 정말 효율적인지 보려면 token 사용량을 함께 봐야 한다. TB 2.0 기준 Compression efficiency analysis를 보면, 큰 모델에서는 정확도가 오르면서도 step당 prompt token이 감소한다. Qwen3-Coder-480B는 21,718 → 19,965로 약 8.1% 줄고, DeepSeek-V3.2는 35,038 → 30,939로 약 11.7% 줄어든다. MiniMax-M2.5는 거의 변동이 없지만 그래도 소폭 감소한다. 즉 적어도 강한 모델에서는 TACO가 정확도와 비용 사이에서 꽤 건강한 trade-off를 형성한다.

모델	정확도 Baseline	정확도 TACO	평균 step 수 변화의 핵심 해석	Token/Step Baseline	Token/Step TACO	변화율
Qwen3-Coder-480B	23.3	25.8	성능이 오르면서도 step당 문맥 부담이 줄었다.	21,718	19,965	-8.1%
DeepSeek-V3.2	40.6	42.7	긴 로그를 더 효과적으로 줄여 가장 뚜렷한 절감을 보였다.	35,038	30,939	-11.7%
MiniMax-M2.5	42.8	44.1	step당 token은 거의 유지되지만 정확도는 상승했다.	28,631	28,559	-0.3%
Qwen3-32B-Instruct	3.9	7.4	더 오래 문제를 풀게 되면서 총 step이 증가했다.	8,472	8,735	소폭 증가
Qwen3-14B-Instruct	4.0	6.1	정확도 상승과 함께 token/step은 완만히 줄었다.	9,663	9,393	-2.8%
Qwen3-8B-Instruct	1.4	3.6	baseline에서 조기 실패하던 과제를 더 오래 탐색해 step 수가 크게 늘었다.	9,579	9,583	거의 동일

이 결과를 해석할 때 주의할 점이 있다. 작은 모델에서 step당 token이 줄지 않거나 오히려 소폭 늘 수 있다는 사실이 TACO의 실패를 뜻하지는 않는다. 논문 해석처럼, baseline에서는 일찍 실패해 금방 종료되던 과제가 TACO를 쓰면 더 오래 진행될 수 있다. 즉 로그 압축 덕분에 모델이 조금 더 버티며 탐색할 수 있게 되면, 총 step 수가 늘어나 token 사용 양상이 달라질 수 있다. 이는 "압축 = 무조건 토큰 감소"라는 단순한 그림보다, 압축 = 같은 예산으로 더 오래 또는 더 잘 탐색이라는 그림으로 읽어야 함을 보여 준다.

Figure 3: 동일 token budget에서 TACO가 더 높은 task success를 보이는 비교 결과

Figure 3은 이 해석을 더 직접적으로 뒷받침한다. 토큰 총량을 14M에서 120M 사이로 맞춘 조건에서도 TACO가 항상 baseline보다 높은 정확도를 보인다는 것은, 향상이 단순히 "더 많이 써서 더 잘했다"가 아님을 뜻한다. 오히려 같은 예산 안에서 더 가치 높은 컨텍스트를 구성했기 때문에 성능이 올랐다고 보는 편이 맞다. 터미널 에이전트 연구에서 이 점은 중요하다. 컨텍스트 압축이 잘 되면 추론 단계 수를 무작정 늘리지 않고도, 더 유효한 정보로 decision loop를 유지할 수 있기 때문이다.

6. 추가 분석 및 Ablation Study: 수렴, 전이, 사례가 보여 주는 것

6.1 Best-of-K, 수렴, 하이퍼파라미터: 규칙 프론티어가 안정되면 성능도 안정된다

TB 2.0의 pass@k 결과는 TACO가 단순 single-run 최적화가 아니라는 점을 보여 준다. k = 4, 5, 6, 7, 8 전 구간에서, 그리고 여섯 모델 전부에서 TACO의 pass@k가 baseline보다 높다. 저자들은 이를 단순 정확도 향상이 아니라 잠재적 해답 다양성의 개선으로 해석한다. 나도 이 해석에 동의한다. 중복 로그가 줄면 모델은 앞선 잘못된 출력에 덜 끌려가고, 여러 독립 시도에서 더 다양한 유망 경로를 탐색할 여지를 얻는다.

Figure 4: 여러 backbone 모델에서 TACO가 pass@k와 해결률을 끌어올리는 실험 비교

수렴 검증도 흥미롭다. 저자들은 자기진화 방법의 특성상 Global Rule Pool의 변화량 자체가 수렴 신호가 될 수 있다고 보고, Top-30 rule retention을 도입했다. Figure 5에 따르면 retention이 높아지는 시점 이후 실제 task accuracy의 rolling standard deviation이 대체로 2.0 이상에서 1.0 근처로 감소한다. 이는 규칙 프론티어의 안정화와 성능 안정화가 상관관계를 갖는다는 주장이다. 절대적인 이론 보장은 아니지만, 운영 측면에서는 매우 유용한 발상이다. self-evolution을 언제 멈출지 판단할 때 단순 평균 정확도만 보면 잡음이 심한데, 규칙 상위 집합의 변화율을 보면 보다 직접적인 정지 조건을 얻을 수 있기 때문이다.

Figure 5: 전역 규칙 풀에 규칙을 유지하고 재사용할수록 성능이 안정화되는 분석

하이퍼파라미터 선택 실험도 메시지가 분명하다. top-k는 너무 작으면 좋은 규칙을 놓치고, 너무 크면 selection token cost가 올라간다. 저자들은 정확도가 30 근방에서 포화하고 그 이후에는 비용만 증가하거나 약간 악화될 수 있다고 보고 k = 30을 택한다. batch size N은 작을수록 규칙 전파가 빨라 정확도에 유리하고, 클수록 런타임이 유리하다. 결국 N = 4가 선택된다. 중요한 점은 이 결과가 TACO의 구조와 잘 맞는다는 것이다. 전역 재사용과 온라인 진화 사이 균형을 잡으려면, 너무 적은 후보도 너무 큰 병렬도 모두 손해다.

Figure 6: 압축 강도와 규칙 선택 수에 따른 TACO의 하이퍼파라미터 민감도 분석

Figure 6은 TACO가 하이퍼파라미터를 임의로 고르지 않았음을 보여 준다. rule retrieval을 너무 작게 잡으면 coverage가 부족하고, 너무 크게 잡으면 선택 단계 자체가 비싸진다. batch size도 마찬가지다. 작은 N은 정확도를 올리지만 전파를 기다리는 시간이 길어지고, 큰 N은 throughput은 좋아도 새 규칙이 다음 태스크에 반영되는 속도가 느려진다. 결국 $k=30$과 $N=4$는 단순 경험값이 아니라, 정확도·비용·전파 속도 사이의 균형점으로 해석하는 편이 맞다.

6.2 추가 벤치마크 전이와 ablation: 토큰만 줄이는 설계로는 충분하지 않다

MiniMax-2.5 기준 추가 벤치마크 전이 결과도 좋다. SWE-Bench Lite는 56.30 → 57.12로 정확도가 소폭 오르면서 총 token은 약 12.1% 줄고, CompileBench는 정확도는 유지되면서 token이 약 21.6% 줄며, DevEval은 38.10 → 39.74로 오르면서 token이 약 27.0% 줄고, CRUST-Bench도 47.00 → 48.05로 오르면서 약 17.5% 줄어든다. 다시 말해 TACO는 주력 TB 외부에서도 "정확도 개선 또는 유지 + 토큰 절감" 패턴을 비교적 안정적으로 보인다.

벤치마크	정확도 Baseline	정확도 TACO	총 Token Baseline	총 Token TACO	토큰 절감률
SWE-Bench Lite	56.30	57.12	307.61M	270.53M	12.1%
CompileBench	75.00	75.00	14.55M	11.41M	21.6%
DevEval	38.10	39.74	36.72M	26.82M	27.0%
CRUST-Bench	47.00	48.05	163.53M	134.97M	17.5%
TB 1.0	42.30	45.25	29.74M	23.43M	21.2%
TB 2.0	42.80	44.16	113.74M	110.63M	2.7%

ablation은 TACO의 핵심이 단순 압축 강도가 아니라는 점을 명확하게 보여 준다. DeepSeek-V3.2 on TB 2.0에서 baseline은 40.6%이고, Global Rule Pool Evolution을 제거하면 정확도는 40.4%로 baseline보다 약간 낮아지지만 token은 18.1% 줄어든다. Intra-Task Rule Set Evolution을 제거하면 정확도는 38.9%까지 더 떨어지고 token은 30.7%나 줄어든다. 반면 Full TACO는 정확도가 42.7%로 +2.1%p 상승하면서 token은 12.2% 감소한다. 즉 많이 줄이는 것이 항상 좋은 압축이 아니며, 정확도와 효율의 균형은 intra-task 적응과 global pool 누적이 함께 있을 때만 제대로 맞춰진다.

방법	정확도	정확도 변화	토큰 절감률	해석
Baseline	40.6%	0.0%p	0.0%	압축 없음
w/o Global Rule Pool Evolution	40.4%	-0.2%p	18.1%	태스크 간 축적이 사라져 효율은 생기지만 성능 이득이 약하다.
w/o Intra-Task Rule Set Evolution	38.9%	-1.7%p	30.7%	태스크 내부 적응이 없으면 과압축 위험이 커진다.
TACO Full	42.7%	+2.1%p	12.2%	두 진화 축을 함께 써야 성능과 효율의 균형이 맞는다.

6.3 사례 연구: apt, make, objdump에서 TACO가 실제로 남기는 것과 버리는 것

부록의 case study는 이 논문의 가치를 가장 구체적으로 보여 주는 부분이다. 분석 대상은 TerminalBench 2.0에서 성공한 세 trajectory, 즉 adaptive-rejection-sampler, sqlite-with-gcov, vulnerable-secret다. 저자들은 Qwen3-Coder-480B를 backbone으로 한 Terminus-2 실행 결과를 분석하면서, 규칙 초기화와 mid-task 진화가 실제로 어떻게 작동했는지 보여 준다. 이 부분을 보면 TACO가 정적 규칙 세트가 아니라는 점이 더 선명해진다.

태스크	재사용 시드 규칙 수	계획 단계 신규 규칙 수	mid-task 신규 규칙 수	읽을 포인트
adaptive-rejection-sampler	4	2	1	설치 로그가 예상보다 길어져 태스크 중 추가 규칙이 생겼다.
sqlite-with-gcov	2	2	0	초기화가 충분히 잘 되어 mid-task 진화가 없어도 커버되었다.
vulnerable-secret	4	2	1	반복 objdump 출력이 새로운 규칙 생성의 계기가 되었다.

adaptive-rejection-sampler에서는 apt-get install -y r-base가 가장 인상적이다. 초기 seed apt 규칙은 일부를 줄였지만, 후속 출력은 여전히 200개가 넘는 패키지의 Unpacking과 Setting up 줄로 가득했다. 이때 TACO는 apt_install_unpacked_packages 같은 더 세밀한 규칙을 태스크 중에 진화시켜, 10,071자 continuation을 73자로 줄였다고 보고한다. 압축률로는 0.007, 즉 99.3% 감소다. 중요한 것은 이것이 무지성 삭제가 아니라는 점이다. 에이전트에게 필요한 정보는 설치 세부 내역이 아니라 현재 설치가 계속 진행 중인지, 실패했는지, 마지막 상태가 무엇인지였기 때문이다.

sqlite-with-gcov에서는 반대로 공격적인 삭제보다 핵심 빌드 신호를 지키는 선택적 압축이 중요했다. make 출력 6,519자가 3,183자로 줄어 compression ratio가 0.488이 되는데, 이때 긴 file-copy listing과 일부 과도한 컴파일 명령행은 지워도, 마지막의 -fprofile-arcs와 -ftest-coverage가 포함된 컴파일 라인은 남긴다. 이는 gcov instrumentation이 제대로 활성화되었는지 판단하는 결정적 단서이기 때문이다. 즉 TACO는 길이만 줄이는 것이 아니라 나중 의사결정에 필요한 논리적 증거를 보존한다.

vulnerable-secret에서는 objdump -d가 대표적이다. 첫 번째 긴 disassembly 출력은 어떤 규칙에도 걸리지 않았고, 이를 계기로 objdump_disassembly_rule이 생성된다. 이 규칙은 반복적인 hex-dump instruction line을 지우되, 섹션 헤더, 심볼 라벨, 주소 마커, 특히 call instruction과 분기 정보를 남긴다. 논문은 5,619자 출력이 821자로 줄어 ratio 0.146, 즉 약 85.4% 감소했다고 설명한다. 더 중요한 것은 이 규칙이 이후 18번의 objdump 호출에 다시 적용되어, 긴 101-episode trajectory 전체에서 29,464 characters를 절감했다는 점이다.

태스크	Episodes	압축 적용 Entries	Chars saved	Overall ratio	Best ratio
adaptive-rejection-sampler	25	4	14,766	0.285	0.007
sqlite-with-gcov	22	9	9,647	0.464	0.390
vulnerable-secret	101	25	29,636	0.455	0.146

이 표가 보여 주는 포인트도 중요하다. adaptive-rejection-sampler는 전체 25개 episode 중 4개 step만 압축했는데도 14,766자를 절감했다. 즉 모든 step을 다 압축해야 효과가 나오는 것이 아니라, 정말 길고 반복적인 step 몇 개만 잘 다뤄도 전체 궤적이 크게 달라질 수 있다. vulnerable-secret은 반대로 긴 궤적 내에서 하나의 진화된 규칙이 여러 번 재사용되면서 큰 누적 절감을 만든다. 이 두 경우는 TACO가 한 번의 규칙 생성으로 끝나는 것이 아니라, 고가치 규칙을 반복 사용 가능한 자산으로 전환한다는 점을 보여 준다.

정리하면 사례 연구는 메인 표보다 오히려 더 강하게 TACO의 정체를 드러낸다. TACO는 요약문 생성기처럼 출력 전체를 새로 쓰지 않고, 현재 태스크가 실제로 무엇을 알아야 하는지에 맞춰 원문에서 의미 밀도가 낮은 부분만 걷어내는 semantic filter에 가깝다. 그래서 동일한 "압축"이라는 말을 써도, 일반 텍스트 요약과는 상당히 다른 종류의 시스템이라고 보는 편이 정확하다.

이 지점에서 나는 TACO의 성능 향상을 단순한 프롬프트 단축 효과로 읽는 것은 부족하다고 본다. 사례 연구에서 드러나듯, TACO가 진짜로 하는 일은 관측의 시간 구조를 다시 편집하는 것이다. 원래라면 설치 로그 1만 자가 이후 여러 단계 프롬프트에 반복 삽입되어 미래 판단을 계속 방해했겠지만, TACO는 그 로그를 "현재 상태 1줄 + 압축 사실 1줄"로 바꾸어 장기 메모리의 오염을 막는다. 이 관점에서 보면 TACO는 입력 길이를 줄이는 도구를 넘어, 장기 추론에 필요한 정보만 남는 작업 기억을 설계하는 장치라고 해석할 수 있다. 특히 터미널 에이전트처럼 명령과 관측이 번갈아 쌓이는 환경에서는, 한 번 정리된 관측이 이후 모든 단계의 맥락 품질을 연쇄적으로 바꾼다.

또한 케이스별 압축 강도가 크게 다르다는 사실도 중요하다. apt 설치처럼 거의 전부를 제거해도 되는 경우에는 ratio가 0.007까지 내려가지만, 빌드 시스템처럼 마지막 설정 라인이 핵심인 경우에는 0.488 정도에서 멈춘다. 이는 TACO가 일정 비율 압축을 목표로 삼지 않는다는 뜻이며, 과제별 정보 밀도에 따라 서로 다른 보존 전략을 선택한다는 증거다. 이 유연성 덕분에 TACO는 "항상 많이 줄이는 압축기"보다 훨씬 실용적이다. 실제 현장에서는 모든 로그를 강하게 줄이는 것보다, 어떤 로그는 거의 그대로 두고 어떤 로그는 공격적으로 없애는 차등 압축이 더 안전하고 더 효과적이기 때문이다.

여기서 특히 중요한 것은 수렴과 ablation이 한 방향의 메시지를 준다는 점이다. 규칙을 많이 모은다고 자동으로 좋은 것이 아니라, 실제로 잘 쓰이는 규칙 프론티어가 안정화될 때 성능도 함께 안정화된다. 동시에 ablation은 토큰을 가장 많이 줄인 설정이 최고의 정확도를 내지 않는다는 사실을 보여 준다. 즉 TACO의 목적 함수는 로그를 가장 짧게 만드는 것이 아니라, 다음 행동에 필요한 증거를 가장 안전하게 남기는 것이다.

사례 연구도 같은 해석을 강화한다. apt 설치에서는 거의 전부를 지워도 되는 반면, gcov 빌드나 objdump에서는 마지막 설정 라인과 심볼, call target을 보존해야 한다. 이는 TACO가 단일한 압축률을 목표로 하지 않고, 관찰의 정보 밀도와 이후 행동 의존성에 맞춰 압축 강도를 달리하는 차등 압축기임을 보여 준다. 그래서 TACO는 generic summarizer라기보다, 태스크별 증거 보존 정책을 가진 operational filter에 더 가깝다.

7. 한계점 및 향후 연구 방향: 직접 비교와 운영비용까지 같이 봐야 한다

논문에는 별도의 limitations 섹션이 강하게 드러나지 않지만, 본문과 부록을 읽으면 몇 가지 제약은 분명하다. 첫째, cold-start와 self-evolution 비용이 있다. 저자들은 한 full round가 약 4일 걸린다고 밝힌다. training-free라고 해서 공짜가 아니라는 뜻이다. 즉 TACO는 모델 재학습 비용을 피하는 대신, 규칙 프론티어를 수렴시키기 위한 운영 시간을 요구한다. 연구 단계에서는 수용 가능하지만, 빠르게 변하는 프로덕션 환경에서는 얼마나 자주 이 진화를 다시 수행할지 정책이 필요해진다.

둘째, 초기 시드 규칙 의존성이 남는다. 논문은 완전한 무초기화가 아니라 6개의 시드 규칙으로 시작한다. 이 선택은 합리적이지만, 동시에 어떤 종류의 노이즈를 처음부터 중요한 문제로 간주했는지를 보여 주는 편향이기도 하다. 예컨대 현재 시드 세트는 개발자용 CLI 환경에 매우 잘 맞지만, 데이터베이스 관리 콘솔, 네트워크 디버깅, 운영 로그, 비코딩 터미널 업무까지 넓혀 가면 다른 seed taxonomy가 필요할 가능성이 크다.

셋째, 일반화 범위가 아직은 터미널과 코드 중심이다. TB, SWE-Bench Lite, CompileBench, DevEval, CRUST-Bench는 넓은 편이지만 모두 CLI와 소프트웨어 작업에 가깝다. 브라우저 에이전트, GUI 자동화, 비정형 문서 워크플로, 다중 애플리케이션 환경으로 가면 "관측 압축"은 여전히 중요하겠지만 규칙의 형태와 안전성 기준이 크게 달라질 수 있다. 다시 말해 TACO의 핵심 아이디어는 더 넓게 전이될 수 있어 보여도, 현재 실험이 곧바로 그 일반화를 보장하지는 않는다.

넷째, 전역 규칙 풀은 강점인 동시에 관리 이슈를 품는다. 좋은 규칙만 남긴다고 해도, 시간이 지날수록 서로 비슷한 규칙이 많아지거나 특정 태스크 클러스터에 치우친 규칙이 상위를 점유할 수 있다. 논문은 ranking score와 confidence로 이를 통제하지만, 왜 어떤 규칙이 어떤 태스크군으로 잘 전이되는지에 대한 더 세밀한 분석은 제한적이다. 장기적으로는 규칙의 중복 제거, 군집화, 버전 관리, 태스크 패밀리별 라우팅이 중요해질 수 있다.

그럼에도 시사점은 크다. TACO는 에이전트 연구에서 종종 놓치기 쉬운 사실, 즉 모델 능력만큼 관측 설계가 중요하다는 점을 정량적으로 보여 준다. 특히 rule-based라는 형식 덕분에, 어떤 로그가 왜 잘렸는지와 어떤 신호가 보호되었는지를 운영자가 추적할 수 있다. 이는 안전과 디버깅 관점에서 유리하다. 실제 현장에서는 모델이 왜 잘못 판단했는지 설명 가능한 중간 계층이 필요할 때가 많고, TACO류 방식은 그 요구와 잘 맞는다.

관찰된 한계	논문에서 드러난 근거	실무적 영향	가능한 후속 방향
cold-start 및 운영 시간	self-evolution 한 full round에 약 4일	빠른 배포 사이클에서는 재진화 주기 설계가 필요하다.	증분 업데이트, 태스크군별 부분 재학습, 규칙 캐시 재사용
시드 규칙 편향	6개 범용 seed에서 시작	개발자 CLI 중심 패턴에 초기 적합성이 높다.	도메인별 seed library, 메타 규칙 검색
complaint 신호의 모호성	에이전트의 재요청/재실행 행동을 간접 해석	오검출 시 과보수적 규칙으로 흘러갈 수 있다.	학습된 complaint detector, 반사실적 재평가
직접 비교 부족	prior compression/pruning과의 광범위 head-to-head 부재	상대적 SOTA 위치를 정확히 판단하기 어렵다.	정적 요약기, 학습 기반 pruning, retrieval형 memory와 동시 비교
터미널 바깥 일반화 미검증	실험 범위가 코드/CLI 중심	브라우저, GUI, 문서 작업으로의 전이는 아직 열린 문제다.	멀티모달 에이전트 관측 압축, UI event summarization과 결합

향후 연구 방향도 비교적 뚜렷하다. 첫째, complaint detection을 더 정교하게 만들어야 한다. 지금은 full output 재요청, 비슷한 명령 재실행, 정보 부족 정황을 간접 신호로 읽는데, 이는 규칙 수정의 근거가 다소 거칠다. 다음 단계에서는 재요청 span의 위치, 직전 실패 유형, 대체 행동의 성공 여부를 함께 넣어 과압축 불만의 원인을 더 세밀하게 판정할 필요가 있다.

둘째, 규칙 기반 압축과 retrieval형 보조 기억을 결합하는 방향이 유망하다. 논문은 현재 observation을 잘 정리하는 데 집중하지만, 실제 운영에서는 삭제된 원문을 완전히 버리기보다 별도 캐시에 보존했다가 필요할 때만 다시 불러오는 구조가 더 안전할 수 있다. 이렇게 되면 프롬프트 본문은 가볍게 유지하면서도, 압축이 너무 공격적이었을 때 원문 복구 경로를 보장할 수 있다.

셋째, 브라우저·GUI·멀티모달 에이전트로의 일반화가 다음 시험대가 될 가능성이 크다. 장기 멀티모달 에이전트에서도 핵심 문제는 비슷하다. raw screenshot, OCR dump, DOM trace, tool output을 전부 history에 인라인으로 남기면 결국 같은 병목이 생긴다. 따라서 TACO의 진짜 후속 연구는 "규칙 기반 terminal compression"의 개선뿐 아니라, 관찰을 history로 승격하기 전에 어떤 해상도로 정리할 것인가라는 일반 원칙을 더 넓은 에이전트 환경으로 확장하는 일일 것이다.

그래서 이 논문의 진짜 의미는 "압축 규칙을 잘 만들었다"에서 끝나지 않는다. 더 중요한 것은 에이전트 메모리 관리가 별도 연구 주제가 될 수 있음을 설득력 있게 보여 준 점이다. 앞으로 장기 에이전트가 더 복잡한 작업을 맡게 될수록, planner와 tool use 못지않게 observation filtering, memory routing, context compression 계층이 핵심 모듈로 자리 잡을 가능성이 높다.

8. 내 해석: 관찰을 history로 올리기 전에 정리하는 계층

내가 보기에 이 논문의 가장 중요한 기여는 압축 규칙 몇 개를 더 잘 만든 데 있지 않다. 나는 이 논문을 터미널 에이전트의 관측 인터페이스를 재설계한 작업으로 읽는다. 많은 agent 논문은 planner, tool use, long reasoning, search strategy에 초점을 맞추는데, TACO는 그보다 앞단에서 "모델이 무엇을 읽게 할 것인가"를 건드린다. 실제 운영에서는 이 층이 매우 중요하다. 같은 모델이라도 어떤 출력을 계속 들고 있게 하느냐에 따라 실수의 종류가 완전히 달라지기 때문이다.

이 지점은 내가 이전에 정리했던 Agent Context Compression, Search-First Agent Memory, Sandboxed Agent Harness 같은 흐름과도 자연스럽게 연결된다. Agent Context Compression이 코드베이스를 어떻게 포장해 모델에게 보여 줄지의 문제였다면, TACO는 행동 이후에 생긴 stdout과 stderr를 어떤 밀도로 history에 남길지를 다룬다. Search-First Agent Memory가 과거 기록을 언제 호출할지의 문제였다면, TACO는 현재 관찰을 애초에 어떤 형태로 미래의 과거로 만들 것인지를 다룬다. 결국 메모리 문제의 절반은 얼마나 많이 저장하느냐가 아니라, 무엇을 history로 승격시키느냐에 있다.

나는 또 이 논문을 최근 컴퓨터 사용 에이전트의 reliability 논의와도 연결해 보고 싶다. 점수 향상과 token 절감이 확인됐다고 해서 repeated-run reliability가 자동으로 올라간다고 보기는 어렵다. 오히려 압축이 잘못되면 특정 run에서는 중요한 증거가 사라져 더 불안정해질 가능성도 있다. 따라서 다음 단계 검증은 단순 평균 정확도보다, 같은 과제를 여러 번 다시 시켰을 때 TACO가 관찰의 흔들림과 실패 분산까지 줄이는지를 보는 쪽으로 가야 한다고 본다. 그렇게 될 때 이 논문은 성능 최적화 기법을 넘어 신뢰성 레이어로도 자리 잡을 수 있다.

또 하나 인상적인 점은 규칙 기반이라는 보수적 선택을 오히려 강점으로 뒤집은 방식이다. 보통 규칙 기반은 확장성이 약하고, LLM 기반은 유연하다고 여겨진다. 그런데 이 논문은 규칙을 정적으로 쓰지 않고 LLM이 만들고 수정하는 구조화된 대상으로 바꾸었다. 덕분에 사람은 규칙의 작동 원리를 해석할 수 있고, 시스템은 새로운 패턴을 만날 때 즉시 적응할 수 있다. 나는 이 조합이 꽤 현실적이라고 본다. 완전히 자유로운 요약보다 안전하고, 완전히 수동적인 규칙 엔진보다 훨씬 유연하다.

약점도 분명하다. 내가 가장 크게 느낀 약점은 직접 비교의 부족이다. 논문은 baseline 대비 개선은 잘 보여 주지만, SWE-Pruner 같은 학습 기반 pruning이나 강한 LLM 요약형 압축기와의 광범위한 head-to-head 비교는 충분하지 않다. 또한 over-compression complaint를 agent 행동으로 간접 추정하는 방식은 아이디어는 좋지만, 실제로는 오검출과 누락 검출 모두 가능하다. 에이전트가 같은 명령을 다시 실행했다고 해서 반드시 압축 때문이라고 볼 수는 없기 때문이다. 이 부분은 방법론의 구조적 리스크다.

후속 제안도 떠오른다. 내가 다음 단계로 보고 싶은 것은 불확실성 추정이 결합된 이중 채널 압축이다. 예를 들어 규칙 기반으로 본문 컨텍스트는 압축하되, 제거된 원문을 별도 압축 메모리나 retrieval cache로 저장해 필요할 때만 재주입하는 방식이다. 동시에 complaint 신호를 단순 행위 규칙이 아니라, 모델의 재질문 패턴, 실행 실패 변화, 다시 요청한 span의 위치 정보를 함께 보는 학습 가능한 안전 추정기로 바꾸면 더 안정적일 것이다. 이렇게 되면 TACO의 해석 가능성은 유지하면서도 과압축 리스크를 줄일 수 있다.

결국 나는 TACO를 "터미널 로그 압축 논문"보다 더 넓게 평가한다. 이것은 관측의 가치 밀도를 높이면 장기 에이전트의 성능이 오른다는 주장을 상당히 설득력 있게 보여 준 사례다. 에이전트가 똑똑해지는 문제만큼, 에이전트가 무엇을 보고 무엇을 잊게 할지를 설계하는 문제도 중요하다는 점을 이 논문은 분명하게 드러낸다.

9. 결론: long-horizon terminal agent에서 관찰 관리가 곧 성능 관리다

이 논문은 장기 터미널 에이전트의 병목을 planner나 model scaling이 아니라 observation management의 문제로 다시 정의한다. raw terminal output을 계속 history에 쌓는 구조에서는 중복 로그가 미래의 모든 단계에 비용과 잡음을 남긴다. TACO는 이를 task-aware rule compression, online rule evolution, global rule reuse라는 세 축으로 풀어, 같은 모델이라도 더 밀도 높은 관찰을 바탕으로 더 긴 작업을 수행하게 만든다.

핵심은 많이 지우는 압축기가 아니라는 점이다. TACO는 critical signal을 남기고, uncovered output에는 새 규칙을 만들고, complaint가 감지되면 더 보수적인 규칙으로 되돌아가며, 효과적인 규칙만 전역 풀에 축적한다. 이 설계 덕분에 압축은 token 절약의 부산물이 아니라, 에이전트가 무엇을 기억하고 무엇을 잊어야 하는지에 대한 운영 정책으로 변한다. 실험 결과가 보여 주는 이득도 바로 그 정책 변화에서 나온다.

결국 TACO의 가장 큰 공헌은 terminal agent를 더 똑똑하게 만든 데 있지 않다. 오히려 에이전트가 매 단계 어떤 증거를 보고 다음 결정을 내리게 할지를 재설계했다는 데 있다. 앞으로 long-horizon agent 연구가 더 커질수록, planner·tool use·memory 못지않게 observation compression과 memory routing이 핵심 설계 축으로 올라올 가능성이 크다. 이 논문은 그 방향을 꽤 설득력 있게 보여 준 첫 사례에 가깝다.

실무 관점에서 보면 이 결론은 꽤 직접적이다. 장기 에이전트의 품질을 올리고 싶을 때 항상 더 큰 모델, 더 긴 컨텍스트, 더 복잡한 planner부터 찾을 필요는 없다. 때로는 현재 도구가 내놓는 로그와 관찰을 어떤 규칙으로 정리해 history에 남길지를 재설계하는 편이 훨씬 싸고 즉각적인 개선을 준다. TACO는 바로 그 사실을 정량 수치와 사례 연구로 같이 보여 준다.

나는 이 논문이 특히 중요한 이유가, 최근 에이전트 연구가 너무 쉽게 planner나 tool-calling policy만 개선 대상으로 보는 흐름에 제동을 건다는 데 있다고 본다. 실제 현장에서는 모델이 틀린 결정을 내리는 이유가 사고 능력 부족보다 잘못된 로그를 너무 오래 들고 있기 때문인 경우가 자주 있다. TACO는 이 현실을 정면으로 다루며, 관찰을 정리하는 일 자체가 에이전트 시스템 설계의 1급 문제라는 점을 보여 준다. 그래서 이 논문은 단순히 terminal compression을 잘한 사례를 넘어, 향후 browser agent나 multimodal agent에서도 반복해서 소환될 가능성이 큰 설계 원칙을 제시한다고 생각한다.

정리하면 TACO는 장기 에이전트 연구의 시선을 planner 중심에서 observation hygiene 중심으로 조금 옮겨 놓는다. 어떤 로그를 계속 들고 갈지, 어떤 로그는 즉시 버리고 어떤 로그는 축약된 흔적으로만 남길지를 설계하는 일이 실제 성능과 비용을 함께 바꾼다는 사실이 이 논문의 핵심 교훈이다. 이런 관점은 앞으로 코드 에이전트뿐 아니라 브라우저 조작, 문서 처리, 멀티모달 workflow처럼 관찰 표면이 더 복잡한 환경에서도 점점 더 중요해질 가능성이 크다. 결국 TACO의 메시지는 로그 압축이 부가 기능이 아니라 추론 조건을 설계하는 핵심 계층이라는 데 있다.

10. 요약 정리: TACO가 보여 준 장기 에이전트의 관찰 관리 원칙

• TACO는 raw terminal output을 자연어 요약으로 바꾸는 시스템이 아니라, 구조화된 압축 규칙을 스스로 만들고 고치는 프레임워크다.
• 문제의 출발점은 장기 터미널 에이전트가 매 단계의 긴 로그를 계속 history에 보존하면서 중복 token cost와 잡음이 누적된다는 데 있다.
• Critical bypass 원칙 때문에 syntax error, exception, 명시적 실패 신호는 압축하지 않고 그대로 남겨 안전성을 우선한다.
• 새로운 장문 출력이 등장하면 uncovered output → new rule 경로로, 과압축 정황이 보이면 complaint → conservative replacement 경로로 규칙이 진화한다.
• 태스크 종료 후 효과적 규칙만 Global Rule Pool에 write-back되며, 다음 태스크는 여기서 top-k 규칙을 가져와 더 좋은 초기화를 얻는다.
• TerminalBench 1.0과 2.0에서 TACO는 제시된 6개 오픈 모델 전부를 개선했고, 동일 token budget 비교와 pass@k 비교에서도 일관된 이득을 보였다.
• 추가 벤치마크인 SWE-Bench Lite, CompileBench, DevEval, CRUST-Bench에서도 정확도 개선 또는 유지와 token 절감이 함께 나타나 전이성을 뒷받침한다.
• ablation 결과는 단순히 더 많이 지우는 압축으로는 충분하지 않으며, intra-task 적응과 global pool 누적이 함께 있어야 성능과 효율의 균형이 맞는다는 점을 보여 준다.
• 내 해석으로는 이 논문의 가장 큰 의의는 에이전트 성능 문제를 planner가 아니라 관측 인터페이스와 메모리 관리의 문제로 재구성했다는 데 있다.