넷플릭스는 왜 정말 AWS로 갔을까? 클라우드 아키텍처의 진짜 이야기

넷플릭스의 클라우드 이야기는 흔히 "마이크로서비스, 카오스 엔지니어링, 오토스케일링 성공 사례"로만 소비됩니다.

하지만 넷플릭스가 왜 AWS로 옮겨야만 했는지, 이 과정에 어떤 사람과 조직의 변화가 있었는지, 어떤 아키텍처 전략이 글로벌 스트리밍 제국을 만들었는지는 상대적으로 덜 알려져 있습니다.

이 글에서는 넷플릭스의 AWS 마이그레이션을 단순 기술 소개가 아니라, "사업이 살아남기 위해 선택한 구조 개편"이라는 관점에서 풀어봅니다. 넷플릭스가 어떤 문제 때문에 클라우드로 내몰렸는지, 왜 AWS였는지, 7년에 걸친 재설계 여정, 글로벌 클라우드 아키텍처의 핵심, 비용과 조직 문화까지 한 번에 정리해볼게요.

넷플릭스를 클라우드로 내몬 2008년의 '한 번의 사고'

넷플릭스의 AWS 마이그레이션은 멋진 미래를 꿈꾸며 시작된 프로젝트가 아니었습니다. 살기 위해 선택한 생존 전략에 가까웠습니다.

2008년 8월, 넷플릭스의 핵심 오라클 기반 모놀리식 데이터베이스가 손상되면서 수 일간 장애가 발생합니다. DVD 배송이 멈추고, 결제가 중단되며, 고객 지원까지 흔들리는 치명적인 사태였죠.

이 사고는 한 가지 사실을 처절하게 보여줬습니다. 기존 데이터센터 기반 아키텍처로는 앞으로 다가올 '글로벌 스트리밍 시대'를 버틸 수 없다는 것입니다. DVD 우편 서비스에서, 전 세계로 영상을 쏘는 스트리밍 서비스로 사업의 중심이 완전히 바뀌는 시점이었기 때문입니다.

문제는 온프레미스 데이터센터가 이 속도를 따라잡지 못한다는 점이었어요. 물리 서버를 주문·설치·운영하는 데는 늘 몇 달이 걸렸고, 장애는 점점 복잡해졌으며, 수요는 예측하기 어려울 정도로 튀었습니다.

넷플릭스가 필요로 했던 건 크게 네 가지였습니다.

• 필요할 때 마음껏 늘리고 줄일 수 있는 탄력적인 컴퓨팅

• 전 세계 사용자에게 빠르게 서비스를 제공할 수 있는 글로벌 인프라

• 몇 달이 아닌, 몇 분·몇 시간 단위의 자원 프로비저닝 속도

• 운영 복잡도를 줄여주는 단순하고 자동화된 운영 모델

온프레미스를 고집하는 것은 사실상 "성장 포기"와 다름없었습니다. 그래서 이 마이그레이션은 비용 최적화가 아닌, "사업 생존을 위한 필수 선택"이었죠.

왜 하필 AWS였을까? 당시 선택지는 거의 없었다

지금 기준으로 보면 "AWS도 있고, 애저도 있고, 구글 클라우드도 있는데 왜 AWS?"라고 생각하기 쉽습니다. 하지만 2009년의 시장 상황은 지금과 전혀 달랐습니다.

당시 기준으로 넷플릭스가 원하는 수준의 글로벌 확장성과 자동화를 제공할 수 있었던 곳은 사실상 AWS 하나뿐이었습니다.

• AWS는 이미 EC2, S3, ELB 같은 핵심 인프라 서비스가 상용화되어 있었고, API 기반으로 서버를 프로그래밍하듯 관리할 수 있었습니다.

• 애저는 아직 윈도우·.NET 중심 PaaS에 가까웠고, 넷플릭스가 사용하는 JVM·리눅스 생태계에 딱 맞지는 않았습니다.

• 구글 클라우드는 지금과 같은 상용 클라우드가 아니라, 내부 인프라 중심에 가깝고 아직 시장에 제대로 나오지 않은 상태였습니다.

즉, "AWS가 좋아 보여서"가 아니라 "이 정도 스케일을 감당할 유일한 옵션이 AWS였기 때문에" 선택한 것입니다. 브랜드 선택이 아니라, 생존을 위한 현실적인 선택이었죠.

7년에 걸친 넷플릭스 AWS 마이그레이션의 실제 타임라인

넷플릭스의 클라우드 이전은 흔히 상상하는 것처럼 "서버를 통째로 옮긴 리프트 앤 시프트"가 아니었습니다. 기존 모놀리스를 바닥부터 뜯어 고쳐 완전히 다른 시스템으로 다시 만든, 장기 재건 프로젝트에 가까웠습니다.

대략적인 흐름을 보면 이렇게 흘러갑니다.

• 2008년: 심각한 DB 장애 이후, 아키텍처 전면 재검토 시작

• 2009년: "클라우드 퍼스트" 전략 공식화

• 2010~2012년: 상태를 가지지 않는 서비스부터 차근차근 쪼개서 마이크로서비스로 이전

• 2012~2014년: S3 기반 데이터 레이크, 하둡/스파크 기반 분석 플랫폼 구축, 전 세계에 분산된 카산드라 운영

• 2015년: 다중 리전 액티브-액티브 구조, 카오스 엔지니어링 체계 정식 도입

• 2016년: 마지막 남은 청구(Billing) 시스템까지 이전 완료, "완전 클라우드 기반 회사" 선언

총 7년이 걸린 이유는 단순합니다. "옮긴" 게 아니라 "다시 만든" 수준이었기 때문입니다. 마이그레이션이라는 말보다, 재설계(re-architecture)에 가깝죠.

넷플릭스 글로벌 클라우드 아키텍처, 한 장으로 요약해 보기

그렇다면 넷플릭스가 AWS 위에 어떻게 글로벌 클라우드 아키텍처를 설계했을까요? 핵심은 "전 세계 사용자에게 끊기지 않는 스트리밍 경험을 주면서, 폭증하는 트래픽을 버틸 수 있는 구조"입니다.

가장 바깥쪽에는 TV, 모바일, 웹 앱 등 다양한 클라이언트가 있습니다. 이 디바이스들의 요청은 먼저 API 게이트웨이를 통과해 각각의 마이크로서비스로 라우팅됩니다.

비즈니스 로직은 대부분 마이크로서비스로 쪼개져 있고, 컨테이너 관리 플랫폼인 Titus 위에서 동작합니다. 이 서비스들은 가능한 한 상태를 가지지 않도록 설계되어, 필요할 때 수평 확장이 쉽습니다.

데이터 계층에서는 카산드라가 전 세계에 분산된 메타데이터 저장소로 사용되고, S3는 영상 콘텐츠와 데이터 레이크의 핵심 저장소 역할을 합니다. 이벤트 스트림과 실시간 데이터 처리는 카프카와 내부 스트리밍 시스템(Mantis)을 통해 처리합니다.

이 모든 것을 안정적으로 운영하기 위해 넷플릭스는 자체 모니터링 시스템 Atlas, 배포 자동화 도구 Spinnaker, 그리고 Chaos Monkey와 같은 카오스 엔지니어링 도구들을 직접 만들었습니다. 이 조합이 "큰 장애 없이 전 세계 동시 접속을 버티는 넷플릭스"를 가능하게 한 셈입니다.

마이크로서비스와 서비스 메시는 '유행'이 아니라 생존 전략이었다

넷플릭스가 마이크로서비스를 도입한 이유는 단순히 "트렌디해서"가 아니었습니다. 기존 모놀리식 구조에서는 하나의 서브시스템이 실패하면 전체 서비스가 같이 무너지는 치명적인 구조적 문제가 있었기 때문입니다.

그래서 넷플릭스는 서비스를 잘게 쪼개고, 각 서비스의 실패가 다른 곳으로 번지지 않도록 "고립된 실패 도메인"을 만드는 데 집중했습니다. 이를 위해 서킷 브레이커, 벌크헤드, 폴백 로직 같은 패턴을 서비스 메시 설계에 적극적으로 활용했습니다.

어떤 서비스가 느려지거나 장애가 나더라도, 나머지 서비스들이 최대한 정상 동작하게 만들고, 자동으로 우회하거나 점진적으로 복구되도록 하는 구조입니다. 이 덕분에 사용자는 내부적으로 일부 장애가 있어도 큰 문제를 느끼지 못하고 스트리밍을 계속 사용할 수 있습니다.

즉, 넷플릭스의 마이크로서비스 아키텍처는 "빠른 개발" 그 자체보다, "장애가 전체로 번지지 않게 막는 방화벽" 역할을 하기 위해 설계된 것입니다.

넷플릭스 데이터를 움직이는 엔진: 추천, 분석, DRM까지

넷플릭스의 진짜 무기는 콘텐츠 수보다 "개인화 추천"이라고 해도 과언이 아닙니다. 이 추천과 스트리밍 경험을 지탱하는 것은 결국 데이터 플랫폼입니다.

넷플릭스는 전 세계 사용자 행동 데이터, 시청 이력, 디바이스·네트워크 상태, 영상 권리(라이선스) 정보 등 엄청난 양의 데이터를 다룹니다. 추천 알고리즘은 이 데이터를 거의 실시간에 가깝게 반영해야 하고, 재생 품질은 네트워크 상황에 따라 즉시 조정되어야 합니다.

이를 위해 넷플릭스는 다음과 같은 구조를 구축했습니다.

• 카산드라: 전 세계 어디에서든 빠른 읽기·쓰기를 제공하는 분산 데이터베이스

• S3 기반 데이터 레이크: 분석과 머신러닝을 위한 핵심 데이터 저장소

• 하둡/스파크: 추천 모델 학습, 대규모 배치 분석, 개인화 로직 강화

• 카프카 + Mantis: 실시간 이벤트와 텔레메트리 처리

데이터 마이그레이션도 마찬가지로 단순한 복사가 아니었습니다. 페타바이트 단위의 데이터를 지역별로 동기화하면서, 스키마 변경, 지연 시간, 일관성 이슈를 모두 관리해야 했습니다. 자동화 파이프라인과 사람의 세심한 검증이 함께 움직인, 긴 호흡의 작업이었죠.

넷플릭스는 왜 AWS로 스트리밍하지 않을까? 'Open Connect'의 비밀

많이들 헷갈리는 지점이 하나 있습니다. 넷플릭스가 AWS 위에서 돌아간다고 해서, 실제 영상 데이터도 AWS에서 바로 쏘는 건 아닙니다.

실제 스트리밍은 대부분 넷플릭스가 직접 만든 전용 CDN인 "Open Connect"를 통해 전달됩니다. Open Connect는 각국 ISP(통신사)의 네트워크 안에 직접 서버를 넣어 두는 방식으로 운영됩니다.

이렇게 하면 장점이 크게 두 가지가 있습니다.

• 사용자가 가장 가까운 곳(자기 ISP 내부)에 있는 서버에서 영상을 받아오므로 지연 시간이 줄고 품질이 좋아집니다.

• 막대한 트래픽을 퍼블릭 클라우드에서 그대로 쏘는 것보다 훨씬 저렴하게 대규모 스트리밍을 할 수 있습니다.

AWS는 로그인, 계정 관리, 추천, API, 로그 수집, 콘텐츠 인코딩 같은 백엔드 로직을 담당하고, Open Connect는 실제 비디오 데이터를 사용자에게 전달하는 역할을 합니다.

이 하이브리드 구조 덕분에 넷플릭스는 4K 영상도 전 세계에 안정적으로, 그리고 상대적으로 낮은 비용으로 제공할 수 있습니다.

클라우드는 처음엔 더 비쌌다, 하지만 '속도'가 모든 걸 바꿨다

많은 기업이 클라우드를 고민할 때 가장 먼저 묻는 질문이 "온프레미스보다 싸냐?"입니다. 넷플릭스의 경험은 이 질문에 솔직하게 답해줍니다. 초반에는 오히려 더 비쌌다고요.

2008~2016년 사이 넷플릭스는 AWS에 수천만 달러 규모의 비용을 썼을 것으로 추정됩니다. 게다가 수백 명·수년에 걸친 엔지니어 인건비까지 합치면 결코 작은 투자가 아니었습니다.

그럼에도 넷플릭스가 얻은 것은 다음과 같았습니다.

• 새로운 기능을 훨씬 빠르게 배포할 수 있는 개발·배포 속도

• 트래픽이 몰릴 때 필요한 만큼 확장할 수 있는 탄력성

• 큰 장애가 날 가능성을 줄여주는 설계와 운영 체계

• 수많은 실험을 빠르게 돌려볼 수 있는 실험 문화

시간이 흐르면서 넷플릭스는 스팟 인스턴스 활용, 리전별 자동 확장, 실시간 비용 모니터링 등으로 비용도 점점 최적화했습니다. 무엇보다 중요한 건 "비용 자체"보다 "속도와 안정성이 만들어낸 사업 가치"였다는 점입니다. 빠르게 시도하고, 안전하게 실패하고, 빨리 다시 고칠 수 있는 능력 말이죠.

기술만으로는 부족했다: 조직 저항, 역할 변화, 그리고 문화

넷플릭스의 AWS 마이그레이션에서 가장 과소평가되는 부분은 "사람과 조직"입니다. 7년에 걸친 대규모 재설계는 기술만 잘한다고 끝나지 않았습니다.

온프레미스 환경에 익숙했던 엔지니어들은 완전히 새로운 클라우드 패러다임을 배워야 했고, 기존 방식으로 잘 돌아가던 프로세스와 책임 구조도 전면 재조정이 필요했습니다. 일부 팀은 변화에 자연스럽게 적응했지만, 어떤 팀은 강한 저항감과 피로감을 느끼기도 했습니다.

이 과정에서 넷플릭스는 플랫폼 엔지니어링, SRE, 옵저버빌리티 엔지니어, 데이터 인프라, CDN·엣지 네트워크, 보안 엔지니어링 등 새로운 역할을 확립했습니다. 동시에 개발자가 인프라에 일일이 신경 쓰지 않아도 되도록 Spinnaker, Titus 같은 내부 플랫폼을 만들어, "복잡한 클라우드는 플랫폼이 대신 감싸주고, 개발자는 제품에 집중하도록" 하는 방향으로 진화했습니다.

무엇보다 중요한 건 리더십이었습니다. 실패를 공개적으로 공유하고, 실험을 장려하며, 장기적인 비전을 끊임없이 설명하는 과정이 없었다면, 이 긴 여정을 버텨내기 어려웠을 것입니다.

클라우드를 고민하는 엔지니어와 조직에게 주는 넷플릭스의 힌트

넷플릭스의 AWS 마이그레이션은 단순히 "우리도 저렇게 해야지"라는 체크리스트가 아닙니다. 대신 몇 가지 방향성을 제시합니다.

• 클라우드 마이그레이션은 IT 프로젝트가 아니라 비즈니스 전략입니다. "왜 옮겨야 하는가?"가 먼저 명확해야 합니다.

• 마이크로서비스는 유행이 아니라, 특정 규모와 복잡성에서 필요한 "고장 방화벽"에 가깝습니다. 필요한 정도만 도입해야 합니다.

• 관찰 가능성(Observability)은 나중에 붙이는 기능이 아니라, 설계 초기부터 함께 들어가야 합니다. 보이지 않으면 운영할 수 없습니다.

• 카오스 엔지니어링은 재미 있는 장난이 아니라, 대규모 시스템에서 장애를 미리 연습하는 훈련입니다.

• 그리고 무엇보다, 문화가 없으면 아키텍처도 오래 가지 못합니다. 팀이 변화에 적응하고, 실패에서 배울 수 있는 문화가 핵심입니다.

넷플릭스는 단지 AWS로 "옮긴" 것이 아니라, 우리가 오늘 당연하게 쓰는 클라우드 패턴들을 몸으로 부딪치며 만들어낸 회사에 가깝습니다. 서비스 메시, 분산 트레이싱, 오토스케일링 오케스트레이션, 카오스 테스트, 멀티 리전 액티브-액티브 같은 개념이 현실 세계에서 검증된 무대가 바로 넷플릭스였으니까요.

당신의 조직이 지금 클라우드 전환을 고민하고 있다면, "얼마나 싸게 옮길 수 있을까?"보다 "이걸 통해 무엇을 더 빨리, 더 안정적으로, 더 자주 해볼 수 있게 될까?"를 먼저 질문해보는 것이 넷플릭스가 남긴 가장 현실적인 교훈일지도 모릅니다.

출처 및 참고 : How Netflix Designed Its Global Cloud Architecture on AWS: The Real Reason Netflix Moved to AWS | by Ismail Kovvuru | Nov, 2025 | Medium