Netflix가 LLM API 요금을 버렸다: 자체 서빙 스택 vLLM + Triton로 전환한 진짜 이유

한눈에 보기

• 공개 시점: Netflix AI Platform Model Runtime 팀 · Inference 팀, 2026년 7월 17일
• 핵심 선택: hosted LLM API에 머물지 않고 vLLM + Triton + OpenAI 호환 API로 자체 풀스택 서빙을 직접 운영
• 가장 흥미로운 장면: constrained decoding을 decode loop 안으로 끌어들인 뒤, vLLM V0에서 V1로 엔진을 한 번 더 갈아엎으며 CPU 병목을 해소
• 숨은 운영 비용: 전환 기간에는 GPU 비용이 일시적으로 오를 수 있어 변동 설정(variable configurations) 설계를 권장
• 실무 메시지: 오픈소스 엔진을 가져다 쓰는 일은 설치가 아니라 마이그레이션을 반복하는 과정
• 한국 시사점: 콘텐츠 추천과 실시간 개인화에 지연이 민감한 국내 플랫폼이 가장 먼저 참고할 만한 인프라 판단 기준

서론: 왜 Netflix는 API 요금표를 그냥 넘기지 않았나

대부분의 회사는 LLM을 쓸 때 한 줄의 API 호출로 시작한다. OpenAI, Anthropic, 구글 같은 호스팅 API에 요청을 던지고, 돌아온 텍스트를 가져다 쓰는 방식이다. 설치가 필요 없고, 인프라를 직접 돌릴 부담도 없다. Netflix도 처음엔 크게 다르지 않았다. 그런데 2026년 7월 17일, Netflix의 AI 플랫폼 팀은 In-House LLM Serving at Netflix라는 글에서 묘한 고백을 한다. "대부분의 조직은 hosted API로 LLM을 소비한다. Netflix는 한 발 더 나아갔다"는 문장으로 시작하는 이 글은, 사실상 "API 요금표을 그냥 받아들이기엔 우리 워크로드가 너무 까다롭다"는 선언에 가깝다.

이 글이 흥미로운 이유는 단순히 "우리도 자체 인프라를 짰다"는 자랑이 아니기 때문이다. Netflix 팀은 엔진을 왜 바꿨는지, 첫 번째 선택에서 무엇이 부족했는지, 그리고 결국 두 번째 엔진까지 갈아엎으며 찾은 답이 무엇인지를 솔직하게 적어 내려간다. 이 요약글은 원문을 줄줄이 옮기는 대신, 한국 개발자와 인프라 설계자가 "우리도 저런 판단을 해야 할 때가 올까?"라는 질문에서 시작해 읽을 수 있도록 의미 있는 흐름으로 다시 짰다.

API를 버린 건 비용 절감 하나 때문이 아니다. 낮은 지연, 깊은 커스터마이징, 기존 프로덕션 환경과의 통합까지 모두 사내에서 통제하려는 선택이었다

1. Netflix가 자체 서빙 스택을 고집한 네 가지 이유

Netflix 팀이 자체 LLM 서빙 플랫폼을 만들겠다고 마음먹은 배경은 단일하지 않다. 원문은 "광범위한 프로덕션 ML 요구를 위한 LLM 서빙 플랫폼을 구축하려 했다"고 밝히며, 그 요구 사항을 낮은 지연, 깊은 커스터마이징, 기존 프로덕션 환경과의 통합이라는 세 축으로 정리한다. 이를 한국 실무자의 언어로 풀면 다음처럼 읽힌다.

• 낮은 지연: 추천과 검색처럼 사용자가 결과를 기다리는 화면에서는 토큰이 늦게 나오는 것 자체가 체류 이탈로 이어짐
• 깊은 커스터마이징: JSON 스키마 같은 제약 출력(constrained decoding)을 쓸 때, 디코딩 과정을 직접 건드릴 수 없으면 품질이 흔들림
• 프로덕션 통합: Netflix의 기존 ML 플랫폼과 관측성, 배포, 권한 체계를 그대로 끌어다 쓰려면 서빙 스택도 사내에 있어야 함
• 비용 통제: 종량제 API 요금은 트래픽이 커질수록 예측이 어려워지고, 자체 GPU를 쓰면 단위 비용을 직접 설계할 수 있음

이 네 가지는 각각이 따로 떨어져 있는 게 아니다. 하나를 잡으면 다른 하나가 흔들리는 줄다리기다. 예컨대 지연을 낮추려고 배치 크기를 줄이면 GPU 활용도가 떨어지고, 비용을 줄이려고 배치를 키우면 지연이 길어진다. Netflix가 결국 내린 결론은 "이 균형을 외부 API에 맡기지 않겠다"는 것이었고, 그 결과물이 이 글이 설명하는 자체 스택이다.

2. 전체 스택 구조: API부터 GPU까지 한 줄로 읽기

Netflix의 자체 스택은 클라이언트에서 GPU까지 일직선으로 읽힌다. 흐름을 단순화하면 이렇다.

1. 클라이언트: 사내 앱, 추천 시스템, 검색, 에이전트가 OpenAI SDK 그대로 호출
2. API 게이트웨이: OpenAI 호환 형식으로 라우팅, 인증, 과금 처리
3. 서빙 프레임워크: vLLM을 backend로 감싸 로깅·메트릭·캐싱을 한 곳에서 관리
4. 추론 서버: Triton이 모델 라이프사이클과 GPU 스케줄링을 맡음
5. vLLM 엔진: continuous batching과 PagedAttention, 그리고 커스텀 디코딩을 decode loop 안에서 처리
6. GPU 클러스터: 가중치는 FSx에 캐싱해 콜드 스타트를 줄이고 레플리카 교체를 빠르게 만듦

OpenAI 호환 API를 끌어들인 것이 눈에 띈다. 클라이언트를 고치지 않고도 백엔드를 바꿀 수 있게 만든 실용적 선택이다

이 구조에서 눈길을 끄는 디테일은 의외로 단순한 곳에 있다. 바로 OpenAI 호환 API를 표준으로 삼았다는 점이다. Netflix 팀은 API 형식을 사내 독자 규격으로 짜지 않았다. 대신 업계 사실상 표준이 된 OpenAI의 스키마를 그대로 가져갔다. 이 결정이 중요한 이유는 클라이언트 쪽 코드를 거의 고치지 않고도 백엔드 엔진을 바꿀 수 있게 만들었기 때문이다. "처음부터 우리 규격으로 짰어야 했나?"라고 묻는 독자에게 Netflix의 답은 "아니, 호환성이 더 싸다"에 가깝다.

3. vLLM을 고른 이유와 silent API gap이라는 함정

서빙 엔진 선택은 이 글의 첫 번째 큰 갈림길이다. Netflix는 처음에 NVIDIA의 TensorRT-LLM을 검토했지만, 결국 vLLM을 메인 엔진으로 가져갔다. 원문이 강조하는 이유는 유연성과 커뮤니티, 그리고 제약 출력을 직접 다룰 수 있는 여지다. TensorRT-LLM이 성능 한 점에선 강하지만, Netflix처럼 디코딩 과정을 깊이 건드려야 하는 워크로드에서는 제약이 더 크게 다가왔던 셈이다.

하지만 vLLM을 가져왔다고 끝이 아니었다. 글이 솔직하게 인정하는 함정이 하나 있다. 바로 silent API gap이다. vLLM이 제공하는 API와 사내 서빙 프레임워크가 기대하는 API 사이에는 보이지 않는 빈틈이 있었고, 이 빈틈은 가끔 에러로 드러나지 않고 조용히 잘못된 동작으로 나타났다. Netflix 팀은 이 빈틈을 찾아내 일일이 패치하는 작업을 "엔진 선택"의 숨은 비용이라고 부른다.

이 부분을 읽으면서 든 생각은 단순하다. 오픈소스 엔진을 "설치했다"고 끝나는 일은 없다는 것. 엔진이 가진 기본 API가 여러분의 운영 기대와 얼마나 같은지를 확인하는 일 자체가 첫 주차의 본업이 된다.

4. 가장 흥미로운 장면: constrained decoding을 decode loop 안으로

원문 전체를 통틌어 가장 기술적으로 흥미로운 대목은 constrained decoding을 다루는 방식이다. 제약 출력, 즉 "모델이 반드시 이 JSON 스키마를 따르게 하라"는 요구는 API 형태로는 단순해 보이지만, 실제로는 디코딩 루프 안에서 토큰이 나올 때마다 허용되는 다음 토큰 집합을 제한하는 일이다.

Netflix 팀의 선택은 이 제약 검사를 decode loop 바깥에 두지 않고 안으로 밀어넣는 것이었다. 왜 이게 중요한가. 제약 검사가 바깥에 있으면 매 토큰마다 추가 왕복 비용이 들고, 그 비용이 쌓이면 결국 지연이 길어진다. 반대로 안으로 넣으면 디코딩 한 패스 안에서 검사까지 끝나므로 지연이 짧아진다. 다만 그만큼 엔진 코드를 직접 건드려야 하는 부담이 생긴다.

이 대목은 단순한 최적화 팁이 아니다. "출력 품질을 지연과 비용이라는 두 변수 위에서 어떻게 설계할 것인가"라는, 모든 LLM 서빙 팀이 결국 부딪히는 질문의 한 사례다.

5. 엔진을 한 번 더 갈아엎다: vLLM V0에서 V1로

여기서 이야기는 더 흥미로워진다. Netflix는 vLLM을 선택한 뒤에도 만족하지 못했다. V0라고 불리는 초기 버전에서는 파이썬 오버헤드 때문에 CPU 병목이 관찰됐다. GPU는 여유가 있는데 CPU가 먼저 지쳐서, GPU가 충분히 채워지지 않는 구간이 반복됐다는 이야기다. throughput은 기대보다 낮게 고정됐고, 단순한 설정 튜닝으로는 한계가 분명했다.

그래서 Netflix는 V1으로의 마이그레이션을 결심한다. V1은 스케줄러를 단순화하고 파이썬 사이클을 줄여 CPU에서 GPU로의 피딩을 매끄럽게 정렬한 구조다. 결과적으로 GPU 활용도가 오르고 단위 비용이 내려갔다. 커스텀 디코딩도 V1 구조에 맞춰 다시 이식됐다.

엔진 선택이 단발성 이벤트가 아니라는 걸 보여주는 장면이다. 첫 선택의 한계를 진단하고 두 번째 선택으로 넘어가는 과정 자체가 설계의 일부였다

이 장면이 중요한 이유는 단순히 "V1이 더 빠르다"가 아니기 때문이다. Netflix가 보여주는 태도는, 엔진 성능 비교를 benchmark 숫자로 끝내지 않고 실제 워크로드에서 CPU와 GPU 사이의 병목이 어디서 도는지 직접 측정한 뒤에 설계를 다시 열었다는 데 있다. 마이그레이션을 "한 번 하면 끝"이 아니라 "설계를 다시 여는 지속 과정"으로 다룬 것이다.

6. 모델 가중치 캐싱: FSx가 숨은 영웅인 이유

구조 이야기에서 자칫 지나치기 쉬운 디테일이 모델 가중치 캐싱이다. LLM 레플리카를 새로 띄울 때 가장 아픈 구간은 콜드 스타트다. 수십 기가바이트짜리 가중치를 원격 저장소에서 가져오면 그 시간 동안 GPU는 놀고, 비용은 새고, 지연은 튄다.

Netflix의 답은 FSx에 가중치를 캐싱해 두는 것이었다. 레플리카가 교체될 때 디스크에서 빠르게 가중치를 읽어 오도록 만들어, 콜드 스타트를 줄이고 배포 속도를 올렸다. 이 부분은 성능 수치로 크게 강조되진 않지만, 실 운영 관점에서는 GPU 비용과 직결되는 묵직한 선택이다.

한국 독자에게 이 대목은 특히 의미 있다. 국내에서도 대규모 모델을 자체 서빙하려는 팀이 늘고 있는데, 이런 팀이 가장 먼저 부딪히는 벽이 바로 "가중치를 어디에 어떻게 둘 것인가"이기 때문이다. FSx라는 특정 제품이 정답이 아니더라도, "가중치 캐싱 전략을 서빙 설계의 일등 시민으로 두라"는 원칙은 그대로 옮겨올 수 있다.

7. 배포 전략: Red-Black와 Versioned 사이의 줄다리기

LLM 서빙 인프라에서 배포는 단순한 "새 버전 올리기"가 아니다. Netflix는 두 가지 배포 전략을 놓고 고민을 적시며, 둘 중 하나를 단일 답으로 고르지 않았다.

• Red-Black 배포: 동일 규모의 신규 클러스터를 미리 띄워두고 트래픽을 한 번에 전환. 문제가 생기면 이전 환경으로 즉시 롤백할 수 있다. 대신 전환 기간 동안 GPU 자원이 두 배로 필요하다
• Versioned 배포: 새 버전을 점진적으로 늘려가며 단계별로 트래픽 비율을 조정. GPU 비용 증가를 흡수할 수 있지만, 롤백은 상대적으로 느리다

정답이 하나가 아니라는 게 핵심이다. 모델 중요도와 전환 기간을 변수로 두고 두 전략을 섞어 쓴다는 점이 실사용 인프라의 현실적인 판단을 보여준다

Netflix의 판단은 흥미롭다. 두 전략 중 하나를 고르지 않고, 모델 중요도와 전환 기간을 변수로 두어 혼합 운영한다. 중요한 모델을 바꿀 때는 Red-Black로 즉시 롤백 가능성을 사고, 잦은 업데이트가 필요한 모델은 Versioned로 비용을 흡수한다. 그리고 이 과정에서 전환 중에 일시적으로 GPU 비용이 오르는 걸 기꺼이 받아들이는 대신 가용성을 산다고 적는다.

이 대목은 비용과 가용성이 단순한 트레이드오프가 아니라, "어떤 모델이 터졌을 때 얼마나 아픈가"라는 비즈니스 질문으로 환원된다는 걸 보여준다. 순수한 엔지니어링 판단이 아니라는 뜻이다.

8. 원문이 경고하는 숨은 비용: 전환 중 GPU 비용과 variable configurations

이 글에서 가장 한국 독자에게 유용한 경고 중 하나는 전환 비용에 관한 것이다. Netflix는 자체 스택으로 옮기는 동안 일시적으로 GPU 비용이 증가하는 구간이 생긴다고 솔직하게 밝힌다. 새 환경을 띄우는 동안에도 기존 환경을 당장 끌 수 없기 때문이다.

이 상황에서 원문이 권장하는 실천 항목이 variable configurations, 즉 변동 설정을 엔진 설정에 포함하라는 것이다. 환경마다, 전환 단계마다 다른 값을 유연하게 넣을 수 있도록 설정 구조를 짜두라는 권고다. 이렇게 해야 전환 중 발생하는 비용과 리스크를 단계적으로 통제할 수 있다.

이 조언은 단순해 보이지만 실무에선 자주 무시된다. "한 번에 설정을 고정하고 끝내겠다"는 접근은 초기엔 깔끔해 보이지만, 전환이 길어지면 어디서 비용이 새는지조차 파악하기 어려워진다. Netflix가 남기는 교훈은, 인프라 전환은 "끝내는" 이벤트가 아니라 "통제하는" 과정이라는 것이다.

9. 통합 메트릭과 관측성: 보이지 않는 것을 재는 도구

마지막으로 눈에 띄는 운영 디테일은 통합 메트릭 endpoint다. Netflix는 각 모델 인스턴스가 자기 상태를 한 곳으로 보고하도록 단일 endpoint를 만들었다. 이게 왜 중요한가. LLM 서빙은 단일 숫자로 "잘 되고 있다"고 말하기 어렵기 때문이다.

• p99 지연: 사용자가 체감하는 느림의 진짜 지표
• GPU 활용도: 비용이 새는 구간을 찾는 첫 단서
• 처리량(throughput): 단위 GPU당 얼마나 일하고 있는지
• 에러율과 silent gap: 조용히 잘못되는 경우를 잡는 신호

이 네 가지를 한 곳에서 볼 수 있어야 "엔진을 갈아엎는 결정"을 데이터로 내릴 수 있다. Netflix가 V0에서 V1으로 넘어갈 수 있었던 것도, CPU 병목이라는 보이지 않는 현상을 메트릭으로 먼저 잡아냈기 때문이다. 관측성 없는 마이그레이션은 그냥 도박에 가깝다.

10. 우리에게 남는 의미: 한국 플랫폼이 가져갈 판단 기준

Netflix 글은 자사 인프라 이야기지만, 한국의 플랫폼 기업과 개발팀에도 명확한 질문을 던진다. 원문에 등장하는 한국 관련 조직 언급은 이 요약에서 의도적으로 빼고, 대신 "우리에게 의미 있는 질문"으로 바꿔 적었다.

• 직접 수혜 가능 그룹: 콘텐츠 추천, 실시간 검색, 에이전트처럼 지연에 민감한 서비스를 운영하는 국내 플랫폼. 종량제 API 비용이 한도에 부닥치는 지점에서 자체 서빙 검토가 자연스러운 팀
• 간접 연결 그룹: GPU 클라우드 사업자, 모델 최적화·양자화 도구를 만드는 국내 스타트업. 자체 서빙 수요가 늘면 가중치 캐싱과 추론 최적화 수요도 함께 자란다
• 판단 기준: 단순히 "API가 비싸서"가 아니라, (1) 지연 민감도, (2) 제약 출력 필요성, (3) 기존 프로덕션 ML과 통합 여부, (4) GPU 자원 확보 가능성을 변수로 두어야 함

여기에 주의할 점이 있다. Netflix 글은 단일 1차 자료 기준의 사례 보고서다. 본문에 등장하는 구체적인 수치는 공식 원문과 GitHub의 공개 자료를 교차해 확인할 수 있는 범위로 읽어야 하며, 정확한 throughput이나 비용 절감률은 Netflix가 별도로 공개하지 않는 한 보수적으로 해석해야 한다. "Netflix처럼 하면 된다"가 아니라 "Netflix가 저런 변수들을 가지고 고민했다"를 옮겨오는 것이 안전한 읽기다.

결론: API 요금표 너머로 갈 것인가

Netflix의 글을 다 읽고 나면 드는 생각은 단순하다. "우리도 저렇게 해야 하나?" 정답은 "상황에 따라 다르다"다. Netflix처럼 지연에 민감하고, 디코딩을 깊이 건드려야 하고, 기존 ML 인프라가 큰 조직이라면 자체 스택은 합리적 선택이다. 반대로 초기 단계의 서비스라면, hosted API의 종량제 비용이 매월 올려 주는 관측성과 운영 편의성을 포기할 만큼 크지 않을 수 있다.

다만 이 글이 모든 독자에게 주는 확실한 교훈이 하나 있다. 오픈소스 엔진을 가져다 쓰는 일은 설치가 아니라 마이그레이션의 반복이라는 것. Netflix가 보여준 태도, 즉 첫 번째 선택의 한계를 진단하고 두 번째 선택으로 넘어가며 그 사이의 비용과 리스크를 통제하는 과정 자체가, 자체 LLM 서빙의 진짜 모습이다. 그 과정까지 감당할 수 있는 조직에게만 API 요금표 너머의 세계가 열린다.

참고 자료

• In-House LLM Serving at Netflix - Netflix TechBlog, AI Platform Model Runtime · Inference 팀, 2026년 7월 17일
• Netflix Technology Blog (Medium) - Netflix 공식 기술 블로그
• vLLM 공식 문서 - vLLM 프로젝트
• NVIDIA TensorRT-LLM 저장소 - NVIDIA, 비교 참고용
• NVIDIA Triton Inference Server - NVIDIA 공식 문서