멀티 LLM 장애 우회 설계 도입 전 판단표: fallback, retry, 비용 상한을 언제 넣고 언제 미뤄야 하나

LLM API 장애 대응은 단순히 벤더를 하나 더 붙이는 문제가 아닙니다. 실제 운영에서는 장애, 지연, 형식 불일치, 품질 흔들림, 재시도에 따른 비용 증가가 함께 발생합니다. 특히 한국 개발팀이 고객지원 자동화, 사내 검색, 문서 요약, 코드 보조 같은 기능을 서비스에 넣을 때는 fallback보다 먼저 실패를 분류하고, retry보다 먼저 멱등성과 비용 상한을 정해야 운영 사고를 줄일 수 있습니다.

OpenAI 공식 문서에서 확인되는 사실은 분명합니다. 현재 빠른 시작 예시는 responses.create 중심으로 제시되고, Responses API는 텍스트, structured output, tools, multimodal workflow에 직접 모델 요청을 보내는 경로로 소개됩니다. 또 Structured Outputs로 JSON schema를 따르는 응답을 받는 흐름이 문서 범위에 포함됩니다. 이 사실은 장애 대응 설계에서 중요한 의미가 있습니다. 즉, 단순 텍스트 생성만이 아니라 도구 호출과 구조화 출력까지 실패 단위로 분리해 로깅하고 우회해야 한다는 뜻입니다.

핵심 답변

LLM API 장애 대응은 fallback 추가가 출발점이 아니라 실패 유형 분리 → 재시도 규칙 → 출력 검증 → 비용 제한 → 대체 경로 순서로 설계해야 합니다. OpenAI, Anthropic, Gemini를 함께 검토하더라도 공식 문서에서 공통으로 확인 가능한 수준은 각자 API 문서와 개발 흐름이 존재한다는 점이므로, 실제 운영 정책은 벤더별 최신 세부 사양을 직접 대조해 추상화 계층으로 감싸는 방식이 안전합니다. 한국 서비스 기준으로는 고객 노출 기능일수록 fallback을 빨리 넣고, 내부 생산성 기능은 먼저 로깅과 비용 상한부터 넣는 편이 낫습니다.

이 글이 다루는 운영 범위

이 글의 초점은 모델 성능 비교가 아니라 운영 안정성입니다. 구체적으로는 아래 네 가지를 다룹니다.

1. API 호출 실패 시 언제 같은 벤더에 retry할지
2. 언제 다른 모델이나 다른 벤더로 fallback할지
3. structured output이나 tool 사용 시 무엇을 검증할지
4. 비용 폭주를 막기 위해 어떤 상한을 둘지

여기서 중요한 점은, 공식 출처가 없는 현재 시점의 세부 rate limit 수치나 지역 제공 범위를 임의로 가정하지 않는 것입니다. 따라서 이 글은 특정 수치보다 설계 원칙과 판단 기준에 집중합니다.

도입 판단표

아래 표는 멀티 LLM 장애 우회 설계를 지금 넣어야 하는 경우와 미뤄도 되는 경우를 나눈 것입니다.

상황	지금 넣을 것	미뤄도 되는 것	이유
고객이 바로 보는 답변 기능	출력 검증, timeout, 1회 제한 retry, fallback	복잡한 다단계 오케스트레이션	장애보다 잘못된 답변 노출이 더 큰 문제
JSON 응답을 파싱해 후속 자동화를 실행	schema 검증, 실패 시 안전 중단, 대체 텍스트 경로	공격적인 자동 재시도	형식 오류가 곧 업무 오류로 이어짐
사내 요약/메모 초안	상세 fallback	벤더 간 완전 추상화	사용자 영향이 상대적으로 낮음
코드 생성/리뷰 보조	요청 로그, 프롬프트 버전 관리, 비용 상한	실시간 다중 벤더 병렬 호출	품질 편차 분석이 먼저 필요
에이전트형 도구 호출	단계별 로깅, tool 실패 분리, 승인 지점	무조건 자동 failover	도구 상태와 모델 상태를 분리해야 함

핵심은 모든 서비스가 같은 수준의 복원력을 필요로 하지 않는다는 점입니다. 고객 결제, 계약서 요약, 운영 자동화처럼 실패 비용이 큰 기능은 초기에 방어선을 두어야 하지만, 내부 실험성 기능은 관측 가능성부터 확보하는 편이 더 효율적입니다.

실패를 한 덩어리로 보지 말아야 하는 이유

운영에서 가장 흔한 실수는 모든 실패를 “API 장애”로 묶는 것입니다. 실제로는 최소한 다음처럼 나눠야 합니다.

• 네트워크/타임아웃 실패
• 벤더 API 오류 응답
• 응답은 왔지만 빈 결과 또는 불완전 결과
• JSON schema 불일치
• tool 호출 단계 실패
• 응답 지연으로 사용자 SLA 초과
• 재시도로 인한 비용 증가

OpenAI 문서에서 Responses API가 텍스트, structured output, tools, multimodal workflow를 포괄한다고 안내하는 점을 보면, 실패 단위도 그만큼 세분화해야 합니다. 예를 들어 텍스트 생성은 성공했지만 구조화 출력이 깨졌다면, 이건 단순 장애가 아니라 후처리 불가 상태입니다. 또 tool 기반 워크플로우에서 모델 응답은 정상이어도 외부 도구가 실패할 수 있습니다. 이런 경우 벤더 fallback보다 먼저 도구 재실행 정책을 따로 둬야 합니다.

retry 설계: 성공률보다 비용과 중복 실행을 먼저 보라

retry는 가장 쉽게 넣을 수 있지만, 가장 쉽게 비용 사고를 만드는 장치이기도 합니다. 특히 LLM 호출 뒤에 DB 저장, 티켓 생성, 메시지 발송, 코드 실행 같은 후속 작업이 붙어 있으면 재시도는 중복 실행 위험을 키웁니다.

실무 기준은 단순합니다.

• 읽기 성격의 요청: 짧은 retry 허용
• 쓰기/실행이 연결된 요청: 멱등 키 또는 실행 기록 없이는 retry 금지
• 구조화 출력 실패: 같은 입력으로 1회 재시도 후 중단
• tool 호출 포함 요청: 모델 retry와 tool retry를 분리

특히 한국 SaaS 팀은 CS 자동화나 백오피스 업무 자동화에서 “한 번 더 보내면 되겠지” 식 재시도를 넣다가 중복 처리 문제를 겪기 쉽습니다. retry는 성공률 최적화 장치가 아니라 제어된 손실 최소화 장치로 봐야 합니다.

fallback 설계: 다른 모델로 넘기기 전에 계약을 맞춰라

fallback은 벤더 추가가 아니라 인터페이스 계약 관리입니다. OpenAI 문서에서 확인되는 responses.create와 output_text, 그리고 Structured Outputs 같은 개념을 기준으로 보면, 애플리케이션은 최소한 아래 계약을 내부적으로 고정해야 합니다.

• 입력 포맷
• 기대 출력 타입: 자유 텍스트 / JSON / tool call
• 실패 코드 체계
• 최대 허용 지연 시간
• 최대 허용 비용

이 계약이 없으면 OpenAI에서 Claude나 Gemini로 넘길 때 단순 성공 여부만 비교하게 되고, 실제로는 출력 형식이 달라 후속 로직이 깨집니다. 따라서 fallback 계층은 “벤더 A 실패 시 벤더 B 호출”이 아니라 아래 순서가 좋습니다.

1. 요청 목적 분류
2. 출력 계약 선택
3. 1차 모델 호출
4. 계약 검증
5. 실패 유형 판정
6. 같은 계약을 만족하는 대체 경로 호출

즉, fallback의 핵심은 모델 교체가 아니라 출력 계약 유지입니다.

선택 기준 매트릭스

어떤 방어 장치를 먼저 넣을지 빠르게 결정하려면 아래 매트릭스를 쓰면 됩니다.

기준	우선순위 높음일 때 먼저 넣을 것	보류 가능 항목
고객 영향도	timeout, 사용자 안내 문구, fallback	세밀한 품질 점수화
자동 실행 위험	schema 검증, 승인 단계, 안전 중단	공격적 retry
비용 민감도	요청당 예산 상한, 일일 상한, 긴 입력 차단	병렬 다중 호출
품질 일관성	프롬프트 버전 관리, 샘플 회귀 검증, 모델별 라우팅	무조건 단일 모델 고정
개발 속도	공통 래퍼, 공통 로그 스키마	벤더별 고급 기능 깊은 통합

이 표를 팀 회의에서 쓰면 “멀티 벤더를 할까 말까” 같은 추상적 논쟁보다, 어떤 리스크를 먼저 막을지로 대화를 바꿀 수 있습니다.

로깅 설계: 나중 분석용이 아니라 즉시 우회용으로 남겨라

로그는 사후 분석만을 위한 것이 아닙니다. 장애 대응에서는 즉시 라우팅 판단에 쓰여야 합니다. 최소 로그 필드는 다음 정도로 잡는 것이 실용적입니다.

• 요청 ID
• 사용자/테넌트 구분값
• 기능명
• 사용 벤더와 모델명
• 입력 크기 구간
• 응답 시간
• 출력 타입
• 검증 성공 여부
• retry 횟수
• fallback 발생 여부
• 최종 사용자 노출 결과

OpenAI 문서에는 Agents SDK에서 tracing을 언급하는 흐름이 보입니다. 이 사실 자체가 시사하는 바는 분명합니다. 앞으로는 단일 completion 로그보다 워크플로우 단위 추적이 중요합니다. Anthropic과 Gemini도 공식 문서가 존재하므로, 실제 구현 시에는 각 문서의 로깅·응답 객체 구조를 확인해 내부 공통 스키마로 정규화하는 것이 좋습니다.

비용 상한은 장애 대응의 일부다

장애가 나면 보통 성공률만 보게 되지만, 운영팀 입장에서는 비용 폭주도 장애입니다. 예를 들어 timeout 뒤 자동 retry, fallback, 병렬 호출이 겹치면 한 사용자 요청이 여러 번 과금될 수 있습니다.

그래서 비용 상한은 아래처럼 계층적으로 두는 편이 안전합니다.

• 요청당 최대 호출 수
• 기능별 일일 예산
• 테넌트별 월간 예산
• 고비용 경로 진입 전 승인 또는 축소 모드
• 장애 시 저비용 모드 강제 전환

OpenAI 문서에 GPT-5.5, GPT-5.4 mini, GPT-5.4 nano처럼 복잡도와 비용/지연 특성이 다른 모델 선택 흐름이 보이는 점은, 운영 설계에서 업무 중요도별 모델 계층화가 가능하다는 힌트를 줍니다. 다만 구체 가격이나 성능 수치는 이 글에서 단정하지 않으며, 실제 적용 전 공식 가격/모델 문서를 별도 확인해야 합니다.

지금 할 일과 미룰 일

지금 바로 할 일:

• 공통 LLM 래퍼를 만든다
• 출력 타입을 텍스트와 JSON으로 먼저 분리한다
• retry는 기본 0 또는 1회로 시작한다
• fallback 전후를 모두 로그에 남긴다
• 요청당 비용 상한과 최대 호출 수를 둔다
• 사용자에게 보여줄 실패 문구를 준비한다

미뤄도 되는 일:

• 초반부터 모든 벤더 고급 기능 통합
• 실시간 병렬 다중 벤더 경쟁 호출
• 지나치게 복잡한 품질 점수 모델
• 장애가 거의 없는 내부 도구에 대한 과한 failover

이 순서를 지키면 과설계를 줄이면서도, 실제 장애가 났을 때 대응 가능한 최소 운영선을 만들 수 있습니다.

구현 체크리스트

• 기능별로 고객 노출 여부와 자동 실행 여부를 분리했는가
• 요청 목적별 출력 계약을 정의했는가
• 자유 텍스트와 structured output 검증 경로를 분리했는가
• retry 가능한 실패와 금지해야 할 실패를 나눴는가
• fallback 전에 schema 또는 결과 유효성 검사를 하는가
• 벤더별 응답을 내부 공통 포맷으로 정규화하는가
• 요청당 최대 호출 수와 예산 상한이 있는가
• timeout 시 사용자 경험 문구가 준비되어 있는가
• tool 실패와 모델 실패를 다른 이벤트로 기록하는가
• 장애 시 저비용 모드 또는 축소 모드로 전환할 수 있는가

리스크와 한계

멀티 LLM 장애 우회 설계에도 한계는 분명합니다.

첫째, 벤더를 늘린다고 품질 일관성이 자동으로 좋아지지 않습니다. 오히려 출력 형식과 문체 차이로 후처리 복잡도가 커질 수 있습니다.

둘째, 공식 문서가 존재하더라도 각 벤더의 최신 응답 객체, 에러 체계, 제한 정책은 계속 바뀔 수 있습니다. 따라서 공통 추상화 계층은 필요하지만, 벤더별 세부 기능을 완전히 숨기려 하면 디버깅이 어려워질 수 있습니다.

셋째, structured output이 가능하다는 사실과 실제 운영에서 항상 안정적으로 같은 스키마가 나온다는 것은 다른 문제입니다. 검증 실패 시 안전 중단 경로가 반드시 필요합니다.

넷째, fallback은 장애를 숨길 수는 있어도 원인을 해결하지는 못합니다. 로그와 추적이 약하면 장애가 장기화됩니다.

확인한 공식/기준 출처

아래는 이 글에서 직접 확인한 공식 또는 기준 출처입니다.

• OpenAI API Docs: https://platform.openai.com/docs
• Anthropic Claude Docs: https://docs.anthropic.com/
• Gemini API Docs: https://ai.google.dev/gemini-api/docs

출처가 말한 사실과 이 글의 해석을 구분하면 다음과 같습니다.

• 공식 출처 사실: OpenAI 문서에는 responses.create 기반 빠른 시작, Responses API, Structured Outputs, Agents SDK, 여러 모델 선택 흐름이 포함됩니다.
• 적용 해석: 따라서 장애 대응은 단순 텍스트 생성이 아니라 structured output, tool, workflow 단위로 실패를 분리해 설계해야 합니다.
• 공식 출처 사실: Anthropic과 Gemini도 각각 공식 API 문서를 제공합니다.
• 적용 해석: 멀티 벤더 운영 시에는 각 문서의 최신 요청/응답 구조를 대조해 내부 공통 계약을 만드는 방식이 안전합니다.

FAQ

fallback은 처음부터 꼭 넣어야 하나요?

아닙니다. 고객이 직접 보는 핵심 기능이거나 자동 실행 리스크가 큰 기능이면 초기에 넣는 편이 좋지만, 내부 생산성 도구라면 먼저 로깅과 비용 상한부터 두는 것이 더 실용적입니다.

retry는 몇 번이 적당한가요?

이 글의 기준은 보수적으로 시작하는 것입니다. 읽기 성격 요청은 짧게 1회 정도를 검토할 수 있지만, 후속 쓰기 작업이 붙는 요청은 멱등성 없이 재시도하지 않는 편이 안전합니다.

OpenAI, Claude, Gemini를 같은 인터페이스로 완전히 감싸면 되나요?

완전 추상화는 편해 보이지만 디버깅과 고급 기능 활용을 어렵게 만들 수 있습니다. 공통 계약은 만들되, 벤더별 원본 응답과 에러 정보도 함께 보존하는 구조가 좋습니다.

structured output을 쓰면 장애 대응이 쉬워지나요?

일부는 그렇지만, 스키마 검증 실패라는 새로운 실패 유형이 생깁니다. 따라서 JSON schema를 기대하는 기능은 fallback보다 먼저 검증 실패 시 안전 중단 경로를 준비해야 합니다.

비용 제한은 장애 대응과 별개 아닌가요?

별개가 아닙니다. timeout 후 retry와 fallback이 겹치면 한 요청이 여러 번 과금될 수 있으므로, 비용 상한은 복원력 설계의 핵심 요소입니다.

결론

한국 개발팀이 LLM 기능을 운영에 넣을 때 가장 먼저 해야 할 일은 벤더 추가가 아니라 실패 분류 체계와 공통 계약 정의입니다. 그 위에 retry, structured output 검증, 비용 상한, fallback을 순서대로 쌓아야 장애와 품질 변동을 함께 다룰 수 있습니다. 공식 문서에서 확인되는 기능 범위를 기준으로 설계하고, 최신 세부 사양은 각 벤더 문서에서 구현 직전에 다시 대조하는 습관이 가장 현실적인 운영 전략입니다.