코드를 PNG로 찍어 Claude에 보내면 청구서가 60% 준다 — pxpipe가 발견한 토큰의 물리학

핵심 요약 (TL;DR)

pxpipe는 텍스트를 PNG로 렌더링해 Claude에 보내는 로컬 프록시입니다. Fable 5 워크로드에서 청구서 59~70% 감소, SWE-bench Lite 파일럿에서 요청 크기 -65%. 트레이드오프는 Opus 4.8의 약 7% 오독입니다. 원리는 단순합니다. 이미지 토큰 비용은 픽셀 치수에 고정, 내용 밀도와 무관합니다.

Claude Code Max를 써도 대형 리팩터링에서 왜 벽에 부딪힐까요?

월 200달러짜리 Claude Code Max 요금제를 쓰는데도, 대형 monorepo 리팩터링을 시도하면 두 가지 벽에 부딪힙니다. 컨텍스트 상한, 그리고 비용입니다. 시스템 프롬프트와 툴 정의만 30K 토큰이 넘어가고, 여기에 관련 파일 20~30개를 물리면 한 세션에 6~8달러가 우습게 나갑니다. 사용량 제한도 하루 몇 번이면 소진됩니다.

teamchong의 pxpipe는 이 벽을 아주 이상한 각도에서 뚫습니다. 텍스트를 텍스트로 보내지 않고, PNG 이미지로 렌더링해서 보냅니다. 벤치 결과부터 볼까요.

• Fable 5 종단간 청구서: 59~70% 감소
• SWE-bench Lite 파일럿: 요청 크기 −65%, 정확도 10/10
• 1928×1928 PNG 한 장이 담는 텍스트: 약 92,000자
• 그 이미지의 비전 토큰: 약 4,761개

텍스트로 92,000자를 보내면 대략 30,000 토큰이 나갑니다. 이미지로 보내면 4,761 토큰입니다. 압축이 아니라 물리적 사실입니다.

이미지 토큰이 왜 텍스트보다 밀도가 높나요?

원리는 단순합니다. Claude의 비전 토큰 비용은 이미지의 픽셀 치수에 고정됩니다. 픽셀 안에 무엇이 들어 있는지, 픽셀당 정보 밀도가 얼마인지는 계산에 반영되지 않습니다. 즉 픽셀당 정보 밀도를 최대로 끌어올리면 이득이 극대화되는 구조입니다.

텍스트는 문자당 대략 1 토큰이 나갑니다. 반면 렌더된 이미지는 문자당 약 3.1 토큰만 소모합니다. 텍스트가 이미지보다 3배 이상 비쌉니다. pxpipe는 이 사실을 시스템 프롬프트, 툴 문서, 대형 파일 컨텍스트에 적용해서 청구서를 반으로 자릅니다.

어떻게 쓰나요?

pxpipe는 로컬 프록시로 동작합니다. Claude에 나가는 요청을 가로채서, 텍스트 페이로드를 PNG로 렌더링한 뒤 이미지 첨부로 대체합니다. 사용 흐름은 대략 이렇습니다.

# 로컬 프록시 실행
pxpipe start --port 8787

# Claude Code나 SDK를 프록시 통해서 호출
export ANTHROPIC_BASE_URL=http://localhost:8787
claude --model claude-opus-4-8 "이 리포지토리 리팩터링해줘"

프록시가 판단해서 큰 텍스트 블록만 이미지화하고, 짧은 인스트럭션은 그대로 텍스트로 보냅니다. 흥미로운 건 저장소 자체의 상당 부분이 pxpipe를 프록시로 통과한 Claude 세션이 작성했다는 점입니다. 자기가 만든 최적화를 자기가 사용해 만드는 재귀 구조죠.

함정: Opus 4.8이 이미지의 약 7%를 오독합니다

무료 점심은 없습니다. Opus 4.8은 렌더된 이미지에서 약 7%의 오독을 일으키고, 정확한 문자열 재현 테스트에서는 15개 중 13개만 성공했습니다. 공백·특수문자·긴 식별자에서 실수가 몰릴 가능성이 크죠.

실전에서 이 7%를 어떻게 다룰 수 있을까요?

1. 중요 식별자는 텍스트로 유지: 함수명·클래스명·파일 경로 같은 정확 재현 필요 부분은 이미지화에서 제외
2. 폰트·해상도 튜닝: 픽셀당 문자 밀도를 낮춰 가독성 확보(비용 절감 폭은 다소 줄지만)
3. 재요청 정책: 응답이 특정 식별자를 왜곡했다고 감지되면 해당 부분만 텍스트로 재전송

7% 오독은 사람 코드 리뷰의 오탐율보다 낮은 수준이지만, 침묵의 오독이라는 점에서 위험 특성이 다릅니다. 프로덕션에 넣기 전 도메인별로 시험 리포지토리 3개(대형 monorepo·중형 웹앱·소형 CLI)에 정직하게 벤치해보시는 걸 권합니다.

FAQ

Q. GPT나 Gemini에도 통하나요?

원리상 이미지 토큰 계산 방식이 비슷한 모델(GPT-5.5, Gemini 3.1)에서는 유사한 이득이 예상되지만, pxpipe의 벤치는 Fable 5와 SWE-bench Lite에서 Claude 기준으로 검증됐습니다. 다른 모델은 자체 벤치가 필요합니다.

Q. 프록시 렌더링 시간이 절감액을 상쇄하지 않나요?

로컬 렌더링은 요청당 수백 밀리초 수준입니다. 반면 대형 리팩터링 세션의 API 응답은 수 초에서 수십 초 걸리므로, 렌더링 오버헤드는 실질적으로 무시할 수 있습니다.

Q. 오늘 실측해볼 수 있는 최소 실험은요?

대형 시스템 프롬프트 하나를 이미지로 렌더링해 기존 텍스트 프롬프트와 동일 질문 10개를 각각 돌려보세요. 응답 품질과 청구서 차이만 봐도 이 접근이 여러분의 워크로드에 통하는지 30분 안에 감이 옵니다.

어제 소개한 claude-real-video가 비디오 축의 토큰 압축이었다면, 오늘 pxpipe는 텍스트 축의 같은 발견입니다. 이미지 토큰이 텍스트보다 밀도가 3배 높다는 물리적 사실이, 한 주 사이 서로 다른 도메인에서 두 번 재발견됐습니다. 앞으로 몇 달간 이 축에서 새 최적화 도구가 계속 나올 겁니다.