콘텐츠로 바로가기

Reactive Programming & Backpressure

비동기 데이터 흐름을 선언적으로 다루는 프로그래밍 사상과, 소비자가 생산자의 속도를 제어하는 백프레셔(Backpressure) 물리학을 다루는 학습 노드입니다.

sys.entry
M

Me

hyunyoun's Blog

posts6 min read

1. Overview

리액티브 프로그래밍 및 백프레셔(Reactive Programming & Backpressure, RPB)는 데이터가 오기를 기다리며 스레드를 낭비하는(Blocking) 대신, 데이터가 도착할 때마다 즉시 반응(Reactive)하여 하드웨어 효율을 극한으로 끌어올리는 현대적 소프트웨어 물리학입니다.

학습자는 데이터를 단일 값이 아닌 '흐름(Stream)'으로 취급하고, 이를 다양한 연산작용(Filter, Map, Zip)으로 가공하는 선언적 수리 모델을 배웁니다. 특히, 빠른 생산자가 느린 소비자를 압도하여 메모리를 터트리는 것을 방지하는 **백프레셔(Backpressure)**의 수리적 사상과 수신 거부(Flow Control)의 물리적 동작을 익힙니다. 이를 통해 적은 CPU와 메모리만으로도 수만 개의 동시 연결을 안정적으로 처리하는 하이엔드 비동기 인프라 역량을 확보합니다.

2. Scope & Boundaries

In-Scope

  • Reactive Core Concepts: 비차단(Non-blocking), 비동기(Asynchronous) 소통 물리학
  • The Reactive Manifesto: 응답성, 회복성, 유연성, 메시지 기반의 4대 수리 가치
  • Backpressure Mechanics: Drop, Buffer, Latest, Push-Pull 하이브리드 제어
  • Async Data Streams: Observable, Flux, Mono 등 시간에 따른 데이터 수열 처리
  • Concurrency in Reactive: 스케줄러(Scheduler)를 이용한 하드웨어 스레드 스위칭 물리학

Out-of-Scope

  • Java, JS 등 개별 언어의 구체적인 문법 상세 (프로그래밍 언어 영역으로 위임)
  • 메시지 브로커(Kafka 등)의 클러스터링 구성 (07-04-01 영역에서 분담)

Boundaries

  • RPB vs. Async Programming: 일반 비동기가 '결과를 나중에 받기'에 집중한다면, RPB는 '결과들이 계속 흐르는 파이프라인과 그 속도 조절'에 집중하여 구분합니다.

3. Counterexample

  • 단순히 "비동기 함수 쓰기"라 설명하는 것은 RPB 학습이 아닙니다. 왜 백프레셔 없이 무제한으로 쌓이는 메시지 큐가 하드웨어의 메모리 부족(OOM) 장애를 일으키는 물리적 원흉인지 수리적으로 증명할 수 있어야 하며, 리액티브 체인 내부에서 '블로킹 호출(Thread.sleep 등)' 한 번이 전체 이벤트 루프를 어떻게 물리적으로 마비시키는지 논증하지 못한다면 RPB의 치명적 함정을 이해하지 못한 것입니다.

4. Prerequisites

  • Pub-Sub, Observer & Event-driven Flows (Basic): 옵저버 패턴 이해가 필수입니다. (07-04-02 POE)
  • Concepts & Language Fundamentals (Recommended): 일급 함수와 람다 이해가 권장됩니다. (05-01-01 CLF)

5. Learning Map

  1. Wait vs Wake up: 데이터를 기다리는 물리적 낭비(Blocking)에서 '데이터가 오면 깨워주는(Async)' 방식으로 전환합니다.
  2. Pipelines of Events: 데이터 조각들을 파이프 속에 흘려보내며 수리적으로 가공하는 수순을 익힙니다.
  3. The Flood Control: 쏟아지는 데이터 폭포 앞에서 소비자가 "잠시 멈춰!"라고 외치는 물리적 제동 장치를 구축합니다.
  4. Hardware Symbiosis: 적은 하드웨어 자원으로 수십 배의 트래픽을 견디는 반응형 시스템의 가용성을 완성합니다.

6. Learning Topics

Basic

Core: 리액티브 프로그래밍의 수리 사상 (Reactive Foundations)

  • Why to Learn: 대규모 유저 요청을 하드웨어 스레드 폭발 없이 처리하기 위해서입니다.
  • What to Learn:
    • Declarative Programming: '어떻게 할지'가 아닌 '무엇이 일어날지' 정의하는 수리 기법
    • Event-Loop Mechanics: 단일/소수 스레드로 수천 건의 I/O를 제어하는 물리 구조
    • Laziness: 구독(Subscribe) 전에는 아무 물리 연산도 일어나지 않는 성질
  • How to Learn:
    • 전통적인 for-each 루프와 Flux.fromIterable의 실행 완료 시간 및 메모리 점유율 비교 실습
    • '지연 평가(Lazy Evaluation)'가 하드웨어 리소스 효율을 어떻게 물리적으로 높이는지 분석
  • Implement: 데이터가 도착할 때마다 로그를 찍는 간단한 리액티브 스트림 정의

Core: 스트림 연산과 마블 다이어그램 (Stream Operations)

  • Why to Learn: 복잡한 비동기 흐름을 시각적으로 이해하고 수리적으로 조립하기 위함입니다.
  • What to Learn:
    • Filter, Map, FlatMap: 데이터의 속성과 차원을 바꾸는 물리적 변환
    • Zip & Merge: 여러 흐름을 하나로 엮거나 융합하는 수리 연산
    • Marble Diagrams: 시간 축에 따른 데이터 흐름의 물리적 표현법
  • How to Learn:
    • 두 개의 API 응답을 기다렸다가 하나로 합쳐서 반환하는 로직을 마블 다이어그램으로 도식화 실습
    • 연산자(Operator) 중복 사용 시 발생하는 하드웨어 호출 스택 깊이 산출
  • Implement: 1초마다 숫자를 발행하여 짝수만 걸러내고 2배로 튀기는 리액티브 파이프라인

Practical

Core: 백프레셔와 흐름 제어 물리학 (Backpressure Control)

  • Why to Learn: 생산자가 날뛰어도 시스템 가용성이 무너지지 않게 물리적 방어선을 구축하기 위해서입니다.
  • What to Learn:
    • Request(n) Protocol: 소비자가 처리 가능한 만큼만 물리적으로 요청하는 기제
    • Buffer Strategies: 넘치는 데이터를 메모리에 잠시 보관하는 수리 모델
    • Drop/Latest Strategies: 처리가 늦어질 때 데이터를 과감히 버리는 물리 정책
  • How to Learn:
    • 10ms마다 데이터를 쏘고 1s마다 처리하는 환경에서 버퍼가 꽉 찼을 때 시스템의 CPU 사용률 변동 측정 실습
    • 백프레셔가 작동하여 생산자에게 전달되는 '부하 피드백'의 물리적 파장 분석
  • Implement: 소비자의 처리 속도에 맞춰 데이터를 건네주는 DynamicSubscriber

Advanced

Core: 비차단 분산 시스템과 스케줄링 (Reactive Architecture)

  • Why to Learn: 전 시스템 구간(DB, MQ, Web)을 리액티브로 연동하여 하드웨어 병목을 완전히 제거하기 위함입니다.
  • What to Learn:
    • R2DBC: 데이터베이스 I/O도 리액티브하게 처리하는 물리 프로토콜
    • Thread Context Switching: 리액티브 환경에서 스레드가 전환되는 하드웨어적 비용 산출
    • Error Propagation: 체인 전체에 비동기 에러를 물리 전파하고 복구하는 전략
  • How to Learn:
    • DB 커넥션 풀을 리액티브 방식으로 바꿨을 때 수용 가능한 동시 접속 수(ConcurrentUsersConcurrent Users) 증대 효과 측정 실습
    • 복잡한 리액티브 체인의 '메모리 덤프'를 분석하여 누수(Leak) 발생 지점 추적
  • Implement: 에러 발생 시 특정 횟수만큼 재시도하거나 대체 데이터를 내보내는 ResilientStream

7. Terminology

Term (EN / ko, abbr) 1문장 정의 단계(기본/권장/실무/심화) 역할/맥락 관련 개념 유사/대비/함께 사용 오해 포인트 Evidence(Primary/Secondary/Industry) Flags(core)
Reactive 데이터나 상태의 변경을 전파하고, 이에 민감하게 반응하여 동작하는 설계 사상입니다. 기본 응답성 향상 Stream / Async Proactive '단순 비동기' 아님 Industry core
Backpressure 데이터 수신자가 처리 가능한 양을 발신자에게 통지하여 데이터 전송 속도를 제어하는 물리 기작입니다. 실무 시스템 보호 Flow Control Buffer 큐(Queue)와 대조 Industry core
Flux / Mono 하나 이상의 데이터 흐름과 단일 데이터 결과를 각각 나타내는 리액티브 프로그래밍의 핵심 수리 모델입니다. 실무 데이터 타입 Stream / Scalar Observable Reactor 라이브러리 Industry core
Non-blocking 작업 완료를 기다리지 않고 제어권을 즉시 반환하여 다음 물리 연산을 수행할 수 있게 하는 성질입니다. 추천 하드웨어 활용 Async / I/O Blocking '정지 없음'의 극치 P1:CS2023 core

8. References

Primary

Secondary

  • [The Reactive Manifesto] Bonér, J. et al. — The foundational vision.
  • [Reactive Design Patterns] Roland Kuhn — Practical architectural patterns.

Industry

  • [Project Reactor: Reference Guide] — Java implementation standard.
  • [RxJS: Reactive Extensions for JavaScript] — Frontend reactive patterns.

9. Final Checklist

Primary

  • '리액티브 프로그래밍'이 왜 '전통적인 비동기(Callback, Future)'보다 복잡한 비동기 결합 상황에서 물리적으로 관리에 유리한지 설명 가능한가? (P1)
  • '비차단 I/O(Non-blocking)'가 하드웨어의 CPU 사용률(UtilizationUtilization)을 어떻게 극대화시키는지 기술할 수 있는 가? (P1)

Secondary

  • '백프레셔'를 지원하지 않는 스트림 라이브러리를 사용했을 때, 대규모 데이터 전송 상황에서 발생하는 하드웨어 재앙을 소통 가능한가?
  • 마블 다이어그램을 활용하여 특정 시점 발생한 에러가 후속 리액티브 체인에 미치는 물리적 파장을 입증할 수 있는 가?

Industry

  • 고부하 뱅킹 시스템 설계 시, '처리 속도 저하'가 상위 시스템으로 전파(PropagatePropagate)되는 것을 차단하기 위한 리액티브 전략을 제안할 수 있는 가? (SFIA)
  • 애플리케이션 내에 '블로킹 연산'이 섞여 있을 때, 이를 안전하게 리액티브 스트림과 물리 격리(IsolateIsolate)시키는 방법을 분석할 수 있는 가?