AI 제품 백엔드 안정성 설계

왜 이 주제가 중요한가

LLM을 붙인 제품의 백엔드는 일반 CRUD 백엔드와 안정성 모델이 다르다. 일반 백엔드는 "DB가 살아 있으면 같은 입력에 같은 출력"이 기본 전제다. AI 제품 백엔드는 그렇지 않다.

응답이 비결정적이다 — 같은 입력에도 모델 출력이 매번 달라진다. 그래서 "정상 응답"의 정의 자체를 우리가 따로 만들어야 한다.
지연이 크고 가변적이다 — 모델 한 번 호출이 수백 ms~수십 초까지 튄다. p99가 평균의 5배를 넘는 경우가 흔하다.
호출당 비용이 실시간으로 발생한다 — 토큰 단위로 돈이 나간다. 루프가 한 번 급증하면 장애가 아니라 청구서로 먼저 드러난다.
외부 모델 제공자에 강하게 의존한다 — 우리 코드가 멀쩡해도 제공자 쪽 429/5xx/지연이 그대로 우리 SLA를 깬다.

그래서 AI 제품 백엔드의 안정성은 "장애가 안 나게 한다"가 아니라 비결정성·가변 지연·실시간 비용·외부 의존을 전제로 깔고, 나빠질 때 어디서 끊고 어떻게 우아하게 내려갈지를 설계한다 가 핵심이다. 이 문서는 그 설계를 지연·비용·권한·관측·실패 처리 다섯 축으로 정리한다.

도구 호출 자체의 설계(레지스트리, 스키마 검증, dispatcher)는 LLM Tool Calling과 Agent Workflow 설계에서, 일반 분산 시스템 resilience 스택(Timeout/Retry/Circuit Breaker/Bulkhead/Backpressure)은 Resilience 패턴 가이드에서 다룬다. 이 문서는 그 둘을 AI 제품 운영 관점에서 묶는 허브 역할을 한다.

핵심 개념: 안정성 5개 축

AI 제품 백엔드의 안정성은 다음 다섯 가지를 각각 "예산"과 "실패 정책"으로 설계하는 일이다.

축	핵심 질문	대표 통제 수단
지연	사용자가 얼마나 기다리게 둘 것인가	시간 예산, 스트리밍, 계층 timeout
비용	한 요청에 얼마까지 쓸 것인가	토큰/호출/누적 비용 가드, 캐싱, 모델 폴백
권한	모델이 무엇을 건드리게 둘 것인가	사용자 컨텍스트 권한 검증, 도구 노출 제한
관측	무엇이 왜 실패했는지 사후에 알 수 있는가	correlation id, audit JSONL, LLM 특화 메트릭
실패 처리	나빠질 때 어떻게 내려갈 것인가	폴백 사다리, 재시도, 사람 에스컬레이션

다섯 축은 독립적이지 않다. 지연 예산이 비용 예산을 제약하고, 실패 처리는 관측이 없으면 설계할 수 없다. 그래서 한 곳(보통 요청 단위 budget 객체)에 모아두는 것이 실무에서 가장 덜 깨진다.

지연 예산 (Latency Budget)

모델 호출은 느리다. 그러므로 "언제까지 기다리고, 어디서 포기할지"를 먼저 정한다.

계층 timeout

모델/도구 호출은 최소 세 계층의 timeout을 분리한다.

단일 모델 호출 timeout — 한 번의 LLM 호출에 대한 상한. 스트리밍이면 "첫 토큰까지" 와 "전체 완료까지" 를 따로 둔다.
단일 도구 호출 timeout — 외부 API/DB 호출 상한. 도구마다 평균/최대 응답 시간이 다르므로 도구 메타데이터에 SLO로 박는다.
요청 전체 timeout(wall-clock budget) — 사용자 발화 하나를 처리하는 전체 상한. 루프가 여러 step을 돌아도 이 예산을 넘기면 끊는다.

스트리밍으로 체감 지연을 낮춘다

전체 응답이 8초 걸려도 첫 토큰이 400ms에 나오면 사용자 체감은 전혀 다르다. 스트리밍(SSE 또는 WebSocket)은 안정성 설계의 일부다. 단, 스트리밍 중간에 실패하면 "이미 일부를 보여준 상태"라는 새 실패 모드가 생긴다. 부분 출력 후 끊겼을 때 어떻게 마감할지(에러 토큰 주입, 재생성 버튼, 마지막 문장 절단 표시)를 미리 정한다.

text

요청 시작
 ├─ 첫 토큰까지 timeout: 5s   (안 오면 폴백)
 ├─ 전체 완료 timeout: 30s
 └─ 요청 wall-clock budget: 40s (도구 호출 포함 전체)

비용 예산 (Cost Budget)

AI 백엔드에서 비용 급증은 "느린 장애"다. 모니터링 그래프보다 다음 달 청구서에서 먼저 보인다. 그래서 비용을 런타임 가드로 다룬다.

요청 단위 가드

한 사용자 발화당 다음을 모두 건다.

최대 step 수 — 에이전트 루프가 도구를 부를 수 있는 횟수 상한 (예: 6회)
최대 누적 토큰 — 입력+출력 토큰 합 상한 (예: 30k)
최대 누적 비용 — 모델별 단가를 곱한 추정 비용 상한

가드에 걸리면 예외가 아니라 정해진 폴백 응답과 사람 에스컬레이션으로 내려간다. "예산 초과로 죽었습니다"가 사용자에게 가서는 안 된다.

모델 폴백 사다리와 캐싱

비용과 안정성을 동시에 잡는 두 수단.

모델 폴백 사다리 — 평소에는 작고 싼 모델로 처리하고, 신뢰도/복잡도가 임계 이상일 때만 큰 모델로 올린다. 반대로 큰 모델이 429를 던지면 같은 모델을 기다리지 말고 바로 다음 모델로 내려가는 전략도 있다. "싸 보이는 모델이 재생성을 반복해 오히려 더 비싸지는" 경우가 있으므로, 폴백 방향은 비용만이 아니라 재시도 총비용으로 판단한다.
컨텍스트 캐싱 / 결과 캐싱 — 동일 시스템 프롬프트나 동일 입력에 대한 반복 호출은 제공자 컨텍스트 캐시 또는 자체 결과 캐시로 토큰을 줄인다. 캐시 키에 모델 버전과 프롬프트 버전을 포함하지 않으면 모델 교체 후 낡은 응답이 새는 함정이 있다.

권한 경계

모델은 "무엇을 할 수 있는지"를 알 필요가 없고, 알게 해서도 안 된다. 권한은 항상 현재 인증된 사용자 컨텍스트에서 검증한다. 자세한 dispatcher 구조는 Tool Calling 문서에 있으므로 여기서는 안정성 관점의 원칙만 짚는다.

모델이 "시켰으니까" 권한을 잠깐 올려서 실행하는 우회는 절대 만들지 않는다. 도구 실행은 언제나 사용자 컨텍스트에서 일어난다.
노출하는 도구 집합을 의도 분류 결과와 사용자 권한으로 동적으로 좁힌다. 잡담 컨텍스트에 민감 도구를 노출하면 prompt injection 표면이 넓어진다.
거절 메시지는 내부 사유를 흘리지 않는 일반화된 형태로 모델에 돌려준다. 모델은 그것을 사용자에게 그대로 풀어 쓸 수 있다.

권한이 안정성 주제인 이유는, 권한 사고가 데이터 유출/오작동이라는 가장 비싼 장애로 직결되기 때문이다.

관측 (Observability)

AI 백엔드는 "왜 이 답이 나왔는가"를 사후에 재구성할 수 없으면 개선도 사고 대응도 못 한다. 일반 관측성 기본기에 더해, AI 특화 항목을 남긴다.

무엇을 남기는가

한 사용자 발화를 하나의 correlation id로 묶어 audit JSONL에 적재한다.

의도 분류 결과와 confidence
모델에 노출한 도구 목록과 system prompt 버전
모델이 제안한 각 tool call의 이름·인자, 검증 결과(통과/거절 사유)
실제 실행된 도구의 입력·출력 요약, 응답 시간, 결과 코드
사용한 모델, 입력/출력 토큰, 추정 비용, step 수
최종 사용자 노출 텍스트

LLM 특화 메트릭

일반 RED(Rate/Error/Duration) 메트릭에 더해 본다.

모델 호출 실패율 (제공자 429/5xx 비율) — 우리 코드가 아니라 외부 의존의 건강 상태
폴백 발동율 — 어떤 폴백 경로가 얼마나 자주 도는지. 폴백이 "가끔"이 아니라 "기본"이 되면 설계가 무너진 신호다.
요청당 평균/누적 토큰·비용 — 비용 회귀를 조기에 잡는다
검증 거절율 — 모델이 스키마/의미 검증에서 떨어지는 비율. hallucination 추세 지표.

audit는 운영뿐 아니라 모델 평가의 입력이다. 이 데이터로 어떤 분류가 자주 틀리고 어떤 도구의 인자 환각이 잦은지를 정량으로 본다. 평가 루프 설계는 LLM 평가 프레임워크와 연결된다.

도구·모델 실패 처리와 폴백 사다리

실패는 예외가 아니라 일정 확률로 항상 일어나는 사건이다. 핵심은 "전파를 어디서 끊고, 어떻게 한 단계씩 우아하게 내려갈지"다.

폴백 사다리 (degradation ladder)

가장 좋은 응답에서 최소한의 응답까지 단계를 미리 정의한다.

text

1. 큰 모델 + 전체 도구       (정상)
2. 작은 모델 + 전체 도구       (큰 모델 429/지연 시)
3. 작은 모델 + 캐시된 결과만    (외부 도구 장애 시)
4. 템플릿/규칙 기반 응답        (모델 전체 장애 시)
5. 사람 상담사로 에스컬레이션    (위 전부 실패 또는 민감 케이스)

각 단계 전환 조건(어떤 신호에서 한 칸 내려가는가)을 코드로 명시한다. "되는 데까지 해보다가 터지면 500"이 가장 나쁜 패턴이다.

재시도는 부작용 여부로 구분한다

읽기/안전한 도구 (조회류): 지수 백오프와 jitter로 2~3회 재시도. 결과는 "성공" 또는 "최종 실패"로 정리해 모델에 준다.
부작용 있는 도구 (발송/결제/취소류): idempotency key가 있을 때만 재시도한다. 없으면 즉시 실패로 보고한다. 모델이 같은 도구를 반복 호출해 부작용이 누적되는 사고를 막는 것이 재시도 정책보다 우선이다.
모델 호출 자체의 429: 같은 모델을 무한정 기다리기보다 폴백 사다리의 다음 모델로 내려가는 편이 지연·비용 모두에 낫다.

부분 성공을 정직하게 전달한다

여러 외부 호출 중 일부만 성공한 경우, observation 페이로드에 부분 성공을 명시해 모델이 "모두 완료"라고 단정하지 않게 한다.

json

{ "sms": "sent", "push": "queue_failed" }

모델 답변은 "문자로는 보냈고 앱 알림은 잠시 후 다시 시도하겠다"가 되어야 한다.

사람 에스컬레이션은 기능이다

AI 제품에서 "사람에게 넘긴다"는 장애 처리의 마지막 수단이 아니라 설계된 정상 경로 중 하나다. 다음을 미리 정한다.

언제 넘기는가 — 예산 초과, 권한 부족, 낮은 confidence, 민감 카테고리, 연속 실패.
무엇을 함께 넘기는가 — 지금까지의 대화 맥락 요약, 시도한 도구와 결과, 실패 사유. 사람이 처음부터 다시 묻지 않게 한다.
사용자에게 어떻게 보이는가 — "처리할 수 없습니다"가 아니라 "확인이 더 필요해 상담사에게 연결합니다" 같은 우아한 마감.

에스컬레이션 경로가 없는 AI 백엔드는 나쁜 케이스에서 무조건 사용자에게 실패를 떠넘긴다.

나쁜 예와 개선된 예

나쁜 예 1: 예산 없는 에이전트 루프

java

// 안티패턴: 종료 조건이 "모델이 끝났다고 할 때"뿐
while (!response.isFinal()) {
    response = llm.next();
    dispatch(response.toolCall());
}

모델이 같은 도구를 반복 호출하면 토큰·비용·지연이 무한히 늘어난다. 장애가 청구서로 드러난다.

개선

java

for (int step = 0; step < ctx.maxSteps(); step++) {
    LlmResponse r = session.next(ctx.budget()); // 토큰·시간·비용 예산 주입
    if (r.isFinal()) return AgentReply.text(r.text());
    dispatcher.dispatch(r.toolCall(), ctx.toToolContext());
    if (ctx.budget().exhausted()) break;        // 예산 가드
}
return AgentReply.escalate("budget_exceeded"); // 우아한 마감

나쁜 예 2: 모델 장애 시 그냥 500

java

// 안티패턴
String answer = llm.complete(prompt); // 제공자 5xx면 그대로 예외 → 사용자 500
return answer;

개선

폴백 사다리를 탄다. 큰 모델 실패 → 작은 모델 → 캐시된 결과 → 템플릿 응답 → 사람 에스컬레이션 순으로 한 칸씩 내려간다. 어느 단계에서 내려갔는지 audit에 남긴다.

로컬 실습 환경

JDK 21, Spring Boot 3.x
의존성: spring-boot-starter-web, spring-boot-starter-validation, resilience4j-retry, resilience4j-circuitbreaker, micrometer-tracing
LLM: 키가 없으면 fake LLM으로 대체 — 시나리오별로 미리 준비된 tool call/응답을 결정적으로 돌려준다. 안정성 가드를 검증할 때는 진짜 모델보다 결정적인 가짜가 낫다.
장애 주입: fake 모델/도구 어댑터가 일정 비율로 429·5xx·timeout·부분 성공을 주입할 수 있게 둔다.
관측: logs/ai-audit.jsonl에 줄 단위 JSON으로 적재하고 jq로 폴백 발동율·평균 토큰을 집계한다.

실행 가능한 시나리오

손으로 굴려보며 실패 모드를 익히는 데 좋은 시나리오.

정상 경로 — 예산 안에서 도구 2회 호출 후 최종 답변. audit에 토큰·비용 기록.
모델 429 — 큰 모델이 429를 던지면 폴백 사다리 2단계(작은 모델)로 내려가고, audit에 폴백 발동을 남긴다.
외부 도구 5xx — 부작용 없는 조회 도구는 백오프 재시도 후 성공/실패 정리, 부작용 도구는 idempotency key 없으면 재시도 금지.
부분 성공 — 두 알림 채널 중 하나만 성공. observation에 부분 성공 명시, 모델이 "모두 완료"라고 답하지 않는지 확인.
예산 초과 — 모델이 같은 도구를 반복 호출. step 가드가 끊고 사람 에스컬레이션으로 마감.
권한 부족 — 사용자 권한 밖 도구 요청. dispatcher가 일반화된 거절을 돌려주고 모델이 안전한 경로로 우회.

각 시나리오는 fake LLM 기반 통합 테스트로 묶어 회귀 보호한다. 모델 응답이 바뀌어도 안정성 가드가 동작하는지를 결정적으로 검증할 수 있다.

설계 점검 질문

시니어 백엔드 관점에서 스스로 던져볼 질문과 답의 뼈대.

"AI 제품 백엔드가 일반 백엔드와 다른 점은?"

비결정성·가변 지연·실시간 토큰 비용·외부 모델 의존을 전제로 깔아야 한다는 점. 그래서 "정상 응답의 정의"와 "나빠질 때 내려가는 단계"를 우리가 직접 설계한다.

"비용과 지연의 과도한 증가를 어떻게 막는가?"

요청 단위 step/토큰/시간/비용 가드를 한 budget 객체에 모으고, 초과 시 폴백·에스컬레이션으로 내려간다. 모델 폴백 사다리와 캐싱으로 평소 비용을 낮추되, 폴백 방향은 재시도 총비용으로 판단한다.

"모델/도구 실패를 어떻게 다루는가?"

폴백 사다리로 한 칸씩 우아하게 내려간다. 재시도는 부작용 여부로 구분하고, 부작용 도구는 idempotency key가 있을 때만 재시도한다. 부분 성공은 정직하게 모델에 전달한다.

"관측은 어떻게 설계하는가?"

correlation id로 한 발화를 묶어 분류·노출 도구·tool call·검증·실행·토큰·비용·최종 답변까지 audit JSONL에 남긴다. 폴백 발동율·검증 거절율·요청당 비용을 LLM 특화 메트릭으로 본다. 이 데이터는 모델 평가의 입력이기도 하다.

체크리스트

왜 이 주제가 중요한가

응답이 비결정적이다 — 같은 입력에도 모델 출력이 매번 달라진다. 그래서 "정상 응답"의 정의 자체를 우리가 따로 만들어야 한다.
지연이 크고 가변적이다 — 모델 한 번 호출이 수백 ms~수십 초까지 튄다. p99가 평균의 5배를 넘는 경우가 흔하다.
호출당 비용이 실시간으로 발생한다 — 토큰 단위로 돈이 나간다. 루프가 한 번 급증하면 장애가 아니라 청구서로 먼저 드러난다.
외부 모델 제공자에 강하게 의존한다 — 우리 코드가 멀쩡해도 제공자 쪽 429/5xx/지연이 그대로 우리 SLA를 깬다.

핵심 개념: 안정성 5개 축

AI 제품 백엔드의 안정성은 다음 다섯 가지를 각각 "예산"과 "실패 정책"으로 설계하는 일이다.

축	핵심 질문	대표 통제 수단
지연	사용자가 얼마나 기다리게 둘 것인가	시간 예산, 스트리밍, 계층 timeout
비용	한 요청에 얼마까지 쓸 것인가	토큰/호출/누적 비용 가드, 캐싱, 모델 폴백
권한	모델이 무엇을 건드리게 둘 것인가	사용자 컨텍스트 권한 검증, 도구 노출 제한
관측	무엇이 왜 실패했는지 사후에 알 수 있는가	correlation id, audit JSONL, LLM 특화 메트릭
실패 처리	나빠질 때 어떻게 내려갈 것인가	폴백 사다리, 재시도, 사람 에스컬레이션

지연 예산 (Latency Budget)

모델 호출은 느리다. 그러므로 "언제까지 기다리고, 어디서 포기할지"를 먼저 정한다.

계층 timeout

모델/도구 호출은 최소 세 계층의 timeout을 분리한다.

단일 모델 호출 timeout — 한 번의 LLM 호출에 대한 상한. 스트리밍이면 "첫 토큰까지" 와 "전체 완료까지" 를 따로 둔다.
단일 도구 호출 timeout — 외부 API/DB 호출 상한. 도구마다 평균/최대 응답 시간이 다르므로 도구 메타데이터에 SLO로 박는다.
요청 전체 timeout(wall-clock budget) — 사용자 발화 하나를 처리하는 전체 상한. 루프가 여러 step을 돌아도 이 예산을 넘기면 끊는다.

스트리밍으로 체감 지연을 낮춘다

text

요청 시작
 ├─ 첫 토큰까지 timeout: 5s   (안 오면 폴백)
 ├─ 전체 완료 timeout: 30s
 └─ 요청 wall-clock budget: 40s (도구 호출 포함 전체)

비용 예산 (Cost Budget)

AI 백엔드에서 비용 급증은 "느린 장애"다. 모니터링 그래프보다 다음 달 청구서에서 먼저 보인다. 그래서 비용을 런타임 가드로 다룬다.

요청 단위 가드

한 사용자 발화당 다음을 모두 건다.

최대 step 수 — 에이전트 루프가 도구를 부를 수 있는 횟수 상한 (예: 6회)
최대 누적 토큰 — 입력+출력 토큰 합 상한 (예: 30k)
최대 누적 비용 — 모델별 단가를 곱한 추정 비용 상한

가드에 걸리면 예외가 아니라 정해진 폴백 응답과 사람 에스컬레이션으로 내려간다. "예산 초과로 죽었습니다"가 사용자에게 가서는 안 된다.

모델 폴백 사다리와 캐싱

비용과 안정성을 동시에 잡는 두 수단.

모델 폴백 사다리 — 평소에는 작고 싼 모델로 처리하고, 신뢰도/복잡도가 임계 이상일 때만 큰 모델로 올린다. 반대로 큰 모델이 429를 던지면 같은 모델을 기다리지 말고 바로 다음 모델로 내려가는 전략도 있다. "싸 보이는 모델이 재생성을 반복해 오히려 더 비싸지는" 경우가 있으므로, 폴백 방향은 비용만이 아니라 재시도 총비용으로 판단한다.
컨텍스트 캐싱 / 결과 캐싱 — 동일 시스템 프롬프트나 동일 입력에 대한 반복 호출은 제공자 컨텍스트 캐시 또는 자체 결과 캐시로 토큰을 줄인다. 캐시 키에 모델 버전과 프롬프트 버전을 포함하지 않으면 모델 교체 후 낡은 응답이 새는 함정이 있다.

권한 경계

모델이 "시켰으니까" 권한을 잠깐 올려서 실행하는 우회는 절대 만들지 않는다. 도구 실행은 언제나 사용자 컨텍스트에서 일어난다.
노출하는 도구 집합을 의도 분류 결과와 사용자 권한으로 동적으로 좁힌다. 잡담 컨텍스트에 민감 도구를 노출하면 prompt injection 표면이 넓어진다.
거절 메시지는 내부 사유를 흘리지 않는 일반화된 형태로 모델에 돌려준다. 모델은 그것을 사용자에게 그대로 풀어 쓸 수 있다.

권한이 안정성 주제인 이유는, 권한 사고가 데이터 유출/오작동이라는 가장 비싼 장애로 직결되기 때문이다.

관측 (Observability)

AI 백엔드는 "왜 이 답이 나왔는가"를 사후에 재구성할 수 없으면 개선도 사고 대응도 못 한다. 일반 관측성 기본기에 더해, AI 특화 항목을 남긴다.

무엇을 남기는가

한 사용자 발화를 하나의 correlation id로 묶어 audit JSONL에 적재한다.

의도 분류 결과와 confidence
모델에 노출한 도구 목록과 system prompt 버전
모델이 제안한 각 tool call의 이름·인자, 검증 결과(통과/거절 사유)
실제 실행된 도구의 입력·출력 요약, 응답 시간, 결과 코드
사용한 모델, 입력/출력 토큰, 추정 비용, step 수
최종 사용자 노출 텍스트

LLM 특화 메트릭

일반 RED(Rate/Error/Duration) 메트릭에 더해 본다.

모델 호출 실패율 (제공자 429/5xx 비율) — 우리 코드가 아니라 외부 의존의 건강 상태
폴백 발동율 — 어떤 폴백 경로가 얼마나 자주 도는지. 폴백이 "가끔"이 아니라 "기본"이 되면 설계가 무너진 신호다.
요청당 평균/누적 토큰·비용 — 비용 회귀를 조기에 잡는다
검증 거절율 — 모델이 스키마/의미 검증에서 떨어지는 비율. hallucination 추세 지표.

도구·모델 실패 처리와 폴백 사다리

실패는 예외가 아니라 일정 확률로 항상 일어나는 사건이다. 핵심은 "전파를 어디서 끊고, 어떻게 한 단계씩 우아하게 내려갈지"다.

폴백 사다리 (degradation ladder)

가장 좋은 응답에서 최소한의 응답까지 단계를 미리 정의한다.

text

1. 큰 모델 + 전체 도구       (정상)
2. 작은 모델 + 전체 도구       (큰 모델 429/지연 시)
3. 작은 모델 + 캐시된 결과만    (외부 도구 장애 시)
4. 템플릿/규칙 기반 응답        (모델 전체 장애 시)
5. 사람 상담사로 에스컬레이션    (위 전부 실패 또는 민감 케이스)

각 단계 전환 조건(어떤 신호에서 한 칸 내려가는가)을 코드로 명시한다. "되는 데까지 해보다가 터지면 500"이 가장 나쁜 패턴이다.

재시도는 부작용 여부로 구분한다

읽기/안전한 도구 (조회류): 지수 백오프와 jitter로 2~3회 재시도. 결과는 "성공" 또는 "최종 실패"로 정리해 모델에 준다.
부작용 있는 도구 (발송/결제/취소류): idempotency key가 있을 때만 재시도한다. 없으면 즉시 실패로 보고한다. 모델이 같은 도구를 반복 호출해 부작용이 누적되는 사고를 막는 것이 재시도 정책보다 우선이다.
모델 호출 자체의 429: 같은 모델을 무한정 기다리기보다 폴백 사다리의 다음 모델로 내려가는 편이 지연·비용 모두에 낫다.

부분 성공을 정직하게 전달한다

여러 외부 호출 중 일부만 성공한 경우, observation 페이로드에 부분 성공을 명시해 모델이 "모두 완료"라고 단정하지 않게 한다.

json

{ "sms": "sent", "push": "queue_failed" }

모델 답변은 "문자로는 보냈고 앱 알림은 잠시 후 다시 시도하겠다"가 되어야 한다.

사람 에스컬레이션은 기능이다

AI 제품에서 "사람에게 넘긴다"는 장애 처리의 마지막 수단이 아니라 설계된 정상 경로 중 하나다. 다음을 미리 정한다.

언제 넘기는가 — 예산 초과, 권한 부족, 낮은 confidence, 민감 카테고리, 연속 실패.
무엇을 함께 넘기는가 — 지금까지의 대화 맥락 요약, 시도한 도구와 결과, 실패 사유. 사람이 처음부터 다시 묻지 않게 한다.
사용자에게 어떻게 보이는가 — "처리할 수 없습니다"가 아니라 "확인이 더 필요해 상담사에게 연결합니다" 같은 우아한 마감.

에스컬레이션 경로가 없는 AI 백엔드는 나쁜 케이스에서 무조건 사용자에게 실패를 떠넘긴다.

나쁜 예와 개선된 예

나쁜 예 1: 예산 없는 에이전트 루프

java

// 안티패턴: 종료 조건이 "모델이 끝났다고 할 때"뿐
while (!response.isFinal()) {
    response = llm.next();
    dispatch(response.toolCall());
}

모델이 같은 도구를 반복 호출하면 토큰·비용·지연이 무한히 늘어난다. 장애가 청구서로 드러난다.

개선

java

for (int step = 0; step < ctx.maxSteps(); step++) {
    LlmResponse r = session.next(ctx.budget()); // 토큰·시간·비용 예산 주입
    if (r.isFinal()) return AgentReply.text(r.text());
    dispatcher.dispatch(r.toolCall(), ctx.toToolContext());
    if (ctx.budget().exhausted()) break;        // 예산 가드
}
return AgentReply.escalate("budget_exceeded"); // 우아한 마감

나쁜 예 2: 모델 장애 시 그냥 500

java

// 안티패턴
String answer = llm.complete(prompt); // 제공자 5xx면 그대로 예외 → 사용자 500
return answer;

개선

로컬 실습 환경

JDK 21, Spring Boot 3.x
의존성: spring-boot-starter-web, spring-boot-starter-validation, resilience4j-retry, resilience4j-circuitbreaker, micrometer-tracing
LLM: 키가 없으면 fake LLM으로 대체 — 시나리오별로 미리 준비된 tool call/응답을 결정적으로 돌려준다. 안정성 가드를 검증할 때는 진짜 모델보다 결정적인 가짜가 낫다.
장애 주입: fake 모델/도구 어댑터가 일정 비율로 429·5xx·timeout·부분 성공을 주입할 수 있게 둔다.
관측: logs/ai-audit.jsonl에 줄 단위 JSON으로 적재하고 jq로 폴백 발동율·평균 토큰을 집계한다.

실행 가능한 시나리오

손으로 굴려보며 실패 모드를 익히는 데 좋은 시나리오.

정상 경로 — 예산 안에서 도구 2회 호출 후 최종 답변. audit에 토큰·비용 기록.
모델 429 — 큰 모델이 429를 던지면 폴백 사다리 2단계(작은 모델)로 내려가고, audit에 폴백 발동을 남긴다.
외부 도구 5xx — 부작용 없는 조회 도구는 백오프 재시도 후 성공/실패 정리, 부작용 도구는 idempotency key 없으면 재시도 금지.
부분 성공 — 두 알림 채널 중 하나만 성공. observation에 부분 성공 명시, 모델이 "모두 완료"라고 답하지 않는지 확인.
예산 초과 — 모델이 같은 도구를 반복 호출. step 가드가 끊고 사람 에스컬레이션으로 마감.
권한 부족 — 사용자 권한 밖 도구 요청. dispatcher가 일반화된 거절을 돌려주고 모델이 안전한 경로로 우회.

각 시나리오는 fake LLM 기반 통합 테스트로 묶어 회귀 보호한다. 모델 응답이 바뀌어도 안정성 가드가 동작하는지를 결정적으로 검증할 수 있다.

왜 이 주제가 중요한가

핵심 개념: 안정성 5개 축

지연 예산 (Latency Budget)

계층 timeout

스트리밍으로 체감 지연을 낮춘다

비용 예산 (Cost Budget)

요청 단위 가드

모델 폴백 사다리와 캐싱

권한 경계

관측 (Observability)

무엇을 남기는가

LLM 특화 메트릭

도구·모델 실패 처리와 폴백 사다리

폴백 사다리 (degradation ladder)

재시도는 부작용 여부로 구분한다

부분 성공을 정직하게 전달한다

사람 에스컬레이션은 기능이다

나쁜 예와 개선된 예

나쁜 예 1: 예산 없는 에이전트 루프

개선

나쁜 예 2: 모델 장애 시 그냥 500

개선

로컬 실습 환경

실행 가능한 시나리오

설계 점검 질문

"AI 제품 백엔드가 일반 백엔드와 다른 점은?"

"비용과 지연의 과도한 증가를 어떻게 막는가?"

"모델/도구 실패를 어떻게 다루는가?"

"관측은 어떻게 설계하는가?"

체크리스트

이런 글도

하네스 회고는 새 문서로 쌓지 않고 종류에 맞는 기존 단일 소스에 환원한다

에이전트가 배운 회피 패턴은 조건을 통과한 것만 파일로 쌓고 주기적으로 지운다

ADR 은 되돌리기 어려운 결정의 이유만 남기고, 대안 기각은 옵션마다 줄을 나눈다

스킬 문서는 반복 실행을 스크립트로 내리고 같은 지시를 한 곳에서만 소유하게 쓴다

댓글 (0)

왜 이 주제가 중요한가

핵심 개념: 안정성 5개 축

지연 예산 (Latency Budget)

계층 timeout

스트리밍으로 체감 지연을 낮춘다

비용 예산 (Cost Budget)

요청 단위 가드

모델 폴백 사다리와 캐싱

권한 경계

관측 (Observability)

무엇을 남기는가

LLM 특화 메트릭

도구·모델 실패 처리와 폴백 사다리

폴백 사다리 (degradation ladder)

재시도는 부작용 여부로 구분한다

부분 성공을 정직하게 전달한다

사람 에스컬레이션은 기능이다

나쁜 예와 개선된 예

나쁜 예 1: 예산 없는 에이전트 루프

개선

나쁜 예 2: 모델 장애 시 그냥 500

개선

로컬 실습 환경

실행 가능한 시나리오

설계 점검 질문

"AI 제품 백엔드가 일반 백엔드와 다른 점은?"

"비용과 지연의 과도한 증가를 어떻게 막는가?"

"모델/도구 실패를 어떻게 다루는가?"

"관측은 어떻게 설계하는가?"

체크리스트

이런 글도

하네스 회고는 새 문서로 쌓지 않고 종류에 맞는 기존 단일 소스에 환원한다

에이전트가 배운 회피 패턴은 조건을 통과한 것만 파일로 쌓고 주기적으로 지운다

ADR 은 되돌리기 어려운 결정의 이유만 남기고, 대안 기각은 옵션마다 줄을 나눈다

스킬 문서는 반복 실행을 스크립트로 내리고 같은 지시를 한 곳에서만 소유하게 쓴다

댓글 (0)