LLM 공급자 추상화 — OpenAI가 내려가도 시스템은 살아야 한다
한줄 요약
전기 콘센트는 어느 나라 제품을 꽂든 같은 방식으로 작동한다. LLM 공급자 추상화는 AI 시스템에 그런 콘센트를 만드는 작업이다.
본문
2024년 11월, OpenAI 장애
2024년 11월 OpenAI API에 대규모 장애가 발생했다. 수천 개의 서비스가 동시에 마비됐다.
OpenAI에만 의존하던 서비스들은 장애 시간 동안 완전히 멈췄다. OpenAI와 Anthropic, Google 등 여러 공급자를 연결해둔 서비스들은 자동으로 다른 공급자로 전환했다.
차이를 만든 것은 단순한 아키텍처 설계 하나였다. LLM 공급자를 추상화했느냐, 하지 않았느냐.
단일 공급자 의존의 문제
대부분의 AI 시스템이 시작할 때 이런 식으로 만들어진다.
사용자 요청 → 코드 → OpenAI API → 응답처음에는 단순하고 빠르게 만들 수 있어서 좋다. 하지만 시스템이 커지고 프로덕션에 올라가면 문제가 생긴다.
문제 1 — 단일 장애점 OpenAI가 다운되면 전체 서비스가 다운된다. 의료 AI라면 의사들이 시스템을 사용할 수 없게 된다.
문제 2 — 비용 협상력 없음 Anthropic이 더 저렴한 모델을 출시했다. 하지만 코드 전체가 OpenAI에 종속돼 있다면 교체 비용이 크다.
문제 3 — 모델 락인 GPT-4가 특정 작업에서 Claude보다 좋고, Claude가 다른 작업에서 더 좋다는 것을 발견해도, 작업별로 모델을 최적화하기가 어렵다.
LLM 추상화 레이어
핵심 아이디어는 단순하다. 코드가 특정 공급자 API를 직접 호출하는 대신, 공통 인터페이스를 통해 호출한다. 공통 인터페이스 뒤에서 어떤 공급자를 쓸지는 설정으로 결정한다.
코드 → [LLM 추상화 레이어] → OpenAI
↘ Anthropic
↘ Google
↘ 로컬 모델 (Ollama 등)코드는 항상 같은 방식으로 LLM을 호출한다. 어떤 공급자를 쓸지는 코드 밖에서 결정한다.
이미 만들어진 추상화 라이브러리들이 있다:
- LiteLLM: 100개 이상 모델을 동일한 API로 호출
- LangChain: ChatModel 인터페이스로 공급자 전환
- 자체 구현: 내부 표준화가 필요한 경우
폴백(Fallback) 설계
추상화 레이어에 폴백 로직을 추가하면 장애 대응이 자동화된다.
1차: GPT-4o (기본 모델)
↓ 실패 또는 3초 초과
2차: Claude 3.5 Sonnet (폴백 1)
↓ 실패 또는 3초 초과
3차: Gemini Flash (폴백 2, 비용 저렴)
↓ 실패
4차: 캐시된 응답 반환 또는 "잠시 후 다시 시도해주세요" 안내의료 AI에서 폴백 설계 시 주의할 점:
- 모델 간 능력 차이 고려: GPT-4o에서 Gemini Flash로 폴백할 때 응답 품질이 달라질 수 있다. 중요한 임상 케이스에서는 더 작은 모델로 폴백하지 않는 규칙을 설정하거나, 폴백 사실을 UI에 표시한다.
- 같은 프롬프트가 다르게 작동: 공급자마다 프롬프트 해석 방식이 다르다. 폴백 모델에서도 시스템 프롬프트가 제대로 작동하는지 별도 테스트가 필요하다.
모델 라우팅 — 작업별 최적 모델 선택
추상화 레이어는 단순 폴백을 넘어 작업별로 최적 모델을 자동 선택하는 라우팅에도 쓸 수 있다.
요청 분류
↓
단순 질문 (FAQs, 일정) → GPT-3.5-turbo (빠름, 저렴)
임상 의사결정 지원 → GPT-4o (정확도 우선)
복잡한 문서 분석 → Claude 3.5 Sonnet (긴 컨텍스트)
한국어 의료 문서 → 한국어 특화 모델오케스트레이션 비용 최적화에서 다뤘듯, 모든 요청에 가장 비싼 모델을 쓸 필요가 없다. 추상화 레이어가 있으면 이 라우팅 로직을 중앙에서 관리할 수 있다.
온프레미스 + 클라우드 하이브리드
의료 데이터 보안을 위해 온프레미스(병원 내부 서버)에서 모델을 운영하는 경우도 있다.
추상화 레이어가 있으면 이 구성도 자연스럽게 지원된다.
PHI(환자 개인정보) 포함 요청 → 병원 내부 로컬 모델
익명화된 데이터 요청 → 외부 클라우드 APIPHI가 포함된 요청은 외부로 나가지 않는다. 익명화된 요청은 더 강력한 클라우드 모델을 활용한다. 이 분기 로직도 추상화 레이어에서 처리한다.
추상화 레이어를 직접 만들 때
외부 라이브러리 대신 간단한 추상화를 직접 만들 수도 있다. 핵심은 세 가지:
- 공통 인터페이스: 어떤 공급자를 쓰든 호출 방식이 같아야 함
- 설정 기반 전환: 코드 수정 없이 환경 변수로 모델 교체 가능
- 오류 표준화: 각 공급자의 오류 메시지를 공통 형식으로 변환
복잡하게 만들 필요 없다. 처음에는 두 공급자만 지원해도 충분하다. 추상화 레이어 자체가 있느냐 없느냐가 핵심이다.
더 알고 싶다면
🔗 관련 글
- 오케스트레이션 비용 최적화 — 모델 계층화로 비용을 줄이는 전략
- 에러 핸들링 — API 장애 시 에러 처리 전략
- AI 시스템 배포 전략 — 모델 교체 시 안전한 배포 방법
- 오케스트레이션 모니터링 — 공급자별 응답 품질과 비용 모니터링