[고찰] 비동기 기술의 추상화

본글은 140% 뇌피셜 입니다. (뇌피셜 주도 개발)

CPU는 멀티코어를 가지고 있고, 우리는 쓰레드를 생성하여, 멀티코어를 활용한다.
그러나 실제 우리가 코어를 직접 컨트롤 하지 않는다.
쓰레드 자체 일종의 추상화이기 때문이다.

여기서 쓰레드의 복잡성을 낮추기위하여 보다 높은 추상을 적용한것이
CSP(Communicating Sequential Processes) 와 Actor 모델들이라고 본다.
이것들은 low-level abstraction 이다.

즉 내가 (비동기를 위해서) 동시성 프로그래밍을 할건데.. 귀찮은게 넘 많아.. 이렇게 쓰면 편할꺼같은데? 에서 나온
"동시성 프로그래밍을 쉽게 구현할수있는 모델의 설계" 에 목적을 둔 추상이다.

Go의 고루틴, Clojure의 core.async 등이 CSP 이며
얼랭이나 스칼라의 Akka 모델, F#의 MailboxProcessor등은 Actor모델이다.

Future / Promise 는 추상화의 도메인이 다르다.
일반적으로 비동기에서는 이벤트-콜백을 이용한다. (콜백을 명시적으로 넘긴다는 의미가 아닌, call-after function 의 의미로써 콜백)
Future / Promise 는 비동기에서 콜백을 어떻게 등록하는가에 대한 추상화로
여기에 monad나 await 의 개념등을 활용하여 비동기를 동기처럼 작성하는것이 목적이다.

FRP는 이벤트 전파 자체의 추상(을 이용한 방법론)이다. (RP or Rx 와 FRP는 다르지만 여기서는 같은것으로보고 설명하도록 하겠다)
Future / Promise 는 한 이벤트(또는 벨류) 에 대하여 추상화를 한것 이라면 FRP는 이를 데이터 스트림으로 바라보는것이다.

우리가 그냥 존재하는 각 Value들을 하나의 선형적인 자료구조인 List로 추상화한것처럼,
List에 값을 적용할때, 하나 하나 for문을 돌고 적용하던 방식에서, map,reduce, filter와 같은 고차함수로 추상화 한것처럼

그냥 존재하던 각각의 독립적인 이벤트자체를 Event Stream이라는 자료구조로 추상화 하고
자료구조와 고차함수로 선언적으로 컨트롤하듯이, 이벤트(+ 알파) 들 을 Obseravble 한 Stream으로써(자료구조로써) 바라보고, 추상화된 map, subscribe  과 같은 고차함수로 컨트롤하는것이다.

개인적인 생각으론 FRP 에서 비동기냐 동기냐 자체보다는, 스트림으로써 바라보는것이 더 중요하다고 생각한다.

예를 들어, 벡터를 다룰때. (map [1 2 3 4]) 와 (pmap [1 2 3 4]) 의 차이는 map 대신 pmap 을 했냐 차이뿐이다. pmap 은 병렬로 돈다.
이 이상의 차이는 사용법의 문제이지, 동작의 문제가 아니다.

FRP 로 이벤트 스트림을 처리할때, 동기냐 비동기냐, 타임 이벤트냐, 마우스 입력이냐 이런구분은 큰 의미가없고,
인간의 사고와 가깝게 추상을 하였기 때문에, 그냥 그 이벤트와 구독(콜백) 의 상관관계가 중요할뿐이다.

정리하자면, 전부 비동기를 동기처럼 생각할수 있도록 해준다.
CSP는 "쉬운 동시성 코딩" 을 위한 추상이다. 쉽게 동시성을 컨트롤하기 위하여 "동시성보장을 위한 통신 모델"을 설계했으며, 해당 통신모델을 쉽게 사용하기위한 함수들을 제공해준다.
Future/ FRP 는 "자연스러운 코딩" 을 위한 추상이다. 여기서는 어떻게 동시성이 보장되는가, 내부적으로 콜백이 어떻게 등록되는지는 중요하지않다. 그것을 숨기기위한 추상이기때문이다.

더 간단하게 말해보자면, CSP / Actor 등은 어렵고 복잡한 동시성 작업을 추상화 한것
Future 등은 귀찮고, 반복적인 콜백등록 작업의 추상화
FRP 는 이벤트 처리방법 전반에 대한 추상화된 방법론

여담

1. 리치히키와 데이비드 놀란은 FRP를 선호하지 않는다는데, 그 명확한 이유를 못찾겠다.
개인적으로 추정하자면.. CSP 를 그대로 사용하는것이 보다 유연하기(?) 때문인듯하다..

I am sure pure FRP implementations will one day widely surmount these obstacles towards correctness.
I'm personally not going to wait - a tunable CSP model seems better suited to the construction of correct
(in the sense that it actually reliably works for the end user, not proof) interactive programs. - David Nolen [1]

2. FRP는 방법론이며, FRP 라이브러리는 CSP 또는 Actor와 같은 low-level abstraction 를 보다 추상화한 일종의 Compositional Event Systems (CES) 으로 볼수있다.

3. CSP (Channel 기반) 과 Actor 기반의 차이는 생산자-소비자의 결합 차이정도로 보면될듯함