리액티브 개발 패러다임에 담긴 메시지

10월에도 무더운 여름 날씨가 이어지는 텍사스 오스틴에 다녀왔다. 리액티브 정상회담(Reactive Summit)이라는 거창한 이름의 컨퍼런스에 참가하기 위해서다. 이름과 달리 티켓을 구매하는 사람은 누구나 참여할 수 있는 일반적인 행사다. 스칼라, 아카, 스파크 등을 지원하는 회사인 라이트밴드(LightBend)에서 조직하고 다양한 회사가 후원을 해서 성공적인 행사가 되었다.

리액티브라는 말은 프로그래밍 업계에서 수년 전부터 회자되어 왔다. reactive는 원래 외부 자극에 수동적으로 반응한다는 의미라서 부정적인 뉘앙스가 있었는데 프로그래밍 업계에 수용되면서 현대적 소프트웨어가 갖추어야 하는 바람직한 속성으로 의미가 달라졌다.

그렇지만 리액티브라는 말은 문맥에 따라 다른 의미로 사용되기 때문에 정확히 무엇을 의미하는지 알기 어렵다. 혼란스럽다. 프로그래밍 업계에서 의미를 획득하는 용어는 대개 비슷한 과정을 밟는다. 빅데이터, 클라우드, 마이크로서비스, 함수형 패러다임, 모바일, 머신러닝, nosql과 같이 의미가 확실해진 용어들조차 최종적인 의미를 획득하기 위한 여정을 끝마치지 않은 상태다.

리액티브라는 말의 정의는 사실 간단하다. 사용자가 해당 소프트웨어를 사용하기 위해서 어떤 입력을 발생 시켰을 때 꾸물거리지 않고 최대한 빠른 시간 내에 응답을 한다는 의미다. 너무나 상식적인 이야기라서 오히려 이해하기 어렵다. 리액티브라는 용어의 의미를 정의하려고 노력하는 리액티브 선언(http://www.reactivemanifesto.org/)에 따르면 리액티브는 4가지 속성으로 이루어진다. 응답성(responsive), 유연성(resilient), 신축성(elastic), 그리고 메시지 주도(message driven)가 그들이다.

소스코드.

■리액티브의 4가지 속성

응답성은 '꾸물거리지 않고 응답한다'는 뜻으로 4가지 속성 중에서 가장 상위에 놓이는 궁극적 목적이다. 소프트웨어가 존재하는 이유는 사용자의 요청에 응답하기 위해서라고 해도 무방하다. 소프트웨어는 응답한다. 고로 존재한다. 이렇게 말할 수도 있다. 나머지 세 개의 속성은 응답성을 위해서 존재하는 하위 속성이다.

유연성은 흔히 말하는 장애허용(fault tolerance)의 다른 말이다. 장애를 허용한다는 것은 부분적인 장애나 고장이 시스템 전체를 망가뜨리지 않음을 뜻한다. 소프트웨어 스스로 고장을 감지하고, 수정하고, 처리한다는 의미를 포함한다. 소프트웨어나 서비스를 10대의 서버가 아니라 100대, 1,000대, 혹은 10,000대의 서버에 배포하는 현대 시스템에서 시스템의 일부가 다운되거나 고장 나는 것은 예외적인 현상이 아니라 평범한 동작의 일부다. 즉, 고장은 소프트웨어의 정상적인 기능의 일부다. 유연성은 고장을 예외가 아니라 기능으로 받아들인다.

신축성은 트래픽이 늘어나면 서버의 수가 자동으로 늘어나고 트래픽이 줄어들면 서버의 수가 자동으로 줄어드는 모습을 상상하면 된다. AWS를 사용한다면 오토스케일 같은 기능을 생각해도 좋다. 리액티브 선언의 초기 버전에서는 elastic이라는 말 대신 scaleable이라는 말을 썼는데, scaleable은(코어의 수가 늘어나는 스케일-업을 포함하여) 서버의 수가 늘어나는 스케일-아웃(scale-out)을 의미하지만 elastic은 서버의 수가 늘어나는 스케일-아웃과 서버의 수가 줄어드는 스케일-인을 동시에 의미하기 때문에 최근 버전에서 일래스틱(elasitc)이라는 말로 표현이 바뀌었다.

메시지 주도는 상대적으로 의미가 확실하다. 소프트웨어를 구성하는 조각과 조각이 의사소통을 하는 방식이 메시지를 주고받는 방식으로 이루어진다는 의미다. 여기에서 조각은 컴포넌트, 서비스, 객체, API, 무엇이라도 될 수 있다. 그들은 과거와 같이 (혹은 현재와 같이) 메서드 호출이나 RPC 같은 블로킹 방식으로 의사소통하지 않고, 보내고 잊는(fire-and-forget) 방식으로 메시지를 주고받으며 소통한다. 객체지향 패러다임의 아버지인 앨런 케이(Alan Kay)가 상상했던 객체들이 의사소통하는 방식은 원래 이렇게 메시지를 중심으로 삼는 방식이었다.

■리액티브 스트림스 표준

티벳 승려가 눈을 감고 외우는 주문처럼 갈피를 잡기 어려운 응답성, 유연성, 신축성, 메시지 주도라는 4개의 추상적인 속성은 구체적인 비트와 바이트를 통해 피와 살을 얻으며 육화된다. 라이트밴드의 전신인 타입세이프, 레드햇, 넷플릭스, 스프링 프레임워크를 지원하는 회사인 피보탈(Pivotal), 그리고 오라클 등이 모여서 합의한 리액티브 스트림스 1.0 표준은 자바가상기계 위해서 구현되는 리액티브 스트림 라이브러리에 표준을 정의하려는 노력이다.

10년 전부터 마이크로소프트 연구센터에서 에릭 마이어 등이 중심이 되어 주창한 리액티브 익스텐션(reactive extension), 즉 RX는 현대 프로그래밍 모델을 비동기적이고, 이벤트 중심인 데이터 구조, 즉 Observable을 통해서 재정의하려는 노력이었다. 닷넷 진영에서 활발하게 논의되고 구현되던 RX를 넷플릭스의 벤 크리스텐슨(Ben Christensen)이 JVM 진영으로 가져온 것이 RxJava다. RxJava 라이브러리가 주목을 끌면서 자바진영에서도 스트림에 대한 관심이 높아졌는데, 데이터를 거대한 크기의 완결된 대상으로 보는 대신 계속 입력되는 작은 데이터 조각의 연속, 즉 스트림으로 보는 방식은 RX에 의해서 현대적 의미를 획득했다. 스트림에서는 비동기성, 이벤트, 그리고 역압(back pressure)이 핵심적인 개념이다.

■리액티브 익스탠션, FRP, 그리고 리액트

리액티브 스트림스 표준은 마이크로소프트의 RX에서 시작된 스트림 API의 백가쟁명에 통합된 표준을 도입하려는 노력이며, 이면의 철학적 바탕에는 리액티브 선언의 4가지 속성이 맞닿아 있다. 아카 스트림, 몽고 DB, 래빗MQ, RxJava, 슬릭, Vert.x 등이 이미 표준을 따르고 있고, 점차 많은 라이브러리가 표준에 참여하고 있다. 함수형 리액티브 프로그래밍(Functional Reactive Programming - FRP)이라는 표현도 자주 사용되는데, 이것은 맵(map), 리듀스(reduce), 필터(filter)와 같은 함수형 빌딩블록을 이용해서 스트림을 처리하는 프로그래밍 방법론을 일컫는 것으로 1997년에 처음 도입된 이래 자기만의 고유한 역사를 가지고 있는 별도의 개념이다. 즉, 리액티브와 FRP는 닮았지만 동일한 개념이 아니다.

자바스크립트 커뮤니티에서 많이 사용하는 리액트(React.js)의 경우, 리액트가 직접적으로 리액티브와 관련이 없는 것은 자바 언어가 자바스크립트와 직접 관련이 없는 것과 마찬가지다. 즉 이름만 비슷할 뿐이다. 물론, 리액트 라이브러리를 이용해서 리액티브 패러다임에 부합하는 프로그래밍을 하는 것은 어느 정도 가능하다. 하지만 그렇다고 해서 리액트와 리액티브가 동일하거나 비슷한 것은 아니다.

오스틴에서 열린 컨퍼런스에서는 이런 리액티브 현상을 구체화 하기 위해서 아파치 스파크, 플린트(Flint), 카프카, Vert.x, 아카 스트림 등을 활발하게 논의했다. 특히 카프카 스트림 라이브러리가 집중적인 조명을 받았다. 마이크로서비스 아키텍처에 대한 재해석, 분산컴퓨팅 환경에서 테스팅이 갖는 의미와 방법론 등도 심도 있게 다루어졌다. 리액티브를 둘러싼 이야기가 너무 복잡하게 전개되고 있어서, 이해를 돕기 위해 칼럼을 썼지만 읽다가 더 혼란을 느낀 독자가 있을지도 모르겠다. 그런 사람은 스트레스 받지 말고 "하늘 아래 새로운 것은 없다"는 말을 기억하기 바란다.

리액티브든 스트림이든 새로울 것은 없다. 둘 다 오래 전부터 존재해온 개념이며 다만 현대적 프로그래밍 환경에서 재해석이 이루어지고 있는 것일 뿐이다. 그래서 복잡하게 들린다. 여러분이 이미 꾸물거리지 않고 응답하는 소프트웨어를 작성하고 있다면, 리액티브라는 추상적인 말은 번거로울 뿐이다. 말은 시니피앙(記表)이며 소프트웨어가 시니피에(記意)다. 말보다 중요한 것은 여러분이 작성하는 코드다.

*본 칼럼 내용은 본지 편집방향과 다를 수 있습니다.