AI 코딩 에이전트의 이미지 토큰 절감 방법론
AI 코딩 에이전트에 스크린샷을 올리는 일은 흔하다. 화면이 깨졌는지 보여주고, 오류 메시지를 그대로 전달하고, 디자인 시안을 확인받는다. 그런데 이 이미지 한 장의 비용이 얼마인지, 그리고 그 비용이 언제까지 계속되는지 아는 사람은 드물다.
우리 작업 기록 175개 세션을 전수 조사한 결과를 정리한다. 결론부터 적으면, 이미지의 진짜 비용은 올릴 때 한 번이 아니라 그 세션이 끝날 때까지 매번 발생한다.
1. 문제의 구조
대화형 AI는 상태를 기억하지 않는다. 매번 요청할 때마다 그때까지의 대화 전체를 다시 보낸다. 텍스트는 이 방식이 큰 부담이 아니지만 이미지는 다르다.
세션 초반에 스크린샷 한 장을 올리면, 그 뒤로 이어지는 모든 요청에 그 이미지가 계속 실려 간다. 50번 더 대화하면 같은 이미지를 51번 보낸 셈이 된다.
2. 실측
작업 기록 175개 세션에서 이미지 484장을 찾아 크기를 재고, 각 이미지가 몇 번 재전송되었는지 셌다.
| 항목 | 값 |
|---|---|
| 이미지 총 장수 | 484장 |
| 1회 전송 기준 토큰 | 약 56만 |
| 재전송까지 포함한 누적 | 약 4,814만 |
| 평균 재전송 배수 | 88배 |
발생원을 나누면 절반씩이다. 사람이 직접 붙여넣은 것이 51%, 에이전트가 파일을 열어본 것이 47.5%였다.
더 중요한 것은 언제 올렸느냐다.
| 이미지가 들어온 시점 | 장수 | 누적 토큰 | 평균 배수 |
|---|---|---|---|
| 세션 초반 | 61 | 930만 | 129배 |
| 세션 중반 | 118 | 1,051만 | 95배 |
| 세션 후반 | 76 | 305만 | 40배 |
같은 이미지라도 세션 초반에 열면 129배, 끝날 무렵에 열면 40배다. 남은 대화가 50턴 이상인 이미지가 전체 비용의 89.5%를 차지했다.
어떤 이미지를 올리느냐보다 언제 올리느냐가 100배 차이를 만든다.
3. 토큰이 정해지는 규칙
여기서 널리 퍼진 오해를 하나 짚는다.
파일 용량은 비용과 아무 관계가 없다.
PNG를 JPEG로 바꾸든 압축률을 올리든 토큰은 1도 줄지 않는다. 이미지 토큰은 오직 가로와 세로 픽셀 수로 정해진다.
토큰 ≈ (가로 × 세로) ÷ 750
여기에 상한이 둘 있다. 긴 변이 1568픽셀을 넘으면 그 크기로 줄고, 총 픽셀이 약 115만을 넘으면 거기서 한 번 더 줄어든다.
이 상한 때문에 생기는 함정이 있다. 1920×1080 전체화면 캡처는 이미 상한에 걸려 강제로 축소된다. 화질은 손해 보면서 요금은 최대로 내는 조합이다.
| 긴 변 | 16:9 기준 토큰 | 절감 |
|---|---|---|
| 1920 (원본) | 1,533 | 기준 |
| 1400 | 1,471 | 4% |
| 1280 | 1,229 | 20% |
| 1100 | 908 | 41% |
| 1000 | 751 | 51% |
1400픽셀로 줄여봐야 4%밖에 안 준다. 상한 아래로 충분히 내려가야 의미 있는 절감이 시작된다.
4. 줄이지 말고 잘라내라
토큰이 면적에 비례한다는 사실에서 실용적인 결론이 나온다.
화면의 4분의 1만 잘라내면 토큰도 4분의 1이 된다. 그런데 잘라내기는 줄이기와 달리 화질 손실이 없다. 원본 픽셀을 그대로 쓰기 때문에 글씨가 오히려 더 잘 보인다.
전체화면 캡처가 1,533토큰인데, 필요한 영역만 900×600으로 잘라내면 720토큰이다. 재전송 배수까지 감안하면 한 장에 7만 토큰 차이가 난다.
전체화면 단축키 대신 영역 캡처 단축키를 쓰는 것만으로 절반이 준다. 설치할 것도 설정할 것도 없다. 이게 가장 값싼 개선이다.
5. 손댈 수 있는 지점
비용이 발생하는 경로를 네 층으로 나눌 수 있다.
① 캡처하는 순간 영역 캡처 습관. 도구도 설정도 필요 없고 효과가 가장 확실하다.
② 업로드하는 관문 자체 제작한 웹 클라이언트나 메신저 봇을 거쳐 이미지가 들어온다면, 그 서버 한 곳에서 축소하면 된다. 기기마다 설정할 필요가 없다는 것이 이 방식의 장점이다.
긴 변을 기준으로 자르는 방식은 세로로 긴 휴대폰 캡처를 거의 못 깎는다. 총 픽셀 수를 예산으로 잡는 편이 낫다. 70만 픽셀로 잡으면 가로든 세로든 한 장당 약 930토큰으로 균일해진다.
우리 측정으로는 이 방식이 데스크탑 캡처에서 39%, 휴대폰 캡처에서 28%를 줄였다.
③ 에이전트가 파일을 여는 순간 에이전트가 스스로 이미지 파일을 열어보는 경우다. 도구 호출을 가로채는 훅으로 처리할 수 있다.
여기서 직관에 반하는 실측 결과가 나왔다. 우리는 처음에 이미지를 가벼운 모델에게 대신 보게 하고 그 설명만 본체로 넘기는 방식이 가장 강력할 것이라고 보았다. 이미지가 대화에 아예 남지 않으니 재전송이 사라진다는 논리였다. 틀렸다.
이유는 이렇다. 이미지 토큰에는 상한이 있어서 전체화면 캡처 한 장은 아무리 커도 약 1,533토큰이다. 그런데 그 화면을 사람이 못 보는 상태에서 판단할 수 있을 만큼 충실히 글로 옮기면 텍스트도 비슷한 분량이 된다. 화면 넷을 실측한 결과 절감은 4%에서 34% 사이였다. 재전송 배수는 이미지든 텍스트든 똑같이 곱해지므로 이 비율이 그대로 최종 절감률이다.
같은 이미지를 1000픽셀로 줄이기만 하면 51%가 준다. 텍스트로 옮기는 쪽보다 절감이 크다.
정확도는 더 벌어진다. 대신 보게 한 가벼운 모델은 800픽셀에서 한글을 여러 군데 잘못 읽었다. 조직홍보를 조직혁신으로, 비전찾기를 비전창기로, 영문 식별자 test-sihyeon-1을 test-stlyeon-1로 옮겼다. 같은 화면을 1000픽셀로 줄여 본체 모델이 직접 보게 했더니 전부 정확히 읽혔다.
정리하면 단순 축소가 절감과 정확도 양쪽에서 텍스트 대체를 이긴다. 게다가 본체가 화면을 직접 보므로 눈으로 확인한다는 원칙이 그대로 유지되고, 다른 모델을 부르는 20초 지연도 없다.
텍스트 대체가 유리한 경우가 아주 없지는 않다. 캡처 수십 장을 한 번에 훑어 목록만 얻으면 되는 작업처럼, 정확한 판독보다 대량 처리가 중요할 때다. 기본값으로 둘 것은 아니고 스위치로 남겨둘 일이다.
한 가지 더. 작은 이미지는 아예 건드리지 않는 편이 낫다. 390×844 휴대폰 캡처는 438토큰인데 이를 충실히 글로 옮기면 약 895토큰이 되어 두 배 손해였다.
④ 세션을 관리하는 층 이미지가 쌓인 세션은 일찍 마무리한다. 재전송 배수가 곧 비용이므로, 이미지를 올린 뒤 대화를 길게 끄는 것이 가장 비싸다. 이미지가 들어온 세션을 다음 날 이어받는 것이 최악이다.
6. 도구를 고를 때 주의할 점
토큰을 크게 줄여준다는 도구가 여럿 있는데, 상당수가 API 호출을 가로채는 로컬 프록시 방식이다. 대화 내용 전체가 제3자 코드를 통과한다는 뜻이다. 업무 자료를 다룬다면 권하지 않는다.
텍스트를 이미지로 렌더링해 압축한다는 접근도 있다. 방향이 반대이므로 이 문제의 해법으로 쓸 것은 아니다.
7. 남는 한계
플랫폼이 이 문제를 해결해 줄 것을 기대하기는 어렵다. 스크린샷 누적을 다룬 공식 이슈는 수정 계획 없음으로 닫혔고, 대화에서 이미지만 골라 지우는 기능 요청도 중복 처리되었다. 현재로서는 전체를 요약하거나 전체를 비우는 방법밖에 없다.
에이전트가 파일을 여는 경로에는 이미 자동 축소가 걸려 있는 경우가 있다. 그런데 그 축소 판단에 쓰이는 토큰 추정이 실제보다 크게 부풀려져 있다는 보고가 있다. 필요 이상으로 뭉개진 이미지를 에이전트가 보고 있을 수 있다는 뜻이므로, 여기를 더 줄이려는 시도는 이득이 작고 화질만 잃기 쉽다.
사람이 직접 붙여넣는 이미지는 훅으로 막을 수 없다. 도구 호출을 가로채는 방식이라 붙여넣기 경로에는 개입할 수 없기 때문이다. 이 절반은 캡처 습관과 세션 관리로만 다룰 수 있다.
8. 정리
우선순위대로 적는다.
- 영역 캡처로 바꾼다. 비용 0, 효과 절반.
- 이미지가 들어온 세션은 일찍 접는다. 재전송 배수가 비용의 본체다.
- 자체 서버를 거치는 업로드 경로가 있으면 픽셀 예산으로 축소한다.
- 에이전트가 여는 이미지는 훅으로 축소한다. 텍스트로 바꾸지 말고 줄이기만 한다. 그래도 눈으로 봐야 할 때를 위한 우회 스위치는 남긴다.
한 문장으로 줄이면 이렇다. 작게 찍고, 잘라서 올리고, 올렸으면 빨리 끝낸다.
마지막으로 방법론을 다루는 글답게 하나 남긴다. 이 문서의 초안은 텍스트 대체를 가장 강한 수단으로 적고 있었다. 실제로 만들어 재보고 나서야 그 방법이 두 번째로 좋은 축에도 못 든다는 것을 알았다. 토큰 절감은 직관이 잘 듣지 않는 영역이다. 상한과 재전송 배수가 겹쳐 있어서, 그럴듯한 설계가 실측에서 뒤집히는 일이 흔하다. 무엇을 도입하든 자기 환경에서 한 번은 직접 재보기를 권한다.
참고
- 스크린샷 누적 문제 보고: anthropics/claude-code 이슈 27869
- 선택적 이미지 제거 요청: 같은 저장소 이슈 52224
- 이미지 토큰 추정 오류 보고: 같은 저장소 이슈 70010
관련 노드: 작업효율화_마스터기획안, 유료구독_인벤토리