API를 쓰면서 비용이 예상보다 두 배 가까이 나온 적 있으신가요? 저는 있습니다. 그것도 첫 달 청구서를 받고 나서야 깨달았습니다. 입력 토큰과 출력 토큰의 요금이 다르다는 걸, 직접 돈을 날리고 나서야 제대로 인식하게 됐습니다. 그 경험이 지금의 설계 습관을 만들었습니다.
청구서가 가르쳐준 입출력 요금의 차이
RAG(Retrieval-Augmented Generation) 기반의 문서 질의응답 서비스를 만들고 있었습니다. RAG란 외부 문서를 검색해서 그 내용을 컨텍스트로 LLM에 넘기는 방식으로, 모델이 학습하지 않은 최신 정보나 사내 자료를 다룰 때 자주 쓰이는 아키텍처입니다.
구조는 단순했습니다. 사용자가 질문하면 관련 문서를 검색하고, 검색된 결과 전체를 컨텍스트 윈도우에 넣은 뒤 상세하고 친절한 자연어 답변을 받아오는 방식이었습니다. 저는 검색 결과를 최대한 많이 넣을수록 답변이 정확해진다고 생각했고, 입력이 길어지니 입력 비용이 크겠지, 라고만 생각했습니다.
그런데 첫 달 내역을 뜯어봤을 때, 입력 비용보다 출력 비용이 압도적으로 컸습니다. 출력 토큰이 전체 비용의 70% 이상을 차지하고 있었습니다. 솔직히 이건 예상 밖이었습니다. 긴 문서를 넣으니까 당연히 입력 비용이 클 거라고만 생각했거든요.
Anthropic의 공식 가격 정책을 보면, Claude Sonnet 계열 기준으로 출력 토큰 요금이 입력 토큰 요금의 약 3~5배 수준으로 책정되어 있습니다. OpenAI의 GPT-4o 기준으로도 출력 토큰이 입력보다 2~4배가량 비쌉니다. 제가 "길고 친절한 답변"을 요청했던 것 자체가, 비용 구조상 가장 비싼 선택이었던 셈입니다.
이 구조를 이해하고 나면 명확해집니다. 출력 토큰 단가는 입력 토큰 대비 최대 5배까지 비쌀 수 있습니다. 자연어로 길게 답변받는 방식은 출력 토큰을 구조적으로 낭비합니다. 프롬프트에서 출력 형식과 최대 길이를 명시하지 않으면 모델은 필요 이상으로 길게 씁니다. 이 세 가지 사실을 설계 단계에서 인지하고 있느냐 아니냐가 실제 운영 비용에 큰 차이를 만듭니다. 저는 이걸 청구서를 보고서야 깨달았는데, 지금 생각하면 설계 단계에서 먼저 따져봤어야 했습니다.
구조화 출력이 비용만 줄인 게 아니었습니다
문제를 파악하고 나서 저는 출력 형식을 JSON으로 고정했습니다. JSON이란 데이터를 키-값 쌍으로 구조화해서 표현하는 형식으로, 기계가 파싱하기 좋고 사람도 보기 편한 경량 데이터 교환 포맷입니다. 프롬프트에 각 항목의 글자 수 제한을 명시했고, "요약은 100자 이내, 출처 항목은 3개 이하"처럼 구체적인 제약을 걸었습니다.
결과가 바로 나왔습니다. 출력 토큰이 절반 가까이 줄었고, 비용도 그에 비례해서 떨어졌습니다. 그런데 제가 직접 써보니 비용 절감보다 더 놀라웠던 건 다른 부분이었습니다.
파싱 안정성이 눈에 띄게 높아졌습니다. 자연어 응답을 후처리할 때는 응답 형태가 매번 조금씩 달라서 예외 처리 코드가 계속 늘어났습니다. JSON으로 고정하고 나서는 그 문제가 거의 사라졌습니다. 후처리 코드가 단순해지니 유지보수 부담도 줄었고, 배포 이후 장애 빈도도 낮아졌습니다.
그리고 사용자 경험도 오히려 개선됐습니다. 군더더기 없이 핵심만 나오니 화면 구성이 깔끔해졌고, 이용자 피드백도 좋았습니다. "친절한 자연어 답변"이 반드시 더 좋은 UX를 만드는 게 아니라는 걸, 직접 해보고 나서야 체감했습니다. 사용자는 길고 친절한 문장보다 필요한 정보를 빠르게 찾는 것을 더 선호했습니다. 이건 제가 서비스 설계에서 가지고 있던 선입견을 완전히 바꾼 경험이었습니다. 개발자 관점에서 "잘 쓴 답변"과 사용자가 원하는 것이 다를 수 있다는 걸, 데이터로 확인하고서야 인정하게 됐습니다.
Batch API, 비용 설계의 차원이 다른 선택
또 한 가지 짚고 싶은 건 Batch API입니다. Batch API란 여러 요청을 묶어서 비동기로 처리하는 방식으로, 실시간 응답이 필요 없는 경우에 비용을 크게 줄일 수 있는 옵션입니다. OpenAI Batch API 기준으로 동일 모델 사용 시 표준 API 대비 약 50% 할인이 적용됩니다. 실시간 응답이 필요 없는 보고서 생성, 야간 배치 분석, 대량 문서 요약 작업 같은 워크로드가 있다면 Batch API는 진지하게 검토할 만한 선택지입니다.
이 부분이 비용 절감 관련 글에서 짧게 지나가는 경우가 많은데, 저는 이걸 본문에서 구체적으로 다뤄야 한다고 생각합니다. 단순히 "프롬프트를 짧게 써라"는 식의 조언과는 차원이 다른 전략적 설계 선택이기 때문입니다. 실시간 응답이 필요 없는 작업 유형을 미리 분류해두고 Batch API로 빼는 것만으로 전체 비용 구조가 상당히 달라질 수 있습니다. 저는 이걸 뒤늦게 적용했는데, 야간 보고서 생성 파이프라인을 Batch API로 전환한 것만으로 해당 기능의 월 비용이 반 이상 줄었습니다. 처음부터 설계할 때 "이 기능은 실시간이어야 하는가?"를 질문하는 게 맞습니다.
설계 습관이 바뀌었습니다
이 경험 이후로 저는 기능 설계를 시작할 때 항상 출력 형식과 최대 길이를 먼저 정합니다. 프롬프트 엔지니어링을 비용 관점에서 먼저 생각하는 습관이 생겼습니다. 예쁜 자연어 답변보다 구조화된 짧은 답변이 비용과 안정성 모두에서 낫다는 걸 몸으로 배웠습니다.
API 비용을 줄이고 싶다면 먼저 청구서를 꺼내서 입력과 출력 토큰 비율을 확인해 보시길 권합니다. 출력 쪽이 예상보다 크다면, 지금 당장 출력 형식을 구조화하는 것만으로도 비용과 코드 품질 두 가지를 동시에 잡을 수 있습니다. 그 작은 변화가 시스템 전체의 설계 방향을 바꿔놓을 수도 있습니다.
참고:
OpenAI 가격 정책: https://openai.com/api/pricing/
Anthropic 가격 정책: https://www.anthropic.com/pricing