느린 AI 기능은 똑똑하게 느껴지지 않습니다. 고장 난 것처럼 느껴집니다.

이것은 많은 AI SaaS 빌더들이 데모가 성공한 이후에 맞닥뜨리는 불편한 진실입니다. 프로토타입은 답변을 잘하고, 에이전트(Agent)는 도구를 호출할 수 있으며, RAG 파이프라인은 인상적으로 보입니다. 그러다 실제 사용자들이 유입됩니다. 프롬프트(Prompt)는 길어집니다. 대기열(Queue)이 형성됩니다. 스트리밍(Streaming)이 늦게 시작됩니다. 어떤 테넌트(Tenant)는 거대한 문서를 업로드합니다. 다른 테넌트는 정오에 대량 작업을 실행합니다. 갑자기 테스트 단계에서 마법처럼 느껴졌던 동일한 워크플로우가, 청구서가 첨부된 로딩 스피너처럼 느껴지게 됩니다.

해결책은 단순히 "더 빠른 모델을 사용하는 것"이 아닙니다. 당신에게는 **LLM 지연 시간 예산 (LLM latency budget)**이 필요합니다. 이는 각 AI 워크플로우가 얼마나 빠르게 느껴져야 하는지, 얼마나 많은 토큰을 사용할 수 있는지, 언제 스트리밍할지, 언제 캐싱(Caching)할지, 언제 다른 모델로 라우팅(Routing)할지, 그리고 비용과 지연 시간이 함께 드리프트(Drift)되기 전에 언제 멈춰야 하는지를 규정하는 일련의 작은 규칙들입니다.

이 가이드는 LLM API, RAG, 에이전트(Agents) 또는 자체 호스팅 모델을 사용하여 프로덕션 기능을 출시하는 1인 SaaS 개발자, 마이크로 SaaS 빌더, 그리고 AI SaaS 팀을 위한 것입니다.

왜 지금 지연 시간 예산이 중요한가

AI 플랫폼 뉴스는 모두 같은 방향을 가리키고 있습니다. 빌더들이 채팅 데모에서 프로덕션 워크플로우로 이동하고 있다는 것입니다. 에이전트 도구, 웹 컨텍스트 API, 음성 에이전트, 코딩 어시스턴트, 그리고 RAG 플랫폼은 모두 점점 더 유능해지고 있습니다. 동시에 추론(Inference) 비용과 신뢰성은 압박을 받고 있습니다.

이제 지연 시간(Latency)은 제품 지표(Product metric)입니다. 추론 효율성(Inference efficiency)은 비즈니스 지표(Business metric)가 되고 있습니다. 하지만 많은 기사들이 TTFT, TPOT, 양자화(Quantization), 배치(Batching) 또는 모델 서빙(Model serving) 단계에서 멈춥니다. SaaS 빌더가 이러한 아이디어들을 코드, 대시보드, 폴백(Fallbacks), 그리고 고객 안전 한계치를 갖춘 제품 수준의 예산으로 어떻게 전환하는지를 보여주는 경우는 드뭅니다.

단순한 모델: TTFT, TPOT, 그리고 총 소요 시간

시작하기 위해 서빙 시스템(Serving systems)에 대한 박사 학위가 필요하지는 않습니다. 세 가지 숫자만 추적하세요.

첫 번째 토큰까지의 시간 (Time to First Token)

**첫 번째 토큰까지의 시간 (Time to First Token, TTFT)**은 사용자 작업과 첫 번째 스트리밍된 토큰 사이의 지연 시간입니다. 여기에는 네트워크 시간, 대기열 시간, 제공업체 오버헤드(Provider overhead), 도구 설정, 검색(Retrieval), 그리고 모델의 프리필(Prefill) 단계가 포함됩니다.

TTFT가 높으면 채팅창이 죽어 있는 것처럼 느껴집니다.

출력 토큰당 시간 (Time Per Output Token)

**출력 토큰당 시간 (Time Per Output Token, TPOT)**은 첫 번째 토큰이 나타난 이후 생성된 토큰들 사이의 평균 시간입니다.

TPOT가 높으면 스트리밍 (streaming)이 마치 물이 뚝뚝 떨어지는 수도꼭지처럼 느껴집니다.

엔드투엔드 지연 시간 (End-to-end latency)

**엔드투엔드 지연 시간 (End-to-end latency)**은 요청부터 최종 답변까지 걸리는 전체 시간입니다.

대략적인 공식은 다음과 같습니다:

end_to_end_latency = TTFT + (output_tokens - 1) * TPOT

이 공식이 모든 제공업체(provider)에 완벽하게 들어맞는 것은 아니지만, 사용자 경험 (user experience)을 추론하기에는 충분히 유용합니다.

모델이 아닌 워크플로(workflow)별로 예산을 수립하세요

흔히 하는 실수는 “AI 응답은 5초 이내에 완료되어야 한다”와 같이 하나의 전역적인 목표를 설정하는 것입니다. 이는 깔끔하게 들릴지 모르지만 빠르게 실패합니다.

워크플로마다 서로 다른 예산이 필요합니다.

핵심은 원시 모델 호출 (raw model call)이 아니라 **경험 (experience)**을 위해 예산을 책정하는 것입니다.

사용자는 UI가 현재 무엇이 일어나고 있는지 알려준다면 40초가 걸리는 백그라운드 보고서도 용서할 수 있습니다. 하지만 아무것도 나타나지 않는다면, 동일한 사용자가 6초짜리 인라인 글쓰기 어시스턴트를 바로 포기할 수도 있습니다.

실용적인 LLM 지연 시간 예산 템플릿

각 AI 워크플로에 대해 예산 객체 (budget object)를 생성하세요.

{
  "workflow": "support_rag_answer",
  "max_ttft_ms": 2500,
...

이렇게 하면 “더 빠르게 만들어라”라는 모호한 요구사항이 엔지니어링 제약 조건 (engineering constraints)으로 변합니다. 이제 여러분의 앱은 컨텍스트 (context)를 줄일지, 스트리밍 (stream)을 할지, 더 빠른 모델로 라우팅 (route)할지, 비동기 (async)로 전환할지, 너무 큰 요청을 거부할지, 아니면 캐시된 답변 (cached answer)을 사용할지를 결정할 수 있습니다.

모든 요청을 계측 (Instrument)하세요

다른 도구를 구매하거나 제공업체를 변경하기 전에, 모든 AI 요청에 대해 지연 시간과 토큰 데이터를 로깅 (logging)하는 것부터 시작하세요.

다음은 간단한 TypeScript 스타일의 예시입니다.

type LlmTrace = {
  requestId: string;
  tenantId: string;
...

트레이스 (trace)는 단순하게 유지하세요. 요청 ID (request ID), 테넌트 ID (tenant ID), 워크플로 (workflow), 모델 (model), 토큰 (tokens), TTFT, 총 시간 (total time), 비용 (cost), 캐시 히트 (cache hit), 그리고 상태 (status)를 캡처한다면, 초기 성능에 관한 대부분의 질문에 답할 수 있습니다.

인프라를 건드리기 전에 입력 토큰을 제어하세요

긴 프롬프트 (Long prompts)는 TTFT (Time To First Token)를 저해합니다. 컨텍스트 (context)가 길다는 것은 첫 번째 토큰이 나타나기 전까지 더 많은 작업이 필요함을 의미합니다.

AI SaaS 제품의 경우, 입력 데이터의 팽창 (input bloat)은 대개 전체 채팅 기록, 너무 많은 RAG 청크 (chunks), 가공되지 않은 HTML, 사용되지 않는 도구 설명 (tool descriptions), 반복되는 시스템 지침 (system instructions), 또는 단 몇 개의 필드만 중요함에도 불구하고 고객 기록 전체를 포함하는 경우에서 발생합니다. GPU를 최적화하거나 벤더 (vendor)를 교체하기 전에, 불필요한 컨텍스트를 제거하세요.

컨텍스트 패커 (context packer)를 사용하세요.

type ContextItem = {
  id: string;
  text: string;
...

이것은 화려한 기술이 아닙니다. 바로 그것이 핵심입니다. 기본적인 우선순위 기반 패커 (priority-based packer)가 종종 "모든 것을 보내고 운에 맡기기"보다 더 나은 성능을 보여줍니다.

RAG의 경우, 더 적지만 더 나은 청크 (chunks)를 사용하세요. 에이전트 (agents)의 경우, 단계당 노출되는 도구 (tools)의 수를 줄이세요. 브라우저 자동화 (browser automation)의 경우, 페이지를 프롬프트에 넣기 전에 정제하세요.

작업 유형별로 출력 토큰 (output tokens) 제한하기

출력 토큰은 전체 지연 시간 (latency)과 비용을 결정합니다. 많은 AI 기능은 긴 답변을 필요로 하지 않습니다.

워크플로 (workflow)별로 출력 제한을 설정하세요:

• 재작성 제안 (Rewrite suggestion): 120 토큰
• 오류 설명 (Error explanation): 250 토큰
• 지원 답변 (Support answer): 700 토큰
• 기술 계획 (Technical plan): 1,200 토큰
• 배경 보고서 (Background report): 더 큰 제한을 가진 비동기 작업 (async job)

또한 모델이 횡설수설하지 않도록 구조를 제공하세요.

다음 형식으로 답변하세요:
1. 직접적인 답변: 최대 2문장
2. 단계: 최대 5개의 불렛 포인트
...

이렇게 하면 가독성 (scannability)이 향상되고 토큰 드리프트 (token drift)를 줄일 수 있습니다.

스트리밍 (Streaming)은 임시방편이 아니라 인지 성능을 위해 사용하세요

스트리밍은 AI 기능이 더 빠르게 느껴지게 할 수 있지만, 모든 것을 해결해주지는 않습니다.

스트리밍을 사용해야 하는 경우:

• 사용자가 생성된 텍스트를 읽고 있는 경우
• 답변에 2초 이상 소요될 수 있는 경우
• 부분적인 출력 (partial output)이 유용한 경우
• 초안이 시작된 후 인용 (citations)이나 도구 결과 (tool results)를 보여줄 수 있는 경우

스트리밍에 의존해서는 안 되는 경우:

• 워크플로가 유효한 JSON을 반환해야 하는 경우
• 사용자에게 단일한 결정론적 결과 (deterministic result)가 필요한 경우
• 모델이 무언가를 말하기 전에 도구 호출 (tool calls)을 완료해야 하는 경우
• 모델이 시작되기 전의 느린 검색 (retrieval) 또는 데이터베이스 단계를 숨기려는 경우

에이전트 워크플로의 경우, 텍스트뿐만 아니라 **상태 이벤트 (status events)**를 스트리밍하세요.

{ "type": "status", "message": "관련 문서 검색 중" }
{ "type": "status", "message": "계정 권한 확인 중" }
{ "type": "status", "message": "인용구를 포함한 답변 초안 작성 중" }

이렇게 하면 시스템이 실제 작업을 수행하는 동안 사용자가 현재 진행 상황을 파악할 수 있습니다.

지연 시간 클래스(latency class)별 모델 라우팅

모든 요청에 가장 강력한 모델을 사용할 필요는 없습니다.

지연 시간 클래스를 생성하세요:

단순한 라우터(router)는 규칙(rules)으로 시작할 수 있습니다.

function chooseModel(workflow: string, risk: "low" | "medium" | "high") {
  if (workflow === "autocomplete") return "small-fast";
  if (workflow === "bulk_report") return "batch-careful";
...

나중에 측정된 성능, 테넌트(tenant) 플랜, 큐 깊이(queue depth) 또는 실패율을 기반으로 라우팅할 수 있습니다. 개발자가 이해하고 디버깅할 수 있는 규칙부터 시작하세요.

지루한 부분은 캐싱(Cache)하기

캐싱(Caching)은 지연 시간과 비용을 모두 개선할 수 있는 가장 쉬운 방법 중 하나이지만, 올바른 대상을 캐싱해야 합니다.

좋은 캐싱 후보:

• 변경되지 않은 문서에 대한 임베딩 (Embeddings)
• 일반적인 쿼리에 대한 RAG 검색 결과
• 시스템 프롬프트 템플릿 (System prompt templates)
• 도구 스키마 (Tool schemas)
• 분류 출력값 (Classification outputs)
• 결정론적 변환 (Deterministic transformations)
• 위험도가 낮고 반복되는 질문에 대한 답변

나쁜 캐싱 후보:

• 테넌트 범위 지정(tenant scoping)이 없는 권한 민감형 답변
• 사용자 범위 지정(user scoping)이 없는 개인화된 답변
• 빠르게 변하는 데이터에 기반한 답변
• 오래된 가격, 정책 또는 계정 상태를 포함할 수 있는 출력값

캐시 키(cache keys)에는 항상 테넌트 및 권한 컨텍스트를 포함하세요.

function cacheKey(input: {
  tenantId: string;
  userRole: string;
...

데이터를 유출하는 캐시 히트(cache hit)는 캐시가 없는 것보다 더 나쁩니다.

우아한 성능 저하 (Graceful degradation) 추가

앱에는 최악의 상황에 대비한 계획이 필요합니다: 제공업체의 속도 저하, 큐 급증(queue spikes), 긴 문서 또는 테넌트가 대규모 작업을 실행하는 경우 등입니다.

유용한 성능 저하 패턴:

• 저위험 요청(low-risk requests)의 경우 정교한 모델에서 빠른 모델로 전환
• TTFT(Time To First Token)가 위험할 때 검색된 청크(retrieved chunks) 수 줄이기
• 부하 급증(load spikes) 시 출력 길이(output length) 단축
• 긴 작업은 비동기 작업(async jobs)으로 이동
• "계속 생성하기(continue generating)"를 통해 부분적인 결과 보여주기
• 토큰을 소모하기 전에 사용자에게 요청 범위를 좁히도록 요청

예시:

if (queueDepth > 100 && workflow === "support_rag_answer") {
  budget.max_input_tokens = 6000;
  budget.max_output_tokens = 500;
...

이는 모든 곳에서 품질을 낮추는 것에 관한 것이 아닙니다. 압박 상황 속에서 사용자 경험을 보호하는 것에 관한 것입니다.

평균이 아닌 p95를 주시하세요

평균 지연 시간(Average latency)은 거짓말을 합니다. 실제 사용자들이 고통받는 동안에도 여러분의 해피 패스(happy path)는 괜찮아 보일 수 있습니다.

워크플로(workflow) 및 테넌트 티어(tenant tier)별로 다음 지표를 추적하세요:

• p50 TTFT
• p95 TTFT
• p50 전체 지연 시간(total latency)
• p95 전체 지연 시간(total latency)
• 요청당 입력 토큰(input tokens per request)
• 요청당 출력 토큰(output tokens per request)
• 캐시 히트율(cache hit rate)
• 타임아웃 비율(timeout rate)
• 성공적인 작업당 비용(cost per successful task)
• 요청당 재시도 횟수(retries per request)

처음에는 간단한 경고 규칙(alert rule)만으로도 충분합니다.

support_rag_answer의 p95 TTFT가 10분 동안 3000ms를 초과하면 경고.
성공적인 작업당 비용이 7일 기준선(baseline)보다 30% 상승하면 경고.
유료 테넌트 티어 중 어느 하나라도 타임아웃 비율이 2%를 초과하면 경고.

지연 시간을 비용과 연결하세요. p95 지연 시간과 비용이 모두 상승한다면, 컨텍스트 팽창(context bloat), 재시도 루프(retry loops), 잘못된 라우팅(poor routing), 또는 비동기로 전환해야 하는 워크플로가 원인일 수 있습니다.

재시도를 예산 위험으로 취급하세요

재시도는 코드상에서는 무해해 보이지만, 프로덕션 환경에서는 비용이 많이 듭니다.

재시도는 비용을 두 배로 늘리고, 지연 시간을 증가시키며, 중복된 도구 액션(tool actions)을 생성할 수 있습니다. 에이전트(agents)의 경우, 모델이 도구를 다시 호출할 수 있기 때문에 재시도 루프는 훨씬 더 위험합니다.

재시도 규칙을 사용하세요:

• 지터(jitter)를 포함하여 네트워크 오류 재시도
• 유효성 검사 실패(validation failures)를 맹목적으로 재시도하지 말 것
• 멱등성 키(idempotency keys) 없이 쓰기 작업(write actions)을 절대 재시도하지 말 것
• 적은 횟수의 시도 후에 중단할 것
• 재시도 이유와 추가된 비용을 기록(log)할 것

const retryPolicy = {
  maxAttempts: 2,
  retryOn: ["rate_limit", "network_timeout"],
...

만약 워크플로 (workflow)가 신뢰성을 확보하기 위해 세 번의 재시도 (retry)를 필요로 한다면, 그것은 더 큰 재시도 루프 (retry loop)가 필요한 것이 아니라 더 나은 설계가 필요한 것입니다.

채팅 대신 비동기 (async)를 사용해야 할 때

어떤 AI 작업은 즉각적인 것처럼 보일 필요가 없습니다.

다음과 같은 경우에는 비동기 (async) 작업을 사용하세요:

• 대규모 문서 분석 (Large document analysis)
• 다중 소스 조사 (Multi-source research)
• 긴 에이전트 워크플로 (Long agent workflows)
• 대량 데이터 보강 (Bulk enrichment)
• 보고서 생성 (Report generation)
• 평가 실행 (Evaluation runs)
• 외부 API 속도 제한 (rate limits)이 있는 작업

좋은 비동기 (async) UX에는 다음이 포함됩니다:

• 즉각적인 작업 접수
• 진행 상황 업데이트
• 취소 버튼
• 예상 완료 시간대
• 최종 요약
• 발생한 상황을 설명하는 에러 상태 (Error state)

이를 통해 채팅 인터페이스가 대기실로 변하는 것을 방지할 수 있습니다.

구현 체크리스트

새로운 AI 기능을 출시하기 전에 다음 사항을 확인하세요:

• 워크플로별 최대 TTFT (Time To First Token) 및 총 지연 시간 (total latency) 정의
• 입력 및 출력 토큰 제한 (token caps) 설정
• 테넌트 (tenant), 워크플로 (workflow), 모델 (model), 토큰 (tokens), 비용 (cost), TTFT, 총 시간 (total time), 상태 (status) 로그 기록
• 평균값뿐만 아니라 p95 지연 시간 (p95 latency) 추적
• 유용한 경우 텍스트 또는 상태 이벤트 스트리밍 (Stream)
• 워크플로 및 위험도에 따른 모델 라우팅 (Route)
• 테넌트 인지 키 (tenant-aware keys)를 사용하여 안전하고 반복적인 작업 캐싱 (Cache)
• 인프라를 변경하기 전에 컨텍스트 (context) 다듬기
• 긴 작업을 비동기 (async) 작업으로 이동
• 지연 시간 (latency), 타임아웃 비율 (timeout rate), 재시도 비율 (retry rate), 성공적인 작업당 비용 (cost per successful task)에 대한 알림 설정

마지막 생각

LLM 지연 시간 예산 (latency budget)은 관료주의가 아닙니다. 그것은 제품 품질을 위한 가드레일 (guardrail)입니다.

예산이 없으면 모든 프롬프트 (prompt)가 커질 수 있고, 모든 에이전트 (agent)가 방황할 수 있으며, 모든 재시도 (retry)가 비용을 두 배로 만들 수 있고, 모든 느린 요청이 미스터리처럼 보일 수 있습니다. 예산이 존재할 때, 팀은 명확한 트레이드오프 (tradeoffs)를 할 수 있습니다: 더 빠른 첫 토큰 (first token), 더 짧은 출력 (output), 더 나은 컨텍스트 (context), 더 안전한 캐시 (cache), 비동기 (async) 워크플로, 또는 중요한 곳에만 더 강력한 모델을 사용하는 것 말입니다.

빠른 AI는 단순히 속도에 관한 것이 아닙니다. 그것은 마진 (margins)을 보호하면서 사용자의 시간을 존중하는 것에 관한 것입니다.

FAQ

LLM 지연 시간 예산 (LLM latency budget)이란 무엇인가요?

LLM 지연 시간 예산 (LLM latency budget)은 AI 워크플로우 (workflow)에 대한 일련의 제한 사항입니다: 첫 번째 토큰 생성 시간 (TTFT, time to first token) 최대치, 최대 총 응답 시간, 입력 토큰 제한 (input token cap), 출력 토큰 제한 (output token cap), 모델 경로 (model route), 캐싱 규칙 (caching rule), 그리고 폴백 동작 (fallback behavior) 등이 포함됩니다.

AI 기능을 위한 좋은 TTFT란 무엇인가요?

워크플로우 (workflow)에 따라 다릅니다. 인라인 제안 (inline suggestions)은 거의 즉각적으로 느껴져야 합니다. 채팅 답변 (chat answers)은 보통 1~2초 이내에 스트리밍 (streaming)이 시작되어야 합니다. RAG 또는 에이전트 (agent) 워크플로우는 UI가 유용한 진행 상황을 보여준다면 더 오래 걸려도 괜찮습니다.

LLM 지연 시간을 빠르게 줄이는 방법은 무엇인가요?

입력 토큰 (input tokens)을 줄이고, 출력 길이 (output length)를 제한하며, 응답을 스트리밍 (streaming)하고, 반복되는 작업을 캐싱 (caching)하며, 간단한 작업은 더 빠른 모델로 라우팅 (routing)하는 것부터 시작하세요. 이러한 변경 사항은 인프라 (infrastructure)를 변경하는 것보다 훨씬 쉬운 경우가 많습니다.

모든 AI 워크플로우가 출력을 스트리밍해야 하나요?

아니요. 스트리밍 (streaming)은 읽기 쉬운 텍스트나 진행 상황 업데이트에는 효과적입니다. 하지만 엄격한 JSON 형식, 숨겨진 도구 호출 (tool-call) 워크플로우, 또는 부분적인 출력이 사용자를 혼란스럽게 할 수 있는 작업에는 덜 유용합니다.