Imperative 프로그래밍과 Reactive 프로그래밍의 차이
Imperative programming means you are responsible for pulling an event off of a queue. Reactive programming means you register a callback and a framework is responsible for calling your callback correctly. In most non-JavaScript languages, imperative programming is the de facto standard.
Imperative Programming은 큐에서 이벤트를 꺼내올 책임이 당신에게 있다는 것을 의미한다. Reactive Programming은 당신이 콜백을 등록하고, 프레임워크가 당신의 콜백을 올바르게 불러와야 할 책임이 있다는 것을 의미합니다. 자바스크립트가 아닌 대부분의 언어들에서, Imperative Programming은 사실상의 표준입니다.
x = y + z라는 식을 이용해 알아보자. y = 10이고, z = 15라고 할 때, x = 25가 된다. x = y + z라는 표현식을 수행할 때 x의 값은 할당될 것이다. 또한, x의 값은 이 이후로 변하지 않는다.
전통적인 프로그래밍 세상에서는 이러한 방식이 많이 사용됐따. 하지만, y와 z의 값이 계속 변하는 상태에서 x의 값을 따라가려면 어떻게 해야 할까?
y = 20, z = 15일 때,x = 35y = 20, z = 25일 때,x = 45
앞의 시나리오는 일반적으로 우리가 일상에서 사용하는 Imperative Programming 에서는 불가능한 시나리오이다. 하지만, 가끔 x의 값이 업데이트될 필요가 있을 때도 있다. 그 때는 y나 z의 값 변화에 따라서 대응해야 할 필요가 있다.
엑셀의 참조 셀이 Reactive Programming 의 가장 대표적인 예이다. 하나의 셀의 값이 바뀌면 그 셀을 참조하는 나머지 셀의 값도 전부 업데이트된다. 이러한 방식은 Model-View-Controller 아키텍쳐에서도 발견되는데, 첨부된 Model 에 따라 View 를 업데이트하는 방식에서 볼 수 있다.
Reactive Programming 은 데이터의 스트림을 다루고 변화시키기 위한 옵저버 패턴과도 닮아있다. 발행자가 구독자의 필요를 기반으로 한 아이템을 발행하는 Pub-Sub 패턴도 바로 그것이다. 발행자가 아이템을 발행하고 구독자는 발행된 아이템을 소비한다. 반복자가 아이템을 끌어오는 것과는 다르게 여기서는 발행자가 구독자에게 아이템을 밀어준다.
Reactive 는 non-blocking 아키텍쳐의 한 부분으로, 우리가 어플리케이션을 스케일할 때 유용할 것이다. 또한, non-blocking 아키텍쳐에서는 모든 것이 이벤트 스트림으로 여겨진다.
Reactive Stream이란?
Reactive Stream 은 애플리케이션이 데이터 아이템을 받았을 때, 그 데이터 아이템에 반응하는 데이터 아이템의 비동기 스트림을 처리하는 것에 대한 기술이다. 메모리 내부 데이터에 의존하지 않는 만큼, 이 모델이 더 메모리 효율이 좋다.
Reactive Stream 에는 아래와 같은 4개의 메인 컨셉이 있다.
- Publisher
- Subscriber
- Subscription
- Processor
Publisher 는 구독한 구독자에게 비동기적으로 데이터의 스트림을 발행한다. Processor는 Publisher나 Subscriber의 변화 없이 데이터 스트림을 변형시킨다. Processor (혹은 Multi Processors)는 Publisher와 Subscriber의 사이에 위치하여 하나의 데이터 스트림을 다른 형태로 변화시킨다.
Reactive Programming의 장점
Reactive Stream 접근법은 Netflix, Pivotal, Twitter, Oracle, TypeSafe 등 유명 기업에서 일하는 엔지니어들에 의해 지지받는다. 넷플릭스 엔지니어는 다음과 같은 말을 했다고 한다.
RxJava를 이용한 Reactive Programming은 넷플릭스 개발자들이 일반적인 thread-safety와 동기화 문제에 시달리지 않고도 서버사이드 동시성 효율을 높여주었다.
대표적 장점은 아래와 같다.
- 비즈니스 로직에 더 집중할 수 있음
- 스트림 과정이 메모리 효율성을 높여줌
- 낮은 레벨의 스레딩, 동기화, 동시성 이슈를 극복할 수 있게 해줌
리액티브 원칙은 실시간 케이스들에 많이 사용된다. 이를테면 라이브 데이터베이스 쿼리, 빅 데이터, 실시간 분석, HTTP2와 같은 것들이다.
