NDC Replay

Rx와 Functional Reactive Programming으로 고성능 서버 어플리케이션 만들기
김종욱
엔씨소프트
엔씨소프트 리니지이터널 개발실에서 플랫폼 서버 개발 담당중
최근 서버 개발에는 비동기 처리를 통해 성능을 향상시키면서도 깔끔한 프로그램을 만들기 위한 다양한 패러다임이 도입되고 있습니다. 이 세션에서는 비동기 서버 프로그램의 원리와 구조를 설명하는 것으로 시작하여 이것을 위해 Functional Reactive Programming이라는 새로운 패러다임을 소개하고, 이 패러다임을 적극 활용한 라이브러리 Rx (Reactive Extensions)를 사용하여 비동기 어플리케이션을 만들 수 있는 방법을 리니지 이터널 플랫폼의 적용 사례와 함께 설명할 예정입니다. 또한 C#, Java, Scala, Groovy, Clojure, Javascript 등 Rx 의 다양한 언어 바인딩을 함께 소개하여 모든 개발자들에게 친숙하게 다가가고자 합니다.
[새 창에서 슬라이드 보기]
안녕하세요. 저는 이런 제목으로 발표를 하게 된 김종욱이라고 합니다. 소개 슬라이드인데요. 학교에서 공부한 것들은 Engineering, science, music 이런 거였고, NC 소프트에서 2012년부터 지금까지 LE 개발실 플랫폼 팀에서 전문 연구요원으로 재직하고 있습니다. 다른 분들은 되게 화려한 경력을 써주셨는데 제 직장 경력은 이게 전부이고, 저 주소에서 저에 대한 뒷조사나 이 슬라이드를 확인하실 수 있습니다. 워드 클라우드가 한 물 가긴 했지만 한번 만들어 봤어요. 제 발표에서 나오는 단어들로 그려봤는데, 이중에서 Functional, Reactive, Programming. FRP라고 하는 것이 제 발표의 주제가 되는 패러다임이고요. 그래서 발표는 라이브러리를 소개하고, API를 소개한다는 것 보다 이 패러다임이 왜 생겼는지에 대해서 더 집중을 할 것 같습니다. 왼쪽에 있는 사진은 bitcoin miner하는 USB에요. 이게 소비 전력이 0.5W인데, 이게 웬만한 고성능 컴퓨터만큼의 속도로 비트코인을 캐낼 수가 있고요. 오른쪽에 있는 사진은 구글의 데이터 센터 사진입니다. 이 두 가지의 공통점이 있는데, 발표를 들으시면 알게 될 것 같아요. 가장 첫 순서인 ‘다시 만난 세계’에서는 프로그래밍 언어를 처음 배울 때로 돌아가서, 그때부터 무슨 일이 일어났는지 다시 훑어보려고 해요. 수학 시간에는 이런 함수를 배운 것이 기억나실 거에요. 왼쪽에 있는 정의역에서 오른쪽에 있는 공역으로 화살표를 보내는 거였고, 여기에는 시간 같은 개념이 들어가지는 않았죠. 그런데 요즘 맨날 쓰는 함수는 이런 식으로 생겼어요. 시간에 따라서 컴퓨터가 명령어를 하나씩 읽어서 처리하는. 그 시간의 개념이 왜 생겼냐가 이번 패러다임의 첫 원인이 됩니다. 수학 시간에 배운 함수들은 이렇게 f를 제공하고 g를 제공하는 형식으로 합성함수를 만들 수가 있죠. 합성 함수를 기호로 동그라미로 표현하기도 했었고요. 그런데 프로그래밍에서는 합성함수를 x의 값이 이미 정해져 있는 상황에서 먼저 y를 계산하고, 그 다음에 z를 계산하고. 하나씩 이렇게 해야 했습니다. 만약에 수학 시간에 배웠던 걸로만 생각하면 이렇게 생각할 수도 있을 것 같아요. 저 회색 화살표를 따라서 데이트가 흐르고 있고, f랑 g로 표시된 박스가 자기한테 들어오는 데이터를 알아서 표시하는 거죠. 그러면 거기에 a, b, c 가 들어가면 알아서 ㄱ, ,ㄴ, ㄷ 이 나오는 그런 합성함수가 만들어질 수 있었을 텐데, 만약에 그렇게 하면 그 두 박스를 하나로 묶어서 추상화 하는 게 당연하게 되겠죠? 마찬가지 방법을 어떤 규모의, 어떤 많은 네모들이 모여서 데이터를 보내면서 각자 독립적인 연산을 하는 것도 추상화를 하는 게 가능합니다. 사실상 이 네모 박스 안에 모든 데이터의 흐름이 포함될 수 있어요. 그래서 이 두 가지의 사진이 네모 박스 안에 있는 데이터의 흐름으로 표시된다고 볼 수 있을 것 같습니다. 왼쪽에 있는 usb miner의 경우에는 전자회로를 통해서 신호가 흐르고 있고, 오른쪽에서는 수 많은 서버들 사이에서 데이터가 흐르고 있고요. 왜 우리는 데이터의 흐름으로 프로그램을 짜지 않고 컨트롤의 흐름으로 프로그램을 짜게 됐을까요? 이 슬라이드는 1973년이라고 적혀있긴 하지만 작년에 발표가 있었던 ‘THE PUTURE OF PROGRAMMING’ 이라는 발표인데, 여기서 이 아저씨가 1973년 기준으로 40년 후의 프로그래밍은 어떨까? 라고 예측을 하고 있습니다. 1973년에 나왔던 ACTOR MODEL은 아까 봤던 것처럼 저기 나와있는 동그라미 하나하나가 독립적으로 메시지를 처리하는 거고요. 오른쪽에 있는 GPU처럼 생긴 그런 것도 일맥상통하는 독립적인 작은 프로세서와 그 사이에서 흐르는 데이터들로 이루어져 있죠. 그래서 data flow와 control flow의 싸움에서 data flow가 지고 말았습니다. 첫 번째 원인이라고 하면 역사적으로는 튜링머신 때문이었을 거에요. 저기 이상한 기계로 나와있는 튜링머신이 페이퍼에 있는 명령어들을 순차적으로 하나씩 진행을 하게 되고, 튜링 머신 자체가 컨트롤이라고 볼 수도 있을 텐데, 좀더 직접적인 원인은 어떤 한 회사에 있습니다. 그 회사 상표가 이렇게 생겼고요. 그 회사에서 70년대 초반부터 쭉 만들어낸 CPU를 보면, 이런 식으로 트랜지스터의 수는 올라가고 있지만, 대략 10년 전부터 성능이나 클럭 스피드가 멈춰있죠. 물리적인 한계 때문인 것도 여러분들이 다 아실 텐데요. 그래서 프로세스 하나로 하는 것들은 한계에 도달하게 되었습니다. 프로세스 하나의 성능은 80년에는 빠르게 발전하고 있었지만 지금은 한계에 도달했고. 컴파일러의 성능과 효율은 당시에는 명령형 언어들만을 효율적으로 컴파일 할 수 있었지만, 지금은 복잡한 패러다임을 사용하는 언어도 감동적으로 처리할 수 있고요. 병렬/분산 프로그래밍에 대한 이론과 실무적 지식 같은 것도 당시에는 아무도 모르는 상황이었지만 지금은 여러 도구가 나와있고, 여러 교육과정이 나와있는 상황이고요. 컴퓨터 한대도 비싸던 와중에 병렬 컴퓨터를 도입할 수 없었던 시절이지만 지금은 핸드폰에도 코어 8개가 들어있는 이상한 세상이죠. 그래서 지금은 다시 data flow에 눈을 돌릴 시간입니다. Data flow 프로그래밍의 일종이라고 할 수 있는, 그 카테고리 안에 들어있는 Reactive Programming에 대해서 얘기를 해보려고 해요. 아주 간단한 코드로서 A에 3을 넣고, B에 4를 넣고, C에 A+B라고 하면, C는 7이 되겠죠? 그 다음에 A에 4를 넣고, B에 5를 넣으면, 우리는 당연히 7이 출력될 것이란 걸 알고 있습니다. 하지만 얘는 다르죠. 처음에는 C에 7이 뜨지만 3, 4를 수정하는 순간 C의 값은 알아서 바뀌게 됩니다. 이거는 엑셀이 data flow 프로그래밍이라는 패러다임에 기반해서 각 셀이 독립적인 프로세서가 되고, 그것들 사이에서 데이터가 흐르고 있기 때문에이에요. 그러니까 C=A+B 라고 하면, 단순히 컨트롤이 명령어를 읽어서 결과 값을 얻어낸 게 아니라, A와 B에서 데이터가 흘러 들어와서, + 라는 프로세스를 통해서 C로 데이터가 흐른다. 이 그림 자체를 명시적으로 표현하는 프로그래밍 언어가 필요할 것 같습니다. 다시 말해 reactive programming의 핵심은 독립적인 여러 개의 작업단위와 그 사이에서 흐르는 데이터의 흐름입니다. 생각해보면 컴퓨터의 처리방식이 상당히 특별한 편에 속하고, 우리 주변에는 이런 식으로 일어나는 일들이 정말 많은데요. 가장 작은 규모에서는, 이게 전가산기라고 부르는 회로인데, 왼쪽에서 오른쪽으로 데이터가 흐르고 있고, 여기 나와있는 데이터들은 각자 독립적으로 연산을 수행하죠. 좀더 커지면, 밴드에서 사용하는 믹서 같은 거에요. 전자 악기에서 나오는 신호들을 이펙터 같은 걸로 변환시키고 믹서로 서로 조합해서 스피커 음향시스템으로 출력하는. 이것도 모든 게 동시에 일어나고, 누군가 하나가 명령어를 읽고 그런 현상이 일어나지 않죠. 더 커져서 회사에서 일어나는 일을 생각해도 마찬가지입니다. 회사 직원들은 각자 독립적인 뇌를 가지고 일을 하고. 그들 사이에서 조직도를 통해서 메시지를 전하고, 업무를 전달하는 구조이죠. 그래서 이런 패러다임이 완전히 달라졌는데, 우리 컴퓨터 프로그래밍 언어는 절차적인 방식으로 되어있으니까 이 패러다임을 어떻게 움직여야 할지를 생각해야 하는데요. 위키피디아에 프로그래밍 패러다임이라고 검색하면 오른쪽에 다양한 쓸데없는 패러다임들이 나오는데, 그거를 네모로 한번 그려봤어요. 그 중에 가장 원초적인 것은 명령형이었죠. 기계가 명령을 하나씩 읽어 들여서 실행하던 것. 그런데 이걸로는, 고수 분들도 계시지만, 일반적인 저 같은 사람으로서는 프로그래밍 하기가 너무 어려운 나머지 프로그래밍 언어가 생기게 됩니다. C언어 같은 경우에는 프로시저 단위로 실행을 구분하고, 단위를 짓고, 스트럭트와 블록들로 코드의 재사용을 어느 정도 가능하게 했습니다. 하지만 70~80년대 때 교과서에서 배우는 소프트웨어의 위기가 찾아오게 되고, 좀더 재사용성이 높은 소프트웨어를 만들기 위해 객체지향프로그래밍 언어가 생기기 시작했죠. 클래스를 만들고 필요하면 reflection이나 template, generic 같은 문법을 쓸 수 있는 상황이 되었습니다. 하지만 이 정도가 우리 업계에서 실무적으로 쓰이는 패러다임의 현 상황인 것 같아요. 그런데 여기까지는 프로세스가 하나라고 가정된 상황에서 만들어진 언어였고, 그래서 멀티 프로세서나 분산 시스템을 구현하는 난이도가 엄청나게 올라갔죠. 그래서 프로그래밍 언어나 라이브러리 차원에서 오른쪽에 있는 패러다임들을 지원하는 것이 더 이로울 것 같습니다. 싱글 프로세서라고 가정되어 있는 명령형 방식의 프로그래밍 패러다임을 최대한 피하면서, 왜냐면 프로세서가 엄청나게 많아질 테니까 그 명령을 하나하나 신경 쓰다 보면 너무 프로그램이 깨지기 쉽고 위태로워 지니까요. 대신에 오른쪽으로 옮겨서 data flow에 기반해서 선언적으로 선언된 데이터의 흐름이고, 그 사이에서 함수형 언어나 함수들을 사용하면서 데이터들이 서로 변환되어서 흐르게 되고, 그것이 동시에 흐르게 되는 그런 패러다임이 필요합니다. 즉, 명령형이었던 것들이 선언적으로 바뀌고, 순차적이었던 것들이 동시적으로 바뀌는 거죠. 요즘 외국 커뮤니티에서 돌아다니는 것 중에 reactive manifesto 라는 선언문이 있어요. 그 선언문은 어떻게 보면 당연한 네 가지 가치를 표방하고 있는데요. Event-Driven이라는 말은 언제 어디서든 발생할 수 있는 이벤트에 빠르게 응답하는 것을 뜻합니다. 그리고 Scalable이라는 말은 접속이 천 개이든 천 만개 이든 부하에 적절히 반응할 수 있고, Resilient라는 말은 실패가 일어나더라도, 컴퓨터가 죽거나 소프트웨어가 비정상 종료를 하거나 하더라도, 그것이 비상 상황이 아닌 언제든지 일어날 수 있는 상황으로 취급을 하고, 그 세가지가 합쳐져서 사용자에게 반응성도 빨라지는 거죠. 그래서 여기서 제일 먼저 나올 수 있는 것은, 제일 중요한 것은, 그리고 제일 근본적인 것은 Event-Driven입니다. Event-Driven이 있어야 빠르게 반응할 수가 있고, 사용자들을 더 많이 받을 수가 있고, 그래서 Scalable 해지고. 그래서 Event-Driven에 대해서 생각해보기 전에 시간에 대한 개념을 한번 다시 한번 짚어봤으면 좋겠어요. 우리는 초 단위로 생각하고 있습니다. 제 앞에 있는 시계도 초 단위로 흘러가고 있고요. 사람에게 가장 익숙한 단위에요. 빛의 속도로 지구를 여러 바퀴, 30만km를 1초에 돌 수 있고요. 그래서 빛의 속도로 이동하는 광케이블 덕분에 외국 웹사이트들은 페이스북 들어갔을 때 1초정도 버벅거리는 게 빛의 속도 때문이죠. 그래서 1초라는 시간은 지구 스케일의 시간이라고 생각하실 수 있을 것 같습니다. 밀리초 단위, 1/1000이라면, 하드디스크에 접근하는 데는 몇 밀리초가 걸리고요. 로컬 네트워크, 우리나라 인터넷이 빨라서 같은 도시에 있는 정도라면 밀리초 정도의 응답이 가능하고요. 모니터의 스크린이 변하는 시간도 밀리초 단위로 일어납니다. 이거는 건물 정도의 스케일이라고 볼 수 있을 것 같아요. 만약에 밀리초 단위로 사는 사람이 있다면 그 사람에게 우리의 1초는 17분처럼 느껴질 거에요. 다시 1/1000이 돼서, 마이크로초 단위의 세상이 되면 SSD에 접근하는데 이 정도의 시간이 걸리고, 보통 메모리가 초당 몇 십 기가 byte를 읽어올 수 있으니까 10K byte를 읽는데 이 정도의 시간이 걸리고. 또 컨텍스트 스위치를 제가 강조해놨는데, 쓰레드에서 다른 쓰레드로 전환하는데 걸리는 시간이 마이크로초 단위입니다. 이거는 컴퓨터 하나 안에서 일어나는 규모의 시간이라고 볼 수 있을 것 같아요. 이 세상에 사는 사람에게 우리 1초는 12일처럼 느껴질 거에요. 그리고 나노초는 프로세서 단위에서 일어나는 시간이고요. 명령어 하나, 레지스터 L1, L2 캐시에 접근하는 데에 걸리는 시간이 나노초 단위의 시간이 걸리고, 빛의 속도로 30cm 밖에 움직이지 못하는 시간입니다. 그래서 컴퓨터가 작은 이유이기도 하고요. 이 세상에 사는 사람들에게 우리의 1초는 32년 같이 느껴질 것입니다. Event-Driven 방식을 사용해서 프로세서의 입장에서 최대한의 성능을 내기 위해서는 이 나노초 단위의 프로세서 입장에서 생각할 필요가 있어요. 그래서 컨텍스트 스위치마저 너무나도 긴 시간이죠. 한번 단위로 그려봤는데, 제일 밑에 있는 게 1초이고, 그 사이에 엄청난 규모의 차이가 일어납니다. 그래서 메인 메모리 접근보다 더 오래 걸리는 것들은 쓰레드한테 부탁을 하기가 너무 느려요. 우리가 객체지향프로그래밍에도 들어가있는 메소드의 일반적인 형태이죠. 입력인자가 있고, 아웃풋 인자가 있고. 이거를 기반으로 거의 모든 객체지향프로그래밍 디자인패턴 이런 것들이 다 이 상황을 가정하고 만들어졌는데, 이 상황의 가장 큰 문제점은 입력이 들어가고 출력이 나올 때까지 이걸 실행한 쓰레드가 아무것도 못한다는 것이었습니다. 다시 말해 여기 노란색으로 표시된 너무 느린 작업들을 하려고 하면 쓰레드한테는 너무나 귀중한 시간을 낭비하는 그런 상황인 거였죠. 한편 흔한 자바 웹서버는 이런 식으로 생겼어요. 제일 밑에서 너무 느린 작업을 하고 있죠. 그런데 이 콜스택이 엄청난데, 콜스택이라는 엄청난 부하를 유저 한 명마다 다 줘야 했어요. 만약에 유저 한 명을 처리하는데 걸리는 시간을 네모로 표시하고, 회색 줄이 쓰레드라고 하면 유저가 8명정도 접속했는데, 이 시간 범위 안에서 더 쓰레드를 추가하지 않으면 네모가 하나 더 들어갈 공간이 없죠. 그래서 쓰레드를 자꾸 추가하는 방식으로 많은 사용자를 받기 시작했고, 그러다 보니 쓰레드가 몇 천 개, 몇 만 개 되면 컨택스트 스위치가 프로세서의 성능에 비해서 너무 느리기 때문에 성능이 제한되고, scalable가 줄어들 수 밖에 없었습니다. 만약에 Event-Driven 방식이 되면, 이렇게 긴 시간으로 되어있던 쓰레드가 이렇게 나눠질 수가 있어요. 실제로 너무 느리지 않은 메모리나 프로세서 작업으로 실행하는 부분만 쓰레드가 사용되고, 나머지에서는 다른 일을 할 수 있는 거죠. 실제로는 지금 보이는 정도로 그려놓았지만 아까 보셨듯이 위에 있는 네모와 아래 있는 네모의 폭은 천 배 이상 차이가 날 거에요. 아까 했던 네 개의 쓰레드에서 8명을 겨우 받았던 작업은 이렇게 표현이 가능하고요. 말씀 드렸듯이 1000배 이상 가는 메모리이기 때문에 더 많은 사람들이 들어갈 수가 있습니다. 흔히 말하는 싱글 쓰레드 기반의 프레임워크라고 하는 Node.js라든지 VertX 이런 것들이 다 이런 거를 목표로 하고 있고요. 그래도 쓰레드 하나를 쓰자니 밋밋하니가 여러 쓰레드나 여러 프로세스를 쓰면 더욱 많은 사용자를 받을 수 있겠죠. 여기서 중요한 점은 이 모든 네모들이 아주 가늘어야 하고, 소프트웨어 스펙의 가장 낮은 부분에서든 가장 높은 부분에서든 쓰레드가 블록하면 안 된다는 것입니다. 즉, TOP TO BOTTOM reactive 한다는 것이 가장 중요합니다. 그렇게 하기 위해서는 운영체제 차원에서의 이벤트 지원이 필요합니다. 여기서는 윈도우에서 제일 빨랐는데요. 여기 계시는 서버 개발자 분들이 아주 고수이신 IOCP가 windows에서 제일 먼저 나왔고, 이에 질세라 BSD 진영과 Linux 진영에서도 그에 상응하는 이벤트 기반, 주로 네트워크에 치중하는, 하지만 네트워크와 I/O 모두 사용할 수 있는 그런 이벤트 지원이 시작되었고요. 운영체제만으로는 어렵다보니 cross platform한 이벤트 라이브러리들도 등장하기 시작했습니다. 파이썬이나 자바가 native 프로그래밍 언어보다 훨씬 느리긴 하지만 아까 보셨듯이 프로세서에서 10배정도 느려지는 것은 쓰레드에서 1000배 느려지는 것 보다 훨씬 효율적이기 때문에 파이썬이나 자바로도 더 빠른 프로그램, 더 scalable한 서버를 만드는 게 가능해졌고요. Native 라이브러리들도 따라 나오기 시작했어요. LIBEVENT, LIBEV, LIBUV라고 부르는 것들이 그런 것들이고, 그 라이브러리들에 기반해서 자바스크립트를 서버 사이드에서 쓰는 Node.js나 아까 보셨던 엔터프라이즈 급의 자바의 엄청난 콜스택에서 탈피해서 이벤트 기반으로 reactive하게 만들 수 있는 프레임워크인 VertX 같은 것들이 나오기 시작했습니다. 그런데 이 두 가지 프레임워크는 치명적인 뻘짓을 하게 되는데요. 콜백을 다음 인자로 넣은 것입니다. 콜백을 다음 인자로 넣으면 쓰레드의 진행과 무관하게 함수를 넘겨서 에러가 있으면 에러를 핸들링하고, 결과값이 나오면 결과값을 핸들링할 수 있죠. 여기까지는 아름다워 보이는데, 뭔가 연산이 세 단계만 넘어가면 이렇게 되요. 이게 태스크 1, 2, 3을 차례대로 하는 비동기 코드인데, Node.js를 처음 배울 때 가장 먼저 주화입마에 빠지는 부분이 이 콜백지옥입니다. 이거를 어떻게 해결할 수 있는 방법들이 고안되고 있고, 어떻게 구조를 잘 짠다든지, 코드 변환을 통해서 컴파일러에 들어가기 전에 뭔가를 해준다든지 하는 게 있지만, 근본적으로 프레임워크의 API가 그렇게 생겼으니 뭔가 근본적인 해결책이라고 할 수 없을 것 같아요. 그러니까 이렇게 되어있는 작업을 비동기적으로 하기 위해서 콜백을 추가할 게 아니라 return 타입에 M이라는 것을 쓰게 됩니다. M에 대해서 이 후반부에서 설명하게 될 거에요. 즉, 인풋에서 아웃풋으로 가는 함수가 아니라 인풋에서 M아웃풋으로 가게 되는 걸 만드는 게 functional reactive programming의 핵심입니다. NDC의 주제인 체크포인트를 한번 만들어봤어요. 처음에 말했던 세상은 뒤집혔어! 다시 만난 세계의 가사죠? 유니프로세서에서 멀티프로세서 세상이 되었고요. 컨트롤이 아닌 데이터가 흐르고 싶은 패러다임. 그리고 Event-Driven만이 이것을 가능하게 해준다. 그리고 콜백은 너무 싫다. 정도가 여기까지의 체크포인트 들이었습니다. Function programming이 왜 이거랑 연관이 되는지를 말씀 드려야 될 것 같아요. Function 프로그램을 단순히 함수를 변수에 저장하거나, 인자로 넘기거나, 람다로 프로그래밍을 표현하거나. 그런 것들도 있지만 그것보다 좀더 깊은 이론들이 들어있는데, 그 중 하나가 이 M이에요. 차마 사람들이 말하기가 두려워서 말하지 않는 이 단어는 MONAD라고 부르는 거고요. 이걸 찾다 보면 무시무시한 하스켈 코드가 나온다든지, 이상한 수식이 나온다든지 해서 이해를 포기하게 하는 것인데, 제가 한번 그림으로 얘기해볼게요. 어떤 값이 있으면 그 값에 껍데기를 씌우는 게 MONAD입니다. 이 경우에는 포장지 안에 넣음으로써 이 값과 context, 문맥을 표현할 수가 있었어요. 이 문맥이라 함은 값이 들어있을 수도 있고 만 들어있을 수도 있는 그런 경우에 해당하고요. 이런 것들을 maybe라고 부릅니다. 아니면 다른 이름으로 option, optional, nullable 이라는 형태로 여러분들이 프로그래밍언어에서 부분적으로 지원하는 걸 많이 보셨을 거에요. 만약에 2라는 값에 +3이라는 함수를 실행해서 5를 만드는 게 있었다면 이 MONAD에는 +3을 하면 타입이 달라서 힘들죠. 그래서 map일는 연산을 사용하면 어떤 MONAD이든간에 안에 들어있는 걸 꺼내서 +3을 한 다음에 다시 포장지를 입혀주는 이런 작업이 업이 일어납니다. 안에 들어있는 거를 꺼내서 연산을 수행하고 포장지를 입혀주는 것. 만약에 예외적인 경우, 아니면 의도한 경우에 값이 들어있지 않은 경우에는 적용할 함수가 없으니까 아무것도 하지 않겠죠. 그래서 map+3을 하면 그냥 값에 +3을 했던 것처럼 MONAD에서 MONAD로 가는 연산을 수행하는 것이 가능합니다. 아까 보셨던 데이터의 흐름이죠. 이것들을 map으로 표현하면 이런 식으로 할 수 있을 것 같아요. +3이나 +4 같은 함수들을 블록으로 만들고 그 사이에 화살표로 표현했던 부분에서 MONAD가 흐르고, 그렇게 함으로써 연산이 진행되는 거죠. MONAD에는 maybe말고도 다양한 타입이 있습니다. Maybe는 예외적인 경우에 값이 안 들어가 있을 수 있는 거였고. try라는 거는 예외적인 경우에 reception이 들어있을 수 있는 거였습니다. 우리가 프로그래밍언어에서 지원하는 reception들은 콜스택을 타고 올라가기만 하기 때문에 콜스택의 의미가 없어진 native 프로그래밍에서는 이런 식으로 MONAD 속에 reception을 넣어서 에러처리 하는 것이 가능하고요. 또 MONAD 속에 값이 하나만 들어있으리라는 법이 없어서 한 개, 두 개, 세 개, 네 개 들어있는 iterable도 MONAD로 취급할 수 있습니다. 그리고 future. 동기적으로 실행되는 것이 아닌 미래의 어느 시점에 값이 돌아오거나, 아니면 미래의 어느 시점에 reception이 담겨 있을 수 있는 그런 future도 MONAD 타입이라고 볼 수 있는데요. 사실상 우리가 generic, template 문법을 사용해서 표현하는 거의 모든 것들을 MONAD라고 생각할 수 있을 것 같습니다. 즉 x, y ,z라는 값이 있으면 M<x>, M<y>, M<z> 라고 하면 그것을 포장지로 덮어 싼 MONAD가 되는 것입니다. MONAD의 구성 요소가 두 가지가 있는데요. 그것만 짚고 이론적인 얘기를 넘어가도록 할게요. 첫 번째는 unit이라서 MONAD에 껍데기를 씌우는 연산입니다. 제가 움짤을 만들었는데 아까워서… 얘가 unit이에요. x에다가 껍데기를 씌우는… 그러면 unit(x)가 됩니다. 참 쉽죠? 그 다음은 f입니다. F는 아까 x에서 y로 가는 대신에 M<y>로 간다고 했었는데요. 영상으로 볼게요. X가 값이 있었으면 y로 가기는 가는데 껍데기도 씌우면서 가는 게 f에요. 이 연산이 동시에 일어난다는 것을 잘 기억하기 위해서 한번 더 보겠습니다. X가 있는데, 껍데기가 씌워지면서 y로 변하는 거에요. 참 쉽죠? 그 다음이 flatMap이라고 부르는 이산한 건데요. 얘는 x의 MONAD가 있으면 y의 MONAD로 움직이는 게 가능해요. 아까 f가 x에다가 무슨 짓을 했는지 기억이 나신다면, x에 MONAD가 있으면 껍데기를 벗기고 아까 했던 y로 바뀌면서 껍데기를 씌워주는 거. 이게 flatMap f에서 하는 것입니다. 이것 두 개만 있으면 MONAD의 성립 요건이 되고요. 기타 등등 이상한 법칙들이 있긴 한데 그거는 중요하지 않은 것 같습니다. 언어에 따라서 unit을 return이나 just라고 부르는 곳도 있고, flatMap 대신에 mapMany, bind, theCompose, 아니면 >>=로 쓰는 곳도 있습니다. 어쨌든 이름은 주요하지 않지만 이 두 가지 개념만 있으면 여러분은 MONAD를 이해하신 거고요. 아까 데이터 흐름을 적어보면 이래요. 2에다가 껍데기를 씌운 A라는 값이 있으면 x에다 +3을 해서 껍데기를 씌워주는, 아까 f에서 두 번 봤던 그거죠? 그 함수를 flatMap 시키면 5에다가 껍데기가 씌워진 모양이 되고, +4를 해서 껍데기를 씌운 함수를 다시 flatMap 시키면 9에다가 껍데기를 씌우는 우리가 원하는 결과가 되는 거죠. 이런 식으로 flatMap과 unit을 사용하면 MONAD에 씌워진 형태로 데이터들이 흐르는 것이 가능해집니다. 동기적으로 하나의 데이터를 받아오기 위해서는 아까 reception이 들어있을 수 있는 try라는 게 사용됐었고요. 비동기적으로 하나의 데이터를 사용하려면 future라는 것을 사용할 수가 있습니다. 여러 개의 데이터가 들어있으려면 친숙한 iterable 또는 inemerable 같은 MONAD를 사용할 수가 있고요. 그러면 여러 개의 다수의 데이터가 나오려면 어떻게 해야 될까요? 이것이 Rx가 등장하는 시점입니다. Rx라는 라이브러리에서는 observable 이라는 것을 통해서 비동기의 다수의 데이터를 포함할 수가 있어서 아까 회색 화살표로 봤던 여러 개의 데이터가 흐르는 상황을 만들 수가 있는데요. 그래서 Rx는 비동기적으로 흐르는 데이터의 LINQ에서 나오는 다양한 쿼리 연산들. 그리고 scheduler라고 하는 병렬처리 제어하는 모듈 비슷한 것들이 있어요. 처음에 reactive extensions는 .NET에 2009년에 추가된 것이었고요. 이게 마이크로소프트에서 항상 뭔가 만들면 아무것도 안 쓰면 남이 따라 만들죠. Rx JARA라는 곳에서 마음에 들어서 만들 게 되었고요. 다양한 언어 포팅이 존재해서 사실상 실무에서 사용되는 거의 모든 언어에서 사용을 할 수 있습니다. Observable이 reactive stream이라고 했는데, 화살표 따라서 데이터를 동그라미로 표현하면 빨주노초파남보 가 하나씩 오고, 정상적으로 끝나거나, 그게 첫째 줄이고, 둘째 줄에서 오다가 비정상적으로 끝나거나. 아니면 데이터가 안 오다가 끝날 수도 있고, 안 오다가 비정상적으로 끝날 수도 있고, 영원이 안 끝날 수도 있습니다. 영원이 안 끝나는 데이터의 흐름 같은 경우는 이런 식으로 할 수도 있고요. 그래서 iterable 또는 stream에서 했던 방식이 다음 값을 키를 return하는 메소드를 알아오고 에러가 발생하면 reception이 콜스택을 따라서 던져지고. 그랬던 것과 반대로 observable과 같은 경우에는 왼쪽에 있느 함수의 입력 인지와 출력 인자가 자리가 바뀌었어요.. 그래서 오른쪽에 있는 함수들의 return값은 다 void이고, 인자로 데이터의 값이 오는 것을 핸들하거나, reception이 들어오는 것을 핸들하거나, stream이 끝나는 것을 핸들하는 거나 하는 것이 가능한데, 그래서 입력인자와 출력인자의 위치가 바뀌어서 그것을 duality라고 표현합니다. 그렇게 바뀌긴 했지만 데이터를 만들고 사용하는 쪽을 빼면 그 중간에 transform하는 부분은 완전히 똑같이 사용할 수 있어요. 로컬 메모리에서 읽는 경우에는 iterable을 통해서 바로 읽을 수 있겠죠. 동기적으로. 그래서 처음 10개를 떼고, 그 다음 5개를 취한 다음에, 그 5개에 뭔가를 붙이고 출력하는 것을 iterable로 했다며 오른쪽에 observable을 return하는 함수, getDateFromNetwork 에서 네트워크로 오래 걸리는 작업이라도 네트워크에서 오는 데이터 10개를 스킵하고 그 다음 5개를 가져서 뭔가 더한 다음에 출력하는. 그 연산은 왼쪽과 오른쪽이 완전히 똑같아서 enqueue 오퍼레이터들에 익숙하기만 하다면 비동기적인 프로그래밍임에도 불구하고 콜백지옥 없이, 그리고 에러 핸들링을 위해서 엄청난 일을 할 필요 없이 이렇게 간단하게 표현이 가능해집니다. 몇 가지 오퍼레이터들을 그림으로 소개해드리려고 해요. 인풋이라는 observable이 있어서 이 stream을 표현하려면 map 연산을 할 수가 있겠죠. x에서 x+3으로 보내는 거, y에서 y+4로 보내는 거. 이것은 같은 동기적으로 일어난 작업이고 +3, +4처럼 빠른 작업은 이렇게 하는 것이 유리했고요. 만약에 +3, +4 같은 작업이 단순한 덧셈이 아니라 미국에 있는 서버에서 와야 되는 쿼리 같은 경우에는 flatMap으로 표현할 수가 있습니다. 이렇게 하면 화살표를 따라서 흐르는 데이터 연산들을 비동기적으로 Event-Driven 방식으로 실행 될 수 있도록 하면서도 아까 동시적으로 실행했던 것과 분량상 차이가 나지 않는 상황이 만들어지고요. 두 개의 stream을 합치는 경우에는 여러 오퍼레이터 중에 하나인 zip 이라는 아이를 쓸 수가 있습니다. 만약에 콜백방식에서 얘를 했다고 생각해보세요. 그러면 둘 중에 뭐가 먼저 끝날지 모르니까 그게 끝났을지, 안 끝났을지 저장하는 변수를 두고 그 변수에 동기화를 하고, 그런 삽질 코드가 들어가는데 이거보다 간단할 수가 없겠죠. 오퍼레이터들이 진짜 많이 있어요. 그냥 LINQ에서 지원하는 것보다 더 많이. 에러가 났을 때 다른 stream으로 failover를 할 수 있다든지, timeout이 걸렸을 때 다른 작업을 수행한다든지, 아니면 타이머에 기반하여서 stream을 변환한다든지. 그런 것들이 가능합니다. 리니지 이터널 플랫폼에 대한 얘기를 간단하게 하려고 해요. 플랫폼에서 돌아가는 프로세스 하나는 이런 식으로 생겼어요. 네트워크에서 오는 메시지들을 핸들러로 돌아가고, 그 다음에 데이터 저장소로 왔다 갔다 하는데, 이것이 전통적인 방식의 콜스택 내지 함수 호출로 이루어지는 게 아니라 메시지 패칭으로 이루어지는 것이기 때문에 쉽게 노드 하나라는 박스를 추상화할 수가 있습니다. 이 노드들은 여러 개가 서로 통신하면서 하나가 없어져도 서비스에는 큰 문제가 없는 그런 걸 만들고 있고요. 그것이 하나의 서비스로 또 추상화가 됩니다. 이 서비스가, 아까 노드 같은 경우에는 같은 역할을 하는 거였다면, 서로 다른 역할을 하는 서비스들이 여러 개가 만들어지고, 그것에 여러분의 컴퓨터가 접속해서 게임을 하는 것이 리니지 이터널의 서버 플랫폼의 설계 방식이었고요. Reactive Manifesto에 있는 네 가지를 어느 정도 지친 것 같지요. 다음은 이렇게 말하는 게 저 혼자 이상한 것을 하는 게 아니라는 You Are Not Along이라는 제목으로 만들어봤습니다. 빵터지는 사람은 덕후인증이고요. 자바 세상에서는 Playflamework이라는 웹 프레임워크나 akka라는 acktorlibrary. 또 spring 에서 만든 Reactor라는 메시지 패싱 기반의 라이브러리들이 이런 reactive programming을 지원하고 있어요. 그리고 이것의 제작자와 스칼라 제작한 분과 여러 네임드 개발자 분들이 모여서 reactive-streams이라는 표준을 만들고 있습니다. 그래서 Rx나 akka, 또는 reactor에서 표현했던 reactive한 방식을 하나의 표준, reactive-streams으로 통일을 하려고 하고 있고요. 그렇게 되면 각각의 라이브러리들이 이 표준을 지원하는 방식이 될 거에요. 자바스크립트 사상에서는 node.js가 워낙 뻘짓을 하는 바람에 클라이언트 사이드에서 더 많이 발전했는데요. 이름부터 react인 페이스북에서 만든 React라는 걸 포함해서 여러 MVVM 방식 모델이, 아까 엑셀에서 봤던 것과 같이 reactive한 방식으로 제작이 되고 있고, Rx의 포팅도 물론 있고, JavaScript Promises라는 MONAD와 비슷한 타입이 표준으로 제한되어 있습니다. 구글에서 만든 dart 라는 언어는 처음부터 뻘짓을 하지 않고 재대로 만들었어요. Future와 stream이라는, 아까 말한 futrue와 observable에 해당하는 MONAD스러운 타입을 표준 라이브러리에서 제공해서 콜백 헬에 빠질 염려 없이 서버를 만들 수가 있고, dart가 자바스크립트로 번역돼서 돌릴 수도 있지만 서버 사이드에서는 자체 VM에서 돌아갈 수도 있고, dart팀에서는 그게 노드보다 빠르다고 주장을 하던데, 한번 해보시고요. elm이라는 웹 기반 functional reactive 언어가 있는데, 얘는 이 언어로 작성하면 CSS와 자바스크립트, HTML로 변환이 되는 건데, 이 사이트에 가시면, 한 사람이 만들고 있는 거긴 한데, 슈퍼마리오 같은 게임을 엄청 선언적으로 쉽게 만드는 것을 확인하실 수 있습니다. 3D 프로그램도 만들기도 하고요. Hadoop에서 돌아가는 Apache Pig 라는 언어도 data flow에 기반한 언어이기도 합니다. React 2014라는 컨퍼런스가 런던에서 얼마 전에 있었는데, 여기 컨퍼런스 영상이 모두 공개되어 있고, 제가 이 40분의 시간 동안 미처 말하지 못한 이야기들을 여기서 보실 수 있을 것 같아요. 그리고 마지막으로 coursera에는 이것을 위한 수업이 2개가 지금 준비가 되어있습니다. 함수형 프로그래밍과 reactive 프로그래밍을 해보시려면 여기 숙제를 하다 보면, 저도 그렇게 해서 많이 익숙해졌고 실무에도 적용하게 되었습니다. 이 정도가 functional reactive programming의 미래 내지는 비전이라고 볼 수 있을 것 같고요. 얘는 NDC 쪽에서 템플릿을 줘서 저희 리니지 이터널 플랫폼 쪽에서 사용을 하고 있습니다. 함께 일하고 싶으신 분은 KR.NCSOFT.COM에 가셔서 채용 공고를 확인해주시면 감사하겠습니다. 이상입니다.
디버깅에 대해서 질문해주신 분이 있는데, “디버깅은 기존의 개념과 큰 차이가 있을 텐데, 어떤 것이 있는지 간단한 예를 설명 부탁 드립니다.” 
라고 하셨습니다. 디버깅이 사실 생각해보면 지난 20~30년간 발전된 콜스택과 브레이크 포인트를 이용한 디버깅과 각종 도구들이 나와있는데, reactive 방식에서는 콜스택이라는 게 없이 이벤트 룸에서 바로 실행되는 거다 보니까 아주 발전되고 성숙한 툴을 사용할 수 없어서 그게 단점인 건 사실입니다. 하지만 아까 보셨던 데이터 흐름을 기반으로 visualize를 한다든지, 타임 시리즈 데이터베이스에 그것의 기록을 남겨서 대량으로 분석한다든지 하는 게 가능해 질 것 같고요. 어차피 멀티 프로세서 세상에서는 브레이크 포인트 하나 잡는다고 해결될 문제들이 많지 않아서 어쩔 수 없는 변화라고 생각합니다.
“I/O 작업보다 CPU intensive한 작업의 경우에도 이런 방법론이 효과가 있을까요?” 
라고 물어보신 분이 있는데, 규모에 따라서 다를 것 같아요. 아까 보셨던 bitcoin miner는 전형적인 CPU intensive 작업이기도 하지요. 그런데 병렬로 했을 때 효과가 있을 것 같고요. 
“C, 노드 박스1, 2, DB 순서대로 데이터가 흐를 때, C에서 먼저 출발한 데이터가 DB에 더 늦게 도착하는 경우는 없나요?” 
라고 하셨는데, reactive-streams 방식상 순서가 UDP처럼 바뀌지는 않는데 그래도 시간 순서대로 생각하는 것에서 탈피해서 데이터의 흐름을 기반으로 생각을 하면 이런 시간 순서를 고민하는 것을 벗어나려고 하는 것이다 보니까 그런 게 유리할 것 같고요.
Rx 파이썬 포팅이 있는 거는 github에서 확인했고요. Reactive-extensions라는 마이크로소프트에서 운영하는 코드플렉스 사이트나 github 페이지에 가면 소스를 볼 수는 있는데, 그게 포팅이다 보니까 성숙하지는 않은 것 같아요. 그래서 파이썬은 제가 잘 모르기도 하는 분야라서…
문법 추가들이 되게 많이 나와있어요. 이거는 하나의 비동기 프로그래밍을 표현하는 방식이었고, stream으로 표현할 수 있기 때문에 장점과 단점이 생기는 거였는데, 스칼라나 C# 언어에 있는 async await 이라는 키워드 같은 경우에는 컴파일러가 그것을 데이터 흐름 방식으로 변환을 해주는 거였고요. MONAD 타입을 지원하는 언어 중에는 for compilation 같이, 뭔가 flatMap 같은 인지적으로 비용이 드는 계산 대신에 for 문 쓰는 것처럼 계산을 할 수 있게 해주는 그런 문법도 있긴 하고요. 제 생각에는 coroutine이나 다른 접근법들도 같은 문제를 해결하기 위한 방법이라고 봅니다. 추가적인 질문이 없으시면 여기서 마무리하고 다들 밥을 먹으러 가는 걸로… 감사합니다. 여러분.
TITLE	TITLE	TITLE	TITLE
TITLE	TITLE	TITLE	TITLE
전체보기
