[책리뷰] (빅 데이터 세상으로 떠나는 간결한 안내서) 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대 비극 중 가장 비극적인 이야기라고 생각한다.
한번의 믿음, 한번의 실수로 모든 것을 잃은 리어왕의 이야기는 남을 불신하는 것에 대한 이야기가 아닌
자신이 누구인지 다시 새겨보게 하는 이야기라고 할 수 있다.

나의 생각

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[java] CountDownLatch와 CyclicBarrier의 차이 (Phaser로 들어가기 전)

출처 : https://www.baeldung.com/java-cyclicbarrier-countdownlatch

개요

사실 오래 전에 배워서 사용했던 Phaser라는 기능이 가물가물해서 기억을 하고자 CountDownLatch와 CyclicBarrier를 비교하면서 복습을 해보았다.
하지만 대부분 Phaser보다는 CountDownLath,CyclicBarrier를 많이 사용하지 않을까 싶다.

CountDownLatch

일단 Latch(빗장이었나?)로 걸어잠그고 숫자를 다 세면 열어주는 것이다. 그래서 만약에 CountDownLatch에 카운트를 5로 지정하면 0이 될때까지 현재 스레드가 기다린다.

CyclicBarrier

CyclicBarrier는 스레드 그룹이 모두 wait하고 있는 지점에 도달 할 때까지 기다린다.
이 시점에서 Barrier가 깨지면서 일을 할 수 있게 된다. 뭐 일을 안해도 되고 해도 된다.

차이점

Task vs Treads

보면 알겠지만 CountDownLatch는 숫자를 세는데 중점을 두고, CyclicBarrier는 모두 다 오길 기다린다.
CountDownLatch는 동일한 녀석이 숫자를 두번 세도 상관이 없다.
CyclicBarrier는 한명당 하나의 카운트라고 생각하면 된다. 무조건 다와야 한다.

CountDownLatch countDownLatch = new CountDownLatch(2);
Thread t = new Thread(() -> {
  countDownLatch.countDown();
  countDownLatch.countDown();
});

t.start();
countDownLatch.await();

System.out.println("code1");
System.out.println(0 == countDownLatch.getCount());
System.out.println("===");

CyclicBarrier cyclicBarrier = new CyclicBarrier(2);
Thread t = new Thread(() -> {
  try {
    cyclicBarrier.await();
    cyclicBarrier.await();
  catch (InterruptedException | BrokenBarrierException e) {
    e.printStackTrace();
  }
});

t.start();

System.out.println("code2");
System.out.println(1 ==  cyclicBarrier.getNumberWaiting());
System.out.println(cyclicBarrier.isBroken());
System.out.println("===");

재사용성

CyclicBarrier는 wait()에 도달해서 다음으로 넘어가면 count값이 원래 값으로 바뀐다. 무한이 돈다
CountDownLatch에서는 한번 도달하면 끝이다.

List outputScraper = Collections.synchronizedList(new ArrayList<>());
CountDownLatch countDownLatch = new CountDownLatch(7);
ExecutorService es = Executors.newFixedThreadPool(20);
for (int i = 0; i < 20; i++) {
  es.execute(() -> {
    long prevValue = countDownLatch.getCount();
    countDownLatch.countDown();
    if (countDownLatch.getCount() != prevValue) {
      outputScraper.add("Count Updated");
    }
  });
}

es.shutdown();
System.out.println(outputScraper);
System.out.println(outputScraper.size() <= 7);

// https://docs.oracle.com/javase/6/docs/api/java/util/concurrent/package-summary.html
// https://stackoverflow.com/questions/6916385/is-there-a-concurrent-list-in-javas-jdk 참고
// Collections.synchronizedList는 내가 임의로 넣은 것이다.
List outputScraper = Collections.synchronizedList(new ArrayList<>());
CyclicBarrier cyclicBarrier = new CyclicBarrier(7);
ExecutorService es = Executors.newFixedThreadPool(20);
for (int i = 0; i < 20; i++) {
  es.execute(() -> {
    int numberWaiting = cyclicBarrier.getNumberWaiting();
    if (numberWaiting >= 0) {
      outputScraper.add("Count Updated"); 
    }
    try {
      cyclicBarrier.await();
    } catch (InterruptedException | BrokenBarrierException e) {
      e.printStackTrace();
    }
  });   
}

es.shutdown();
System.out.println(outputScraper);
System.out.println(outputScraper.size() > 7);
cyclicBarrier.await();

다음에는 Phaser에 대해 알아보자.

[javascript] jQuery는 어떻게 new가 없이 생성되는 것일까?

언젠가 개발을 처음 시작할 때 나프다의 [정개발]이라는 분과 슬랙 대화를 한 적이 있다. 당시 나는 자바만을 배우고 있었음에도, 그분은 언젠가 jQuery소스를 공부해야 한다고 했었다.
그때는 자바 개발하기에도 바쁜데 자바스크립트에 제이쿼리를 사용하는 것도 모자라 소스를 공부?
라고 생각했었다.

지금은 자바스크립트를 배우는 것이 자바에도 도움되고 더 나아가 내가 어떤 언어를 짜던 잘나가는 오픈소스를 읽는 것이 중요하다고 생각한다. (하지만 제대로 소스를 판 적은...)
오늘은 제이쿼리에게서 한 수 배워보고자 한다.

오늘 주제는 jQuery는 어떻게 new를 없앴는가? 이다.
대부분 new를 없앤다는 것은 생성자를 사용하지 않는 다는 말과 같다. 매개변수가 필요하면 그 매개변수를 클로저로 덮어서 함수로 던지는 것이다. 그러면 그 함수의 스코프는 자기 함수 밖에 있는 변수(매개변수 포함)를 덮은(closure) 채로 세상 밖에 내던져진다.

하지만 jQuery는 그런 것 같지 않다. 어떻게 그렇지 않은지 아주 쉬운 방법으로 알 수 있다.


이처럼 __proto__안에 수 많은 함수들이 있는 것을 알 수 있다. 어쩌면 당연한 것이다. 수 많은 기능들을 사용할 때마다 각 Execution Context에 포함해서 던진다는 말은 사용할 때마다 동일한 기능들이 메모리에 올라간다는 말이니까. 한 두개면 괜찮겠지만 저게 몇 개인가!

new를 사용하는 것이 분명하다.

그렇다면 jQuery소스를 한번 구경해보자.

jQuery($)의 정체

제이쿼리 사이트에서 일반 개발용소스를 참고했다.(https://code.jquery.com/jquery-3.4.1.js)

일단 jQuery를 실행하면 무엇이 나오는가? 그것이 시작일 것이다. 일단 jQuery는 함수일 것이다. 그러니까 new가 없이 실행되는 것이다. jQuery라는 이름의 함수를 찾아보자.

var version = "3.4.1",
  // Define a local copy of jQuery
  jQuery = function( selector, context ) {
  // The jQuery object is actually just the init constructor 'enhanced'
  // Need init if jQuery is called (just allow error to be thrown if not included)
      return new jQuery.fn.init( selector, context );
  },
...

그렇다. jQuery를 실행하면 내부적으로 jQuery.fn.init이라는 생성자를 실행한다!

jQuery.fn.init의 정체

이제부터는 jQuery의 소스를 이용하면, 말이 많아지기 때문에, 제이쿼리의 간단한 구조를 간단히 설명하고자 한다. 조그만한 자바스크립트 라이브러리를 만들었다고 해보자.

/*
제이쿼리 구조를 설명하기 위해 만든 간단한 함수
*/
(function (global) {
  var mini = function(name) {
    return new mini.fn.init(name);
  }

  mini.fn = mini.prototype = {};

  mini.fn.sayHi = function() {
    console.log("hi " + this.name);
    return this;
  }

  mini.fn.sayBye = function() {
      console.log("bye " + this.name);
      return this;
  }

  mini.fn.init = function(name) {
    this.name = name;
  }

  mini.fn.init.prototype = mini.fn;
  global.mini = mini;
})(window);

var M = mini("Nam");
M.sayHi().sayBye();

녀석의 이름은 mini다. 즉시실행함수를 만들어서 스코프가 밖으로 나가지 못하도록 하였으며 글로벌에 mini라는 변수를 넣어야 하기 때문에 window를 매개변수로 넣었다.

jQuery에서는 이 global이라는 녀석을 받아서 jQuery에서 사용할 수 있는 녀석인지 유효성 체크도 한다.
그리고 mini를 실행하면 mini.fn.init 이라는 객체를 뱉을 것이다.
한번보자.

실행해보자.

var M = mini("nam");
M.sayHi().sayBye();

잘 보면 두 함수를 연속적으로 실행할 수 있는데, 이건 다른 라이브러리에서도 많은 보았을 것이다. 이렇게 함수를 연결하는 방법은 우리가 사용하는 객체를 계속 리턴하는 것이다.
그런데 왜 prototype이 아니라 fn이라는 녀석에 넣은 것일까?

아마 계속 쓰일 녀석이라서 fn으로 간편화 한게 아닌가 추측을 하지만 정확한 이유는 모른다.
이렇게 new가 없이 객체를 생성하는 방법을 알아보았다.

[java] 상속 대신 구성을 사용하자.

왜 이 글을 쓰는 걸까

나는 자바 개발자로 일을 하면서 주위 사람들과 계속 이야기 하였다. 하지만 다들 수긍을 하는 듯 하면서 절대 바뀌지 않는 것이 있었다. 바로 **상속 대신 구성**이라는 말이다. 꽤나 오랜시간 구성을 사용하자고 설득하였지만 아무도 변화시키지 못했다. 나의 능력이 부족해서 속상하면서도 한 편으로는 내 말을 듣지 않는 것 같은 동료들이 마냥 아쉬웠다.

그런 의미로 나의 주장을 정리하고 가다듬어야 겠다는 생각을 했다.

내가 처음 자바를 공부할 때부터 들어온 말이 있다. 재사용을 위해 상속을 사용하라. 코드의 재사용을 위해서는 상속을 사용해야 한다. 두 개의 코드가 중복되면 상속을 해라. 그런데 뭔가 이상한 것을 느꼈다. 한 명이 말 한 것이 아니며 나에게 자바를 처음 알려준 강사부터 일터에 나가서 까지 그들은 마치 개발의 시작과 끝은 extends라는 키워드만 알면 다 할 수 있는 것으로 설명했다.

마치 상속이라는 단어가 마법의 단어이며, 이것만 있으면 다른 것을 알 필요도 없고 객체지향이건 유지보수 가능한 구조이며 모든 것이 가능하다고 설파했다.
그런데 막상 시간이 지나면 "이건 뭔가 잘못된 구조야", "아! 이건 상속을 좀 잘못했군. 제대로 했어야지", "앗! 이건 못 고친다. 이거 고치면 다 바꿔야해!" 상속은 점점 사람들을 옥죄었고 무엇이 잘못되었는지 몰랐다.

다들 너무 착하다. 사람들은 마치 상속으로 재사용 도모하라는 책들의 말을 믿고 구조가 이상하게 되면 마치 자기 탓인 것 마냥 아파한다. 자기 머리를 쥐어뜯는다. 하지만 끝까지 상속의 잘못은 아니라고 한다.

하지만 이건 그들의 잘못이 아니다 상속이라는 상아탑을 맹신하게하는 분위기가 그들의 도전을 막는다. 상속은 왠지 클래스 사이에 절대 바뀌지 않을 거라는 약속을 하며 새끼손가락을 거는 것 같다. 장기처럼 한 번 두면 무를 수 없는 약속이었다. 나는 이런 약속을 하고 싶지는 않았다. 무조건 깨질 것인데
후에 이 상속 구조를 자유롭게 수정할 수 있을까? 정말 이 구조가 맞는 걸까? 나중에 이 구조가 틀려서 바꿔야 한다면 바꿀 수는 있는 것일까?

없을 것 같았다. 시간이 지나면 지날수록 상속으로 끈끈하게 만들어진 유대관계는 깨기가 힘들어 보였다. 상속계층의 위로 올라갈 수록 그 약속이 많아지기 때문에 수정되면 안된다. 가령 자바에서 가장 위에 있는 객체는 `Object`이다. 이 녀석은 왠만해서는 절대 바뀌지 않는다. 수많은 자식들이 자신을 쳐다보고 있다. 그 자식들(서브클래스)은 당신(Object)이 변하지 않는다는 것만 믿고 재사용을 하기로 한 것이다.

상속은 마치 서브 클래스가 부모 클래스를 위에다가 그대로 복사해서 쓰는 것과 비슷하다. 만약 부모가 바뀐다고 해보자. 서브클래스도 당연히 바뀐 것이다.

2003년도부터 혹은 그 이전부터 상속은 문제였다.

https://www.javaworld.com/article/2073649/why-extends-is-evil.html

someone : If you could do Java over again, what would you change?
Gosling : I'd leave out classes

고슬링은 클래스를 없애고 싶다고 했다. 덧붙이자면 클래스 자체에는 문제가 없으나 extends관계가 문제이며 `implements`관계를 선호하라고 한다.

어떤 개발자는 자신의 99%의 코드에 상속을 사용하지 않았다고 한다

https://codeburst.io/inheritance-is-evil-stop-using-it-6c4f1caf5117
위 블로그에 있는 내용을 인용하겠다.

Using inheritance is not the only way to extend a class behavior.
But definitely is the most dangerous and harmful one.

I do not use inheritance in the 99% of my code.
And I really mean 99%.

- use interfaces to define the contracts between your classes.
- use final classes to implement behavior for those interfaces.
- use composition (through constructor dependency injection) to put things
together and prevent complexity

[이펙티브 자바]에서는 상속 대신 구성을 사용하라고 권고한다.

자세한 건 책을 참고

[오브젝트]에서는 상속을 절대 재사용을 위해 사용하지 말라고 한다.

계층구조를 표현하기 위해 사용해야 한다고 말이다. 즉 타입을 상속하기 위해서 쓰라는 말이다.

C++창시자분도 유튜브로 상속이 없이 어떻게 개발해야 하는지 발표하는 시대가 왔다.

세상은 정말 많이 변했다. 비야넷 아저씨도 변한 세상에 따라 자신의 주장을 바꿨다.

내가 정리한 문제점

내가 생각하는 상속의 문제점은 아래와 같다.
1. equals 구현에 문제가 생긴다(추이성)
2. 상속을 할 때 부모클래스 중에 구현된 기능이 있다면, 그것을 제대로 알고 구현을 해야 한다. 이 말은 하나의 소스코드가 둘로 쪼개져 있는 것과 같다.
3. 부모클래스가 변경되면 자식클래스 또한 전부 점검해야 한다.
4. 자식클래스가 바뀔 때, 부모클래스를 안 볼 수가 없다.
5. 버그를 찾기가 힘들다. 누구의 책임인지 확인하기가 쉽지 않다. 특히 `super`를 함께 쓰게되면 마치 저 클래스 멀리 있는 코드가 내 코드처럼 행동하면서 핑퐁을 하기 시작한다. 위로갔다 내려왔다 롤러코스터를 타게 된다.

그러므로 나는 상속보다는 `Composition` 소위 구성이라는 기능이 기본이 되어야 한다고 생각한다. `Composition`은 상속과 다르게 내부 구현을 알 수 없다. 필요한 부분에만 책임을 위임한다. 내부 소스로직이 수정되었다고 다른 소스에 문제를 일으키지 않는다. 위임한 책임만 완수하면 어떻게 바뀌던 상관이 없다. 하지만 상속은 문제를 끼칠 수 있다. 구성은 그래서 수정에 자유롭다. 아니 아예 전부 뜯어 고쳐서 새로 넣어도 된다. 그렇게 하라고 의존성 주입이 있는 거니까.

방금 구성을 사용해야 하는 다른 이유가 나왔다. 구성은 런타임에 의존성이 바뀔 수 있다. 즉, 프로그래밍이 실행 중에도 내 할일을 다시 집어넣을 수 있다는 말이다. 원래라면 하늘 아래 부모클래스는 하나밖에 가질 수 없고, 그것은 컴파일 이후에는 운명처럼 거스를 수가 없는데 말이다.

결론

글을 쓰면서 내가 틀렸던 건 아닐까 하는 생각으로 정리를 해보았으나.
틀리지 않은 것 같다. 오히려 자신감이 생긴 것 같다.

상속을 쓰기 전에 구성을 할 수 있는지 확인하자. 어떻게 해서든지 구성을 사용하려고 해보자. 코드에 더 믿음이 갈 것이다. 클래스에 final을 붙여서 상속을 막아 보자. 나 자신뿐만 아니라 사람들이 그 코드를 믿게 될 것이다. 상속보다 구성으로 짠 코드를 볼 때 더 별거 아닌 코드라고 생각하는 사람들이 많다. 그것이 목적이다. 더 별거 아닌 것처럼 보이게 더 쉽게 읽을 수 있게 말이다.

[javascript] 이벤트가 동시에 실행되지 않도록 간단한 Lock 객체를 만들어 보았다.

Notion페이지 링크

고쳐야할 부분이 계속 보이지만, 그냥 단순깔끔하게만 사용하면 괜찮을 것 같다.

[리뷰][맨먼스미신]을 읽고

이 책은 저자가 한 프로젝트를 진행하면서 겪었던 내용을 에세이로 적은 책이다.
이 책은 소프트웨어 개발자의 이야기라기보다 인간들의 이야기이다.
우리 인간들이 일을 함께 하면서 일어나는 일이다. 용어들만 바꾼다면 어떤 산업에서도 적용될 이야기이다.

이 책에서 그 유명한 대사가 나오는데 바로

여자 9명이 있다고 아기가 1개월만에 나오는 것이 아니다.

이 대사가 우리가 일을 할 때, 무엇을 생각하고 계획해야 하는지 알려주는 것이라 생각한다.

내용

이 책은 프로젝트를 어떻게 관리해야 하는지 설명한다. 그는 자신이 믿지는 않지만 개발자의 경력과 생산성에는 큰 차이가 없는 연구결과를 지속적으로 알려준다.(믿지않으면서 왜 지속적으로 보여주는 거지)
아마 우리가 생각하는 통념을 조금이나마 깨뜨리려고 하는 것이 아닌가.
나에게 가장 기억에 남는 것은 일반적으로 개발을 해서 앱을 만드는 것과 그 앱을 상용화하기 위한 제품으로 만드는 것에는 아주 큰 차이가 있다는 것이다.

생산성 측면에서 보면 적은 인원의 외과의(스타개발자)가 최고의 성능을 가져오면 버그율도 적다. 하지만 큰 프로젝트를 진행하려면 시간이 아주 오래 걸릴 것이다.
그래서 사람이 더 필요하게 되는데 사람이 더 많아질 수록 의사소통, 교육 등에 병목이나, 마찰율(책에는 없는 단어다 ㅋㅋ)같은 것이 발생하여 진행이 많이 떨어지게 된다는 점을 말한다.
하지만 상용제품은 그밖에도 다른 것들에 문제가 있는데, 바로 요구사항 적립의 체계화, 테스트, 문서화, 재무관리 등으로 실제 개발시간에 수배의 노력(책에서는 9배라고 나온 것으로 기억한다.)이 필요하다는 것이다.

외과 수술 팀이라는 형식으로 팀을 꾸릴 것을 제안한다. 외과의과 나머지라고 부를 수도 있겠다. 바로 집도하는 외과의를 필두로 그를 보조하는 사람들을 분야별로 나눠서 구성하는 것이다.
재무, 프로그래밍언어, 새로운 툴 등을 분야별로 나눠서 처리하여 외과의를 보조한다. 신선한 방식이다. 아직 개발을 하면서 이런 형태를 본 적이 없어서 어떨지는 잘 모르겠지만, 좋을 것 같긴한다.

그리고 뒷부분으로 갈수록 문서화에 대한 내용에 노력을 기울인다. 주목할만한 점 중에 하나는, 개발을 하는데 서로의 이슈나, 요구사항 변경내용을 모두 적어서 모든 담당자들이 보도록 해서 서로 무슨일을 하는지 공유하는 것이 중요하다고 했지만,
종단에는 시간이 지나서 자신이 틀렸다고 말한다. 서로가 무슨 일을 하는지 모르고 자신의 업무에 집중하며 연결되어야 하는 부분에만 집중하는 것이 더 효율적이라고 주장이 대두되었고, 그는 그에 동조한다.

또한 논란이 되었던 은 탄환은 없다는 소프으웨어 개발에 지름길이란 없다는 것을 서술한다.
소프트웨어가 복잡한 것은 그 내재된 성질이기에, 도구로 고칠 수 있는 것이 아니라는 것이다. 객체지향 언어나 다른 방법론들이 쏟아져 나오지만, 결국 복잡성은 밖에 문제가 아닌, 소프트웨어 개발 자체가 가진 성질이며, 그것들을 없애주는 은탄환은 없다고 말한다.

이 책은 개발보다는 소통에 관한 내용이 많다. 그래서 누구라도 읽어볼만 하다고 할 수 있다.

[리뷰][클린 아키텍처]를 읽고

클린 아키텍처는 밥 아저씨의 클린 시리즈에서 가장 최신작인 것 같다.
이 책은 이전에 읽었던 [클린코드]와는 달리 아주 멀리서 소프트웨어산업을 바라보고 자신의 생각을 담아내고 있다.

내용

초반에는 자신이 생각하는 소프트웨어에 대해 설명하며 무엇이 소프트웨어를 더욱 소프트하게 만드는지 알려준다.
소프트함이라는 것은 변하기 쉬워야 한다는 것이다. 변하기 어렵게 만들거였으면, 하드웨어로 만들었을 것이라는 것이 그의 주장이다.
극단적인 예로, 변하기 쉽지만 요구사항에 맞지 않는 프로그램과 요구사항에는 맞지만 변하기 어려운 프로그램을 주어지면 그는 주저없이 첫번째를 선택하겠다고 말한다.
변하기 쉬운 것은 요구사항에 맞출 수 있지만, 후자는 비즈니스 로직이 변하거나, 버그를 발견했을 때, 바꾸기 어려우므로 안된다는 것이다.
물론 전대 변할 수 없는 프로그램은 없다. 하지만 프로그램을 변화시켜서 기대되는 비용과 개발을 하는 비용의 수지타산이 맞지 않을 때, 변할 수 없는 프로그램이라 부를 수 있다면 그런 프로그램은 존재할 것이다.

중반부터는 어떻게 하면 안전한 코드를 만드는지 설명한다. 하지만 코딩자체를 말하지는 않는다. 오히려 컴포넌트나 서비스같은 단위로 설명한다. 하지만 이 모든 내용은 작게는 코드에 대한 내용과 별 다를 것이 없어보인다.
그는 객체지향에 대해 설명을 하지만, 객체지향에 어떤 것도 이전에 C로 코딩을 하던 개발자들을 더 나은 개발자로 만들지는 못했다는 것을 설명한다. 왜냐하면 당시 개발자들 모두 그렇게 개발을 했었기 때문이다.
상속, 캡슐화, 다형성 모두 C언어로 가능한 구현들이었다. 대부분 문법적으로 간단하게 해준 것이며, 그 마저도 어떤 것은 오히려 구현이 불안정하게 만들었다. 저자가 객체지향으로 넘어가면서 얻은 장점은 다형성이라고 주장한다.

그리고는 지속적으로 그래프를 보여주면서 컴포넌트의 의존성의 방향이 얼마나 중요한지 설명한다. 나는 처음 이런 것을 보면서, 저자의 깊이를 더 알게 되었고, 정말 나중에 한 번 더 읽어야 겠다는 생각을 했다.
더해서 DI라는 것이 어떻게 아키텍처에서 쓰이는지 알게 되었다. 아무때나 DI를 다 붙잉는 것이 아니라. 이 방향을 바꾸기 위해서 하는 것이라는 것을 알게 되었다.
더해서 컴포넌트를 분리할 때도 DI를 사용해서 A,B컴포넌트에 서로 로직들이 잘 분리되도록 하는 것이다.

확실히 저자는 다형성에 큰 의의를 두고 있었다.

또 기억나는 것은 바로 구현에 대한 결정은 나중으로 미루라이라는 것이다. 그는 지속적으로 플러그인 패턴을 강조했다. 예를들어, 출력되는 곳이 콘솔일지, 프린터일지, HTML일지 이런것은 나중에 결정하라는 것이다.
환경은 또 어떨까? 웹으로 할 것인지 아닌지도 나중에 결정할 수 있도록 해야한다. 영속성은? DB로 할지도 나중에 결정해야 한다. 단순히 오라클/MySQL/... 중에 뭘 고를지 정하는 것이 아니다.
처음에는 map자료구조에 메모리로 저장하여 개발함으로써 영속성의 결정을 미룬다. 그리고 파일로 저장해서 또 미룬다. 미루고 미룬 후에 결정하는 것이다. 저자는 때때로 DB를 사용하지 않고 파일로 저장하고 가져와서 로딩하는 방식을 사용했다.
왜냐하면 DB가 필요 없었기 때문이다. 파일로도 충분했다.

이 구현을 미루는 것은 아키텍처에게 유현함(soft)함을 가져오게 해주고, 이런 외부 사항들로과 비즈니스로직을 자연적으로 분리시켜주게 된다. 그는 software가 firmware가 되는 것을 싫어했다. 펌웨어는 한 하드웨어에 종속되어 움직이는 경우가 대부분인데
그의 관점에서는 특정 DB에 종속된 것, 아니면 DB에 종속된 것을 펌웨어라 간주한다. 왜냐하면 세상은 많이 복잡해졌고, 그 정도의 종속도 펌웨어라는 것이다.
HTTP에 종속된 것도 펌웨어이다. 그는 코어 로직이 어딘가에 종속되지 않기를 바란다.

예를 들어보면 아래와 같다.

Core <- DB-AccessObject -> DB
     <- Network-Object

여기서 화살표 방향은 해당 객체가 무엇을 사용하는지 알려준다. 왼쪽에 있는 Core컴포넌트는 아무것도 사용하지 않아야 한다. 그래야 플랫폼이 바뀌어도 사용할 수 있다. DB를 사용하기로 결정했어도 Core는 변경되지 않는다. 그런데 말이 되지 않는다. 만약 Network에서 요청이 오고 DB-AccessObject를 실행해야 하는데 어떻게 Core에서는 사용하지도 않는데 실행을 한다는 거지? 그 답은 아래 DI에 있다(!!) 아래처럼 화살표가 되어 있다고 해보자.

Core -> DB-AccessObject -> DB
     <- Network-Object

이렇게 구현하는 것이 자연스러울 것이다. 여기서 DI를 적용하면?!

Core -> I-Persistent(in Core Component) <- DB-AccessObject -> DB
     <- Network-Object

이렇게 I-Persistent를 이용하여 저장하고 조회하는 것이다. I-Persistent는 코어 컴포넌트 안에 있고, 영속성관리를 무엇으로 해도 상관이 없게 되었다.
이것이 DI의 힘이다. 나는 지금까지 재사용을 쓰기 위해서다. 구현이 바껴도 사용할 수 있어서 DI를 쓴다고 알고 있었다. 물론 맞는 말이긴 해도, 이정도의 깊이가 있는 사람이 동일한 말을 하는 사람과는 전혀 달랐다.
나는 이정도의 넓은 숲을 보면서 말하지는 않았다. 왜냐하면 이런 세상을 전혀 몰랐으니까...

방향을 바꿔서 컴포넌트의 분리를 꾀하고, 종단에는 코어를 (유연하게 하는 것)지키는 것.
일류 아키텍처의 속마음을 잠깐 들여다 볼 수 있는 순간이었다.
마지막으로 가면 갈수록 그는 이 DI를 더 강조하는 것처럼 보인다. 그리고 실제적인 예시들을 보여주면서 어떻게 해야 하는지 알려 준다. 사실 다 읽었지만, 완벽하게 이해했다고 생각되지는 않는다.

나에게 또한 많은 생각을 하게 한 내용은 바로 프레임워크다.
그는 프레임워크에 종속되면 안된다고 말한다. 물론 프레임워크 개발자는 당신이 종속되도록 요청한다. 아예 하나의 언어처럼 붙어살길 원한다. 하지만 당신은 그렇게 하면 안된다는 것이다.
당신은 프레임워크를 툴로 써야 하며, 언제든지 바꿀 준비가 되어있어야 한다. 도구로써 써야 한다. 마법과 같은 일을 할 수 있다고 계약하지 말라.
당신에게 분명 되돌아 온다. 프레임워크에 종속되어 펌웨어가 되지 말라고 한다.

예를들어 자바의 스프링프레임워크를 예를 들면, Autowired를 하지말라고 한다. 차라리 Main에 다가 종속성을 다 쓰라고 말한다. 당신이 사용하는 모든 클래스에 spring이 import되어 있다면
종속되어 있는 것이다. 어쩌면 플러그인 패턴을 사용하여 DI로 프레임워크를 분리해서 사용하는 것이 해답이 될 수도 있을 것 같다.

끝없이 소프트하게 하라, 그것이 소프트웨어 개발자가 해야 할 일인 것이다.

이 책은 분명 다시 읽어야겠다. 누군가가 개발자가 되었다면, 그리고 소프트웨어개발자라면, 언젠가는 읽어야 할 책이라고 소개하고 싶다.