Quarkus vs Spring: 성능, 개발자 경험, 그리고 프로덕션 트레이드오프 : Part 1

Source: Dev.to

Background

Spring Boot이 등장한 이후로, 개발자 친화적인 생태계, 자동 설정 매직, 그리고 바로 코딩할 수 있는 설정(Spring starter) 덕분에 Java 웹 개발자들의 사실상 표준 백엔드 프레임워크가 되었습니다.

클라우드 시대에 들어서면서 Micronaut, Quarkus와 같은 다른 프레임워크들도 등장했습니다. 이 글에서는 Quarkus에 초점을 맞추어 Spring Boot과 어떻게 다른지, 클라우드 채택이 기업들로 하여금 프레임워크 선택을 재고하게 만든 이유, 그리고 Spring이 Quarkus에 대응하기 위해 어떤 노력을 하고 있는지를 살펴봅니다.

Spring Boot Internals

Spring은 자동 설정을 위해 리플렉션을 많이 사용하며, 이는 뛰어난 개발자 경험을 제공합니다. 스테레오타입, 컴포넌트 스캔, 컨테이너 밖 클래스에 대한 @Bean 선언, Spring Data JPA 인터페이스 등은 모두 리플렉션을 통해 자동 설정됩니다. Spring은 런타임에 프록시를 생성해 Spring 컨테이너를 구성하는데, 이 과정에서 메모리 사용량이 많아지고 애플리케이션 시작 속도가 느려집니다.

예를 들어, Spring을 사용할 때 흔히 마주칠 수 있는 BeanCreationException을 살펴보세요(공식 Javadoc은 여기에서 확인할 수 있습니다). 이 예외는 Spring이 시작 시 애플리케이션 컨텍스트를 생성하면서 모든 의존성을 해결하고 각 스코프에 맞는 빈을 인스턴스화하려 할 때 발생합니다. 이는 Spring 빈이 애플리케이션 컨텍스트 초기화 과정에서 런타임에 생성된다는 것을 보여줍니다.

Impact on Cloud Deployments

조직들은 신뢰성과 확장성을 위해 마이크로서비스 아키텍처로 전환하고 있습니다. 시스템을 클라우드 환경에 배포함으로써 온프레미스 인프라 대비 비용을 절감하고, 다양한 사용 사례에 맞는 즉시 사용 가능한 옵션들을 활용하고 있습니다.

도메인‑드리븐 설계 원칙에 따라 모놀리식 애플리케이션을 여러 마이크로서비스로 분할합니다. 각 마이크로서비스는 일반적으로 여러 복제 인스턴스로 실행되며, 각각 고유한 컴퓨팅 및 메모리 자원을 가집니다. 수백, 심지어 수천 개의 마이크로서비스가 클라우드에서 실행되는 상황을 상상해 보세요; 각 파드가 메모리와 컴퓨팅 자원을 소비하면서 클라우드 비용이 급증합니다.

이제 평균 10배 빠르고 메모리를 1/10만 사용하는 대안을 생각해 보세요. 비용 절감 효과는 상당하지만, 그 대가가 개발자 경험일 수도 있습니다. 이것이 바로 Quarkus가 제공하는 약속입니다.

Looking Ahead

우리는 Spring이 내부적으로 어떻게 동작하는지와 클라우드 환경과 통합될 때 직면하는 과제를 간략히 살펴보았습니다. 다음 파트에서는 Quarkus가 이러한 클라우드 과제를 어떻게 해결하는지, 그리고 Spring 팀이 이를 완화하기 위해 어떤 작업을 진행하고 있는지를 다룰 예정입니다.