솔직히 말하면, 처음 Claude API를 블로그 자동화에 연결했을 때 한 달 청구서를 보고 잠시 멈췄습니다. 콘텐츠 하나당 드는 API 비용이 제가 예상한 것의 두 배를 넘고 있었거든요. 문제는 API 자체가 비싼 게 아니라, 제가 프롬프트를 아무 전략 없이 보내고 있었다는 겁니다. 시스템 프롬프트를 매 요청마다 통째로 전송하고, 같은 맥락을 중복 설명하고, 출력 형식을 자연어로 장황하게 설명하는 방식이었습니다. 8주 동안 실험을 반복하면서 지금은 같은 품질의 결과물을 훨씬 적은 토큰으로 뽑아내고 있습니다. 오늘은 그 과정에서 직접 확인한 기법들을 공유합니다.
문제는 ‘토큰 수’가 아니라 ‘중복 토큰’이었다
처음에 저는 비용 문제를 단순히 ‘긴 프롬프트 = 비싼 비용’으로 이해했습니다. 그래서 시스템 프롬프트를 짧게 줄이는 방향으로 접근했는데, 품질이 먼저 떨어졌습니다. 핵심을 이해하고 나서야 방향이 바뀌었습니다. 진짜 문제는 ‘중복 전송’이었습니다. 제 파이프라인은 Make.com에서 Flask API를 거쳐 Claude API를 호출하는 구조인데, 매 요청마다 동일한 시스템 프롬프트 전체, 즉 역할 정의 + 톤 가이드 + 출력 스키마 + 예시까지 전부 input 토큰으로 전송하고 있었습니다. Claude API의 Prompt Caching 기능을 적용하기 전까지는 이 비용이 고스란히 쌓였습니다. Anthropic의 Prompt Caching은 cache_control 파라미터를 system 블록에 추가하면 동일한 프리픽스를 캐시로 처리해 토큰 비용을 약 90% 절감합니다. 단, 캐시 유효 시간이 5분이라는 제약이 있어서, 저처럼 Make.com에서 여러 시나리오를 순차 실행하는 구조에서는 실행 간격을 5분 이내로 묶는 배치 처리 방식으로 전환했습니다. 이것만으로 시스템 프롬프트 관련 input 토큰이 대폭 감소했습니다. 중복을 제거하지 않으면 프롬프트를 아무리 정교하게 다듬어도 비용 구조는 바뀌지 않습니다.
출력 형식 지시를 자연어에서 구조로 바꾸면 생기는 일
두 번째로 큰 낭비는 출력 형식 설명에 있었습니다. 예전 제 시스템 프롬프트에는 이런 식의 문장이 있었습니다. ‘응답은 반드시 JSON 형식으로 작성하되, title 필드에는 제목을, body 필드에는 본문을, 그리고 tags 필드에는 콤마로 구분된 태그 5개를 넣어주세요. 필드 누락 시 파이프라인이 중단됩니다.’ 이런 자연어 설명은 사람이 읽기엔 편하지만 토큰 비용 측면에서는 최악입니다. 저는 이걸 JSON Schema 블록으로 교체했습니다. 스키마 자체가 필드 이름, 타입, 설명을 함축하기 때문에 자연어 설명 대비 토큰이 절반 이하로 줄어들었고, 오히려 형식 준수율이 높아졌습니다. 추가로, user 메시지 쪽에서도 동일한 원칙을 적용했습니다. 매 요청에 콘텐츠 맥락을 장황하게 서술하던 방식을 변수 치환 방식으로 전환했습니다. Flask API에서 Make.com으로부터 받은 데이터를 키-값 쌍으로 압축해서 ‘날짜: 2026-09-12 / 주제: Claude API 비용 절감 / 주차: 8’처럼 한 줄로 전달합니다. Claude는 이 압축된 맥락을 충분히 이해하고 품질을 유지합니다. 중요한 건 모델이 ‘이해할 수 있는’ 최소 정보를 주는 것이지, 사람이 이해할 수 있는 수준으로 친절하게 설명하는 게 아닙니다.
역할 분리와 모델 계층화로 비용 구조를 설계한다
세 번째 실험은 모델 선택의 계층화입니다. 저는 처음에 모든 작업을 claude-3-5-sonnet으로 처리했습니다. 칼럼 작성이든, 태그 추출이든, 슬러그 생성이든 다 똑같이 Sonnet에게 맡겼습니다. 그런데 실제로 태그 5개를 추출하거나 슬러그를 영문으로 변환하는 작업은 Haiku로도 충분히 처리됩니다. 지금은 파이프라인을 두 단계로 나눴습니다. Make.com에서 먼저 Haiku에게 메타 정보 생성 작업(태그, 슬러그, meta_description)을 맡기고, 본문 생성만 Sonnet에게 위임하는 구조입니다. Haiku는 Sonnet 대비 입력 토큰 기준으로 약 25배 저렴합니다. 분량이 적은 필드들을 Haiku로 전환하는 것만으로도 전체 비용 구조가 달라집니다. 단, 주의할 점이 있습니다. Haiku에게 창의적인 판단이나 긴 맥락 이해를 요구하면 품질이 떨어집니다. 저는 Haiku에게는 ‘주어진 본문을 보고 태그 5개를 추출하라’처럼 판단 범위를 명확히 제한한 프롬프트만 줍니다. 판단 영역과 처리 영역을 분리하는 것이 모델 계층화의 핵심입니다. 이 세 가지 실험, 즉 캐싱 적용 + 출력 구조화 + 모델 계층화를 조합한 결과, 현재 파이프라인의 월간 API 비용은 초기 대비 관찰 기준으로 절반 수준에서 안정화되고 있습니다. 아직 검증 중인 수치이므로 단정은 못 하지만, 방향성은 명확합니다.
💬 운영자 한마디
저는 AI 도구를 쓸 때 ‘잘 쓰는 것’보다 ‘효율적으로 구조화하는 것’이 더 중요하다는 걸 이번 실험에서 다시 확인했습니다. 프롬프트 엔지니어링은 글쓰기 기술이 아니라 시스템 설계 기술에 가깝습니다. 비용이 부담되기 시작했다면, 그건 설계를 다시 볼 시점이라는 신호입니다.
— J_River · autoprofit 운영자
✅ 이번 주 체크리스트
- Claude API 호출 시 system 블록에 cache_control 파라미터를 추가했는가
- Make.com 시나리오 실행 간격이 5분 이내로 묶여 캐시를 실제로 활용하고 있는가
- 출력 형식 지시를 자연어 문장 대신 JSON Schema로 교체했는가
- user 메시지의 맥락 정보를 키-값 압축 방식으로 전달하고 있는가
- 태그 추출·슬러그 생성 등 단순 처리 작업을 Haiku로 분리했는가
- 각 모델 호출 건당 input/output 토큰 수를 Anthropic 콘솔에서 주기적으로 확인하고 있는가
- 시스템 프롬프트 내 중복 설명이나 불필요한 예시 블록을 제거했는가
비용 절감은 품질 타협이 아닙니다. 중복을 제거하고, 구조로 설명하고, 역할을 나누는 것. 이 세 가지가 제가 8주 동안 실험으로 확인한 방향입니다. 다음 주에는 Jesse 프레임워크 전략 파라미터 최적화 실험을 다룰 예정입니다.
※ 본 콘텐츠는 운영자 개인의 경험과 연구를 바탕으로 한 정보 제공 목적이며, 특정 종목에 대한 투자 권유나 매매 시그널이 아닙니다. 암호화폐 및 자동매매는 원금 손실 가능성이 있는 고위험 활동이며, 모든 투자 판단과 그 결과에 대한 책임은 투자자 본인에게 있습니다.