19장. 비용, 속도, 품질의 트레이드오프

프로토타입 단계에서는 가장 똑똑해 보이는 모델 하나를 붙이면 일이 꽤 잘 굴러간다. 하지만 서비스가 되면 질문이 달라진다. "이 답이 좋은가?"만으로는 부족하다. "얼마나 빨리?", "얼마나 자주 안정적으로?", "얼마나 적은 비용으로?"가 함께 따라온다. 프로덕션에서 중요한 것은 최고 성능 모델을 쓰는 일이 아니라, 적정 비용으로 충분한 품질을 꾸준히 내는 것이다.

LLM 서비스의 세 축은 비용, 속도, 품질이다. 셋은 늘 같은 방향으로 움직이지 않는다. 보통 품질을 더 원하면 더 비싼 모델, 더 긴 프롬프트, 더 많은 출력 토큰이 필요해진다. 반대로 속도를 올리려고 작은 모델과 짧은 응답을 택하면 품질이 흔들릴 수 있다. 결국 실무는 "무엇을 포기하고 무엇을 지킬 것인가"를 결정하는 일이다.

세 축은 감으로 보지 말고 숫자로 본다

속도부터 보자. LLM 응답 속도는 단순히 "몇 초 걸렸는가" 한 줄로 보면 오판하기 쉽다. 사용자는 먼저 첫 글자가 얼마나 빨리 보이느냐를 체감하고, 그다음 전체 응답이 언제 끝나는지를 느낀다. 그래서 최소한 다음 지표는 구분해서 봐야 한다.

• TTFT(Time to First Token): 첫 토큰이 도착하기까지 걸린 시간

• E2E Latency: 요청부터 마지막 토큰까지의 전체 시간

• TPOT(Time per Output Token): 첫 토큰 이후 토큰이 얼마나 부드럽게 이어지는지 보여주는 속도

• Goodput: 단순 처리량이 아니라, 정한 SLO를 만족한 요청의 처리량¹

운영에서는 평균값만 보면 안 된다. 평균이 좋아도 느린 꼬리 구간이 길면 실제 사용자는 "오늘 왜 이렇게 느려?"라고 느낀다. 그래서 P50보다 P95, P99가 더 중요할 때가 많다. 모델별·엔드포인트별로 비용, 지연 시간, 에러율을 함께 봐야 좋은 판단이 나온다.²

품질도 마찬가지다. "좋다"는 감상이 아니라 작업 기준으로 정의해야 한다. 예를 들어 요약 기능이라면 핵심 누락률, 분류 기능이라면 정답률, 구조화 출력이라면 스키마 준수율, 고객지원 챗봇이라면 해결률과 상담 전환율이 품질 지표가 된다. 문장이 그럴듯한지는 중요하지만, 서비스에서는 그보다 업무 성공률이 더 중요하다.

비용은 더 냉정하다. LLM 비용은 대체로 토큰 사용량에 비례한다. 입력 토큰과 출력 토큰을 따로 과금하는 경우가 많고, 보통 출력 토큰이 더 비싸다. 2026년 기준 시장 가격은 극저가 모델부터 고가 프리미엄 모델까지 차이가 매우 크며, 출력 토큰 단가는 입력보다 2~5배 비싼 경우가 흔하다.³

품질은 절대값이 아니라 바닥선이다

실무에서 가장 흔한 실수는 "제일 좋은 모델이면 제일 좋은 서비스"라고 믿는 것이다. 사실 서비스가 원하는 것은 최고 점수가 아니라 통과 점수다.

예를 들어 사내 공지 요약 기능을 생각해 보자. 요약이 약간 덜 우아해도 핵심만 빠뜨리지 않으면 충분하다. 반대로 계약서 검토 보조나 의료 상담 보조처럼 틀리면 안 되는 기능은 더 높은 품질 기준이 필요하다. 같은 LLM이라도 기능에 따라 요구 수준이 완전히 다르다.

품질을 이렇게 나눠 생각하면 판단이 쉬워진다.

• 있으면 좋은 품질: 더 자연스러운 문장, 더 멋진 표현, 더 긴 설명

• 없으면 안 되는 품질: 사실 오류 억제, 형식 준수, 핵심 정보 보존, 안전한 응답

• 비즈니스 품질: 전환율, 재사용률, 작업 시간 절감, 상담 종료율

이 구분이 중요한 이유는, 많은 기능이 최고급 모델 없이도 충분히 통과선에 도달하기 때문이다. 분류, 짧은 요약, 문장 재작성, 단순 추출, FAQ 응답 같은 작업은 작은 모델이나 중간급 모델로도 충분한 경우가 많다. 반면 다단계 추론, 긴 문서 분석, 까다로운 제약 조건이 많은 생성 작업은 상위 모델이 체감 차이를 만든다.

토큰은 돈이고, 긴 출력은 생각보다 더 비싸다

LLM 비용을 잡는 가장 현실적인 손잡이는 모델보다도 토큰 예산이다. 같은 모델을 써도 프롬프트와 출력 길이 설계에 따라 월 비용은 크게 달라진다.

대략적인 비용 계산은 이렇게 시작하면 된다.

월 비용 ≈ 요청 수 × (입력 토큰 × 입력 단가 + 출력 토큰 × 출력 단가)

문제는 서비스가 커질수록 "조금 긴 프롬프트"가 "엄청 비싼 운영 습관"으로 바뀐다는 점이다. 시스템 프롬프트가 길고, 예시가 많고, 대화 히스토리를 무심코 계속 붙이고, 출력도 장황하게 허용하면 비용과 지연 시간이 동시에 늘어난다. 프롬프트 압축, 중복 지시 제거, 응답 길이 제한은 생각보다 큰 절감 효과를 낸다. 특히 출력 토큰이 비싸기 때문에, 불필요하게 장문을 생성하지 않도록 설계하는 것이 매우 중요하다.³⁵

여기서 재미있는 역전 현상이 하나 있다. 많은 팀이 모델을 바꾸기 전에 더 비싼 모델을 먼저 붙인다. 하지만 실제로는 다음 순서가 더 자주 맞다.

1. 프롬프트를 짧고 명확하게 정리한다.

2. 응답 길이와 형식을 제한한다.

3. 그 상태에서 작은 모델로 품질을 측정한다.

4. 그래도 부족할 때만 상위 모델로 올린다.

이 순서를 지키면, "모델을 키워서 문제를 덮는" 대신 "낭비를 제거해서 문제를 줄이는" 쪽으로 갈 수 있다.

모델 선택은 고정값이 아니라 런타임 결정이다

프로덕션에서 모델 선택을 설정 파일 한 줄로 끝내면 곧 비용 보고서가 경고장을 보낸다. 요청마다 난도가 다르기 때문이다. 단순 요청까지 모두 최고급 모델로 보내는 것은 고속도로에서 전동 킥보드도 헬리콥터로 운반하는 것과 비슷하다.

그래서 실무에서는 모델 라우팅이나 계단형 모델 전략이 자주 쓰인다. 쉬운 요청은 저비용 모델, 애매한 요청은 중간급 모델, 복잡한 요청만 상위 모델로 보내는 방식이다. 이런 라우팅은 비용을 크게 줄이면서도 품질을 유지하는 데 효과적이며, 실제로 40~60% 수준의 비용 절감 사례가 자주 보고된다.⁴

간단한 기준은 이렇다.

여기에 제품 관점의 조건도 붙일 수 있다. 유료 플랜 사용자는 더 좋은 모델을, 무료 사용자는 빠르고 저렴한 모델을 기본으로 주는 식이다. 또는 실패 비용이 큰 기능만 프리미엄 모델을 쓰는 방식도 가능하다.

모델 계열별로도 대략적인 성향 차이가 있다. 일반적으로 OpenAI 계열은 범용성, 실행형 워크플로, 코딩과 도구 사용에 강점을 보이고, Claude 계열은 긴 문서와 서술 품질, 신중한 분석에 강점이 있으며, Gemini 계열은 긴 컨텍스트와 멀티모달, 검색 결합 시나리오에서 장점이 크다.⁸ 중요한 것은 "누가 최고인가"가 아니라 "내 기능에 어느 계열이 가장 잘 맞는가"다.

속도는 실제 속도와 체감 속도로 나뉜다

사용자는 벤치마크 표를 읽지 않는다. 화면을 본다. 그래서 속도는 두 종류로 관리해야 한다.

첫째는 실제 속도다. 전체 응답 시간이 짧아야 하고, 특히 P95가 너무 길어지면 서비스가 둔해진다. 둘째는 체감 속도다. 첫 토큰이 빨리 보이면 사용자는 기다릴 의향이 생긴다. 스트리밍은 전체 계산 시간을 줄이지 않아도 서비스가 훨씬 빨라 보이게 만든다.⁴

대화형 UI라면 스트리밍이 기본값에 가깝다. 반대로 사람이 즉시 읽지 않는 작업, 예를 들어 대량 분류나 야간 보고서 생성은 굳이 초저지연을 고집할 필요가 없다. 이런 경우에는 비동기 처리나 배치 처리가 더 낫다. 일부 제공자는 실시간 대신 느슨한 SLA를 받는 배치 API에 더 낮은 단가를 적용하기도 한다.⁶

이 구분이 중요하다. 같은 품질이라면 채팅 화면에서는 스트리밍이 이기고, 배치 파이프라인에서는 저렴한 배치 실행이 이긴다. 즉, 속도 목표는 기능별로 달라야 한다.

또 하나 놓치기 쉬운 점은, 긴 입력만이 속도를 늦추는 것이 아니라 긴 출력도 속도를 늦춘다는 사실이다. 프롬프트를 간결하게 하고, 필요한 만큼만 말하게 하고, 큰 작업은 더 작은 단계로 나누면 TTFT와 전체 지연 시간을 함께 줄일 수 있다.⁵

기능마다 다른 균형점을 가져가라

하나의 서비스 안에도 서로 다른 기능이 있다. 모두에게 같은 품질, 같은 속도, 같은 비용 기준을 적용하면 비효율이 생긴다.

이 표에서 핵심은, 빠른 채팅과 깊은 분석을 같은 기준으로 평가하지 않는다는 점이다. 채팅 기능은 TTFT가 생명이고, 보고서 생성은 정확성과 비용이 더 중요하다. 제품 안에서 서비스 등급을 나누는 것만으로도 의사결정이 훨씬 쉬워진다.

의사결정은 "품질 하한선 → 속도 상한선 → 비용 최소화" 순서로 한다

세 축을 동시에 최적화하려고 하면 보통 아무것도 못 고른다. 순서를 정하면 쉽다.

먼저 품질 하한선을 정한다. 예를 들어 "스키마 준수율 98% 이상", "핵심 정보 누락률 5% 이하", "사람 검수 재작업률 15% 이하"처럼 말이다. 이 기준을 통과하지 못하는 구성은 싸고 빨라도 탈락이다.

그다음 속도 상한선을 정한다. 예를 들어 채팅은 P95 5초 이하, 문장 추천은 TTFT 1초 이하, 백오피스 작업은 10분 이내 완료처럼 기능에 맞는 제한을 둔다.

마지막으로 그 둘을 모두 만족하는 후보 중 가장 싼 구성을 고른다. 실무에서 좋은 아키텍처는 대개 가장 화려한 구성이 아니라, 이 필터를 통과한 가장 단순한 구성이다.

짧게 쓰면 이런 규칙이다.

• 품질 기준을 못 넘으면 탈락

• 속도 기준을 못 넘으면 탈락

• 둘 다 넘는 후보 중 비용이 가장 낮은 것을 채택

이 방식은 감정이 아니라 측정으로 결정하게 만든다. 특히 여러 모델과 프롬프트 버전을 비교할 때 효과적이다.

관측 없이는 최적화도 없다

비용, 속도, 품질의 균형은 감으로 유지되지 않는다. 요청마다 어떤 모델이 쓰였고, 입력·출력 토큰이 얼마였고, 응답 시간이 얼마나 걸렸는지 기록해야 한다. 여기에 기능 이름, 사용자 플랜, 엔드포인트, 프롬프트 버전을 함께 붙이면 "어디서 돈이 새고 어디서 느려지는지"가 보인다.²⁷

특히 유용한 질문은 다음과 같다.

• 어떤 기능이 가장 많은 토큰을 먹는가?

• 어떤 모델이 P95를 가장 악화시키는가?

• 어떤 프롬프트 버전에서 출력 토큰이 갑자기 늘었는가?

• 어떤 사용자군에서 고급 모델 사용 비율이 과도한가?

이 데이터가 있어야 모델 다운그레이드도, 업그레이드도, 프롬프트 수정도 자신 있게 할 수 있다. 관측 없이 최적화하겠다는 말은 연료계 없는 자동차로 장거리 운전하겠다는 말과 비슷하다.

실전 예시 세 가지

고객지원 FAQ 챗봇

이 경우 가장 중요한 것은 체감 속도와 비용이다. 대부분의 질문은 반복적이고 구조가 단순하다. 작은 모델이나 중간 모델로 시작하고, 답변이 애매하거나 정책 충돌이 감지될 때만 상위 모델로 올리는 편이 낫다. 응답은 짧게, 스트리밍으로 시작하면 사용자 만족도는 올라가고 비용은 내려간다.

계약서 요약 및 위험 조항 표시

여기서는 속도보다 품질이 우선이다. 핵심 누락은 곧 사고가 될 수 있다. 긴 문맥을 다뤄야 하므로 컨텍스트 관리가 중요하고, 상위 모델이나 긴 문서 처리에 강한 모델이 유리하다. 다만 전체 문서를 무조건 한 번에 던지는 대신, 섹션 단위 분해와 구조화 출력을 함께 쓰면 비용을 줄이면서 품질을 지킬 수 있다.

야간 리포트 생성 파이프라인

사람이 기다리는 화면이 아니므로 저지연 집착은 낭비다. 배치 처리, 비동기 큐, 저비용 모델 조합이 맞는다. 이 경우 속도 목표는 "몇 초"가 아니라 "업무 시작 전 완료"다. 품질이 충분하다면 가장 비싼 모델은 오히려 운영 효율을 해친다.

흔한 실수

첫째, 전 기능에 최고급 모델을 붙인다. 초기에는 편하지만, 나중에는 비용 때문에 기능 확장이 막힌다.

둘째, 프롬프트에 계속 문장을 덧붙인다. 설명을 추가할수록 품질이 올라갈 것 같지만, 실제로는 중복 지시와 긴 문맥 때문에 비용과 지연만 늘고 오히려 모델이 헷갈리는 경우도 많다.

셋째, 평균 지연 시간만 본다. 평균은 멀쩡한데 P95가 무너져서 실제 사용자는 계속 답답해한다.

넷째, 모든 기능에 같은 SLA를 적용한다. 채팅과 배치는 다른 스포츠다. 단거리 육상 선수에게 마라톤 기록을 요구하면 둘 다 망친다.

다섯째, 비용 절감만 보고 모델을 내린다. 품질 평가 없이 모델만 바꾸면 고객 불만이 조용히 쌓인다. 절감은 숫자로 보이지만, 손실은 종종 늦게 보인다.

결국 중요한 것은 "충분히 좋은 답"을 "지속 가능한 가격"으로 내는 일이다

LLM 서비스의 경쟁력은 가장 비싼 모델을 쓰는 데서 나오지 않는다. 오히려 반대다. 작업별 품질 하한선을 정확히 정하고, 그 선을 넘는 가장 가볍고 빠른 구성을 찾는 팀이 오래 이긴다.

좋은 팀은 모델을 숭배하지 않는다. 대신 기능을 나누고, 지표를 세우고, 예산을 관리하고, 라우팅과 출력 제어와 운영 관측을 통해 균형점을 만든다. 그 균형점이 바로 프로덕션 감각이다. 화려한 데모는 큰 모델이 만들 수 있지만, 오래 살아남는 서비스는 대개 더 차분한 판단이 만든다.

참고

¹Key metrics for LLM inference

²LLM Latency & Performance Monitoring: Complete Guide

³LLM API Pricing Comparison & Cost Guide (Apr 2026)

⁴5 Ways to Optimize Costs and Latency in LLM-Powered Applications

⁵Latency optimization - OpenAI API

⁶LLM Integration in Production: Latency, Cost, and Reliability Patterns

⁷Log token usage, prompts, and completions for LLM APIs

⁸ChatGPT vs Claude vs Gemini: Which AI Is Best in 2026?