🤖
1200 in / 5837 out / 7037 total tokens
🔥 핫 토픽
Universal Claude.md – Claude 출력 토큰 절감 가이드
Hacker News에서 265점을 받은 이 저장소는 Claude의 출력 토큰을 획기적으로 줄이는 범용 프롬프트 템플릿을 제공한다. 단순히 "짧게 대답해"라는 식의 접근이 아니라, 구조화된 시스템 프롬프트를 통해 Claude가 본능적으로 길게 작성하려는 성향을 제어하는 방법을 담고 있다. API 호출 비용이 출력 토큰 기준으로 책정되는 현실에서 이건 그냥 팁 수준이 아니라 실제 프로덕션 비용에 직접 타격을 주는 기술적 과제다.
Claude는 기본적으로 "도움이 되려고" 과하게 설명하는 경향이 있다. 코드 리뷰를 요청하면 단순히 "버그 있음"이라고 하지 않고, 왜 버그인지, 어떤 원리인지, 비슷한 사례는 무엇인지까지 늘어놓는다. 사용자 입장에서는 친절하지만, API 비용 관점에서는 재앙이다. 입력 1000토큰에 출력 3000토큰이 나가는 상황이 반복되면 월 청구서가 눈물난다. 이 저장소는 그 딜레마를 시스템 프롬프트 레벨에서 해결한다.
핵심 아이디어는 "dense information packing"이다. Claude에게 정보를 압축하는 방식을 명시적으로 가르치는 것. 예를 들어 불렛 포인트 대신 세미콜론으로 구분하거나, 예시를 최소화하거나, 군더더기 문장을 제거하는 규칙을 코딩하듯 명세한다. 일종의 "압축 알고리즘을 프롬프트로 구현"하는 셈이다. 게임 개발할 때 메모리 절약 위해 데이터 구조 최적화하는 것과 같은 맥락이다.
출처: GitHub - drona23/claude-token-efficient
💡 왜 이게 중요한가
토큰 비용의 실체
Claude API 가격을 보면 입력 토큰보다 출력 토큰이 3~5배 비싸다. Claude 3.5 Sonnet 기준으로 입력 백만 토큰에 3달러, 출력 백만 토큰에 15달러다. 입력은 모델이 읽는 거고 출력은 모델이 생성하는 건데, 생성 비용이 훨씬 크다. 이건 게임 서버에서 CPU 연산보다 네트워크 대역폭이 비싼 것과 비슷하다. 읽기는 싼데 쓰기가 비싼 구조다.
실제 프로젝트에서 체감해보니, 대화형 챗봇보다 코드 생성이나 문서 요약 작업에서 출력 토큰 폭증이 심하다. 코드 하나 수정해달라고 하면 Claude가 전후 맥락 50줄을 다시 뱉어내는 경우가 있다. diff 형식으로 달라고 해도 종종 전체 코드를 출력하려 든다. 이 저장소의 템플릿을 적용하면 그런 낭비를 40~60%까지 줄일 수 있다고 한다. 월 100달러 쓰던 걸 50달러로 줄이는 건 확실한 성과다.
경쟁 모델과의 비교
GPT-4도 출력이 길어지는 경향이 있지만, Claude가 유독 심하다. OpenAI는 o1 시리즈에서 "thinking tokens"를 별도 과금하면서 사고 과정과 최종 답변을 분리했다. 반면 Anthropic은 아직 그런 구분이 없다. 그래서 사용자가 직접 프롬프트 레벨에서 제어해야 한다. 이 저장소가 인기를 끄는 이유가 여기에 있다. 공식 기능이 없으니 커뮤니티가 해결책을 만든 셈이다.
Gemini의 경우 1.5 Pro에서 컨텍스트 윈도우가 100만 토큰까지 늘어났지만, 출력은 여전히 8천 토큰으로 제한된다. 모델이 알아서 적당히 끊어주는 구조다. Claude는 출력 제한이 있어도 그 안에서 최대한 길게 쓰려 한다. 모델의 "성격" 차이다. Claude는 기본적으로 철수다. 뭐든 자세히 설명하려 한다. 그걸 제어하는 게 이 프로젝트의 목표다.
🛠️ 실무 적용 관점
어떤 방식들이 있는가
저장소를 뜯어보면 몇 가지 패턴이 보인다. 첫째, "response template" 강제다. JSON, YAML 같은 구조화된 포맷으로만 답하라고 하면 군더더기가 사라진다. 둘째, "verbosity level" 설정이다. 1~5 단계로 상세함을 지정하면 모델이 스스로 조절한다. 셋째, "negative constraints"다. "예시를 들지 마", "비유하지 마", "역사적 배경 설명하지 마" 같은 부정적 제약을 주면 의외로 잘 따른다.
게임 개발으로 치면 이건 일종의 "LOD 시스템"이다. 카메라 거리에 따라 메시 디테일을 조절하듯, 사용자 의도에 따라 응답 디테일을 조절하는 것. 멀리서 보면 로우폴리, 가까이서 보면 하이폴리. 프롬프트에 "간단히"라고만 하면 로우폴리가 안 나온다. 구체적으로 "삼각형 100개 이하로"라고 해야 한다. 그 원리를 토큰에 적용한 것이다.
서버 아키텍처와의 연관성
API 호출을 많이 하는 서비스라면 토큰 절감은 곧 서버 비용 절감이다. 예를 들어 실시간 코딩 어시스턴트를 만든다고 하자. 사용자가 타이핑할 때마다 Claude를 호출하면 출력 토큰이 눈덩이처럼 불어난다. 이때 시스템 프롬프트에 토큰 절감 템플릿을 박아넣으면, 응답 속도도 빨라지고 비용도 줄어든다. 출력 토큰이 적으면 스트리밍 완료 시간도 짧아지니 UX도 개선된다.
또 하나 중요한 건 캐싱이다. Anthropic은 프롬프트 캐싱을 지원하는데, 시스템 프롬프트가 길어도 캐시되면 입력 비용이 90%까지 줄어든다. 그런데 출력은 캐시가 안 된다. 매번 새로 생성하니까. 그래서 입력은 캐싱으로 해결하고 출력은 프롬프트로 제어하는 게 정석적인 최적화 전략이다. 이 저장소는 후자를 담당한다.
한계와 주의점
물론 만능은 아니다. 너무 강하게 압축하면 응답 품질이 떨어질 수 있다. 특히 복잡한 추론이 필요한 작업에서는 중간 단계가 생략되면 답이 틀릴 수 있다. o1 모델이 사고 과정을 길게 보여주는 게 심미적 이유가 아니라 추론 품질 때문인 것처럼, Claude도 생각할 공간을 주면 더 잘한다. 토큰 절감과 품질 사이의 균형점을 찾는 게 관건이다.
또한 이 템플릿 자체가 토큰을 먹는다. 시스템 프롬프트에 500토큰짜리 "압축 지침"을 넣으면, 그게 입력 비용으로 들어간다. 매 호출마다 500토큰을 추가로 읽히는 셈이다. 그래도 출력이 2000토큰 줄어들면 본전 이상이다. 입력 500토큰 비용은 출력 100토큰 비용과 비슷하니까. 하지만 짧은 대화에서는 오히려 손해일 수 있다. 상황에 따라 템플릿을 끄고 켜는 로직이 필요하다.
📊 비용 시뮬레이션
실제 숫자로 보기
간단한 계산을 해보자. 하루에 1000번 API 호출하는 서비스가 있다. 평균 출력이 1500토큰이라고 가정하면, 일일 출력 토큰은 150만 개. Claude 3.5 Sonnet 기준으로 하루 출력 비용만 22.5달러다. 월이면 675달러. 이걸 40%만 줄여도 월 405달러로 내려간다. 270달러 절약이다. 1년이면 3240달러. 꽤 큰 돈이다.
이 저장소의 템플릿을 적용하는 건 코드 몇 줄 추가하는 거다. 시스템 프롬프트에 텍스트 복붙하면 끝. 10분 작업으로 연 300만 원 이상 절약하는 셈이다. 게임 개발에서 이 정도 최적화 효과를 내려면 프로파일링 도구 깔고 한참 분석해야 한다. LLM 비용 최적화는 게임 최적화보다 ROI가 훨씬 좋을 수 있다.
규모 확장 시
사용자가 만 명이면 얘기가 달라진다. 하루 1000만 토큰 출력이면 일일 150달러, 월 4500달러다. 40% 절감하면 월 1800달러 아낀다. 이 정도 규모면 CDN 비용이나 DB 비용 최적화하던 것과 비슷한 금액이다. 인프라 비용 최적화의 한 축으로 LLM 토큰 관리를 넣어야 하는 시대가 온 것이다.
🔮 향후 전망
Anthropic의 대응
Anthropic도 이 문제를 인식하고 있을 것이다. 경쟁사들이 "reasoning tokens" 분리 과금 같은 방식으로 대응하는 마당에, Anthropic이 가만있을 리 없다. 아마도 공식적인 "concise mode"나 "output budget" 같은 기능이 추가될 가능성이 크다. 사용자가 "최대 500토큰만 출력해"라고 지정하면 모델이 알아서 조절하는 기능이다.
그 전까지는 이런 커뮤니티 솔루션에 의존해야 한다. 역설적이지만, 이런 저장소가 인기를 끄는 건 Anthropic에게도 시그널이다. 사용자가 토큰 비용에 민감하다는 증거니까. API 제공사 입장에서는 사용자가 비용 부담을 느껴서 사용을 줄이는 것보다, 효율적으로 쓰면서 계속 사용하는 게 낫다. 그래서 공식 지원이 추가될 가능성이 높다.
개발자가 해야 할 일
지금 당장은 이 저장소의 템플릿을 프로젝트에 통합해보는 걸 추천한다. 특히 Claude를 백엔드로 쓰는 서비스라면 필수다. 시스템 프롬프트 최적화는 한 번 해두면 계속 효과가 있다. "set and forget"이다. 그리고 토큰 사용량을 모니터링하는 대시보드를 만들어야 한다. 입력/출력 토큰을 따로 추적해서 최적화 전후를 비교할 수 있어야 한다.
장기적으로는 "토큰 예산" 개념을 코드에 녹여야 한다. 함수 하나당 최대 토큰을 지정하고, 초과하면 자동으로 프롬프트를 조정하는 식이다. 게임 엔진에서 메모리 예산을 기능별로 할당하는 것과 같다. AI 기능에도 예산 개념이 들어오는 시대다. 이 저장소는 그 첫걸음을 보여준다.
Claude는 친절하려다 비용을 폭발시킨다. 프롬프트로 다스려야 한다.