2026년 9월 기준 · Anthropic 공식 문서, Claude 헬프센터, 각 서비스 공식 요금 페이지 확인분
PART 0. 관점의 전환
절약의 목표는 돈이 아니라 시간이다
토큰 절약 글의 대부분은 개발자를 향해 쓰여 있다. 백만 토큰당 몇 달러, 캐시 히트율, 배치 API. 그런데 이 글을 읽는 사람의 다수는 월 정액을 내고 채팅창을 쓰는 작가와 마케터다. 그들에게 "토큰당 $2"는 의미가 없다. 청구서는 어차피 고정이니까.
그렇다면 이들에게 절약이란 무엇인가.
한도다. 정액제 사용자가 실제로 지불하는 통화는 돈이 아니라 사용 한도다. 오후 3시에 "사용 한도에 도달했습니다"를 만나 마감 직전 두 시간을 날리는 것 — 그게 진짜 비용이다.
토큰 절약 = 비용 절감이 아니라 토큰 절약 = 작업 가능 시간 확보
이 문장이 이 문서 전체의 축이다. 그리고 이 축이 바뀌면 우선순위가 통째로 달라진다. 프롬프트 문구를 다듬는 일은 뒤로 밀리고, 자료를 어디에 두느냐가 앞으로 온다.
이 문서의 우선순위
효과가 큰 순서다. 대부분의 절약 가이드가 이 순서를 거꾸로 소개한다.
| 순위 | 수단 | 대상 |
|---|---|---|
| 1 | 프로젝트 캐싱 — 반복 참조 자료를 올려둔다 | 전원 |
| 2 | 부분 출력 — "전문 다시" 를 없앤다 | 전원 |
| 3 | 배치 요청 — 여러 요청을 한 메시지에 | 전원 |
| 4 | 세션 설계 — 대화를 작업 단위로 끊는다 | 전원 |
| 5 | 모델·effort 티어링 | 전원 |
| 6 | 도구 정리 — 안 쓰는 커넥터를 끈다 | 전원 |
| 7 | 외부 도구 (NotebookLM 등) | 자료가 많은 사람 |
| 8 | API 전환 (캐싱·배치·라우팅) | 대량 반복 업무 |
| 9 | 프롬프트 문구 다듬기 | 효과 작음 |
| 10 | 다단계 번역·압축 파이프라인 | 대부분 불필요 |
PART 1. 비용 구조: 당신은 어느 트랙에 있는가
두 개의 완전히 다른 과금 체계가 있고, 절약 전략도 다르다.
트랙 A — 정액제 채팅 (작가·마케터 대다수)
두 개의 시계
- 5시간 롤링 세션: 첫 메시지를 보낸 순간부터 5시간. 자정 리셋이 아니다. 09:47에 시작하면 14:47까지가 한 창이다.
- 주간 한도: 계정마다 지정된 시각에 리셋. Opus 전용 주간 한도와 나머지 모델 주간 한도가 따로 표시된다.
중요한 사실 하나. claude.ai 웹, 데스크톱 앱, Claude Code가 전부 같은 풀을 쓴다. 아침에 다른 도구에서 뭔가를 돌렸다면 오후에 원고를 다듬을 여력이 그만큼 줄어 있다.
Anthropic은 플랜별 토큰 수를 공개하지 않는다. 공개하는 건 상대 배수뿐이다. Pro는 무료 대비 세션당 최소 5배, Max 5x는 Pro의 5배, Max 20x는 20배. 참고 수치로 "Pro 평균 사용자 기준 5시간당 약 45개 메시지"라는 안내가 있으나 어디까지나 평균이다.
왜 고정 숫자가 없는가
메시지 하나가 소모하는 양이 상황마다 다르기 때문이다. 공식 문서가 명시한 소모 요인은 일곱 가지다.
| 소모 요인 | 실무적 의미 |
|---|---|
| 메시지 길이 | 원고 통째 붙여넣기 |
| 첨부 파일 크기 | PDF 200페이지 = 짧은 질문 수십 개 값 |
| 현재 대화 길이 | 가장 과소평가되는 항목 |
| 도구 사용 (리서치, 웹 검색) | 켜져 있기만 해도 토큰을 먹는다 |
| 모델 선택 | Opus는 Haiku보다 훨씬 빨리 태운다 |
| Effort 레벨 | 높을수록 소모 증가 |
| 아티팩트 생성·사용 | 긴 문서를 계속 재생성하면 비싸다 |
세 번째 항목이 낭비의 대부분을 만든다
LLM은 기억이 없다. 대화 40번째 턴에서 "그 문단 다시 손봐줘"라고 쓸 때 실제로 전송되는 것은 그 아홉 글자가 아니라 1턴부터 39턴까지의 전체 기록 + 올린 원고 + 그 아홉 글자다. 매 턴마다.
그래서 대화가 길어질수록 메시지 하나의 단가가 계속 오른다. 선형이 아니라 누적이다.
함정이 하나 더 있다. 대화가 컨텍스트 한계에 가까워지면 자동 컨텍스트 관리가 앞부분을 요약하며 대화를 이어준다(코드 실행이 켜져 있어야 한다). 편리하지만 공식 문서는 이렇게 못 박는다. 자동 컨텍스트 관리가 발동한 긴 대화는 사용 한도를 더 많이 소모한다.
대화를 무한정 이어가는 것은 편한 게 아니라 비싼 것이다.
좋은 소식: 채팅에도 캐싱이 있다
개발자 전용 기능이 아니다. 공식 문서의 표현 그대로:
- 프로젝트에 올린 콘텐츠는 캐시되며, 재사용될 때 한도에 계산되지 않는다.
- 자주 쓰는 유사한 프롬프트는 부분적으로 캐시된다.
이 두 문장이 이 문서의 전략적 토대다.
매번 붙여넣지 말고, 한 번 올려두고 계속 참조하라. 같은 파일, 같은 내용, 다른 청구서다.
트랙 B — API (대량 반복 업무)
2026년 9월 기준 Claude API 요금이다.
| 모델 | 입력 | 5분 캐시 쓰기 | 1시간 캐시 쓰기 | 캐시 읽기 | 출력 |
|---|---|---|---|---|---|
| Claude Opus 5 | $5 / MTok | $6.25 | $10 | $0.50 | $25 / MTok |
| Claude Sonnet 5 | $2 / MTok | $2.50 | $4 | $0.20 | $10 / MTok |
| Claude Haiku 4.5 | $1 / MTok | $1.25 | $2 | $0.10 | $5 / MTok |
| Claude Fable 5.1 | $10 / MTok | $12.50 | $20 | $0.25 | $50 / MTok |
두 개의 비대칭이 모든 전략을 결정한다.
- 출력은 입력의 5배
- 캐시 읽기는 입력의 10분의 1
입력 압축의 상한을 직접 계산하는 법
여기서 널리 잘못 인용되는 수치를 바로잡는다. "입력은 전체 비용의 28.6%"라는 말이 상수처럼 돌아다니는데, 그건 특정 예시의 값이다. 자기 작업에 맞춰 직접 계산해야 한다.
출력 단가가 입력의 5배인 Claude 계열에서:
입력 비중 = 입력토큰 ÷ (입력토큰 + 5 × 출력토큰)
| 작업 유형 | 입력 / 출력 | 입력 비중 | 입력을 절반 압축 시 총액 절감 |
|---|---|---|---|
| 짧은 질의응답 | 500 / 1,000 | 9.1% | 4.6% |
| 일반 요청 | 2,000 / 1,000 | 28.6% | 14.3% |
| 문서 요약 | 20,000 / 500 | 88.9% | 44.4% |
| 대량 분류 | 2,000 / 50 | 88.9% | 44.4% |
작업 유형에 따라 압축의 가치가 열 배 차이 난다. 문서 요약과 대량 분류에서는 입력 압축이 실제로 크게 먹히고, 창작·대화형 작업에서는 거의 무의미하다. 이 표가 PART 8의 판단 기준이 된다.
그리고 캐싱을 켜면 입력 단가가 10분의 1이 되므로, 위 비중이 전부 급락한다. 캐싱과 입력 압축은 같은 파이를 놓고 다투는데, 캐싱이 압도적으로 이긴다.
PART 2. 작가와 인문 필자를 위한 절약
2-1. 가장 큰 낭비: "전문을 다시 써줘"
퇴고 중인 작가가 하는 가장 비싼 행동이다.
원고 10,000토큰을 20회 퇴고한다고 하자.
| 방식 | 누적 출력량 |
|---|---|
| 매번 전문 재출력 | 10,000 × 20 = 200,000 토큰 |
| 바뀐 부분만 (평균 800토큰) | 800 × 20 = 16,000 토큰 |
출력의 92%가 사라진다. 게다가 전문을 20번 뱉은 대화는 그 20개가 전부 기록에 쌓여 이후 모든 턴의 입력을 부풀린다. 실제 격차는 표보다 훨씬 크다.
입력과 출력을 혼동하지 말 것
여기서 한 가지 구분이 중요하다. Claude 공식 문서는 글쓰기 작업에 대해 편집할 텍스트는 나눠 보내지 말고 한 메시지에 전체를 보내라고 안내한다. 위 조언과 모순처럼 보이지만 아니다.
입력은 통째로, 출력은 부분만.
원고를 세 번에 나눠 붙여넣으면 세 번 값을 내고 맥락도 끊긴다. 한 번에 넣는 게 맞다. 하지만 받을 때는 바뀐 부분만 받는다. 둘은 다른 축이다.
처방: "차이만 달라"고 말하는 법
"3번 문단만 고쳐서 그 문단만 출력해줘. 나머지는 손대지 마.""수정 제안을 before/after 표로만 줘. 전문은 출력하지 마.""고칠 지점 5곳을 위치와 이유만 짚어줘. 문장은 내가 쓸게.""이번엔 진단만. 수정은 다음 메시지에서 요청할게."
마지막이 특히 좋다. 진단과 집행을 분리하면 방향이 틀렸을 때 긴 출력을 낭비하지 않는다.
인문 필자를 위한 부기
전문 재생성을 반복하지 않는 습관은 비용 문제이기 전에 작법 문제다. 반복하면 원고의 주인이 서서히 바뀐다. 어느 순간 자기 문장이 아닌 것이 원고에 남아 있는데 어디서부터 그렇게 됐는지 추적할 수 없다. 문단 단위로 받고 문장 단위로 자기가 고쳐 넣는 방식은 절약인 동시에 저자성의 방어선이다.
2-2. 원고는 채팅창이 아니라 프로젝트에 둔다
프로젝트에 올린 파일은 캐시되고, 재사용 시 한도를 소모하지 않는다. 공식 문서가 든 예시가 정확히 이 상황이다. 참고 자료를 전부 프로젝트에 넣어두면, 여러 번 질문해도 매번 업로드하는 것보다 훨씬 적은 메시지를 쓴다.
작가용 프로젝트 구성
프로젝트: 『장편소설 A』
| 프로젝트 지식(파일) | 프로젝트 지침(짧게) |
|---|---|
| 원고 현재본 | 이 프로젝트는 장편소설 A의 집필이다 |
| 설정 바이블 (인물·연표·지명·용어) | 나는 저자, 너는 편집자 역할이다 |
| 문체 규칙 메모 | 문체 규칙 파일을 항상 따른다 |
| 기획서 / 시놉시스 | 요청하지 않은 전문 재출력은 하지 않는다 |
| 참고 자료 (인용 원전, 답사 메모) | 수정 제안은 해당 부분만 출력한다 |
| 기출간 원고 2~3편 (문체 기준선) |
공식 권고 두 가지를 얹는다.
- 프로젝트 지침은 짧게. 지침에는 일반 맥락·가이드라인·역할만. 작업별 지시는 채팅에서. 지침이 길면 모든 대화가 그 길이를 부담한다.
- 안 쓰는 파일은 지워라. 3고까지 온 프로젝트에 초고·1고·2고가 남아 있으면 검색 정확도가 떨어지고 답변 품질이 나빠진다.
프로젝트는 RAG(검색 증강 생성) 모드를 지원한다. 관련 부분만 골라 컨텍스트에 올리므로 자료가 많아도 창을 다 태우지 않는다. 자료가 수십 건인 논픽션 작업에는 사실상 필수다.
2-3. 문체를 매번 설명하지 마라
작가들이 매 대화 서두에 반복하는 문단이 있다. "건조하게, 형용사 남발 금지, 문장은 짧게, 감상적 마무리 금지…" 이걸 마흔 번 입력하면 마흔 번 값을 낸다. 게다가 매번 조금씩 다르게 쓰기 때문에 부분 캐싱 혜택도 못 받는다.
처방 두 가지.
- 스타일 기능으로 고정한다.
- 프로젝트 지침 또는 문체 규칙 파일에 넣는다.
부수 효과가 더 크다. 말로 설명한 문체는 매번 조금씩 달라진다. 파일로 고정하면 원고 전체에 일관된 기준이 적용된다.
문체 규칙은 판정 가능하게
| 나쁜 규칙 | 좋은 규칙 |
|---|---|
| 문학적으로 | 비유는 문단당 1개 이하. 관용구 금지 |
| 간결하게 | 한 문장 25어절 초과 금지 |
| 감상적이지 않게 | 문단 마지막 문장에 요약·교훈을 붙이지 않는다 |
| 내 스타일대로 | (첨부한 기출간 원고 3편의 문장 리듬을 기준으로) |
마지막이 강력하다. 자기 기출간 텍스트를 프로젝트에 넣는 것이 문체 지시문 열 줄보다 정확하다.
2-4. 장편 집필의 세션 설계
권장 리듬: 챕터 = 대화 1개
[프로젝트: 장편소설 A]
├── 대화 #1 — 3장 집필 → 끝날 때 "3장 상태 요약 300자" 요청
├── 대화 #2 — 4장 집필 → 첫 메시지에 3장 요약 붙여 시작
├── 대화 #3 — 3~4장 연결 검토
└── 대화 #4 — 5장 집필
챕터를 끝낼 때마다:
"이 대화에서 확정된 것만 300자로 정리해줘. 인물 상태 변화, 새로 생긴 복선, 다음 장으로 넘길 미해결 항목. 수사 없이 메모 형식으로."
40턴을 끌고 가는 대신 300자를 넘긴다. 소모량이 두 자릿수 배로 차이 난다.
확정된 설정은 요약이 아니라 설정 바이블 파일에 반영해 다시 올린다. 그러면 그 다음부터 캐싱 대상이다.
유료 플랜에서는 이전 대화를 검색해 참조하도록 요청할 수도 있다. 다만 검색도 도구 호출이므로 핵심은 파일로 고정하고 검색은 보조로 쓰는 편이 낫다.
2-5. 퇴고는 분업이다 — 교열에 최상위 모델을 쓰지 마라
| 단계 | 작업 | 모델 | 빈도 |
|---|---|---|---|
| 구조 진단 | 플롯 구멍, 논지 비약, 챕터 배열, 인물 동기 | 최상위 (Opus급) | 원고당 2~3회 |
| 문단 수술 | 문단 재구성, 리듬, 전환, 시점 일관성 | 중간 (Sonnet급) | 수시 |
| 교열·표기 | 오탈자, 띄어쓰기, 인용 형식, 수치 대조 | 하위 (Haiku급) | 대량 |
구조 진단은 정말로 최상위 모델이 값을 하는 작업이다. 원고 전체를 붙들고 "3장의 갈등이 5장에서 회수되지 않는다"를 짚는 건 다르다. 반면 교열은 하위 모델이 사실상 동등하다.
주간 한도에서 Opus 사용량이 별도 집계된다는 점을 기억하자. Opus 한도는 구조 진단에 남겨둔다.
2-6. 리서치와 인용: 원문을 채팅창에 붓지 마라
규모 감각을 위한 참고치다. 평균 웹페이지(10kB)가 약 2,500토큰, 문서 페이지(100kB)가 약 25,000토큰, 논문 PDF(500kB)가 약 125,000토큰이다. 논문 두 편이면 짧은 질문 수백 개 값이다.
자료 처리 4가지 경로
| 경로 | 적합 | 주의 |
|---|---|---|
| 프로젝트 지식 + RAG | 자료 수십 건, 질문이 특정적 | 검색 품질이 답변 품질의 상한 |
| NotebookLM 등 외부 선요약 | 개인 작업, PDF·영상 자막 위주 | 요약 손실, 인용 검증 필요 (PART 7) |
| 직접 요약 후 투입 | 자료가 소수, 핵심이 명확 | 자기 시간 소모 |
| 통째 업로드 + 프로젝트 캐싱 | 자료가 고정적, 반복 참조 | 큰 컨텍스트 창이 전제 |
마지막 경로가 재평가되고 있다. 유료 플랜의 최신 모델은 최대 100만 토큰 컨텍스트를 지원한다(모델에 따라 50만 또는 20만). 자료가 그 안에 들어오고 반복 참조한다면, 복잡한 요약 파이프라인을 짜는 것보다 통째로 넣고 프로젝트에 캐시해두는 게 싸고 정확하다.
도구를 꺼라
공식 권고 중 가장 실용적인 항목. 웹 검색, 리서치, MCP 커넥터는 토큰 집약적이다. 필요 없는 대화에서는 "검색 및 도구" 설정에서 끄는 것만으로 컨텍스트와 한도가 모두 여유로워진다.
- 리서치 대화 → 도구 켬
- 집필 대화 → 도구 끔
확장 사고와 effort
같은 이유로 확장 사고를 끄고 effort를 낮추는 것도 공식 권고다. 사고 과정은 출력 토큰으로 계산되므로 가장 비싼 단가로 청구된다. 교열에 깊은 사고를 열어두는 건 순수한 낭비다.
2-7. 번역과 다국어 발행
비효율: 원고를 붙여넣고 영어 요청 → 새 대화에서 다시 붙여넣고 일본어 → 또 새 대화에서 중국어. 원문 값을 세 번 낸다.
효율: 원문은 프로젝트에 한 번. 그리고 한 메시지에 배치한다.
"프로젝트의 원고를 영어·일본어·중국어(간체)로 번역해줘. 세 개를 한 응답에 담고 구분선으로 나눠줘. 번역 노트는 붙이지 마."
원문 값을 한 번만 내고 메시지 수도 3분의 1이다. 단, 문학 텍스트에는 유보가 필요하다. PART 6에서 따로 다룬다.
PART 3. 마케터를 위한 절약
3-1. 카피 30종은 서른 번 묻는 게 아니라 한 번 묻는다
전형적 낭비 패턴이 있다. 브리프를 붙여넣고 "하나 써줘" → "다른 버전" → "좀 더 캐주얼하게" → … 30번.
문제가 두 겹이다. 첫째, 메시지 30개가 5시간 한도에서 30개로 계산된다. 둘째, 30번째 메시지를 보낼 때 1~29번의 모든 기록이 함께 간다.
브리프 1,500토큰, 카피 한 편 80토큰 기준.
| 방식 | 입력 누적 | 메시지 수 |
|---|---|---|
| 하나씩 30턴 | 브리프 재전송 + 대화 누적으로 45,000토큰 이상 | 30 |
| 한 메시지에 30종 | 1,500토큰 | 1 |
입력 97% 감소, 메시지 30분의 1. 최적화가 아니라 다른 게임이다.
배치 요청의 올바른 형태
"30개 뽑아줘"라고만 하면 비슷한 게 30개 나온다. 축을 지정해야 한다.
"아래 브리프로 인스타 캡션을 만들어줘.축1 — 훅 유형: 질문형 / 통계형 / 공감형 / 반전형 / 선언형 (5종)축2 — 길이: 20자 내외 / 60자 내외 (2종)5×2=10개를 표로. 열은 [번호, 훅유형, 길이, 카피, 타깃가정].마지막에 CTR 관점 상위 3개를 골라 이유 한 줄씩.서론과 설명은 붙이지 마."
표로 받으면 출력이 압축되고 비교도 쉽다. 설명은 붙이지 마 한 줄이 매번 서너 문단을 없앤다. 평가까지 같은 메시지에 붙이면 한 턴을 더 아낀다.
3-2. 브랜드 가이드는 프롬프트가 아니라 자산이다
톤앤매너, 금지어, 브랜드 페르소나, 제품 사양, 법무 승인 문구 — 이걸 캠페인마다 다시 치는 건 회사 자산을 소모품처럼 쓰는 것이다.
프로젝트: 『[브랜드명] 커뮤니케이션』
| 파일 | 내용 |
|---|---|
브랜드_보이스.md |
톤앤매너, 어휘 원칙, 금지 표현, 예시 문장 20개 |
제품_팩트시트.md |
사양, 가격, 차별점, 절대 틀리면 안 되는 수치 |
타깃_페르소나.md |
세그먼트 3종의 언어 습관과 구매 동기 |
법무_가이드.md |
표시광고법 금지 표현, 필수 고지 문구 |
기출고_우수사례.md |
성과 좋았던 카피 (문체 기준선) |
경쟁사_포지셔닝.md |
쓰면 안 되는 클레임, 차별화 축 |
프로젝트 지침은 이 정도만.
"모든 카피는 브랜드_보이스 규칙을 따른다. 제품 수치는 팩트시트에서만 인용하고, 없는 수치는 만들지 않는다. 법무_가이드의 금지 표현은 절대 쓰지 않는다. 요청하지 않은 설명은 붙이지 않는다."
이득이 세 겹이다. 캐싱(재사용 시 한도 미소모), 일관성(담당자가 바뀌어도 같은 기준), 리스크 관리(금지 표현·수치 오류를 구조적으로 차단).
세 번째가 실무에서 제일 크다. 카피 하나 잘못 나가 정정 공지를 띄우는 비용은 연간 구독료를 압도한다.
팁:"프롬프트에 매번 쓰면 되지 않나"라고 생각하기 쉬운데, 매번 쓴다는 건매번 빠뜨릴 수 있다는 뜻이다. 마감에 쫓겨 급하게 친 프롬프트에서 법무 문구가 누락되는 사고가 실제로 그렇게 난다. 파일은 잊지 않는다.
3-3. 반복 업무는 템플릿으로 고정한다
주간 리포트, SNS 캘린더, 뉴스레터 — 마케터 업무의 상당 부분은 형식이 같고 내용만 바뀐다. 그리고 자주 쓰는 유사 프롬프트는 부분 캐싱된다.
[고정 블록 — 절대 안 바뀜]
너는 [브랜드]의 퍼포먼스 마케터다.
출력 형식: 표. 열은 [채널, 지표, 전주대비, 해석, 액션].
해석은 한 줄. 액션은 실행 동사로 시작.
서론과 요약 문단은 쓰지 않는다.
[변수 블록 — 매주 바뀜]
기간: {{이번 주}}
데이터: {{첨부}}
특이사항: {{프로모션 유무}}
고정 블록을 위에, 변수 블록을 아래에. 캐싱은 앞에서부터 일치하는 구간에 작동하므로, 맨 앞에 날짜 같은 변수를 넣으면 캐시가 매번 깨진다.
3-4. 데이터는 붙여넣지 말고 올려라
CSV를 텍스트로 붙여넣으면 헤더·구분자·반복 값·빈 셀까지 전부 토큰이다. 행 5,000개짜리 광고 리포트를 붙여넣는 순간 그 한 메시지가 세션 한도의 상당 부분을 가져간다.
대안 순서:
- 필요한 열만 남겨 파일로 업로드. 열이 40개인데 실제로 보는 건 6개다.
- 집계 요약본을 올린다. 5,000행을 캠페인별 30행으로 피벗. 스프레드시트에서 3분이면 된다.
- 반복 참조 데이터는 프로젝트에. 분기 벤치마크, 작년 동기 실적.
- 원본이 꼭 필요할 때만 원본. 이상치 탐색이라면 요약본으로는 안 된다. 그때는 쓰되 그 대화에서만.
3-5. 고객 인터뷰와 정성 데이터
[프로젝트: 2026 사용자 리서치]
├── 녹취_01.txt ~ 녹취_15.txt (프로젝트 지식, RAG 모드)
├── 리서치_질문.md
└── 코딩_스킴.md
대화 #1 — "녹취 1~5에서 [구매 저항] 관련 발언만 추출, 표로"
대화 #2 — "녹취 6~10에서 동일하게"
대화 #3 — "위 코딩 결과로 저항 유형 3~4개 도출"
녹취 전체를 한 대화에 부어놓고 "페르소나 만들어줘"라고 하는 것보다 싸고 정확하다. 한 번에 다 넣으면 모델이 중간 부분을 흘린다.
3-6. 아티팩트를 반복 재생성하지 마라
공식 소모 요인 목록에 아티팩트 생성 및 사용이 있다. 랜딩페이지 카피나 긴 기획서를 아티팩트로 만들고 스무 번 "다시 뽑아줘"를 하면 매번 전체를 다시 출력하는 것이다. 2-1의 문제와 같다. 3번 섹션 헤드라인만 바꿔줘가 정답이다.
PART 4. 일반 사용자를 위한 기본기
작가도 마케터도 아닌, 그냥 매일 쓰는 사람을 위한 최소 규칙이다. 이것만 해도 30~50%가 달라진다.
| 규칙 | 이유 |
|---|---|
| 주제가 바뀌면 새 대화 | 이전 기록 전체가 매 턴 재전송된다 |
| 작업 단위로 세션 분리 | 한 채팅에서 세 가지 일을 하면 세 번째 일에 앞의 둘 값을 낸다 |
| 응답 길이를 직접 지정 | "300단어 이내", "표만", "결론 3줄" — 출력이 비싼 쪽이다 |
| 여러 질문은 한 메시지에 | 맥락 값을 한 번만 낸다 |
| 같은 파일 재업로드 자제 | 반복 참조할 거면 프로젝트로 |
| 정중어 걷어내기 | "혹시 가능하시다면 ~해주실 수 있을까요"는 성능 이득 없이 토큰만 먹는다 |
| 단순 작업엔 하위 모델 | 번역·요약·포맷 변환에 최상위 모델은 낭비 |
| 안 쓰는 도구는 끄기 | 켜져 있으면 정의 자체가 매 요청에 포함된다 |
PART 5. 공통 운영 규칙
5-1. 계기판을 켜고 일한다
설정 > 사용량에서 확인할 것 세 가지.
- 현재 세션: 5시간 한도 중 사용량, 남은 시간
- 주간 한도 (Opus): 리셋 시점
- 주간 한도 (그 외 모델): 별도 표시
한도는 오후 3시에 확인하는 게 아니라 오전 9시에 배분하는 것이다.
5-2. 3단 스위치를 습관화한다
| 스위치 | 무거운 작업 | 가벼운 작업 |
|---|---|---|
| 모델 | 최상위 | 하위 |
| Effort | 높음 | 낮음 |
| 확장 사고 | 켬 | 끔 |
- 무거운 작업: 원고 구조 진단, 캠페인 전략 설계, 데이터 해석, 논지 검증
- 가벼운 작업: 교열, 포맷 변환, 번역, 요약, 카피 변주, 표 정리
대부분의 사람은 하루 종일 최상위 모델에 최고 effort로 오탈자를 잡는다. 이 하나만 고쳐도 체감이 크게 달라진다.
5-3. 5시간 창을 설계한다
롤링 창이라는 점을 이용한다. 핵심은 무거운 작업을 흩뿌리지 않는 것.
| 시간 | 작업 | 창 |
|---|---|---|
| 09:00 | 창 1 시작 — 구조 진단 (Opus, 무거운 작업 몰아서) | 09:00~14:00 |
| 12:00 | 창 1 안에서 문단 수술 (Sonnet) | |
| 14:00 | 창 2 시작 — 교열·표기 (하위 모델) | 14:00~19:00 |
5-4. 한도가 부족할 때
- 이 문서의 PART 1~3을 먼저 적용한다. 대부분 여기서 해결된다.
- 사용량 크레딧 / 사용량 번들 구매. 플랜을 바꾸지 않고 한도만 보충한다. 성수기에만 필요하면 합리적이다.
- 상위 플랜. Pro → Max 5x → Max 20x.
- API 전환. PART 10 참조.
판단 기준: 일주일간 한도에 몇 번 걸리는지 세어보라. 한 번도 안 걸리면 업그레이드는 낭비다. 매일 걸리면 상위 플랜이 값을 한다. 하루에 여러 번이면 워크플로 자체를 다시 봐야 한다.
PART 6. 언어와 문체의 경제학 — 인문학적 관점
이 장은 절약 기법이 아니라 절약해서는 안 되는 것에 관한 이야기다.
6-1. "영어가 토큰 효율이 좋다"는 말의 정확한 지위
방향은 맞다. 주요 토크나이저는 영어 중심으로 설계됐고, 같은 의미의 한국어 문장이 더 많은 토큰을 소모하는 경향이 있다.
그러나 이 명제를 남의 블로그에 적힌 비율로 받아들이면 안 된다. 토크나이저는 모델 세대마다 바뀐다. 실제로 Claude 4.7 이후 모델은 새 토크나이저를 쓰는데, 같은 텍스트에 대해 약 30% 더 많은 토큰을 생성한다. 성능 향상의 대가다.
즉 "한국어는 영어의 몇 배"라는 상수는 존재하지 않는다. 모델이 바뀌면 비율도 바뀐다. 절감률을 인용하지 말고 자기 모델에 자기 문서를 넣어 직접 재보라.
6-2. 번역 경유가 문학 텍스트에서 치르는 대가
분류나 태깅에서는 번역 경유가 타당하다. 문학과 인문 텍스트에서는 아니다. 그리고 그 이유는 감상적인 것이 아니라 구조적이다.
| 소실 항목 | 예 |
|---|---|
| 어미의 정치학 | -다 / -습니다 / -지요 / -네 의 거리 조절에 영어 대응물이 없다 |
| 호칭 체계 | 선생, 형, 씨, 님, 군의 관계 정보가 you로 압축된다 |
| 문장 리듬 | 3·4조, 반복, 도치의 물리적 길이 감각 |
| 한자어와 고유어의 층위 | '고독'과 '외로움'의 온도차 |
| 생략의 문법 | 주어를 지우는 한국어의 능력. 영어는 채워 넣는다 |
| 말맛과 방언 | 지역어, 세대어, 계층어의 흔적 |
왕복 번역을 거치면 이것들이 한 번 사라진 뒤 다시 만들어지지 않는다. 복원된 한국어는 문법적으로 옳고 의미적으로 맞지만 원래 문장이 아니다. 그것을 우리는 이미 "번역투"라는 이름으로 알고 있다.
인문 필자에게 이 손실은 절감액으로 상쇄되지 않는다.
6-3. "원시인 영어"의 한계 — 네 가지 이유
문법 요소를 제거하고 명령어만 남기는 압축 기법이 널리 소개돼 있다. 네 겹의 문제가 있다.
① 기제가 잘못 알려져 있다. 프롬프트 문법을 깎으면 줄어드는 건 입력 토큰이지 출력 토큰이 아니다. 출력 길이는 문법이 아니라 무엇을 요청했는지가 결정한다. "ANALYZE market. TOP players. FORECAST 5yr."는 정중한 원문과 똑같이 긴 분석을 요구하고 있고 따라서 출력도 똑같이 길다. "출력 토큰 68~75% 절감"류의 수치는 입력과 출력을 혼동한 결과다.
간접 효과는 있다. 짧고 딱딱한 프롬프트에 모델이 건조하게 답하는 미러링 경향이 있다. 하지만 부수 효과지 통제 수단이 아니다. 출력을 줄이려면 출력을 직접 제약해야 한다.
② 절감 상한이 작업 유형에 달려 있다. PART 1의 공식으로 돌아가자.
입력 비중 = 입력토큰 ÷ (입력토큰 + 5 × 출력토큰)
대화형·창작 작업(입력 2,000 / 출력 1,000)에서는 입력이 28.6%다. 입력을 0으로 만들어도 그게 상한이고, 절반 압축하면 총액의 14.3%다. 반면 출력을 30% 줄이면 21.4%다. 압축보다 출력 제약이 언제나 효율적이다.
단, 대량 분류(입력 2,000 / 출력 50)에서는 입력이 88.9%다. 여기서는 압축이 실제로 크게 먹힌다. 그래서 이 기법은 틀린 게 아니라 적용 범위가 좁은 것이다.
③ 재질문 손익분기가 아슬아슬하다.
순절감 = (입력 비중 × 압축률) − (재질문 발생률 × 1.0)
대화형 작업에서 절감이 14.3%라면 재질문이 15%만 발생해도 순손실이다. 번역 두 번, 압축 한 번이 끼는 다단계 파이프라인에서 이 확률은 낮지 않다.
④ 작가에게는 자기모순이다. 뉘앙스를 다루는 일을 하면서 뉘앙스를 지운 언어로 지시하는 것은, 도구를 아끼려고 도구가 하는 일을 포기하는 것이다. "슬프게 말고, 슬픔을 참는 사람처럼"이라는 지시는 압축하면 남는 게 없다. 그런데 그 지시야말로 작가가 LLM에 요구하는 유일하게 어려운 일이다.
6-4. 압축해도 되는 것과 안 되는 것
| 압축해도 되는 것 | 압축하면 안 되는 것 |
|---|---|
| 형식 지시 ("표로", "3개", "제목만") | 문체·정서·톤에 관한 지시 |
| 분류·태깅·추출 작업 | 문학 텍스트 자체 |
| 데이터 요약 요청 | 인용의 원문 |
| 반복 업무 템플릿 | 브랜드 보이스 정의 |
| 정중어와 완충 표현 | 미묘한 판단이 필요한 맥락 설명 |
마지막 행이 실용적이다. 정중어는 마음껏 잘라도 된다. 반면 "이 인물은 화가 났지만 그걸 인정하고 싶어 하지 않는 상태다" 같은 문장은 길어도 남겨야 한다. 그게 정보다.
6-5. 절약과 사유의 관계
한 가지 덧붙일 것이 있다.
대화를 짧게 자르고, 배치로 몰아 묻고, 되묻지 않도록 프롬프트를 완벽히 설계하는 습관은 대부분 좋다. 그런데 넘어가는 지점이 있다. 탐색적 대화를 못 하게 되는 지점이다.
작가와 연구자가 LLM에서 얻는 가치의 상당 부분은 효율적인 질의응답이 아니라 비효율적인 배회에서 나온다. "이게 왜 안 되는지 모르겠는데"로 시작해 여섯 번 왕복한 끝에 문제가 딴 데 있었음을 깨닫는 종류의 대화. 이건 배치로 처리할 수 없고, 처리하려 들면 답이 나오지 않는다.
그러니 이 문서의 기법들은 반복 업무를 압축해 탐색에 쓸 여유를 만들기 위한 것으로 이해하는 게 맞다. 교열과 포맷 변환에서 아낀 한도를 배회에 쓰는 것. 그게 목적이지, 배회 자체를 없애는 게 목적이 아니다.
PART 7. 외부 도구 활용 — 현재 수치로 다시 보기
여러 가이드가 NotebookLM·DeepSeek·OpenRouter를 절약 수단으로 소개한다. 유용하지만 수치가 계속 바뀌고 있고, 대부분의 소개글이 오래된 수치를 인용한다. 2026년 9월 기준으로 다시 정리한다.
7-1. NotebookLM
핵심 원리:무거운 원자료는 추론 모델에 넣지 말고 밖에 두고, 비싼 모델은 추론과 편집만 시킨다. 이건컨텍스트 오프로딩이라는 일반 패턴이고 원리는 타당하다.
그런데 무료 티어에 한도가 있다. 이걸 밝히지 않는 소개글이 많다.
| 항목 | NotebookLM Standard(무료) |
|---|---|
| 노트북 수 | 100개 |
| 노트북당 소스 | 50개 |
| 일일 채팅 쿼리 | 50회 (전체 계정 합산) |
| 오디오 개요 | 3회/일 |
| 소스당 크기 | 약 50만 단어 / 200MB |
일일 채팅 50회는 생각보다 빨리 소진된다. 논픽션 작업 하루치면 절반이 날아간다. 상향하려면 Google AI 요금제 구독이 필요하다.
노트북 간 정보 공유가 안 된다는 점도 중요하다. NotebookLM은 여러 노트북의 정보에 동시 접근하지 못한다. 자료를 주제별로 잘게 쪼개면 나중에 통합 질의를 못 한다.
보안:개인용 NotebookLM은 엔터프라이즈 규정 준수 기능이 없다. NDA 대상 자료라면 NotebookLM Enterprise(데이터가 Google Cloud 프로젝트 내에 상주, VPC-SC 준수)를 검토해야 한다.개인 계정에 고객사 자료를 올리는 것은 대개 계약 위반이다.
언제 쓸 만한가: 개인 리서치, 공개 자료 기반 논픽션, 영상 자막·PDF 다수 처리. 출처 표기가 자동으로 붙는 점이 인용 검증에 유리하다.
언제 안 쓰는 게 나은가: Claude Projects의 캐싱과 RAG로 충분한 경우. 두 도구를 겹쳐 쓰면 관리 비용만 늘어난다.
7-2. DeepSeek — 최근 가격이 바뀌었다
저비용 전처리용으로 널리 권해지는 모델이다. 다만 2026년 8월 16일에 요금 체계가 바뀌었고, 상시 할인이 사라졌다.
| 모델 | 오프피크 입력 | 오프피크 출력 | 캐시 히트 입력 |
|---|---|---|---|
| DeepSeek V4 Flash | $0.22 / MTok | $0.66 / MTok | $0.007 / MTok |
| DeepSeek V4 Pro | $0.66 / MTok | $1.98 / MTok | $0.022 / MTok |
피크 시간대는 정확히 2배다. 그리고 여기가 한국 사용자에게 결정적이다.
피크 시간: 01:00–04:00, 06:00–10:00 UTC (월~금) = 한국시간 10:00–13:00, 15:00–19:00
한국의 업무 시간이 통째로 피크다. "DeepSeek이 싸다"는 전제로 워크플로를 짠 한국 사용자는 실제로는 두 배를 내고 있을 가능성이 높다. 오프피크(한국시간 야간·새벽·주말)로 배치 작업을 돌릴 수 있다면 절반이지만, 대화형 작업은 그럴 수 없다.
여전히 최상위 모델 대비 훨씬 싼 것은 사실이다. 신규 계정에 500만 토큰(30일) 무료 크레딧도 있다. 다만 "압도적으로 싸다"는 인식과 실제 청구 사이의 간격을 알고 쓰는 것과 모르고 쓰는 것은 다르다.
보안: 프롬프트를 제3자 API에 보낸다는 것은 원문 전체를 외부에 넘긴다는 뜻이다. PART 9 참조.
7-3. OpenRouter
여러 모델을 하나의 API로 중개한다. 무료 티어 수치가 특히 자주 잘못 인용된다.
| 항목 | 실제 (2026년) |
|---|---|
| 분당 요청 | 20회 — 크레딧을 사도 안 오른다 |
| 일일 요청 (누적 결제 $10 미만) | 50회 |
| 일일 요청 (누적 결제 $10 이상) | 1,000회 |
| 무료 모델 수 | 25~29개 사이, 로스터가 계속 바뀐다 |
| BYOK | 자기 API 키 연결 시 월 100만 건 무료 라우팅 |
- $10은 누적 구매액 기준이고 잔액이 0이 되어도 1,000회 구간은 유지된다
- 일일 한도는 계정 단위다. API 키를 여러 개 만들어도 늘지 않는다
- "하루 200회"라는 수치가 아직도 돌아다니는데 오래된 값이다
함정 세 가지.
- 실패한 요청도 쿼터를 소모한다. 429를 맞고 재시도하는 루프를 잘못 짜면 오전에 하루치를 태운다.
- 무료 모델은 예고 없이 사라진다. 모델 ID를 하드코딩하면 언젠가 멈춘다. 폴백 필수.
- 데이터 정책. 무료 엔드포인트 중 프롬프트가 학습에 쓰일 수 있다고 약관에 명시된 것이 있다.
유용한 기능: :floor(최저가 라우팅), :nitro(속도 우선), 폴백 모델 지정, 예산 알림.
결론:OpenRouter는 개발자 도구다.작가와 마케터가 채팅으로 일한다면 필요 없다. 대량 반복 업무를 자동화하는 단계에서 검토할 것이다.
PART 8. 다단계 파이프라인 — 언제 만들 가치가 있는가?
널리 공유되는 6단계 워크플로우가 있다.
| 단계 | 작업 | 도구 |
|---|---|---|
| 1 | 복잡한 한국어 프롬프트 정리 | 저비용 모델 |
| 2 | 영어로 변환 | 저비용 모델 |
| 3 | "원시인 영어"로 압축 | 저비용 모델 |
| 4 | 최종 질의 | 고성능 모델 |
| 5 | 결과 정리·번역 | NotebookLM 등 |
| 6 | 한국어 최종본 | 저비용 모델 |
이 방식을 통째로 부정할 필요는 없다. 다만 위치를 바로잡아야 한다. 이건 "모든 사람에게 권하는 기본 워크플로"가 아니라, 앞의 모든 수단을 다 쓰고도 부족할 때 검토하는 최후의 수단이다.
8-1. 진입 조건 — 넷을 모두 충족할 때만
- 입력 비중이 높은 작업인가?PART 1 공식으로 계산해70% 이상이어야 한다. 대량 분류·문서 요약은 해당, 창작·대화형은 미해당.
- 캐싱을 쓸 수 없는가? 매번 완전히 다른 원문이 들어와야 한다. 자료가 고정적이면 프로젝트 캐싱이 훨씬 낫다.
- 번역 손실이 무의미한 작업인가? 분류·태깅은 해당, 문학·브랜드 카피는 미해당.
- 비실시간인가? 왕복 15~25초를 감당할 수 있어야 한다.
넷 중 하나라도 아니면 만들지 마라.
8-2. 성립하지 않는 부분
지연. 6단계는 API 호출 5회를 추가한다. 각 단계 25초면 왕복 1525초다. 작가가 문장 하나 고칠 때마다 20초를 기다리는 워크플로는 성립하지 않는다.
운영 비용. 파이프라인을 만들고 유지하는 시간이 있다. 월 30달러를 아끼려고 하루를 쓰는 것은 자기 시급을 넣으면 명백한 적자다. 그 하루로 쓸 수 있는 원고가 있다.
손실 누적. 번역 두 번, 압축 한 번을 거치면 의미 손실이 곱해진다. 재질문 확률이 올라가고, PART 6-3의 손익분기에 걸린다.
8-3. 그럼에도 유효한 형태
정보 계층화는 다르다. 200페이지 자료를 저비용 모델로 20페이지 요약본으로 만든 뒤 고성능 모델에 넣는 것 — 이건 "압축"이 아니라 선별이고 대단히 효과적이다. 논픽션 작가에게 권할 만하다.
차이는 이렇다. 압축은 같은 내용을 짧게 쓰는 것이고, 선별은 덜 중요한 내용을 버리는 것이다. 전자는 손실이 문체에서 나고, 후자는 손실이 범위에서 난다. 범위 손실은 통제할 수 있다.
PART 9. 보안: 원고와 캠페인 자료는 어디로 가는가
토큰 절약 가이드에 이 장이 없는 경우가 많은데, 실무에서는 가격보다 중요하다.
9-1. 무엇을 넘기고 있는지
저렴한 제3자 API나 무료 중개 서비스를 경유시킨다는 것은 프롬프트 원문 전체를 외부에 넘긴다는 뜻이다.
작가에게 그 원문은 — 미발표 원고, 출판 계약 조건, 취재원 신원이 담긴 녹취, 공동 작업 중인 타인의 초고.
마케터에게 그 원문은 — 미공개 캠페인 전략, 고객사 자료(대개 NDA 대상), 미발표 가격 정책과 출시 일정, 개인정보가 섞인 CRM 데이터.
9-2. "무료"의 실제 대가
여러 무료 LLM 엔드포인트의 데이터 정책에는 프롬프트가 학습에 사용될 수 있다고 명시돼 있다. 음모론이 아니라 약관에 적힌 내용이다.
무료가 아니라 프롬프트로 지불하는 것이다. 미발표 원고나 고객사 자료로 지불하는 것은 계산이 맞지 않는다. 유출 사고 한 건의 기대 비용이 연간 구독료를 몇 자리 수 상회한다.
9-3. 실무 기준선
| 자료 등급 | 허용 범위 |
|---|---|
| 공개 정보 (발표된 글, 공개 자료 리서치) | 저비용 경유·무료 티어 허용 |
| 자기 비공개 자료 (집필 중 원고, 사내 기획) | 계약된 단일 사업자만. 학습 사용 여부 확인 |
| 타인 관련·계약 대상 (고객사 자료, 취재원 정보, 개인정보) | 경유 금지. 조직 계정·엔터프라이즈 등급에서만 |
세 번째 줄에서 마케터들이 자주 실수한다. 고객사 브리프를 개인 계정에 올리는 것은 대개 계약 위반이다.
9-4. 작가를 위한 부기
법적 문제와 별개로, 미발표 원고를 어디에 두느냐는 감정적으로도 중요하다. 최소한 다음은 확인해두는 게 좋다.
- 사용 중인 서비스의 학습 데이터 사용 정책 (플랜별로 다르다)
- 대화 보관 기간과 삭제 절차
- 조직 계정이라면 관리자가 대화를 볼 수 있는지
확인하고 쓰는 것과 확인하지 않고 쓰는 것은 다르다.
PART 10. 규모가 커졌을 때 API 전환하라
10-1. 판단 기준
| 상황 | 권장 |
|---|---|
| 하루 몇 시간 대화형 작업 | 채팅 정액제 |
| 원고 집필·퇴고 | 채팅 (프로젝트 캐싱) |
| 탐색적 리서치 | 채팅 |
| 매일 같은 형식의 대량 처리 | API |
| 카피 수백~수천 종 생성 | API 배치 |
| 정형화된 분류·태깅 | API + 하위 모델 |
작가는 대체로 채팅이 맞다. 집필은 본질적으로 대화형이고 프로젝트 캐싱이 이미 상당한 효율을 준다. 마케터는 반반이다. 기획과 카피 검토는 채팅, 대량 생성과 분류는 API.
10-2. 세 가지 큰 레버
프롬프트 캐싱 — 반복되는 앞부분을 캐시에 올려두면 이후 요청은 정가의 10%로 읽는다. 5분 캐시는 읽기 1회, 1시간 캐시는 읽기 2회면 손익분기다. 진입장벽이 사실상 없다.
배치 처리 — 24시간 안에 결과를 받아도 되면 입출력 모두 50% 할인이고 캐싱과 스택된다. 다만 배치는 비동기·병렬이라 캐시 히트가 최선노력 방식이고 실제 히트율은 30~98%로 편차가 크다.
모델 캐스케이드 — 전량을 하위 모델로 돌린 뒤 신뢰도 낮은 일부만 상위 모델로.
10-3. 실무 예시 - 문서 10만 건 분류
건당 입력 2,000토큰, 출력 50토큰.
| 전략 | 비용 |
|---|---|
| Opus 5 전량 | $1,125 |
| Haiku 4.5 전량 | $225 |
| 캐스케이드 (Haiku 전량 + 저신뢰 10%만 Opus) | $337.50 |
| 캐스케이드 + 배치 50% | $168.75 |
| 캐스케이드 + 배치 + 지침 캐싱 | ~$150 |
Opus 전량 대비 87% 절감하면서 품질 리스크는 10% 구간에서만 지불했다.
10-4. 캐싱 실전 예제 - 사내 문서 QA
고정 시스템 프롬프트 + 참조 문서 50,000토큰, 질문 200 / 답변 500토큰, 하루 500건, Sonnet 5.
| 캐싱 없음 | 5분 캐싱 | |
|---|---|---|
| 입력 | $50.20 | $5.32 (쓰기 $0.13 + 읽기 $4.99 + 질문 $0.20) |
| 출력 | $2.50 | $2.50 |
| 일 합계 | $52.70 | $7.82 |
월 $1,581 → $235. 85% 절감. 프롬프트 문구는 한 글자도 안 고쳤다.
캐시를 깨뜨리는 실수 3가지
- 동적 값을 앞에 두기 — 맨 앞에 타임스탬프를 넣으면 매 요청이 미스다. 정적 앞, 동적 뒤.
- 브레이크포인트를 변하는 블록에 걸기 — 매번 쓰기만 하고 영원히 읽지 않는다.
- 트래픽 공백 — 5분 이상 끊기면 만료된다. 간헐적이면 1시간 캐시나 배치로.
10-5. 숨은 비용
- 웹 검색은 토큰과 별도로 1,000회당 $10. 에이전트가 한 턴에 여덟 번 검색하면 그것만으로 8센트다.
- 웹 페치는 별도 요금이 없지만 가져온 내용이 전부 입력 토큰이다. 논문 PDF 한 편이 약 125,000토큰.
- 도구 정의가 매 요청 입력에 포함된다. 컴퓨터 사용 툴셋 약 4,500토큰, 브라우저 툴셋 약 6,600토큰. 캐시 브레이크포인트 앞에 두면 10분의 1이 된다.
10-6. 비용 회계부터
기법보다 먼저 할 일이다. 어디에 얼마를 쓰는지 모르면 무엇을 줄일지도 모른다.
- 요청마다
usage의input_tokens,output_tokens,cache_read_input_tokens,cache_creation_input_tokens를 기능 태그와 함께 로깅 - 주간으로 "기능별 비용 / 요청 수 / 캐시 히트율" 확인
- 콘솔에서 지출 알림 설정
대부분의 조직에서 청구서의 절반은 예상 밖의 한두 기능에서 나온다.
PART 11. 안티패턴 — 이렇게 하면 오히려 손해
- 재질문을 유발하는 과압축. 대화형 작업에서 재질문 15%면 손익분기다. 압축은 "한 번에 이해되는 선"까지만.
- 품질 미달 모델로 내렸다가 재시도. 하위 모델로 실패하고 상위 모델로 다시 하면 처음부터 상위 모델을 쓰는 것보다 비싸다. 티어링은 어떤 작업이 어느 티어에 맞는지 알 때만 유효하다.
- 미발표 원고·고객사 자료를 비용 이유로 외부 경유. 절약이 아니라 위험 전가다.
- 검증 없는 절감률 인용. "80% 절감"은 대부분 특정 워크로드 한 건의 측정이거나 기제를 잘못 이해한 것이다. 자기 작업에서 재보기 전까지 모든 절감률은 가설이다.
- 오래된 수치 인용. DeepSeek은 2026년 8월에 요금 체계가 바뀌었고, OpenRouter의 "하루 200회"는 이미 낡은 값이다. 절약 가이드의 수치는 6개월이면 상한다.
- 자기 시간을 무료로 계산. 파이프라인 구축·유지 시간이 절감액을 넘으면 절약이 아니다.
- 탐색적 대화까지 없애기. 반복 업무 압축과 사유 압축은 다르다.
- 프로젝트를 만들어놓고 파일을 안 넣기. 프로젝트만 만들고 원고는 매번 채팅에 붙여넣는 사람이 많다. 캐싱 혜택은 프로젝트 지식에 올린 것에만 적용된다.
- 정리 안 한 프로젝트. 초고·1고·2고가 다 남아 있으면 검색 정확도가 떨어진다. 절약 이전에 품질 문제다.
- 도구를 겹쳐 쓰기. NotebookLM과 Projects를 둘 다 쓰면서 자료를 양쪽에 두면 관리 비용만 늘고 절감은 없다.
PART 12. 직군별 체크리스트
작가·인문 필자용
설정 (한 번만)
- 작품별 Projects 생성
- 원고·설정 바이블·문체 규칙·참고 자료를 프로젝트 지식에 업로드
- 프로젝트 지침은 5줄 이내. "요청하지 않은 전문 재출력 금지" 포함
- 문체를 스타일 기능 또는 규칙 파일로 고정
- 기출간 원고 2~3편을 문체 기준선으로 첨부
습관 (매일)
- 챕터당 대화 1개. 끝날 때 300자 요약 요청
- "전문 다시" 대신 "해당 문단만" / "before-after 표만"
- 원고 입력은 통째로, 출력은 부분만
- 교열에는 하위 모델. 구조 진단에만 최상위 모델
- 집필 대화에서는 웹 검색·리서치 끄기
- 가벼운 작업에는 확장 사고 끄고 effort 낮추기
주간
- 설정 > 사용량에서 세션·주간 진행 확인
- 프로젝트에서 안 쓰는 파일 정리
- 확정된 설정을 설정 바이블에 반영해 재업로드
마케터용
설정 (한 번만)
- 브랜드별 Projects 생성
- 브랜드 보이스·팩트시트·페르소나·법무 가이드·우수사례 업로드
- 반복 업무용 프롬프트 템플릿 작성 (고정 블록 위, 변수 블록 아래)
- 고객사 자료 취급 기준을 팀 내에 명문화
습관 (매일)
- 카피는 축을 지정해 한 메시지에 배치 요청
- 출력은 표 형식 + "설명 붙이지 마"
- 평가·선별까지 같은 메시지에 포함
- 데이터는 붙여넣지 말고 필요한 열만 파일로
- 아티팩트는 부분 수정, 전체 재생성 금지
주간·월간
- 설정 > 사용량 확인. Opus 한도 별도 관리
- 성과 좋았던 카피를 우수사례 파일에 추가
- 팩트시트 수치 갱신
- 대량 반복 업무가 생겼는지 점검 → API 검토 시점
PART 13. 한 장 요약
| 순서 | 할 일 | 예상 효과 |
|---|---|---|
| 1 | 반복 참조 자료를 전부 Projects로 옮긴다 | 크다 |
| 2 | "전문 재출력"을 "부분만 출력"으로 바꾼다 | 크다 |
| 3 | 여러 요청을 한 메시지에 배치한다 | 크다 |
| 4 | 대화를 작업 단위로 끊고 요약으로 인계한다 | 중간 |
| 5 | 작업 난이도별로 모델·effort·확장 사고를 바꾼다 | 중간 |
| 6 | 안 쓰는 도구·커넥터를 끈다 | 중간 |
| 7 | 문체·브랜드 규칙을 파일로 고정한다 | 중간 (품질 이득이 더 큼) |
| 8 | 자료가 많으면 외부 오프로딩 검토 | 상황에 따라 |
| 9 | 대량 반복 업무면 API + 캐싱 + 배치 | 크다 (해당자만) |
| 10 | 프롬프트 문구를 다듬는다 | 작다 |
| 11 | 다단계 번역·압축 파이프라인 | 대부분 불필요 |
1~3번만 해도 대부분의 사람은 체감이 달라진다.
마치며
토큰 최적화 글이 유독 과장되기 쉬운 이유가 있다. 절감률은 분모를 밝히지 않고도 쓸 수 있는 숫자이기 때문이다. "80% 절감"은 어떤 작업에서 무엇을 기준으로 재느냐에 따라 사실일 수도 있고 완전한 허구일 수도 있다. 그리고 그 분모를 밝힌 글은 거의 없다.
이 문서도 그 위험에서 자유롭지 않다. 여기 실린 수치들 — 92%, 97%, 85%, 87% — 은 전부 명시된 조건에서의 계산값이지 당신의 작업에서 나올 값이 아니다. 조건이 다르면 결과도 다르다. PART 1에 공식을 넣어둔 이유가 그것이다. 인용하지 말고 계산하라.
그래서 이 문서의 실제 결론은 기법 목록이 아니라 태도 쪽에 가깝다.
LLM은 엑셀이지 오라클이 아니다. 계산기이지 신탁이 아니라는 뜻이고, 그건 비용에 대해서도 똑같이 적용된다. 남의 절감률을 신탁처럼 받아들이지 말고, 자기 설정 화면을 열어 자기 숫자를 보라. 5시간 진행 막대가 언제 어디서 빨리 차는지 일주일만 관찰하면, 이 문서의 어떤 항목보다 정확한 답이 나온다.
그리고 마지막으로 한 가지. 절약의 목적은 절약이 아니다. 교열과 포맷 변환과 반복 카피에서 아낀 한도로 무엇을 할 것인가 — 그게 정해져 있지 않으면 아낀 것은 그냥 안 쓴 것이다. 작가에게는 여섯 번 왕복하는 배회가, 마케터에게는 브리프를 세 번 뒤집어 보는 시간이 거기 있어야 한다.
아끼는 법을 익히는 이유는 중요한 데 쓰기 위해서다.
출처
Claude.ai 사용 한도 (정액제 사용자)
- 사용 한도와 길이 한도 — https://support.claude.com/en/articles/11647753-how-do-usage-and-length-limits-work
- 사용 한도 모범 사례 — https://support.claude.com/en/articles/9797557-usage-limit-best-practices
- 컨텍스트 창 크기 — https://support.claude.com/en/articles/8606394-how-large-is-the-context-window-on-paid-claude-plans
- 프로젝트 RAG — https://support.claude.com/en/articles/11473015-retrieval-augmented-generation-rag-for-projects
- 사용량 확인 — https://claude.ai/settings/usage
Claude API
- 공식 가격표 — https://platform.claude.com/docs/en/about-claude/pricing
- 프롬프트 캐싱 — https://platform.claude.com/docs/en/build-with-claude/prompt-caching
- 배치 처리 — https://platform.claude.com/docs/en/build-with-claude/batch-processing
외부 도구
- NotebookLM 고객센터 — https://support.google.com/notebooklm/
- NotebookLM Enterprise — https://cloud.google.com/gemini/enterprise/notebooklm-enterprise/docs/overview
- DeepSeek 요금 — https://api-docs.deepseek.com/quick_start/pricing
- OpenRouter 한도 — https://openrouter.ai/docs/api_reference/limits
가격·한도·기능은 자주 바뀐다. 특히 DeepSeek은 2026년 8월, OpenRouter는 그 이전에 조건이 변경됐다. 중요한 판단 전에 공식 페이지에서 다시 확인할 것.
이 글은 유료 LLM 사용 실전 가이드이며, 투자 권유나 특정 모델·플랜 가입 권유가 아닙니다.