AI 서비스 SLO와 폴백 설계: HTTP 200인데 틀린 답을 다루는 법
LLM 서비스의 성공률·지연뿐 아니라 구조화 출력, 근거, 도구 실행과 안전 실패를 SLI로 정의하고 오류 예산, 회로 차단, 축소 운영과 사람 전환을 설계합니다.
핵심 요약
- LLM API가 200을 반환해도 파싱 실패, 근거 누락, 잘못된 도구 실행이 생길 수 있으므로 제품 수준의 성공 지표가 필요합니다.
- 재시도, 회로 차단, 대체 모델, 읽기 전용 축소 모드와 사람 전환을 위험 순서에 맞게 설계해야 합니다.
- 100% 목표보다 허용 실패량을 정하고 오류 예산이 소진될 때 출시와 실험을 늦추는 운영 규칙이 중요합니다.
LLM API가 200 OK를 반환했는데 JSON이 깨졌거나 존재하지 않는 정책을 인용할 수 있습니다. 인프라 대시보드는 초록색이지만 사용자는 실패한 셈이다. 일반 API 성공률만으로 AI 기능의 신뢰성을 설명하기 어려운 지점이 여기입니다.
AI 서비스 수준 목표는 모델의 “정확도 95%” 한 줄로도 끝나지 않습니다. 요청이 도착하고, 필요한 형식을 만들고, 근거를 지키며, 허용된 행동만 실행하고, 실패 때 안전하게 물러나는 전체 경로를 측정해야 합니다.
SLI, SLO, SLA를 섞지 않는다
- SLI는 관찰한 서비스 수준 지표입니다. 성공 요청 비율이나 p95 지연이 여기에 해당합니다.
- SLO는 일정 기간 지켜야 할 내부 목표 범위입니다.
- SLA는 고객과 맺은 계약상 약속이며 위반 시 보상 조건이 붙을 수 있습니다.
Google SRE 지침은 SLI를 정량 지표, SLO를 그 지표의 목표값이나 범위로 정의합니다. 사용자가 중요하게 여기는 동작에서 출발하고 100% 목표를 피하라고 권고합니다. 100%를 약속하면 실험과 변경에 쓸 오류 여지가 사라지기 때문입니다. Google SRE, Service Level Objectives
처음부터 외부 SLA로 약속하지 마세요. 실제 분포와 실패 원인을 관찰한 뒤 내부 SLO를 운영하고, 측정이 안정된 항목만 계약 검토 대상으로 올리는 편이 안전합니다.
AI 요청의 성공을 층별로 나눈다
1. 전송 성공
공급자 연결, 인증, rate limit, 시간 초과와 5xx를 봅니다. 필요한 자료지만 제품 성공의 가장 바깥층일 뿐이다.
2. 형식 성공
응답이 JSON 스키마를 통과하는지, 필수 필드가 있는지, 스트림이 정상 종료됐는지 측정합니다. 파싱 복구를 했다면 최초 성공과 복구 후 성공을 구분합니다.
3. 근거·업무 규칙 성공
RAG 답변이 허용 문서를 인용하는지, 계산 결과가 업무 규칙과 맞는지, 근거가 없을 때 추측하지 않는지 봅니다. 자동 검증과 사람 표본 검토가 함께 필요할 수 있습니다.
4. 행동 성공
에이전트가 올바른 도구와 인자를 골랐는지, 외부 시스템이 실제로 바뀌었는지, 중복 실행은 없었는지 측정합니다. 도구 실행은 모델 답변과 별도 성공 기준을 둡니다.
5. 안전한 실패
실패를 숨기지 않고 사용자가 다음 행동을 선택할 수 있게 했는지 봅니다. 근거가 없을 때 답변을 만들지 않은 요청은 기술 실패가 아니라 올바른 거부일 수 있다.
첫 SLI 표를 이렇게 만든다
목표 수치는 제품 위험과 현재 기준선으로 정해야 합니다. 아래 값은 계산 구조를 보여주는 예시일 뿐 권장 SLA가 아닙니다.
| 사용자 여정 | SLI 계산 | 예시 SLO | 실패로 세는 경우 |
|---|---|---|---|
| 답변 초안 생성 | 허용 시간 안에 형식 검사를 통과한 요청 / 유효 요청 | 28일간 99.0% | 시간 초과, 빈 응답, JSON 실패 |
| 근거 기반 질의 | 확인 가능한 근거를 가진 답변 / 평가 대상 답변 | 주간 97.0% | 없는 문서 인용, 근거 누락 |
| 읽기 도구 실행 | 올바른 대상에서 성공한 호출 / 허용된 호출 | 28일간 99.5% | 잘못된 도구·대상, 권한 오류 |
| 쓰기 작업 | 중복 없이 승인된 결과 / 승인된 작업 | 28일간 99.9% | 중복 결제, 부분 실행, 상태 불명 |
| 응답 지연 | 사용자 요청부터 완료까지 | p95 8초 이하 | 큐·검색·생성을 모두 포함 |
분모 정의가 중요합니다. 사용자가 취소한 요청, 정책상 올바르게 차단한 요청, 공급자 장애 중 큐에 보관한 요청을 어떻게 셀지 문서화해야 팀마다 다른 숫자를 만들지 않습니다.
Google Cloud의 AI/ML 신뢰성 지침도 성공률과 지연 외에 첫 토큰 시간, 유해 출력 같은 AI 특화 지표를 SLO 예시로 제시합니다. Google Cloud AI/ML Reliability
온라인 지표와 오프라인 평가를 연결한다
정답을 즉시 알 수 없는 생성형 답변이 많습니다. 운영 중 모든 응답의 사실성을 실시간 계산하겠다는 목표는 현실적이지 않을 수 있다.
두 계층으로 나눕니다.
- 온라인 SLI: 오류, 지연, 파싱, 인용 존재, 도구 상태, 사용자 취소처럼 즉시 관찰 가능한 신호
- 오프라인 SLI: 고정 평가 세트, 사람 검토, 사고 표본에서 측정한 근거·정확성·안전 결과
온라인 지표가 정상이어도 오프라인 품질이 떨어지면 오류 예산을 소진한 것으로 취급할 수 있습니다. 모델·프롬프트 변경을 평가 실행 ID와 연결하면 어느 배포부터 회귀가 시작됐는지 찾기 쉽습니다. 평가 세트 구성은 LLM 회귀 평가 가이드를 참고하세요.
오류 예산이 행동을 바꾸게 만든다
오류 예산은 1 - SLO로 허용한 실패량이다. 목표가 99%라면 측정 기간의 유효 요청 중 1%가 예산입니다. 숫자만 계산하고 배포 규칙이 없으면 장식에 그칩니다.
| 예산 상태 | 운영 규칙 예시 |
|---|---|
| 충분 | 계획된 기능 배포와 실험 진행 |
| 절반 이상 소진 | 고위험 변경 축소, 실패 상위 원인 점검 |
| 빠른 속도로 소진 | 새 모델·프롬프트 배포 중단, 담당자 호출 |
| 소진 | 신뢰성 수정 우선, 축소 모드 또는 롤백 |
짧은 시간에 예산이 빠르게 타는지 보는 burn-rate 경보를 두면 월말까지 기다리지 않아도 됩니다. 경보는 소유자가 즉시 할 수 있는 행동과 연결해야 한다. “정확도가 낮습니다”보다 “새 모델 카나리의 JSON 실패가 기준선의 세 배이며 이전 설정으로 되돌릴 수 있음”이 낫습니다.
폴백은 모델 하나 더 붙이는 일이 아니다
주 모델이 실패하면 무조건 다른 모델로 같은 요청을 보내는 구현은 비용과 지연을 늘리고, 쓰기 작업을 중복 실행할 수 있습니다. 영향이 작은 단계부터 내려가는 폴백 사다리를 만듭니다.
1단계: 제한된 재시도
429, 일시적 5xx, 네트워크 시간 초과처럼 재시도 가능한 오류만 지수 백오프와 무작위 지연을 적용합니다. 공급자가 retry-after를 주면 우선 따릅니다. 총 시도 횟수와 전체 시간 한도를 둡니다.
Anthropic 오류 문서는 429, 500, 504, 529 같은 상태와 오류 형태를 설명합니다. rate limit 문서는 retry-after 헤더와 토큰 버킷 방식도 안내합니다. Anthropic API Errors Anthropic Rate Limits
2단계: 회로 차단과 부하 억제
같은 공급자 오류가 계속되면 새 호출을 잠시 막고 빠르게 실패시킵니다. 큐 길이, 동시 실행 수와 최대 입력 크기를 줄여 장애가 전체 시스템으로 번지는 일을 막습니다.
3단계: 대체 모델 또는 리전
읽기 전용 초안처럼 위험이 낮은 기능은 사전 검증한 대체 모델로 보낼 수 있습니다. 입력 형식, 안전 정책과 데이터 처리 조건이 같은지 확인해야 합니다. 모델 종료 전환 절차는 LLM 모델 마이그레이션 런북과 동일한 계약 테스트가 필요합니다.
4단계: 기능 축소
생성 대신 검색 결과와 원문 링크만 보여주거나, 자유 서술 대신 검증된 템플릿을 채웁니다. 에이전트는 쓰기 권한을 닫고 읽기 전용으로 바꿀 수 있습니다. Google SRE 운영 지침은 과부하 때 기능을 줄이는 graceful degradation을 권고합니다. Google SRE, Service Best Practices
5단계: 비동기 처리와 사람 전환
즉시 답할 필요가 없는 작업은 큐에 넣고 예상 처리 시간을 알립니다. 결제, 삭제, 의료·법률 판단처럼 위험이 큰 작업은 자동 대체 모델보다 사람 검토로 전환하는 편이 맞을 수 있습니다.
6단계: 명확한 중단
안전한 대안이 없으면 실패를 숨기지 않습니다. 처리되지 않은 범위, 재시도 여부와 사용자가 취할 다음 행동을 알려야 한다.
쓰기 작업은 상태 기계와 멱등성으로 보호한다
모델이 도구 호출을 제안했고 응답 연결이 끊겼다고 가정해 봅시다. 클라이언트가 전체 요청을 재시도하면 첫 호출이 이미 결제를 실행했을 수 있습니다.
쓰기 작업에는 다음 상태를 모델 바깥에 둡니다.
planned -> policy_checked -> approved -> executing -> committed
-> failed -> compensating -> compensated- 업무 단위별 멱등성 키를 하위 API까지 전달합니다.
- 시간 초과 뒤에는 재실행 전에 현재 상태를 조회합니다.
- 승인 내용과 실제 실행 인자가 달라지면 새 승인을 요구합니다.
- 부분 성공을 되돌릴 보상 작업과 사람 연락 경로를 둡니다.
- 모델 응답의 “완료했습니다”가 아니라 하위 시스템 결과로 완료를 판정합니다.
권한과 승인 로그는 AI 에이전트 권한 설계 가이드에서 더 자세히 다룹니다.
게임데이에서 깨뜨려 볼 시나리오
- 공급자가 429와
retry-after를 반환한다. - 5xx가 10분 이어져 회로 차단기가 열린다.
- 스트리밍 중간에 연결이 끊긴다.
- 모델은 성공했지만 JSON 필수 필드가 빠진다.
- 검색 문서가 없는데 답변을 요구한다.
- 도구 실행 뒤 응답만 시간 초과된다.
- 대체 모델도 같은 공급자 장애의 영향을 받는다.
- 큐가 처리 한도를 넘고 오래된 작업이 남는다.
- 축소 모드에서 쓰기 도구가 호출된다.
- 사람 전환 채널이 근무 외 시간에 응답하지 않는다.
각 시험에서 사용자 메시지, 내부 상태, 중복 실행, 경보와 복구 시간을 기록합니다. 정상 경로 스크린샷보다 장애 때 데이터가 어디까지 바뀌었는지가 중요한 증거다.
작은 서비스가 처음 정할 세 가지 목표
처음부터 지표 수십 개를 운영하기 어렵다면 다음 세 가지로 시작할 수 있습니다.
- 사용자 여정 하나의 완료 성공률과 p95 지연
- 구조화 출력 또는 근거 검사의 통과율
- 안전한 폴백으로 끝난 요청과 상태 불명 요청의 비율
그다음 비용, 사람 수정률, 정책 차단과 도구 정확성을 붙입니다. SLO는 모델 공급자의 상태 페이지를 복사하는 문서가 아니다. 우리가 사용자에게 제공하는 기능의 경계와 실패 시 행동을 합의하는 운영 계약입니다.
NIST 생성형 AI 프로필은 제3자 서비스의 비상 계획, 복구와 변경 관리를 검토하도록 권고합니다. 특정 폴백 구조를 인증하는 문서는 아니므로 산업 위험과 계약 조건은 별도 검토가 필요합니다. NIST AI 600-1
첫 게임데이에서는 공급자 5xx를 주입하고 읽기 전용 축소 모드까지 내려가 보세요. 요청이 중복 실행되지 않고 사용자가 현재 상태를 이해할 수 있다면, 그다음에 대체 모델과 자동 라우팅을 붙여도 늦지 않습니다.