이맥스로 블로그 배포하기

이맥스 org mode로 작성한 글을 블로그로 배포해보았다.
css를 좀 더 만져볼까 했지만, 역시 치장보단 글 자체가 중요하다고 생각해서 글이나 써야겠다고 생각한다.
새로 만든 사이트에는 좀 제대로 써보려고한다. 기존에 회사에서 썼던 기술블로그들도 좀 다시 정리해서 올려볼까 한다.
나의 사견이 들어간 글이 필요하다. 왜냐하면, 정보는 어짜피 책을 보는 것이 더 정확하기 때문이다.
나는 개발자로서 기술을 말로 유창하게 말하는 것을 좋아하지 않는다. 이것이 옳고 저것이 그르다. 라는 것을 말로만 유창한 사람들을 피한다.
개발자라면 기어코 코드로 먼저 말하는 사람들이 좋다.
개발은 이상하게 하면서 말은 유창하고 잘하는 것처럼 말하는 사람들이 많다. 하지만 그것을 말만 듣는 사람들은 잘 모른다.
복싱분석은 선수보다 비평가들이 더 잘하는 법이니까. 이론만으로는 그가 복싱을 잘하는지 알기 어려울 것이다.
그래서 새로운 기술블로그에는 코드를 보여주고 짧게 설명하는 식으로 가볼까한다.
그 첫번째 clojure에서 유명한 라이브러리 중에 하나인 ring 프로젝트의 소스를 까보고 직접 간단하게 만들어서 돌려보는 것을 주제로 삼았다.
https://ssisksl77.gitlab.io/code-that-talks/220122-ring.html

[리뷰] 자바스크립트 디자인 패턴

http://www.kyobobook.co.kr/product/detailViewKor.laf?mallGb=KOR&ejkGb=KOR&barcode=9788960778856

객체지향 프로그래밍

GoF패턴을 자바스크립트로 설명한다. 그렇기에 '이게 뭐야? 뭐 이런거에 이름을 붙여서까지 해서 사용해야해?' 라는 생각이 들게 만든다. 자바를 사용한 사람에게는 꽤나 중요한 패턴들이지만, 자바스크립트로 그 패턴을 어거지로 표현하려다보니 색다르면서 몇몇 패턴들은 자바스크립트에서는 쓰지 않겠다 라는 생각을 했다.

함수형 프로그래밍

GoF 패턴을 설명한 후, 함수형 프로그래밍을 간단하게 소개한다. 확실히 자바스크립트의 특성상 함수형 프로그래밍이 좀 더 깔끔하다는 느낌이 든다.

이후 패턴들

이후 설명하는 모델 뷰 패턴, 웹 패턴은 별로였다. 사실 GoF 설명 이후부터는 대충 페이지 크기를 부풀리기용처럼 보일정도다.

하지만 가장 마지막에 고급패턴이라고 써있는 내용은 꽤나 재밌었다.

괜찮은 책이지만 다른 명저에 비해서는 우선순위가 적은 책이라고 할 수 있다. 이 책을 보기 전에 GoF의 디자인패턴을 보지 않았다면 그 책부터 보는 것이 좋겠다.

기술 덜어내기

항상 덜어내야 한다고 생각했다.

가볍게 살아야 한다고 생각했다.

무언가 잘 안될 때, 항상 무엇을 더 버려야 하지? 라고 생각했다. 잠자는 시간을 버려야 하는걸까. 좋아하는 음식을 먹기를 버려야 하는 걸까? 나의 어떤 생각이 잘못되고 버려야 할까? 혹은 내가 항상 옳다고 생각했던 신념을 버려야 하는 걸까?

계속 버리다보면 거울 속에 보이는 초라한 몸뚱아리 넘어 정직한 나를 보게 된다.

덜어내기 전에

그 동안 많은 기술들을 습득하려했다.

알고리즘, 디자인패턴을 넘어서 유펭린의 집합론, OOP, 여러 고수들의 에세이, 철학, 소설, FP, 리스프, Clojure, 매크로, 유다시티의 로보틱스/블록체인 강의, nodejs와 express, golang ...

언어의 문법을 익히는 것은 너무 쉽다.

중요한 것은 왜 새로 만들어져야 하는가 라고 생각한다. IT만큼 새로운 것이 급격하게 만들어지고 사그러지는 곳은 드물다. (CoffeeScript 잘 지내니?)

go 언어에서 덜어내기

go는 그런면에서 지루한 언어이면서 새롭다. go는 심플함을 위해 신기능들을 넣지 않으려고 노력한다.

오늘 내가 이 글을 적는 가장 결정적인 동기는 바로 golang에 대한 세미나를 듣던 중 go언어 개발자의 인상깊은 Q&A답변을 들어서이다.

So what's been the biggest challenge in Go?

I'd say that, for me at least, the biggest challenge is keeping it simple.

It's always so easy to add another feature. And you can see so clearly how useful it would be to have this new facility in the language. But if we add every new facility in the language, then we get something so complicated that it's very difficult to use, like some existing languages today.

And I'd say the biggest challenge has been to say no.

언어를 만들면서 가장 힘들었던 것은 언어를 심플하게 만들기 위해 no를 말하는 것이 가장 힘든 허들이라는 점이었다는 것이다.

메인스트림의 언어들은 너도나도 할 것 없이 새로운 기능들을 추가한다. 옆 언어에서 쓰는 문법들을 추가하고 '우리도 이거 있어요~' 라고 판매한다. 이해한다. 그들이 어떻게 잘 사용하는지는 모르겠고, 모든 사람이 좋아할만한 모든 기술을 추가하는 것이다. 쓰고 안쓰고는 당신의 마음이다. 좋은 코드를 만드는 것은 오로지 당신의 선택이 좌우하는 것이다 라고 말하는 것 같다.

더글라스 크록포드의 덜어내기

더글라스 크록포드는 그의 서적 [javascript : The Good Parts] 나 최근 서적에도 소개하듯이, 좋은 기능만을 쓰고 좋지 않은 기능은 기본문법에 추가되었더라도 쓰지말라고 말한다. 쓰지 않는 것은 용기가 필요하다. 덜어내는 것은 참으로 힘들다.

추가하는 것은 때때로 힙해보이고, 여러 경험을 얻을 수 있을 것이다.

덜어내는 것은 힙하지도 않고, 경험을 얻지도 못한다. 덜어내는 것은 이미 경험한 자들 그리고 정확한 믿음이 있는 사람들의 것이다.

더 나은 코드란 무엇일까?

나의 덜어내기

나에게 더 나은 코드란, 더욱 담백하고, 덜어내고 덜어내서, 이해가 쉬운 별거 아닌 것처럼 보이는 코드이다. (사실 별거지만...)

이기능 저기능을 넣어서 오히려 복잡해보인다면 큰 문제가 있을 것이다.

최소한 새로운 기술, 범용함수 또는 매크로를 넣었다면 보기에는 쉬워보여야 한다.

별거 아닌 것처럼 보여서 '별거 아니네 이것만 고치면 되겠구만' 라고 고치고 지나갈 수 있는 코드이길 바란다.

Clojure를 하다가 Node.js/Express 만져보면서 느낀점.

Javascript는 참으로 특이한 언어이다. 문서를 보지 않아도 대충 보고 쓸 수 있을 정도로 직관적이다. 당연히 공식문서를 우선적으로 읽고 차근차근 문법을 익히고 개발을 진행하겠지만, 이상하게도 자바스크립트를 만질 때는 공식문서를 보지 않고, 기존 코드를 보더니 '음... 이렇게 돌아가는 거군?' 하면서 간단한 코드를 짤 수 있게 되었다. '물론 null이 Object라던가 하는 문제는 그 이후에 하나씩 알아가는 거고'

Node.js/Express를 현업에서 쓰진 않았지만 어떻게 사용하는지 궁금했다.

해서 Udacity강의를 들어보고 아래 유튜브를 보았다.

https://www.youtube.com/watch?v=qwfE7fSVaZM

고백하자면 Clojure의 웹개발과 아주 비슷하다는 느낌을 받았다. 유튜브 강의에서 나오는 몇몇 기능은 개선을 하면 좀 더 멋지게(생산성있게) 개발할 수 있겠다는 생각도 했다. 

매크로에 대한 글을 적다

https://green-labs.github.io/the-macro

이직한지 6개월이 되는 시점에 드디어 기술블로그를 올리게 되었다. 입문자를 위해 자세한 설명을 적거나 하진 않았지만 최소한 말로 약만 파는 것이 아니라, 나의 코드로 가능하다는 것을 보여주고 싶었다. 개발자는 코드로 말하는 것이 기본이니까.

LISP 매크로는 개발자에게 만지기 어려운 무서운 기술처럼 보이는가보다. 실제로 쉽지는 않다. 

주류의 인사들은 '매크로를 쓰는 가장 좋은 방법은 쓰지 않는 것'이라고 한다. 그 만큼 매크로는 과한 기술이라는 평이 지배적이다.

하지만 과한 기술이라고 쓰지말라고 하는 것은 웃기다. 기술에 대한 이해도가 부족할 때 과하게 사용하니까 말이다. 즉, 이 말은 나에게 '넌 잘 모르니까 쓰지마' 라는 말로도 들린다.

매크로를 쓰지 말아야 하는 가장 큰 이유는 제대로 사용할 수 없는 개인의 이해도만이 이유가 되어야 한다고 주장하겠다.

어떤 기술이던 이해하지 못하고 쓰면 화를 면치 못한다. 반복문/조건문을 이해하지 못하고 쓴다면 안전할까? 죽음이 무서운 이유는 우리가 죽음을 모르기 때문이라는 말이 있듯이 매크로가 어둠의 기술처럼 느껴지는 이유는 그 만큼 매크로를 모르기 때문이라고 생각한다. 매크로는 죽음과 다르게 다행스럽게도 관심이 있으면 이해할 수 있다. 즉, 매크로가 두려운 이유는 매크로를 온전히 받아들이려고 하지 않는 나의 마음일 것이다.

난 권위에서 오는 말을 좋아하면서도 싫어한다. 여러 잠언들은 때때로 나를 편안하게 하지만 어떤 문장들은 맞는 말 같으면서도 고개를 갸우뚱하게 만드는 경우가 있다. 이때 '권위자'라는 단어는 그 갸우뚱하던 고개를 끄덕이게 만든다. 알아서 고개를 숙이거나 주위에서 숙이도록 강요하게 하는 힘이 있다.

'매크로를 쓰지말라' 라고 말한다면, 우리는 매크로가 무엇인지 정확히 알 필요가 있다. C, LISP의 매크로는 모두 컴파일러가 미리 만들어놓은 룰을 초월한다. 

이 초월하는 힘을 처음 접한 나는 다음과 같은 경험을 하였다.  

첫째, 내가 한번 휘두른 이 힘이 어디까지 닿는지 가늠이 되지 않는다.

둘째, 기존의 힘이 무색함을 느낄 수 있다.

셋째, 결국 강력한 이 힘에 집착하게 된다.

아마 구루들은 세번째에 이르는 것에 두려움을 느끼게 하고 싶었다고 생각한다.

그리고 구루들의 "매크로를 잘 쓰는 방법은 쓰지 않는 것이다" 라고 말하는 것에 대한 숨겨진 또다른 의도는 아래와 같다고 생각한다.

"매크로는 어짜피 기어코 위험을 무릎쓰고 자유로운 힘을 얻고자 하는 사람들이 쓰는 기술이다. 쓰지말라고 쓰지 않는 사람들에게는 필요없다. 어짜피 매크로를 쓰고자 하는 사람들은 나의 말이 의미 없다. 이미 쓰고 있을테니"

나는 위처럼 이해를 했다. 나는 그래서 매크로의 강력함과 위험성을 인지하고 자유롭게 쓰려고 한다. 만약에 그분들이 자신들은 그런 의미로 말한 것이 아니라고 말하면 어떤가?

그런 것들은 이미 상관없다.

clojure 매크로에 대해 알아보자

오랫만에 작성하는 기술블로그다. LISP의 매크로에 대해서 작성해보았다.

 https://green-labs.github.io/the-macro

컬리에서 작성하는 마지막 기술 블로그

y combinator에 대해서 한번 적어보았다. 

마지막에는 종립님께서 글을 다듬어 주시고 javascript 코드를 추가해주셨다. 

글이 더 풍부해졌다.

종립님과 함께 기고할 수 있어서 영광이다.

무엇보다

즐거웠다

컬리에서 작성하는 마지막 기술 블로그

 

[그런 REST API로 괜찮은가]를 보고

REST API는 무엇일까.

로이 필딩의 논문을 다 읽진 않았지만 그곳에는 client-server 아키텍처 사이에서 완벽하게 독립적으로 개발을 할 수 있도록 하는 API 아키텍처를 상상한 듯 하다.

만약에 할일 목록을 가져왔다면, 그 할일 목록에서 할 수 있는 행위들을 위한 링크를 제공하는 것이다. 그러면 클라이언트에선 특정 uri에 대한 정보를 알 필요도 없을 것이다.

이것이 HATEOS의 중요성인 듯하다. 로이 필딩을 정확히 무엇을 꿈꾼 것일까. 

아래 유튜브 비디오를 보면서 고민을 하는 하루가 되었다. 로이 필딩 논문을 한 번 마저 읽어봐야겠다.

 https://www.youtube.com/watch?v=RP_f5dMoHFc

폴그레이엄은 왜 ycombinator라고 이름을 지었을까

ycombinator는 lambda calculus에서 꽤나 중요하게 여겨지는 아이디어이다.

오랫만에 컬리에 기술블로그로 기고할 겸 공부도하고 정리도 했다.

https://www.notion.so/tombox/Y-combinator-865c9614db0245ce869424a92462406b 

취직을 위한 공부만 했다면 달라졌을까

Java/Spring을 많이 사용해왔지만, 솔직하게 Spring을 잘 안다고 할 수는 없겠다. 

더 솔직히 말하면, 그동안 너무 쓸데없어 보이는 것들에 신경을 많이 썼던 것 같다.

유펭린의 집합론을 공부하질 않나, 잘 이해도 못하는 Lisp 책이나 보려고 하질 않나...

다 나의 커리어에는 큰 도움을 줄 것같지 않는 것들만 산더미로 공부했다.

그나마 괜찮은건 그래도 공부를 하긴 했다는 점

나만 괜찮다면 그것이 정도가 아니라도 괜찮다고 생각했다.

후회하지 않을 거라고 생각했다.

회사에서 사용하는 기술들을 그때그때 공부하면 되지 라는 알인한 생각을 가져왔다.

왜 그랬을까.

왜 나는 해야하는 공부에는 관심을 갖지 않고, 꼭 필요 없어 보이는 것에만 열중했을까

아쉽고도 아쉽지만, 어쩔 수 없다.

지금에라도 나의 공부 포트폴리오를 바꿔야할 것이다.

평생 이렇게 공부만 할 수는 없을 것이다.

언젠가는 꽃을 피워야 하고, 또 동료들이 내가 동료인 것이 만족할 수 있도록 나는 더 분발해야 한다.

누구를 만나던 그들과의 만남과 헤어짐에서 내가 좋은 동료로 남고 싶으니까...

나는 더 열심히 살아야겠다. 

[패스트캠퍼스] 강의를 구매했다.

컬리에 있으면서 고민을 하게된 큰 그림을 보는 인사이트를 얻기 위해 구매해보았다. 

아래는 관련 강의 링크이다.

https://www.fastcampus.co.kr/dev_red_yjs

윤진석님이 어떤 분인지는 잘 모르겠지만, 나보다 많은 경험을 하신분이니 가격에 맞는 정보를 알려주지 않을까 라는 생각에 구매를 진행했다. 

그리고 생각보다 비싸진 않다. (이전에 구매한 clojureScript 강의에 비하면...)

수강을 다 하지 못해서 속단할 수는 없지만, 강의시간이 4시간 정도 된다. 거기에서 intro 관련 내용을 빼면 더 시간이 줄어든다. 가격은 15만원 정도였으니, 약 4시간이라고 치면 한시간에 37500원 정도다.

싼 가격은 아닌 것 같다.

그래도 다 들어보면 생각이 달라질 수 있으니 전부 수강하고 다시 리뷰를 해야겠다.

Learn Reagent Pro by Jacek Schae 강의 후기

reagent 란

reagent react를 clojureScript로 개발할 수 있게 해주는 라이브러리다. 

html을 만들 때는 hiccup라이브러리 처럼 clojure 자료 구조로 표현이 가능하다. 

즉 일반적으로 컬렉션을 다루는 함수를 그대로 적용해도 잘 작동한다. 

더 특이한 것은 reagent의 atom이다. 

clojure에서 atom은 java의 AtomicInteger, AtomicReference와 같은 녀석처럼 병렬 프로그래밍을 할 때 사용한다. 

reagent 에서 atom은 react, redux의 조합처럼 값을 변경시키면 저절로 해당 atom을 dereference해서 사용하는 구간이 다시 렌더링 되면서 값이 보여진다.

Learn Reagent Pro

강의는 꽤나 비싼데 reagent를 처음 접하는 사람에게는 유용할 것이다. 

reagent만 배우는 것이 아니라, shadow-cljs 같이 의존성을 적용하는 방법이나, 일반적으로 reagent를 사용할 때 어떻게 사용하는지 알 수 있다.

현재 5강 정도를 남겨두고 firebase에 올려보기 까지 진행했다. 

꽤나 유익했고, 다음 강의 Learn Reframe Pro도 이어서 수강할 예정이다. 

  

강의 링크

clojure로 카프카에 이벤트 발행

의존성

[org.apache.kafka/kafka-clients "2.5.0"]

사용코드

(ns kafka-demo2.core
  (:import [org.apache.kafka.common.serialization StringSerializer]
           [org.apache.kafka.clients.producer KafkaProducer ProducerRecord])
  (:gen-class))

(def config
  {"bootstrap.servers" "127.0.0.1:9092"
   "key.serializer" StringSerializer
   "value.serializer" StringSerializer})

(defn publish [topic str]
  (let [producer (KafkaProducer. config)
        record (ProducerRecord. topic str)]
    (try
      (.send producer record)
      (finally (.close producer)))))

(defn -main
  "I don't do a whole lot ... yet."
  [& args]
  (println "push A")
  (publish "yhnam-topic" "A"))

도커

https://github.com/ssisksl77/clojure-breadcrumb 위 깃허브 참고

실행

별거 없음 위 깃허브 참고

$ docker-compose up
$ lein uberjar
$ java -jar kafka-demo2-0.1.0-standalone.jar

그외 정리

https://www.notion.so/tombox/db6bc836f25d41948d28f3aff9ec1aff

[책리뷰] (빅 데이터 세상으로 떠나는 간결한 안내서) NoSQL

 이 책은 NoSQL의 개요를 담고있다.

NoSQL의 전체적인 추세가 그때와 지금은 다르지 않은 것 같다.

NoSQL이 어떤 종류가 있으며, 기존 문제들을 어떻게 풀려고 하는지 간결하게 설명한다.

흥미로운 책이었다. MongoDB를 아무생각없이 쓰고 있었는데 조만간 DB 관련된 책을 봐야겠다는 생각을 한다.

MySQL도 아무생각없이 썼던게 아닌가 싶다. 공부해야겠다.

서적 링크 : http://www.yes24.com/Product/Goods/8510944

Monad 정리

내가 이해하는 모나드에 대한 생각을 잠깐 정리해보려고 한다

1. Monoid

2. Functor

3. Applicative Functor

4. Monad

이 순서를 알아야 한다.

1. Monoid

모노이드는 아주 단순하다. 

 - 항등원을 가진다

 - 결합법칙

 - 이항연산

참조 : https://ko.wikipedia.org/wiki/%EB%AA%A8%EB%85%B8%EC%9D%B4%EB%93%9C

이 셋이 뭔지 모른다면 덧셈을 예로 들겠다. 덧셈은 Monoid다.

1. 항등원을 가진다. (0은 항등원이다)

2. 결합법칙을 가진다 (1 + (2 + 3)) == ((1 + 2) + 3)

3. 이항연산 (덧셈은 두개의 항이 필요하다)

모노이드는 함수형 프로그래밍에서 꽤나 중요한 역할을 한다. 

바로 병렬로 fold(fold가 뭔가 모른다면 reduce라고 생각하면 됨)를 할 수 있다는 것이다. 

순서가 필요없이 이항연산이 가능하기 때문에, 왼쪽부터 덧셈을 하거나, 오른쪽부터 덧셈을 하거나, 식을 반으로 쪼개서 각자 계산후에 머지를 하더라도 값이 동일하다는 것을 의미한다.

그러므로 모노이드는 꽤나 중요하다.

모노이드면 일단 '이항연산을 안전하게 할 수 있구나' 라는 생각을 하면 된다.

2. Functor

https://en.wikipedia.org/wiki/Functor

a Functor is a mapping between categories.

두 가지의 카테고리 사이를 이어주는(map) 사상을 말하는 것 같다. (사실 영어는 잘 모르겠다)

하스켈에서 functor는 `fmap` 을 구현한 녀석을 말한다.

`fmap`이란 뭘까?

이건 List 에서 map을 사용하는 것을 생각하면 쉽다.

List에서 map을 사용하면 어떻게 될까? 값이 변경되어도 그것이 List라는 것은 변함이 없다. 즉, Functor는 map이다 라고 생각하는 것이 좀 더 이해하기 쉬울 것 같다.

하스켈 Functor의 fmap의 구조는 아래와 같다. 

class Functor f where
    fmap :: (a -> b) -> f a -> f b
    (<$) :: a -> f b -> f a

3. Applicative Functor

중요한 리소스가 있다.

https://adit.io/posts/2013-04-17-functors,_applicatives,_and_monads_in_pictures.html

하스켈에서 Functor와 Applicative Functor의 타입차이를 한번 봐보자.

(<$>) :: Functor f => (a -> b) -> f a -> f b 

(<*>) :: Applicative f => f (a -> b) -> f a -> f b

그러니까 functor는 (a -> b) 이고 Applicative functor는 f (a -> b) 임을 보자.

결국 f (a -> b)에서 이 앞에 붙은 f가 무엇이냐는 것이다. 즉. Applicative Functor는 Functor 안에 함수도 들어갈 수 있는 경우를 말한다.

만약에 즉, 위에서 예를 들었던 List안에 [+1, +2] 이런식의 리스트가 존재하여, 합칠 수도 있다.

즉, 이런 타입 안에 함수를 넣을 수 있고, 이 함수는 그 타입에서 가지는 컨텍스트가 적용된다.

(여기서 컨텍스트란 그 타입 안에 내포되어 있는 의미를 말한다. 예를 들어 List는 여러개를 가진다를 말할 수도 있을 것 같다)

4. Monad

모나드는 좀 특이한데, 내 생각에 이것은 좀 필요에 의해서 만들어진 것 같다.

최근에 회사 내에서 스칼라 빨간책 스터디를 하면서 monad에 대한 이야기를 했다.

일반적으로 monad에 대한 가장 간단한 설명은 `flatMap`을 말한다고 할 수 있다. 그런데 flatMap이 왜 중요할까? 

class Applicative m => Monad m where 
    (>>=) :: m a -> (a -> m b) -> m b 
    (>>) :: m a -> m b -> m b 
    return :: a -> m a

여기서 중요한 것은 >>= 이다

m a -> (a -> m b) -> m b 이 형태를 보면 flatMap임을 알 수 있다. (이것이 이상하다고 생각된다면, 자바나 다른 언어에서 map과 flatMap의 차이를 보면 좋을 것 같다)

flatMap이 왜 map이랑 그렇게 다른 것일까?

왜 

-- fmap or map (Functor)
(a -> b) -> f a -> f b 
-- flatMap (Monad)
m a -> (a -> m b) -> m b

이 둘이 뭐가 그렇게 다른 것일까?

아주 조금 다르지만 아주 크게 다르다. 여기서 중요한 것은 

(a -> m b) 이다. 이것이 아주 큰 일을 한다. 

일단 Monad는 Functor랑 아주 큰 차이는 Type을 생성하는데 주도권이 서로 다르다는 것이다.

당신은 List [1,2,3,4] 에 더하기 1을 하는 함수를 호출했다고 해보자.

var a = [1,2,3]

function addOne(x) {
 return x + 1;
}

a.map(addOne); // [2,3,4]

여기서 당신은 이런걸 원할 수도 있다.

리스트를 두배로 만드는 거다! 

var a = [1,2,3]

function double(x) { return [x,x] }

var b = a.map(double); // [[2,2],[3,3],[4,4]]
b.map(double); // [[[2,2],[2,2]],[[3,3],[3,3]],[[4,4],[4,4]]]

이래가지고, 함수를 함성할 수 있을까?
누군가는 이렇게 말할 수 있다. 애초에 왜! 리스트를 리턴하는 함수를 만든거야? 그냥 그 타입에 맞는 것만 리턴하지?! 

말은 쉽지만 그렇지 않다. List를 다루는 곳에는 List를 리턴하는 함수를 많이 사용할 수 밖에 없다. 

만약에 리턴하는 것이 IO라면? 그리고 IO를 리턴하는 객체가 계속 겹친다면? 제대로 작동할 수 없다.

자바의 Optional도 마찬가지이다. Optional을 실행했는데 안에 Optional이 있다면 어떻게 할 것인가? 재귀로 호출할 것인가?

이런 함수의 합성에서 예기치 않은 타입의 덮어씌움이 있기에 우리는 flatMap을 쓴다. 여기서 한가지 뇌피셜을 더해서 설명하면

monad는 두 개의 타입을 어떻게 concat을 하냐가 관건이다.

즉 파이썬의 키워드를 빌려서 직관적으로 설명을 시도해보겠다.

[1,2,3] ++ [4,5,6] # [1,2,3,4,5,6]

List를 concat한다면 이렇게 될 것이다. 만약에 다른 타입들에도 이 concat이라는 개념을 녹일 수 있다면(concat을 해서 두 타입 합치는 방식을 약속한다면)

flatMap안에 해당 타입에 어울리는 구현으로 만들어서 flatMap을 만들면 타입을 겹겹이 쌓이지 않을 수 있다. 그때그때 concat으로 합치면 되니까 말이다. 

우리가 concat이라는 개념을 생각해보는 것이 중요하다. concat은 1번에서 지칭한 Monoid와 같다. (왼쪽부터 수행하건, 오른쪽부터 수행하건 결과값은 동일해야 한다.)

이상 여기까지가 내가 이해한 Monad의 정리다.

모나딕 뭐 이런 말은 안쓰려고 노력했다. (사실 용어에 대해서 완벽하게 알지 못하면 안쓰는게 나을 것 같아서 쓰지 않았다)

사실 더 디테일한 내용들이 있다. 특히 모나드의 경우 위에 설명한 타입만 맞으면 되는 것은 아니고, 몇가지 조건을 만족해야만 한다.

2020년을 생각하며...

2020년이 갔고 2021년이 왔다.

아주 바쁘게 보냈지만, 그렇기에 너무 조용하고, 기억에 남는 것이 없는 한 해를 보낸 것 같다.

피로사회에서 바쁜 삶은 사람을 피로하게 하고 깊은 생각을 못하게 하고 자신을 되돌아볼 시간을 제한하게 한다고 주장한다. 그는 쉬는 시간에 게임을 하거나 여행을 가는 것 같이 `무언가를 하는 방식`으로는 근본적인 해결이 아니라고 한다. 

나는 그럼에도 되돌아 보려고 한다. 

내가 이번 해에서 무엇을 보았고, 무엇을 느꼈는지.

작년 초를 생각하면 나는 삶의 무료함을 느끼고 있었다.

다들 나와 같지 않은 마음, 안정감있는 삶. 아니 도태되어 가고 있는 삶에 행복감을 누리는 사람들과 몇년을 함께 지내면서 나 자신도 그렇게 변해가는 것에 환멸을 느꼈다.

나는 서울로 상경했으며, 현재 하고 있는 일도 정도를 걸어서 온 길이 아니다. 대학의 전공을 따르지 않고, 선택한 길이기에 나에게는 한계가 명확함을 인지하고 있었다. 누군가는 4년을 준비하고 좋은 회사를 거쳐가겠지만, 나는 작은 회사에서 2400이라는 숫자를 지니고 시작했다.

적은 숫자가 아닐까 라고 생각했지만 당시 나는 서울 고시원에 살고 있었다. 그것도 내창으로 (내창은 창문이 복도에 있는 것을 말한다. 나는 햇빛을 볼 수 없는 방에 살았다) 버는 돈이 없었기에, 나는 2400이라는 숫자를 받으면서 너무 행복했다. 

나도 사회의 일원이 되었구나

2400 

이것이 나에게 주어진 숫자구나

나는 현재 4,5년차가 되었고 회사는 3번을 이직했다. 마치 서울에 내리는 소나기처럼. 어디 한 곳에 뿌리내려 꽃을 피우는 것이 아니라, 하수구로 내려가 이리저리 더러운 것들을 닦고 묻혀서 결국에는 서울에서 밀려나지는 않을까 걱정한다.

이것은 나의 언더독 성향이 더 이런 경향을 강하게 만든다. 

개발을 하면서 Lisp에 빠져버렸을 때, 나의 커리어패스가 뒤틀어질 것을 예언했다.

개발학원에서 SICP마법사책을 읽고, Scheme을 공부하면서, 이걸로 취직을 하겠다고 학원을 수료하지 않고 뛰쳐나왔을 때. 

전혀 Scheme이나 Racket을 쓰는 회사를 찾을 수 없었을 때의 그 어둠은 창문이 없는 고시원에 사는 것보다 더 무서웠다.

결국 Spring을 여차여차 공부해보고 취직을 하고, 공부를 다시하고, 일을 하고 버텼던 것 같다.

수학을 공부하고, 함수형 프로그래밍을 공부하지만 

내 마음 속에는 Lisp가 항상 있다.

음식 평론가 황교익은 한 때 최고의 음식은 자장면이라고 뽑았다.

어렸을 때, 가난한 시절 부모님과 함께 먹었던 자장면을 기억하며,

최고의 음식은 맛만으로 평가할 수 없다는 그의 말처럼

나에게 Lisp는 그 시절 나의 악몽같던 시절에 

희망과 절망을 동시에 준 도구였다.

다시 돌아와서

나는 컬리라는 회사로 이직했다.

처음으로 사람들이 이름을 아는 회사.
사장님의 이름을 연예인처럼 많은 사람들이 기억하고 있는 회사.

부모님이 이름을 안다는 것에 괜히 기분이 좋았다.

그리고 무엇보다 변화를 두려워하기보다 변하지 못하는 것을 두려워 하는 사람들을 만난다는 것은

나에게 신선했고, 내 자신을 움츠려들게 했다.

왜냐하면

결국 가만히 있어도, 그들과 함께 있으면 변하기 때문일지도 모른다.

난 오히려 내가 어떻게 변하는지 소극적으로 바라만 봐야했다.

그동안 나는 해내는 것에 집중했었다.

해야할 것을 바로알고 어떻게 해야 할지, 정말 그들이 잘 쓸 수 있을지를 고민했다.

2400이라는 숫자로 일을 시작했을 때부터

나는 항상 감사했다. 이 감사함은 유저들에게 보답해야 한다고 나는 생각했다.

컬리에서 일하면서 새로운 경험을 하게 되었다.

무엇을 만들어야 한다고 하지만,

그것이 무엇인지 너무 추상적이기에 또 그걸을 알 수 없기에

우리는 개발하기보다는 대화를 하는 사람이 된 것 같다.

신기한 경험이었다. 

해야할 일이 있지만 할 수 없는 답답함.

코드 리팩토링, 좋은 코드는 세상을 바꿀까?

컬리에서 일을 하면서 이 말은 좋은 질문이 아니라는 생각을 하게 되었다. 

이 말은 그렇기도 하고 그렇지 않기도 하다.

모든 세상은 단순한 말로 표현할 수 없다.

각자의 서비스를 만들기 위해

각자의 팀이 가지는 프로젝트를 마치 자신의 사업처럼 사랑하면서 작업을 해야하며,

서로 함께 만들기 위해

회의하고 언성이 높아지고 

회의하고 언성이 낮아지고

회의하고 적막이 흐르고

반복에 반복을 하다보면

개발자는 코드를 만드는 사람이 아니라

꿈을 꾸는 사람들이며

무엇을 만드는지 상상하는 사람들이구나...

라는 생각을 했다.

개념적으로만 존재하던 개념들의 점점 실체화되고 구조과 완성이 되가는 그 시점부터

좋은 코드, 리팩토링에 대한 지식과 경험이 있으신 분들과 함께라면

상상한 구조를 만들어내는 데에는 마치 뻥 뚤린 고속도로가 펼쳐진 것처럼

정신없이 나아간다.

무엇을 만들지도 모르는 곳에 떨어져서

무엇을 어떻게 만들지 고민하는 순간의 고통을 느낄 때

나는 새로운 세상에 들어왔음을 느꼈다.

2021년에는 

더 겸손해지고

더 열심히 공부해야겠다.

처음으로 마켓컬리에 기술블로그를 발행했다.

Lambda Calculus에 대해 알아보자

다들 멋지신 분들이라서, 감히 기술 관련 글을 올리기가 무서웠다.
그래서 기술적인 것보다는 좀 더 내가 개인적으로 관심을 가졌던 글을 써야겠다고 생각했고, 그래서 선택한 글이 lambda calculus였다.

오타가 좀 있지만, 어쩔 수 없다... 이미 기고는 되었다.
정리하고 레퍼런스 체크를 하는데 꽤나 시간이 걸렸다.
잘못된 정보를 공유하기 싫었기에 레퍼런스 체크를 계속 했으며, 모호한 부분은 아예 삭제를 하던가, 유머스러운 글 또한 전부 삭제했다.

[리뷰][인프런 강의] 김영하의 JPA ORM 기본편

내용이 알차다. 이전에 서적으로 볼 때보다. 강의로 듣는 것이 더 이해가 쉽다. 직접 알려줘서 그런 것 같기도 하고, 레퍼런스 같이 알려주는 것이 아닌 중요한 부분을 계속 짚어 주기 때문이다.

선배가 후배에게 알려 주듯이, 그때그때 현업의 이야기를 구수하게 해주실 때도 있다.

노트정리한 것

[리뷰] clojure polymorphism

이 책은 leanpub이라는 사이트에서 구매한 책이다.

저자는 코드의 재사용에서 가장 중요한 요소를 다형성이라 믿는 듯 하다.
하여 다형성에 대한 자신의 생각과 그 노하우를 clojure를 이용해서 아주 짧게 설명해주고 있다.


노트정리한 내용

[리뷰] 셰익스피어의 리어왕

셰익스피어의 4대 비극 중 가장 비극적인 이야기라고 생각한다.
한번의 믿음, 한번의 실수로 모든 것을 잃은 리어왕의 이야기는 남을 불신하는 것에 대한 이야기가 아닌
자신이 누구인지 다시 새겨보게 하는 이야기라고 할 수 있다.

나의 생각

리어왕은 세명의 딸에게 각각 땅을 나눠주기로 한다. 갈등의 시작은 이미 여기서 시작된다. 왜 땅을 나눠주려하는가. 왜 땅을 삼등분하였는가.
리어왕은 이미 처음부터 세 딸에 대해 제대로 보려고 하지 않는다. 이미 결정은 만들어졌고, 딸들은 리어왕을 친송하기만 하면 되는 것이다.
리어왕 자신은 그럴 가치가 있는 사람이라고 생각했나보다. 이제 나눠줘도 자신은 리어왕 그대로 이기 때문에 상관이 없다고 생각했나보다.
당연히 세 딸들이 자신을 사랑하고, 자신이 재산을 나눠주면 그 보답으로 무언가를 해줄 것이라 생각했나보다.
리어왕은 그 증거로 자신을 얼마나 사랑하는지 말하라 한다. 첫째 딸, 둘째 딸은 리어왕에 대한 사랑을 온갖 수식어를 붙여서 표현한다. 그는 흡족한다.
하지만 막내딸 코딜리어는 거짓을 말하지 않고 자신의 생각을 그대로 말한다.

리어왕은 분노하며 코딜리어에게 주어질 모든 땅을 빼앗고, 시집을 보낸다.

재산을 받은 두 딸은 재산을 받은 시점부터 리어왕을 무시하기 시작한다. 리어왕은 자신이 무슨 일을 저지른 것인지 뒤늦게 깨닫게 되는데...

이 이후의 내용은 굳이 설명하지 않도록 하겠다. 이 책이 비극이라는 점으로 추론하거나, 리어왕은 짧은 글이니 읽어보길 추천한다.

기억에 남는 문장을 말하라 한다면 글로스터가 두 눈을 잃고 하는 말이다.

갈 곳이 없으니 눈도 필요없다. 
눈이 있을 땐 넘어졌지.

이 말이 계속 머리 속에 맴도는 것이 신기하다. 특이 "눈이 있을 땐 넘어졌지" 라는 말이 신기하다.

눈이 없어서 부축을 받는 존재가 된 글로스터는 눈이 있을 때 넘어졌다는 말을
마치 거짓된 글들을 읽고 그것에 혹해 잘못을 저지른 자신을 되돌아 보는 말일 수도 있고

방향성이 있던 그의 삶에서는 넘어지기도 하고 나아갔겠지만
전의를 상실하였기에 나아가지도 않기에 넘이지지도 않는 다는 말일 수도 있을 것 같다.

셰익스피어의 리어왕에서 나오는 유명한 명언은 아래와 같다

있다고 다 보여주지 말고
안다고 다 말하지 말고
가졋다고 다 빌려주지 말고
들었다고 다 믿지 말고

이 내용만을 보면 아첨에 조심하라는 말이다.

내가 리어왕을 보면서 느낀 점은 이것과는 조금 다르다.
자신을 보고 싶은 대로 보고, 누군가를 현혹하려는 것은 인간의 본능임을 셰익스피어는 보여주려는 것 같다.
사랑하고자 하는 것을 바라보고, 믿고 싶은 것을 믿는 것 또한 인간이 하는 실수라고 생각한다.

사실 코딜리어가 아버지를 사랑하는 말을 해주었다면, 이런 비극이 과연 일어났을 것인가.
혹은 딸들에게 재산을 물려줄 때, 끝까지 막아섰던 신하를 버리지 않고 그를 믿었다면 어떻게 되었을가.

라는 생각을 해본다. 하지만 이 한 편의 연극이 단순한 격언을 말하기 위한 극이라고 하기에는 아깝다고 생각한다.

나는 리어왕의 이야기가 우리의 삶으로 느껴진다.

누군가를 어리석게 믿는 것은 피할 수 없으며 우리가 사랑하는 행위이기 때문이다.