변경점

indent-based syntax - 1주차

일단 가장 큰 변화는 들여쓰기 문법을 도입하면서 중괄호({})를 쓸 필요가 없어졌다는 것이다. 1주차 수업부터 조건문을 설명하면서

1
2
3
4

if condition then
  expression
else
  expression

처럼 여러 줄의 표현식이 있을 때 중괄호없이 표기하는 예시를 보여준다.

imperative-loop - 2주차

지금까지 for문(for comprehension)을 쓸 때, flatMap, map, withFilter 등으로 변환된다고 알고 있었는데 여기에 foreach로 변환되는 문법이 하나 추가되었다. for … do인데

1
2
3
4
5

for
  x <- exp1
do f(x)
// is equivalent to
exp1.foreach(x => f(x))

yield처럼 값을 반환하지 않고 실행만 하는 명령식 반복문(imperative loop)이 생겼다.

package-object - 3주차

탑레벨(top-level) 변수들이 허용되어서 굳이 패키지 객체가 필요없긴 하지만 기능도 사라졌다.

imports - 3주차

import 문에서 몇가지 변화가 생겼다. 일단은 패키지 내의 멤버 전부를 가져오는게 import root.from.to._였는데 이제는 import root.from.to.*로 *을 사용하게 되었다. 아직 하위호환으로 _도 사용할 수 있다.

그리고 이름을 변경하여 가져올 때 import from.to.{Pkg => P}였다면 이제는 as라는 키워드를 사용해 import from.to.{Pkg as P}처럼 쓰면 된다.

새로운 given 키워드와 새로운 문법상 맥락이 생기며 given 변수들은 .*로 가져올 수 없으니 given을 한번에 가져오려면 import from.to.given을 쓰거나 given을 포함한 다른 멤버들도 한번에 가져오려면 import from.to{given, *}처럼 사용하면 된다.

Program Entry Point - 3주차

예전에는 Java처럼 main(args: Array[String]) 메소드가 있는 Object들을 진입점들로 찾았다면 이제는 @main이 붙은 메소드들이 모두 진입점이 될 수 있다. 그리고 인자로 @main def run(name: String, n: Int)같은 식의 타입을 받으면 받은 인자들을 순서대로 저 타입 변환을 하는데 맞지않으면 실행이 되지 않는다.

Opaque Types - 3주차

예전에도 데이터의 일관성을 위해 타입을 다른 이름으로 바꾸거나 다른 타입의 인자에 넣거나 trait를 붙여서 구분하는 등의 방식들이 존재했는데, 그 중에서 실행 시점에서 추가적인 리소스를 소모하지 않는 방법은 type alias가 있었지만 원래 타입으로 변환이 가능해서 type UserID = Long, type GroupID = Long이면 두 타입을 혼용하거나 원래 타입과 구분할 수 없다는 단점이 있었고 이걸 해결하기 위해 opaque type이라는 기능이 도입되었다.

1
2
3
4
5
6
7
8

object UserID:
  opaque type UserID = Long
  def parse(string: String) = string.toLongOption
  extension (id: UserID)
    def value(id: UserId): Long = id

def find(id: UserID): Option[User] =
  ... (id.value)

이렇게 타입에 이름을 붙이고, 원 타입과의 변환은 선언된 스코프 내에서만 가능해서 type alias와 다르게 안전하게 사용할 수 있다.

Extension Method - 3주차

위의 예제에서 id.value로 value 멤버가 없는 opaque type에 접근한 것처럼 타입을 확장할 수 있는 기능이다. 예전에는 암묵적 변환(implicit conversion)을 통해 다른 클래스로 변환하고 그 클래스의 메소드를 실행하는 방식이었는데, import를 통해 extension을 가져올 수 있고 특수한 경우로 UserID처럼 opaque type에 연결되어있으면 그 opaque type만 import하면 가져올 수 있다.

Given - 5주차

예전에도 Context Bound라는 타입 연산자(:)가 있었고, 풀어서 쓰자면

1
2
3

def g[A : B](a: A)
// is equivelent to
def g[A](a: A)(implicit ev: B[A])

처럼 맥락에 해당하는 묵시적 변수를 implicit으로 표기했는데 이제는 모든 묵시적 행동에 쓰이던 implicit이라는 키워드가 사라지고 이런 용도로는 using으로 쓴다. 그리고 using에서 자동으로 가져오기 위한 변수를 선언하는 키워드는 given이 되었다.

1
2
3
4
5

object Ordering:
  given IntOrd: Ordering[Int] with
    def compare(x: Int, y: Int) = ...
  given Ordering[Double] with
    def compare(x: Double, y: Double) = ...

이렇게 해당 given에 이름을 붙일 수도 생략할 수도 있고, given intOrdering: Ordering[Int] = IntOdering처럼 given이 아닌 변수지만 메소드를 제공한다면 given 변수에 할당해서 사용할 수도 있다.

또한 implicitly라고 문맥상 스코프에 존재하는 묵시적인 변수를 가져오는 함수는 이제 summon으로 쓴다. summon[Ordering[Int]]처럼 부르는데, 이것도 implicitly처럼 미리 선언된 함수이다.

given의 경우 다음과 같은 방식으로 가져올 수 있다

• 이름: import Ordering.Int
• 타입: import Ordering.{given Ordering[Int]}
• 타입*: import Ordering.{given Ordering[?]}
• 전부: import Ordering.given

T 타입의 given은 다음과 같은 순서로 찾는다

1. 접근할 수 있는 given 인스턴스들

• 상속받았거나 import했거나 스코프 안에서 정의된 변수들

2. T와 관련된 컴패니언 객체를 통해서

• ‘관련된’의 의미는
  • T 자체의 컴패니언 객체
  • T가 상속하는 타입들의 컴패니언 객체
  • T에 있는 타입 인자들의 컴패니언 객체
  • T가 inner class라면 바깥쪽 스코프의 객체

given a: A가 given b: B보다 더 구체적이다, 라는 말은

• a가 b보다 가까운 스코프에 있다
• b가 정의된 클래스의 스버클래스 안에. a가 있다
• a가 b의 서브타입이다
• A 타입이 B 타입보다 더 “고정된” 부분이 있다.
  • Ordering[Int]가 Ordering[?]보다 더 고정되어 있다.

유용한 내용

sbt에 대한 설명은 아주 기본적인 것이나 아주 깊은 내용 아니면 찾기 어려워서 기본적으로 내부에서 사용하는 개념에 대해 정리된 자료를 찾기 힘든데, 3주차의 “sbt, Keys, and Scopes” 챕터에서 sbt 내에서 쓰이는 중요한 개념인 Key와 Task, 그리고 Scope에 대해 잘 설명해준다.

1. PV

• Best Session: 393 (6/15)
  • 관련글
    • Spark로 빅데이터 입문, 1-2주차 노트 - 6/10
    • Spark로 빅데이터 입문, 3주차 노트 - 6/14
  • edX의 Introduction to Big Data with Apache Spark를 들으면서 정리한 노트인데, 내 트위터에 바로 공유했던 1-2주차는 전혀 관심을 받지 못했고, 3주차를 쓰고 하루 뒤에 관련 그룹(페이스북의 스사모 (한국 스파크 사용자 모임))에 글을 올리고 나서야 PV가 생겼다.
• Best PV: 601 (8/5)
  • 관련글
    • WTF - 1. 시작 - 8/4
  • 글 4개 시리즈를 동시에 올렸더니 고유 접속자(DAU)는 낮아도 PV가 높게 나왔다.

두 시리즈의 공통점은 유의미한 피드백이 전혀 없었다는 점.

2. Top 7

왜 7이냐면 Top Page(/)와 블로그 메인(/blog)과 광고 페이지를 제외하니 첫 페이지에서 7개가 남아서.

1. underscore.js로 편해지자
2. Spark로 빅데이터 입문, 1-2주차 노트
3. 책 후기, Programming in Scala 2nd
4. Callback에서 Future로(그리고 Functor, Monad)
5. WTF - 1. 시작
6. 커피스크립트를 쓰면 좋은 10가지 이유
7. Spark로 빅데이터 입문, 3주차 노트

3. Referrer

역시 구글 검색이 제일 많고, 두번째는 직접 방문, 세번째는 광고라 필터링했고 네번째는 트위터 공유. 그리고readtrend에서 공유된 글은 시간이 지나도 방문자가 꾸준히 들어오는게 신기하다. 페이스북은 어디서공유되었는지 알 길이 없어서 막을 수 있으면 막고 싶지만 방법이 있어도 귀찮아서 안할 것 같다.

time travel debugger

요새 react-hot-loader를 통해 hot swap(코드 수정 후 현재 상태까지 다시 컨트롤하지않고 그 상태로 바로 반영하는 것)이 가능하다고 사람들이 환호했는데, 그 이전에Clojurescript의 Leiningen plugin으로 lein-figwheel이 있었다.

하지만 여기에서 조금 더 발전한 time travel debugger가 이미 있었다.자세한 내용은 당시 Hacker News의 코멘트를 참고.

이게 가능한 것은 Elm의 runtime에 Signal이라는 흐름 위에서 돌아가도록설계되어있어서 그런 것이라 추정한다. (아직 뜯어보지 않았다.)

blazing fast

vDOM/react의 구현체 속도 벤치마크가 유행했던 적이 있는데 거기에서 뜬금없이등장한 적이 있다. 홈페이지에도 자랑이 올라와있는데 벤치마크 결과는다음과 같다. 참고로 Om은 Clojurescript의 React 구현체다.

tutorial

공식 홈페이지에도 문서화나 예제가 잘 되어있긴 하지만 단계별로 따라갈만한 과정은아직 없다. 그래서 검색하다가 유튜브의 Elm Tutorial을 발견했는데,문제는 이게 0.12 기준이라 현재(0.15.1)와 맞지 않다. 그래도 유일하게 존재하는튜토리얼이라 공식 문서를 검색해가며 따라해봤고, 단계별로 소스를정리해봤지만 실시간으로 저장하며 따라한 것이라 따라가기 벅찰 때는갑자기 단계가 휙 뛸 수도 있다. (그러므로 언제든 더 좋은 정리를 PR로!)

이 튜토리얼을 끝내고 얼마 뒤 유료로 Elm: Building Reactive Web Apps라는유료 강의가 올라왔는데, 들어보지않아서 어떤 강의인지는 잘 모르겠다.

other drugs

• Functional Programming
  • 시카고대에서 올해 초 겨울학기 강의를 Elm으로 진행했다. 조만간 읽을 예정.
  • 0.14 기준이라 Mailbox와 Task 대신 Channel이 있어서 지금 그대로따라하기는 어렵다.
• Learning FP the hard way: Experiences on the Elm language
  • Gist에 한페이지짜리 함수형 프로그래밍 소개글이 있지만 이것만으로 이해하기는어려워보인다.
• Shipping a Production Web App in Elm
  • Dreamwriter라는 in-browser editor가 원래 React/Flux + CoffeeScript로만들어졌는데, 속도와 관리 때문에 Elm으로 넘어간 이야기.
• Using Mailboxes in Elm
  • Actor Model처럼 Mailbox라는 개념을 통해서 Message를 보내는데 문서가 부족해서누가 대신 쓴 글
• Similar libraries which were inspired by RxJS: Elm
  • rx-book의 한 챕터에 링크를 정리해놨는데 어떤 Elm 커뮤니티보다 잘해놨다.
• Seven More Languages in Seven Weeks
  • "You’ll learn seven exciting languages: Lua, Factor, Elixir, Elm, Julia, MiniKanren, and Idris."
  • 유일하게 Elm을 언급한 책인데 전작인 세븐 랭귀지처럼 번역될 것 같아서 일단 기다리는 중.

간단하게 링크만 올릴 예정이었는데 쓰다보니 아직 제대로 이해하지 못한 불필요한설명이 길어졌다. 하지만 아까워서 삭제하지 않고 그냥 발행.

What is the Functional?

1. Introduction
2. Algebraic Data Type
3. Maybe or Not
4. Monadic Molecule Parser

Codewars에 분자식(문자열)에서 원자들이 몇 개인지 세는 문제가 있었다. 이미제출한 답은 다음과 같은 구조였다.

1
2
3
4
5
6
7
8
9
10

const token = (str) => str.match(regToken);
const lexer = (arr) => arr.reduce((r,t) => ..., [])
const parse = (form) => {
  const syms = lexer(token(formula));
  let offset = 0;
  let buffer = traverse();
  return evaluate(buffer);

  function evaluate(array) {...}
}

옛날에 컴파일러 수업을 들었던 게 대충 생각나서 그래도 tokenizer로 식을 token단위로 끊고, lexer로 symbol로 만들고(원래는 scan할 때 한 번에 하는 작업이었던것으로 기억하지만), parse에서 Parse Tree를 만들어서 evaluator에서실행(계산)하도록 만들려고 짜다가 구현을 할수록 구조는 복잡해지는데 비해 난이도는올라가서 그냥 뒷부분은 한군데 섞어버렸다. 배운 걸 써먹기 위해서 이걸 다시Haskell로 도전해보았다. 일단 문제를 단순화시켜서 괄호 없는 분자식을 구현해보자.규칙은 다음과 같다.

1. 원소기호는 대분자와 소문자, 혹은 대문자로 이루어진다.
2. 개수는 원소기호 뒤에 오는 0자리 이상의 숫자로 없다면 1이 된다.
3. 원소기호와 개수를 합쳐서 동원소분자(homoatomic; 물론 제대로 된 명칭인지는모름)라고 부른다.
4. 분자식은 동원소분자가 1개 이상 이어진다.

BNF라는 명칭만 기억나고 정확한 내용은 기억나지 않지만 비슷하게 옮겨보자면

• molecules = homoatomic | molecules
• homoatomic = atom amount | atom

이제 이걸 적용할 수 있는 파서를 만들어보자. 일단 파서의 적절한 타입을만들어야 하는데, 함수형에서는 어떤 흐름을 기록하는데 자주 쓰이는State라는패턴이 있다. 모양은 대충 type State s a = s -> (a, s)가 된다. 즉, 현재의 어떤상태s에서 그 상태에서 원하는 결과 a와 다음 상태s를 동시에 가져오게 된다.상태는 변이(tramsform)되지만 원하는 값을 얻으면서 변수의 불변성(immutability)도만족해서, 메모리만 충분하다면 구조에 따라 상태 변이를 기록할 수 있어서 추적하기쉽다는 장점이 있다. 다시 돌아와서, State처럼 파싱할 문자열을 받아서 어떤 연산을규칙에 맞는 결과물 T를 가져온 뒤 남은 문자열과 함께 돌려주는 일종의 State같은타입을 Parser라고 정의해서 사용할 것이다.

1

// type Parser[T] = String -> (T, String)

먼저 앞에서 구현했던 것처럼 token을 가져오는 Parser를 만들어보자. Haskell의경우에는 강한 타입에다 패턴 매칭을 지원하는 언어라서 원하는 타입이나 원하는형태가 아니면 실패했다고 돌려줄 수 있지만, JavaScript는 둘 다 지원되지 않아서내가 원하는 것이 맞는지 글자를 소모하지 않고 확인할 수 있는 기능과 글자를소모해서 원하는 것인지 확인하는 기능 두 가지를 통해 tokenizer를 구현할 수 있다.

1
2
3
4

///// Parser => Parser
const ahead   = p => (str) => p(str) ? ['', str] : [];
///// Parser => Parser
const satisfy = p => (str) => p(str) ? [str[0], str.substr(1)] : [];

실패[]의 경우는 같고, 성공할 경우에 ahead는 아무것도 매칭하지 않은 채원래의 문자열str을 돌려주고, satisfy의 경우 매칭된 글자와 나머지 문자열을돌려준다. 원래는 튜플(Tuple)로 구현하는 게 좋지만, JavaScript에 그런 게있을 리가.

이제 다음 글자가 대문자라는 파서를 만들려면 다음과 같이 만들면 된다.

1
2
3

const upper = satisfy(ch => 'A' <= ch[0] && ch[0] <= 'Z');

console.log( upper("H") ); // [ 'H', '' ]

하지만 타입 확인도 패턴 매칭도 존재하지 않아서 적절한 입력인지 확인할 수 있는규칙과 그것을 합성할 수 있는 기능이 필요하다. 물론 합성 기능은 다음 글자가소문자라는 파서를 만들었을 때 그 파서와 합성하는 데 사용할 수도 있다.

1
2
3
4
5
6
7
8

// (Parser, Parser) -> Parser
const and = (pa, pb) => (str) => {
  const ra = pa(str);
  if(ra.length === 0) return [];
  const rb = pb(ra[1]);
  if(rb.length === 0) return [];
  return [ra[0] + rb[0], rb[1]];
};

이제 첫 번째 파서가 성공할 경우 [match1, rest1]를 받아서 rest1을 다음 파서에넘겨서 [match2, rest2]를 가져온 뒤에 [match1 + match2, rest2]라는 결과를만들어주는 파서를 생성할 수 있게 되었다. 물론 둘 중 하나라도 실패하면 실패[]가리턴된다. 이걸 사용해서 소문자 확인과 결합해보자.

1
2
3

const lower = satisfy(ch => 'a' <= ch[0] && ch[0] <= 'z');

console.log(and(upper, lower)("Mg")); // [ 'Mg', '' ]

그리고 앞서 만들어놓은 ahead와 더불어 원하는 조건인지 확인을 합성할 수도 있다.

1
2
3
4
5

const chr   = ahead(str => str.length > 0);

const upper = and(chr, satisfy(ch => 'A' <= ch[0] && ch[0] <= 'Z'));
const lower = and(chr, satisfy(ch => 'a' <= ch[0] && ch[0] <= 'z'));
const digit = and(chr, satisfy(ch => '0' <= ch[0] && ch[0] <= '9'));

다음 글자가 존재하는지, 존재할 때 원하는 범위의 글자가 맞는지를 한 번에 확인할수 있는 파서들이 만들어졌다. 이제 원소기호를 파싱할 때 대문자와 소문자가연속으로 올 때도 있지만, 대문자만 존재할 수 있으니 or를 만들어보자.

1
2
3
4
5
6

///// (Parser, Parser) -> Parser
const or = (pa, pb) => (str) => {
  const r = pa(str);
  if(r.length > 0) return r;
  else             return pb(str);
};

and처럼 파서 두 개를 받아서 새로운 파서를 만들어주는데, 차이는 첫 번째 파서가실패하면 바로 실패했다는 결과를 넘겨주고 뒤의 규칙은 확인하지 않으며, 두 번째파서가 실패할 경우에는 그 자체가 실패의 결괏값이므로 그냥 넘겨주면 된다. 이걸로원소기호를 가져와 보자.

1
2
3
4

const atom   = or(and(upper, lower), upper);

console.log(atom("Mg")); // [ 'Mg', '' ]
console.log(atom("H"));  // [ 'H', '' ]

이제 둘 다 만족하게 되었다. 그럼 다음은 숫자를 0개 이상 받을 때인데, 재귀적인규칙이라 앞에서 구현한 것들보다 약간 복잡해진다.

1

const amount = or(and(digit, amount), digit);

ES6에서 생긴 상수/변수인 const와 let은 호이스팅(hoisting)되지 않아서 이렇게만들면 작동하지 않는다. 그래서 함수가 실행된 뒤에 amount를 읽을 수 있도록소스가 약간 길어지지만 감수하면서 만들자면 다음과 같다.

1

const amount = (str) => or(and(digit, amount), digit)(str);

하지만 0개 이상을 읽는 경우가 이번뿐이 아니므로 이걸 좀 다듬어보자.

1
2

const many = (p) => (str) => or(and(p, many(p)), p)(str);
const amount = many(digit);

이제 many를 사용하면 나머지를 완성할 수 있다.

1
2

const homo   = or(and(atom, amount), atom);
const mole   = many(homo);

원소기호와 개수가 나오는 경우 혹은 원소기호만 있는 경우가 0번 이상 반복되는 것을분자식이라고 한다. 아예 받지 않거나 실패하는 경우에는 아무것도 출력하지 않도록결과를 다듬어보자.

1
2

const parse  = (p) => (str) => or(p, (str) => ['', str])(str)[0];
console.log(parse(mole)("H2O")); // H2O

이제 satisfy(ch=>ch=='(') 같은 식으로 열고 닫는 괄호를 3종류로 나누어서 규칙을만들고 and와 or로 잘 조합하면 원래 문제의 답을 얻을 수 있을 것이다. 맨 위에적어놓은 것보다 훨씬 깔끔한 구조로 함수들을 연결해서 답을 만들어냈다. 다만 현재JavaScript 엔진들은 스코프를 생성하는 비용이 비싸서 함수 호출이 많아질수록 꽤느려질 수 있다. 다만 불변성 구조가 유행하고 있고 엔진들도 최적화가 많이 진행되고있으므로 trade-off를 통해 성능은 비슷하지만 구조는 깔끔하게 만들 수 있지 않을까기대한다.

예전에 Rx, LINQ 등을 만든 에릭 마이어(Erik Meijer)가 edX에서 함수형 프로그래밍입문을 강의한다길래 반가운 마음에 들어봤는데, 이상한 아저씨가 이상한 배경에하이톤으로 함수형에 대해 역사부터 열심히 설명하길래 거기까지만 듣고 포기했던적이 있다. 이번에 읽은 책이 Haskell 자체보다는 함수형 개념에 관해 설명한 책이라Haskell로 문제를 풀어보면서 모르는 게 있어서 리뷰하려고 다시 들어봤더니 여전히그 배경은 적응이 안 되지만 그래도 친절하고 좋은 강의였다(참고로 아래의 Contents링크에 들어가면 화질별 강의와 슬라이드, 자막이 있다). 10월 15일에 다음 강의가열리는데, 함수형이나 Haskell 입문에 관심 있는 분들께는 시각적인 어려움을참작하고라도 매우 도움이 되는 강의니 추천한다.

ps, 구직중

Reference

• Monadic Parser Combinators - Graham Hutton, Erik Meijer

• Codewars

  • Molecule to atoms

• Hackage: Official Haskell Package archive

  • Text.ParserCombinators.ReadP

• Haskell/Wikibooks

  • Haskell/ParseExps

• FP101x

  • edX course 10/15~
  • Contents

What is the Functional?

1. Introduction
2. Algebraic Data Type
3. Maybe or Not
4. Monadic Molecule Parser

Maybe

바로 앞에서 언급했듯이 최근에 생겼거나 메이저 업데이트를 한 언어들이라면 대부분지원하는 Maybe(Optional, Option)라는 타입이 있다. 값을 가지고 있는 Just라는타입과 값이 없는 Nothing이라는 타입 중 하나가 되는 섬 타입이다. 일단 함수형이니하는 이야기는 잠시 미뤄두고 간단하게 Maybe를 만들어보자. Maybe의 정의를 간단하게표현해보자면 다음과 같다.

1

data Maybe a = Just a | Nothing

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

class Maybe {
  toString() { throw new Error("Must be implemented."); }
}

class Just extends Maybe {
  constructor(v) {
    super();
    this.value = v;
    Object.freeze(this);
  }
  toString() { return `Just ${this.value.toString()}`; }
}

class Nothing extends Maybe {
  constructor(v) {
    super();
    Object.freeze(this);
  }
  toString() { return "Nothing"; }
}

const nothing = new Nothing();

정의는 단순하지만 같은 내용을 JavaScript로 구현하면 다소 길어진다. 소스를 보면알겠지만, Just는 생성될 때만 값을 받을 수 있고 생성된 후에는 값을 변경할 수없다. 이제 이 Maybe를 어떻게 다룰지에 대해서 생각을 해보자. Maybe 타입을 통해어떤 연산을 하고 싶을 때 메소드를 추가해서 Maybe를 계속 생산하도록 만들면편하겠지만, 값이 있다 없다의 속성을 가질 수 있다면 Maybe의 연산 결과를 Maybe라고유지하고, 값이 없을 때는 계속 값이 없도록 유지하려면 그 결괏값을 보장해줘야한다.이걸 만족하는 연산들을 생각해보자.

1. 값을 Maybe로 감싸서 새로운 Maybe를 만들어준다.
2. Maybe의 값에 그 값을 처리하는 함수를 적용하고 싶다.
3. 그런데 그 함수가 Maybe의 값일 수도 있다.
4. 함수의 결괏값 자체가 Maybe라면 어떨까?

1번의 구현은 간단하다.

1
2

///// unit : a -> Maybe a
const unit = (x) => new Just(x)

값만 존재할 때는 두 배로 만들려면 단순히 x * 2를 하면 되지만, Maybe로 감싸져있으니 바로 적용하기 어렵다. 그러니 2번처럼 값을 처리하는 함수를 적용할 수 있는기능을 구현해보자.

1
2
3
4
5
6
7
8
9
10
11
12

const isNothing = (m) =>
  m.constructor.name === "Nothing"

///// fmap : Maybe a, (a -> b) -> Maybe b
const fmap = (m, fn) =>
  isNothing(m)
    ? new Nothing
    : new Just(fn(m.value))

const doub = (d) => d * 2
console.log( fmap(unit(1), doub).toString() ); // Just 2
console.log( fmap(nothing, doub).toString() ); // Nothing

Maybe의 값이 함수일 경우에 그 함수를 다른 Maybe의 값에 적용해보자.

1
2
3
4
5
6
7
8
9

///// appl : Maybe (a -> b), Maybe a -> Maybe b
const appl = (mfn, ma) =>
  isNothing(mfn) || isNothing(ma)
    ? new Nothing()
    : unit(mfn.value(ma.value))

const mdoub = unit(doub);
console.log( appl(mdoub, nothing).toString() ); // Nothing
console.log( appl(mdoub, unit(1)).toString() ); // Just 2

그런데 모양을 보면 fmap과 비슷해서 fmap을 재사용해서 구현할 수도 있다.

1
2
3
4
5
6
7

const appl2 = (mfn, ma) =>
  isNothing(mfn)
    ? new Nothing()
    : fmap(ma, mfn.value)

console.log( appl2(mdoub, nothing).toString() ); // Nothing
console.log( appl2(mdoub, unit(1)).toString() ); // Just 2

이제 마지막으로 함수의 결과 자체가 Maybe일 경우를 생각해보자.

1
2
3
4
5
6
7
8
9

///// bind :  Maybe a, (a -> Maybe b) -> Maybe b
const bind = (ma, fn) =>
  isNothing(ma)
    ? new Nothing()
    : fn(ma.value)

const udoub = (d) => unit(doub(d));             // a -> Maybe b
console.log( bind(nothing, udoub).toString() ); // Nothing
console.log( bind(unit(1), udoub).toString() ); // Just 2

지금까지의 구현에서 JavaScript 자체의 복잡한 기능을 사용한 곳은 없다. 구현자체가 어렵지도 않고 짧아서 여기까지는 다들 이해할 수 있을 것으로 생각한다.그런데 안에 값을 넣을 수 있는 타입 중에서 개발자들이 항상 사용하고 있으며,다들 사용법에 대해 아주 잘 알고 있는 타입이 하나 있다. 이제 Maybe를 Array와비교해보자.

F, A, M with Array

1. Functor

앞에서 구현했던 fmap에서 설명을 돕기 위해 구현 위에 주석으로 타입을 적어놓은것이 있다. 처음에는 Haskell 식으로 타입을 적었다가 이해하기 편하도록 수정했더니무슨 언어인지 모를 내용이 되긴 했지만.

1

///// fmap : Maybe a, (a -> b) -> Maybe b

값을 가지고 있는 타입과 값을 변환하는 함수를 받아서 다른 값을 가지고 있는타입으로 변환해준다. 이걸 이해하기 좋게 조금 수정해보자면,

1
2
3

///// amap : Array a, (a -> b) -> Array b
const amap = (arr, fn) => arr.map(fn);
console.log( amap([1,2,3], (n => String(n))) );  // [ '1', '2', '3' ]

a라는 타입의 값을 가지고 있는 어떤 타입을 ⓐ라고 하고, b의 경우를 ⓑ라고 하면,(a -> b) 함수를 통해 결과적으로 (ⓐ -> ⓑ)를 만족하도록 연산할 수 있는 타입을Functor라고 부른다. Array에서는 그런 연산을 해주는 map 메소드를 가지고 있다.

2. Applicative Functor

순서대로 fmap 다음에 구현했던 appl을 이야기할 차례다.

1

///// appl : Maybe (a -> b), Maybe a -> Maybe b

applicative라는 표현 그대로 어딘가에 적용할 수 있는 Functor이다. 즉, 함수를가지고 있는 Functor.

1
2
3
4
5
6
7
8
9

const doub = d => d * 2;
const incr = d => d + 1;

///// Array (a -> b), Array a -> Array b
const appl = (fns, as) => fns.map(fn => as.map(fn))
                             .reduce((r,b) => r.concat(b), [])
console.log(
  appl( [doub, incr], [1, 2, 3] )
); // [ 2, 4, 6, 2, 3, 4 ]

이렇게 (a -> b)를 가지고 있는 Array와 Array a를 통해 Array b를 만들었다. 위에서말했듯 함수를 가지고 있는 Functor(Array (a -> b))와 다른 Functor(Array a)를 통해다른 Functor(Array b)를 만들어내는 Applicative Functor를 map을 사용해서 간단히구현해보았다. 하지만 Applicative Functor 자체를 본 적이 별로 없어서 내가 맞게이해하고 있는 것인지 잘 모르겠다.

3. Monad

1

///// bind :  Maybe a, (a -> Maybe b) -> Maybe b

JavaScript에서는 lodash같은 라이브러리를 사용하지 않은사람에게 익숙하지 않은 개념일 수 있지만, 다른 함수형 언어들을 써본 사람이라면Sequence 종류에서 기본적으로 지원해주는 익숙한 개념이 있다.

1
2
3
4
5
6
7

const flatMap = function(fn) {
  return this.map(fn).reduce((r,a) => r.concat(a), [])
};

console.log(
  [1,2,3]::flatMap(d => Array(d).fill(d))
); // [ 1, 2, 2, 3, 3, 3 ]

바로 flatMap(간혹 concatMap)이라는 개념인데, (a -> ⓑ) 함수를 통해(ⓐ -> ⓑ)를 만족하는 함수를 말한다. [1, [2], [[3]]]처럼 깊이가 다른 배열을1차원으로 합치는 함수를 flatten이라고 표현하는데, flatten + map이 아닐까 싶다.Haskell에서는 Monad라면 Applicative Functor를 만족하고, Applicative Functor라면Functor를 만족한다. 즉 Monad > Applicative > Functor로 상속하는 구조다. 잠깐접해본 짧은 생각으로는 독립적인 개념으로 봐도 될 것 같은데(굳이 따지자면Functor와 Applicative 정도는 has-a로 봐도 될 것 같지만), 내가 놓치고 있는 뭔가가있는 것 같다.

이렇게 대수형 타입끼리 어떻게 연산하는지의 패턴들에 대해 알아봤는데, 왜 이렇게복잡한 설명과 패턴을 통해 타입을 유지해야 하는가 싶은 생각이 들 수 있다. 가장기본이 되는 개념은 간단한 개념이니 이것만 알면 된다! 라는 식의 글을 참 많이봤는데, 내가 원점에 있을 때 (10, 0)쯤에 있던 글보다 쉽다는 글은 (0, 10)쯤에있었고 그보다 쉽다고 주장하는 글은 (-10, 0)쯤에 있었다. 방향만 달라질 뿐, 거리는좁혀지지 않는 느낌이었다. 그래도 그나마 알아들을만 했던 예제는 Railway orientedProgramming이었다.

Just에 어떤 연산bind을 할 때 결과는 다시 Maybe가 되어야 하니 Just(그림에서의Success) 혹은 Nothing(그림에서의 Failure) 둘 중 하나가 된다.

그런 연산이 여러 개 존재할 수 있다.

그때, 앞에서 어떤 처리들이 있었고 어디에서 Nothing으로 갔는지 관계없이 현재들어온 값을 보고 Just인지 Nothing인지 구분(switch)해주는 하나의 블럭을 만들기만하면 된다.

한번 Nothing이 되면 그 뒤에 어떤 연산이 오든 관계없이 Nothing으로 계속유지된다. 앞의 어디에서 Nothing이 되었다는 것에 신경 쓰지 않고 현재의 값만 보고Just인지 Nothing인지 연결하면 된다. 즉, bind(혹은 flatMap)에서는 현재 값과앞뒤 타입만 맞추면 입력에서 출력까지 연산이 안전하다고 보장된다.

패턴이라는 것은 약속이고, 약속이라는 것은 그것이 보장된다는 말이다. 즉 일종의추상화로 블랙박스 모델처럼 그림에서의 스위치만 구현해서 레일을 연결하면 안전하게연산이 잘 흘러간다. OOP처럼 객체 단위의 추상화가 없으니 타입클래스에서 이런패턴들이 그 역할을 대신하고, 덕분에 재사용하기 좋고 확장 가능해진다. 그런 것들의기초가 되기 때문에 사람들이 중요하다고 많이 이야기하는 것이라고 생각한다.

여전히 이게 뭐다라고 정의내려서 설명하기는 어렵지만 이제 A가 B다라는 말에서 그게맞거나 틀리다는걸 구분할 수는 있는 것 같다. 사실 이 글을 쓰게 된 목적 중 하나는이거다. 그동안 함수형 언어를 기껏해야 퀴즈 몇개 풀어보는 정도 이외에는 제대로써본 적이 없다보니 알듯말듯 한 상태가 몇년째 계속되고 있는데, 최근에 Haskell 책한권을 읽으면서 그 감이 약간 더 구체화된 김에 정리를 해서 더 잡기 위해서다. 물론조금 어긋난 내용이 있을 수도 있고 아예 잘못된 내용이 있을 수 있어서 언젠가 이글을 읽고 이불킥할지도 모르겠지만, 이번 기회에 정리하지 않으면 몇년 더 이해할기회가 오지 않을 것같다는 느낌이 들었다. 그러니 틀린게 있으면 틀린거고, 아니면좋고. 이제 Monad라는게 뭔지 대충 정리를 해밨으니 이걸로 뭘 할 수 있는지 한번써먹어보자.

ps, 타입을 유지하기 위한 연산의 패턴들에 대해서 알아봤는데 이런 것들이 타입론(Type Theory)이나 범주론(Category Theory)에 속한 것이라면, "정수의 덧셈은 정수에'닫혀있다'"라고 말하는 것처럼 연산 자체의 성질에 대해서 논하는 군론(GroupTheory)라는 것이 있고 그 중 모노이드(Monoid)라는 개념을 모나드와 함께 사용하면더 편하게 사용할 수 있는데 그 부분에 대해서는 지금보다 아는 것이 좀 더 생기면다뤄보고 싶다.

ps2, 다시 말하지만 ps도 맞는지 확신이 없다.

Reference

• Hackage: Official Haskell Package archive

  • Control.Monad
  • Control.Applicative
  • GHC.Base | Source

• Codewars Kata

  • Monads: The Maybe Monad: Maybe = Just | Nothing

• Functors, Applicatives, And Monads In Pictures (번역)

• All Image Credit under CC BY 3.0by ScottWlaschin

  • from Railway oriented programming

What is the Functional?

1. Introduction
2. Algebraic Data Type
3. Maybe or Not
4. Monadic Molecule Parser

컴퓨터 프로그래밍에서, 특히 함수형 프로그래밍과 타입 이론에서 대수 자료형은합성 타입의 한 종류이며 즉, 다른 타입들을 모아서 형성된 타입이다. 제일 보편적인두 경우로는 프로덕트 타입(product type. 예를 들어 튜플과 레코드)과 섬 타입(sumtype. 혹은 Tagged Union이라 불린다)이 있다.(중략)대수 자료형의 값들을 패턴 매칭을 통해 분석해서 생성자나 필드 이름을 통해 값을알아내거나 내부의 값을 추출해낸다. 대수 자료형은 70년대 에든버러 대학에서 개발한작은 함수형 언어인 Hope에서 소개됐다.

Algebraic data type - Wikipedia

프로덕트 타입은 여러 타입을 한 번에 쓸 수 있는 구조(튜플의 경우 (A, B), 레코드의경우 {A: B}같은 형식)이며 섬 타입은 열거형(Union) 비슷한 이름을 갖는 것에서도추정할 수 있듯 여러 타입 중 하나를 쓸 수 있는 구조다. 여러 언어에서 예전부터혹은 최근에 도입된 자료형 중에서 Maybe, Option, Optional 등의 이름으로 값을갖거나(Just) 혹은 값이 없거나(Nothing, None, Null)로 구분되는 자료형이 가장익숙하지 않을까 싶다. 설명을 하다 보니 OOP에서 추상 클래스와 상속받은 클래스들간메소드 오버로딩을 통한 다형성과 비슷한 느낌이 든다.

위키피디아의 내용처럼 패턴 매칭에서 주로 사용되는데 패턴 매칭을 지원하지 않는JavaScript에서는 적용할 수 없는 개념이고 제대로 사용할 수 없으므로 이해하기어려운 개념이기도 하다. 그런데 굳이 처음부터 잘 이해하고 갈 필요가 있나? 그냥어떤 것인지 알아보고 JavaScript로 한번 구현해보면 제대로는 아니어도 어떤 것인지정도는 감을 잡을 수 있을 것이다.

대수적 자료형의 재미있는 점은 재귀적 구조와 지연 평가(Lazy Evaluation)을 통해무한의 자료형이 가능하다는 점인데, Codewars에서 Nat(0 이상의 정수)과 Cons를JavaScript로 구현하는 문제가 있다.

Nat

1

data Nat = Zero | Succ Nat

Haskell에서 대수 자료형 Nat을 정의해보았다. 코드를 정확히 이해할 필요는 없고,Zero라는 0에 해당하는 값과 Nat을 인자로 받아 그다음 값을 갖는 Succ의 두가지경우가 될 수 있는 Nat이라는 섬 타입이다. 문제에서는 Zero와 Succ에 대해서정확히 같지는 않지만, 다음과 비슷하게 주어진다.

1
2

const zero = () => {};
const succ = (nat) => ( ()=>nat );

zero는 일종의 상수고, succ는 nat을 리턴하는 함수를 리턴한다. 즉, 패턴 매칭을통해 Succ에서 받은 이전 값을 다시 추출하는 과정을 함수 호출로 대신했다. 패턴매칭을 통해 Nat을 정숫값으로 변환하는 과정도 JavaScript로 대신해보자.

1
2
3

toInt :: Nat -> Int
toInt Zero = 0
toInt (Succ nat) = 1 + toInt nat

인자로 Zero를 받을 경우에는 당연히 0이 되고, Succ를 받았을 경우에 Succ를생성할 때 받았던 이전 값 nat을 패턴 매칭을 통해 추출해서 다시 toInt로 넘겨서Nat은 하나씩 이전값을 보고 Zero가 나올 때까지 결괏값을 하나씩 증가시킨다.

1

toInt (Succ (Succ (Succ Zero)))

이렇게 0의 세 번째 다음 값을 정수로 변환한다면 그 과정을 간단히 표현해서1 + (1 + (1 + 0)이 되고 3을 리턴하게 된다. 그렇다면 이걸 JavaScript로구현하면

1
2
3
4
5
6

const toInt = (nat) =>
  nat === zero
    ? 0
    : 1 + toInt(nat())

console.log(toInt(succ(succ(succ(zero))))); // 3

이런 식으로 재귀를 통해 구현할 수 있다. 혹은 앞에서 언급했던 트램펄린과 비슷하게

1
2
3
4
5
6
7

const toInt = (nat) => {
  let count = 0;
  for(; nat !== zero ; nat = nat(), count++);
  return count;
}

console.log(toInt(succ(succ(succ(zero))))); // 3

구현할 수도 있다. succ와 zero의 의미, 그리고 어떻게 다루어야하는지 방법을알았으니 나머지 인터페이스는 쉽게 구현할 수 있다.

Cons

Codewars에 대수 자료형을 다룬 문제가 하나 더 있다. Nat처럼 재귀적인 구조로 아주비슷한 Cons라는 구조다. 많은 언어에서 List 혹은 Sequence라는 이름으로 구현체를제공하는 유명한 자료형이다.

1
2

data List a = Cons { head :: a , tail :: List a}
            | Nil

List는 Cons 혹은 Nil이 될 수 있는 섬 타입이다. 그리고 Cons는 다시 a타입의 head와 List a 타입의 tail로 이루어진다. 위에서 말했듯이 Nat와유사한 모양의 재귀적인 구조다. 참고로 head와 tail은 Cons 구조에서 일반적으로쓰이는 이름이지만 언어에 따라서 car과 cdr로표현하기도 한다. 또한, List와 Array를 모두 제공하는 언어나 라이브러리에서는 보통C언어에서처럼 고정된 길이의 index를 가지는 배열을 Array(혹은 Vector)라고 부르고앞서 말했듯 이런 Cons 구조를 List(Sequence)라고 부르는 경우가 많다.

1
2
3
4
5
6
7

function Cons(head, tail) {
  this.head = head;
  this.tail = tail;
}
const Nil = new Cons(null, ()=> {
  throw new Error('Empty!');
});

문제를 다른 사람이 낸 것인지 앞에서는 함수 호출을 통해 지연 평가를 비슷하게구현했는데 이번에는 간단하게 속성(property)으로만 구현해서 제공된다. 앞에서의Nat과 비슷한 정수의 스트림을 구현해보면

1
2
3

int :: Int -> List Int
int n = Cons n tail
  where tail = int (n + 1)

이런 식이 된다. tail을 바로 평가하지 않기 때문에 int 0으로 List를 만들어도바로 Cons 0 tail을 만들 뿐 무한루프를 돌지 않는다. JavaScript에서 비슷하게만들어보자면

1
2
3
4

const int = (n) => new Cons(n, ()=>int(n+1))

int(0)        // { head: 0, tail: [Function] }
int(0).tail() // { head: 1, tail: [Function] }

이렇게 계속 tail을 실행할 때마다 다음 Cons를 생성해서 지연 평가를 구현했다.사실 링크의 문제에서는 지연 평가에 대한 내용이 없어서 굳이 이렇게까지 할 필요는없지만, 문제풀이가 목적이 아니니. 그럼 언어가 제공하는 List에서 앞서 정의한List(Cons|Nil)로 변환을 통해 Cons를 생성할 수 있도록 해보자.

1
2
3

fromArray :: [a] -> List a
fromArray [] = Nil
fromArray (x:xs) = Cons x (fromArray xs)

x:xs는 Cons의 x가 head고 xs가 tail이며 두 개를 연결해서 하나의 Cons를만든다는 연산자 :이다. 참고로 ++의 경우 두 개의 Cons를 연결(concat)한다.이걸 또 JavaScript로 구현해보면 다음과 같다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

const fromArray = (arr = []) => {
  if(arr.length === 0) return Nil;
  else return new Cons(arr.shift(), ()=>fromArray(arr.slice()));
}

let cons = fromArray([1, 2]);
console.log(cons); // { head: 1, tail: [Function] }
cons = cons.tail();
console.log(cons); // { head: 2, tail: [Function] }
cons = cons.tail();
console.log(cons, cons === Nil); // { head: null, tail: [Function] } true
cons = cons.tail();
//   throw new Error('Empty!');
//         ^
// Error: Empty!

이제 Sequence 타입에 항상 적용해보는 filter와 map을 구현해보자

1
2
3
4
5
6
7
8
9
10

filter' :: (a -> Bool) -> List a -> List a
filter' f Nil = Nil
filter' f (Cons x xs)
  | f x       = Cons x (filter' f xs)
  | otherwise = (filter' f xs)


map' :: (a -> b) -> List a -> List b
map' f Nil = Nil
map' f (Cons x xs) = Cons (f x) (map' f xs)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

const filter = (f, cons) => {
  if(cons === Nil) return Nil;
  else if(!f(cons.head)) return filter(f, cons.tail());
  else return new Cons(cons.head, ()=>filter(f, cons.tail()));
}

const map = (f, cons) => {
  if(cons === Nil) return Nil;
  else return new Cons(f(cons.head), ()=>map(f, cons.tail()));
}

const prt = (cons) => {
  while(cons !== Nil) {
    console.log(cons.head);
    cons = cons.tail();
  }
}

출력이 귀찮아서 prt 함수를 따로 만들었다. 이제 확인을 해보면

1
2
3
4
5
6
7
8
9
10
11
12
13

const even = (d) => d % 2 === 0;
const doub = (d) => d * 2;
const toFive = fromArray([1,2,3,4,5]);

prt(filter(even, toFive));
// 2
// 4
prt(map(doub, toFive));
// 2
// 4
// 6
// 8
// 10

이제 재귀적인 구조를 다룰 때 어떻게 실행되는지에 대해 안에서 어떻게 돌아갈지를간단하게 구현해봤는데 적당히 감이 왔을 것이다. 여기에서 약간의 스킬을 더해서window.setImmediate나 process.nextTick으로 스레드 점유를 살짝 연기시키면충분히 큰 자료도 시간만 있으면 다룰 수 있을 것이다. JavaScript에서 map과filter를 어떻게 쓰는지 모르는 사람은 거의 없을 것이고 Cons에서 구현한 것들도배열에서 쓰이는 것과 큰 차이가 없었다. 다음에는 이걸 대수적으로 해석할 때의의미와 그걸 지원하는 구조에 대한 명칭을 이야기할 것이다.

Reference

• Codewars Kata
  • Algebraic Data Types: Nat = Zero | Succ Nat
  • Algebraic List: List a = Cons {a, List a} | Nil
• 함수프로그래밍 실천기술(가칭), 제이펍 2015

What is the Functional?

1. Introduction
2. Algebraic Data Type
3. Maybe or Not
4. Monadic Molecule Parser

얼마 전에 지인과 맥주 한잔을 하다가 iOS 개발을 Swift로 하고 있다 보니 함수형으로못 쓰는 것도 아닌데 같이 일하는 사람들이 배울 생각이 없어서 도입하기 어렵다는말을 들었다. 요즘 여기저기에서 폴리글랏이니 병렬처리니 하는 말과 함께 함수형패러다임이 무엇인지 어디에 좋다는지 하는 설명은 많이 들려오고 있어 관심이있는 사람은 많지만, 그래서 그걸 구체적으로 어디에 어떻게 쓰이는지에 대해 잘몰라 동기부여가 되지 않는 사람들이 많다. 나도 입문 단계를 아직 벗어나지못했다고 생각해서 앞으로 쓸 글에 잘못된 점이 있을 수도 있지만Codewars의 문제몇 개를 풀어보면서 이게 어떤 모습인지, 어떻게 쓰이는지 한번 써볼까 한다(그러니이상하거나 틀린 점을 발견한다면 이슈에남겨주길 바란다) . 사실 개발자가 뭔가를 배우는 데는 생업에 관련된 게큰 이유겠지만 가장 좋은 동기부여는 역시 재미가 아닐까 싶다. 이걸 보고 뭔가재미있게 쓰인다고 느끼고 서점가서 책이라도 한번 펼쳐보는 사람이 생긴다면 이글의 목표는 성공한 것이다.

시작하기에 앞서서 앞으로 관심을 가질 사람들에게 가장 도움이 될만한 것은 내가어떤 책을 읽고 어떻게 공부해왔는지부터 말하는 것이 아닐까. 예전의PiS 리뷰에서 썼듯이처음에 재미를 느끼고 뭔가 해보기 시작한 것은 자바 개발자를 위한 함수형프로그래밍과함수형 자바스크립트에서다. 함수형 언어라고 불리는 것들을 배우면 함수형 사고에 큰 도움이 되지만처음부터 너무 큰 벽을 넘으려고 하면 지치기 쉽다. 그런 의미에서 지금 가장 익숙한언어가 적당히 함수형을 쓸 수 있도록 지원한다면 그걸로 먼저 조금씩 사고를 익히는것이 좋다. JavaScript도 좋고 Java 8도 충분하고 Swift라면 훌륭하다.

이미 많은 사람이 알고 있지만 그래도 가장 먼저 익숙해지면 좋은 개념은 함수를자료형으로 생각하는 것이다. First-class function이니 Higher-order function이라는개념들이 있지만 결국 함수도 하나의 자료형이라는 개념에 조건을 붙인 것이다.함수(혹은 메소드)에서 정적인 자료를 넘기는 것에 익숙한 사람들이 가장 이질적으로느끼는 것이 이런 것으로 생각한다. 함수를 넘기고 함수를 만들어서 리턴하고,함수끼리 연산해서 새로운 함수를 만들고. 함수형 자바스크립트라는 책에서 독자에게훈련시키는 이런 것이 아닐까 싶다. 그럼 익숙한 것부터 시작해보자.

1
2
3
4

var count = 0;
try{ (function a(){ count++; return a(); })(); }
catch(e) { console.log(e.message, count); }
// Maximum call stack size exceeded 17926

JavaScript로 코딩하다 보면 재귀함수에서 로직을 잘못 짜거나 생각했던 범위를 훨씬넘는 값을 받았을 때 저런 문제가 발생한다. 대부분은 이미 아는 내용이겠지만 잠시다른 이야기를 해보자면, 기계는 코드를 한 줄씩 읽어서 해석하다가 어딘가로넘어가게 될 때(CALL), 현재 가지고 있는 값들을 어딘가에 저장해두고 다시 돌아올위치를 기록한 다음에 넘어가게 된다. 그래서 어딘가로 계속 넘어가다 보면 기계의물리적 혹은 논리적인 한계 때문에 실행환경에서 익셉션을 발생시키거나 프로세스가강제로 종료된다. 많은 언어에서는 꼬리 재귀 최적화(Tail Recursion Optimization)혹은 꼬리 호출 제거(Tail-call Elimination)라고 불리는 기능을 지원하는데,어딘가(A)로 한번 넘어갔을 때 거기에서 다시 어딘가(B)로 넘어갈 때 A에서의 상태를굳이 저장하지 않아도 된다면 돌아올 곳은 똑같으니 현재 값들을 저장하고 돌아올곳을 기록하는 작업을 생략한 채 그냥 B로 넘어가는 식(JMP)으로 최적화가 가능하다.

그렇다면 JavaScript에서는 언어적인 한계 때문에 충분한 시간이 있어도 충분히 많은재귀를 할 수 없을까? JavaScript에서도 어떤 패턴을 통해 콜스택을 일정하게 유지할수 있다(하지만 아마 다소 메모리의 증가는 생길 것이다). 간단한 예를 들어서 다음과같은 피보나치 수열이 있다고 해보자.

1
2
3
4

const fibo = (n) =>
  n < 3
    ? 1
    : fibo(n-1) + fibo(n-2);

위에서 말했듯이 저장할 상태가 없어야하는데 양쪽으로 재귀를 돌다 보니 하나를 돌때다른 하나를 저장하고 있어야 한다. 그러니 구조를 약간 바꾸어보자.

1
2
3
4
5
6
7

const f = (a, b, n) =>
  n < 2
    ? a
    : f(b, a+b, n-1);


const fibo2 = (n) => f(1, 1, n);

인자가 많이 늘어났지만 저장해야하는 상태없이 다음 재귀로 넘어갈 수 있게 되었다.이제 콜 스택의 깊이를 유지하려면 함수를 재귀적으로 실행시키지 않고 실행하고끝난 뒤에 다시 실행하도록 순서를 변경하면 된다.

1
2
3
4
5
6
7
8
9
10

const f2 = (a, b, n) =>
  n < 2
    ? a
    : () => f2(b, a+b, n-1)

const fibo3 = (n) => {
  let t = () => f2(1, 1, n);
  while(typeof (t = t()) === 'function');
  return t;
}

다음 실행될 재귀를 함수로 감싸서 리턴하면 한번에 하나씩 실행이 되며, 함수가 아닌값을 받았을 때 재귀를 대신한 루프가 종료된다. 이해하기 편하도록 원형fibo2을최대한 유지해서 fibo3를 작성했고, 이걸 일반화시킨 패턴을 트램펄린(trampoline)이라고 부른다. 사실 트램펄린 자체는 함수형 패턴의 예시라기보다 CPS(Continuationpassing style)의 예라고 설명하는 쪽이 더 적절하다. 다만 이 패턴이 재미있는 것은JavaScript에서 지원하지 않는 꼬리 재귀 최적화와 지연평가의 개념, 그리고 우회구현이 동시에 들어있기 때문에 언어의 한계를 기술적으로 우회한다는 점에서, 그리고그 기반에 대한 개념이 함수형과 맞닿아있다는 점에서 예시로 가져왔다. 함수형자바스크립트 책을 처음 읽었을 때 이해하기 어려워서 미뤄뒀는데 계속 함수형처럼코딩하려고 노력하다 나중에 다시 읽으니 그 전에 왜 이해하지 못했나 싶었다. 아마위에서 언급했던 것처럼 자료형처럼 넘기고 받는다는 생각에 이질감이 들어서였을까.

Reference

• Continuation-passing and tail call elimination in Javascript
• 예제로 설명하는 자바스크립트에서의 Continuation-passing style
• 함수형 자바스크립트, 한빛미디어 2014

슬랙이라는 메시징 앱이 있는데 이 앱이 유행하면서 아직채팅 공간이 없는 커뮤니티들은 IRC 대신 슬랙을 사용하고 있고, 그래서 이것저것추가를 하다 보니 10개를 넘어갔다가 다시 추려서 7개만 남았는데, 그중에서 가장오랜 시간을 보고 있고, 계속 1번에 위치했던 이상한 모임 팀에질문이 올라왔다. (슬랙은 업무용 툴이라 하나의 단위가 팀이다. 사실 이 글이 중복게시되는 메타블로그를 통해 보는 사람이 대다수라 부연설명이 필요 없을 수도 있지만,혹시 모르는 분들이 있을까봐 남겨봤다. )

"Lazy evaluation를 뭐라고 번역해야 좋을까요?"

한국어 위키에 "느긋한 계산법"이라고되어있다며 질문이 올라왔고 질문한 분은 "이따 평가"라는 제안을 했고 나는"지연평가가 가장 흔한 번역같습니다."라고 대답했다.

필요해질 때까지 평가를 미뤄둔다는 의미에서 Lazy의 번역으로 '지연'이라는 표현을많이 사용하는데, 지연이라는 말에 타의적 혹은 일정 시간이라는 정적인 뉘앙스가있다고 생각해서 원래 의미가 살지 못해서 좋은 번역은 아니라고 생각한다. 다만,그 번역을 들었을만한 사람(특히 개발자)들은 대부분 "Lazy Evaluation"이라는 원문과동시에 그 원문의 뜻을 같이 떠올릴 수 있을 것이다. 좋은 번역은 아니지만, 대부분은뉘앙스를 알 수 있다는 의미로 나는 "합의된 번역"이라고 표현한다.

도입에서 말한 언어의 사회성이라는 것은 번역어에도 적용된다. 하지만 언어끼리의1:1 매칭이 되는 표현은 거의 존재하지 않는다는 특수성 때문에 번역어에서의 사회성은언어의 사회성과 다소 차이가 있다. 자연스럽게 시간이 흐르면서 생기는 사회적 합의없이, 이미 존재하는 언어의 이미 존재하는 표현을 갑자기 다른 언어의 다른 표현으로옮기는 것에는 사회성이 존재하기 어렵다. 그래서 많은 번역어가 사회적 합의 없이생겨나고 생긴 뒤에서야 사람들이 그 표현에 익숙해지는 후불제 합의에 가깝다.그래서 어떤 분야를 맨 처음 번역하는 사람들의 역할이 중요하다. 처음 시도했던번역어가 후세에도 많은 영향을 끼치기 마련이고, 그 영향을 벗어나 새로운 합의를만들어내기까지 오랜 시간과 노력이 필요하기 때문이다. 그 시간과 노력을 투자하는사람은 언어 자체를 공부하는 사람이 될 수도 있고, 또 다른 번역자일 수도 있다.하지만 누군가의 주도 하에 결정되기보다 사회적 합의를 이루기 위해 커뮤니티의주도로 이루어졌으면 좋겠다는 생각을 한다. 페이스북의 개발자영어라는그룹에서 종종 그런 글들이 올라온다. 이런 말은 보통 이렇게 번역하는데 더 좋은표현이 없을까 하는 질문글. 저 그룹이 어떤 권위나 영향력이 있지는 않지만, 합의를위해 토론이 이루어지는 (내가 아는 한에서)유일한 커뮤니티이다.

이 생각을 맨 처음 했던 것은 얼마 전에 읽었던 책 때문이다. 유명한 역자분이번역했고, 역자 서문에서부터 현재의 (합의된)번역어보다 더 어울리는 말을 찾기 위해많이 고민하고 노력했다고 적혀있고 책을 읽으면서 생소한 단어 때문에 읽는 데 방해도많이 되긴 했지만, 무슨 뜻일까 거꾸로 영어로 영작해보기도 하고 원문을 찾아보고한자어의 경우 한자 뜻을 찾아보고 나서야 어떤 의도로 그런 번역어를 만들었다고이해하기도 했고 혹은 아무 문제 없다고 생각했던 번역어를 굳이 쓰지 않고 곡해하기좋은 새로운 번역어라고 생각되는 경우도 있었다.

책을 읽으며 아쉬웠던 점은 합의없이 새로운 표현을 만들어냈다는 것이 아니라, 생소한표현을 처음 사용할 때는 차라리 원어 병기를 통해 유추라도 가능하도록 도와줬으면좋았을 텐데 그렇지 못한 경우가 너무 많았다는 점 정도다. 번역어에 대한 합의는현재 그럴만한 적당한 공간이 없기 때문에 그걸 생략했다고 누구에게 뭐라고 할 상황은아니라고 생각한다. 그래서 더더욱 그럴만한 적당한 공간이 없다는데 더 안타깝다.

마무리로 광고를 남기자면 이상한 모임의 슬랙에들어와 보시면 이 공간의 아이덴티티를 이해하는 데 도움이 된다. 위에서 말한 번역에대한 이야기도 간혹 하고, 개발자가 많다보니 개발에 관한 채널이 많지만 그 이외에도각종 가젯(gadget)/SW 지름, 음악, 책, 디자인, 운동 등 아주 잡다한 분야에 대한이야기가 항상 오고가서 어떤 사람들이 어떤 이야기를 한다고 특별히 정의내려서설명하기 어렵다. 그냥 직접 와서 겪어보는게 이해하는데 제일 좋다. 굳이 공통점을꼽자면 재미있는 것에 목마른 사람들이라고 표현하고 싶다.

이번 주의 제목은 노트가 아니라 메모 겸 후기다.5주차에는 수업이 없고 과제와 퀴즈만 있다.

Lab 4. 스파크로 머신러닝 시작

영화 목록과 평점 이력을 트레이닝 셋으로 해서 내가 영화 평점을 몇 개 입력해서다른 영화의 내 평점을 예측하도록 기계학습을 해보는 과제이다.스파크의 머신러닝 라이브러리(MLlib)에서의 협업 필터링(Collaborative Filtering)에서는 ALS(Alternating Least Squares)라는 알고리즘을 사용하는데, 유사도를평가하는 데는 평균 제곱근 오차(Root Mean Square Error; RMSE)라는 방법을 사용한다. 정확한 의미는 이해하지 못했지만, 순서대로 따라가니 풀 수있었다.

Lab 4. Quiz

RMSE의 값에 대한 의미(예상값과 실제값이 같을 때의 결괏값)를 묻는 간단한문제들이었다.

후기

세 번째 과제를 진행하다가 TF-IDF에 대한 이해가 부족해서 자료를 찾다가 영어로 된글을 계속 읽다 보니 지루해져서 계속 미뤘는데, 결국 기한을 넘겨서 그냥 하던 데까지만 제출했다. 그래서 이번 과제는 알고리즘(ALS)에 대한 이해가 부족해도 그냥최대한 설명을 자세히 읽고 이리저리 시도해보다가 다 풀긴 했다.

내용을 다 이해하지는 못했지만, 좋은 입문 강의다. 강의 시작에서 언급했듯이 파이썬기본 문법 정도만 알고 있으면 진행하는 데 큰 무리는 없을 것이라 생각한다. 어차피기초적인 개념부터 설명하는 강의라, 과제할 때 파이썬 문법의 문제인지 스파크를잘못 사용한 것인지에 대해 구분할 수 있을 정도면 되지만, 그렇지 않을 때는어렵다기보다 상당히 까다로울 것이다.

기초적인 개념부터 설명한다고 위에서 말했지만, 개념과 역사, 사례를 넓게 훑고지나가면서 책, 논문 등의 자료들을 레퍼런스로 많이 소개해서 깊게 알고 싶은 분야에대한 좋은 진입점을 제시해준다. 당연히 입문 강의는 그렇다고 생각하지만 A to Z로가르쳐주길 원하는 사람에게는 맞지 않는 강의다.

가장 마음에 들었던 것들을 꼽자면, 하나는 모든 강의가 5분 내로 되어있다는 점이고나머지 하나는 FPPiS처럼 과제가단계별 테스트로 되어있다는 점이다.

입문 강의라 많은 개념을 깊게 설명할 수 없으므로 개념별로 간단하게 설명을하기 지나가는데, 덕분에 지하철/버스에서 이동 중에 틈틈이 듣고 나중에 1.5배속으로빠르게 복기하면서 퀴즈를 풀면 두세 번 반복하는 느낌이라 오래(과제가 끝나기 전까지)기억에 남는다. 이동하는 시간은 어차피 낭비하는 시간이라고 생각했는데 꽤 요긴하게쓰였다.

그리고 단계별 테스트로 되어있다는 것도 입문 과목에서 큰 장점이라고 생각하는데,과제를 던져주고 알아서 해결하는 방법을 찾는 것도 중요하지만 가장 정석적인단계를 알려주기 위해서는 과제를 단계별로 나누고 각각의 단계를 어떻게 진행할지에대한 설명을 사이사이에 주고, 하나가 통과해야 그다음으로 넘어갈 수 있으니 다음문제를 보고 이전 문제의 의도를 가늠해볼 수 있기도 하다. 물론 하나가 막혀버리면그다음의 모든 것을 못한다는 게 단점이지만 그렇게 난이도 조절을 못 한 과제는아니라고 생각한다.

사실 다 마치고 나서도 이제 무엇을 해야할지 막막하지만, 소재의 문제이지 방법에대한 것은 한번 과정을 거쳤으니 어떤 식으로 접근해야 할지에 대한 감을 대충 알았다.

참고로 edX에서는 한 학교가 주제에 따라 코스웍을 제공하는 X시리즈 인증이 있는데,이 강의(CS100.1x)는 Berkeley에서 진행하는 빅데이터 코스인 BerkeleyX의 두 단계 중첫 번째다. 두 번째 단계(CS109.1x)는 확장 가능한 머신 러닝(Scalable Machine Learning)이라는 제목으로 29일부터 시작한다. 수학적 사고와 알고리즘 개념, 그리고 기본적인머신 러닝에 대한 개념이 필요하며, 알고리즘, 확률, 선형대수, 미적분을 접해본 적이있고, 파이썬 경험이 있거나 빠르게 익힐 수 있으면 된다. 듣긴 하겠지만, 이 과목처럼완주하겠다는 생각으로 듣는 것은 아니고 재미있는 부분까지만.

Lecture 7. 데이터 품질

데이터 클리닝

• 왜곡: 처리과정에서 변질된 표본들
• 선택편견: 값에 따른 표본의 가능도(likelihood)
• 좌우검열: 데이터가 무한대일 때 시작과 끝을 어떻게 자를지
• 의존성: 표본이 독립적인지 아닌지에 대한 판단

• 정확성과 (과정의)간소에 대한 트레이드오프
• 단위 통일, 중복 제거 등

문제

• 텍스트 파싱
• 같은 엔티티 다른 표현(2 vs two, NYC vs NewYork)
• 비구조적-구조적 전환시 primary key
• 너무 길어서 잘리는 필드
• 형식 문제(특히 날짜)

수집

• 과정에서 무결성 체크
• 구조에 없는건 기본값

전송

• 신뢰할만한 프로토콜인가
• 받은 데이터의 확인이 가능한가(checksum)

분석의 어려움

• 크기, 성능
• 모델에 적용
• 전문지식 부족
• 다트판(때려맞추기)
• 대충 경험(특정 상황에만 맞는 분석)

품질 측정

• 스키마 일치
• 정확성, 접근성, 해석가능
• Lab2에서 정규식을 통한 형식 일치 확인

용어?

• 개체 식별(entity resolution)
• 중복 검출(DeDup: Detection Duplicated)

표준화

• USPS에서 제공하는 주소 표준가이드
• 다른 필드 참고 등 식별 힌트

Lecture 8. 탐험적 데이터 분석과 머신 러닝

기술통계 vs 추론통계(위키피디아)

업무에서의 목적

• 간단한 통계
• 가설 검증
• 분류
• 예측

탐험적 데이터분석

• 기본 테크닉 소개
  • Five-number summary
  • box plot, stem and leaf diagram
• 통계요약의 문제: 같은 요약이라도 다른 데이터일 수 있다

정규 분포

• 평균, 표준편차
• 중심극한정리(Central Limit Theorem): n이 무한대로 가면 정규분포에 가까워진다.

다른 중요한 분포

• 프아송 분포
• 이항 분포, 다항 분포

Spark의 mllib

• NumPy와 함께 사용가능(pySpark >= 0.9)
• 여기에서는 영화평점 예측
  • collaborative filtering
  • k rank = user(a) x movie feature(b)

Lab 3. 텍스트 분석과 개체 식별

1. 텍스트 유사성으로 개체 식별 - Bags of Words

• Bag of Words 기법

2. 텍스트 유사성으로 개체 식별- TF-IDF를 사용한 가중치 적용된 BOW

• TF-IDF

3. 텍스트 유사성으로 개체 식별- 코사인 유사도(Cosine Similarity)
4. 역참조(inverted index)를 통한 효율적인 개체 식별
5. 그래프(plot)을 통한 결과 분석

Lab 3. 퀴즈

Lab 3에서 배운 것들 재확인

pySpark Docset

• Dash용 pySpark API문서
• 설정의 다운로드 -> 좌하단의 사용자 제공(User Contibuted) -> pySpark 검색

• Lecture 7 slides
• Lecture 8 slides

자료 형태

• 구조적: 정형(schema) 데이터. RDB, formatted msg
• 반구조적: schema를 그때그때. XML, JSON, mp3tag
• 비구조적: plain text

파일이란

• byte의 나열
• FS를 통한 상하구조
• POSIX interface(이건 왜?)

테이블

• 처음부터 구조를 잘 짜야
• 같은 데이터도 타입문제(2 vs 2.0)
• 이력관리

취합 문제

• 필드가 다를 때
• 데이터 단위가 다름
• 같은 값인데 표현이 다름

pandas

• data analysys + modeling for python
• DataFrame: named column
• R도 비슷한 data frame 지원

DF in pySpark

• 1.3부터 RDD 확장으로 지원
• pandas, R의 DF와 같지만 분산환경
• pandas DF와 convert 쉬움
• pandas -> pySpark시 driver 메모리 꽉 찰 수 있음 주의
• RDD는 Scala구현체가 Python구현체보다 두 배 이상 빠름
• DF는 RDD Scala보다 두 배쯤 빠르고 Py/Scala 비슷

Apache Common Log Format의 데이터를 분석해보자

• 컨텐츠 통계: status code, size
• 404 횟수

• 하루에 단일host는 얼마나?
• 하루에 요청은 얼마나?
• 호스트당 평균 요청은?
• 하루에 404는?

로그 마이닝

• splunk를 통해 event log, disk error, network, cpu/memory usage 등 통계 및 분석

read/write

• binary가 항상 빠르다
• 압축 알고리즘과 rw속도는 어느 정도 trade-off

Lecture 6. 구조적 데이터

RDB

• relation: schema + instance
• sparse에 약하다

SQL 기초

• select, (inner, outer)join
• join in Spark

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

x = sc.parallelize([("a", 1), ("b", 4)])
y = sc.parallelize([("a", 2), ("a", 3)])
x.join(y).collect
// [('a', (1, 2)), ('a', (1, 3))]

x = sc.parallelize([("a", 1), ("b", 4)])
y = sc.parallelize([("a", 2)])
x.leftOuterJoin(y).collect()
// [('a', (1, 2)), ('b', (4, None))]

x.rightOuterJoin(y).collect()
// [('a', (1, 2))]

x = sc.parallelize([("a", 1), ("b", 4)])
y = sc.parallelize([("a", 2), ("c", 8)])
x.fullOuterJoin(y).collect()
// [('a', (1, 2)), ('c', (None, 8)), ('b', (4, None))]

Lab 2. 로그 분석

Apache Log Format을

1. 정규식으로 나눠서
2. 종류별 aggregation
3. key, value로 나눠서 plot
4. 그리기 위해 2, 3번의 반복이 많아 분량에 비해 생각할꺼리는 적음
5. 아마도 python 사용에 익숙치 않은 사람들을 위한 단순반복으로 추정

tip.

저번 과제에 비해 데이터가 커서연산할 때 시간이 많이 걸리므로 REPL이나편한 python 툴을 꺼내놓고 기다리면서 다음 셀에서 어떻게 하면 될지 간단히테스트해보면 좋다.

• Lecture 5 slides
• Lecture 6 slides

1
2
3
4

// 선택된 첫번째 엘리먼트 - $('input[name="food"]')
var $ = document.querySelector.bind(document);
// 선택된 엘리먼트들의 배열 - $('img.dog')
var $$ = document.querySelectorAll.bind(document)

여기에 @paul_irish가 비슷한 컨셉으로 이벤트 등록까지 할 수 있는 bling.js를 리플로 남겼다.

1
2
3
4

Node.prototype.on = window.on = function(name, fn) {
    this.addEventListener(name, fn);
}
// 이하 생략

이런 @thejameskyle가 흥미로운 리플로 이런 소스를 남겼다.

1
2
3
4
5

let $ = ::document.querySelector;
let find = Element.prototype.querySelectorAll;
let each = Array.prototype.forEach;
let on = Node.prototype.addEventListener;
// 이하 생략

생소한 문법이 등장했다. ::는 어떤 의미일까?

예전에 봤던 reactjs로 ES6를 접한 사람들이 하는 오해에 대한 글, ES6 Gotchas가 생각났다.

1

<div onClick={this.handleClick} />

이게 사실은

1
2
3
4
5
6
7
8

import React from 'react'

export default class ComponentName extends React.Component {
  constructor(){
    super()
    this.handleClick = this.handleClick.bind(this)
  }
  ...

이런 식으로 this.handleClick을 그대로 넘기는게 아니라 자동으로 bind해서 넘겨주는걸 react에서 해주기 때문에 사람들이 오해하기 쉽다는 뜻이다.babel에서는 (소위 ES7이라 부르는)실험 기능을 활성화할 수도 있는데, 그 중 데코레이터에 autobind decorator를 붙일 수도 있다.@autobind를 메소드 혹은 함수 위에 붙이면 react처럼 bind해주는 기능을 한다. 그런데 이게 마음에 안 찼는지 함수 Bind 문법이라는 제안이나왔고, babel에도 추가되었으며 자세한 설명된 포스팅도 올라왔다. 위에 'ES6 Gotchas' 댓글에서 예제 소스를 빌려오자면,

1. ::a.b는 a::a.b와 같다.
2. a::b.c는 b.c.bind(a)와 같다.
3. 그러므로 ::a.b는 a.b.bind(a)와 같다.

이제 다시 처음 소스의 ::document.querySelector를 풀어보자면 document.querySelector.bind(document)라는 것을 알 수 있다.

ES6/ES7(이제는 ES2015 or after라고 부르지만)에 대한 이야기를 자주 하는 이유는 재미있고 내가 관심 있는 분야라서도 그렇지만,이런 기술들은 나 혼자 편하다고 해서 쓸 수 있는 것이 아니다. 같이 일하는 사람들이 필요성에 대해 공감하고 익숙해야 쓸 수 있다.그래서 보다 많은 사람들이 관심을 가지고 익숙해졌으면하는 바람이 있다. (물론 나는 현재 무직이라 같이 일하는 사람이 없지만 나중을 위해)

JavaScript라는 언어의 문법 자체는 심플한 편이지만, 거지같은 실행환경 때문에 this가 뭐냐 언제 결정되느냐는 질문을 하도 많이 받아서"var that = this" 같은 자바스크립트 스코프에 대한 이해라는StackOverflow의 답변을 번역해 글을 쓴 적도 있다. 어차피 웹이라는 거대한 플랫폼에서 자유로운 개발자는 많지 않고, 발을 디딘 사람들 중 대부분은 프론트를 한 번쯤 만지게 된다.피할 수 없다고 즐기는 건 변태지만, 최대한 생산성을 높여서 괴로움을 줄이길 바란다.

실습은 노트북 파일에서 비어있는 부분을 채우면서 진행하면 되는데, 의도에 대한 설명은 코드 위에 충분히자세하게 되어있고 단계별 진행이다보니 정확히 읽지 않아도 코드를 보면서 따라가면 유추가 가능하다.단순히 유행어(Buzzword) 이상으로 Big Data나 Spark에 대해 배워보고 싶은 사람들에게 추천할 겸,몇달 뒤에 잊어먹을 나 자신을 위해서 기록을 남겨본다.

1주차

환경설정: Jupyer + PySpark가 세팅된 vagrant 올리기

수업 목표

• Data Science를 배워보자
• 실제 데이터를 다루는 과정
• Spark(w/ mllib)를 써보자

Lecture 1. Big Data와 Data Science 소개

• 데이터 분석의 역사
• 원인 ≠ 상관관계
• 충분한 데이터가 필요
• 현재를 분석하는건 쉽고 미래를 예측하는건 어렵다
• 사건에 대한 중요한 요인을 모두 알고 있어야한다
• (MySpcae 사례를 통한 페이스북 유행시기 추정 -> 실패)

빅데이터는 어디에서?

• 사용자들이 올리는 컨텐츠들(웹/모바일) - 페이스북, 인스타그램, 옐프
• 생체정보/과학쪽 연산

그래프 데이터

• 많은 데이터들이 그래프 구조
• SNS, 네트워크 등

사람이 보기에 너무 많은 정보

• 아파치 서버 로그
• IoT의 센서 측정기록

빅데이터를 어떻게 다룰까

• Crowdsourcing
• Physical modeling
• Sensing
• Data Assimilation

많은 사람들에게서 정보를 얻어 분석한 다음에 중요한 정보를 시각화

Lecture 2. Data Science는 어떻게? 데이터 준비하기

• 코딩 + 도메인 지식만으로는 잘못된 분석의 가능성
• Data Science = 코딩 + 도메인 + 통계지식

The Data Science Venn Diagram

Database와 Data Science의 차이

• 데이터가 중요하다 / 싸다
• 원자성이 중요 / 결과적으로 유지만되면 오케이
• 과거를 조회 / 미래를 예측
• 정해진 복잡도 / 하다보면 됨

방법

• Jim Gray 모델 vs Ben Fry 모델 vs Jeff Hammerbacher 모델

어려움

• 실제 데이터는 너무 더러움
• 이전에 발견한 패턴/가설이 선입견

준비: ETL

• extract: 데이터 추출
• transform: 가공
• load: 모아놓는다

2주차

Lecture 3. 빅 데이터, Spark

왜 필요한가?

• 페이스북의 하루 로그는 60TB
• 이제 머신 하나에서 다룰 수 없다

거대한 문서에서 단어를 세는 예제

• 머신 n-to-1
  • 문단 별 단어 카운트는 n개에서 나눠서 해도 된다
  • 합치는 작업을 1개에서 한다면 병목
• 머신 n-to-n
  • 합치는 작업도 단어별로 n개에서 나눠서
  • 이게 Map/Reduce 개념
• 문제
  • 머신끼리 데이터 보내는건 느리다
  • 하나가 실패하면? -> 그 머신만 다시 시작
  • 하나가 느리면? -> 하나 더 돌리고 먼저 끝난걸 선택
• 문제 2
  • 작업을 반복해서할 때 디스크에 저장하면 I/O가 병목
  • 메모리에 올려서 작업하면? -> Spark

Spark

• 위에서 말한 실패하거나 느린 노드를 자동으로 처리
• Core와 컴포넌트 4개 Spark SQL, Spark Streaming, MLlib, GraphX로 구성
• disk에 넣기 위해 serialization/deserialization 할 필요가 없으므로 100배 이상 빠르다

특징

• 다양한 경우에 쓸 수 있는 엔진
• 리니지(immutable을 이용한 이력관리)의 lazy eval

Lecture 4. Spark 기초

• 어플리케이션(driver)에서 SparkContext로 시작
• worker는 클러스터 혹은 로컬 스레드
• 분산된 worker의 추상화가 RDD

맨 처음 실행하면

• SparkContext 객체의 인스턴스 sc 생성
• sc로 로컬의 worker 접근, 혹은 hdfs, mesos 접근

RDD는

• 만들어지면 불변
• transform되는 과정(lineage)을 추적해서 재사용 가능
• 파티션을 설정하면 그만큼 병렬처리

연산은

• transformation, action 두 종류
• transform: lazy eval, action까지 미뤄둠
• persis(cache)는 메모리/디스크 저장

1
2

data = [1, 2, 3, 4, 5]
rDD = sc.parallelize(data, 4)

혹은

1

file = sc.textFile("README.md", 4)

transformation

• map, filter, distinct, flatMap,

action

• 바로 계산
• reduce, take, collect, takeOrdered

1
2
3

lines = sc.textFile("...", 4)
comments = lines.filter(isComment)
print lines.count(), comments.count()

lines 연산을 한번, lines+comments 연산을 한번해서 중복. 그럴 때는 중간에 lines.cache()

key-value transformation

• reduceByKy, sortByKe, groupByKey
• groupByKey는 데이터가 이동하므로 네트워크/대량에서는 주의

1
2

rdd // [(1,2), (3,4), (3,6)]
rdd.reduceByKey(lambda a, b: a + b) // [(1,2), (3,10)]

closure

• broadcase: driver가 쓰면 worker들이 읽기 가능
• accumulator: worker들이 쓰기만 가능 driver만 접근가능

Lab 1. Spark 과제

구텐베르크 프로젝트에서 셰익스피어 전집의 데이터로 단어 세기

• 특수문자 제거
• 띄어쓰기로 단어 구분
• 중복 제거를 위해 소문자로 변환
• 최빈 15개 단어

참고로 강의노트(PDF)가 공개되어있다.

• Lecture 1 slides
• Lecture 2 slides
• Lecture 3 slides
• Lecture 4 slides

• 죽는 건 상관없지만 죽은 뒤에 탭 목록이 유지될 것

패턴이라는 게 별것 없다. 트위터, RSS, 뉴스레터에 올라온 링크들을 브라우저에 최대한(약 50개)으로올려놓고 빠르게 훑어본 뒤 필요 없다고 판단된 것들은 닫고 정독할 것들을 쌓아둔다. 예전에는 그냥 닫거나포켓에 넣거나 둘 중 하나였는데, 포켓이 반응속도가 느려진 뒤로 포켓을 거치지 않고 그냥 브라우저에띄워놓고 있다. 다양한 곳에서 하루에 세 자리 단위의 링크들을 띄우고 정리하다보니 어디까지 읽었는지,어떤 것을 정독하려고 판단했는지의 목록이 사라지면 그것을 다시 복구하는 것만 해도 경험상 두세 시간 이상은걸리게 되니 탭 목록이 사라지는데 매우 민감해졌다. 물론 공식적으로 사파리/파이어폭스도 탭 목록을유지해준다.

사파리에서는 다시 열었을 때, 마지막 세션에서 모든 윈도우를 다시 자동으로 열어주는 옵션도 있고, 혹여저 옵션을 선택하지 않았거나 비정상적으로 종료되었을 때 마지막 세션의 모든 윈도우를 다시 열게 해주는기능이 존재한다. 그리고 Session 등 주기적으로 세션을 백업해두는 확장도 존재하긴 한다. 다만,비정상적으로 종료당하는 일이 그리 많지는 않은데 그럴 때 앞에서 언급한 기능들에서 제대로 목록을살려주는 경우가 별로 없다. 맥에서 가장 미려하고 반응속도도 좋은 사파리라 사파리나 OS X의 메이저업데이트때마다 항상 재도전을 하고 있지만 항상 실패했다. 물론 10.11이나 Safari 9이 나오면 또도전할 예정이다. 하지만 그리 큰 기대를 하진 않는다.

파이어폭스도 마찬가지지만 비정상 종료의 모습이 약간 다르다. 사파리는 "뿅! 사파리가 사라졌습니다"하면서 갑자기 튕긴다면, 파이어폭스는 갑자기 "나 죽어어어어어어어어"하면서 CPU 점유율이 100%를넘어가며 주변에 민폐를 끼쳐서 어쩔 수 없이 강제종료하게 만든다. IE 6, 7 시절부터 쓰기 시작해서크롬으로 넘어가기 전에 메인으로 쓰다가, 크롬이 지나치게 무거워져서 돌아간 게 20대 후반 버전이었던것으로 기억하는데 파이어폭스도 그때부터 메이저 버전때마다 도전했지만 항상 저런 증상 때문에 실패했다.Session Manager 등 확장들을 찾아봤지만 평소에도 느리게 만들고 구동시간을 느리게 만들 뿐이었다.

사파리가 다른 두 브라우저에 비해 개발도구의 기능은 매우 떨어지나, 메모리/배터리 효율 면에서비교하기 어려울 정도로 좋다는 장점이 있고, 파이어폭스는 개발도구로써 최신 기술이 가장 먼저 들어가고Event listeners popup처럼 다른 브라우저에서 찾기 힘든 편리한 기능 등이 있다.

저 브라우저들이 내 머신들에서만 같은 문제를 발생하는 것일 수도 있고, 하루에 몇백 개의 링크를 훑어봐야하는사람이 많지도 않을테니 누군가에게 동의를 구할 수도 없고 그럴 생각도 없는 이유지만, 이것이 내가 크롬을쓸 수 밖에 없는 이유다.

1. "use strong" mode in ES6

ES5의 "use strict"를 포함하는 개선된(빡쎈) 버전이다. V8의 경우 예측할 수 있는 경우에는 최적화된 컴파일러를, 아닌 경우에는 일반 컴파일러를 실행한다고되어있는 글이 있었는데, 다른 구현체들의정확한 internal은 잘 모르겠지만 컨셉 자체는 다른 곳에도 적용가능해보인다. 다시 말해서, 프로그램 흐름과 객체 상태를 제약해서 유지보수를 편하게 하고성능을 좋게 한다는 아이디어에 대한 구체적인 제약들이다. 대표적으로 var와 delete를 금지하는 문법상 제약이 있다. var를 금지하는 대신 let을사용해서 lexical scope의 범위를 줄여서 컴파일러나 사람이 생각해야하는 양을 줄이겠다는 것으로 보인다. 그리고 delete를 금지하면 객체의 형태가 고정(seal)되어 형태에 대한 정보를 재사용하고 예측가능해진다.(참고, ES6의 Object.freeze와 Object.seal의 차이에 대한 답변)

2. ES2016 Observable

ES6의 Generator와 ES7의 async/await를 합치면 비슷한 구현은 가능하지만, async generator의 경우에 IO에는 적합하지만 Push(Event, WebSocket)등에는 적합하지 않는다. 즉 async는 producer를 observable은 consumer를 만들 때 적합하다(하지만 이해를 잘못한 것인지 슬라이드에는 반대로 되어있다).사실 이게 들어갈 확률은 매우 적어 보이지만, 요즘 듣고 있는 Coursera의 reactive programming에서Rx에 대한 내용이 나오다 보니 그쪽으로 관심이 생겨서 RxJS도 써보고 싶은데 마침 이 제안을 발견해서 기억에 남았다.

ps 1, 이것들 말고도 hn/reddit에 추천 상위로 올라온 게 더 있지만 재미가 없었는지 키워드도 기억나지 않는 게 많다.

ps 2, 흥미로운 것들을 발견하면 실시간으로 트위터에 올리고 있다. @devthewild

ps 3, 구직중

Translation of "From callback to (Future -> Functor -> Monad)" into Korean, under the same license as the original.

동기

함수형 프로그래밍에서 기본개념은 조합(composition) 이다. 간단히 설명해서, 단순한 것들을 엮어서 더복잡한 것을 만들 수 있고 그 결과를 다시 엮어서 더 복잡한 것을 만들 수도 있다. 함수의 의미나 리턴값이무엇인지만 알고 있으면 조합으로 무엇이든 만들어낼 수 있다.

Node.js를 써봤으면 아래와 같은코드를 본 적이 있을 것이다.

1
2
3
4

fs.readFile('...', function (err, data) {
  if (err) throw err;
  ....
});

위의 코드는 전형적인 CPS(continuation-passing style) 함수이다. fs.readFile이라는 CPS함수는 계속(continuation) 진행될 콜백을 추가 파라미터로 받는다. 이 CPS가 끝나면 호출한 곳에 값을반환하는게 아니라 계속 함수, 콜백에 계산 결과를 넘겨준다.

나는 콜백을 쓰는걸 꺼리진 않는다. 사실 콜백은 부수효과를 표현하거나 이벤트 알림같은 것을 다룰 때훌륭하다. 그렇지만 그걸로 흐름을 관리하기 시작하면 함정에 빠진 것이다. 왜냐면 조합할 수 없기 때문에.

자, 생각해보자. "위에 나온 함수의 **표기(denotation)**나 리턴값은 무슨 의미일까?" 답은undefined이다. undefined라는건 테스트할 때 실제로 undefined인지 확인하는 용도 이외에는 쓸데가 없다.

콜백 안에서 다른 실행 흐름으로 넘어갈 때 일방통행이라는게 문제다.

물리학에서 유명한 블랙홀처럼 콜백을 생각해보자:

블랙홀은 수학적으로 정의된 지역이다. 강한 인력이 작용하거나, 어떤 티끌이나 전자기적 파장조차빠져나갈 수 없는

그 중에서도

어떤 빛도 반사하지 않는 등 블랙홀은 많은 부분에서 이상적인 검은 물체처럼 작용한다.

콜백 함수 또한 흐름에서의 어떤 것도 반사하지 못한다.

나중에 첫번째 콜백에 들어갈 때 다른 콜백 스타일 함수를 쓸 수 있는데, 그때는 두번째 흐름을 잃게되고 다른 구멍에 빠지게 된다. 콜백을 쓰면 쓸 수록 지옥에 빠지게 된다.

그럼 블랙홀에 빠지지 않고 코드를 진행할 수는 없을까?

답은 조합이다. 하지만 조합을 사용하려면 일단 CPS 함수가 어디로도 돌아갈 수 없다는 사실을알아야하고, 함수로부터 뭔가를 받아와야한다. 그러니 어떻게든 함수가 뭔가를 반환하게 만들어야한다. 어떤값이 반환될까? 이게 이 글의 동기이다.

이미 자바스크립트에서의 해답을 알고 있을 수 있다. 하지만 계속 이 글을 읽도록, 강하게, 추천한다.지시적인(즉 함수형) 생각의 힘을 보게 될 것이고, 깔끔하고 간결한 해답을 어떻게 사용할지 보게 될 것이다.

future로 입문

파일 읽기, 네트워크 요청, DOM 이벤트, 이런 함수들의 공통점은 뭘까?

이 함수들은 즉시 완료되지 않는 것들이다. 즉, (보통 함수들을 다루는 식으로는) 현재 프로그램흐름에서 저 함수들이 완료될 때까지 기다릴 수 없다는 뜻이다. 그래서 _future_를 설명할 것이다.

그래서 특별한 반환 타입, 나중에 결과를 만들어준다고 명시하는 Future를 만들어보자. 요점은 다른함수들로 넘길 수 있는 1등급 클래스 값을 사용하는 것이다.

Future는 무슨 의미일까? 특정 시간(0이 될 수도 있다) 후에 발생할 것이라고 명시해놓은 값이다.그 시간은 우리가 x초 후라고 말하는 것처럼 명시적인 시간이 될 수도 있지만, Future 2개가 완료된 후혹은 Future 하나가 완료된 뒤 다른 Future 완료될 때처럼 상대적인 개념일 수도 있다.

여기서 중요한 점은: Future의 결과는 항상 불변값이다.

즉, 완료 값을 어떤 방법으로든 변경할 수 없다. 이 제약으로 구현 뿐만 아니라 의미론에 대한 추론도간단해진다.

Future는 일회용의 간단한 상태머신처럼 구현될 수 있다. 이 머신은 대기 로 시작했다가 완료 가 된후에 멈춘다. 한번 완료되면 계속 완료상태에 고정된다.

내부적으로 Future는 콜백에 여전히 의존하고 있지만, 그 콜백들이 컨트롤 흐름 매커니즘을 방해하지는않는다. 대신 올바른 목적으로만 사용된다, 이벤트 알림.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

function Future() {
  // 대기중인 구독들을 저장하는 리스트
  this.slots = [];
}

// 완료를 알린다
Future.prototype.ready = function(slot) {
  if(this.completed) slot(this.value);
  else this.slots.push(slot);
}

// 간단한 로그 유틸리티
function logF(f) {
  f.ready( v => console.log(v) );
}

Future를 완료시키는 외부 인터페이스로 메소드가 있다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

Future.prototype.complete = function(val) {
  // 불변성 보장
  if(this.completed)
    throw "이미 완료된 Future는 완료시킬 수 없다."

  this.value = val;
  this.completed = true;

  // 구독들에게 알림
  for(var i=0, len=this.slots.length; i< len; i++) {
    this.slots[i](val);
  }

  // 모두 실행되면 이제 필요없다.
  this.slots = null;
}

Future의 가장 간단한 예제로 어떤 값으로 즉시 완료시켜보자. 그 역할을 unit이란 메소드를만들어보자.

1
2
3
4
5
6
7
8

// unit: Value -> Future<Value>
Future.unit = function(val) {
  var fut = new Future();
  fut.complete(val);
  return fut;
}

logF( Future.unit('hi now') );

코드에 대해 간단히 설명하기 위해 타입 표기(type annotation) 를 사용했다.

unit: Value -> Future<Value>를 풀어보면 1- unit은 함수고, 2- 제네릭 타입 Value를입력으로 받으며, 3- 제너릭 타입을 가진 Future 인스턴스를 리턴한다. 여기서 타입 정보는 중요하지않으므로 Value라는 제너릭은 신경쓰지 않아도 된다.

다음 예제는 특정 시간이 지나고 완료되는 값이다.

1
2
3
4
5
6
7
8
9
10

// delay: (Value, Number) -> Future<Value>
Future.delay = function(v, millis) {
  var f = new Future();
  setTimeout(function() {
    f.complete(v);
  }, millis);
  return f;
}

logF( Future.delay('안녕, 이건 5초 걸린다', 5000) );

delay의 결과는 주어진 값만큼의 시간이 지난 뒤에 완료되는 Future다.

readFile 예제로 돌아가서, 이제 CPS 함수 대신에 Future를 리턴하는 함수를 사용할 수 있다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

var fs = require('fs');

// readFileF: (String, Object) -> Future<String>
function readFileF(file, options) {
  var f = new Future();
  fs.readFile(file, options, function(err, data) {
    // 에러는 잠시 후에 다루겠다

    if(err) throw err;
    f.complete(data);
  });
  return f;
}

logF( readFileF('test.txt', {encoding: 'utf8'}) );

readFileF의 결과는 인자로 받은 파일 이름의 내용을 잡고 있는 Future가 된다.

Future 다루기: 첫번째 게스트

Future를 결과적으로 함수의 결과를 잡고 있는 마법 상자처럼 생각할 수도 있다.

뭔가 쓸모있는 것을 하려면 Future 타입에서 쓸모있는 연산들을 제공해야한다. 그러지 않는다면필요없이 또 다른 undefined를 만든 것과 다를 바 없다.

그러면 어떤 연산을 Future에서 제공해야할까?

Future 상자에서 잡고 있는 값에 어떤 연산을 하고 싶을 때 (function map을 줄인)fmap을 호출할것이다.

fmap의 예제를 보자. 여기서 Future는 텍스트 파일의 내용을 잡고 있고, 이 내용의 길이를 계산하려고한다.

1
2
3
4
5

var textF = readFileF('test.txt', {encoding: 'utf8'});

// fmap: (Future<String, (String -> Number)> -> Future<Number>)
var lengthF = textF.fmap( text => text.length );
logF( lengthF );

lengthF의 뜻은 인자로 받은 Future가 잡고 있는 파일 내용의 길이를 잡고 있는 Future다.

일반화를 해보자면, fmap은 인자를 둘 받는데, 하나는 값을 잡고 있는 Future고 하나는 일반값을다루는 매핑 함수다. 입력으로 받은 Future의 결과물에 매핑 함수를 적용한 결과를 잡고 이는 Future가결과로 나온다. 받은 Future와 결과 Future는 둘 다 동시에 완료된다.

정확하진 않지만, 이렇게 표현할 수 있다

1

fmap( Future<value>, func ) = Future< func(value) >

fmap은 몇줄만으로 구현할 수 있다.

1
2
3
4
5
6
7

Future.prototype.fmap = function(fn) {
  var fut = new Future();
  this.ready(function(val) {
    fut.complete( fn(val) );
  });
  return fut;
}

현재 Future가 완료되었을 때 결과로 나온 Future도 완료된다. 그 때 매핑 함수를 적용시킨다.

위의 예제에서는, 파일 내용을 잡고 있는 Future를 내용 길이를 잡고 있는 다른 Future로 변이시켰다.

어디서 들어본 말 같지 않은가? 잘 알고 있는 자바스크립트 Array의 map 메소드와 꽤 비슷하다.실제로 정확히 같은 개념이다.

• Array 타입은 여러 값들을 잡고 있는 박스다
• Future 타입은 완료될 값을 잡고 있는 박스다
• Array.map(...) 은 Array 박스 안의 값들을 변이시켜서, 변이된 값들을 잡고 있는 다른 Array 박스를 돌려준다
• Future.fmap(...)은 Future 박스 안의 값을 변이시켜서, 변이된 값을 잡고 있는 다른 Future 박스를 돌려준다

Array와 Future 타입 둘 모두 포함되는 Functor라는 첫번째 게스트가 등장했다. 일반 함수를 하나받아서 안에 무엇을 가지고 있든 그것이 변이된 결과를 표현하는 다른 인스턴스를 만들어내는 타입이다.

• 다른 타입을 감싸는 컨텍스트처럼 작동할 수 있는 타입이고
• 내부에 있는 것을 일반 함수에 적용시킬 수 있다면

Array와 Future가 아니더라도 그게 무엇이든간에 그 타입을 Functor라고 부를 수 있다.

이제 Future를 다른 Future로 매핑할 수 있다. 이제 일반값을 다루듯이 Future를 직접적으로 다루는함수를 만들 수 있다는 뜻이다. textF.fmap( c => c.length )처럼 호출하는 대신에 Future를직접 다루는 lengthF라는 특별한 종류의 함수를 만들 수도 있다.

1
2
3
4

// lengthF: Future<String> -> Future<Number>
function lengthF(strF) {
  return strF.fmap( s => s.length )
}

파일 길이를 읽는 예제를 흔히 보던 방법처럼 다시 작성할 수 있게 되었다.

1

nbCharsF = lengthF( readFileF('...') )

lengthF를 lift된 함수라고 부른다. Functor같은 _박스 타입_을 다루는 함수를 lift한다는것은 일반값을 다루는 함수를 박스 타입을 다루는 함수로 만든다는 뜻이다. 여기에서는 문자열을 다루는 함수length(String)를 lift해서 Future를 다루는 함수lengthF( Future<String> )로 lift했다.

일반화된 lift1(인자를 하나만 받아서 lift하는 함수)를 정의해보자.

1
2
3

Future.lift1 = function(fn) {
  return fut => fut.fmap(fn);
}

비동기 실행을 일반 함수 실행처럼 만들어주는 간단한 추상 함수다. 위에서 lengthF( readFileF('...') )는readFileF와 lengthF를 조합해서 비동기 연산을 현재의 흐름을 떠나지 않고 실행할 수 있다.

인자를 여러개 받는 함수는 어떻게? (두번째 게스트?)

질문에 대답하기 전에 잠시 기초지식에 대해 생각해보자: Future 박스가 잡을 수 있는 타입에는 뭐가있을까? Future는 모든 타입에 대해 같은 의미를 가질까?

Future<String>의 뜻은 명확하다: 시간이 지난 뒤에 문자열 타입의 값이 발생한다는 뜻이다. 다른타입들에 이 의미를 확장할 수 있을까? 숫자, 객체, 배열? 그럴듯... 그럼 Future 자체에 대해서는어떨까? Future<Future>는 무슨 뜻일까? 그러니까 Future의 Future는?

보고 바로 이해할 수 있도록, 디렉토리를 보고 첫번째 파일의 내용을 읽는 간단한 예제를 만들어보자(간단히 생각하기 위해 내부에 다른 디렉토리가 없다고 가정한다).

Node.js에서는 비동기 함수 fs.readdir을 통해 디렉토리 속 파일들 이름의 배열을 가져올 수 있다.먼저 이걸 Future식 함수로 만들어보자.

1
2
3
4
5
6
7
8
9
10

// readDirF: String -> Future< Array<String> >
function readDirF(path) {
  var f = new Future();
  fs.readdir(path, (err, files) => {
    // 기다리면 곧 실행된다
    if(err) throw err;
    f.complete(files);
  });
  return f;
}

readDirF는 디렉토리 내 파일 이름들의 배열을 기다리는 Future를 뜻한다.

위에서 말한걸 구현하려면 필요한 나머지는

1. Future가 잡고 있는 파일 이름들의 배열을 기다린다.
2. 첫번째 파일명을 가져온다.

여기서 fmap을 사용할 수 있을까? Node에서 이걸 실행해보자

1
2

var resultF = readDirF("testdir").fmap( files => readFileF( files[0]) )
logF( resultF )

기다리면... 아차

1

{ slots: [] }

확실히 뭔가 잘못됐다. 콘솔에서 파일 내용이 나오는게 아니라 Future 인스턴스 객체의 내용이 나왔다.

왜냐면 fmap은 매핑 함수의 결과가 무엇이든 받아서 그걸 Future로 잡아 돌려주기 때문이다. 위에서의매핑 함수는 또다른 Future(readFileF의 결과)를 fmap은 그 Future를 잡는 Future를 만들어resultF에 보내기만 한다.

하지만 Future는 잡고 있는 Future와 함께 끝나는지 않으므로, 속에 있는 Future가 완료될 때까지계속 기다릴 뿐이다.

그래서 이럴 때 필요한 함수를 만들어보자. Future를 리턴하고 끝내는 대신에 속에 있는 Future가 끝날때까지 기다리는 함수다.

(이중 Future)Future를 그냥 Future로 만들어주는 flatten를 만들어보자.

1
2
3
4
5
6
7
8
9
10

// flatten: Future< Future<Value> > -> Future<Value>
Future.prototype.flatten = function() {
  var fut = new Future();
  this.ready(function(fut2) {
    fut2.ready( function(val) {
      fut.complete(val);
    } );
  });
  return fut;
}

이렇게 하면 원하는 결과를 얻을 수 있다.

1
2
3

var result = readDirF("testdir")
              .fmap( files => readFileF(files[0], {encoding: 'utf8'}) )
logF( result.flatten() )

fmap과 flatten을 따로 부르는 대신에 한번에 부를 수 있게 합쳐보자: 매핑 함수에서 나온 2중Future를 압축(flatten)하는 두가지 일을 한다. 하는 일 그대로 flatMap이라고 하자(좀 이상한건 나도 안다).

1
2
3

Future.prototype.flatMap = function( fn ) {
  return this.fmap(fn).flatten();
}

개념상으로는 위에서 독립적인 두 연산을 _이어서_하는 것인데, readDirF에서 나오는 파일 이름의배열을 readFileF에 넘겨준다.

여기에서 두번째 게스트가 등장하는데, Future를 Functor라고 부를 수 있는 것처럼 Monad라고 부를수도 있다. 순서대로 연산할 수 있는 방법에 대한 개념이다. 위에서 flatMap에서처럼, 이전 단계에서의결과를 다음 단계로 넘겨서 여러 함수를 연이어 연산할 수 있다.

Functor처럼 Monad도 많은 사용법이 있는데, 기술적으로 모든 모나드는 다음을 만족한다.

• 일반값을 Monad식(Monoadic) 값 으로 lift하는 방법: 예를 들어, Future.unit은 일반값을 Future로 만든다.
• 연이은 연산 2개를 이어서 실행하는 방법: Monad는 연산을 이어서 실행하게 해주는 방법이 포함된다. 위에서 flatMap은 그냥 Future 하나만 만들고 다음으로 넘어가는게 아니라, 앞의 Future가 끝날 때까지 기다렸다가 넘어가는 방법이 들어있다.

위에서 2개의 다른 연산(fmap과 flatten)으로 두번째 인터페이스(flatMap)를 만들 수 있다는것을 확인했다. fmap 함수를 정의하는 Functor라면 이중 구조를 단순화시켜서 합치는(flatten) 연산이필요해진다.

이제 처음의 질문으로 돌아가보자, Future들 여러개를 받는 함수를 어떻게 lift할 수 있을까?

다시 파일 예제로 돌아가서, 디렉토리의 모든 파일 내용을 합치려면 이런 코드가 될 것이다.

1
2

// concatF: (Future<String, ...) -> Future<String>
var resultF = concatF( text1F, text2F, ...)

이건 무슨 뜻일까? 입력받은 Future들이 잡고 있는 각 문자열들을 합친 것을 다시 잡고 있는 Future를만들어준다. concatF는 입력받은 모든 Future들이 순서대로 처리되도록 기다려야하므로 결과로 나온Future는 입력받은 모든 Future가 완료될 때 완료된다.

인자 2개를 받는 경우부터 시작해보자.

1
2
3
4
5
6
7
8
9
10
11

// fn: (Value, Value) -> Value
// lift2: ( (Value, Value) -> Value ) -> ( (Future, Future) -> Future )
Future.lift2 = function(fn) {
  return (fut1, fut2) => {
    fut1.flatMap( value1 => 
      fut2.flatMap( value2 =>
        Future.unit( fn(value1, value2) );
      )
    )
  };
}

보이는 것과는 별개로 코드의 로직은 꽤 간단하다. 한줄씩 읽어보자면:

• Future.lift2는 "일반값 2개를 다루는 함수"를 받아서 "Future 2개를 다루는 함수"를 리턴한다.
• 리턴된 (lift된) 함수가 실제로 하는 일은
  • (중첩되어 실행되는) 2개의 연산을 순서대로 flatMap에 넣고
  • 첫번째 연산은 그 자체로 하는게 없지만 value1을 바인딩해서 스코프에 묶어두는 역할을 하고
  • 두번째로 중첩된 연산은 value1과 value2를 fn에 넘긴다.
  • fn은 일반값을 리턴하는데 flatMap은 받은 함수가 Future를 리턴해야하므로 Future.unit을 통해 일반값을 Future로 lift한다.

이게 트릭이다: 모든 Future에서 순차적으로 flatMap을 실행해서 모두 끝나길 기다린 다음에 모든완료값이 한 스코프에 모였을 때 함수를 실행한다.

readDir 내부에서 readFile를 실행하는 것처럼 순차 연산으로 설명되는 Monadic 값과는 다르게여러 인자를 한번에 lift하도록 마지막에 Future.unit를 사용했다.

파일 2개의 내용을 합치기 위한 예제다.

1
2
3
4
5
6

var concat2 = Future.lift2( (str1, str2) => str1+' '+str2 );

var text1 = readFileF('test1.txt', {encoding: 'utf8'});
var text2 = readFileF('test2.txt', {encoding: 'utf8'});

logF( concat2(text1, text2) );

두번째 Future text2가 첫번째의 text1보다 먼저 끝나더라도 text1을 기다리게 되고,text1이 끝나면 text2는 이미 끝났으므로 바로 함수를 실행한다.

여러 인자를 받는 함수는, 입력들이 언제 끝나는지나 의존성과는 관련없다는 것을 알 수 있다.이걸 정리하면 다음과 같다.

• fmap이 하나의 연산을 실행하고
• flatMap은 순차 연산을 실행하지만
• 여러 인자를 lift하는 함수는 병렬 실행이다.

위에서 봤듯이, Future들을 한번에 실행하고 연산이 진행되기 전에 이미 그 결과를 기다리고 있다.

lift2의 패턴을 lift3이나 lift4로 쉽게 확장할 수 있지만, 인자의 갯수와 관계없이 위에서나온 중첩과 스코프를 통해 일반화를 구현해볼 것이다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

function toArray(args) {
  return Array.prototype.slice.call(args);
}

Future.lift = function(fn) {
  return function() {
    var futArgs = toArray(arguments), // Future 인자들
        ctx = this; // 컨텍스트(`this`)를 저장

    return bindArg(0, []);

    function bindArg(index, valArgs) {
      // 현재 Future 인자를 기다린다
      return futArgs[index].flatMap(function(val) {
        valArgs = valArgs.concat(val); // 완료값들을 모은다.

        return (idnex < futArgs.length - 1) ? // 아직 마지막 Future 인자가 아니라면
          bindArg(index+1, valArgs) : // 다음 인자를 flatMap에 넘기고 기다린다
          Future.unit( fn.apply(ctx, valArgs) ); // 끝까지 오면 모은 완료값들을 함수에 넘긴다
      });
    }
  }
}

lift에서는 lift2의 패턴을 재활용했다. 인자가 몇개 들어올지 정확히 모르니 재귀를 통해 전체를순회(iterate)하고, 완료를 기다렸다가 결과를 계속 넘겨서 모은다.(index번째의 Future를기다렸다가 완료값을 저장하고, 모든 입력이 완료될 때까지 다음 Future 입력에 이 연산을 반복한다.)마지막 Future까지 오면 함수를 실행하고 결과를 lift해서 리턴한다.

노트: 'Applicative Functor'라는 자료구조를 통해 n개 인자를 lift하도록 구현할 수 있지만,그러려면 람다나 커리에 대한 설명을 해야하므로 오늘은 일단 생략하자.

에러 처리

위에서 fs.readFile의 에러값을 어떻게 뒀는지 다시 확인해보자.

1
2
3
4
5

function readFileF(file, options) {
  var f = new Future();
  fs.readFile(file, options, function(err, data) {
    if(err) throw err;
    ...

실제로 작동하지 않는 코드다. 프로그램 흐름에서 떨어져서 실행중이므로 발생하는 에러를 잡을 방법이 없다.위의 상황에서 에러는 상위로 전파되며 잡는 핸들러가 없어서 Node.js 전체 프로그램을 중단시킨다.

에러를 잡아 흐름을 고치려고 한다거나 의미있는 메시지를 사용자에게 전달하는게 필요할 수도 있다.

가능한 방법으로는 Future에 실패 의 개념을 붙여서 의미를 확장하는 것이 있다. 아직까지는 Future의결과에 어떤 의미를 붙이지는 않았지만, 가능한 2가지 결과(완료 혹은 실패)로 Future를 생각해볼 수도 있다.실패에 대한 경우가 포함되었는지 확인해보자.

먼저, 완료를 알리는 ready 메소드가 있으니 실패를 알리는 메소드를 정의해보자.

1
2
3
4
5
6
7
8
9

function Future() {
  this.slots = [];
  this.failslots = [];
}

Future.prototype.failed = function(slot) {
  if(this.hasFailed) slot(this.error);
  else this.failslots.push(slot);
}

Future가 실패할 때의 메소드도 정의해보자.

1
2
3
4
5
6
7
8
9

Future.prototype.fail = function(err) {
  if(this.completed || this.hasFailed)
    throw "이미 끝난 Future를 실패할 수는 없다!"
  this.hasFailed = true;
  this.error = err;
  for(var i=0, len=this.failslots.length ; i<len ; i++) {
    this.failslots[i](err);
  }
}

이제 fmap를 다시 생각해보자.

readFileF(...).fmap( s => s.length) 예제에서 파일이 없을 때에 대한 처리가 없다.제대로 읽었을 때에 대해서만 변환하기 때문에 아닐 때는 에러와 함께 실패할 것이다. 혹시 변환 중 실패할경우에도 실패해야한다.

1
2
3
4
5
6
7
8
9
10

Future.prototype.fmap = function(fn) {
  var fut = new Future();
  this.ready( val => {
    try        { fut.complete( fn(val) ); }
    catch(err) { fut.fail(err); }
  });
  this.failed( err => fut.fail(err) );

  return fut;
}

flatten은 약간 복잡하다. 안쪽과 바깥쪽의 Future 2개가 있고, 각각 완료될 수도 실패할 수도 있다.그래서 4가지(2x2) 경우를 다뤄야한다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

Future.prototype.flatten = function() {
  var fut = new Future();

  // 1- 밖깥 실패 안쪽 실패 => 결과 실패
  // 2- 바깥 실패 안쪽 완료 => 결과 실패
  this.failed( _ => fut.fail(err) );

  // 3- 바깥 완료 안쪽 실패 => 결과 실패
  this.ready( fut2 =>
    fut2.failed( err => fut.fail(err) );
  );

  // 4- 바깥 완료 안쪽 완료 => 결과 완료
  this.ready( fut2 =>
    fut2.ready( val => fut.complete(val) );
  );

  return fut;
}

flatten에서 안쪽과 바깥쪽 모두 완료되었을 때만 결과가 완료된다.

flatMap과 lift는 수정할 필요가 없다. 이미 fmap과 flatten의 의미를 가져오는 것이기때문에 자동으로 에러에 대한 의미가 추가된다.

자, 이제 실패한 Future들은 연산에서 제외하게 만들었다. 그럼 실패한 Future들을 어떻게 다뤄야할까?

Future 에러를 잡아서 고치면 된다. 어떻게? 실패한 Future를 완료값으로 변이시켜서 원래의 연산에포함시키면된다.

fmap과 비슷하지만 좌우반전같은 fmapError 함수를 만들 것이다.

1
2
3
4
5
6
7
8
9

Future.prototype.fmapError = funciton(fn) {
  var fut = new Future();
  this.ready( val => fut.complete(val) );
  this.failed( err => {
    try         { fut.complete( fn(err) ); }
    catch(err1) { fut.fail(err1); }
  });
  return fut;
}

fmapError는 catch문의 비동기 버전처럼 작동하며, 정상적으로 완료되면 그냥 값을 넘기고 에러가발생했을 때는 매핑 함수에 적용시켜서 완료값으로 넘긴다.

간단히 예제를 만들어보자

1

readFileF('unknown file').fmapError( err => 'alternate content')

그럼 에러를 Monad식으로 파이프라인처럼 다음 연산으로 넘기려면?

flatMap의 좌우반전같은 flatMapError를 만들어보자

1
2
3

Future.prototype.flatMapError = funciton( fn ){
  return this.fmapError(fn).flatten();
}

예를 들어서 어떤 주소(URL)에서 내용을 가져오려고 할 때 요청이 실패한다면 다른 주소에서 가져오도록시도를 하려고 하는데, flatMapError을 사용해서 앞의 실패를 잡아서 다른 요청을 만들 수 있다.

1

resultF = requestF('/url1').flatMapError( err => requestF('/url2') )

resultF는 첫번째 요청이 성공할 때 'url1'의 내용을 잡고 있고, 실패할 때는 'url2'를요청해서 그 결과를 잡고 있다는 뜻이다.

부수효과

합성해서 연산할 수 있는 방법에 대해 필요한 것들을 모두 다뤄보았다. 지금까지 다뤘던 함수들을 통해서Future를 동기 연산을 할 때처럼 일반값으로 넘겨서 비동기 처리를 하게 해봈다.

하지만 연산들은 끝까지 도달해야 결과가 나온다. 부수효과가 필요한 연산들을 다뤄 볼 시간이다. UI를업데이트한다거나 콘솔에 로그를 찍는다거나 데이터베이스에 저장을 한다거나.

ready와 failed 이벤트를 사용할 수도 있지만 좋은 방법은 아니라고 생각한다.

실제 어플리케이션에서 한 Future가 여러 자식 Future들을 가지고 그 Future들은 또 자식 Future들을갖게 되는 트리같은 구조가 된다. Future하나가 완료돌 때 매핑된 Future들이 연쇄적으로 완료된다.

Future의 ready알림을 통해서 부수효과를 실행하려고 한다면 트리 내부에 있는 Future들 전체에영향을 끼치게 된다. 의미적으로나 구현상으로나 업데이트가 끝날 때까지 부수효과 연산을 미뤄두는 것이 좋다.예를 들어 DOM을 업데이트할 때는 requestAnimationFrame같은 스케쥴러에 맡기는게 더 좋을 수도 있다.

위에서 말한 이유로 do라는 메소드를 하나 만들텐데 부수효과 연산을 명시하는 것이다. fmap처럼부수효과 함수를 받겠지만, 내부의 알림들(ready와 failed)이 완료될 때까지 지연될 것이다.

예를 들어

1

requestF('/url').do( val => /* update ... */ )

이번에도 do의 의미와 리턴값이 무엇인지 생각해보자.

변이없이 그냥 Future를 리턴한다면 future.fmap( Id )(여기에서 Id는 x => x 같은 항등함수)와 같은 형태이다. fmap과 다른 점은, 먼저 do에서 부수효과가 발생한다는 점이고 두번째는 다른컨텍스트에서 실행된다는 점이다.(fmap은 즉시, do는 나중에). 가장 다른건 _의미_다.

정정: 2015년 4월 6일. Action이라는 새로운 타입을 통해 do를 적용했는데, 굳이 Monad(Future)안에 다른 Monad(Action)을 넣어 복잡하게 만들 필요가 없었다. 서버에 데이터를 넘기거나 응답을기다리는 등의 상황에서 리턴값이 필요할 수도 있는데, 다음 글에 이걸 개발해 볼 수도 있다.

빠르게 대충 구현해보자.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

Future.prototype.do = funciton(action) {
  var fut = new Future();
  if(this.completed) {
    action(this.value);
    fut.complete(this.value);
  } else {
    this.actions.push( val => { 
      action(val);
      fut.complete(val);
    });
  }

  return fut;
}

Future.prototype.complete = function(val) {
  ...
  var me = this;
  setTimeout( () => {
    for(var i=0, len=me.actions.length ; i<len; i++)
      me.actions[i](val);
  });
}

덧붙여서, 비동기실행을 제대로 구현하려면 process.nextTick이나 MessageChannel 등을 사용해야하지만 여기서는 간단히 구현하고 넘어가자. 비슷하게, 부수효과의 실패에 대응해 doError도 만들어야하는데, do와 비슷하므로 각자 알아서 구현해보자. (Gist에 코드 전체가 있다)

역주 1: Promise와의 비교는 Future/Functor/Monad 개념을 이해하는데 관계없다고 생각해서 생략했다.

역주 2: 그림으로 설명하는 Functor, Applicative, Monad(번역)과 함께 읽으면 이해하는데 도움이 될 것이다.

Translation of "Transitioning to Scala" into Korean, under the same license as the original.

2011년 말부터 2014년 초까지 전자상거래 솔루션 전문 에이전시, Nurun Toronto에서 리드개발자로 일했다. 자바와 스프링만으로 새로운 프로젝트들을 계속하다보니 대체제를 찾아야할 때라는걸 알게 되었다.

에이전시에서의 업무를 장기적인 관점에서 생각해봤다. "자바가 구리다"를 이해하지 못하는 고객들 때문에 마감에 시달렸다. 2004년도에 어플리케이션을 만들던 툴과 테크닉들은 2014년에는 별 도움이 되질 않았다. 2004년에는 코드 한줄을 테스트하기 위해 서버를 재시작하는게 당연했다 - 웹스피어는 재시작할 때 정체불명의 1200줄 XML 설정파일을 읽어오는데, 평균 걸리는 시간이 커피 한잔 마시고 오기 딱 좋은 120초 정도다. 요새는 이렇게 하면 에이전시나 개발자나 망한다.

우리가 만드는 어플리케이션들은 단순히 데이터베이스의 뷰어가 아니라, 매일매일 똥을 치워주는 소중한 도구다.

1. 왜 타입세이프의 스택을?

지난 프로젝트를 루비온레일즈로 진행해보고 뭘 싫은지를 알았다. 다른 동적 타입 언어도 인터프리트 언어도 상태기반 웹 프레임워크(stateful web framework)도 쓰기 싫었다. 자바 바이트코드로 컴파일되는 정적 타입 언어나 활발한 생태계를 가진 툴들, 그리고 확장성을 위한 무상태 웹 프레임워크가 더 괜찮았다. 또한 우리 고객사들은 믿을만한 회사를 통해 전문적인 기술지원을 받을 수 있어야 마음의 위안을 가졌다.

그래서 몇가지 선택지를 꼽아봤는데, 가장 먼저 타입세이프가 떠올랐다. 우리가 원하는 모든 것들이 있었다.

컨셉증명을 위해 초소형 전자상거래 사이트를 내부적으로 만들어서 스칼라의 단순함과 플레이의 개발 생산성에 대해서 시연했고 충분히 관심을 끌어서 결국 월마트 캐나다의 새로운 전자상거래 플랫폼의 토대가 되었다.

왜 스칼라가 복잡하다고 느낄까?

스칼라는 유연하다. 유연하다는 것은 단순하다는 것을 포기해야하는 일이지만, 다른 면으로 스칼라는 단순히 "자바보다 나은" 정도가 아니라 그보다 더 좋으며 매우 우아한 언어이다. 스칼라나 새로운 어떤 언어로의 전환이라는 큰 도전은 단지 기술적인 일만이 아니다. 능력있는 개발자라면 새로운 문법, 새로운 개념, 새로운 IDE를 배울 수 있다. 변화는 기술보다는 그 과정이나 문화같은 다른 면에서 어렵다.

짧게 말해서, 모든 것은 사람에 달려있다.

이 글의 뒷부분은 스칼라 프로그래밍 튜토리얼이 아니다. 이미 많은 글들이 있고, 고급 스칼라의 깊은 부분에 대한 최신 트릭을 가르칠 만큼 나는 인정받은 스칼라 개발자도 아니다. 이 뒤로는 스칼라로의 전환을 생각하고 있는 개발자들, 팀장 혹은 매니저들에게 전하는 조언들이다. 이 조언들은 기업용 스칼라 프로젝트를 이끌 때 개인적으로 한 경험을 토대로한 것들이다.

스칼라로의 전환을 생각 중인 매니저와 개발자들에게 하는 조언

1. 언어의 기능들을 이해해라

모든 스칼라 개발자, 팀장, 매니저는 마틴 오더스키의 스칼라 레벨 가이드를 읽어야한다.

전업 스칼라 개발자로 경력 1년반이 지나고 엔터프라이즈 스칼라 프로젝트도 진행했지만, 마틴의 가이드에서 스칼라 개발자 등급 A2.5/L1.5라고 생각한다. A3/L3에 있는 테크닉들을 사용하지만, 웹 어플리케이션을 쭉 개발해오면서 대부분은 써본 적이 없다. 케이크 패턴을 써본 적도 없고, 고계도 타입(high-kinded type, 역주: 스칼라 학교에서는 상류 타입이라고 번역했는데, 하나의 Layer 위에 있다는 생각으로 고계高階를 생각해봤다)을 써본 적이 아직 없다. 그렇다고 나쁜 개발자도 아니고, 가면현상의 증상도 아니고, 단지 내 시간은 한정되어있고 가장 돈이 되는 것에 집중하려고 한다. 게다가 드럼도 치고 기타도 치고 일주일에 두번 댄스 레슨도 다니고 커피도 많이 마시고 데이트하러 나가야한다. 시간은 소중하니까.

Walmart.ca 프로젝트에서는 콤비네이터 파서와 폴드를 사용하지도 않고 레벨 가이드의 얇은 부분만을 썼다. "얇은" 스칼라로도 이전 플랫폼보다 훨씬 좋은 생산성을 보여줬다. 구현하는데 골치아픈 일도 없었다. 그렇게 짠 코드들은 이전보다 더 관리하기에도 좋고 생산성도 더 좋았다. 블랙 프라이데이나 박싱 데이(역주, 북미지역 등지에서 추수감사절 시즌/크리스마스 시즌에 대부분의 쇼핑몰들이 매년하는 대량할인 이벤트 기간들)에서의 확장도 완벽하게 돌아갔고, 많은 자바기반의 전자상거래 플랫폼은 하지 못했던 것들이다.

그래서 중요하지 않다는건가?

단순하게 스칼라를 쓴다는 것을 스칼라가 부족하다는 것으로 착각하지 마시길. A1과 A2 등급에서 익힐 수 있는 것들을 보자.

• 간단한 클로저
• map, filter 등의 콜렉션
• 패턴 매칭
• trait 합성
• 재귀
• XML 표현식

(역주: 코멘트에서 XML 표현식은 SWIFT에서 사용중이라고 한다.)

자바에 몇개 더 추가한 것과 비슷하다. 서술하듯이 개발하고 소프트웨어를 관리하는 새로운 방법이다. A3에 있는 몇개도 익히기 꽤 쉽고 - Akka나 다른 병렬 처리 라이브러리들을 사용하기 위해 꽤나 중요한 것들인데 - 그에 비해 크게 어렵지 않고 수학 학위가 필요할 정도는 아니다.

• fold
• stream, 혹은 지연평가 자료구조
• actor
• combinator parser

이런 테크닉들을 익혔을 때의 좋은 부가효과는, 사용하는 모든 언어에서 더 좋은 개발자가 된다는 것이다. 나는 스칼라와 자바스크립트 모두에서 클로저나 다른 테크닉들을 익히는데 정말 도움이 됐고 더 좋은 자바스크립트 프로그래머가 되었다.

2. 시간을 써라

자바에서 건너온 많은 스칼라 개발자들은 바로 적응하고 싶어하지만 스칼라는 완전히 다른 언어다. 새로운걸 익힌다는 것은 연습을 필요로 한다. 스칼라도 예외는 아니다.

좋은 소식은 A2/L1 등급만으로도 충분히 스칼라 어플리케이션을 만들만한 자격이 있다는 것이다. 모든 스칼라 개발자가 고급 순수함수 자료구조, 타입 이론, 고계도 타입을 이해하고 있을 필요는 없다. 하지만 스칼라는 차세대 어플리케이션을 만드는 전문 개발자를 위한 프로그래밍언어라는 것이다. 그래서 배우고 체득하는데 많은 시간이 걸릴 것이다.

3. 배우는걸 두려워말라

자바 개발자라면 다음과 같은 자료들을 통해 스칼라를 배우길 강력히 추천한다.

• Scala for the Impatient를 읽어라. 특히 예제가 필요한 성격급한 개발자들에게 좋은 시작점이다. (역주, 번역판 쉽게 배워서 빨리 써먹는 스칼라 프로그래밍, 2013 비제이퍼블릭)
• 마틴 오더스키, 렉스 스푼, 빌 베너스의 Programming in Scala를 읽어라. Scala for the Impatient보다 더 자세한 책이라 언어의 기능들에 대해 폭넓은 시야를 익히기에도 좋다. (역주, 번역판 Programming in Scala, 2014 에이콘)
• 가능하면 Coursera의 Functional Programming Principles in Scala 코스를 들어라. Coursera가 Scala로 만들어졌다.
• Typesafe Activator 템플릿들을 살펴봐라. 다른 언어들에 비해 온라인 문서나 학습자료가 부족하기도 하지만, 다른 사람 코드를 분석하는게 제일 좋은 방법이기도 하다. 특히 James Ward같은 능력있는 개발자들이 짠 코드라면.
• 가능하면 Coursera의 Principles of Reactive Programming 코스를 들어라. 스칼라와 대량 데이터 처리를 위한 Akka를 사용하려는 개발자들에게 좋은 자료다.
• 스칼라 모임에 참석하고 스칼라를 사용하는 실무자들이 어디에 쓰는지 배워라.
• Functional Programming Patterns in Scala and Clojure를 읽어라. 예전의 명령형 스타일 코드와 더 읽을만해진 함수형 스타일 코드를 비교해보고 더 함수형의 언어를 배우고 싶어졌다. 하스켈은 좀 과하고, 그래서 Clojure를 배우기 시작했다. 그리고나서 내 스칼라 코드는 더 간략해지고 더 의미있어졌다.

4. 온라인에서 읽는 것들은 적당히 감안해서

Scalaz를 만든 토니 모리스처럼 다른 세계에서 온 똑똑한 개발자들이 많이 있다. 하스켈 세계나, 함수형 프로그래밍, 그리고 수학 분야.

토니는 다음과 같은 함수 선언에 반대를 한다.

1

def reverse[A]: List[A] => List[A]

그리고 이런 선언을 더 선호한다.

1

def <-:[A, B](f: A => B): List[A] => List[B]

다음에 <-:라는 이름의 함수를 보면 이렇게 생각해라, "으악, 읽기도 구리고 내가 뭘 하고 있는거야?", (아마 친근보다는 좀 강력한) 다른 툴은 없는지? 이거 타입은 뭐지? 대수적인 속성은 뭐지? 드러난 속성들이 또 뭐가 있지?

Sticks, stones, but names are not useful to me by Tony Morris

이게 스칼라의 미학이다. 토니도 맞다. 틀린건 없고, 그냥 개인과 팀의 선택에 대한 문제다. 나는 <-:보다 reverse를 더 선호하지만, 내가 가독성과 단순성을 선호하는만큼 토니같은 개발자들은 수학적인 순수성과 사실성을 선호한다. 이 스타일들은 항상 다른 것 같다. 토니는 라이브러리들을 개발했고, 나는 라이브러리들로 어플리케이션을 만들고, 우리 둘 다 스칼라로 개발한다. 나는 가끔 var를 쓰고 나중에 걷어내지만, 누군가는 그걸 질색한다.

그런데 팀에서 사람들이 영어, 불어, 독어 같이 한 언어가 아닌 여러 언어를 쓴다고 해보자. 이럴 때 함수 이름을 영어 동사로 써도 그러려니 한다. 내가 같이 일했던 캐나다 사람들은 영어와 불어를 쓰는 사람들이 많았고, 헝크러진 머리나 좁쌀만한 눈(역주, 미국인이 캐나다인을 놀릴 때 주로 쓰는 표현)보다는 보기 괜찮다고 확신할 수 있다. 젠장(Sacré bleu!)

스칼라처럼 독선적이지 않은 언어는 그래서 아름답다. 자기 스타일을 자유롭게 적용할 수 있고, 언어가 그걸 방해하지 않는다. <-:도 쓸 수 있다는게 마음에 든다.

5. 주머니가 허락한다면 기술지원을 받아라

나는 운좋게도 타입세이프의 Nilanjan Raychaudhuri와 Roland Kuhn같은 진짜 고수들에게 배워서 Nurun에 설계 리뷰, 코드 리뷰, 페어 프로그래밍을 도입할 수 있었다. 새로운 프로그래밍 스타일을 배운 덕분에 신뢰도를 월등히 높인 프로젝트를 진행하면서 다방면으로 값으로 따질 수 없는 도움을 받았다.

단순히 스칼라의 함수형 스타일뿐만 배운게 아니라, 리액티브 프로그래밍 컨셉도 배웠다. Play와 Akka도. 새로운 테크닉들과 프로젝트 전반에 걸쳐 타입세이프의 도움을 많이 받았다. 우리가 항상 제대로 된 길을 가고 있는지에 대해 확신을 받았다.

타입세이프의 이메일 지원 역시 훌륭하다. 지원 구독은 주머니가 허락한다면 지출할 가치가 충분히 있다.

6. 다양성을 포용하라

스칼라 커뮤니티에는 전세계의 다양한 프로그래머들이 모여있다. 나처럼 전직 자바 개발자도 있고, 학계에서 온 사람들도 있다. 독학한 개발자도 있고 박사학위자들도 있다. 빠듯한 예산으로 사업문제를 해결하려 하는 사람들도 있고, 관심분야를 넓히려고 하는 사람들도 있다. 어플리케이션을 만드는 사람도 있고, 라이브러리를 만드는 사람도 있다.

커뮤니티의 모든 사람을 존중하고 이해하는게 좋은 개발자가 되는데 중요하다. StackOverflow에 단순한 질문을 올렸는데, 이해하려면 카테고리 이론을 몇년 배워야하는 난해한 답변이 달릴지도 모른다. 하지만 스칼라는 아직 새로운 언어이고 커뮤니티는 자기 색깔을 찾아가고 있다는 것을 염두에 둬라. 학계 출신이 아닌 개발자들이 스칼라 세계에 더 많아지고 더 많이 답변하다보면 토론은 조금 더 이론 개념보다는 어플리케이션 개념으로 옮겨갈 것이다.

답변에 실망했다면, 트위터의 Finagle이나 mDialog의 Smoke같은 라이브러리들의 소스코드를 봐라. 두 프로젝트는 제품 레벨에서도 많이 쓰이는 구현체로 훌륭한 스칼라 예제이다. 모든 스칼라가 어마어마하게 복잡하지는 않다.

7. 현실적인 목표를 설정하라

자바에서 온 신입 스칼라 개발자들은 하룻밤만에 고급 스칼라, 함수형 스칼라를 배울 수 없다는 사실을 깨달아야한다. 전형적인 비지니스 어플리케이션을 성공적으로 개발하는데 고급 함수형 스칼라가 필요한건 아니다.

함수형 프로그래밍을 접해본 개발자라면 스칼라 스타일로 익히데 시간이 덜 걸릴 것이다. 그렇지만 팀원들 대부분이 명령형 언어 개발자들이라면 스타일을 맞춰야할 것이다.

그리고 팀 밸런스에 대한 것인데, 유지보수해야할 사람이 이해할 수 있는 코드를 짜야할 것이다. 아무리 전세계에서 가장 우아한 코드라도 관리할 수 없으면 쓸모없다.

8. 짝코딩과 코드리뷰는 의무

짝코딩을 하면 팀 전체 스타일과 기술 평균에서 너무 멀어지지 않게 해주는데 효과적이다. 마지막으로 바라는게 필멸자들이 감히 범접할 수 없는 어려운 코드를 짜거나, 팀원들이 다들 준비가 될 때까지 다시 완벽하게 작동하는 명령형 코드로 짜는 것이다. 실험은 중요하지만, git은 두었다 무엇하는가. 포크해라, 두번해라.

스칼라의 유연성 덕분에 복잡함의 칼날을 피하는 것도, 언어의 새 기능이나 스칼라의 표현력을 익히기 쉽다. 문화는 언제나 개발팀에게 중요하지만, 더 중요한건 스칼라를 처음 배울 때 다같이 페달을 밟아 나가야한다는 것이다.

9. 간결함을 유지하라

스칼라는 새로운 것이고, 사람들은 무엇을 써야하고 무엇을 피해야할지 여전히 배우는 중이다. 더글라스 크록포드가 스칼라를 마스터하고 Scala: The Good Parts를 쓰기 전까지는, 언어의 각 부분에 대한 가치를 알아서 확인해야한다. 옳고 그름은 없고, 단지 시도와 실패만 있을 뿐이다. 뭐가 더 맞는지에 대해 얼마든 질문해라.

Reflection API가 처음 자바에 도입되었을 때, 모든 자바 개발자들이 자신들의 지적 능력을 동원해 모든 것에 리플렉션을 사용하려고 했다. 당시 내가 개발하던 코드들은 관리하기가 더럽게 복잡해졌고, 한 개발자가 미쳐날뛰어서 이해하지 못하는 기능을 남용했다는 것 말고 다른 이유는 없었다. 모든 생소한 기능은 발을 담그기 전에 천천히 깨끗하고 심플한 코드를 짜는게 더 낫다. 고급 테크닉을 이상하게 뒤죽박죽으로 구현한 것보다 깔끔하게 명령형 스타일로 스칼라 코딩을 하는게 차라리 낫다.

좋은 음악처럼 좋은 코드도 우아하고 드물다. 좋은 음식에 꼭 좋은 재료가 들어가는건 아니다. 상상할 수 있는 모든 향신료가 들어간 음식을 먹고 싶어할 사람이 있을까? 코드를 쓰는 것도 그렇다. A1급 개발자가 쓴 신뢰할만한 코드는 자기가 뭘 하고 있는지 왜 하는지도 모르며 제멋대로 짠 A3/L3급 개발자의 코드보다 더 관리하기 쉽다.

10. 구린 코드를 살펴봐라

심각하게 구린 스칼라 코드를 짤 수도 있고, 자바, 펄, 그리고 영어도 마찬가지다.

하지만 구린 자바코드와 구린 스칼라코드의 중요한 차이가 있다.

구린 스칼라 코드는 좀 다른 방식으로 구리다. 명령형으로 구리거나, 함수형으로 구리거나, 혹은 두가지가 섞인 채로 구리거나. 이해할 수 없을 정도로 구리다면 익숙하지 않은 스타일이라서 그럴 수도 있다. 스칼라는 새로운 언어라, 자바같은 성숙된 언어처럼 바로 안티패턴을 발견해내는게 아직은 어렵다. 그래서 개발팀들이 아름다운 코드를 구리다고 착각할 수도 있고, 구린 코드를 아름답다고 착각하게 될 수도 있다. 개발자들은 배운대로 구린 패턴을 짜기 시작하면 나중에는 더 구린 코드가 나온다. 그렇게 악순환이 된다.

나중에 고치려고 하는 것보다 처음부터 피하는게 더 좋다.

똑똑한 개발자가 스칼라로 이상하게 코딩한다면 불러봐라. 질문해라. 익히지 못한 언어에 대해 추측하지마라. 최악의 경우는, 잘못짰으면서 우아한 코드라고 생각은 하는데, 왜 우아한지 이해하지 못하는 경우다.

11. 스칼라는 단지 퍼즐의 일부분

웹 어플리케이션을 개발하는 방법은 10년전에 비하면 매우 다양하다. 요새는 스칼라, 플레이, AngularJS, MongoDB 앱을 개발한다. 내가 짜는 코드 대부분은 클라이언트단이다. 몇년간은 스칼라보다 Angular를 더 많이 짰는데, 나쁘다는게 아니라 그냥 현실이 그렇다.

스칼라의 미학은 자바처럼 쓸데없는 밑바닥을 만들어야하거나 루비같은 동적 언어의 불안함을 걱정할 필요없이 깔끔하고 안정적이고 성능좋은 서버단 코드를 짤 수 있게 해준다는 것이다. 스칼라로 짠 서버쪽 로직은 견고하기에 클라이언트쪽 코드를 안정적으로 짜는데 시간을 투자할 수 있다.

스칼라의 모든 쪽에서 마스터가 되고 싶어하는만큼 파고들어야할 기술들이 너무 많다. HTML5, SASS, AngularJS, RequireJS, SQL, MongoDB, 또, 또, 또.

한 언어의 모든 면을 마스터할 시간은 없겠지만, 스칼라는 맛을 보기만 해도 괜찮은 기술이다. Reactive Programming은 다음 세대의 대세가 될 것이며 그 패러다임 전환의 선두에 스칼라가 있을 것이라 믿는다. 성능과 안정성을 모두 얻을 수 있는 리엑티브 어플리케이션을 무시하기는 힘들다.

요즘엔 대부분 묵직한 XML 대신 JSON을 쓴다. SOA 패턴 대신 REST를 쓴다. 데스크탑 대신 모바일을 쓴다. 어마어마한 크기의 데이터에서 필요한 정보를 뽑아낼 때, Akka의 성능이라면 막대한 하드웨어를 투자하지 않고서도 가능하다.

스칼라는 퍼즐의 한 부분일 뿐이지만, 새로운 종류의 개발을 위해 필요한 다른 많은 부분들의 심장과도 같다.

12. 스칼라를 배우면 더 좋은 프로그래머가 된다

직장인 개발자가 자기 영역을 넓히는건 정말 드문 일이다. 소프트웨어 개발에서 완전히 다른 접근법을 배워본게 마지막으로 언제인가?

마지막 전환(그리고 내 경력에서 겪었던 유일한 전환)은 절차지향 언어에서 객체지향 언어로의 변환이었다. CIBC에서 인턴하던 1998년에 운좋게도 첫 자바 어플리케이션 개발자 중 하나가 될 수 있었다. 대부분의 개발자들은 전직 COBOL이나 C였다가 전환하는 시점이었다. 요새는 뭐든 다 자바를 쓰지만, 당시에 윈도우와 OS/2에 모두 배포해야하는 상황에서 자바는 매우 실용적이었다.

2-30년 경력의 개발자들(몇명은 실제로 펀치카드로 프로그래밍을 해봤던)과 일하면서 좋은 경험을 쌓았고, 한가지 스타일에 매이면 안된다는 것을 깨달았다. 자바를 배울 때 JCL도 관리해야했다. 바로 다시 복귀하기 몇달전까지는 old COBOL과 360 어셈블리도 파고들었다. 넓게 보자. JCL과 COBOL이 섹시한 언어는 아니지만 필요한 분야에서는 괜찮은 언어다. 인턴시절 스몰토크에서 엑셀까지 모든 것을 겪어볼 수 있었다. 엑셀은 처음 접한 함수형 프로그래밍이다. (역주: 엑셀이 함수형 프로그래밍을 지원하는지에 대한 StackExchange의 글이 댓글에 있다.)

스칼라는 부당한 평을 많이 받았다. 어떤 개발자들은 생각을 깊게 하기보다는 잠깐 시도해보고 익숙한 언어로 도망친다. 문제는 그 사람들이 인터넷에 남긴 불평들 때문에 관심있어하는 개발자들에게 언어의 가치가 잘못 전달될 수도 있다.

스칼라에 대한 불만을 읽는다면 누가 썼는지 찾아보기를. 다른걸 원한 사람일 수도 있다. 쉽게 흔들리지 말고, 불평하는 사람들에게 얽매이지 마라. 점점 널리 퍼져가는 스칼라의 성공사례들을 찾아보기를 바란다.

결론

스칼라는 기술뿐만이 아니라 문화적인 투자다. 투자할만한 가치가 있는 보상이 있는데, 어쨋든 해봐야하지 않을까? 확장가능하고 믿을만하고 관리하기 편한 프로젝트를 진행중이라면, 혹은 프로그래머로서 사고를 확장하고 싶다면 단언컨데 스칼라는 할만 하다. 기본만 있으면 보이는 것만큼 어렵지도 않다.

스칼라는 실무에서도 쓸만하다는걸 기억해라, 아니 이미 쓰이고 있다.

이런 테크닉들을 익혔을 때의 좋은 부가효과는, 사용하는 모든 언어에서 더 좋은 개발자가 된다는 것이다. 나는 스칼라와 자바스크립트 모두에서 클로저나 다른 테크닉들을 익히는데 정말 도움이 됐고 더 좋은 자바스크립트 프로그래머가 되었다.

스칼라로의 전환에서

스칼라를 도전해본 것은 이번이 처음이 아니다. 함수형에 대해 이름만 알던 차에 자바 개발자를 위한 함수형 프로그래밍를 읽고 함수형이라는 개념을 더 배우고 싶어했고, 코세라(Coursera)에 가입하게 된 계기이자 처음으로(그리고 현재로서는 마지막으로) 수료한 스칼라로 배우는 함수형 프로그래밍 기초로 함수형이라는 패러다임을 잠깐 맛보았다. 그리고 1년 정도 손을 놓았다가 리액티브 프로그래밍 기초에 다시 도전했다가 영어 실력의 한계와 스칼라의 이해가 부족했다라는 점만 뼈저리게 깨닫고 중도포기를 했다. 그리고 쉽게 배워서 빨리 써먹는 스칼라 프로그래밍를 통해 문법은 리뷰할 수 있었지만 언어 자체와 함수형에 대한 이해도가 좋아지진 않았다.

스칼라를 더 공부해보고 싶다는 막연한 생각은 가지고 있었고, 함수형에 대한 재미 때문에 underscore/lo-dash를 다양하게 써본다거나 함수형 자바스크립트 책을 재미있게 읽기도 했고, 파이썬을 다시 써볼까 싶어서 나간 스터디에서 프로젝트 오일러의 문제를 최대한 함수형으로 풀어보면서 더 간결한 코드 작성이 가능해졌다는걸 느꼈다. 그러던 차에 내가 들었던 두 강의의 교수이자 스칼라를 만든 마틴 오더스키의 책, 스칼라 프로그래밍 2판 번역판이 출간된다는 이야기에 많이 기대하고 있었다. 책 내용과 관련없는 이야기를 길게 늘어놓은 이유는, 내가 생각하기에 나는 초심자와 다름없는 수준같지만 그래도 완전히 스칼라를 처음 접하는 사람과 느끼는 부분이 다를 수 있어서 겪어온 과정을 적어봤다.

첫번째 장에서는 스칼라의 특징들에 대한 설명과 어떤 언어에서 어떤 장점들을 가져온 것인지에 대해 나열하며 앞으로 배울 것들에 대해 개요를 보여준다. 하지만 언어론에 대해 관심이 있는 사람이 아니라면 적당히 훑어보고 나중에 다시 읽거나 아니면 구조적인 내용(10장 상속과 구성)이 나오기 전까지 읽고 나서 언어에 대한 감을 잡고 다시 1장을 읽어보기를 권한다. 1장을 (체감상)세 호흡 정도로 읽었다면 2장부터 9장까지는 거의 한 호흡에 집중해서 쭉 읽었다.

2장부터는 필요할 때 REPL로 한줄 정도 테스트해보면서 쭉 읽어나갔다. 그래도 문법에 대해서는 어느 정도 알고 있어서 무난히 넘어가긴 했지만, 이 책으로 처음 스칼라를 접한 사람들에게는 코딩을 시도해볼 여지가 별로 없다. 새로운 언어를 배울 때 이것저것 시도해보면서 체득하는 것이 중요하다고 생각해서 이 책의 그나마 단점이 있다면 그런 면이 아닐까 생각한다. 위에서 언급한 쉽게 배워서~의 경우에는 설명이 빈약해서 그 책만으로 스칼라를 이해하기 어렵지만 챕터마다 연습문제가 있어서 이 책을 읽으면서 같이 진행한다면 좋은 부교재가 되지 않을까 싶다.

추천 챕터

오랜만에 끝까지 정독한 책이지만 아직 완전히 이해했다고 생각하지 않아서 챕터들에 대해 평가를 내리기 조심스럽지만, 그래도 이 책을 읽을 사람들을 위해서 꼭 두번 읽고 넘어가라고 권해주고 싶은 챕터들이 있어서 메모를 해뒀다.

• 12.7 트레이트냐 아니냐, 이것이 문제로다: 어떨 때 트레이트로 만들어야하는지에 대한 가이드라인
• 15.1 패턴 매치(p322-324): 패턴매치가 어떻게 작동하는지에 대해 화이트박스로 설명하는 자세한 가이드
• 16.10 스칼라의 타입 추론 알고리즘 이해: 어떤 순서와 힌트로 타입을 추론하는지에 대한 매카니즘과 현재 불가능한 점.
• 22.1 List 클래스 개괄: 함수형 언어들에서 List(정확히는 cons 구조)가 왜 중요한지, 그리고 이 구조를 이해해야 지연 평가를 이해
• 24.15 뷰: Scala를 Scala답게 쓰기 위한 기능(자세히 설명하기 어렵지만 읽고 나면 이해될 것이다)

외부 라이브러리 사용

그리고 책에서는 scala.actors.Actor가 2.11부터 삭제예정(deprecated)이니 akka를 사용할 것을 권장하고 있는데, 2.11.0부터 아예 패키지 자체가 삭제되었다. 또, 2.11.0부터 독립한 다른 라이브러리들도 있다. Scala 2.11.0 API 페이지를 보면 다음과 같은 부분이 있다.

• scala.reflect - Scala's reflection API (scala-reflect.jar)
• scala.xml - XML parsing, manipulation, and serialization (scala-xml.jar)
• scala.swing - A convenient wrapper around Java's GUI framework called Swing (scala-swing.jar)
• scala.util.continuations - Delimited continuations using continuation-passing-style (scala-continuations-library.jar, scala-continuations-plugin.jar)
• scala.util.parsing - Parser combinators, including an example implementation of a JSON parser (scala-parser-combinators.jar)
• scala.actors - Actor-based concurrency (deprecated and replaced by Akka actors, scala-actors.jar)

책을 기준으로 akka를 제외하고 28장 XML 다루기(scala-xml.jar), 33장 콤비네이터 파싱(scala-parser-combinators.jar), 34장 GUI 프로그래밍(scala-swing.jar)이 해당된다. 신기한 것은 REPL로 한줄씩 테스트해볼 때는 몰랐는데, scala-xml이 독립했다는걸 보고 이클립스에서 프로젝트로 만들어서 실험해봤더니 XML 표현법(literal)에서 에러가 났다. REPL(scala)의 경우, bash script 파일인데 여기서 기본 라이브러리(homebrew로 설치한 경우 /usr/local/Cellar/scala/2.11.4/libexec/lib)를 classpath로 추가해서 실행되므로 가능한 것이다.

외부 라이브러리를 어떻게 사용하는지에 대해 나와있지 않아서 sbt를 사용해보려고 검색하다가 이 책의 역자인 오현석님께서 번역하신 트위터의 스칼라 학교의 빌드 도구 SBT(Simple Build Tool) 챕터를 참고해 시도해보려고 했지만, 간단한 의존성 추가에 너무 많은 공수가 들어서 sbt 레퍼런스에서 라이브러리 의존성를 참고해 build.sbt을 작성했다. 예를 들어 akka-actor만 추가할 경우에

1
2
3
4
5
6
7

name := "Ciruit Simulator"

version := "0.1.0"

scalaVersion := "2.11.4"

libraryDependencies += "com.typesafe.akka" %% "akka-actor" % "2.3.8"

혹은 여러 라이브러리를 한번에 명시할 경우 Seq를 사용해서

1
2
3
4
5
6
7
8
9
10

name := "SCells Spreadsheet"

version := "0.1.0"

scalaVersion := "2.11.4"

libraryDependencies ++= Seq(
    "org.scala-lang" % "scala-swing" % "2.11+",
    "org.scala-lang.modules" %% "scala-parser-combinators" % "1.0.3"
)

이런 식으로 프로젝트 루트에 build.sbt파일을 만들고, sbt update를 통해 가져온 뒤 sbt eclipse를 통해 이클립스에 import할 수 있는 프로젝트를 생성할 수 있다.

akka

책의 예제는 scala.actors가 기준이라 akka.actor로 예제 소스를 다시 쓰고 싶었지만 제대로 이해하지 못해서 도움이 될만한 글을 검색하던 도중 오현석님의 프로그래밍 인 스칼라 액터 예제 akka로 변환하기(1) - 간단한 액터를 발견해서 이 글과 마이그레이션 가이드를 읽고 시도해보려다가 잘 안돼서 다시 검색하던 도중 누군가 만들어준 프로젝트를 발견했다. 혹시 필요한 분들을 위해 남겨둔다.

책을 읽으면서 간략하게 메모해놓은 것을 토대로 짧은 후기와 함께 같은 고생을 할 분들을 위해 약간의 도움을 남기고자했는데 의외로 글이 길어졌다. 스칼라를 배우면서 좋았던건 처음에 언급했던 것처럼 함수형이라는 패러다임에 대한 이해에 도움이 된다는 것이었다. 설계부터 변경할 수 없는 값(immutable)이나 지연평가 등 함수형을 잘 살릴 수 있는 구조로 만들수도 있지만, 평소에 하던 스타일에 크게 변형을 주지 않으면서도 세세한 부분의 조금 더 좋게 개선할 수 있는 직교적(orthogonal)인 개념이라는 점에서 누구에게나 도움이 될 수 있지 않을까 생각한다. 다른 패러다임들이 무엇이 있을지 궁금해하던 차에 이 책을 읽는 도중에 발견했던 글이 있는데, AI의 대부격이라는 피터 노빅의 "프로그래밍 10년 완성"이라는 글에서 눈에 들어온 문단을 인용해본다.

프로그래밍을 정복하기 위한 나만의 비법이 있다:

• 최소 다섯가지 프로그래밍 언어를 배워라. class abstractions (자바 또는 C++) 지원하는 언어, coroutines을 (Icon 또는 Scheme) 지원하는 언어, functional abstraction (Lisp 또는 ML) 지원하는 언어, syntactic abstraction (Lisp) 지원하는 언어, declarative specifications를 (Prolog또는 C++ 템플렛) 지원하는 언어, 그리고 parallelism을 (Sisal) 지원하는 언어를 한개씩 배워라.

프로그래밍 10년 완성(번역)에서

업데이트 01(2015-01-19 02:40)

라 스칼라 코딩단의 슬랙 채널을 통해 오현석님의 조언을 받아, akka 부분과 REPL에서 scala-xml이 작동하는 이유에 대해 정정

Translation of "Prototyping swipe and drag gestures with Framer 3" into Korean, under the same license as the original.

우리는 Potluck에서 iOS앱에서 인터렉션을 테스트해보고 프로토타이핑을 하기 위해 Framer.js를 사용하기 시작했다. Framer는 모바일과 데스크탑 앱에서의 인터렉션 프로토타이핑과 에니메이션을 위한 자바스크립트 프레임워크다. 쿼츠 콤포저(Quartz Composer)보다 러닝커브가 훨씬 낮고 아이폰과 데스크탑 양쪽에서 쉽게 실행할 수 있는 훌륭한 대안이다. 키노트에서 시작해서 실제같은 인터렉티브 프로토타입을 단계별로 만들 수 있다.

자바스크립트 기반이기 때문에 특히 드래그나 스와이프같은 복잡한 제스쳐를 만들 때 좋다. 스와이프 거리에 따라 엘리먼트를 움직이거나 사라지게할 때 혹은 특정거리 이상 스와이프할 때 액션이 발생하도록 할 수 있다.

신생 프로젝트라 예제나 문서들이 너무 없다. 그래서 배웠던 것들을 공유하려고 생각했다.

시작하기 전에 타이핑하기 귀찮은 사람을 위해 [CodePen](http://codepen.io/seoh/full/AqycD에 완성본을 올려놨다.

Activate on release

다른 액션을 가진 테이블 셀들로 간단한 예제를 시작해보자.

일단 보통 아이폰 스크린을 표시하기 위한 컨테이너 뷰를 만들어보자. 시스템 상태바를 가진 웹앱을 프로토타이핑하기 위해 높이는 598px로 정했다. (역주, 원문에서는 1096px였지만 웹에서 확인하기 좋게 절반으로 줄였다.)

셀에서 사용자에게 보이는 부분을 정한 컨테이너를 만들고, 화면 밖에서 슬라이드하면 셀이 나타나도록 할 것이다.

이렇게 보일 것이다.

이제 셀에 드래그를 추가해보자.

원하는 기능은 아니지만 어디로든 드래그할 수 있다.

더 구체적인 제스쳐를 구현하기 위해 드래그 이벤트 핸들러를 사용할 수도 있다. 뭔가 드래그할 때 세가지 이벤트가 발생한다. Events.DragStart는 드래그를 시작할 때 한번, Events.DragEnd는 드래그를 놓았을 때 한번 발생한다. Events.DragMove는 마우스나 손가락을 움직일 때 계속 발생한다.

draggable은 "speed" 속성을 갖는데 마우스 움직임에 따라 어느 정도의 속도로 움직일지 결정한다. 속도를 0으로 설정하면 물체가 해당하는 방향(축)으로 이동하지 않게 된다.

드래그가 끝났을 때 무엇을 할지 정할 수도 있는데, 여기에서는 원래 물체를 자리로 돌아가게 해보자.

이제 화면 밖의 엘리먼트가 드래그할 때 나타나도록 해보자. 그 엘리먼트는 셀 컨테이너의 차일드 뷰가 될 것이고(그래서 셀과 함께 움직일 것이고) 그냥 화면 밖에 놓도록 하겠다.

이 액션 바를 추가한 다음에 셀을 왼쪽으로 끌면 화면 오른쪽 끝에서 나타나는걸 볼 수 있다.

좀 재미있는걸 넣어보자. 드래그 핸들러는 액션 바를 조금이라도 움직일 때마다 실행되는데, 얼마나 셀을 움직이는지에 따라 색깔을 바꾸게 만들 수 있다.

(얼마나 셀을 움직였는지에 대한)범위를 다른 (바의 색상)범위로 바꾸는 것은 Utils.mapRange 함수를 통해 쉽게 할 수 있다.

(역주: 원문은 원래 framerjs 2를 기준으로 작성되어 Proccessing 프레임워크의 map_range라는 함수를 사용했는데 중요한 정보는 아니다.)

이 함수에서는 [low1, high1] 범위에 있는 value를 [low2, high2] 범위에서의 같은 위치(비율)로 변환해준다. 이제 셀의 x축 좌표를 액션 바의 투명도로 바꿔보자.

셀을 드래그할 때 액션 바의 색은 다음과 같이 변한다.

충분히 액션 바를 드래그했을 때는 그대로 열려있도록 만들고 싶다. 이걸 하려면, DragEnd 핸들러에서 얼마나 드래그되었는지 확인하고 특정 너비를 넘었다면 계속 열려있도록 해보자.

Activate on threshold

탭을 밀었을 때 계속 열려있도록 해봤다. 탭까지 가지 않고 액션을 할 수는 없을까? iOS 6의 당겨서 새로고침이 좋은 예다. 충분히 당기면 탭까지 가지 않아도 새로고침이 일어난다. (역주, 여기에서는 특정 길이만큼 드래그 후 이벤트 발생으로 애니메이션을 실행하는 것까지만 예제로 한다.)

위아래로 움직이는 두번째 셀을 만들어보자.

셀을 100px 아래로 내리면 쪼그라들게 해보자. 일단 이렇게 시도해봤다.

애니메이션이 좀 산만하다. 드래그할 때마다 계속 DragMove 이벤트가 발생하고 계속 애니메이션을 시작하려고 한다. 그래서 조건이 만족될 때 딱 한번만 발생하도록 해보자.

(역주, 원문에서는 Drag와 Animate 기능이 충돌해서 제대로 Animate가 작동하지 않아 Drag하는 레이어와 Animate되는 레이어를 따로 뒀는데 버그가 수정되었는지 잘 작동해서 그 이하 부분은 생략했다.)

아이폰에서 테스트

Framer Studio 1.7에서 Mirror라는 굉장히 편한 기능이 추가되었다. Studio에서 작업한 내용을 저장하고 Mirror 버튼을 누르면 작업중인 컴퓨터를 자동으로 서버로 사용해서 외부에서 접근할 수 있는 주소를 생성해준다. (역주, 원문에서는 Dropbox Public folder에 대한 내용이었지만 Mirror 기능이 더 유용하다고 생각해서 변경했다.)

1. 스코프 내의 변수 잡기

클로저는 사용자의 코드 안에서 전달되거나 사용할 수 있는 기능을 포함한 독립적인 블록(block)입니다. Swift에서의 클로저는 C 및 Objective-C 의 blocks와 유사하며, 다른 언어의 람다(lambda)와도 유사합니다. 클로저는 자신이 정의된 컨텍스트(context)로부터 임의의 상수 및 변수의 참조(reference)를 획득(capture)하고 저장할 수 있습니다.

09 클로저 (Closures) by inureyes

for-loop(for var...)의 스코프에 있는 변수를 사용하는 함수를 만드는데, 해당하는 변수의 값이 스코프 내에서 계속 변하는 경우에 loop가 끝난 뒤 당연히 마지막값을 기준으로 함수가 실행되는 상황에서 현재값을 저장할 수 있는 방법에 대한 문제였다.

해결책은

1. 변수를 다시 캡처한다. var _i = i
2. for-loop를 돌 때 for var...가 아니라 for-in으로 돌면 상수let가 되어 따로 캡처할 필요가 없다.
3. 값을 받아서 그 값을 캡처하는 함수를 리턴하는 함수를 만든다.

1
2
3
4
5
6
7

func capture(i:Int, closure:Int->Int) -> ()->Int {  
    func sth() -> Int {
        return closure(i)
    }
    return sth
}
// capture(i){ $0*$0 }

3번의 경우를 더 간단하게 만들기 위해서 JavaScript의 즉시실행함수(IIFE)를 흉내내고 싶었는데, Swift의 버그 때문에 현재 단순히 값만 리턴하는 IIFE도 var는 안되고 let을 써야 타입 추론이 가능하며, let을 쓰더라도 함수를 리턴하는 경우에도 에러가 나고, IIFE 속에서 조건문(conditional statement)이 존재할 경우 경우의 수에 대한 superset을 추론하는게 아니라 그냥 에러가 난다.

2. 부분함수와 합성함수의 단계적 구현

2.1. 기본 구현

Swift에서도 함수형 프로그래밍 스타일을 지원하도록 Array에 filter, map, reduce 등의 메소드들이 존재해서 array.filter{}.map{}.reduce(){} 같은 스타일로 작성할 수 있다. 그래서 특정 조건까지의 배열을 뽑아서(take) filter와 map을 체이닝해서 변이(tramsform)된 배열을 구하는 문제부터 시작했다. 앞/뒤에서 특정 길이만큼 읽는 함수는 Swift의 기본 라이브러리에서 prefix와 suffix를 통해 지원하고 함수형 프로그래밍에서는 보통 take/takeRight라는 이름으로 지원된다. 특정 조건까지 읽는 함수는 takeWhile이라고 보통 부르는데, Swift에서 구현되어있지 않아서 도장에서는 ExSwift에 있는 takeWhile의 소스가 제공되었다.

2.2. Pythonic solution

Python, underscore.js처럼 filter/map/reduce라는 함수에 sequence를 인자로 넘기는 식으로 개발을 하다보면 체이닝이 아니라 reduce(map(filter(... 처럼 전역함수를 이용해 구현할 수도 있는데, 이럴 경우에는 실행되는 순서와 함수호출의 순서가 역순이고, 값을 평가하는 함수를 인자로 넘길 때 인자로 받는 전역함수와의 거리가 멀어져서 가독성이 떨어지는 문제가 생긴다. 이 문제를 부분 함수(partial function)와 합성 함수(compose function)을 이용해서 인자를 받는 순서를 바꾸면 훨씬 가독성이 올라간다.

2.3. Functional Programming

함수형 프로그래밍으로 구현하기 위해서는 일단 1급 시민(first-class citizen, 혹은 1급 함수나 1급 객체 등으로 불린다)이라는 개념에 대해 이해가 먼저 필요하다. Java의 경험이 있다면 함수형 언어로 가는 길 (중편) - 일급객체, JavaScript의 경험이 있다면 Javascript : 함수(function) 다시 보기라는 자세한 설명의 글들이 있고 영문으로는 더 자세하고 풍부한 자료들이 있다. 그리고 함수형 프로그래밍에 대한 패러다임의 이해도 필요한데, 가장 좋은 방법은 함수형 프로그래밍을 지원하는 언어를 배우는 것이다. Twitter에서 만든 Scala School이라는 Scala 입문 강의가 있는데 한글 번역도 존재한다. 혹은 Java 경험이 있다면 자바 개발자를 위한 함수형 프로그래밍라는 eBook을, JavaScript 경험이 있다면 함수형 자바스크립트라는 좋은 책들도 있다.

2.4. Solution

다시 도장 이야기로 돌아가서, 이 문제를 해결하기 위해 영후님은 F#이라는 언어의 pipe-forwarding(|>)이라는 연산자를 구현하셨다. Swift에서의 pipe-forwarding |>의 구현이라는 글을 읽어보면 구현체와 그 설명이 자세히 나와있다.

도장에서 나온 문제와 일치하지는 않지만 위에 나온 과정들을 종합해보면 이런 예제를 만들 수 있다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

infix operator |>   { precedence 50 associativity left }

public func |> <T,U>(lhs: T, rhs: T -> U) -> U {  
    return rhs(lhs)
}

func ifilter<T>(closure: T->Bool) -> [T]->[T] {  
    return { filter($0, closure) }
}

func imap<T,S>(closure: T->S) -> [T]->[S] {  
    return { map($0, closure) }
}


let list = [1,2,3,4,5]  
         |> ifilter  { $0%2 == 0 }
         |> imap     { $0*2 }
         |> imap     { String($0) }

println(list) // ["4", "8"]  

3. Accumulator

누산기(accumulator)는 함수 하나를 리턴하는데, 그 함수는 인자를 하나 받을 때마다 그 값들이 누산된 결과를 리턴한다. 클로저에서 값을 캡처해서 리턴하는 것은 1번 문제에서 했고, 캡처된 값을 변경하도록 하는 것과 파라미터로 정의된 값을 다시 변수로 사용해서 소스코드를 짧게 만들도록 구현하는게 목적이었다.

4. Jensen's Device

이번에도 알고리즘 문제가 하나 나왔다. Jensen's Device라는 문제로 한 변수를 캡처하고 있는 클로저를 계속 이용해서 따로 변수 선언없이 파라미터만으로 문제를 해결하도록하는 문제였다. 인자로 넘길 때 스코프 명시({})없이 쓸 수 있도록 해주는 @auto_closure라는 키워드에 대해 배웠다.

5. Conclusion

1회의 난이도가 1이었다면 이번 난이도는 10쯤 된다. 다음의 난이도는 얼마나 될지 모르겠다.