2026년에 Angular 앱이 여전히 RxJS에 의존해야 할까?
Source: Dev.to
Angular는 반응성을 처리하는 방식에 있어 조용하지만 중요한 변화를 겪고 있습니다. Signals가 도입되면서 많은 개발자들이 간단한 질문을 던지고 있습니다:
2026년 현재 Angular 애플리케이션에서도 여전히 RxJS가 필요할까요?
짧은 답은 예 — 하지만 모든 곳에 필요한 것은 아닙니다.
진짜 답은 더 흥미로운데, 이는 선호도가 아니라 아키텍처에 관한 이야기입니다.
논의를 이해하려면 두 가지 근본적으로 다른 반응성 모델을 구분하는 것이 도움이 됩니다.
RxJS는 다음을 중심으로 합니다
- 이벤트 스트림
- 비동기 조합
- 시간 기반 연산
다음과 같은 경우에 강점을 발휘합니다
- HTTP 요청
- WebSocket
- 복잡한 비동기 워크플로우
- 이벤트 오케스트레이션
RxJS는 시간과 이벤트에 관한 것입니다.
Signals는 다른 개념을 나타냅니다
- 동기식 반응성
- 로컬 상태 추적
- 명시적 의존성
다음에 가장 적합합니다
- UI 상태
- 파생 상태
- 컴포넌트 수준 반응성
Signals는 상태와 UI 일관성에 관한 것입니다.
import { signal, computed } from '@angular/core';
const count = signal(0);
const doubled = computed(() => count() * 2);
function increment() {
count.set(count() + 1);
}Signals는 상태와 의존성을 명시적으로 드러냅니다. 구독도 없고, 숨겨진 연결도 없습니다.
import { BehaviorSubject, map } from 'rxjs';
const count$ = new BehaviorSubject(0);
const doubled$ = count$.pipe(
map(value => value * 2)
);
function increment() {
count$.next(count$.value + 1);
}RxJS는 모든 것이 Observable을 통해 흐르는 스트림 기반 모델을 도입합니다.
현대 Angular 애플리케이션에서 가장 큰 아키텍처 문제는 RxJS와 Signals 중 하나를 선택하는 것이 아니라, 명확한 경계 없이 두 가지를 섞어 쓰는 것입니다.
두 모델을 어디든지 섞어 쓰면
- 상태가 중복되고
- 로직이 흩어지며
- “진실의 원천”(source of truth)이 어디에 있는지 불분명해집니다.
2026년에도 RxJS가 여전히 필수적인 경우
- HTTP 요청 파이프라인
- 취소 및 재시도 로직
- 실시간 데이터 스트림
- 여러 비동기 소스의 조정
문제가 시간, 동시성, 이벤트 조합과 관련된다면 RxJS가 여전히 더 좋은 추상화입니다.
Signals가 더 적합한 경우
- 로컬하고 상태 중심적인 문제
- 컴포넌트 상태
- 파생 UI 값
- 폼 상태
- 간단한 반응형 바인딩
Signals는 불필요한 복잡성을 줄이고 데이터 흐름을 보다 명시적으로 만들어 줍니다.
간단한 규칙
- RxJS는 외부 세계를 다룹니다. → 통합 레이어
- Signals는 프레젠테이션 레이어를 담당합니다.
이 경계를 지키면 Angular 애플리케이션은 유지보수가 크게 쉬워집니다.
2026년, RxJS는 Angular에서 구식이 아닙니다 — 단지 유일한 반응성 모델이 아니라는 점만 기억하면 됩니다. Signals는 개발자가 반응형 파워를 포기하지 않으면서 UI 로직을 단순화할 수 있게 해 주는 두 번째 레이어를 제공합니다.
가장 좋은 Angular 애플리케이션은 어느 하나를 선택하는 것이 아니라, 각각을 언제 사용할지 명확히 정의한 애플리케이션입니다.
아키텍처는 도구에 관한 것이 아니라 경계에 관한 것입니다.