LLM 응답 지연을 사용자 경험과 SLO로 관리하는 법

30초 답변

LLM 서비스의 속도는 “평균 몇 초”가 아니라 요청 접수, 첫 진행 상태, 첫 유용한 결과, 최종 완료까지를 분리해 측정해야 한다. 업무 유형별로 p95 SLO를 두고 모델, 검색, Tool, 큐, 승인, 프런트엔드 구간을 같은 trace에서 비교해야 병목을 찾을 수 있다.

Streaming은 첫 글자를 빨리 보여주지만 전체 작업을 빠르게 하지는 않는다. 사용자가 기다릴 이유를 이해하고 취소·부분 결과·백그라운드 완료를 선택할 수 있게 만드는 것이 실제 속도 최적화와 같은 수준으로 중요하다.

이 글의 핵심

• 평균 latency 하나로는 느린 사용자의 경험과 병목 구간을 볼 수 없다.
• 대화, 조회, 보고서 생성, 외부 실행은 서로 다른 SLO가 필요하다.
• Streaming, 진행 상태, 취소, 비동기 완료는 하나의 UX 패턴으로 설계한다.

latency를 한 숫자로 보면 생기는 문제

한 요청의 전체 시간은 여러 구간의 합이다.

1. 브라우저와 API gateway
2. 큐 대기
3. 의도 분류
4. retrieval과 reranking
5. 모델의 첫 token
6. 모델의 전체 생성
7. Tool 호출과 재시도
8. 승인 대기
9. 결과 검증과 렌더링

전체가 12초라는 사실만으로는 무엇을 고쳐야 하는지 알 수 없다. 모델을 바꿨지만 실제 병목이 사내 ERP API라면 비용만 늘어난다.

네 개의 사용자 시간

요청 접수 시간

클릭 후 시스템이 요청을 받았다고 알려주는 시간이다. 네트워크나 큐가 길어도 즉시 접수 상태를 보여주면 중복 클릭을 줄일 수 있다.

첫 진행 표시 시간

무슨 일을 시작했는지 보여주는 시간이다. “답변 생성 중”보다 “정책 문서 검색 중”, “주문 시스템 조회 중”처럼 실제 단계가 낫다. 내부 사고 과정을 그대로 노출할 필요는 없다.

첫 유용한 결과 시간

첫 token이 아니라 사용자가 판단에 쓸 수 있는 결과가 나온 시간이다. 제목만 스트리밍되는 것과 첫 근거·첫 행·첫 요약이 보이는 것은 다르다.

최종 완료 시간

검증, Tool 실행, 저장까지 끝난 시간이다. 사용자가 창을 닫아도 계속되는 작업이라면 완료 알림과 결과 보관 위치가 필요하다.

업무 유형별 SLO

모든 요청에 같은 목표를 적용하지 않는다.

SLO 값은 실제 사용자 연구와 현재 성능 기준으로 정한다. 이 글에서 보편적인 초 단위를 제시하지 않는 이유는 업무 위험과 기대가 다르기 때문이다.

평균보다 p95를 우선한다. 평균이 좋아도 특정 지역, 큰 문서, 복잡한 Tool에서 느린 사용자가 반복되면 제품 신뢰가 무너진다.

Streaming의 역할과 한계

OpenAI의 latency 최적화 가이드는 적은 token 생성, 더 적은 요청, 병렬화, streaming 같은 기본 전략을 설명한다. Streaming은 사용자가 결과를 일찍 읽게 하지만 다음을 해결하지 못한다.

• retrieval이 끝나기 전의 긴 정적 대기
• Tool이 언제 끝날지 모르는 상태
• 생성 후 검증·저장에 걸리는 시간
• 중간 오류로 전체 결과가 무효가 되는 상황

따라서 streaming과 함께 단계 상태, 취소, retry, 부분 결과의 유효성 표시가 필요하다.

속도를 줄이는 아키텍처 순서

1. 불필요한 단계를 없앤다

모든 질문을 RAG, 고급 모델, 여러 Agent에 보내지 않는다. 규칙으로 해결되는 요청, 캐시 가능한 조회, 단순 형식 변환을 분리한다.

2. 의존하지 않는 작업을 병렬화한다

권한 정보와 문서 검색, 여러 독립 Tool 조회처럼 서로 결과에 의존하지 않는 작업은 병렬 실행을 검토한다. 단, 같은 쓰기 작업을 병렬 실행해 충돌시키면 안 된다.

3. 작은 모델과 큰 모델의 역할을 분리한다

분류·형식 검사와 복잡한 분석을 같은 모델에 맡길 필요가 없다. 모델 routing은 품질 평가셋과 fallback을 함께 둔다.

4. 입력과 출력을 줄인다

검색 문서를 무제한 넣지 않고 관련성을 평가한다. 사용자가 필요로 하는 형식보다 긴 답을 기본 생성하지 않는다. “간단히”만 prompt에 쓰는 대신 출력 schema와 길이 정책을 둔다.

5. cache와 precompute를 사용한다

변경이 드문 정책 요약, 동일 embedding, 반복 retrieval은 version-aware cache 후보가 된다. 권한과 최신성을 cache key와 무효화 정책에 포함한다.

6. 긴 작업을 비동기로 전환한다

브라우저 연결을 오래 붙잡기보다 job ID, 상태, 취소, 완료 알림을 제공한다. 재접속해도 상태를 복구할 수 있어야 한다.

실패 UX가 속도 UX다

사용자가 가장 오래 기다리는 경우는 실패가 늦게 드러날 때다.

• 30초 후 권한 없음
• 긴 생성 후 schema 오류
• Tool 재시도를 여러 번 한 뒤 처음부터 재입력
• 취소했는데 실제 외부 작업은 실행

권한과 입력 형식은 가능한 앞에서 확인한다. 재시도 한도를 두고, 마지막 성공 checkpoint부터 이어갈 수 있게 한다. 실패 시 사용자가 수정할 항목과 보존된 작업을 명확히 보여준다.

Microsoft HAX 지침은 시스템 능력과 한계를 알리고, 불확실할 때 범위를 좁히며, 오류를 쉽게 수정·무시·복구하도록 권한다. 진행 상태는 장식이 아니라 이 원칙의 구현이다.

측정 대시보드

업무 유형과 release ID별로 다음을 본다.

• request accepted
• time to first status
• time to first useful result
• time to final completion
• p50·p95·p99
• 모델·retrieval·Tool·큐 구간
• 취소율과 실제 중단 성공률
• retry와 timeout
• 완료 후 사용자 수정·재질문
• 작업당 비용

latency가 줄었지만 정답률이나 사용자 완료율이 낮아지면 성공으로 보지 않는다.

실무 체크리스트

• 요청 접수, 첫 상태, 첫 유용 결과, 완료를 따로 측정한다.
• 업무 유형별 SLO와 오류 예산이 있다.
• 평균과 함께 p95·p99를 본다.
• 모델, 검색, Tool, 큐, 프런트 구간을 trace로 연결한다.
• streaming 외에 단계 상태와 취소가 있다.
• 긴 작업은 비동기 job으로 복구 가능하다.
• 권한·형식 오류를 가능한 앞에서 검사한다.
• latency 개선 전후 품질과 task success를 함께 평가한다.

자주 묻는 질문

Streaming을 쓰면 응답 속도가 빨라지는가?

사용자가 첫 결과를 빨리 보므로 체감 대기시간은 줄 수 있다. 그러나 검색·Tool·전체 생성 시간 자체가 줄어드는 것은 아니다. 두 효과를 다른 지표로 측정한다.

p95가 중요한 이유는 무엇인가?

평균은 느린 요청을 가릴 수 있다. 반복적으로 느린 큰 문서, 특정 Tool, 특정 사용자군의 경험을 보기 위해 상위 지연 구간이 필요하다.

느린 작업은 모두 비동기로 바꿔야 하나?

아니다. 대화 중 즉시 판단이 필요한 작업은 동기 경험이 적합할 수 있다. 완료 시간이 길고 창을 계속 열 필요가 없는 보고서·대량 분석·외부 배치가 우선 후보다.

근거 자료

• OpenAI Latency optimization
• Microsoft HAX Guidelines for Human-AI Interaction