AI 코딩 도구의 토큰 절감, 청구서 절감으로 계산하면 틀리는 이유

AI 코딩 에이전트의 사용량이 늘면 팀은 곧 비용 최적화 도구를 찾게 됩니다. 터미널 출력을 줄여 입력 토큰을 아끼는 RTK 같은 도구는 매력적으로 보입니다. 대시보드에 60%, 90% 같은 절감률이 표시되면, 다음 달 모델 사용료도 비슷하게 줄 것으로 기대하기 쉽습니다.

하지만 CTO나 개발 리드가 확인해야 할 숫자는 토큰 절감률이 아니라 성공적으로 끝난 개발 작업 1건당 총비용입니다. 출력 압축은 비용을 낮출 수도 있지만, 에이전트가 정보를 덜 받아 추가 명령을 실행하거나 판단을 잘못해 재시도하면 오히려 비용과 리뷰 부담이 늘 수 있습니다.

압축 도구를 도입할지 결정할 때는 제품의 절감 수치를 받아들이기보다, 팀의 모델·에이전트·저장소·작업 방식 안에서 비용과 성공률을 함께 재는 자체 벤치마크가 필요합니다.

오해: 줄어든 출력 바이트가 곧 절감된 과금 토큰이다

터미널 출력 압축 도구는 ls, git, 테스트, 패키지 명령처럼 사람이 읽기에는 장황한 결과를 짧게 바꿉니다. 파일 목록에서 소유자나 날짜를 빼고, 긴 로그에서 반복 행을 줄이는 방식입니다. 에이전트가 셸 도구로 읽는 정보량은 분명 줄어들 수 있습니다.

다만 도구가 표시하는 “절감 토큰”은 과금 명세의 입력 토큰과 다를 수 있습니다. 일부 압축 지표는 원본 출력과 필터링된 출력의 바이트 차이를 일정 비율로 환산합니다. 에이전트가 애초에 head, tail, grep, wc 등으로 제한해서 요청한 출력, 실제로 모델 컨텍스트에 들어가지 않은 출력, 캐시에서 저렴하게 다시 읽힌 입력까지 모두 같은 값으로 볼 수 없습니다.

에이전트 환경에서는 더 중요한 차이도 있습니다. 셸 출력이 줄어도 파일 읽기, 코드 검색, 디렉터리 탐색이 별도 도구로 실행되면 압축 대상이 아닐 수 있습니다. 반대로 압축된 정보가 부족하면 에이전트가 추가 검색과 확인 명령을 실행합니다. 이때 줄어든 입력 토큰보다 새로 생성된 추론 토큰과 응답 토큰이 더 커질 수 있습니다.

판단 기준은 “얼마나 많이 삭제했는가”가 아니라 “모델 공급자 청구 데이터에서 어떤 항목이 얼마나 변했는가”입니다. 입력, 캐시 입력, 출력, 추론 사용량을 분리해 봐야 합니다.

현실: 비용은 한 번의 호출이 아니라 작업 완료 과정에서 생긴다

압축 도구의 경제성은 다음처럼 계산하는 편이 낫습니다.

성공 1건당 총비용 = 모든 실행의 모델 비용 + 도구 운영비용 + 사람의 검토·복구 비용 ÷ 성공적으로 완료된 작업 수

여기서 모든 실행에는 실패, 시간 초과, 같은 작업의 재시도가 포함됩니다. 모델 비용만 보더라도 성공한 실행만 골라 평균을 내면 위험합니다. 운영 환경에서는 실패한 에이전트 실행도 청구되고, 실패 원인을 사람이 확인하는 시간도 남습니다.

공개된 비교 실험에서도 이런 차이가 나타났습니다. 터미널 상호작용이 많은 과제를 여러 차례 반복한 한 테스트에서, 출력 압축을 적용한 뒤 한 모델 조합의 총 청구액은 소폭 낮아졌지만 다른 모델 조합에서는 올랐습니다. 성공률도 각각 조금씩 낮아졌습니다. 성공한 작업 수로 모든 지출을 나누면 결과는 다시 달라졌고, 과제별 평균 비용으로 비교하면 특정 조합은 평균 비용 증가가 더 크게 나타났습니다.

이 결과가 모든 팀에 같은 결론을 뜻하지는 않습니다. 다만 다음 사실은 분명합니다. 같은 압축 도구라도 모델, 에이전트 프레임워크, 셸 호출 비중, 캐시 가격, 과제 난이도에 따라 비용 효과가 달라집니다.

특히 다음 조건에서는 토큰 절감률과 비용 절감률의 차이가 커질 수 있습니다.

• 에이전트가 이미 출력 범위를 좁히는 명령을 자주 사용하는 경우
• 파일 읽기와 검색이 셸이 아닌 별도 도구로 처리되는 경우
• 장기 컨텍스트가 캐시되어 후속 입력 단가가 낮은 경우
• 복잡한 오류 로그나 환경 정보를 압축 없이 보아야 문제를 해결하는 경우
• 에이전트가 압축된 결과를 신뢰하지 못해 확인 명령을 반복하는 경우

오해: 총 청구액만 낮으면 도입해도 된다

총 청구액은 중요한 지표지만, 작업 구성이 조금만 바뀌어도 쉽게 흔들립니다. 소수의 비싼 과제 하나가 전체 비용 변화를 만들어낼 수 있고, 쉬운 작업이 많이 섞이면 품질 저하가 가려질 수도 있습니다.

운영 단계의 팀이라면 작업을 먼저 몇 가지로 나누는 편이 좋습니다. 예를 들어 버그 재현과 수정, 테스트 실패 원인 분석, 의존성 업데이트, 리팩터링, 신규 기능 구현, 배포 장애 조사처럼 에이전트 사용 목적이 다른 작업을 구분합니다. 각 그룹은 필요한 정보의 양과 실패 비용이 다릅니다.

그다음 압축 도구 미적용 조건과 적용 조건을 같은 환경에서 비교합니다.

• 같은 모델과 모델 라우팅
• 같은 에이전트 버전과 권한 범위
• 같은 저장소 상태와 의존성 환경
• 같은 작업 지시문과 완료 판정 기준
• 같은 시간 제한과 최대 재시도 정책
• 가능한 한 비슷한 시간대의 가격 정책과 API 설정

한 조건에서 먼저 모두 실행하고 다른 조건을 나중에 실행하면 모델 업데이트, API 장애, 캐시 상태, 저장소 변경이 결과에 섞일 수 있습니다. 가능하다면 과제를 번갈아 배정하고, 같은 과제를 여러 번 실행해 실행 간 변동도 기록해야 합니다.

현실: 성공률과 복구 시간까지 봐야 운영 예산을 설명할 수 있다

자체 벤치마크는 적어도 네 가지 결과를 남겨야 합니다.

비교 항목	확인할 질문
작업 성공률	테스트 통과, 요구사항 충족, 리뷰 가능 상태까지 도달했는가
성공 1건당 모델 비용	실패와 재시도 비용을 포함해 완료 작업 수로 나누면 얼마인가
완료 시간과 턴 수	압축 후 추가 탐색, 반복 명령, 시간 초과가 늘었는가
사람의 개입량	리뷰 수정, 실행 중단, 오류 분석, 수동 복구가 얼마나 발생했는가

성공 판정은 “에이전트가 종료했다”가 아니라 팀이 일을 받아들일 수 있는 상태여야 합니다. 코드 변경 과제라면 빌드와 테스트 통과 여부, 요구된 파일 변경 여부, 금지된 변경이 없는지 같은 검증 규칙을 미리 정합니다. 운영 장애 조사라면 원인 후보를 제시하는 데서 끝내지 않고, 재현 가능한 근거와 다음 조치가 남았는지 확인해야 합니다.

조기 경고 신호도 따로 봐야 합니다. 적용 후 셸 명령 수가 늘거나, 같은 오류 메시지가 반복되거나, 도구 자체의 지원하지 않는 옵션 오류가 나타난다면 압축이 정보를 덜 주는 문제보다 명령 재작성 호환성 문제가 원인일 수 있습니다. 한 공개 실험에서는 특정 find 옵션을 압축 도구가 제대로 처리하지 못해 에이전트가 오류를 반복한 사례가 있었습니다. 해당 실행은 과제를 통과했어도 시간과 비용이 크게 늘었습니다.

따라서 운영 도입 전에는 “지원하지 않는 명령은 원래 명령으로 안전하게 통과시키는가”, “도구 오류가 반복될 때 자동 적용을 중단할 수 있는가”, “버전 변경 후 회귀 테스트를 어떻게 할 것인가”를 확인해야 합니다.

압축 도구는 전사 기본값보다 조건부 정책으로 시작하는 편이 낫다

벤치마크 결과가 모든 작업에서 일관되게 좋지 않다면, 전사 기본값으로 켜기보다 적용 범위를 좁힐 수 있습니다. 출력량이 크고 정보 손실 위험이 낮은 명령에만 적용하거나, 특정 에이전트와 모델 조합에서만 활성화하는 방식입니다. 반대로 장애 분석, 보안 점검, 복잡한 빌드 실패처럼 원본 로그의 문맥이 중요한 작업은 제외 후보가 됩니다.

예산 담당자에게는 “토큰을 몇 퍼센트 줄였다”보다 다음 문장으로 보고하는 편이 정확합니다.

이 도구는 현재 작업군에서 성공 1건당 모델 비용과 완료 시간을 함께 낮추는지 검증 중이며, 성공률 또는 복구 부담이 나빠지는 작업에는 적용하지 않는다.

도입 승인은 압축률 그래프가 아니라 이 기준으로 내리면 됩니다. 먼저 팀에서 자주 발생하고 완료 조건이 분명한 작업군을 고른 뒤, 미적용 조건과 적용 조건의 성공 1건당 비용을 비교하십시오. 그 차이가 재현되고, 실패 처리 부담까지 감당할 수 있을 때만 운영 정책에 넣는 것이 안전합니다.