• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
dart:async로 맛보는 Functional Reactive Programming
 

dart:async로 맛보는 Functional Reactive Programming

on

  • 429 views

 

Statistics

Views

Total Views
429
Views on SlideShare
414
Embed Views
15

Actions

Likes
6
Downloads
0
Comments
0

3 Embeds 15

http://mangastorytelling.tistory.com 10
http://www.hanrss.com 3
http://www.slideee.com 2

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • 전문연구요원
  • 가장 첫 순서인 “다시 만난 세계”에서는 프로그래밍 언어를 처음 배우던 때로 돌아가서 <br /> 프로그래머들이 잊고 있었던 세계를 다시 만나 보려고 합니다. <br /> 우리가 만약 지금처럼 절차적으로 프로그래밍하는 것에 완전히 길들여져 있지 않았더라면, <br /> 처음 그 갈림길에서 다른 길을 갔더라면 어땠을 지 생각해 보겠습니다.
  • 대충 이렇게 표현하고, 프로세서는 프로그램을 한줄씩 따라가며 함수를 호출하고 결과 값을 얻어낼 것입니다. <br /> 컨트롤이 한줄씩 명령을 실행하기 때문에 이런 방식을 명령형Imperative 또는 절차적Procedural 이라고 합니다.
  • 그런데 이렇게 표현하면 어떨까요? <br /> 그 합성함수를 조금 다른 방식으로 그려 본 것입니다. <br /> F 와 g 는 각자 아주 간단한 계산을 하는 블록입니다. <br /> 데이터는 계속 흐르고, f와 g는 독립적으로 각자 주어진 일을 수행합니다. <br /> <br /> 그런 의미에서 이 그림은 선언적Declarative입니다.
  • 작은 단위의 두 블록을 합쳐서 하나의 큰 블록이 있다고 볼 수도 있겠죠.
  • 생각해 보면 우리가 생각할 수 있는 거의 모든 것을 이 그림으로 표현할 수 있습니다. <br /> 데이터가 흐르는 작은 단위로 소프트웨어를 구성하고 그것을 조합해서 큰 소프트웨어 전체에 데이터가 흐를 수 있게 하면 좋을 것 같다는 생각이 듭니다.
  • 아무리 봐도 데이터의 흐름이 컨트롤의 흐름보다 좋아 보이지만, 70년대와 80년대를 지나면서 데이터 플로우는 대세를 잃게 됩니다.
  • 가장 직접적인 원인이라면 컴퓨터의 시초가 된 튜링머신과 그로부터 탄생한 모든 컴퓨터들이 모두 이 방식이었다는 데에 있겠지만, <br /> 무엇보다 가장 큰 원인은 어느 한 회사였습니다. 그 회사의 상표가..
  • 이렇게 생겼는데, 이 회사에서 프로세서를 너무 잘 만들었고, <br /> 그 프로세서에서 매우 효율적으로 돌아가는, 컨트롤 플로우에 기반한 프로그래밍 언어와 소프트웨어가 주류가 되기 시작했습니다. <br /> <br /> 컴퓨터 한 대로는 어쩔 수 없으니 고성능을 위해선 여러 대로 분산해서 써야 하게 되었습니다. <br /> 이제 컨트롤 플로우 방식을 선택해야 했던 요인들이 없어졌으니, 다시 데이터플로우에 눈길을 돌릴 때가 된 것입니다.
  • 리액티브 프로그래밍은 데이터 플로우 방식의 프로그램을 구현할 수 있는 하나의 패러다임입니다. <br />
  • 그런데 같은 동작을 엑셀에서 했다면 어떨까요? <br /> 3, 4를 입력하고 C를 저렇게 정했다면 <br /> A, B의 값을 바꾸면 C의 값도 자동으로 변하겠죠. <br /> 이것이 바로 Reactive Programming 의 가장 특징적인 개념입니다.
  • 엑셀에서처럼, Reactive 하게 C = A + B 라고 했다는 말은 사실 다음과 같은 데이터 흐름을 정의한 것과 같습니다. <br /> 보셨듯이, 절차적procedural, 명령형imperative이지 않고 선언적declarative이며, 컨트롤의 흐름에 관계 없이 데이터의 흐름에 기반해 있습니다. <br /> 프로그램이 이렇게 선언적으로 짜여 있다면 C = A + B 라고 하고 A, B의 값이 바뀌면 자동으로 C의 값도 변화하는 셈이죠. <br /> <br /> <br />
  • 즉, 리액티브한 시스템을 위해서는 독립적인 여러 개의 계산 단위와 데이터들이 그들 사이로 흐르는 방식이 필요하고, <br /> 그렇게 되어야 분산 시스템을 제대로 만들 수 있습니다. <br /> <br /> 찾아보면 이런 방식이 우리 주변에 정말 많이 있습니다.
  • 가장 유사한 것으로는 논리회로가 있습니다. 그림은 ‘전가산기’라고 부르는 덧셈을 하는 회로이죠. <br /> 이런 회로가 아주 복잡해지면 CPU가 되고 메모리가 되기도 하구요, <br /> 이런 하드웨어를 만들기 위해서 사용되는 Verilog 같은 언어들은 데이터플로우 패러다임으로 분류됩니다.
  • 밴드에서 연주하는 음악도 각각의 악기가 보내는 전기적인 신호가 각종 이펙터와 믹서를 거쳐서 출력 결과를 내놓는 것이었구요.
  • 좀더 크게 보면 우리가 회사와 세상에서 하는 모든 일들은 각자 살아가는 사람들이 서로 메시지를 주고 받으면서 <br /> 제가 지금 하고 있는 일도 여러분들께 메시지를 전달하고 있는 것이죠. <br /> <br /> 이러한 새로운 패러다임을 컴퓨터로 구현하기 위해서는 어떻게 해야 할까요? 다른 패러다임들이 무엇이 있는지부터 찾아봅시다.
  • 우리가 아는 함수는 입력을 주면 출력을 리턴합니다. 그런데 문제가 있어요. <br /> 이 함수는 동기적으로 호출되기 때문에, 입력이 들어가고 출력이 나올 때까지 이 함수를 실행한 스레드는 당연하게도 다른 일을 못한다는 것입니다. <br /> 우리가 객체지향 프로그래밍 패턴이라고 배웠던 것들 중에 대부분이 이것을 당연하게 생각하고 있는데,
  • 그것의 결정체라고 할 수 있는 엔터프라이즈 자바 어플리케이션의 콜스택을 한번 봅시다. <br /> 진짜 하려고 했던 일은 노란색 네모가 가리키는 것 뿐인데, 나머지가 저렇게 많은 화면을 차지하고 있습니다. <br /> 더 문제는 스레드는 수백개 이상으로 만들기 부적절한 비싼 자원인데, 이걸 각각의 사용자가 한 스레드씩 잡아먹고 있다는 점이죠. <br /> <br /> 수만명 규모 이상의 부하를 처리하기 위해서는 그래서 비동기 방식이 필수적입니다.
  • <br /> 만약 블로킹 호출이 아닌 이벤트기반 프로그래밍이라면 아래와 같은 형태가 가능합니다. <br /> 그림은 이 정도이지만 실제로는 1000배 이상의 차이가 날 것입니다.
  • 완전히 이벤트드리븐 방식이 되면 이렇게 싱글스레드만으로도 엄청난 성능을 낼 수 있게 됩니다. <br /> 쿼드코어 컴퓨터라면 스레드 4개를 사용해서 성능을 더욱 높일 수 있겠죠. <br /> <br /> 그런데 이 중 하나라도 블로킹하는 아이가 있으면 어떻게 될까요? 스케일이 다른 네모가 등장하면서 다른 네모들이 끼어들 자리가 없게 되겠죠.
  • Event Driven 방식을 위해 가장 먼저 필요한 것은 운영체제 차원에서의 지원입니다. 여기에선 윈도우 진영이 제일 빨랐습니다. <br /> 초기 온라인 게임서버들이 윈도우 위주이고 여기 계신 서버개발자분들 중 다수가 IOCP의 전문가이신 것도 이것과 관련이 있죠. <br /> … <br /> 그런데 이 NodeJS와 VertX는 치명적인 뻘짓을 하고 맙니다.
  • 비동기 방식을 위해 콜백을 인자로 넣어 버린 것이죠.
  • NodeJS의 콜백 함수들은 대개 이런 식으로 생겼습니다. 비동기 호출을 하고,
  • 콜백 방식으로 비동기 작업을 3번 정도만 하려고 해도, 이런 식으로 함수 안에 함수 안에 함수 넣기를 반복하게 됩니다. <br /> 몇 단계씩이나 들어가는데다 에러처리와 로직이 뒤엉키면서 관리할 수 없는 구조가 되어버립니다. <br /> NodeJS API들이 다 이런 식으로 되어 있어서 프로그램을 짜다 보면 어느새 이렇게 콜백 지옥에 빠져 있고, <br /> 코드를 잘 정리한다거나 컴파일러 변환을 한다거나 하는 식의 몇 가지 해결방법이 고안되어 있긴 합니다만 근본적인 해결책은 아니죠.
  • 우리는 이렇게 되어 있었던 함수에 콜백을 추가할 것이 아니라,
  • 대신 M 이란 아이를 사용할 수 있습니다.
  • 대신 M 이란 아이를 사용할 수 있습니다.
  • 이 M에서 바로 함수형 리액티브 프로그램이 시작됩니다. <br />
  • 이에 반해 구글에서 새로 만들고 있는 Dart는 언어 차원에서 Future와 비동기 스트림을 지원합니다. <br /> 정말 현명한 선택이 아닐 수 없죠.
  • 즉, 리액티브한 시스템을 위해서는 독립적인 여러 개의 계산 단위와 데이터들이 그들 사이로 흐르는 방식이 필요하고, <br /> 그렇게 되어야 분산 시스템을 제대로 만들 수 있습니다. <br /> <br /> 찾아보면 이런 방식이 우리 주변에 정말 많이 있습니다.
  • 자바스크립트 생태계에선 , 우선 아까 말했듯이 NodeJS는 망하긴 했지만, 클라이언트사이드에서 쏟아져나오고 있는 많은 MVVM 프레임웍들이 리액티브 프로그래밍의 개념을 구현하고 있습니다. <br /> Q Promise라는 퓨처 모나드와, Javascript Promise라는 표준이 발표되어 있으며, Rx의 자바스크립트 포팅도 물론 있습니다.

dart:async로 맛보는 Functional Reactive Programming dart:async로 맛보는 Functional Reactive Programming Presentation Transcript