How Netflix Uses Java 2026 Edition 리뷰

2025년에 Java 컨퍼런스에서 Netflix는 Java를 어떻게 사용하였고, 이런게 Netflix에서 어떤 영향을 끼쳤는지에 대하여 이야기해준적이 있습니다.

 

간단하게 이야기하면 다음과 같은 내용이 인상깊었습니다.

• Java의 버전을 8에서 17로 올리면서 CPU 사용량이 약 20% 감소했다.
  • Java8의 GC와 Java17의 GC가 차이가 있음으로 인해서 성능이 좋아졌다는 이야기를 했었습니다.
• G1 GC에서 ZGC로 바꾸면서 STW의 시간이 대폭 줄었고, 이로 인하여 서비스 통신 시간이 감소되어 오류율이 많이 감소되었다.
  • ZGC는 G1 GC에 비하여 많은 메모리를 소모하는 대신 STW의 시간이 대폭 줄어들어 시간적으로는 효과가 있어서 발생한 현상입니다.
• Spring boot WebFlux를 사용하지 않는다.
  • Java의 버전이 올리가면서 21에 추가된 Vritual Thread로 인하여 굳이 WebFlux를 사용할 필요가 없어졌다.

이번 2026에서는 어떤 이야기를 할지 정리해보도록하겠습니다.

 

 

Netflix의 기술 스택

Netflix는 하나의 언어만 사용하는 회사는 당연히 아니다.

• TV 환경 : JavaScript
• 모바일 : Kotlin, Swift
• 인프라 및 간단한 시스템 : Go
• 머신러닝 : Python
• 백엔드 및 마이크로 서비스 Java or Kotlin

"모든 걸 하나의 언어로 통일"하는 방식보다는 목적에 맞는 기술을 선택하는 구조에 가까움

 

 

 테스트 전략

Netflix에서 @SpringBootTest를 사용하여 테스트 코드를 작성한다.

 

그치만, 해당 부분에는 명확한 문제가 발생한다.

 

@SpringBootTest는 전체 Spring 애플리케이션을 부트스트랩하기 때문에

• GraphQL Layer
• Service Layer
• Database Layer 등이 모두 함께 올라간다.

특정 기능 하나만 테스트하고 싶어도 전체 애플리케이션이 실행되어, 테스트 속도를 느리게 만드는 문제가 발생함

 

그래서 Netflix는

• 실제 테스틑 대상 클래스를 명확히 지정
• 테스트 슬라이스를 활용
• 필요한 최소한의 Spring 기능만 부트스트랩 을 활용하여 사용한다.

Spring boot 2 -> 3 업그레이드

Spring boot 2에서 3로 업그레이드 하는데, 몇몇 라이브러리는 javax이지만 Spring boot 3은 jakarta를 사용하고 있었음

 

라이브러리가 업그레이드 되야 애플리케이션을 올릴 수 있고, 애플리케이션이 올라가야 라이브러리를 올릴 수 있는 순환 의존 문제가 발생함

Netflix가 만든 라이브러리

라이브러리를 다운로드 할 때, 바이트코드를 재작성해서 javax -> jakarta 네임스페이스로 변환하는 Gradle 플러그인을 만들어 사용함

 

해당 플러그인을 활용하면 기존 javax 기반 라이브러리를 jakarta 기반으로 마이그레이션 할 수 있음

 

현재는 netflix도 vibe coding으로 Spring boot의 버전을 3에서 4로 업그레이드 진행

그런데 왜 계속 업그레이드를 계속할까?

당장 Spring boot 최신 버전을 확인하였을 때, 흥미를 느낄만한 새로운 기능들이 없을 수 있다.

 

하지만, Spring boot가 업그레이드 하면서, 다른 라이브러리들도 해당 버전에 맞춰 업그레이드를 진행하게 된다.

 

만약, 최신 라이브러리의 기능을 사용하고 싶은데, 현재 사용중인 다른 라이브러리들과 버전이 호환되지 않아 도입 자체가 불가능해지는 상황이 발생할 수 있다.

 

최신 기술을 따라가지 않으면, 결국 미래 기능을 사용할 수 없게 될지도 모른다.

GC

Netflix는 원래 ZGC는 CPU 사용량이 높아 대부분의 서비스에 적합하지 않을 것이라고 생각했다.

 

왜냐하면, ZGC는 CPU를 더 사용하는 대신 STW를 극단적으로 줄이는 GC이기 때문이다.

 

하지만, 여러 확인 테스트를 해본 결과, 거의 모든 워크로드에서 매우 효과적이여서 기본값으로 설정했다.

G1 GC에서 발생했던 문제

메모리가 많은 대형 머신들을 사용하다 보면, 어느 시점에선가 모든 작업이 일시 중지되는 긴 STW가 발생한다.

 

1 ~ 2가 매우 짧아보일 수 있지만, Netflix와 같은 대규모 분산 시스템에서는 매우 치명적이다.

 

왜냐하면, 모든 RPC 호출에 매우 업격한 타임아웃이 존재하고, 잠깐 멈추는 순간 요청이 실패하여 재시도가 발생하고, 클러스터의 다른 노드들에 부하가 몰려 연쇄 장애가 발생할 수 있다.

 

ZGC를 적용한 이후에는 STW 시간이 거의 0에 가까워 졌고, IPC 오류율도 크게 감소하였다.

 

GC STW 발생시간 그래프

 

IPC 오류 발생 그래프

 

Virtual Thread

Netflix는 jdk21에서 Virtual Thread를 실 서비스에 적용했었다.

 

그러나, Thread Pinning 문제가 발생하면서 이로 인해 서비스 교착 상태가 발생하였고, 대부분의 Virtual Thread 적용을 다시 되돌려야 했다.

JDK 25

JDK 25에서는 Thread Pinning 문제가 사실상 해결되었고, 다시 Virtual Thread를 사용하기 시작했다.

느낀점

• 모든 서비스를 하나의 언어로 고집해서 사용할 필요는 없다.
  • 나 또한 Rust라는 언어를 최근에 활용해서 개발을 진행하고 있고, 빠른 서비스와 안전한 메모리 사용량을 필요로 하는 부분에 대해서는 적용하는 것이 좋다고 생각하고 있다.
  • 언어별로 각각의 장점과 단점이 존재할 것이고, 이를 어떻게 적재적소에 활용하는지가 중요하다고 생각한다.
• 최신 버전은 올릴 수 있다면 무조건 올리는 것이 좋다고 생각한다.
  • 새로 추가된 기능을 사용하지 않더라도, jdk의 버전별 같은 함수의 구현 코드들만 보더라도 라이브러리는 계속적으로 발전되어 가면서 성능 향상이 발생할 수 있다.