이 문서를 통해 아래 질문들에 답할 수 있게 됩니다.
- AI 기능에서 비용, 지연시간, 품질은 왜 서로 충돌하는가?
- 요청 위험도별로 모델과 context를 어떻게 다르게 라우팅하는가?
- 개인 프로젝트와 기업 운영에서 비용 제한은 어떻게 달라지는가?
- fallback과 prompt caching은 어떤 조건에서 도움이 되는가?
개요
AI 기능은 비용, 지연시간, 품질을 동시에 최대로 만족시키기 어렵다. 좋은 모델은 비싸고 느릴 수 있고, 긴 context는 품질을 올릴 수 있지만 비용과 latency를 늘린다. 작은 모델은 빠르고 저렴하지만 복잡한 추론에서 실패할 수 있다.
실전에서는 모든 요청에 같은 모델과 같은 context를 쓰지 않는다. 요청 유형과 위험도에 따라 다르게 라우팅한다.
핵심 원리
세 가지 축을 함께 본다.
- 비용: token, 모델 단가, retry, eval, embedding, vector search
- 지연시간: provider latency, context 길이, streaming, queue, reranker
- 품질: 정확도, 근거성, schema 준수, 안전성, 일관성
어떤 축을 우선할지는 기능의 업무 가치와 위험도에 따라 달라진다.
요청 유형별 전략
| 유형 | 우선순위 | 전략 |
|---|---|---|
| 실시간 채팅 | 지연시간 | streaming, 작은 모델, 짧은 context |
| 고객 답변 생성 | 품질 | RAG, source, eval, human review |
| 내부 초안 생성 | 비용 | 저렴한 모델, batch, 후편집 |
| 정책 분류 | 일관성 | structured output, 낮은 temperature |
| 장애 분석 | 품질 | 긴 context, 고성능 모델, trace source |
| 대량 요약 | 비용 | queue, batch, output limit |
Model Routing
모든 요청에 최고 모델을 쓰지 않는다. 간단한 분류는 작은 모델, 고위험 판단은 큰 모델을 쓴다.
def choose_model(*, task_type: str, risk_level: str, input_tokens: int) -> str:
if risk_level == "high":
return "quality-reasoning"
if task_type == "classification" and input_tokens < 1000:
return "fast-cheap"
if input_tokens > 12000:
return "long-context"
return "balanced"내부 model profile을 쓰면 provider model 이름이 바뀌어도 서비스 로직을 덜 바꾼다.
Context Budget
품질이 낮다고 context를 무작정 늘리지 않는다.
- 관련 없는 chunk가 늘면 모델이 헷갈린다.
- 최신 문서와 오래된 문서가 충돌할 수 있다.
- input token 비용이 늘어난다.
- prompt caching 효율이 떨어질 수 있다.
context budget은 retrieval 품질, reranking, source freshness와 함께 조정해야 한다.
Fallback 판단
fallback은 가용성을 높인다. 그러나 fallback model은 품질, 비용, schema 준수율이 다를 수 있다.
fallback 전 확인:
- 같은 schema를 지키는가?
- 같은 안전 정책을 가지는가?
- latency와 비용이 어떤가?
- eval 기준을 통과했는가?
- 사용자에게 품질 저하를 알릴 필요가 있는가?
fallback은 장애 때 처음 켜는 기능이 아니라 평소에 테스트된 경로여야 한다.
장애 상황과 대응
비용과 latency가 동시에 증가하면 retry와 context 증가를 의심한다. 품질이 낮아져 고성능 모델로 바꿨더니 비용이 터지는 경우도 흔하다.
대응 순서:
- usage를 feature와 prompt version별로 본다.
- token 길이와 latency 상관관계를 본다.
- retrieval 품질을 eval한다.
- 작은 모델이 가능한 요청을 분리한다.
- output limit과 cache 구조를 조정한다.
인프라 협업 포인트
인프라팀과는 budget과 SLO를 숫자로 이야기한다.
- P95 latency 목표
- 요청당 최대 token
- tenant별 월간 token budget
- provider별 rate limit
- queue depth 한계
- fallback 사용률 알림
“AI가 느려요”보다 “document_qa P95가 12초를 넘고 input token P95가 9천입니다”가 훨씬 좋은 대화다.
개인 프로젝트 최소 기준
- max output token을 둔다.
- 요청당 context 개수를 제한한다.
- 간단한 usage log를 남긴다.
- 고품질 모델과 저비용 모델을 구분해 써 본다.
기업 운영 수준 기준
- model routing policy를 문서화한다.
- tenant quota와 budget alert를 둔다.
- fallback model을 eval한다.
- 비용, latency, quality 지표를 함께 본다.
- prompt cache hit rate를 추적한다.
실전 팁
- 비용 최적화는 모델 단가보다 token 길이와 retry부터 본다.
- 품질 문제는 모델 교체 전에 retrieval과 schema 실패를 확인한다.
- latency 문제는 streaming과 queue 중 무엇이 맞는지 구분한다.
- 높은 품질이 필요한 요청만 비싼 모델로 보낸다.
위험 신호!
- 모든 기능이 같은 모델을 쓴다.
- tenant별 비용 제한이 없다.
- fallback model을 eval하지 않았다.
- context를 많이 넣는 것으로 품질을 해결한다.
- latency와 token 지표를 연결해서 보지 않는다.
확인 질문
확인 질문
- AI 기능에서 비용과 품질이 충돌하는 대표 상황은 무엇인가?
- 더 좋은 모델과 더 긴 context를 쓰면 품질은 좋아질 수 있지만 비용과 latency가 증가하는 상황이다.
- fallback model을 운영에 쓰기 전 확인해야 할 것은 무엇인가?
- schema 준수, 품질 eval, 비용, latency, 안전 정책 차이를 확인해야 한다.