WebFlux vs MVC + Virtual Threads — 2026년 기준 선택 가이드

// MVC + Virtual Threads — 기존 블로킹 코드 그대로 사용
@GetMapping("/users/{id}")
public UserResponse getUser(@PathVariable Long id) {
    // JPA 블로킹 호출이지만, Virtual Thread가 I/O 대기 시 양보
    User user = userRepository.findById(id)
            .orElseThrow(() -> new UserNotFoundException(id));

    // 외부 API 블로킹 호출 — 역시 자동으로 양보
    CreditScore score = creditService.getScore(user.getSsn());

    return UserResponse.from(user, score);
}

// WebFlux — 동일한 로직을 리액티브로 작성
@GetMapping("/users/{id}")
public Mono<UserResponse> getUser(@PathVariable Long id) {
    return userRepository.findById(id)  // R2DBC 사용 필수
            .switchIfEmpty(Mono.error(new UserNotFoundException(id)))
            .flatMap(user ->
                creditService.getScore(user.getSsn())  // 논블로킹 클라이언트 필요
                    .map(score -> UserResponse.from(user, score))
            );
}

캐리어 스레드 (OS 스레드, 소수)
├── Virtual Thread A → DB 쿼리 중 (언마운트, 대기)
├── Virtual Thread B → 실행 중
├── Virtual Thread C → API 호출 중 (언마운트, 대기)
└── Virtual Thread D → 실행 중

// Virtual Thread는 수십만 개 생성 가능
// 캐리어 스레드는 CPU 코어 수만큼만 유지

// JPA, JDBC — 그냥 된다
@Transactional
public Order createOrder(OrderRequest request) {
    // JPA 엔티티 저장 — 블로킹이지만 VT가 알아서 처리
    Order order = orderRepository.save(Order.from(request));

    // JDBC 기반 레거시 라이브러리 — 역시 그냥 동작
    legacyBillingSystem.charge(order.getPaymentInfo());

    return order;
}

// R2DBC 필수 — JPA 사용 불가
public Mono<Order> createOrder(OrderRequest request) {
    return r2dbcOrderRepository.save(Order.from(request))
            .flatMap(order ->
                // 레거시 블로킹 라이브러리? Schedulers.boundedElastic()으로 감싸야 함
                Mono.fromCallable(() -> legacyBillingSystem.charge(order.getPaymentInfo()))
                    .subscribeOn(Schedulers.boundedElastic())
                    .thenReturn(order)
            );
}

# application.yml — Virtual Threads 활성화 (Spring Boot 3.2+)
spring:
  threads:
    virtual:
      enabled: true

// MVC + VT — 스택 트레이스가 깔끔하다
java.lang.NullPointerException
    at com.example.UserService.getUser(UserService.java:25)
    at com.example.UserController.getUser(UserController.java:18)
    // 읽기 쉬운 동기식 스택 트레이스

// WebFlux — 스택 트레이스가 복잡하다
java.lang.NullPointerException
    at com.example.UserService.lambda$getUser$0(UserService.java:25)
    at reactor.core.publisher.FluxMap$MapSubscriber.onNext(FluxMap.java:106)
    at reactor.core.publisher.FluxFlatMap$FlatMapMain.tryEmit(FluxFlatMap.java:543)
    // 리액터 내부 스택이 섞여서 원인 파악이 어려움

// WebFlux — 백프레셔가 자연스럽게 동작
@GetMapping(value = "/events", produces = MediaType.TEXT_EVENT_STREAM_VALUE)
public Flux<ServerSentEvent<String>> streamEvents() {
    return eventService.getEventStream()
            .onBackpressureBuffer(1000)  // 버퍼 크기 제한
            .map(event -> ServerSentEvent.<String>builder()
                    .data(event.toJson())
                    .build());
    // 클라이언트가 느리면 자동으로 속도 조절
}

// WebFlux가 빛나는 전형적인 예 — 실시간 대시보드
@GetMapping(value = "/dashboard", produces = MediaType.TEXT_EVENT_STREAM_VALUE)
public Flux<DashboardData> streamDashboard() {
    // 세 개의 실시간 소스를 결합
    Flux<CpuMetric> cpu = metricsService.streamCpu();
    Flux<MemoryMetric> memory = metricsService.streamMemory();
    Flux<RequestRate> requests = metricsService.streamRequests();

    return Flux.combineLatest(cpu, memory, requests,
            (c, m, r) -> new DashboardData(c, m, r))
            .onBackpressureLatest();  // 느린 클라이언트에게는 최신 값만 전달
}

// MVC + VT로 충분한 전형적인 예 — 주문 처리 API
@RestController
@RequiredArgsConstructor
public class OrderController {

    private final OrderService orderService;

    @PostMapping("/orders")
    public ResponseEntity<OrderResponse> createOrder(@RequestBody @Valid OrderRequest request) {
        // 복잡한 비즈니스 로직도 동기 코드로 깔끔하게
        Order order = orderService.create(request);
        return ResponseEntity.created(URI.create("/orders/" + order.getId()))
                .body(OrderResponse.from(order));
    }
}

@Service
@RequiredArgsConstructor
public class OrderService {

    private final OrderRepository orderRepository;        // JPA
    private final InventoryService inventoryService;      // 블로킹 호출
    private final PaymentGateway paymentGateway;          // 외부 API

    @Transactional
    public Order create(OrderRequest request) {
        // 재고 확인 → 결제 → 주문 저장
        // 세 단계 모두 블로킹이지만, VT 덕분에 동시성 문제 없음
        inventoryService.reserve(request.getItems());
        PaymentResult payment = paymentGateway.charge(request.getPaymentInfo());
        return orderRepository.save(Order.from(request, payment));
    }
}

// 하이브리드 — MVC 컨트롤러 + WebClient 비동기 호출
@Service
@RequiredArgsConstructor
public class AggregationService {

    private final WebClient webClient;
    private final UserRepository userRepository;  // JPA — 블로킹

    public AggregatedData aggregate(Long userId) {
        // JPA 블로킹 호출 — VT가 처리
        User user = userRepository.findById(userId)
                .orElseThrow();

        // 여러 외부 API를 병렬 호출 — WebClient로 효율적으로
        CompletableFuture<Profile> profileFuture = webClient.get()
                .uri("/api/profiles/{id}", userId)
                .retrieve()
                .bodyToMono(Profile.class)
                .toFuture();

        CompletableFuture<List<Activity>> activitiesFuture = webClient.get()
                .uri("/api/activities/{id}", userId)
                .retrieve()
                .bodyToFlux(Activity.class)
                .collectList()
                .toFuture();

        // 병렬 결과 취합
        Profile profile = profileFuture.join();
        List<Activity> activities = activitiesFuture.join();

        return new AggregatedData(user, profile, activities);
    }
}

새 프로젝트 시작
    │
    ├── 실시간 스트리밍/SSE/백프레셔가 핵심인가?
    │     ├── Yes → WebFlux
    │     └── No ↓
    │
    ├── JPA/JDBC/블로킹 라이브러리를 써야 하나?
    │     ├── Yes → MVC + Virtual Threads
    │     └── No ↓
    │
    ├── 팀에 리액티브 경험이 있나?
    │     ├── Yes → WebFlux 고려 가능
    │     └── No → MVC + Virtual Threads
    │
    └── 기본 선택: MVC + Virtual Threads

// 주의: synchronized 블록 안에서 블로킹 I/O를 하면 캐리어 스레드가 핀된다
synchronized (lock) {
    // 이 안에서 I/O 하면 Virtual Thread가 양보하지 못함
    database.query("SELECT ...");  // 캐리어 스레드 점유!
}

// 해결: ReentrantLock 사용
private final ReentrantLock lock = new ReentrantLock();

lock.lock();
try {
    database.query("SELECT ...");  // Virtual Thread가 정상적으로 양보
} finally {
    lock.unlock();
}

// 주의: Virtual Thread는 매우 많이 생성되므로 ThreadLocal이 메모리를 많이 차지
private static final ThreadLocal<ExpensiveObject> cache =
    ThreadLocal.withInitial(ExpensiveObject::new);
// VT 100만 개 = ExpensiveObject 100만 개 생성 가능!

// 대안: ScopedValue (Java 21+ preview, Java 25 정식)
private static final ScopedValue<RequestContext> CONTEXT = ScopedValue.newInstance();