LLM 게이트웨이 대신 호출 프로세스에 복원력을 넣는 vernLLM

왜 지금 이 이야기인가

Hacker News Show HN에 LLM 호출 프레임워크인 vernLLM이 올라왔어요. 핵심 주장은 단순해요. LLM 게이트웨이를 거치지 말고, 호출 프로세스 자체에 rate-limit, 회로차단기, 폴백, 캐시, 미들웨어를 넣자는 거죠. 아직 스타가 몇 개 안 되는 초기 프로젝트라서 업계 흐름이라고 말하기는 이르지만, 게이트웨이와 라이브러리 중 어디에 복원력을 둘지는 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 속도 제한이 중요한 서비스라면 검토할 만한 접근이에요.

인스턴스가 여러 개가 되면 생기는 문제

in-process 방식의 가장 큰 약점은 상태가 프로세스마다 따로 있다는 점이에요. README에 따르면 rate limit은 기본이 프로세스 단위(requestsPerMinute, tokensPerMinute, maxConcurrent)이고, 회로차단기·캐시·속도 제한을 여러 인스턴스가 공유하려면 별도 패키지인 vern-llm-redis로 Redis를 붙여야 해요. 관측성도 비슷해요. OpenTelemetry 트레이스와 메트릭은 vern-llm-otel로 따로 붙여야 하고, 그러지 않으면 호출 기록이 서비스마다 흩어져요.

이를 숫자로 풀어 보면 이런 식이에요. 제공업체가 계정 전체에 분당 요청 한도를 건다고 할 때, 프로세스마다 분당 100개로 제한하더라도 인스턴스가 10개면 합계 1,000개가 나가요. 한도를 넘기는 걸 막으려면 공유 저장소를 쓰거나, 인스턴스 수로 나눈 값을 각자에게 설정해야 해요. 오토스케일링으로 인스턴스 수가 변하는 환경이라면 후자는 맞추기 어려워요. 이 계산은 필자가 README의 구조를 바탕으로 든 예시이고, vernLLM의 실제 동작을 측정한 결과는 아니에요.

게이트웨이와 라이브러리 중 어디에 둘까

기준은 정책을 바꿀 때 누가 배포하느냐예요. 라이브러리 방식은 정책을 바꾸려면 각 서비스를 다시 배포해야 하지만, 게이트웨이는 한 곳만 고치면 돼요. 반면 게이트웨이는 장애 지점이 되고 네트워크 홉이 하나 늘어요. 서비스가 한두 개이고 팀이 작다면 라이브러리가 단순해서 유리하고, 서비스가 많고 키·정책을 보안팀이 중앙에서 통제해야 한다면 게이트웨이가 맞아요. 둘을 섞는 방법도 있어요. 게이트웨이는 키 관리와 정책에만 쓰고, 재시도·폴백은 호출 쪽 라이브러리에 두는 식이에요.

이 글은 README와 Show HN 소개를 읽고 구조를 정리한 거예요. 직접 설치해서 부하를 걸어 보거나 지연 시간을 잰 결과는 없어요. 도입을 고민한다면 먼저 폴백 전환과 회로차단기 동작을 자기 서비스의 오류 패턴으로 시험해 보는 게 안전해요.