RxJS 정리 — 비동기 스트림과 리액티브 프로그래밍

비동기 프로그래밍 패러다임의 진화와 리액티브 프로그래밍의 부상

현대 웹 애플리케이션 아키텍쳐에서 비동기 데이터 처리의 효율성은 시스템의 전체 성능과 사용자 경험을 결정짓는 핵심 지표로 작용합니다.

자바스크립트는 본질적으로 단일 스레드 기반의 이벤트 루프 모델을 채택하고 있으며, 이는 필연적으로 수많은 비동기 작업의 병렬적 관리라는 과제를 동반합니다.

과거의 자바스크립트 개발 환경에서는 이러한 비동기 흐름을 제어하기 위해 콜백함수를 사용했으나, 이는 로직의 복잡도가 증가함에 따라 가독성과 유지보수성을 심각하게 저해하는 콜백 지옥 문제를 야기했습니다.

이후 도입된 Promise는 비동기 작업의 상태를 객체화하여 체이닝을 가능하게 함으로써 일정한 진보를 이루었으나, 단일 값만을 처리할 수 있다는 한계로 인해 지속적으로 발생하는 데이터 스트림을 다루기에는 역부족이었습니다.

** Promise가 단일 값만을 처리할 수 있다는 말은, 프로미스 객체 하나가 생성되어 작업이 완료되면 딱 한번만 결과(성공 또는 실패)를 반환하고 그 생명주기가 끝난다는 뜻입니다.

이러한 맥락에서 등장한 리액티브 프로그래밍(Reactive Programming)은 데이터를 정적인 상태가 아닌 시간의 흐름에 따라 발생하는 이벤트의 연속으로 파악합니다.

RxJS(Reactive Extensions for JavaScript)는 이러한 리액티브 프로그래밍 패러다임을 자바스크립트 환경에서 구현하기 위한 핵심 라이브러리로, 비동기 데이터 스트림을 옵저버블(Observable)이라는 단일한 인터페이스로 추상화하여 제공합니다.

이는 단순히 비동기 처리를 돕는 도구를 넘어, 애플리케이션이 외부 자극에 어떻게 반응할 것인가를 선언적으로 기술하는 설계 철학의 변화를 의미합니다.

RxJS의 핵심 설계 원리와 리액티브 매니페스토의 실현

RxJS의 작동원리는 크게 네 가지 핵심 원칙으로 요약될 수 있으며, 이는 리액티브 시스템이 갖추어야 할 유연성과 견고함을 뒷받침합니다.

1. 첫째, 비동기 데이터 스트림(Asynchronous Data Streams)의 원칙입니다. 리액티브 프로그래밍에서 모든 것은 스트림이 될 수 있습니다.

   사용자의 클릭 한 번부터 서버에서 실시간으로 전송되는 주식 시세 데이터에 이르기까지, 모든 데이터는 시간에 따라 흐르는 파이프라인을 통해 전달됩니다.

   RxJS는 이러한 다양한 소스를 옵저버블로 변환하여 동일한 방식으로 처리할 수 있는 일관성을 부여합니다.

2. 둘째, 변화의 전파(Propagation of Change) 원칙입니다. 이는 데이터 소스에서 변화가 발생했을 때, 해당 데이터를 구독하고 있는 모든 소비자에게 그 변화가 자동으로 전달되는 메커니즘을 의미합니다.

   개발자가 수동으로 상태를 확인하고 화면을 갱신하는 명령형 방식과 달리, 리액티브 방식에서는 데이터의 흐름에 따라 하부 시스템이 스스로 반응하여 업데이트를 수행합니다.

3. 셋째, 옵저버블의 합성(Composition) 원칙입니다. RxJS는 수많은 연산자(Operators)를 제공하여 복잡한 비동기 로직을 작은 단위의 순수 함수들로 조합할 수 있게 합니다.

   이는 함수형 프로그래밍의 이점을 비동기 영역으로 확장한 것으로, 데이터 스트림을 필터링하고, 변형하며, 다른 스트림과 결합하는 과정을 마치 레고 블록을 쌓는 것처럼 선언적으로 작성할 수 있게 합니다.

4. 넷째, 시간과 공간의 디커플링(Time and Space Decoupling) 원칙입니다. 데이터의 생산자와 소비자는 서로의 위치나 정확한 동작 시점을 알 필요가 없습니다.

   생산자는 데이터를 발행할 뿐이며, 소비자는 자신이 필요할 때 스트림을 구독하여 데이터를 처리합니다. 이러한 느슨한 결합은 시스템의 확장성을 높이고 독립적인 컴포넌트 개발을 가능하게 합니다.

   아래 표는 기존의 명령형 프로그래밍과 RxJS가 지향하는 리액티브 프로그래밍의 특성을 대조해서 보여줍니다.

이벤트 스트림의 본질적 의미와 범위 분석

RxJS를 이해하는 데 있어 가장 중요한 개념 중 하나인 ‘이벤트 스트림(Event Stream)’은 시스템에서 발생하는 모든 동적인 변화를 추상화한 개념적 파이프라인을 의미합니다. API 요청인가 혹은 UI 이벤트인가에 대한 질문에 둘 다 해당하며, 그 이상을 포함한다고 할 수 있습니다.

• 사용자 인터페이스(UI) 이벤트로서의 스트림

  브라우저 환경에서 발생하는 모든 사용자 상호작용은 본질적으로 스트림의 성격을 띱니다. 사용자가 페이지를 스크롤하는 행위는 수많은 좌표 데이터의 연속적인 발생이며, 키보드 입력은 시간차를 두고 발생하는 문자들의 나열입니다.

  RxJS의 fromEvent 함수는 이러한 DOM 이벤트를 옵저버블 스트림으로 변환하는 창구 역할을 합니다.

  예를 들어, 단순한 버튼 클릭조차도 단발성 이벤트가 아닌, ‘무한히 지속될 수 있는 클릭들의 스트림’으로 간주될 때, 더 정교한 시간 기반 제어(ex. 더블 클릭 감지, 클릭 간격 제한)이 가능해집니다.

• 네트워크 통신 및 API로서의 스트림

  네트워크 요청 역시 스트림 모델로 완벽하게 통합됩니다. 전통적인 HTTP 요청은 요청과 응답이라는 단일 쌍으로 구성되지만, RxJS는 이를 ‘단 하나의 값이 발행되고 종료되는 스트림’으로 취급합니다.

  이는 단일 값 응답(REST API)과 지속적인 데이터 흐름(WebSockets, SSE)을 동일한 연산자로 처리할 수 있게 하는 강력한 추상화를 제공합니다.

  특히 마이크로서비스 아키텍처나 실시간 데이터 대시보드에서 여러 API 응답을 조합하거나 에러 발생시 재시도(Retry)를 수행하는 로직은 스트림 관점에서 처리할 때 가장 효율적입니다.

• 추상적 데이터 소스의 스트림화

  이벤트 스트림은 물리적인 클릭이나 네트워크 패킷에 국한되지 않습니다. 애플리케이션 내부의 상태 변화, 타이머의 틱(Tick), 배열 내 정적인 요소들조차도 스트림으로 변환될 수 있습니다.

  이는 시스템의 서로 다른 부분에서 발생하는 비동기적 사건들을 ‘옵저버블’이라는 공용어로 통일함으로써, 데이터의 출처에 상관없이 일관된 로직을 적용할 수 있게 합니다.

On-Demand 개념의 다각적 해석: 실행 모델과 기술 환경

“On-Demand(주문형)”라는 용어는 RxJS의 실행 메커니즘과 현대 네트워크 API 기술이라는 두 가지 측면에서 깊이 있게 논의될 필요가 있습니다.

** 온디맨드(On-Demand)는 “수요가 있을 때(요청 시) 비로소 자원을 할당하거나 로직을 실행하는 방식”을 통칭하는 개념입니다.

• RxJS의 지연평가(Lazy Evaluation)과 On-Demand 실행

  프로그래밍적 관점에서 RxJS의 옵저버블은 대표적인 “On-Demand” 시스템입니다. 이는 옵저버블이 게으른(Lazy) 특성을 갖기 때문입니다.

  옵저버블은 정의된 시점에서는 아무런 실행도 하지 않으며, 누군가 이를 구독(Subscribe)하는 순간(즉, 데이터가 필요하다고 주문하는 순간)에 비로소 데이터를 생산하거나 비동기 작업을 시작합니다.

  이러한 특성을 가장 잘 보여주는 것이 ‘Cold Observable’입니다. 이는 주문형 비디오 서비스(VOD)인 넷플릭스와 유사합니다. 각 시청자가 재생버튼을 누를 때마다 영화가 처음부터 시작되듯이, Cold Observable은 구독자가 생길 때마다 독립적인 실행을 시작하여 데이터를 전달합니다.

  반면 Hot Observable은 라이브 라디오 방송과 같아서 구독 여부와 관계없이 데이터가 흐르고 있으며, 구독자는 자신이 합류한 시점부터의 데이터만을 수신합니다.

자바스크립트 개발자를 위한 RxJS 도입의 필요성 및 가치제안

순수 자바스크립트(Vanilla JS)에 익숙한 개발자들에게 RxJS의 도입은 초기 학습 비용이라는 장벽을 동반합니다. 하지만 애플리케이션의 비동기 복잡도가 일정 수준을 넘어서는 순간, RxJS가 제공하는 가치는 그 비용을 상회합니다.

• 상태 오염 방지와 부수 효과(Side-Effects)의 최소화

  명령형 자바스크립트 코드의 가장 큰 고충 중 하나는 비동기 작업 도중 상태를 관리하기 위해 사용하는 공유 변수들 입니다.

  비동기 콜백 내부에서 외부 변수를 수정하는 행위는 예기치 못한 부수 효과를 낳고, 디버깅을 어렵게 만듭니다.

  RxJS는 데이터 흐름을 파이프라인 안에 격리하고, scan과 같은 연산자를 통해 상태를 순수 함수적 방식으로 관리하게 함으로써 코드의 예측 가능성을 획기적으로 높입니다.

• 비동기 로직의 선언적 기술과 가독성 향상

  명령형 방식이 ‘어떻게(How)’ 비동기 작업을 수행할지에 집중한다면, RxJS는 ‘무엇을(What)’ 할지에 집중합니다.

  사용자가 입력하고, 0.3초를 기다리고, 이전 요청을 취소하고, 새 데이터를 가져오는 일련의 과정을 RxJS는 각 단계를 연산자로 정의하여 선언적으로 표현합니다.

  이는 복잡한 비동기 워크플로우를 한눈에 파악할 수 있게 하며, 비즈니스 로직과 제어 로직을 명확히 분리합니다.

• 자원 정리 및 메모리 관리의 단순화

  자바스크립트 개발자는 이벤트 리스너를 등록한 후 이를 적절한 시점에 제거(removeEventListener)하는일을 자주 잊어버리곤 합니다. 이는 특히 페이지 전환이 잦은 단일 페이지 애플리케이션(SPA)에서 메모리 누수의 원인이 됩니다.

  RxJS의 구독(Subscription) 모델은 모든 비동기 소스를 단일한 구독 객체로 관리하며, unsubscribe 한번으로 내부 리스너와 타이머 등 모든 자원을 일괄 정리할 수 있는 매커니즘을 제공합니다.

Vanilla JS와 RxJS의 비교분석: 실전 코드를 통한 심층 고찰

실제 개발 현장에서 빈번하게 발생하는 시나리오를 통해 두 방식의 차이를 정밀하게 비교분석합니다.

• 시나리오 1: 사용자 입력에 따른 실시간 검색(Debounce & Race Condition)

  사용자가 검색어를 입력할 때마다 서버 API를 호출하는 기능을 구현한다고 가정합니다. 네트워크 비용을 줄이기 위해 사용자가 타자를 멈춘 후 0.5초가 지났을 때만 요청을 보내야 하며(Debounce), 만약 이전 요청이 완료되기 전에 새로운 요청이 발생하면 이전 응답은 무시해야 합니다.(Race Condition 해결)

  Vanilla 자바스크립트 구현의 문제점

  순수 자바스크립트에서는 setTimeout과 clear Timeout을 수동으로 관리해야하며, 요청 취소를 위해 AbortController를 도입해야 합니다. 이 과정에서 전역 변수나 상위 스코프의 변수가 오염되기 쉽습니다.

  let timer
  let abortController
  
  const searchInput = document.getElementById("search")
  
  searchInput.addEventListener("input", e => {
    // 1. 기존 타이머 제거(Debounce 로직)
    if (timer) clearTimeout(timer)
  
    // 2. 0.5초 대기 후 실행
    timer = setTimeout(async () => {
      // 3. 이전 네트워크 요청 취소(Race Condition 해결)
      if (abortController) abortController.abort()
      abortController = new AbortController()
  
      try {
        const response = await fetch(`/api/search?q=${e.target.value}`, {
          signal: abortController.signal,
        })
        const data = await response.json()
        updateUI(data)
      } catch (error) {
        if (error.name === "AbortError") return // 취소된 요청은 무시
        handleError(error)
      }
    }, 500)
  })
  

  위 코드는 기능적으로는 작동하지만, 상태를 관리하기 위한 변수들이 외부에 노출되어 있고, 로직의 흐름이 명령형으로 파편화되어 있어 유지보수가 어렵습니다.

  RxJS를 이용한 선언적 구현

  RxJS는 파이프라인 연산자를 통해 이 모든 요구사항을 우아하게 처리합니다.

  import { fromEvent, debounceTime, map, switchMap, catchError, of } from "rxjs"
  
  fromEvent(document.getElementById("search"), input)
    .pipe(
      map(event => event.target.value),
      debounceTime(500),
      switchMap(query =>
        fetchAsObservable(query).pipe(catchError(err => of())),
      ),
    )
    .subscribe(data => updateUI(data))
  

  switchMap 연산자는 새로운 값이 들어오면 이전의 내부 옵저버블 구독을 자동으로 해지하고, 새로운 구독을 시작합니다. 이는 AbortController를 수동으로 제어하는 복잡성을 내부적으로 추상화하여 제거합니다.

RxJS 도입의 전략적 판단 기준: 언제 써야 하는가?

RxJS는 강력한 도구이지만 만능은 아닙니다. 프로젝트의 성격과 요구사항에 따라 적절한 도구 선택이 필요합니다. RxJS가 필수적인 최적의 상황 세 가지는 아래와 같습니다.

• 첫째, 복잡한 비동기 워크플로우를 가진 애플리케이션입니다. 여러개의 API가 서로의 결과에 의존하여 호출되어야 하거나, 병렬로 실행된 작업들이 모두 완료된 후 특정 로직을 수행해야 하는 경우 RxJS의 결합 연산자(mergeMap, concatMap, forkJoin, combineLatest)는 필수적입니다.
• 둘째, 실시간성 데이터 처리가 핵심인 서비스입니다. 금융 거래 시스템, 실시간 대시보드, 멀티플레이어 게임, 협업 편집 툴과 같이 데이터가 푸시 방식으로 끊임없이 전달되는 환경에서는 스트림 아키텍쳐가 가장 자연스러운 해결책입니다.
• 셋째, 고도의 사용자 인터페이스 상호작용이 필요한 경우입니다. 드래그 앤 드롭, 정교한 제스처 인식, 복합적인 키보드 단축키 관리 등은 수많은 이벤트를 조합하고 필터링해야 하므로 RxJS를 통해 훨씬 쉽고 안정적으로 구현할 수 있습니다

자바스크립트 표준(Promise/Async-await)이 유리한 상황

단순히 서버에서 데이터를 한 번 가져와서 보여주는 전형적인 CRUD 애플리케이션이나 소규모 프로젝트에서는 RxJS의 도입이 과도한 설계(Over-engineering)가 될 수 있습니다.

async/await은 선형적인 비동기 흐름을 이해하기 쉽게 표현해주며, 추가적인 라이브러리 설치 없이 자바스크립트 엔진에서 네이티브하게 지원된다는 강력한 장점이 있습니다.