영상에서 단테는 Codex CLI에서 같은 Astra 모델을 쓰면서, 입력 자료를 TypeSafe의 판단 모델 Jev로 먼저 선별하면 입력 토큰이 얼마나 달라지는지 직접 측정했습니다. 코딩 에이전트에 여러 파일이나 긴 검색 결과를 넣어 쓰는 분, 그리고 "토큰 절감" 주장을 자기 작업에서 어떻게 검증할지 고민하는 분께 도움이 되는 내용입니다.
실험 조건을 어떻게 고정했나
대상은 공개된 jev-code 저장소입니다. 이 저장소의 실제 소스와 문서 17개를 후보 자료로 가져왔고, 요청은 검색 결과를 고르는 도구에 옵션 하나를 추가하는 작업이었습니다. 관련 없는 항목을 빼 달라고 했을 때의 동작을 바꾸는 것으로, 제외할 항목이 결과 개수 제한을 먼저 차지하면 안 된다는 조건이 붙었습니다.
두 조건 모두 Codex CLI에서 모델을 gpt-6-astra로 명시하고 추론 강도는 medium으로 고정했습니다. 요청문, 수정할 기능, 통과해야 할 테스트도 같습니다. 바뀌는 것은 Astra에 전달하는 자료뿐입니다. 한 번 잘 나온 수치만 골라 보여주지 않도록, 순서를 바꿔 가며 조건마다 세 번씩 총 6회 실행하기로 미리 정했습니다.
비교 기준은 모아 둔 후보 파일 17개를 전부 프롬프트에 넣는 조건입니다. 단테는 이것이 Codex가 평소 저장소 전체를 읽는다는 뜻이 아니며, Codex가 스스로 필요한 파일을 찾아 읽는 기본 동작과 비교한 실험도 아니라고 분명히 했습니다. 이미 모아 둔 자료를 넣어야 하는 상황에서 먼저 선별하면 얼마나 달라지는지를 본 것입니다.
Jev가 먼저 파일을 고르는 구조
여기서 중요한 것은 순서입니다. Astra가 자료를 다 읽은 뒤 Jev에게 넘기면 입력 토큰은 이미 쓴 상태가 됩니다. 그래서 로컬 스크립트가 후보 파일을 먼저 Jev에게 보내고, 선택된 파일의 원문만 Astra 요청에 넣었습니다.
Jev는 정해진 보기 중에서 고르거나 조건에 맞는지 판단하는 역할의 모델입니다. 코드를 작성하는 모델은 계속 Astra이고, 바꾼 것은 Astra가 읽는 자료의 양뿐입니다. Jev는 세 번 모두 17개 중 2개를 골랐습니다. 결과를 정렬하는 rank.ts와 입력 형식을 정의하는 schemas.ts로, 실제로 수정해야 할 파일 두 개가 모두 포함됐습니다. 선별 결과를 재사용하지 않고 매번 Jev를 새로 호출했으며, 선택된 파일은 요약하거나 고치지 않고 원문 그대로 넘겼습니다.
결과: 기능은 유지, Astra 입력은 감소
입력이 줄었다고 바로 성공으로 볼 수는 없으니 결과 코드부터 확인했습니다. 관련 없는 결과를 거르는 시점이 결과 개수 제한보다 앞서는지, 옵션을 주지 않은 기존 사용법이 계속 동작하는지, 잘못된 응답을 제외하는지, 기준값과 같은 점수를 포함하는지를 검사했습니다. 6회 모두 빌드에 성공했고 같은 기능 검사 13개를 전부 통과했습니다. 다만 단테는 이것이 더 좋은 코드를 만들었다는 뜻은 아니라고 덧붙였습니다.
Codex가 보고한 Astra 입력 토큰은 다음과 같았습니다.
- 전체 자료 조건: 평균 32,276토큰
- Jev 선별 조건: 평균 17,484토큰
- 두 평균을 비교하면 약 45.8% 감소
캐시 재사용과 저장은 6회 모두 0으로 기록됐습니다. 반면 Astra의 출력 토큰은 선별 조건에서 더 많았습니다.
Jev 사용량과 실행 시간까지 더하면
Jev가 읽은 입력도 따로 있습니다. 선별 한 번에 20,474토큰이 들었고, Astra 입력과 더하면 평균 37,958토큰으로 전체 자료 조건의 32,276토큰보다 약 17.6% 많습니다. 실행 시간도 전체 자료 조건이 평균 14.6초, 선별 조건은 Jev 과정을 포함해 평균 18.7초로 오히려 늘었습니다.
단테는 이 합계를 청구 금액으로 해석하면 안 된다고 강조했습니다. 공급자마다 토큰을 세는 단위와 가격이 다르기 때문입니다. 이번 결과만으로 비용이 절약됐다고 말할 수 없고, 한 저장소의 한 가지 변경을 세 번씩 실행한 결과이므로 다른 프로젝트에서 같은 비율로 줄어든다는 보장도 없습니다. 필요한 파일을 놓치면 Astra가 다시 찾거나 코드를 고쳐야 하고, 그때 들어간 토큰도 합쳐서 봐야 합니다.
재현 방법, 공식 스킬, MCP 연결
같은 실습을 해볼 수 있도록 입력 자료와 실행 스크립트를 묶어 두었습니다. Codex 로그인과 TypeSafe API 키를 준비하면 예제 폴더에서 선별과 비교를 실행할 수 있습니다. 키 값은 화면이나 프롬프트에 넣지 않고 환경 변수로 전달합니다.
TypeSafe 공식 스킬은 API 사용법을 에이전트에게 알려주는 자료로, Claude Code와 Codex에 각각 설치할 수 있습니다(설치 안내: https://docs.typesafe.ai/agent-skill). 다만 스킬을 설치한다고 모든 작업의 입력이 자동으로 줄지는 않습니다. Jev를 도구로 연결하려면 커뮤니티 프로젝트 jev-code의 MCP 서버를 쓸 수 있고, Codex에서는 Jev 분류 도구가 실제로 응답하는 것까지 확인했습니다. 이번 비교에서는 이 도구 대신 입력 전에 파일을 고르는 별도 스크립트를 썼습니다. 도구 연결과 입력 자료 축소는 별개의 문제로 봐야 한다는 것이 단테의 설명입니다.
Claude Code에서도 같은 MCP 서버를 연결해 Jev 도구 다섯 개가 연결되는 것까지 확인했지만, 기존 로그인이 만료돼 모델이 도구를 호출하는 단계는 완료하지 못했습니다. 따라서 영상의 전후 수치는 모두 Codex Astra 결과입니다.
이 실험의 계기는 X에 올라온 글이었습니다. 작성자는 Astra의 작업 단계마다 추론 강도를 조절해 자신의 테스트에서 비용이 50% 줄었다고 했지만, 이는 이번에 측정한 자료 선별과는 다른 방식이고 이번 비교에서 재현한 결과도 아닙니다. 조사 기준일인 9월 22일에는 설치할 수 있는 구현 링크를 찾지 못했습니다.
정리
- 같은 Astra, 같은 추론 강도로 두 조건을 각 3회 실행했고, 13개 기능 검사는 6회 모두 통과했습니다.
- Astra 입력 토큰은 평균 기준 약 45.8% 줄었지만, Jev 입력을 더한 합계와 실행 시간은 늘었습니다.
- 자료를 거의 쓰지 않는 작은 요청에는 선별 호출이 오히려 손해일 수 있고, 매번 긴 검색 결과나 여러 파일을 넣는 작업이라면 비교해 볼 만합니다.
- 자기 작업에 적용할 때는 정답과 필수 근거가 남는지, 그리고 호스트 모델과 Jev의 사용량을 함께 확인해야 합니다.