시리즈 되돌아보기 7편의 글에 걸쳐 JVM 위의 동시성 기술이 어떤 문제를 풀기 위해 등장했고, 어떻게 발전해왔는지를 살펴봤습니다. 각 기술이 해결하려 한 핵심 문제 한 가지를 중심으로 되돌아봅니다. Part 1 — 동시성과 병렬성의 기초. 동시성(concurrency)과 병렬성(parallelism)은 다르다. 동기/비동기는 “결과를 누가 챙기는가”, 블로킹/논블로킹은 “제어권이 언제 돌아오는가” — 이 두 축이 독립적이라는 것을 정리했습니다. 이후 모든 기술을 이해하는 … 더 읽기
Reactor 위에서 동기 코드를 쓴다 — Spring이 suspend fun을 처리하는 방식 Part 5에서 코루틴의 원리를 다뤘습니다 — CPS 변환, 상태 머신, Flow, 구조화된 동시성. 코루틴이 “동기 코드처럼 보이지만 논블로킹인” 코드를 가능하게 해준다는 것을 이해했습니다. 하지만 한 가지 의문이 남아 있습니다. Spring WebFlux는 Reactor 기반입니다. Part 4에서 다뤘듯이, WebFlux의 요청 처리 파이프라인은 Mono/Flux를 통해 흐릅니다. 컨트롤러가 … 더 읽기
Reactor가 웹을 만났을 때 — 적은 스레드로 많은 연결을 처리하는 법 Part 3에서 Reactive Streams 스펙과 Project Reactor의 Mono/Flux, 연산자, 스케줄러를 다뤘습니다. Reactor는 비동기 데이터 스트림을 처리하는 강력한 라이브러리이지만, 그 자체로는 HTTP 요청을 받거나 응답을 보내는 기능이 없습니다. 이 글에서는 Reactor 위에 Spring이 구축한 WebFlux 프레임워크를 다룹니다. Spring MVC의 어떤 한계를 해결하려고 만들어졌는지, 내부에서 Netty의 … 더 읽기
CompletableFuture 너머의 세계 — 스트림을 제어하는 새로운 방법 Part 2에서 Java 동시성 API의 발전을 따라갔습니다. Thread → ExecutorService → CompletableFuture로 추상화 수준이 올라가면서 비동기 프로그래밍이 점점 편해졌지만, CompletableFuture에는 두 가지 근본적인 한계가 남아 있었습니다. 첫째, 단건 처리에 특화되어 있습니다. CompletableFuture는 “하나의 비동기 작업이 완료되면 결과를 처리한다”는 모델입니다. 그런데 실시간으로 계속 들어오는 데이터 — 예를 들어 … 더 읽기
서론 이전 글에서 ThreadLocal과 MDC가 어떻게 Tracing Context를 저장하고 전파하는지 살펴봤습니다. 동기 환경에서는 “한 요청 = 한 스레드”라는 단순한 모델 덕분에 ThreadLocal만으로도 충분했습니다. 하지만 Spring WebFlux로 넘어오면 상황이 완전히 달라집니다. WebFlux는 소수의 스레드가 수천 개의 요청을 동시에 처리하는 Event Loop 모델을 사용합니다. 하나의 요청이 처리되는 동안 스레드가 수시로 바뀔 수 있죠. 이 환경에서 ThreadLocal은 더 … 더 읽기