2026년 7월, 넷플릭스가 자사 LLM 서빙 스택을 공개했다. 요약하면 '우리는 OpenAI API를 쓰지 않는다. 모델 배포부터 추론까지 전 과정을 우리 손으로 굴린다'이다. 대부분의 회사가 API 한 줄로 끝내는 시대에, 넷플릭스는 왜 굳이 인프라를 통째로 짊어졌을까? 이 특집 1부는 그 '왜'를 추천 시스템의 역사부터 2026년 인퍼런스 경제학까지 따라가며 답한다.
2026년 7월, 넷플릭스 기술 블로그에 「In-House LLM Serving at Netflix」라는 글이 올라왔다. AI 업계에서 곧바로 화제가 됐다. 내용을 한 줄로 줄이면 이렇다.
"우리는 LLM을 API로 빌려 쓰지 않는다. 모델 배포부터 추론, 출력 제어까지 전 과정을 우리 프로덕션 환경 안에서 직접 굴린다."
지금은 프롬프트 몇 줄과 API 키 하나면 세계 최고 수준의 LLM을 쓸 수 있는 시대다. 그런데 넷플릭스는 그 편한 길을 두고, vLLM과 NVIDIA Triton이라는 오픈소스 위에 서빙 플랫폼을 통째로 지어 올렸다. 왜?
이 특집은 그 이야기를 3부에 걸쳐 푼다.
1부인 이 글은 개념과 역사와 동기를 다룬다. vLLM이 뭔지, KV 캐시가 뭔지 같은 기술 용어는 2부에서 차근차근 풀 테니, 여기서는 편하게 "넷플릭스가 왜 이 고생을 사서 하는가"만 따라오면 된다.
먼저 용어 하나. 이 글 내내 서빙(serving) 또는 추론(inference) 이라는 말이 나온다. 어렵게 생각할 것 없다.
세상의 관심은 온통 학습에 쏠려 있지만, 회사의 돈과 사용자 경험이 실제로 갈리는 곳은 서빙이다. 모델이 아무리 똑똑해도, 답이 3초씩 늦게 나오거나 초당 요청 100개에서 뻗어버리면 서비스는 망한다. 서빙은 AI 서비스의 '안 보이는 절반'이다.
넷플릭스처럼 회원 수억 명에게 매초 수백만 건씩 추천을 계산해야 하는 회사에서, 이 '안 보이는 절반'은 사실 절반이 아니라 거의 전부다.
여기서 중요한 반전이 있다. 넷플릭스에게 LLM 서빙은 갑자기 뚝 떨어진 신문물이 아니다. 넷플릭스는 25년 동안 대규모 ML 서빙만 해온 회사다. LLM은 그 긴 역사의 최신 챕터일 뿐이다.
주목할 부분은 마지막이다. 2025년 3월, 넷플릭스는 「Foundation Model for Personalized Recommendation」이라는 연구를 공개했다. 그동안 홈 화면 곳곳에 흩어져 있던 수백 개의 특화 모델을, LLM에서 영감을 받은 하나의 거대한 트랜스포머로 통합하겠다는 것이다. 사용자의 시청 이력을 하나의 '문장'처럼 읽어 다음 행동을 예측하는, 말 그대로 언어 모델의 발상을 추천에 옮긴 모델이다.
즉 넷플릭스에게 LLM은 "외부에서 사 오는 신기한 챗봇"이 아니라, 자기가 25년째 굴려온 추천 시스템이 진화한 결과물이다. 남의 API로 빌려 쓸 대상이 아니라, 원래 자기 집 마당에서 키우던 작물인 셈이다. 이 관점을 잡고 가면 뒤의 모든 결정이 자연스럽게 이해된다.
넷플릭스 이야기를 이해하려면, 넷플릭스가 가지 않은 길을 먼저 봐야 한다. 2026년 오늘, 어떤 스타트업이 제품에 AI 기능을 넣는다고 하자. 십중팔구 이렇게 한다.
이게 나쁜 게 아니다. 오히려 대부분의 경우 정답이다. GPU를 살 필요도, 모델을 관리할 필요도, 새벽에 서버가 죽을까 봐 깨어 있을 필요도 없다. 세계 최고 연구소가 만든 모델을 토큰당 몇 원에 빌린다. 인류 역사상 이렇게 강력한 능력이 이렇게 싸게 임대된 적이 없다.
그래서 질문은 이렇게 바뀐다. "이렇게 쉬운데, 넷플릭스는 대체 뭐가 아쉬워서 직접 지었나?"
업계가 자체 호스팅으로 기우는 이유는 크게 다섯 갈래다. 하나씩 보자.
가장 먼저 떠오르는 건 돈이다. 하지만 여기엔 함정이 있다. 소규모에서는 API가 거의 항상 더 싸다. 남의 GPU를 필요한 만큼만 빌리는 게, 내 GPU를 사서 놀리는 것보다 싸기 때문이다.
역전은 오직 엄청난 물량에서만 일어난다. 2026년의 여러 분석은 손익분기를 대략 이렇게 잡는다(여러 컨설팅·벤더 블로그의 추정치로, 정밀한 수치가 아니라 방향성으로만 보자).
이 선을 넘기 전까지는 자체 호스팅이 오히려 손해다. GPU 임대료뿐 아니라 그걸 운영하는 시니어 엔지니어의 시간(한 달 수천 달러어치)까지 얹히기 때문이다. 그런데 넷플릭스는? 회원 수억 명, 매초 수백만 건의 추론. 이 선을 한참 전에, 여러 자릿수만큼 넘어선 회사다. 넷플릭스에게 비용은 "직접 하면 이득일까?"가 아니라 "직접 안 하면 파산할까?" 수준의 문제다.
API를 쓰면 요청이 내 서버 → 벤더 서버 → 다시 내 서버로 네트워크를 왕복한다. 여기에 벤더의 대기열, 속도 제한(rate limit), 사용량 쿼터가 얹힌다. 추천 화면을 0.1초라도 빨리 그려야 하는 회사에게 이 왕복은 치명적이다. 직접 서빙하면 처리량은 벤더의 쿼터가 아니라 내 하드웨어의 함수가 된다.
이건 성격이 다르다. 어떤 회사는 컴플라이언스·법무팀이 "우리 프로덕션 데이터는 제3자 서버를 절대 지나가지 않는다"를 보증해야 한다. 이 경우 비용도 품질도 부차적이다. 데이터가 밖으로 나가면 안 되므로, 자체 호스팅은 선택이 아니라 요구사항이 된다. 업계에서 "이 이유 하나는 다른 모든 비용 논리를 압도한다"고 말하는 항목이다.
여기가 넷플릭스 이야기의 핵심이다. API를 쓰면 모델은 '블랙박스'다. 프롬프트를 넣고 답을 받을 뿐, 그 사이에서 벌어지는 일에 손댈 수 없다. 하지만 직접 서빙하면 모델이 토큰을 하나씩 생성하는 그 순간에 개입할 수 있다.
넷플릭스는 바로 이걸 원했다. 모델이 아무렇게나 답하는 게 아니라, 처음부터 정해진 형식(예: 반드시 유효한 JSON, 반드시 후보 목록 안의 값)만 뱉도록 생성 과정 자체를 제약하는 것. 이 기술을 제약 디코딩(constrained decoding) 이라 부르는데, 이게 얼마나 중요하고 어려운지는 3부에서 통째로 다룬다. 지금은 "API로는 절대 못 하는, 직접 서빙해야만 가능한 일이 있다"만 기억하자.
벤더의 가격 인상, 모델 버전 폐기(deprecation), 갑작스러운 장애로부터 자유로워진다. 버전을 내가 고정(pin)하고, 업그레이드 시점을 내가 정한다. 남의 로드맵에 내 서비스를 인질로 잡히지 않는다.
| 기준 | 호스티드 API | 자체 서빙 |
|---|---|---|
| 초기 난이도 | 아주 낮음 (한 줄) | 아주 높음 (인프라 통째) |
| 소규모 비용 | 저렴 | 비쌈 (GPU 놀림) |
| 초대규모 비용 | 폭발 | 저렴 |
| 지연 시간 | 네트워크 왕복 | 내 하드웨어 함수 |
| 데이터 프라이버시 | 제3자 경유 | 내 경계 안 |
| 생성 과정 커스터마이징 | 불가 (블랙박스) | 가능 (제약 디코딩 등) |
| 운영 부담 | 벤더가 짐 | 내가 짐 |
정리하면 이렇다. 자체 서빙은 아무나 택할 길이 아니다. 하지만 물량이 압도적으로 크고(①②), 데이터가 민감하고(③), 생성 과정을 제어해야 하며(④), 벤더에 종속되기 싫은(⑤) 회사에겐 — 즉 넷플릭스에겐 — 거의 유일한 답이다.
당신의 조직은 어느 쪽일까? 아래에서 직접 조건을 넣어보자.
이게 넷플릭스의 유별난 취향이 아니라는 걸, 다른 빅테크의 사례가 증명한다. 2023년 이후 자체 LLM 서빙을 공개적으로 이야기한 회사들을 보자.
여기에 Meta(Llama를 하루 수백조 회 실행), DoorDash(메뉴 사진 전사·검색), Pinterest, Databricks까지 줄줄이 이어진다. 공통점이 보인다. 일정 규모를 넘은 회사는 결국 자기 손으로 추론을 굴린다. 그리고 그 상당수가 넷플릭스와 똑같이 vLLM을 고른다. (vLLM이 뭐길래 다들 이걸 쓰는지는 2부의 주제다.)
흥미로운 질문. 자체 서빙이 그렇게 좋으면 왜 진작 다 안 했을까? 답은 "2025~2026년이 되어서야 비로소 현실적이 됐다" 이다. 세 가지가 동시에 무르익었다.
이 세 가지가 겹치면서, 2026년은 "인퍼런스가 상용품(commodity)이 되는 해"라는 말까지 나온다. 그 상징적인 신호가 바로 모두가 OpenAI 호환 API 형태로 수렴하는 현상이다. 넷플릭스도, Uber도, 호스티드 벤더도 전부 같은 API 모양을 채택한다. 인터페이스가 표준화되면 그 뒤의 모델은 언제든 갈아 끼울 수 있는 부품이 된다. 이것이야말로 상용화의 가장 확실한 증거다.
이 지점을 오해하지 말자. "2026년엔 모두 자체 호스팅해야 한다"는 뜻이 아니다. 진지한 분석은 하나같이 단서를 단다 — 중간 규모 팀에게는 여전히 API가 싸다. 자체 서빙이 이기는 건 (a) 압도적 물량이거나 (b) 양보 불가능한 프라이버시/컴플라이언스 요건일 때다. 넷플릭스는 이 둘 다에 해당한다.
넷플릭스 원문에서 가장 인상적인 철학 한 줄을 소개하며 1부를 닫는다. 그들은 이렇게 말한다.
"LLM 모델은 특별한 눈송이(special snowflake)가 되어서는 안 된다."
무슨 뜻일까. 많은 회사가 LLM을 다룰 때 완전히 새로운 별도의 시스템을 짓는다. 기존 ML 파이프라인 옆에 'LLM 전용 특별관'을 하나 더 세우는 식이다. 넷플릭스는 정반대로 갔다. XGBoost 앙상블이든 초대형 LLM이든, 모든 모델은 똑같은 gRPC 호출 하나로 서빙된다. 같은 클라이언트 라이브러리, 같은 상태 점검, 같은 배포 파이프라인을 쓴다.
왜 이게 중요할까? LLM을 특별 취급하는 순간, 그 시스템은 나머지 25년치 인프라(모니터링·배포·A/B 테스트·로깅)의 혜택을 하나도 못 받는 외딴섬이 된다. 반대로 "LLM도 그냥 또 하나의 모델일 뿐"이라고 선언하면, LLM은 넷플릭스가 사반세기 동안 갈고닦은 서빙 제국의 모든 무기를 그대로 물려받는다.
이 "특별하지 않게 만들겠다"는 고집이, 사실은 가장 정교한 엔지니어링 결정이다. 그리고 그 고집을 실제 아키텍처로 구현하는 방법 — 하나의 파이프에 XGBoost와 LLM을 함께 흘려보내는 구조 — 이 바로 2부의 이야기다.
2부에서 계속 → — 이제 그 '문' 안으로 들어간다. vLLM과 Triton이 정확히 무엇이고, KV 캐시·PagedAttention·연속 배칭 같은 마법이 어떻게 작동하는지, 원문의 아키텍처 그림을 한 칸씩 뜯어본다.
