trim-1: 1.2 MB 모델로 에이전트의 입력 줄이기

무엇이 문제인가

에이전트는 로그와 도구 결과, 긴 문서를 전부 읽는다. README 의 첫 이미지가 그 예다. 오류 하나를 찾으려고 로그 전체를 읽는다. 읽는 분량만큼 토큰을 쓰고, 문맥 한도도 그만큼 빨리 찬다.

코딩 에이전트코딩 에이전트개발자 대신 코드를 읽고 고치고 명령을 실행하는 AI 프로그램. Claude Code, Codex 등이 있다. Claude Code 도 이 문제를 두 가지 방법으로 다룬다. 공식 문서에 따르면 대화가 문맥 한도에 가까워지면 지난 대화를 요약해 압축한다. 무엇을 남길지 지시할 수는 있지만 결국 요약이라 원문의 세부가 빠질 수 있고, 압축 자체도 큰 요청이다. 문서에는 훅훅정해진 시점에 자동으로 실행되도록 등록해 둔 스크립트. Git 은 커밋이나 푸시 직전에 훅을 실행한다. 예시도 있다. 훅이 로그를 grep ERROR 로 걸러 그 결과만 에이전트에게 전달한다. 이 방법은 모델 호출이 필요 없지만, 답이 있어도 그 줄에 키워드가 없으면 빠진다. 제작자는 README 에서 요약과 | tail -20 을 비교 대상으로 든다.

어떻게 해결했나

trim-1 은 지우기만 한다. 문맥을 줄 단위로 나누고, 각 줄이 지금 질의에 얼마나 필요한지 점수로 계산해 기준보다 낮으면 지운다. 줄의 내용과 순서는 바꾸지 않고, 줄을 지우면, 지운 줄 대신 "… 25 lines …" 같은 표시줄을 삽입한다. README 에는 질의가 비어 있으면 라이브러리가 입력을 그대로 반환한다고 적혀 있다. 입력이 2,000 바이트 미만이거나 지워도 10% 를 줄이지 못할 때도 입력을 그대로 반환한다.

무엇이 다른가

점수는 신경망이 아니라 결정 트리 712개가 산출한다. 모델 카드에 따르면 줄마다 질의와 비교해 수치 특징 67개를 계산한다. 어휘 일치, 줄의 종류(오류·경로·스택 프레임), 위치와 들여쓰기, 이웃 줄의 점수다. 트리라서 모델이 1.2 MB 이고, CPU 한 코어에서 밀리초 단위로 처리되며, 무작위성이 없어 결과가 결정적이다. 트레이드오프도 모델 카드에 적혀 있다. 줄 단위로만 지우므로 긴 줄 하나를 짧게 만들지는 못하고, 후속 근거는 질의와 단어가 겹치지 않으면 찾지 못한다. 코딩 에이전트의 도구 출력은 짧고 밀도가 높아서 기본 설정에서 1.9% 만 줄어들고, 본래 용도는 긴 문서 검색이다. 그 용도에서는 토큰 88.9% 를 지우면서 근거를 94.4% 유지했다고 적혀 있다.

어떻게 만들었나

• 커밋은 2026-10-13 과 14 이틀 동안 4개이고, 그중 2개에 Claude Opus 5.5 가 Co-authored-by 로 적혀 있다. 외부 컨트리뷰터의 PR 도 1개 있다. 입력 크기에 상한을 두어 메모리 고갈을 막는다.
• 코드는 Go 1,788줄이다. features.go 가 특징을 계산하고 model.go 가 트리를 평가하며, model.bin 은 go:embed 로 바이너리에 포함한다. 테스트는 2개다. 예측값이 학습 라이브러리와 비트 단위로 같은지, 샘플 로그의 출력이 고정값과 같은지 확인한다.
• 제작자 Julius Brussee 는 Caveman 도 만들었다. Caveman 은 에이전트의 토큰을 줄이고, trim-1 은 Caveman 안에서 모델로 사용된다.
• 모델 카드에 따르면 학습 데이터는 모두 공개 데이터이고 상업 이용이 허용된다. 벤치마크 수치는 한 번만 실행해 얻었다.

실행해 보니

빌드한 뒤 아래 순서로 시험했다.

1. 빌드와 테스트. go build 는 9.7초에 완료됐고 바이너리는 4.2 MB 다. 의존성은 표준 라이브러리뿐이고, 테스트 2개가 0.166초에 통과했다. 모델 파일의 머리글에는 특징 67개, 트리 712개가 적혀 있었다.
2. 코드 41 KB. 이 사이트의 스크립트 10개를 하나로 합쳐 "how are visits fetched from Vercel analytics" 로 질의했다. 1,092줄 중 785줄이 지워져 14 KB 가 됐고, 방문 집계 스크립트의 API 주소와 토큰 변수는 그대로 유지됐다.
3. HN 스레드 35 KB. 스레드를 덤프해 "did the PS2 recompiler use AI generated code" 로 질의했다. 기본 설정에서는 10% 를 줄이지 못해 한 줄도 지우지 않았다(unchanged). 설정을 aggressive 로 변경하자 150줄 중 93줄을 지우고 15 KB 를 반환했다.
4. 출력 대조. 두 출력의 줄을 입력과 대조하니 표시줄 외에는 전부 입력의 줄이었고 순서도 같았다. 같은 명령을 4회 실행하자 해시가 모두 같았다.
5. 작은 입력과 재입력. 1,800 바이트 로그는 크기가 작다는 안내와 함께 그대로 반환됐다. 출력을 다시 입력해도 그대로 반환됐다.
6. 빈 질의. 이 경우만 README 와 다르게 동작했다. 라이브러리는 입력을 그대로 반환한다고 적혀 있지만, CLI 는 --query "" 를 받으면 종료 코드 2 를 반환하고 사용법만 표시했으며, stdout 은 비어 있었다. 파이프라인에서 출력을 리다이렉트로 받으면 빈 파일이 생성된다.
7. 처리 시간. 프로세스 시작까지 포함해 35 KB 입력이 23~34 ms, 스레드 덤프 7개를 이어 붙인 245 KB 입력이 94~121 ms 였다. 모델 카드의 7.2 ms(5,000 토큰)는 프로세스 안에서 측정해 방법이 다르다.

$ trim --query "how are visits fetched from Vercel analytics" scripts.txt
trim: kept 307 lines, removed 785, 41396 -> 14462 bytes
$ trim --query "did the PS2 recompiler use AI generated code" hn-threads.txt
trim: unchanged (cut below the minimum)
$ trim --query "" hn-threads.txt; echo exit=$?
usage: trim --query QUERY [--point POINT] [FILE]   (reads stdin without FILE)
exit=2

확인하지 못한 것

• 모델 카드의 벤치마크 수치. 긴 문서로 시험하지 않아 88.9% 와 94.4% 는 확인할 수 없었다.
• 실제 에이전트 루프에서 효과가 있는지. Caveman 이 어느 시점에 trim-1 을 호출하는지 다음에 그 저장소에서 확인하자.
• 한국어 입력. 영어로만 학습했다고 적혀 있어 한국어 로그로는 시험하지 않았다.

판정

작동한다. 코드 41 KB 를 질의 하나로 65% 줄이면서 답이 있는 줄은 남겼다. 다만 HN 스레드 덤프는 기본 설정에서 그대로 반환했다. 에이전트에게 긴 로그나 문서를 전부 전달하고 있고, 요약하면 원문이 바뀌어서 곤란한 경우에 써 볼 만하다. 도구 출력처럼 짧고 밀도가 높은 문맥을 줄이려면 이 프로덕트는 적합하지 않다. 모델 카드에도 기본 설정에서 2% 만 줄어든다고 적혀 있다.

얻어갈 것

• 에이전트에게 긴 문맥을 전달해야 한다면, 요약하기 전에 필요 없는 줄부터 지워 보자. 오늘 trim-1 의 출력은 표시줄을 빼면 전부 입력의 줄 그대로였다.
• 작은 모델을 사용할 때는 결과가 결정적인지부터 확인하면 된다. 같은 명령을 4회 실행해 sha256 이 모두 같았다.
• 입력이 비어 있으면 라이브러리와 CLI 가 똑같이 동작하게 맞추자. 오늘 CLI 는 빈 질의를 받자 종료 코드 2 를 반환했고, stdout 에는 아무것도 출력하지 않았다.
• 도구가 자신의 출력을 다시 받으면 어떻게 동작할지도 정해 두자. trim-1 은 입력에 자신의 표시줄이 있으면 그대로 반환했다.