Jev를 코딩 에이전트에 붙이면 개발 비용은 얼마나 줄어들까

4편에서 87줄짜리 변경 로그를 줄 단위로 평가해 질문에 필요한 줄만 남겼다. 정답 줄은 14개 질문에서 모두 1위였고, 질문 87개를 한 번에 보낸 호출은 0.27초가 걸렸다. 그때 확인한 것은 Jev로 컨텍스트 압축기를 만들 수 있다는 가능성까지였다.

이번에는 그 방식이 실제 Claude Code의 압축 경로에 들어갔다. Tamara Tran이 공개한 fast-jev-compaction은 Claude Code가 긴 대화를 요약해야 할 때 끼어들어, Jev가 더 필요하지 않다고 판단한 도구 호출과 결과를 제거한다. 압축에 실패하거나 충분히 줄이지 못하면 Claude Code의 기존 요약으로 돌아간다.

이 저장소의 의미는 요약을 몇 초 빠르게 만드는 데 그치지 않는다. 코딩 에이전트의 비용은 코드 한 번을 생성할 때만 생기지 않는다. 파일을 읽고, 테스트를 돌리고, 로그를 확인할 때마다 대화 기록이 길어지고 이후의 생성 모델 호출이 그 기록을 다시 받는다. 앞에서 불필요한 기록을 싸게 걷어내면 절감분이 뒤의 여러 호출에 반복해서 적용된다.

다만 이 글은 플러그인을 장시간 실사용해 비교한 결과가 아니다. 공개된 코드와 README를 분석하고, 같은 구조의 압축기를 직접 만들어 통제된 Astro 기록과 완료된 실제 Claude Code 세션을 재생했다. 통제 실험은 잘 나왔지만 실제 세션에서는 안전한 임계값과 유용한 압축률을 동시에 찾지 못했다.

코딩 에이전트는 코드 밖에서 판단을 반복한다

에이전트가 중형 리팩터링 하나를 끝내는 동안 내리는 결정에는 문장을 생성할 필요가 없는 것이 많다.

• 이 파일 내용은 지금도 필요한가
• 같은 테스트를 다시 실행할까
• 실패가 일시적인가, 접근 방법을 바꿔야 하는가
• 이 명령은 바로 실행해도 되는가
• 검색 결과 스무 개 중 어느 것을 다음 모델 호출에 넣을까

이 질문의 답은 대부분 예·아니오, 고정된 선택지 하나, 또는 확률 하나다. 그래도 일반적인 에이전트는 코드 생성에 쓰는 큰 모델에 대화 전체를 다시 보내 답을 구한다. 판단 하나의 비용보다 더 큰 문제는 그 판단을 위해 오래된 로그와 파일 내용까지 입력에 붙는다는 점이다.

Jev를 붙이는 자리는 코드 생성기가 아니라 그 앞뒤다.

도구 호출과 결과가 쌓임
        ↓
Jev가 보존·삭제·절단을 판정
        ↓
줄어든 대화 기록
        ↓
Claude가 원인 분석과 코드 생성을 수행
        ↓
다음 도구 호출

Claude는 답을 만들어야 하는 일을 계속 맡는다. Jev는 후보가 이미 정해진 판단만 맡는다. 이 구분이 지켜져야 빠른 판정 모델의 이점이 생긴다.

fast-jev-compaction은 요약문을 만들지 않는다

Claude Code의 기존 압축은 오래된 대화를 읽고 계속 작업하는 데 필요한 내용을 요약한다. 요약은 많은 내용을 짧은 새 문장으로 바꾼다. 그 과정에서 파일 경로, 정확한 오류 문구, 사용자가 정한 제약처럼 나중에 다시 필요해질 세부 사항이 빠질 수 있다.

fast-jev-compaction은 다른 선택을 한다. 남기는 내용은 다시 쓰지 않고 원문 그대로 유지한다. 대신 오래된 도구 호출마다 두 가지를 묻는다.

1. 이 도구를 호출했다는 사실과 입력이 아직 필요한가?
2. 이 도구의 결과 전문이 아직 필요하고, 다시 실행해서 얻기 어려운가?

두 번째 확률이 기준 이상이면 호출과 결과를 모두 보존한다. 결과는 필요 없지만 호출 사실이 필요하면 결과 앞부분 300자와 생략 표시만 남긴다. 둘 다 기준보다 낮으면 호출과 결과를 함께 제거한다. 기본 기준은 0.5다.

여기에는 구조적인 보존 규칙도 있다. 첫 메시지와 최근 6개 메시지는 판정 대상에서 제외한다. 사용자와 어시스턴트가 쓴 일반 텍스트도 출력에서는 삭제하거나 줄이지 않는다. tool_use_id로 호출과 결과를 묶기 때문에 결과만 남고 어떤 호출에서 나왔는지 사라지는 경우도 막는다.

즉 이 플러그인의 압축 단위는 토큰이나 문장이 아니라 도구 호출 한 쌍이다. 코딩 세션에 큰 비중을 차지하는 파일 전문, 터미널 출력, 테스트 로그를 겨냥한다.

Jev는 터미널 출력 전문을 보고 고르지 않는다

구현에서 가장 중요한 제약은 Jev가 실제 도구 결과의 내용을 읽지 않는다는 점이다. Jev에 보내는 state에서는 결과 전문을 성공, 4,213자, 내용 생략과 같은 한 줄로 바꾼다. 도구 이름과 입력, 사용자·어시스턴트의 대화, 결과의 성공 여부와 크기를 보고 보존 가치를 추정한다.

예를 들어 에이전트가 Read src/auth.ts를 실행한 뒤 그 파일을 고쳤다면, Jev는 호출 기록과 이후 대화를 보고 처음 읽은 파일 전문을 다시 보관할 필요가 낮다고 판단할 수 있다. 반대로 외부 API에서 한 번 받은 응답이나 재현하기 어려운 실패 로그도 내용 자체는 보지 못한다. 주변 대화가 그 중요성을 드러내지 않으면 잘못 지울 수 있다.

이 설계는 모순이 아니라 속도와 비용을 위한 선택이다. 수천 줄짜리 출력 전문을 전부 Jev에 보낸다면 압축기가 줄이려는 입력을 압축기 자신이 먼저 읽어야 한다. 대신 이 구현은 “다시 실행할 수 있는 도구 결과는 버리고 필요하면 다시 얻는다”는 복구 가능성을 이용한다.

따라서 “핵심 코드와 상태를 100% 보존한다”고 설명하면 안 된다. 정확한 표현은 다음에 가깝다.

최근 대화와 일반 텍스트는 그대로 고정하고, 오래된 도구 기록은 대화의 목표와 호출 정보로 보존 가치를 판정한다. 잘못 삭제한 결과는 가능한 경우 도구를 다시 실행해 복구한다.

긴 대화도 먼저 2만5천 토큰 안으로 맞춘다

Jev의 요청 한도보다 긴 대화를 그대로 보낼 수는 없다. 플러그인은 판정하기 전에 상태를 기본 2만5천 토큰 안으로 맞춘다. 실제 토크나이저 대신 문자 종류와 길이로 토큰 수를 추정한다.

한 번에 자르지 않고 단계적으로 줄인다. 먼저 긴 도구 입력을 1,000자, 200자, 60자로 줄인다. 그래도 크면 오래된 긴 텍스트의 앞뒤만 남기고, 오래된 메시지를 생략 표시로 바꾸고, 도구 호출을 한 줄로 축약한다. 마지막에는 호출이 없는 오래된 메시지를 Jev가 읽을 상태에서 제외한다. 그래도 맞지 않으면 압축을 중단한다.

판정 질문까지 합친 요청은 기본 3만 토큰 아래로 나눈다. 질문이 많으면 같은 상태를 여러 요청에 반복해서 붙이고 요청들은 동시에 실행한다. 질문 수가 늘어도 지연을 억제할 수 있지만 입력 비용은 요청 수만큼 증가한다.

이 지점에서 “수십 밀리초에 수천 줄을 모두 평가한다”는 설명도 수정할 필요가 있다. 3편에서 직접 잰 jev-1.13.0의 서버 처리 시간은 약 90밀리초였고, 한국에서 미국 서부까지 네트워크 왕복을 포함한 중앙값은 약 250밀리초였다. 질문 1개와 10개의 지연은 거의 같았지만, 이 플러그인은 기록이 많으면 여러 요청으로 나눈다. 전체 시간은 상태 크기, 질문 수, 네트워크 위치에 따라 달라진다.

그래도 기존 압축이 큰 생성 모델로 요약문을 완성할 때까지 기다리는 구조와는 일이 다르다. Jev는 각 항목에 대한 확률만 계산하고, 호스트 코드가 그 결과로 메시지 배열을 다시 만든다.

절감 효과는 압축 다음 턴에서 누적된다

압축 호출 한 번의 가격만 비교하면 이 설계의 효과를 작게 보게 된다. 실제 비교식은 다음과 같다.

기본 방식의 총비용
= 기존 요약 비용 + 이후 N번의 큰 문맥 입력 비용

Jev 방식의 총비용
= Jev 판정 비용 + 이후 N번의 줄어든 문맥 입력 비용 + 재실행 비용

가령 오래된 도구 기록을 제거해 이후 입력에서 5만 토큰을 덜 보내고, 압축 뒤에 Claude 호출이 열 번 남아 있다면 최대 50만 입력 토큰이 호출 경로에서 사라진다. 이것은 설명을 위한 계산이지 이 플러그인으로 측정한 결과는 아니다. 프롬프트 캐시가 적용되면 실제 청구 차이는 작아질 수 있고, 삭제한 파일을 다시 읽으면 일부 절감분을 돌려준다.

속도도 같은 방식으로 봐야 한다. 압축 순간의 대기 시간이 줄어드는 것에 더해, 이후 모델이 매번 처리하는 입력이 작아질 수 있다. 반면 API 왕복과 여러 배치 요청이 추가되고, 필요한 내용을 지웠다면 도구를 다시 실행하는 턴이 늘어난다. 토큰 감소만으로 전체 작업이 빨라졌다고 결론 내릴 수 없는 이유다.

KV 캐시를 “우회한다”는 표현도 맞지 않는다. 이 플러그인은 애플리케이션이 다음 요청에 넣을 메시지를 줄인다. 모델 공급자 내부의 KV 캐시나 프롬프트 캐시를 대체하지 않는다. 오히려 메시지 배열이 바뀌면서 기존 캐시의 어느 부분을 재사용할 수 있는지는 공급자의 캐시 정책에 따라 달라진다.

안전한 삭제와 위험한 삭제를 나눠야 한다

모든 도구 결과의 손실 비용이 같지 않다.

현재 구현은 일반 텍스트와 최근 메시지를 고정하고 실패하면 기존 압축으로 돌아가지만, 도구 종류별 보존 정책까지 강제하지는 않는다. 실제 팀에 넣는다면 확률 기준 하나만 조정하기보다 도구마다 정책을 더하는 편이 안전하다. 예를 들어 Read 결과는 Jev가 버릴 수 있게 하고, 배포·데이터베이스·외부 API 결과는 파일이나 아티팩트에 먼저 저장한 뒤 대화에서는 포인터만 남기는 식이다.

Jev의 확률도 삭제 안전성에 대한 보증이 아니다. 4편의 압축 실험에서 돌려 말한 질문 여섯 개의 정답 줄은 모두 1위였지만, 0.7을 기준으로 자르면 두 개를 잃었다. 압축에서는 높은 기준이 항상 안전하지 않다. 결과를 보존할 확률이 기준을 넘어야 남는 구조이므로, 기준을 높이면 더 많이 삭제한다. 먼저 보수적으로 시작하고 실제 재조회율을 보면서 조정해야 한다.

실제 개발 과제로 측정해야 할 다섯 가지

장시간 에이전트 실험에 앞서 같은 구조의 프로토타입을 만들고, 이 사이트에 설치된 Astro 패키지의 실제 소스와 타입 파일 240개를 읽은 기록을 구성했다. 과제는 라우팅과 route manifest 구현을 추적하는 것으로 정했다. 경로에 route, routing, manifest가 들어간 60개 호출을 보존해야 할 정답으로 두고, JEV에는 도구 결과 전문을 제외한 대화와 파일 경로를 보냈다. 호출 40개씩 여섯 요청을 동시에 실행했다.

관련 호출 재현율과 무관 호출 제거율을 같은 백분율 축으로 표시했다. 이 fixture에서는 0.3이 두 목표가 함께 꺾이지 않는 지점이었다.

JEV가 240개 호출에 대한 Noul 질문 480개를 처리하는 데 걸린 시간은 약 1.01초였다. 기본값 0.5는 많이 줄였지만 필요한 호출 여덟 개를 버렸다. 같은 응답에 0.3을 적용하자 관련 호출 60개를 모두 살리면서도 전체 기록의 79.4%를 제거했다. 별도 실행에서도 0.3은 60개를 모두 보존했고 무관한 호출은 다섯 개만 남겼다.

이 수치를 실제 개발 비용 절감률로 읽으면 안 된다. 파일 경로로 정답을 만든 통제 실험이고, 관련 파일 전문을 모두 다시 필요로 한다는 뜻도 아니다. 다만 대형 프레임워크를 탐색하며 쌓인 약 56만 자의 기록에서 JEV가 관련 호출과 무관한 호출을 구분했고, 임계값 선택이 보존율과 압축률을 크게 바꾼다는 것까지는 직접 확인했다.

완료된 Claude Code 세션에서는 구분하지 못했다

인공적인 경로 정답이 결과를 부풀리는지 확인하기 위해 이 저장소에서 완료된 실제 Claude Code 세션 하나를 다시 재생했다. 원본은 5.15MB, 정규화한 메시지는 477개, 도구 호출은 188개였다. 기록된 세션 비용은 44.78달러였지만 여러 모델의 누적 비용이므로 이번 압축으로 절약 가능한 금액으로 환산하지 않았다.

도구 호출의 50%, 70%, 85% 지점을 각각 압축 시점으로 잡았다. 각 시점 이후의 실제 기록에서 같은 파일 경로나 URL이 다시 등장하면 앞선 호출을 future-reused로 표시했다. 쓰기와 사용자 확인처럼 되돌리기 어려운 도구는 항상 보존하고 정확도 계산에서도 제외했다. 이 정답 역시 의미적 의존성을 완벽히 나타내지는 않지만, 결과를 본 뒤 유리한 호출만 고른 표본은 아니다.

0.3에서 시점별 문자 압축률은 16.6~27.1%였고 판정에는 0.55~1.10초가 걸렸다. 그러나 이후 다시 쓰인 대상을 20% 넘게 잃었다. 기준을 0.2로 낮추면 보존율은 100%가 됐지만 무관 호출은 평균 0.5%밖에 제거하지 못했다. 이 세션에서는 채택할 만한 운용 지점이 없었다.

첫 요청은 JEV의 최대 토큰 제한을 넘겨 실패하기도 했다. 프로토타입이 오래된 대화 전체를 판정 상태로 만든 탓이었다. 상태를 최근 정보 중심 1만2천 자로 제한한 뒤 실행은 됐지만, 이 수정은 긴 세션에서 상태 예산을 호스트 코드가 강제해야 한다는 조건을 추가한다.

따라서 Astro 결과만으로 79.4% 절감을 주장하면 안 된다. 현재 직접 측정한 결론은 더 좁다. JEV는 목표가 경로 이름에 명확히 드러나는 통제 기록에서는 잘 구분했지만, 여러 작업과 도구가 섞인 실제 세션에서는 같은 임계값이 일반화되지 않았다. 장시간 코딩 작업의 비용과 성공률이 좋아졌다는 증거도 아직 없다.

채택 여부를 다시 검토하려면 같은 개발 과제를 세 구성으로 반복해야 한다.

과제는 파일 읽기와 테스트 실패가 충분히 쌓이고, 압축 뒤에도 여러 단계가 남는 중형 리팩터링이 적합하다. 각 실행에서 다음을 함께 기록한다.

1. 작업을 끝낼 때까지의 총 입력·출력 토큰과 청구액
2. 압축에 걸린 시간과 전체 완료 시간
3. 삭제한 결과를 다시 읽거나 명령을 다시 실행한 횟수
4. 잘못된 파일 수정, 누락된 요구사항, 사람의 개입 횟수
5. 같은 테스트와 리뷰 기준을 통과했는지

minReductionRatio 기본값은 0.25다. Jev가 기록을 25% 이상 줄이지 못하면 기존 요약으로 돌아간다. 이 조건은 작은 세션에서 판정 호출만 추가하고 얻는 것이 없는 경우를 줄인다. 실험에서도 토큰 감소율만 보지 말고, 재실행을 포함한 총비용과 최종 성공률을 채택 기준으로 삼아야 한다.

코딩 에이전트의 제어 경로가 따로 생긴다

fast-jev-compaction 하나만으로 개발 비용이 사라지지는 않는다. 함수 훅은 아직 초기 기능이고 Claude Code 버전에 따라 바뀔 수 있다. Jev API가 실패할 수 있고, 판정이 틀릴 수 있으며, 긴 기록에서는 같은 상태를 여러 번 보내야 한다.

그래도 이 구현이 보여주는 방향은 분명하다. 지금까지 하나의 큰 모델이 코드 생성과 파일 선택, 로그 정리, 위험 심사, 실패 복구를 모두 맡았다. Jev처럼 빠른 판정기가 들어오면 호스트 프로그램이 후보와 보존 규칙을 만들고, Jev가 자주 반복되는 작은 판단을 처리하고, Claude는 새 답을 만들어야 하는 작업에 집중할 수 있다.

압축은 그중 효과를 계산하기 좋은 첫 자리다. 한 번 줄인 문맥이 뒤의 여러 호출에 영향을 주기 때문이다. 다만 가장 많이 지우는 압축기가 좋은 압축기는 아니다. 실제 개발 과제를 끝까지 수행하면서 총비용, 완료 시간, 재조회율, 결과 품질이 함께 좋아질 때 비로소 JEV가 개발 비용을 줄였다고 말할 수 있다.