🚀 Spring WebFlux와 리액티브 프로그래밍

📌 목차

1. 왜 Spring WebFlux를 선택했는가?
2. 메모리 관점에서 Mono/Flux 이해하기
3. Publisher-Subscriber 패턴의 실제
4. Spring WebFlux 실행 환경 이해
5. 실제 데이터 흐름 추적하기

---

1. 왜 Spring WebFlux를 선택했는가?

🎯 리액티브 아키텍처가 필요한 이유

높은 동시성 처리 요구사항

• 수천~수만 개의 동시 연결 처리 필요
• 전통적인 스레드 모델(1요청=1스레드)로는 메모리 부족
• 실시간 이벤트 스트리밍 (SSE) 지원 필요

I/O 집약적 작업 특성

suspend fun check(): Response {
    val tasks = taskService.query(...).asFlow().toList()  // DB 조회
    val deliveries = deliveryService.query(...).toList()   // 다른 서비스 조회
    val editorResource = editorResourceClient.queryOne(...) // 외부 API 호출
}

• CPU 연산보다 I/O 대기 시간이 대부분
• 논블로킹 I/O로 대기 시간 동안 다른 요청 처리 가능

마이크로서비스 환경

• 서비스 간 네트워크 호출이 빈번
• 동기 방식으로는 cascading failure 위험
• Circuit Breaker, Retry, Timeout을 리액티브하게 처리

---

2. 메모리 관점에서 Mono/Flux 이해하기

📦 일반 변수 vs Mono/Flux

일반 변수 - 즉시 실행, 즉시 메모리 할당

val text: String = "test"  
// 메모리: [0x1234] → "test" (바로 저장됨)

val result = getDataFromDB()  
// DB 쿼리 즉시 실행 → 3초 대기 → 메모리에 결과 저장

Mono/Flux - 실행 안 함, 명령어만 저장

val mono: Mono<String> = Mono.just("test")
// 메모리: [0x5678] → {명령: "test 반환하기"} (실행 안 됨!)

val flux: Flux<Task> = taskRepository.findAll()
// 메모리: [0x9999] → {명령: "DB에서 조회하기"} (쿼리 안 날림!)

🎯 핵심: Mono/Flux는 "실행 계획서"

// Mono/Flux = 실행 계획서
Mono<Pizza> = "피자 만들 계획"  (피자 ❌)

// subscribe() = 실행 버튼  
.subscribe() = "계획 실행!"  (피자 ✅)

// 메모리 관점
Mono = [명령어 리스트]  // 가벼움
subscribe() = 명령어 실행 → 실제 메모리 할당

💾 메모리에서 실제로 일어나는 일

Mono/Flux 생성 시

메모리 상태:
[0xA000] taskMono = {
    type: "Mono",
    operation: "SELECT * FROM task WHERE uuid = ?",
    params: [uuid],
    executed: false  👈 아직 실행 안 됨
}

연산자 체인 시

메모리 상태:
[0xB000] result = {
    type: "Mono",
    chain: [
        {op: "SELECT", params: [uuid]},        👈 1번 명령
        {op: "MAP", fn: "state 변경"},         👈 2번 명령  
        {op: "FLATMAP", fn: "UPDATE task..."}  👈 3번 명령
    ],
    executed: false  👈 여전히 실행 안 됨!
}

---

3. Publisher-Subscriber 패턴의 실제

🎬 Spring WebFlux에서 실제 Subscriber는 누구?

WebFlux Controller의 경우

@GetMapping("{uuid}")
fun sseScopeTask(@PathVariable taskUuid: UUID): Flux<ServerSentEvent<TaskUpdatedEvent>> {
    return taskUpdatedEventChannel.events.asFlux()
        .map { ServerSentEvent.builder(it).build() }
}

• Spring WebFlux 프레임워크가 자동으로 구독
• HTTP 클라이언트(브라우저)가 최종 소비자
• 클라이언트가 연결하면 → Spring이 자동으로 .subscribe() 호출

Coroutines 사용 시

suspend fun complete(taskUuid: UUID, completedBy: UUID) {
    val task = taskDomainQueryService.queryForUpdate(taskUuid)  
    // .awaitSingle()이 내부적으로 subscribe() + 결과 대기
    orderClient.queryOne(spec).awaitSingleOrNull()  
}

📊 Publisher-Subscriber 실제 구현 정리

Publisher	Subscriber	구독 시점
Mono<Task> (Repository)	Spring WebFlux	Controller 반환 시
Flux<Event> (SSE)	HTTP 클라이언트	브라우저 연결 시
Mono/Flux	Coroutines	.await*() 호출 시
Event (Domain)	@EventListener	애플리케이션 시작 시
Flux<Message>	RabbitMQ Binder	스트림 바인딩 시

---

4. Spring WebFlux 실행 환경 이해

🏃 개발자는 subscribe()를 쓰지 않는다!

우리가 작성하는 코드

@RestController
class TaskController {
    @GetMapping("/task/{id}")
    suspend fun getTask(@PathVariable id: Long): Task {
        return taskRepository.findById(id).awaitSingle()
    }
}

Spring이 자동으로 하는 일

// 🔴 Spring WebFlux 내부 (우리가 안 봄)
class SpringWebFluxEngine {
    fun processRequest(request: HttpRequest) {
        // 1. Controller 메서드 호출
        val mono = controller.getTask(123)
        
        // 2. 자동으로 구독 및 실행
        mono.subscribe(object : Subscriber<Task> {
            override fun onNext(task: Task) {
                // ✅ 여기서 실제 DB 쿼리 실행됨!
                response.writeJson(task)
            }
        })
    }
}

💾 블로킹 vs 논블로킹 메모리 비교

Spring MVC (블로킹)

메모리 상태:
[Thread-1] 
    ↓ 요청 받음
    ↓ DB 쿼리 (3초 대기) 🚫 Thread 블로킹!
    ↓ 결과 받음
    ↓ JSON 변환
    ↓ 응답
[Thread-1 해제]

문제: 3초 동안 Thread-1이 놀고 있음

Spring WebFlux (논블로킹)

메모리 상태:
[Thread-1] 
    ↓ 요청 받음
    ↓ Mono 생성 (명령만)
    ↓ Spring에 Mono 전달
    ↓ Thread-1 해제! ✅ (다른 요청 처리 가능)

[EventLoop] (별도 스레드)
    ↓ DB 쿼리 시작
    ↓ (3초 후) 결과 받음
    ↓ JSON 변환
    ↓ 응답

📊 100개 요청 동시 처리 비교

Spring MVC:
100개 요청 → 100개 Thread 필요
Thread 1개 = 1MB 메모리
총 메모리 = 100MB

Spring WebFlux:
100개 요청 → 4개 Thread로 처리 (CPU 코어 수)
총 메모리 = 4MB

---

5. 실제 데이터 흐름 추적하기

🌊 Task 완료 시 데이터 흐름

Step 1: 사용자 요청

[웹 브라우저] → HTTP POST /task/complete/123-456

Step 2: Service에서 이벤트 발행

suspend fun complete(taskUuid: UUID, completedBy: UUID) {
    val task = taskRepository.findByUuid(taskUuid)
    task.state = TaskState.COMPLETED
    
    // 이벤트 발행 (Publisher)
    task.publishTaskCompletedEvent(...)  
    taskRepository.save(task)
}

Step 3: 여러 구독자가 동시 처리

graph TB
    A[사용자 클릭] --> B[Controller]
    B --> C[Service: Task 상태 변경]
    C --> D[이벤트 발행: TaskCompletedEvent]
    
    D --> E[Spring Event Bus]
    
    E --> F[구독자1: SSE Handler]
    E --> G[구독자2: RabbitMQ Handler]  
    E --> H[구독자3: External API Handler]
    E --> I[구독자4: 통계 Handler]

⚡ 발행-구독의 장점

// ❌ 기존 방식 (직접 호출)
fun completeTask(task: Task) {
    task.state = COMPLETED
    taskRepository.save(task)
    
    // 모든 곳을 직접 호출해야 함 😱
    sseService.notify(task)
    rabbitMQ.send(task)
    emailService.send(task)
    statisticsService.update(task)
    pivoApi.notify(task)
}

// ✅ 발행-구독 방식
fun completeTask(task: Task) {
    task.state = COMPLETED
    taskRepository.save(task)
    
    // 이벤트 하나만 발행! 🎉
    publishEvent(TaskCompletedEvent(task))
}

🔥 Hot vs Cold Publisher

Cold Publisher (구독할 때마다 새로 시작)

val cold = Mono.fromCallable { Random.nextInt() }
cold.subscribe()  // 결과: 42
cold.subscribe()  // 결과: 17 (다른 값!)

Hot Publisher (구독과 무관하게 데이터 발생)

val hot = Sinks.many().multicast()
hot.emitNext(42)
hot.asFlux().subscribe()  // 42 못 받음 (이미 지나감)

---

🎯 핵심 정리

Spring WebFlux 실무 요약

1. 우리는 subscribe() 안 씀

   // ✅ 이렇게만 하면 됨
   @GetMapping("/data")
   suspend fun getData(): Data {
       return service.getData()
   }

2. Spring이 알아서 실행

   • Controller가 Mono/Flux 반환
   • Spring이 자동으로 subscribe()
   • 결과를 HTTP Response로 변환

3. 메모리 효율

   • MVC: 1요청 = 1Thread = 1MB
   • WebFlux: N요청 = 4Thread = 4MB

4. 발행-구독 = 방송국 시스템

   • 발행자(방송국): 이벤트 생성만 담당
   • 구독자(시청자): 원하는 채널 구독하여 처리
   • Spring(케이블회사): 연결 자동 관리

왜 리액티브 프로그래밍인가?

• 늦은 실행: 필요할 때만 실행
• 재사용: 같은 계획으로 여러 번 실행 가능
• 조합: 여러 계획을 합쳐서 큰 계획 만들기
• 비동기: 계획만 짜고 다른 일 하기
• 리소스 효율: 적은 스레드로 많은 요청 처리