Opus 4.7의 늘어난 토큰 소모량을 억제하는 프롬프트 설계법

Claude Opus 4.7은 성능 면에서 괴물 같은 모델이지만 비용 면에서는 꽤 까다롭습니다. 이전 모델보다 토큰 소모량이 약 35% 늘어났기 때문입니다. Anthropic이 입력 가격을 $5/MTok으로 묶어두긴 했어도 실제 청구서를 받아보면 숫자가 달라져 있을 겁니다. 출력 토큰 가격이 입력보다 5배 비싼 $25/MTok이라는 점을 기억해야 합니다. 모델의 뛰어난 지시 이행 능력을 활용해 답변의 길이를 물리적으로 줄이지 않으면 지갑이 순식간에 털립니다.

서술어를 버리고 기호로 명령하기

Opus 4.7은 "친절하고 상세하게 요약해줘" 같은 다정한 문장에 오히려 낭비되는 토큰이 많습니다. 이 모델은 구조화된 명령을 훨씬 잘 알아듣습니다. 자연어 지시사항을 XML 태그와 핵심 키워드 위주로 바꾸면 응답 길이를 20% 정도 줄일 수 있습니다.

• 시스템 프롬프트의 체질 개선: "당신은 도움이 되는 비서입니다" 같은 미사여구는 전부 삭제하십시오. 대신 Tone: Concise, Output: JSON only, Intro/Outro: None처럼 짧은 키워드로 명세하는 것이 유리합니다.
• XML 태그 활용: 지시사항은 <instructions>, 배경 정보는 <context> 태그로 분리하십시오. 모델이 정보를 탐색하는 연산 효율이 좋아집니다.
• 추론 과정 차단: 프롬프트 끝에 Skip reasoning: true 플래그를 넣으십시오. 사용자에게 보여줄 필요가 없는 모델의 속생각(Thinking process)이 출력 토큰으로 잡히는 것을 막아줍니다.

이미지 분석 비용을 80% 아끼는 파이프라인

Opus 4.7은 2,576픽셀 고해상도까지 읽어내지만 그 대가는 요청당 최대 4,784 토큰입니다. Anthropic의 계산식 $Tokens \approx (Width \times Height) / 750$을 대입해보면 고해상도 이미지를 그대로 던지는 건 무모한 짓입니다. 1인 개발자나 스타트업이라면 인프라 단에서 해상도를 통제해야 합니다.

1. 사전 리사이징: 백엔드에서 Sharp나 Pillow 라이브러리를 사용해 이미지의 긴 쪽을 800px로 줄여서 보내십시오. UI 분석이나 일반 객체 인식에는 이 정도 해상도로도 충분합니다.
2. Files API 참조: 같은 이미지를 두고 여러 번 대화해야 한다면 base64로 매번 쏘지 말고 Files API에 올려서 file_id만 부르십시오.
3. 부분 크롭(ROI) 전략: 꼭 정밀하게 봐야 할 부분만 고해상도로 잘라내고, 나머지는 저해상도 전체 샷으로 보내는 이중 구조를 만드십시오. 이미지 관련 비용을 80% 이상 깎으면서 정확도는 챙길 수 있습니다.

하이쿠를 라우터로 쓰는 하이브리드 설계

모든 요청을 Opus 4.7로 받는 건 돈을 버리는 일입니다. 2026년 현재 백엔드 설계의 정석은 코디네이터-워커(Coordinator-Worker) 패턴입니다. 상대적으로 저렴한 모델이 1차 분류를 맡고 정말 어려운 일만 Opus에게 넘기는 방식입니다.

비용 절감의 핵심은 프롬프트 캐싱입니다. 시스템 프롬프트나 고정된 API 문서가 1,024 토큰을 넘어가는 지점에 cache_control: {"type": "ephemeral"}을 설정하십시오. 캐시 히트율을 80%까지 끌어올리면 반복되는 입력값에 대해 90% 할인을 받을 수 있습니다. 단순한 라우팅과 캐싱 도입만으로도 전체 운영비를 절반 이하로 묶어두는 게 가능합니다.

마지막으로 effort: low 파라미터를 사용해 모델이 스스로 추론 깊이를 과하게 가져가지 않도록 제한하십시오. 태스크 예산(Task Budgets) 기능을 켜두는 것도 갑작스러운 토큰 폭주를 막는 안전장치가 됩니다.