Claude API 토큰, 아끼려다 오히려 망하는 패턴들

Claude API 요금 고지서 보고 멘붕 온 적 있으신가요. 저도 처음엔 그랬어요. 분명히 "간단한 기능 하나만 붙이는 거잖아" 싶었는데, 한 달 쓰고 나서 청구서를 열었더니 숫자가 예상의 세 배였습니다. 그때부터 진지하게 뜯어봤어요. 토큰이 어디서 새는지.

그리고 솔직히 말하면, 문제는 대부분 Claude가 아니라 제 코드에 있었어요. 몰라서 그냥 냅뒀던 습관들, 귀찮아서 안 건드린 설정들. 오늘은 그걸 하나씩 짚어볼게요.

토큰이 뭔지부터 다시 잡고 가야 해요

토큰. 이게 글자 수랑 같은 거라고 생각하면 살짝 틀려요. 영어는 단어 하나가 대략 1토큰, 한국어는 글자 하나가 보통 1~2토큰 정도 됩니다. 그러니까 한국어로 프롬프트 쓰면 영어보다 토큰 소비가 훨씬 빠르다는 뜻이에요.

여기서 중요한 게 있는데, Claude API는 입력 토큰이랑 출력 토큰을 따로 셉니다. 그리고 Claude 3.5 Sonnet 기준으로 출력이 입력보다 약 3배 비싸요. 쉽게 말하면, 내가 보내는 질문보다 Claude가 돌려주는 답변이 돈을 더 잡아먹는다는 거예요. 1만 토큰짜리 대화면 입력·출력 구조에 따라 실제 비용이 2배 이상 차이 날 수 있어요.

이 구조를 모르고 그냥 썼을 때 어떤 일이 생기는지는, Claude API 쓰다가 요금 폭탄 맞기 전에 알아야 할 것들에서 계산식까지 같이 뜯어봤으니 거기도 한번 보시면 좋아요.

시스템 프롬프트가 매 요청마다 탄다는 걸 모르는 사람이 많아요

처음 API 붙일 때 시스템 프롬프트를 좀 공들여 씁니다. "너는 친절한 고객 상담 어시스턴트고, 항상 공손하게 답해야 하며, 부정적인 내용은 삼가고, 제품 소개는 이런 방식으로 하고, 절대 경쟁사 이름은 언급하지 말고..." 이러다 보면 쉽게 500~1000토큰이 돼요.

그런데 이게 매 요청마다 입력 토큰에 합산됩니다. 하루에 사용자가 1000번 질문하면, 시스템 프롬프트 1000토큰짜리가 100만 토큰을 혼자 다 태우는 거예요. 질문 내용이랑 상관없이.

그래서 저는 시스템 프롬프트를 줄이는 작업을 했는데, 처음엔 "이거 지우면 품질 떨어지는 거 아니야?" 걱정했거든요. 근데 막상 해보니까 핵심 지침만 남겨도 Claude가 맥락을 꽤 잘 잡아요. 장황하게 설명하는 것보다 짧고 명확한 게 오히려 낫더라고요. 600토큰짜리를 180토큰으로 줄였을 때 응답 품질이 크게 달라지진 않았어요.

줄이는 요령은 간단해요. "항상 ~ 해야 한다"는 표현보다 "~만 해"처럼 동작 중심으로. 예시를 길게 넣는 것보다 핵심 패턴 하나만. 부정형("~하지 말 것")을 긍정형으로 바꾸면 대부분 더 짧아져요.

대화 기록을 통째로 넘기는 실수

Claude API에는 자동 메모리가 없어요. 대화 흐름을 유지하려면 이전 메시지들을 직접 배열에 담아서 매번 보내야 해요. 이걸 처음 API 연결할 때 보통 배우는데, 문제는 그 배열을 계속 쌓아두는 거예요.

사용자가 10번 왔다 갔다 하면, 10번째 요청에는 이전 9번의 대화가 전부 담겨서 날아갑니다. 대화가 길어질수록 입력 토큰이 눈덩이처럼 불어나는 구조예요. 이걸 모르고 방치하면 후반부 대화 한 번이 초반부 대화 열 번 값이 나오는 상황이 생겨요.

해결 방법은 몇 가지 있는데, 제가 가장 많이 쓰는 건 두 가지예요.

첫 번째는 슬라이딩 윈도우. 최근 N턴만 유지하고 그 이상은 잘라내는 방식이에요. 고객 상담처럼 단발성 대화가 많은 서비스는 이게 제일 간단하고 효과적이에요. 보통 최근 4~6턴 정도면 맥락 유지에 충분한 경우가 많더라고요.

두 번째는 요약 압축. 일정 길이가 넘어가면 Claude한테 "지금까지 대화를 3문장으로 요약해줘"라고 한 번 더 호출해서, 그 요약본을 이후 대화에 맥락으로 심어두는 방식이에요. 이건 장기 대화가 필요한 서비스에 더 맞아요. 요약 호출 비용이 추가되긴 하는데, 그래도 원문 통째로 들고 다니는 것보다 훨씬 저렴해요.

출력을 제한하지 않으면 Claude는 친절하게 길게 씁니다

Claude가 기본적으로 상당히 친절해요. 물어본 것보다 더 많이 설명해주려는 경향이 있어요. 좋은 특성인데, API로 쓸 때는 이게 비용으로 직결됩니다.

"이 텍스트가 긍정인지 부정인지 분류해줘"라고 보내면, 잘 설명 안 하면 "네, 이 텍스트는 전반적으로 긍정적인 감정을 담고 있습니다. 특히 '기쁘다'라는 표현과..."처럼 분석까지 딸려오거든요. 근데 저한테 필요한 건 그냥 "긍정" 한 단어예요.

max_tokens 파라미터로 출력 길이를 제한하는 건 기본이고, 프롬프트 자체에서도 출력 형식을 못 박아두는 게 효과적이에요. "한 단어로만 답해", "JSON 형식으로만 반환해, 설명 없이" 이런 식으로요. 이렇게 하면 출력 토큰이 극적으로 줄어드는 경우가 많아요. 분류 작업 같은 건 90% 이상도 가능해요.

모델 선택을 안 바꾸는 것도 낭비예요

Claude 3.5 Sonnet을 모든 작업에 기본값으로 박아두는 분들 꽤 있어요. 저도 초반에 그랬는데, 이게 사실 상당한 낭비입니다.

단순 텍스트 분류, 키워드 추출, 형식 변환 같은 작업은 Claude 3 Haiku로도 충분히 잘 돼요. Haiku는 Sonnet 대비 입력 기준으로 훨씬 저렴하고 속도도 빠릅니다. 복잡한 추론이나 긴 문서 분석은 Sonnet이 맞는데, 간단한 작업까지 Sonnet 돌릴 이유가 없어요.

제가 했던 방식은 작업 유형을 분류해서 라우팅하는 거예요. 입력 길이가 짧고 출력도 단순한 작업은 Haiku로, 복잡도가 높은 건 Sonnet으로 나눠 보내는 거죠. 이렇게 했더니 월 비용이 체감할 수 있을 만큼 줄었어요. 전체 요청 중 단순 작업이 60% 넘으면 효과가 확실하게 나와요.

캐싱을 쓰면 되는 걸 모르는 경우

Anthropic이 프롬프트 캐싱 기능을 내놨는데, 생각보다 모르는 분들이 많더라고요. 동일한 시스템 프롬프트나 긴 컨텍스트가 반복적으로 쓰인다면, 캐싱 설정을 켜두면 첫 호출 이후 같은 부분은 캐시된 토큰 가격으로 처리돼요.

캐시 읽기 비용은 일반 입력 토큰보다 훨씬 싸요. 시스템 프롬프트가 길거나, RAG로 긴 문서를 맥락에 주입하는 구조라면 캐싱 효과가 굉장히 크게 나와요. API 문서에서 cache_control 파라미터 설정하는 방법 금방 나오니까, 해당하는 구조면 꼭 한번 적용해보세요.

아끼려다 오히려 망하는 패턴 하나 더

프롬프트를 너무 짧게 줄이려다가 Claude가 엉뚱한 답을 내놓고, 그걸 보정하려고 재호출을 반복하는 경우가 있어요. 이게 사실 토큰을 더 씁니다. 처음에 명확하게 써서 한 번에 원하는 답 받는 게 훨씬 경제적이에요.

절약과 명확성 사이에서 균형을 잡는 게 진짜 노하우인데, 경험적으로는 "왜 이 작업을 하는지 배경 설명"은 줄여도 되고, "어떤 형식으로 답해야 하는지"는 절대 줄이면 안 된다는 기준이 도움이 됐어요. 역할·형식·제약 조건은 명확하게. 나머지 친절한 배경 설명은 과감하게 쳐내는 거예요.

📌 한 줄 정리: Claude API 토큰 낭비는 대부분 시스템 프롬프트 비대화, 대화 기록 무한 축적, 출력 미제한, 단일 모델 고정에서 나온다. 각각 하나씩만 손봐도 체감 비용이 달라진다.

토큰 절약은 프롬프트를 무조건 짧게 만드는 게 아니라, 불필요한 부분을 정확하게 찾아내는 일이에요.