LLM 게이트웨이를 버리고 인프라 자체에 복원력을 넣는 흐름

왜 지금 이 이야기인가

Hacker News Show HN에 LLM 호출 프레임워크인 vernLLM이 올라왔어요. 핵심 주장은 단순해요. LLM 게이트웨이를 거치지 말고, 호출 프로세스 자체에 rate-limit, 회로차단기, 폴백, 캐시, 미들웨어를 넣자는 거죠. 2026년 9월 현재도 많은 팀이 LLM 트래픽을 전용 게이트웨이로 집계하는 구조를 쓰고 있으니, 이 대안이 실현 가능한지 살펴볼 가치가 충분해요.

기존 게이트웨이 구조는 어땠나

게이트웨이는 제공업체마다 단일 엔드포인트를 앞세워 요청을 받고, 인증·할당량·프롬프트 필터링을 중앙에서 처리해요. 장점은 통제가 한 곳에 모인다는 점이에요. 문제는 그 중앙 노드가 장애 포인트가 되기 쉽다는 거죠. 게이트웨이 부하가 늘어나면 지연이 생기고, 게이트웨이 측 오류가 LLM 호출 실패로 그대로 전파돼요. 특히 여러 제공업체를 섞어 쓰는 멀티 모델 환경에서는 라우팅 규칙이 복잡해지고, 제공업체별 재시도·타임아웃 정책을 한 곳에 맞추기도 어려워요.

vernLLM이 바꾸려는 점

LakBud/vernLLM은 애플리케이션 프로세스 안에서 LLM 호출을 직접 제어하는 프레임워크를 표방해요. OpenAI, Anthropic, Gemini, AWS Bedrock 등 여러 제공업체를 하나의 인터페이스로 감싸고, 그 위에 재시도, 회로차단, 폴백, 속도 제한, 캐시, 미들웨어를 기본으로 넣었어요. 코드 예시를 보면 fromOpenAI, fromAnthropic 같은 어댑터로 클라이언트를 감싼 뒤 VernLLM 인스턴스에서 모델, 폴백 모델, rateLimit, retryBudget, maxRetries, timeoutMs 같은 값을 설정하는 구조예요.

이 구조의 차이는 네트워크 홉이 줄어든다는 점이에요. 게이트웨이를 거치지 않으니 왕복 지연이 짧아지고, 호출자가 직접 제공업체를 바꿀 수 있으니 장애 전파 경로가 단순해져요. 또 in-process 방식이라 로그·메트릭·미들웨어 삽입이 애플리케이션 계층에서 바로 가능해요.

관측성과 복원력은 어떻게 달라지나

게이트웨이 모델은 중앙 로그 하나로 모든 LLM 트래픽을 볼 수 있다는 장점이 있지만, 그 로그 자체가 단일 장애점이 되기도 해요. vernLLM 방식은 관측 포인트가 분산되고, 애플리케이션 단에서만 볼 수 있는 문맥이 함께 기록돼요. 예를 들어 특정 사용자 세션 안에서 어떤 폴백이 실행됐는지, rate-limit으로 인해 요청이 지연된 시간은 얼마인지, 회로차단기가 열린 구간은 어디인지 등을 호출 컨텍스트와 함께 파악하기 쉬워져요.

속도 제한과 회로차단의 의미도 조금 달라져요. 게이트웨이는 보통 제공업체 전체 요청 수를 기준으로 제한하는 반면, in-process 방식은 애플리케이션별로 더 세밀하게 제한할 수 있어요. 재시도 예산 windowMs, minCalls, retryRatio 같은 개념은 제공업체 임계값을 넘기기 전에 애플리케이션 쪽에서 먼저 요청을 조절하려는 의도로 읽혀요.

실제 도입 때 고려할 점

이 방식이 모든 환경에 맞는 것은 아니에요. 제공업체 키를 애플리케이션 서비스에 직접 배포해야 하니 키 회전·격리·권한 관리 책임이 애플리케이션 계층으로 넘어가요. 또 게이트웨이가 제공하던 프롬프트 필터링·사용자 정책 적용 기능을 직접 구현해야 할 수 있어요. 다중 서비스 환경에서는 각 서비스가 독자적으로 재시도 정책을 가지면 전체 시스템의 부하 곡선이 예측하기 어려워질 수도 있고요.

그래서 vernLLM은 게이트웨이의 모든 기능을 대체하는 도구라기보다, 호출 프로세스 안에 복원력을 직접 심는 대안 패턴으로 보는 게 맞아요. 특히 멀티 제공업체 폴백, 제공업체별 라우팅, in-process 속도 제한이 중요한 서비스라면 검토할 만한 접근이에요.

이 아이디어가 가지는 의미

LLM 트래픽이 늘수록, 장애 대응과 관측성은 선택이 아니라 기본 요구사항이에요. vernLLM이 보여주는 패턴은 LLM을 외부 API 하나로 보는 관점에서, 애플리케이션 계층에서 복원력을 설계하는 관점으로 이동하는 흐름과 맞닿아요. 이번 Show HN 글은 프레임워크 소개 이상으로, 현재 LLM 인프라 설계에서 논의가 필요한 질문을 던져주고 있어요.