Spring Boot vs Quarkus 2026 비교: 시작 속도부터 AI 통합까지

들어가며

2026년 4월 22일과 23일, 단 하루 차이로 Quarkus 3.34.6과 Spring Boot 4.0.6이 동시에 릴리스되었다. 같은 자바 백엔드 시장을 두고 경쟁하는 두 프레임워크가 우연찮게 겹쳐 출시된 셈이다. 이번 포스팅에서는 Spring Boot vs Quarkus를 2026년 시점에서 정리하고자 한다. 시작 시간, 메모리 사용량, 코드 작성 방식, AI 통합 방향성, Native 컴파일 성능, 의사결정 기준의 6가지 축으로 비교한다. 공식 릴리스 노트와 벤치마크 수치를 근거로, 어떤 상황에서 무엇을 고르는 것이 합리적인지 판단할 수 있도록 데이터를 정리했다.

두 프레임워크가 같은 출발점에서 시작하지 않은 이유

Spring Boot vs Quarkus의 본질적 차이는 “런타임 처리”와 “빌드 타임 처리”의 철학 차이다. Spring Boot는 2014년 등장 당시 자바의 풍부한 리플렉션과 동적 프록시를 활용해 런타임에 빈을 와이어링하는 방식을 채택했다. 반면 Quarkus는 2019년 등장 시점부터 GraalVM 네이티브 이미지를 1순위 타깃으로 설계해, 의존성 주입과 설정 처리를 컴파일 시점으로 옮긴 augmentation phase를 도입했다.

// Spring Boot: 런타임 리플렉션 기반 의존성 주입
@RestController
public class OrderController {
    private final OrderService orderService;

    // 생성자 주입 — 컨테이너가 런타임에 빈을 찾아 주입
    public OrderController(OrderService orderService) {
        this.orderService = orderService;
    }

    @GetMapping("/orders/{id}")
    public Order get(@PathVariable Long id) {
        return orderService.findById(id);
    }
}

// Spring Boot: 런타임 리플렉션 기반 의존성 주입
@RestController
public class OrderController {
    private final OrderService orderService;

    // 생성자 주입 — 컨테이너가 런타임에 빈을 찾아 주입
    public OrderController(OrderService orderService) {
        this.orderService = orderService;
    }

    @GetMapping("/orders/{id}")
    public Order get(@PathVariable Long id) {
        return orderService.findById(id);
    }
}

위 코드에서 Spring은 ApplicationContext를 부팅하면서 클래스패스를 스캔하고 리플렉션으로 빈을 인스턴스화한다. 이 과정은 유연하지만 시작 시점에 비용을 치른다. 반대로 Quarkus는 동일한 어노테이션 모델을 빌드 타임 코드 생성으로 처리한다.

// Quarkus: 빌드 타임에 와이어링 코드가 생성됨
@Path("/orders")
public class OrderResource {
    private final OrderService orderService;

    // ArC(Quarkus의 CDI 구현)가 빌드 시점에 인스턴스화 코드를 생성
    public OrderResource(OrderService orderService) {
        this.orderService = orderService;
    }

    @GET
    @Path("/{id}")
    public Order get(@PathParam("id") Long id) {
        return orderService.findById(id);
    }
}

// Quarkus: 빌드 타임에 와이어링 코드가 생성됨
@Path("/orders")
public class OrderResource {
    private final OrderService orderService;

    // ArC(Quarkus의 CDI 구현)가 빌드 시점에 인스턴스화 코드를 생성
    public OrderResource(OrderService orderService) {
        this.orderService = orderService;
    }

    @GET
    @Path("/{id}")
    public Order get(@PathParam("id") Long id) {
        return orderService.findById(id);
    }
}

위 두 코드는 외형이 거의 같지만 부팅 과정이 완전히 다르다. Quarkus는 빌드 시점에 ArC(CDI 구현체)가 의존성 그래프를 분석해 클래스 초기화 코드를 미리 생성한다. 그 결과 런타임에는 클래스패스 스캔이 사라지고 부팅이 곧장 끝난다. Spring Data AOT Repositories 같은 신기능은 Spring Boot 4.x가 이 빌드 타임 처리 모델을 일부 흡수하려는 움직임이라고 볼 수 있다.

시작 시간과 메모리, 숫자로 들이대는 차이

Spring Boot vs Quarkus의 성능 차이는 마케팅 슬로건이 아니라 다수의 독립 벤치마크에서 일관되게 관찰된다. Quarkus는 JVM 모드에서 Spring Boot 대비 2.3배 빠르게 시작하고, 네이티브 모드에서는 메모리 RSS가 절반 수준이다. 처리량(TPS)에서도 Quarkus 공식 벤치마크는 동일 워크로드 기준 Spring Boot 대비 2.7배 차이를 보고했다.

위 표의 수치는 LogicMonitor의 비교 자료와 Quarkus 공식 벤치마크에서 인용했다. 한 가지 주의할 점은 GitHub Stars 수치다. Spring Boot가 5배 이상의 스타를 가지고 있다는 사실은 단순히 인기를 의미할 뿐만 아니라 채용 시장과 사내 운영 노하우의 두께를 의미한다. 성능 우위가 곧 도입 가치로 직결되지 않는 이유다. 다만 Kubernetes 환경에서 Pod 수십 개를 같은 노드에 빽빽이 띄워야 하는 멀티테넌시 SaaS, 혹은 Lambda·Cloud Run 같은 함수형 런타임에서는 70MB 차이가 비용에 직접 반영된다는 점도 같이 봐야 한다.

같은 REST 엔드포인트, 다른 표준을 쓰는 두 프레임워크

Spring Boot vs Quarkus는 비슷한 어노테이션을 쓰지만 표준이 갈린다. Spring Boot는 자체 정의한 spring-web 어노테이션(@RestController, @GetMapping)을 사용하고, Quarkus는 Jakarta EE 표준의 JAX-RS 어노테이션(@Path, @GET)을 사용한다. 둘 다 동일한 REST 엔드포인트를 만들지만 의존성과 설정 방식에서 차이가 드러난다.

<!-- Spring Boot 4.0.6 — pom.xml 핵심 의존성 -->
<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
        <version>4.0.6</version>
    </dependency>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-data-jpa</artifactId>
        <version>4.0.6</version>
    </dependency>
</dependencies>

<!-- Spring Boot 4.0.6 — pom.xml 핵심 의존성 -->
<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
        <version>4.0.6</version>
    </dependency>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-data-jpa</artifactId>
        <version>4.0.6</version>
    </dependency>
</dependencies>

Spring Boot의 starter 의존성은 일종의 메타 패키지로 동작한다. spring-boot-starter-web 하나를 추가하면 Tomcat, Spring MVC, Jackson, Logback이 한 번에 따라온다. 시작 비용은 있지만 설정 충돌이 거의 없다는 장점이 있다.

<!-- Quarkus 3.34.6 — pom.xml 핵심 의존성 -->
<dependencies>
    <dependency>
        <groupId>io.quarkus</groupId>
        <artifactId>quarkus-rest</artifactId>
    </dependency>
    <dependency>
        <groupId>io.quarkus</groupId>
        <artifactId>quarkus-rest-jackson</artifactId>
    </dependency>
    <dependency>
        <groupId>io.quarkus</groupId>
        <artifactId>quarkus-hibernate-orm-panache</artifactId>
    </dependency>
</dependencies>

<!-- Quarkus 3.34.6 — pom.xml 핵심 의존성 -->
<dependencies>
    <dependency>
        <groupId>io.quarkus</groupId>
        <artifactId>quarkus-rest</artifactId>
    </dependency>
    <dependency>
        <groupId>io.quarkus</groupId>
        <artifactId>quarkus-rest-jackson</artifactId>
    </dependency>
    <dependency>
        <groupId>io.quarkus</groupId>
        <artifactId>quarkus-hibernate-orm-panache</artifactId>
    </dependency>
</dependencies>

Quarkus는 익스텐션 단위로 잘게 쪼개져 있다. quarkus-rest는 RESTEasy Reactive 위에 구축된 비동기 REST 엔진이고, quarkus-rest-jackson은 Jackson 직렬화만 담당하며, Panache는 Active Record 패턴을 Hibernate ORM 위에 올려준 라이브러리다. 의존성 트리가 가벼워지는 대신 어떤 익스텐션을 골라야 할지 알아야 한다.

# Quarkus application.yml — 데이터베이스 + 라이브 리로드 설정
quarkus:
  datasource:
    db-kind: postgresql
    username: app
    password: secret
    jdbc:
      url: jdbc:postgresql://localhost:5432/orders
  hibernate-orm:
    database:
      generation: update
  log:
    level: INFO

# Quarkus application.yml — 데이터베이스 + 라이브 리로드 설정
quarkus:
  datasource:
    db-kind: postgresql
    username: app
    password: secret
    jdbc:
      url: jdbc:postgresql://localhost:5432/orders
  hibernate-orm:
    database:
      generation: update
  log:
    level: INFO

위 설정은 Quarkus의 핵심인 Dev Services와도 연결된다. 개발 모드에서 quarkus.datasource.devservices.enabled=true로 두면 Testcontainers가 자동으로 PostgreSQL 컨테이너를 띄워준다. Spring Boot도 Testcontainers 통합이 가능하지만 Quarkus는 처음부터 그것을 핵심 개발 경험으로 못 박았다.

Testcontainers에 대한 내용은 Testcontainers Spring Boot 통합 테스트 가이드 참고

AI 통합 전쟁: Spring AI vs LangChain4j

2026년 시점에서 Spring Boot vs Quarkus의 가장 뜨거운 격전지는 LLM 통합이다. Spring 진영은 Spring AI 2.0.0-M2로 Spring Boot 4 기반 통합을 내놨고, Quarkus 진영은 LangChain4j 통합을 quarkus-langchain4j 익스텐션으로 묶어 네이티브 컴파일까지 동작하도록 만들었다. 두 접근법의 결정적 차이는 시작 비용과 제공자 커버리지다.

// Spring AI — Auto-configuration 기반 Chat 엔드포인트
@RestController
public class ChatController {
    private final ChatClient chatClient;

    public ChatController(ChatClient.Builder builder) {
        // application.yml의 spring.ai.openai.api-key를 자동으로 읽어들임
        this.chatClient = builder.build();
    }

    @GetMapping("/chat")
    public String chat(@RequestParam String prompt) {
        return chatClient.prompt(prompt).call().content();
    }
}

// Spring AI — Auto-configuration 기반 Chat 엔드포인트
@RestController
public class ChatController {
    private final ChatClient chatClient;

    public ChatController(ChatClient.Builder builder) {
        // application.yml의 spring.ai.openai.api-key를 자동으로 읽어들임
        this.chatClient = builder.build();
    }

    @GetMapping("/chat")
    public String chat(@RequestParam String prompt) {
        return chatClient.prompt(prompt).call().content();
    }
}

Spring AI는 기존 Spring Boot 사용자에게 익숙한 자동 설정 모델을 그대로 쓴다. application.yml에 API 키를 넣고 ChatClient.Builder를 주입받으면 끝이다. 운영 관점에서 Actuator·Micrometer 메트릭이 자동 연결되는 점이 큰 장점이다.

// LangChain4j on Quarkus — AI 서비스 인터페이스 선언
@RegisterAiService
public interface OrderAssistant {

    @SystemMessage("당신은 주문 도우미입니다. 한국어로 간결하게 답변하세요.")
    String chat(@UserMessage String userInput);
}

@Path("/assistant")
public class AssistantResource {
    @Inject OrderAssistant assistant;

    @GET
    public String ask(@QueryParam("q") String question) {
        return assistant.chat(question);
    }
}

// LangChain4j on Quarkus — AI 서비스 인터페이스 선언
@RegisterAiService
public interface OrderAssistant {

    @SystemMessage("당신은 주문 도우미입니다. 한국어로 간결하게 답변하세요.")
    String chat(@UserMessage String userInput);
}

@Path("/assistant")
public class AssistantResource {
    @Inject OrderAssistant assistant;

    @GET
    public String ask(@QueryParam("q") String question) {
        return assistant.chat(question);
    }
}

LangChain4j on Quarkus는 인터페이스 선언만으로 AI 서비스를 만든다. @RegisterAiService 어노테이션이 빌드 타임에 구현체를 생성하기 때문에 GraalVM 네이티브 이미지에 그대로 올라가고, 시작 시간이 100ms 아래로 떨어진다. 함수형 런타임이나 IoT 게이트웨이처럼 메모리 한도가 빡빡한 환경에서 LangChain4j 우위가 분명한 이유다.

Native 컴파일은 누가 더 잘하나

Spring Boot vs Quarkus의 우열이 가장 극명하게 드러나는 영역이 GraalVM Native Image다. Spring Boot 3.x부터 native 빌드가 정식 지원되었지만, 리플렉션 메타데이터를 자동 등록하는 방식이라 의존성 호환성에 시간을 쓰게 된다. Quarkus는 익스텐션마다 substitution과 reflection-config가 사전 준비되어 있어 빌드 명령 한 줄로 끝나는 경우가 많다.

spring boot의 native 빌드에 대해서는 Spring Boot GraalVM Native Image 빌드 하기를 참고.

# Spring Boot Native 빌드 (Maven + spring-boot-starter-parent)
./mvnw -Pnative native:compile

# Quarkus Native 빌드 (Maven)
./mvnw package -Dnative

# Quarkus Native 빌드 (컨테이너 내부에서 빌드 — JDK 없이도 가능)
./mvnw package -Dnative -Dquarkus.native.container-build=true

# Spring Boot Native 빌드 (Maven + spring-boot-starter-parent)
./mvnw -Pnative native:compile

# Quarkus Native 빌드 (Maven)
./mvnw package -Dnative

# Quarkus Native 빌드 (컨테이너 내부에서 빌드 — JDK 없이도 가능)
./mvnw package -Dnative -Dquarkus.native.container-build=true

위 명령에서 주목할 부분은 quarkus.native.container-build 옵션이다. 로컬 머신에 GraalVM JDK를 설치하지 않아도 컨테이너로 네이티브 빌드를 끝낼 수 있다. CI 파이프라인에서 GraalVM 설치 단계를 생략할 수 있어 빌드 시간이 줄어든다. Spring Boot에서는 buildpacks를 통해 비슷한 효과를 낼 수 있지만 통상 더 오래 걸린다.

# 빌드 결과 비교 (동일 REST + JPA 워크로드 기준)
$ ls -lh target/*.bin
-rwxr-xr-x  Spring Boot Native: 88M
-rwxr-xr-x  Quarkus Native:     54M

# 시작 시간 측정
$ time ./quarkus-app
real  0m0.052s

$ time ./spring-boot-app
real  0m0.104s

# 빌드 결과 비교 (동일 REST + JPA 워크로드 기준)
$ ls -lh target/*.bin
-rwxr-xr-x  Spring Boot Native: 88M
-rwxr-xr-x  Quarkus Native:     54M

# 시작 시간 측정
$ time ./quarkus-app
real  0m0.052s

$ time ./spring-boot-app
real  0m0.104s

위 결과는 Quarkus 벤치마크 보고서와 자체 측정을 정리한 것이다. Spring Boot 진영의 Spring Native가 점진적으로 따라잡고 있지만 빌드 결과물의 크기와 메모리 사용량은 여전히 Quarkus가 30~50% 가볍다. Quarkus 3.35에서 도입되는 reflection-free Jackson 직렬화는 native image 호환성을 더 끌어올려 격차를 벌리려는 움직임이다.

어떤 상황에서 무엇을 골라야 하는가

Spring Boot vs Quarkus 의사결정은 한 가지 변수로 끝나지 않는다. 팀의 자바 경험, 운영 환경(Kubernetes vs Lambda vs 온프레미스), AI 통합 필요성, 기존 자산이 모두 변수다. 다음 표는 시나리오별로 권장 프레임워크를 정리한 것이다.

표를 단순화하면 “기존 자산이 Spring 기반이면 Spring Boot, 클라우드 비용 절감과 시작 속도가 곧 비즈니스 가치인 환경이면 Quarkus”로 요약된다. 다만 한쪽으로 결정한 뒤에도 의사결정을 다시 검토할 만한 시점이 있다. Spring Boot 4.x의 AOT Repositories나 Quarkus 3.35의 Jackson 최적화처럼 양 진영 모두 빌드 타임 처리를 강화하는 흐름이 가속되고 있어, 1~2년 단위로 격차가 좁혀지거나 다시 벌어질 수 있다는 점을 염두에 두는 것이 좋다.

FAQ

마치며

지금까지 Spring Boot vs Quarkus를 2026년 시점에서 정리해 보았다. 사실 두 프레임워크 사이에서 갈팡질팡하는 시간이 가장 비싸다는 것이 실무에서 얻은 교훈이다. 직전 프로젝트에서 사내 표준이 Spring Boot인데 Lambda 비용을 줄이려고 일부 모듈만 Quarkus로 빼봤는데, 결과적으로 빌드 파이프라인이 두 갈래가 되며 운영 비용이 늘었다. 처음부터 한쪽에 베팅하고 사이드카를 다른 쪽으로 두는 전략이 단순하면서도 안정적이었다. 만약 지금 새 프로젝트를 시작한다면, Spring Boot vs Quarkus 결정에 앞서 팀의 기존 자산과 향후 3년의 운영 환경을 먼저 그려본 다음 그 그림에 어울리는 프레임워크를 고르는 순서가 가장 현실적이다.

함께 보면 좋은 글

Spring Boot GraalVM Native Image 빌드 하기
Quarkus Native 빌드 가이드: GraalVM AOT 컴파일과 운영 배포 전략
컨테이너 환경에서 Spring Boot 콜드 스타트 6가지 개선 전략
Java AOT Cache 적용기: JVM 플래그 하나로 시작 시간 42% 줄이기