유쾌한 혁명을 작당하는 공동체 가이드 북

이책은 독서모임에 나가기 위해 구입하고 읽기 시작한 책이지만 읽기 시작하면서 몇번을 실패했다. 이유는 내가 그냥 여유가 없었다. 바쁘고 피곤하고 집중도 안되고, 몇번을 읽다가 접었다. 일단 초반부 내용이 너무 평이해서 건질게 없거나 재미가 없거나 아님 내가 집중을 못하고 있거나…

책을 한참 읽어 제끼는데 페이지 수만 증가하는 그 느낌을 아는가? 딱 그랬다. 역시 내가 아직 책을 받아들일 준비가 안되어 있구나 싶다. 그래서 한 2주일간 책의 한글자도 읽지 않았다. 그리고는 결국 모임을 1주일 앞두고 다시 처음부터 머릿말과 번역자의 말부터 읽기 시작했다. 음… 아.. 그렇구나.

나는 늘 닥쳐야하는 성격인지라 날짜가 다가오니 집중력이 살아나기 시작한다. 평소엔 자차로 출퇴근하느라 도통 책 읽을 시간이 없었는데 저녁 수업에 대중교통을 이용하게 되면서 책읽을 짬이 나기 시작했다. 읽어보니 또 금방 잘 읽힌다. 뭥미~

여튼 생각나는 구절만 적어본다. 사실 아직도 다 못읽었다. ㅎㅎㅎ

행복을 만드는 4대 요소

이 책에서는 행복을 만드는 4대요소로 관계와 소명, 유희 그리고 통제라는 키워드를 꼽았는데 그중에서 인상적이었던 것은 유희와 통제였다. 유희란 그냥 재밌으면 되는거 아니야? 생각했는데 여기서는 지금 이 순간을 즐기라는 뜻이 강했다. 첨엔 뭔소린가 했다. 음악 감상하면서 딴생각하고 영화보면서 딴생각한다면 그것은 그 순간을 즐기지 못한다는 것이다. 그리고 이런 유희의 유례도 그런가 싶을정도로 설득력이있다. 일하면 천국간다라는 믿음을 지배했던 청교도 문화권보다 카르페디엠이 지배한 남미 문화권이 훨씬 더 행복하다는 것이다. 안그래도 오늘 여행 스터디 댕겨왔는데 남미를 그렇게 찬미하더라. 한국과는 정반대인 남미는 한국에서 가장 먼 곳이라 인생에 2번가기 힘든 곳이라니 이번에 꼭 가봐야겠다는 생각이 든다. 아직 11월이 되려면 시간이 좀 남았지만 그동안 막연하게 세계여행을 꿈꾸면서 구체적인 플랜은 가서 짜지뭐~ 했는데, 론니 플래닛으로 일정 짜는 방법을 듣다보니 지름신이 도졌다. 나 킨들 살꺼다!! 킨들에선 론니 플래닛이 무료란다. 언제까지 할런지는 모르겠지만 당장 구매해야겠다.

다시 돌아와서 대부분 어떤 문제에 통제를 가한다면 개인적인 문제로 치부하기 마련인다. 이 책의 저자는 개인이 속한 공동체의 문제로 보고 그것을 해결하라고 주장한다. 이것이 이책의 핵심인듯 싶다. 그래서 공동체의 문제를 해결하기 위한 방안으로 작은 공동체를 어떻게 만들고 이끌어가는지에 대한 얘기를 하는 것 같다. 아직은 다 안읽은 상태에서 섣부른 전망이겠지만.. ㅎㅎ 동구밭이란 모임도 그렇고 맥주파티도 그렇고 패치패치도 그렇고 뭔가 맘맞는 사람들과 놀다보면 이사람들과 평생 같이 하고 싶다는 생각이 드는데,.. 이 저자도 같은 마음으로 책을 쓰지 않았나 싶다.

유쾌한 공동체 만들기

책을 읽다보면 요즘 나의 생활과 대입해서 보게된다. 매번 적자를 내면서도 맥주파티를 기획하고 사람들과 두런두런 이야기하며 여유롭게 노는게 좋다. 복잡한건 싫고 작은 모임을 선호한다. 가장 좋은 호스트는 손님을 신경쓰지 않고 내버려두는 사람이라한던데 딱 나다. 이 책에서 가이드 하듯이 다음 모임을 만든다면 모임에 오는 사람들을 반갑게 맞이하는 스탭을 구성해봐야겠다. 그리고 강의를 나가면 꼭 서너 명씩 작은 그룹으로 모아놓고 피드백도 받아봐야겠다. 책에 집중을 잘 못하는지 책 읽으면서 자꾸 잡다구리 생각이 떠올라 트랠로에 메모를 하고 폰에 메모를 하고 머리속에 생각을 정리하면 다시 책으로 돌아오니 진도가 잘 안나간다. ㅎㅎㅎ

나와 타인을 위한 대화법

요즘 한꺼번에 엄청 많은 일들을 처리하고 있는데 그중 하나가 비폭력 대화라는 수업이다. 이책에서는 비폭력 대화라는 단어를 쓰지는 않았지만 비폭력 대화에서 가르치는 대화법과 굉장히 유사한 내용이 많다. 결국 사람과 사람이 모이는 곳에는 대화가 중요하기 때문에 의미있는 대화를 효과적으로 이끌어내는 대화법을 소개한다. 비폭력 대화도 늘 내 입말 속에 평가의 말이 들어가 있진 않은지 내가 제대로 관찰하고 있는지 나의 느낌은 어떻고 내재된 욕구는 무엇인지 자꾸 의식적으로 생각하며 대화하는 연습을 하는데 책에서도 같은 맥락의 이야기가 여러번 나온다.

Swift 공부하면서 새롭게 알게된 내용 정리

sorted VS. sort

“자바스크립트 같은 스크립트 언어를 기존에 써왔던 사람이라면 Swift라는 언어는 비교적 쉽게 배울수있는 것 같다.” 라고 생각했다가 뒤통수 맞는 것들이 몇가지 있는데 그중에 하나가 바로 sorted 함수와 sort 함수다. 둘의 차이는 정렬을 해서 반환값이 있냐? 없냐의 차이!

mutating func sort(isOrderedBefore: (T, T) -> Bool)
func sorted(isOrderedBefore: (T, T) -> Bool) -> [T]

함수 시그니처만 봐도 sort는 반환값이 없다. -_-;;

참고, Javascript 에서 sorted 함수는 당연히 없고, sort 함수는 본래 배열을 정렬시키고 정렬된 값을 slice해서 새로운 값으로 반환한다. 즉, Swift의 sort 와 sorted 두가지 역할을 모두 수행한다.

극강의 타입 추론 능력!

Swift 의 또 다른 매력이라고 하면 타입 추론을 빼놓을수없다. 얼마나 똑똑한 언어인지 개발자의 귀차니즘을 많이 줄여준다(?) 하지만 단점은 이게 뭔소린가하는 느낌을 줄정도다. 하지만 타입 추론 방식을 좀 이해하고 나니 지금은 꾀나 익숙해졌다.

var arr = [6,2,1,2,3,3]
arr.sort(<)   <--- 이게 뭐얌?             --- 1번
println(arr)   // "[1, 2, 2, 3, 3, 6]"

arr.sort(<) 이게 도대체 뭔소리야 하는 사람도 있겠지만 결과는 오름차순 정렬이다. sort 함수는 인자로 오퍼레이터를 받는건가? 라고 생각할수도 있겠지만 사실 위 코드는 아래와 같이 풀어 쓸수도 있다.

var arr = [6,2,1,2,3,3]
arr.sort{$0 < $1} <--- 이건 또 뭐얌?      --- 2번
println(arr)  

당연히 2번은 1번과 같은 코드다. 2번에서 $0과 $1이라는 변수는 Swift에서 인자의 타입이 무엇이 정확하게 추론이 가능할때 타입 이름을 특별히 지정하지 않아도 쓸수있는 키워드 정도로 이해하면 된다. 물론 인자가 3개라면 $2도 쓸수있다. 그렇다면 이 함수의 원형은 어떻길래 추론이 가능한걸까? 추론 되기전 상태로 좀 더 거슬러 올라가보자.

var arr = [6,2,1,2,3,3]
arr.sort{                              --- 3번
   (t1, t2) -> Bool in
   t1 < t2  
}
println(arr)  

3번에서 sort 다음에 {} 중괄호는 일단 넘어가자. 괄호안에 in 이라는 키워드는 이 함수가 클로저 함수임을 나타낸다. 즉 in 앞에 내용이 이 함수의 시그니처다. 그러니까 인자 2개를 받아서 Bool형으로 반환한다는 이야기!! 뚜둥~!! 그런데 또 여기에 return 문이 없다. Swift 에서 함수의 마지막 문장은 return 문이 없어도 그 문장의 결과값이 return 문으로 반환된다. 그러니까 4번 처럼 된다는 얘기다.

var arr = [6,2,1,2,3,3]
arr.sort{                              --- 4번
   (t1, t2) -> Bool in

   return t1 < t2  
}
println(arr)  

그런데 여기서 또 의문이 생겼다. 도대체 t1과 t2는 어떤 타입이길래 서로 비교가 가능한걸까? 이걸 추론해 내는 것이 Swift 컴파일러의 능력인것이다!! arr 변수는 숫자형 배열이기때문에 바로 위에 문장을 기반으로 sort 내부에서 수행되는 t1과 t2가 Int형임을 알수있는 것이다. 그러니까 5번처럼 인식한다는 얘기!

var arr = [6,2,1,2,3,3]
arr.sort{                              --- 5번
   (t1:Int, t2:Int) -> Bool in

   return t1 < t2  
}
println(arr)  

맨위에 sort 함수 시그니처를 보면 sort 함수는 같은 제네릭타입 T를 인자로 받는다. 따라서 t1과 t2는 같은 타입이 된다. 만약 t2를 Int가 아닌 다른 타입으로 캐스팅 한다면 어떻게 될까?

arr.sort{                              --- 5-1 번 
   (t1:Int, t2:Float) -> Bool in
   return t1 < t2  
}

당연한 얘기지만 sort 함수의 인자 타입이 달라서 실행할수없다고 에러를 낸다. 역시 똑똑한 녀석!!

“Cannot invoke ‘sort’ with an argument list of type ‘((Int, Float) -> Bool)’

마지막으로 저 뜬금없는 sort 다음에 {} 중괄호!! 너는 도대체 뭐냐? 아래 6번 코드를 보자!

var arr = [6,2,1,2,3,3]
arr.sort() {                              --- 6번
   (t1:Int, t2:Int) -> Bool in
   return t1 < t2  
}
println(arr)  

잉? 이건 또 모야? 앞에 () 괄호를 써도 되는 거네? 맞다! {} 중괄호 앞에 괄호가 와도 된다. 6번에 괄호가 생략된 이유는 괄호 안에 들어가는 마지막 인자가 함수일 경우 Swift는 마지막 함수를 괄호 밖으로 끄집어 내서 쓸수있도록 허용한다. 정리하면 괄호안에 들어가는 인자가 여러개 일때, 중간에 함수가 들어가는 경우는 뺄수없다.

// p는 변수, f는 함수라고 가정한다. 
// 이런 함수는 f1을 끄지어 내지 못한다. 
x.method(p1, f1, p2) ---> X

//  이렇게 맨 마지막 인자가 함수면 끄집어 낼수있다. 
x.method(p1, p2, f1) ---> x.method(p1, p2) {} 

제네릭 타입의 형변환

클로저 함수를 다루다 보면 타입 추론에 의해서 생략되는 녀석들이 많아 가끔씩 헷갈릴때가 있는데 이럴때는 꼭 해당 함수에 마우스를 올리고 커맨드 키와 함께 문서를 열어보는 것이 좋다. 여튼 Swift에서 제공하는 많은 내장 함수들이 Typealias나 제네릭 같은 타입을 많이 쓰고 있어서 클로저 함수에 인자를 받아서 쓰다보면 다음과 같은 에러가 종종 발생한다.

(!) Cannot invoke ‘predicate’ with an argument list of type ‘(T)’

extension Array {
  func myFilter<T>(predicate:(T) -> Bool) -> [T] {
    var result = [T]()

    for i in self {
      if predicate(i) {      // <----- 여기가 문제!!
        result.append(i)
      }
    }
    return result
  }  
}

위에서 myFilter 함수는 predicate 라는 클로저 함수를 인자로 받아서 제네릭 타입인 T를 요소로 갖는 배열을 반환하는 함수다. 내부에서 쓰이는 self는 Array 클래스를 확장했으므로 당연히 내부에서 관리되는 배열일 것이라는 추측을 할수있다. 실제로 출력을 해봐도 배열값은 맞다. 하지만 컴파일러는 self 배열에서 꺼낸 i 타입이 사실 뭔지 모르고, predicate가 T 타입을 받아야한다는 사실만 알고 있기 때문에 “i가 뭔지 모르겠는데 T타입은 아닌거 같아. 제대로 넣어줘~!” 라는 메세지를 준다.

extension Array {
  func myFilter<T>(predicate:(T) -> Bool) -> [T] {
    var result = [T]()

    for i in self {
      if predicate(i as! T) {      // <----- 해결!!
        result.append(i as! T)     // <----- 해결!!
      }
    }
    return result
  }  
}

그래서 이럴때 as! 를 이용해 타입을 확실히 명시해주면 해결된다!

React 사용 1일차 회고

첫만남

F8 컨퍼런스 이후 React Nativce 이야기가 한창 들리더니 이제 다시 잠잠해지는 느낌이다. React를 처음 접한건 지금으로부터 대략 1년전 바르셀로나에서 열렸던 FutureJS에서 였다. 당시 왜들 그렇게 React React 하는지 이해가 안갔다. 그냥 Facebook에서 만들어서 그런건가 싶었다. 그래서 한국에 돌아오고나서 React를 살펴봤다. 역시나 그냥 Facebook이 만들어서 그런건가 싶었다.

첫느낌

Angular에 비해서 개발속도가 엄청 빨라 보이지도 않았을 뿐더라 그때는 한창 Two way binding에 열광하고 있던터라 React의 장점이 크게 다가오지 않았다. 고백하건데 당시 React를 공부해볼까했는데 사실은 연애를 시작하는 바람에 제대로 보지 못했다. ㅎㅎㅎ (핑계는…ㅋㅋㅋ)

첫회고

여하튼 그래서 다시 보기로 맘 먹고 어제 튜토리얼을 한번 쭉 훝어보고 기획해놓은 아이디어에 적용해보고 있다. 써본지 1일차의 느낌은 예전에 네이버에서 근무할때 Jindo Component를 만드는 느낌이다. 돌이켜 생각해보면 Jindo Component에 고민을 좀더 더 했더라면 React 같은 녀석을 훨씬더 일찍 만들어 쓰고 있지 않았을까 싶다. 그나저나 JSX 문법이 처음엔 이상했는데 지금보니 이게 정말 물건이지 싶다. 🙂 역시 사람이나 기술이나 겪어봐야 아는갑다.

오늘은 React에 이어 Flux도 같이 찬찬히 볼 예정이다. 또 적용해보고 생각나는대로 글을 남겨봐야겠다.