단일 AI 제공업체에 의존하는 것을 그만둔 이유
커뮤니티 포럼을 위한 실시간 챗봇을 만들었습니다. API 하나만 사용하면 충분할 것이라고 생각했습니다. 하지만 제 착각이었습니다.
3주 차에 접어들었을 때, 피크 시간대에 5xx 에러가 발생했습니다. 챗봇이 먹통이 되었습니다. 사용자들은 불만을 터뜨렸습니다. 저는 프로덕션 앱을 운영할 때 단 하나의 제공업체만 믿어서는 안 된다는 것을 깨달았습니다.
GPT-4를 사용했습니다. 잘 작동하다가 어느 순간 문제가 생겼습니다. 속도 제한(rate limits), 타임아웃, 그리고 완전한 서비스 중단을 겪었습니다. 더 높은 티어의 요금제를 결제하는 것은 문제의 근본 원인을 해결하는 것이 아니라 증상만 완화하는 것처럼 느껴졌습니다.
다른 제공업체들도 시도해 보았지만, 모두 데이터 형식과 인증 방식이 달랐습니다. 제 코드는 switch-case 문으로 엉망이 되었습니다. 저는 다음과 같은 기능을 갖춘 시스템이 필요했습니다:
- 제공업체 간의 차이점 숨기기.
- 장애 발생 시 백업 제공업체로 전환하기.
- 응답 캐싱하기.
- 특정 업체 종속(vendor lock-in) 방지하기.
서드파티 라이브러리는 너무 복잡하고 쉽게 깨지기 때문에 사용하지 않았습니다. 대신 간단한 라우터를 직접 만들었습니다.
먼저, 모든 제공업체를 위한 공통 인터페이스를 정의했습니다. 각 제공업체는 generate 메서드와 헬스 체크(health check)를 구현합니다.
그다음, 라우터 클래스를 구축했습니다. 이 클래스는 특정 순서에 따라 제공업체를 시도합니다. 지수 백오프(exponential backoff)와 간단한 캐시를 사용합니다. 첫 번째 제공업체가 실패하면 시스템은 잠시 대기한 후 다음 제공업체를 시도합니다.
이 시스템 덕분에 세 번의 서비스 중단 사태 동안 주말을 지킬 수 있었습니다. 주요 제공업체가 다운되더라도 제 앱은 계속 작동합니다.
만약 이 시스템을 구축한다면, 다음 사항들을 유념하세요:
- 프로덕션 환경에서는 로컬 딕셔너리 대신 Redis를 캐싱에 사용하세요.
- 헬스 체크가 성공을 보장하지는 않습니다. 제공업체가 체크는 통과하더라도 실제 요청에서는 실패할 수 있습니다.
- 속도 제한을 적절히 처리하려면
Retry-After헤더를 파싱하세요. - 비용 추적을 위해 토큰 사용량에 대한 로깅을 추가하세요.
- 더 높은 성능을 위해
asyncio를 사용하세요.
프로젝트 규모가 작다면 과도하게 설계(over-engineer)하지 마세요. 스트리밍이 필요하다면 이 패턴은 지연 시간(latency)을 추가할 수 있습니다. 규모에 맞는 적절한 도구를 선택하세요.
여러분은 제공업체의 신뢰성 문제를 어떻게 해결하시나요? 하나의 제공업체만 고수하시나요, 아니면 폴백(fallback) 레이어를 구축하시나요?
Optional learning community: https://t.me/GyaanSetuAi