 THINK FREE

새로운 에디터가 나올 때 마다 이것 저것 써 보고 와~좋다 하지만, 결국은 다시 emacs 나 vim 으로 돌아오게 된다능..

AWS Lambda와 API Gateway가 런칭할 때부터 관심은 가지고 있었지만, 대수롭게 생각하지 않다가, 최근에 몇 가지 개인 프로젝트를 하면서 사용해보게 되었는데, 정말 인상적이었다.

"와, Serverless의 세상이 진짜 오는구나."

얼마전에 슬랙 명령어와 개인적으로 사용하는 범용 함수를 간단한 API로 만들어서 사용하려고 했는데, 겨우 이것때문에 EC2등의 서버를 추가하는 것이 좀 부담스러웠다. 그래서 문득 생각난 것이 AWS Lambda 여서 사용해보게 되었다.

"와, 정말 편하다."

아직, 퍼포먼스는 약간 떨어지지만, 관리적인 측면에서 이처럼 편할 수가 없다. 단순히 서버 관리뿐 아니라, 배포나 확장 문제, 또한 보안 측면에서도 거의 신경 쓸 부분이 없다. 물론 이런 것은 Heroku 같은 것을 사용해도 비슷한 효과를 누릴 수 있지만, AWS Lambda는 개별 서버에 배포한다는 개념을 없앴다는 점에서 조금 더 진보한 부분이 있다. "이것이 바로 레알 클라우드 서버야" 라는 느낌이랄까?

또한 작은 기능 단위로 하나씩 만들어서 올려두어야 한다는 점이 개발적인 측면에서도 상당히 좋은 영감을 준다. 반강제적으로 마이크로 아키텍처와 Stateless 개념에 기반하여 만들게 되기 때문에, 의존성을 줄이고 확장성을 쉽게 높일 수 있게 된다. 직접 서버를 운용해야 한다면, 이렇게 작은 기능 기반으로 만드는 것은 서버를 운용하기 까다롭기 때문에 쉽게 접근할 수 없는 방법인데, 서버의 확장에 대한 문제를 고려할 필요가 없으니 쉽게 접근이 가능하다.

어제 mecab 랩핑 라이브러리를 만들면서, 명사만을 추출하는 함수를 만들 때, 조건문 부분을 코딩하며 생각했던 사고의 흐름을 소개해본다.

추출 대상이 되는 명사의 태그 종류에는 NNP(고유명사)와 NNG(일반명사)가 있다. 그 외의 태그들도 있지만, 명사만을 추출하는 대부분의 경우는 태그 클라우드 등을 만들기 위함이니 두 가지의 종류만 사용하는 것이 대부분일 것이다.

이 둘 중의 하나의 태그일 때만 로직을 돌게 하려면 조건문을 어떻게 써야할까? if 문을 사용 하는 것이 좋을까? 아니면 딕셔너리 참조등을 사용하는 것이 좋을까?

NNP와 NNG 이외의 다른 태그를 나중에 추가하게 될 수도 있겠지만, 일단은 두 개가 기본이니 거의 바뀌지 않을 것이고, 그렇다면 당장은 명시적인 if 문을 사용하는 것이 좋겠다. 그러면 if 문의 조건은,

if (tag === ‘NNP’ || tag === ‘NNG’) {

이렇게 해야할까? 아니면,

if (tag === 'NNG’ || tag === 'NNP’) {

그럼 둘 중에 어떤 것이 성능이 좋을까? 아무래도 고유명사보다는 일반명사가 대개의 경우 훨씬 더 많을 것이므로, 일반명사의 조건을 앞으로 빼는 것이 좋을 것이다.

그래서 마지막으로 선택한 것이 후자.

오래전부터 생각만 하다가 최근들어 빨리 프로토타입이라도 한 번 만들어봐야겠다고 생각하고 있는 프로젝트가 있는데, 그 프로젝트에는 한국어 형태소 분석기가 반드시 필요했다.

한가지 놀랐던 것은, 예전과는 다르게 요즘엔 공개된 형태소 분석기가 꽤 많아져서 선택을 하는 것이 오히려 더 어려울 정도였다. (이런 환경을 만들기 위해 애써주신 분들께 정말 감사드립니다. (_ _))

공개되어 있는 다양한 형태소 분석기 중에서 어떤 것을 쓸까 고민했는데, 내가 원하는 기준에서는 mecab-ko가 가장 나았다. mecab이라는 일본어 형태소 분석기를 한국어에 맞게 수정한 버전인데, 일단 로딩 및 파싱 속도가 가장 빠르다는 것이 최고의 장점.

그리고 mecab을 랩핑한 Node.js 모듈이 몇 개 있었는데, 그 중 mecab-async, mecab-ffi 라는 두 개의 모듈이 가장 많이 쓰이는 것 같았다. 다만, 내가 원하는 형식에는 조금 맞지 않아, 야크쉐이빙을 한 번 해 보기로 했다. 내가 원하던 형태는 KoNLPy라서 이 모듈의 인터페이스를 참조해서 만들기로 했다.

그리고 그 결과물 mecab-ya (이제 눈치 채셨겠지만, 사실 이 글은 광고글임다 ㅋㅋ 깃허브에 별점 좀 찍어주십셔 굽신굽신(_ _);;)

mecab-ffi 처럼 ffi 모듈을 이용해서 만들어볼까 했지만, mecab이 워낙 성능이 좋아 ffi 모듈을 이용하는 것과 프로세스를 띄우는 것 차이에 성능차가 거의 없었고, Node.js의 특성상 의존성과 성능측면을 고려하여 프로세스를 띄우는 방법을 쓰기로 했다.

우리 회사에서는 Promise를 사용하기 위해 Q 라이브러리를 사용하고 있고, 유닛 테스트를 위해서는 nodeunit을 사용하고 있다.1

특히 Q는 백엔드에서는 모든 라이브러리를 Q로 랩핑해서 사용하는 것을 기본으로하여 Promise 사용을 강제하고 있다. Promise의 장점은 여러가지가 있는데, 내가 생각하는 가장 중요한 장점은 다음의 두 가지라고 생각한다.

callback 로직을 절차형 로직으로 이해하기 쉽게 코드를 만들 수 있다.

예외처리/에러 핸들링을 쉽게 해 준다.

그 중 Promise를 강제로 사용하록 한 가장 큰 이유는 2번의 예외처리 핸들링이다. Express.js와 다양한 Node의 필수 패키지들을 만든 TJ가 Node 진영을 떠나면서 썼던 글(Node.js를 떠나며)에도 나왔듯이, Node는 예외처리/에러 핸들링이 쉽지 않아 Node서버를 자주 죽게만드는 1등 공신이라 할 수 있다.

그런데, Promise를 사용하면 그런 예외처리의 상당수를 쉽게 제어할 수 있다. 그래서 대부분의 로직이 DB/캐시등에 집중되어 있는 웹서비스 개발의 경우, Promise로 콜백 로직을 모두 감싸면 알 수 없는 예외로 서버가 죽는 경우를 상당부분 막을 수 있고, 로직이 눈에 명확히 드러나므로 디버깅 역시 조금 더 수월하게 할 수 있게 된다.

다음의 예제를 보면, Promise 안에서 예외가 발생한 경우의 처리와 테스트(사용) 로직이 얼마나 깔끔해지는지를 어느정도는 느낄 수 있지 않을까 한다.

테스트 프로젝트 : https://github.com/golbin/q-nodeunit-sample

사람마다 개발하는 방식이 달라서 이것이 반드시 맞는 방법이라 할 수는 없겠지만, 어느정도 사용해 본 결과 Promise는 이제 선택이 아니라 필수로 사용해야 하는 것이 아닐까한다. 신규 프로젝트나 또는 가능하다면 앞으로는 Promise를 강제로 사용하는 것을 추천하고 싶다.

golbin: 나도 동성혼 합법화를 지지하는 입장이지만, 그렇다고 동성혼을 지지하지 않는 사람을 비난하거나 미개하게 생각한다면 그게 더 잘못된 것 아닌가? 정말로 다양성을 인정하는 사람이라면, 동성혼을 인정하지 않는 것도 인정해줘야하지 않나 싶은..

ahastudio: 다양성을 최우선 가치로 여긴다면 그렇겠지만, 대부분의 경우 그 다양성이란 건 몇 가지 검증 단계가 있기 마련입니다. 1+1의 답에 대해 무제한의 다양성을 요구하진 않죠. 우리는 식인, 폭력, 학대에 대해서도 다양성을 열지 않습니다.

ahastudio: 진짜로 다양성이 요구되는 지점은 법적, 물리적으로 특정 권리를 제약하고 있을 때입니다. 흔히 “너는 틀렸어”라고 말하는 건 담론 레벨이고, 앞에서 언급한 것들과는 엄격히 구분돼야 하죠.

golbin: 긴 토론이 필요하겠습니다만, 다양성 인정, 차별에 대한 범주라는 것은 시간이 갈수록 점점 넓어지고 있고, 그 시대에 그것을 받아들이지 못하는 사람이 있는 것 역시 당연하다고 생각합니다. 각기 나름의 다양한 삶을 살아왔으니까요.

golbin: 윤리적인 문제도 마찬가지인데, 이를테면 근친혼이라든가 하는 것도 차별을 받고 있다고 할 수 있는 것이라고 할 수 있지 않을까 싶은데, 이 부분은 대부분이 암묵적으로 당연하다고 생각하는 부분이죠.

golbin: 아무튼 가치관등에 따라 다양성에 대한 정의 역시 달라질 수 있고, 그러므로 동성혼을 받아들이지 못하는 사람도 충분히 있을 수 있고, 그런 사고방식이 현대에 맞지 않는 것이지 틀린 것이라고 볼 수는 없지 않을까 합니다.

ahastudio: 저는 이런 문제를 만났을 때 그것은 차별이 맞다고 인정하느냐 안 하느냐가 자유주의자인가 아닌가를 가르는 기준이라고 생각합니다. 공통공간에선 결론이 늘 하나라서(대표적인 게 바로 재판이죠), 맞냐 틀리냐에서 벗어나는 건 불가능합니다.

ahastudio: “시대에 맞지 않는다”라고 포장한 건 정치적으로 보면 “틀렸다”는 걸 예쁘게 포장한 것에 불과하죠. 현실에서, 실천적으로, 동성결혼이 법적 허용되냐 마냐에 대한 결론은 하나거든요.

golbin: 그런 관점이라면, 법적으로 허용이 안 된 우리나라의 경우 동성혼은 아직까지는 틀린 일이 되는데요. ㅎㅎ

ahastudio: 아뇨. 그건 제 논리를 거꾸로 읽으신 게 됩니다. 정치적으로 맞냐 틀리냐를 우리는 결정해야 한다는 거고, 그래야 그게 법적/실천적으로 반영됩니다. 우리는 그걸 다양성이란 변명으로 미루면 안 된다는 거죠.

ahastudio: 제가 하는 이야기는, 담론 레벨이 아니라 현실에서는 결국 답이 하나란 겁니다. 이걸 다양성이란 이름으로 포장해봐야 한국 같이 엉터리인 상태가 유지된다는 거죠. 분명히 특정 권리를 제약하고 있는 틀린 상황이죠?

golbin: 즉, 이것이 나에게는 틀린 것이지만 다른 사람에게는 맞는 것일 수도 있다고 봅니다. (물론 저는 틀린거라고 생각합니다만 여튼) 지구가 돈다는 것이 틀린 것이라고 생각했던 과학도 그럴진데, 사고방식이나 가치관은 더욱 그렇죠.

ahastudio: “권리=자유”에 대한 이해가 바로 자유주의와 다른 것을 가르는 경계입니다. 타인의 자유를 침해하는 범죄가 아니라면, 우리의 자유는 제약될 수 없습니다. 이런 게 상대적일 수 없다는 게 바로 근대정치의 기본입니다. 보편인권사상이죠.

ahastudio: 보편인권 이슈를 후퇴시키는 것도 무리고, 이미 벌어지고 있는 현실입니다. 현실을 담론 레벨로 축소하기 때문에 상대주의가 가능한 겁니다. 현실은 그렇지 않죠.

golbin: 아무튼, 그보다 제 논지는 생각의 차이가 있는 사람들을 비난해서는 안된다는 것 입니다. 비판은 할 수 있겠지만요. 더군다나 가치관이나 사고방식 같은 것은 맞고 틀리다는 것으로 재단할 수는 없는 것이라고 생각합니다.

ahastudio: “유태인을 죽이는 것은 정의롭다”란 가치관은 옳다 그르다 따질 수 없을까요? 현실에선 매우 중요한 문제입니다. 상대주의가 적용되는 분야는 이런 곳이 아니죠.

ahastudio: 러브라이브가 옳냐 이이돌마스터가 옳냐 이런 이야기를 하자는 게 아니죠. 미학과 윤리학이 만나는 지점은 있어도 이 둘을 막 뒤섞지 않는 이유입니다.

golbin: 흠. 핀트가 자꾸 나가는 것 같지만 ㅎㅎ 제가 생각하는바도 권리 보장을 위한 차별금지라는 부분에서는 아샬님하고 비슷한데요. 제가 말하고 싶은 요점은 다양성을 존중하지 않는 사람들을 비난하는 것은 옳은 일일까요? 라는 부분입니다.

ahastudio: 골빈해커님의 포지션을 의심하는 게 아닙니다. 제가 계속해서 말하는 건 보편인권=권리=자유 이슈에 다양성은 없다는 겁니다. 모든 내용이 그것의 반복입니다.

golbin: 음, 그러한 권리는 필요 없다는 가치관이나 의견도 있을 수는 있는 것 아닌가요? 그러니까 보편인권 자체를 인정하지 못하는 의견은 있을 수 없다라는 건가요? 그게 아니라면, 그러한 가치관에 대한 다양성을 인정해줘야 하는 것 아닐까요?

ahastudio: “그런 권리”란 게 따로 있지 않습니다. 기본적으로 공화국은 보편인권을 전제로 구성됩니다. 이걸 파괴할 경우 적용되는 게 바로 형법이죠. 현실 문제를 단순 가치관 문제로 후퇴시키면 안 됩니다.

ahastudio: 논의는 단순합니다. “유태인학살”이 옳냐 그르냐를 따질 수 없는 다양성에 속하느냐죠. 아이마스냐 럽라냐와 다른 층위라고 구분하느냐 하는 거죠.

golbin: 음. 그렇다면, 좀 극단적이긴 한데, 보편인권을 전제로 한 공화국인 한국에 태어난 이상 그런 가치관이나 의견을 가지면 안된다는 걸까요? 그럼 다른 나라로 가면 그런 의견을 가져도 되는걸까요? 라는 또 다른 삼천포가 생각나네요. ㅎㅎ

ahastudio: 이것 또한 제 논리를 거꾸로 따라간 겁니다. 우리가 공통영역에서 만든 걸 공화국으로 구현하는 거지, 공화국이 선행하지 않습니다. 제가 아까 이야기한 케이스죠.

golbin: 그렇다면 공화국이 아닌 다른 나라는, 이를테면 인도나 아랍쪽 같은 경우는 차별을 기반으로 한 사회가 공통 영역이었고, 그걸 기반으로 나라가 구현(?) 된 것이지 않나요?

ahastudio: 네, 이건 정말로 삼첨포로 빠졌는데 1) 일단 우리나라는 그렇다란 걸 분리하겠습니다. 2) 인도의 경우엔 공화국입니다. 우리나라와 동일하게 봐도 되죠. 3) 아랍 왕국의 경우엔 국제사회에서 이슈가 됩니다. 바로 UN에서요.

ahastudio: UN은 법적 강제력을 갖고 있지 않지만, 국제연합은 일정한 테두리를 만들어서 운영되고 있습니다. 거기에 세계인권선언이 포함되지요. UN에 가입했지만 그런 건 무시하겠다고 하는 건 늘 비난의 대상이 됩니다.

golbin: 그렇다면 의문은, 모든 나라는 인권에 관해선 궁극적으로는 동일한 가치관을 가져야한다인건가요?

ahastudio: 제가 무엇이 먼저냐를 따지는 걸 보면, 이게 나라에 얽힐 문제는 아니라고 생각합니다. 보편인권은 매우 작고 단단합니다. 이것은 허용범위를 갖는 게 아니라, 불가능을 갖습니다. 서로 충돌하지 않는 범위가 바로 권리=자유의 범위입니다.

ahastudio: 하지만 현실에선 그렇지 않죠. 그 지점을 저는 다양성이 지지하는 게 아니라고 말씀드리고 싶습니다. 그리고, 이건 가치관이 아닙니다. 현실이죠.

golbin: 음. 정리하자면 아샬님 말씀은 동성혼 법제화는 보편인권에 해당하는 것이기 때문에 다양성이 있을 수 없고, 그러므로 그것을 반대하는 것은 인정할 수 없으므로 틀렸다고 말 할 수 있다는 것이겠고요.

golbin: 제 이야기는 사람의 가치관이라는 것은 모두가 같은 경험과 지식으로 공통되게 형성될 수 없으므로 그 사람의 생각을 인정해줘야 한다는 말인데요.

golbin: 제 글에서 정정되어야 할 부분은, 다양성을 인정하라가 아니라, 그 사람의 생각이 현재 그럴 수 있다는 것을 이해하고 존중은 하되, 그러한 생각은 보편인권을 생각했을 때는 잘못된 것이라는 것을 계몽해야 한다. 정도가 되어야겠네요.

golbin: 으아.. 손석희씨가 옆에 있었으면 좋겠네요. ㅎㅎ

JavaScript 라이브러리 중에 거의 jQuery 다음으로 많이 사용하지 않을까 싶은 라이브러리 중에 underscore 또는 lodash 라는 것이 있다. (두 라이러리는 차후 합치는 것이 논의되고 있다.)

이 라이브러리들은 다양한 데이터들을 체인 형태로 실행 할 수 있게 해 주는 라이브러리로써 로직을 깔끔하게 유지시키는데 좋은 역할을 해 준다. JavaScript 기본 함수에도 배열을 처리하는 map, reduce 같은 것이 있지만, lodash와 underscore가 조금 더 편하게 사용 할 수 있고, 추가로 다양한 유틸리티들이 포함되어 있어서 우리 회사에서도 기본 라이브러리로 사용하고 있다.

그 중 lodash에는 지연 실행(Lazy Evaluation) 기법이 포함되었는데, 이에 대해서 간단하게 설명해보고자 한다.

배열을 처리하는 일반적인 방법은 바로 다음과 같이 for 문 같은 루프문을 사용하는 것이다.

이를 lodash의 map과 filter를 이용해서 함수형 툴체인 기법으로 변경하면 다음과 같이 된다.

이 기법이 익숙하지 않다면 처음엔 약간 이해하기 쉽지 않을 수 있지만, for 루프에 비해 각각의 로직이 명확하게 분리가 되어 있으므로, 차후 디버깅을 하거나 로직을 추가/수정할 때 훨씬 쉽고 편하게 할 수 있다.

다만, 각각의 map/filter 함수마다 루프를 한 번씩 돌고, 또 각각 루프를 돌 때 마다 배열을 새로 생성하므로, 상황에 따라 실행속도가 급격히 느려지거나 메모리를 과도하게 잡아먹는 문제가 생길 수 있다.

이를 해결하기 위해 지연 실행이라는 기법이 생겼는데, lodash의 경우 다음과 같이 사용할 수 있다.

사용법은 간단한데, 첫 함수 사용시 lodash 의 _.map(numbers, function) 대신에 _(numbers).map(function) 이와 같이 lodash의 생성자를 이용해 객체를 만든 뒤 함수 체인을 사용하고, 함수체인의 마지막에 .value() 를 붙여주면 된다.

이렇게 하면 함수체인으로 연결되어 있는 각각의 함수들이 배열의 모든 요소들을 처리한 뒤에 다음 체인으로 넘어가는 것이 아니라, 요소 하나를 처리하고 다음 체인으로 넘기는 방식으로 실행 방식이 변한다.

즉, map에서 첫번째 요소에 1을 더하고 filter 에서 2보다 큰 값인 경우만 다음 map 에서 자승을 리턴. 그 다음 두번째 요소를 같은 방식으로 처리, 그리고 또 그 다음 세번째 요소를 같은 방식으로 처리. 이런 방식으로 for 문과 같은 형태로 루프를 돌게 된다.

따라서 요소 3개가 있는 3개의 함수 체인은 최대 9번(여기서는 8번)의 루프를 도는 반면, 지연 실행으로 실행한 함수 체인은 요소의 갯수만큼인 3번의 루프만 돌게 되어 실행 속도를 획기적으로 줄일 수 있게 된다.

참고로, 맨 마지막 체인에 reduce 등을 넣으면 value를 사용하지 않아도 된다.

또한 다음처럼 함수 체인에 들어가는 함수들을 모두 독립 함수로 빼서 조금 더 함수형 프로그래밍에 가까운 형식으로 만들면, 로직이 복잡한 경우라도 훨씬 더 이해하기 쉽고 유지보수가 쉬운 코드로 만들 수 있다.

언젠가 팀원 중 한 명하고 얘기를 하다가 재미난 사실(?)을 알게됐다.

기획팀하고 개발팀하고 회의를 하는데 프론트엔드 개발팀 팀장님하고 나하고 싸우길래 왜 저러지? 하고 벌벌 떨다가, 갑자기 결론이 나면서 화기애애하게 얘기도 하고 그래서 이건 뭔 상황이지? 그랬다고.

이후에 또 다른 기획팀 팀원이 들어왔는데, 나랑 그 팀장님이랑 자리에서 막 싸우길래 '두 분이 사이가 안 좋아요?' 라고 물어봤다고 한다.

알고보니 토론을 격하게 하는거였고, 둘 다, 틀리거나 더 좋은 의견이 나오면 바로 수긍하는 스타일이어서 그런 것이었는데, 남들이 보기에는 오해할 수도 있는 상황으로 보이는 것.

어떤 의견이 진짜로 맞는 것인지 토론하는 것은 전투와 비슷한 것이라고 생각한다. 물론 나와 상대가 싸우는 것이 아니라 논리와 논리를 싸움 시키는 것으로써 말이다. 그리고 나 또는 누군가의 지식과 논리는 당연히 틀리거나 깨질 수도 있고, 회의를 나와서도 생각이 바뀔 수 있는 것은 당연하다. 진리로 믿었던 과학 논리조차 계속해서 깨지고 있는 판에, 당장 내 작은 생각 따위가 뭐라고.

물론 나의 의견을 강하게 주장하려면 애착을 가져야할 것이고, 반면에 나의 의견을 나와 동일시하면 마음에 상처를 받을 수도 있다. 하지만, 사람에 따라 쉽지 않을 수 있겠지만, 그래도 좀 더 나은 결론을 도출해 내길 원한다면 최대한 치열하게 해야 하지 않을까?