2025년 기준으로 넷플릭스가 어떻게 Java를 메인 백엔드 기술로 선택하고 발전시켜왔는지, 그리고 최근 Java 생태계의 변화에 어떻게 발 빠르게 대응하고 있는지를 친절하게, 핵심 사례와 실제 경험을 바탕으로 풀어내는 발표입니다. Java 버전 업그레이드, 대규모 마이크로서비스 관리, 최첨단 가비지 컬렉터, Spring Boot 전환, 그리고 REST에서 GraphQL과 gRPC로의 진화 등, 대규모 서비스 운영의 실무 노하우를 모두 담았습니다.

1. 발표 도입과 넷플릭스의 현실적인 Java 활용 관점

발표자 Paul Bakker는 지난 수년 간 비슷한 주제로 넷플릭스 Java 활용 방법을 여러 번 다뤄왔다고 먼저 운을 뗍니다. 그러나 매년 아키텍처도, 기술도, 조직도 계속 바뀌기 때문에, "아마 같은 제목의 발표를 예전에 본 분이 있다 해도 이번엔 완전히 다를 것"이라고 강조합니다.

"매년 아키텍처가 계속 바뀌고, 우리가 쓰는 기술도 바뀌고 새로운 것을 계속 배우고 있죠."

최근 소셜 미디어에서 넷플릭스가 Java를 쓴다는 이야기가 흥미롭게 회자되었고, 여러 오해도 있었다고 전합니다. 대표적으로, Oracle 라이선스 비용 관련 질문에는

"저희는 Oracle에 라이선스 비용을 한 푼도 안 냅니다. OpenJDK를 쓰고 있으니까요."

라는 답변으로 웃음을 자아냈죠. 또, 왜 Rust가 아니냐는 지적에는,

"왜 Rust냐고 묻는 분들도 많았어요. 그런데 저희엔 Java가 더 적합한 여러 이유가 있습니다."

라며 기술 선택이 단순한 유행이나 이미지 문제가 아니라고 덧붙입니다.

2. 넷플릭스의 서비스 구조와 백엔드 아키텍처

스트리밍과 엔터프라이즈, 두 가지 대표 시나리오

넷플릭스는 단순 스트리밍 앱만 있는 게 아닙니다. 실제로 백엔드에서 Java가 주로 사용되는 영역은 아래와 같이 두 가지로 나눌 수 있습니다.

a. 스트리밍 서비스

• 매초 엄청나게 많은 요청을 처리해야 합니다 (고RPS)
• "수백만 사용자가 동시 접속하니, 백엔드는 항상 매우 높은 트래픽을 견뎌야 하죠."
• 글로벌 서비스이기 때문에, 4개 아마존 리전에 분산되어 저지연 서비스를 보장합니다.
• 대부분의 실패 상황은 재시도로 해결하거나, 일부 데이터 누락이 발생해도 전체 사용자 경험엔 큰 문제가 없게 설계되어 있습니다.
• 성능상 이유로 관계형 데이터베이스는 거의 쓰지 않고, 인메모리 데이터스토어나 분산 캐시 등을 활용합니다.

b. 엔터프라이즈/스튜디오(사내/제작 지원) 앱

• 영화 제작 인력, 장비, 장소, 일정을 관리하는 등 비즈니스 핵심 앱이 상당수입니다.
• 트래픽은 상대적으로 매우 낮고, 대부분 단일 리전에서 운영 가능합니다.
• "이런 앱에서는 데이터가 단 한 건도 사라지면 안 됩니다." 재시도보다 트랜잭션적 안정성이 우선입니다.
• 관계형 데이터베이스를 주로 사용합니다.

공통된 GraphQL 기반 백엔드 아키텍처

흥미로운 점은, 스트리밍이든 엔터프라이즈든, 백엔드 서비스 아키텍처는 거의 동일하다는 점입니다.

• API Gateway가 가장 앞단에서 GraphQL 쿼리를 받습니다.
• 이 API Gateway는 다수의 DGS(Domain Graph Service)와 연동을 통해 GraphQL Federation을 구현합니다.
• DGS는 Spring Boot로 작성된 Java 애플리케이션이며, 내부적으로는 더 하위 서비스(gRPC 및 다양한 데이터스토어 등)로 추가적인 팬아웃이 일어납니다.

"모든 백엔드 주요 서비스가 DGS(Spring Boot + DGS 프레임워크)와 GraphQL 기반으로 통일되어 있어요."

gRPC는 서비스 간의 내부 통신(Java to Java)에서 고성능 이점을 위해 주로 사용됩니다.

3. Open Connect와 Java의 역할, 그리고 멀티랭귀지 환경

넷플릭스의 영상 실시간 스트리밍(direct streaming itself)은 별도의 Open Connect 인프라가 담당합니다.

• 전 세계 ISP에 오픈 커넥트 서버(전용 박스)를 배치해, 스트리밍 트래픽을 네트워크적으로도 가까운 곳에서 시작하게 만듭니다.
• 이 영역 역시 관리 소프트웨어의 대부분이 Java로 작성되어 있습니다.
• 미디어 인코딩 파이프라인, 실시간 데이터 처리, 일부 데이터베이스 등도 Java 기반입니다.

다만, Go, Python 등으로 개발된 일부 플랫폼/머신러닝 요소도 자유롭게 활용되고 있습니다.

"물론 저희도 Go, Python 여러 언어를 쓰긴 하지만, 백엔드 전반은 Java가 압도적이에요."

4. JDK 및 프레임워크 업그레이드 여정: JDK 8에서 21/23으로

몇 년 전만 해도 넷플릭스 전체 Java 서비스가 아주 오래된 JDK8과 자체 제작된 낡은 프레임워크에 머물러 있었다고 솔직하게 고백합니다.

"당시엔 최신 JDK로 가고 싶어도, 오래전에 만든 내부 라이브러리, 호환성 안 맞는 외부 라이브러리 탓에 엄두를 못 내는 상황이었어요."

그래서 전사적으로 아래와 같은 대수술을 단행했습니다:

1. 유지보수 중단/호환성 문제 라이브러리 직접 패치
   • "막상 해보니 손볼 게 아주 적었더라고요. 복잡해 보여도 직접 고쳐보면 충분히 할 수 있는 일이에요."
2. 모든 서비스 프레임워크를 Spring Boot로 전환
   • 코드 자동 변환 툴링 등도 내부 개발
   • 그 결과 3000개에 달하는 Java 서비스를 완전 이전

현재는 거의 모든 서비스가 Spring Boot + JDK 17 이상에서 운영됩니다. 주요 트래픽 서비스는 JDK 20/21/23으로, 새로운 GC(Generational ZGC)와 신기능을 적극 활용 중입니다.

5. JDK 업그레이드 효과와 실전 GC, Virtual Thread 경험

JDK 17: G1 GC 성능 20% 업!

JDK 8 → JDK 17 업그레이드에서 가장 큰 변화는 G1 GC의 비약적 성능 향상이었습니다.

"JDK17로 올리니 GC CPU 소모가 20%는 그냥 줄어들더랍니다. 노력 대비 가장 큰 성능 향상이에요."

JDK 21: Generational ZGC와 에러 드라마틱 감소

• 기존 ZGC는 비세대형(Non-generational)이라 대용량 힙에서는 역효과가 있었습니다.
• 하지만 JDK 21의 Generational ZGC는 "모든 서비스에 압도적으로 좋은 결과!"
• GC가 stop-the-world로 1~1.5초 멈추던 현상이 아예 사라지고, 서비스 에러/타임아웃도 확연히 감소.

"GC Pause로 인해 서비스가 1초 넘게 정체돼 리트라이가 많던 게, ZGC로 바꾸자마자 바로 0이 되었죠."

Virtual Threads: 복잡한 동시성의 판을 바꾸다

• 가벼운 병렬 처리가 필수인 GraphQL 등에서, 기존엔 Executor나 CompletableFuture 등 직접 지정해야 해서 번거로웠음.
• Virtual Threads로 디폴트 병렬 처리가 가능, 복잡도 및 디버깅 난이도 급감.

"개발자는 신경 안 써도, 느린 DB 호출이 알아서 병렬로 돌아가 결과적으로 응답 시간은 획기적으로 줄었어요."

아직은 조심! 실무 디버깅 경험

• Virtual Threads + synchronized/reentrant lock 혼합에서 JDK 23까지는 치명적 데드락도 경험.
• JDK 24에서 해결(491 이슈)됨에 따라 본격 적용 재개 예정.

6. Spring Boot와 내부 플랫폼, 도구 체계 고도화

넷플릭스의 Spring Boot 전략

• Spring Boot + 자체 모듈(인증/인가, 서비스 메시, GPRC, Observability, Dynamic Config 등)
• "실제 개발 경험은 거의 오픈소스 Spring Boot와 다를 게 없고, 대부분의 확장은 (Spring Data 등처럼) AutoConfiguration 방식으로 처리합니다."
• 배포는 AWS 인스턴스 또는 컨테이너(Titus, Netflix 자체 K8s 플랫폼), 모두 Exploded Jar + Embedded Tomcat 구조

네이티브 이미지(빌드타임 컴파일)는 신중히

• "빌드ㆍ디버깅 환경, 개발자 경험 악화와 안정성 문제 때문에 네이티브 이미지는 아직 채택하지 않았습니다."
• 대신 Project Leiden, Spring의 AOT 등 차세대 기술을 예의주시는 중

Reactive 탈출, WebFlux는 지양

• 과거 회사 차원에서 RxJava 기반 Reactive 전도사였으나, 코드 복잡도/디버깅 고통이 더 커 현재는 완전히 WebMVC에 표준화.

"지금은 누구도 Reactive 코드를 건드리고 싶어하지 않아요. Virtual Threads, Structured Concurrency가 결국 Reactive를 대체할 겁니다."

Spring Boot 3 업그레이드, Jakarta 네임스페이스 문제

• "대부분 find/replace로 끝나지만, 라이브러리는 더 복잡해서, 넷플릭스는 Gradle Transform 플러그인으로 바이트코드 단계에서 자동 변환 처리합니다."
• 관련 도구도 오픈소스로 공개해 커뮤니티에서 활용 가능!

7. GraphQL & DGS 프레임워크: 실용적인 대규모 적용과 협업

• 넷플릭스 내부에서 GraphQL 활용을 위해 DGS 프레임워크(2020년 공개) 오픈소스화
• Java 진영에선 GraphQL Java가 매우 로우레벨이라, Spring Boot 기반 훨씬 더 높은 생산성 모델 제공
• 테스팅 툴, 어노테이션 기반 프로그래밍 모델 등 개발·운영 편의성에 많은 투자

"Spring for GraphQL과 협력해, 넷플릭스 DGS와 Spring 공식 GraphQL 모두를 조화롭게 함께 쓸 수 있도록 하고 있습니다."

8. REST 대신 GraphQL/gRPC!

Paul Bakker는 현 시점에서 UI↔백엔드는 GraphQL, 서비스 간 통신은 gRPC가 각각 최적이라고 분명히 말합니다.

• GraphQL:
  • "UI에 맞춘 유연한 API 스키마화가 필수입니다."
  • "UI/백엔드가 같은 스키마를 공유하기 때문에 협업 효율이 높아요."
• gRPC:
  • 서버-서버 간 고성능, 강타입, 메서드 기반의 원격 호출에 이상적
• REST는 이제 추천하지 않음!
  • "REST를 쓰면 데이터를 무작정 덤핑하고, UI 개발자에게 복잡한 필터링 책임을 전가하게 될 뿐이에요."
  • "빠른 프로토타이핑에 한정적으로만 OK."

마치며

넷플릭스는 한때 기술적 부채에 갇혀 있었지만, 적극적인 레거시 탈피와 전사적 업그레이드, 그리고 최신 Java·Spring 패러다임을 대규모로 적용하는 선도적 경험을 쌓아왔습니다.
특히 JDK 최신 GC와 Virtual Threads, GraphQL 도입은 실질적 성능 개선과 개발자 경험을 동시에 달성한 핵심 포인트입니다.
Paul Bakker의 발표는 단순한 기술 트렌드 소개가 아니라, 실제 조직이 다양한 현실 문제를 어떻게 해결하는지, 그리고 기술 생태계 변화를 어떻게 실용적으로 수용하는지를 생생히 전달합니다.
Java가 "느리고 무겁다"는 편견, 넷플릭스만큼은 완전히 벗어던졌다는 것을 보여주는 강연이었습니다! 🚀

"질문 있으면 오늘 복도에서 언제든 저를 찾아주세요!"