tidibooks

tidybooks 개발 일지 02 - 도구들


Architecture

모든 얘기는 여기서 시작한다.

위 이미지는 trello 를 제작한 fogcreek 의 블로그 글에서 찾았다. 사용해보고 싶은 것 모두 들어가 있는 것에 놀라며, 그래. 나도 요렇게 한번 만들어봐야지.. 했었다.

물론 실제 프로젝트에서 이런 그림을 개발자에게 들이댔다가 뭔 얘기를 들을지는 모르겠다. 요렇게 만들어주세요. 하면 뿅하고 만들어주실 개발자분들 없나.. 없겠지.

하지만 고민할 필요없지. 내가 해보면 되니까.


Front-end

CSS framework ( bootstrap )

이건 뭐 다른 선택의 여지가 없다. 사용도 쉽고 깔끔하기도 하고.

AMD ( require.js )

코드가 깔끔하게 떨어지는 맛이 있어 쓰려했다. node.js 에서 require 하듯 사용하는 방법도 마음에 들고 쓸데없이 복잡한 패턴이나 scope 를 없애고 이해하기 쉽게 만들수 있는 것 같다. 하지만 backbone과 함께 쓰면서부터 삽집이 재앙 수준이었다.

MVC framework ( backbone.js )

이전부터 봐오던 backbone.js 를 사용한다. 사실 오래전부터 knockout 이나 ember 를 함께 눈여겨 보고 있었고 최근 angular 까지 봐왔지만, 결과적으로 backbone 을 선택하게 된 이유는 가장 많은 사용자가 있어서였다. 사용전까지만 해도 이게 과연 효율적인 것으로 기억될 것인가, 아니면 그냥 단지 취미생활 단위의 호기심을 채우는 비효율  덩어리인가 고민하게 했지만, view를 쌓을 때마다 backbone이 줄여주는 수고가 눈에 보인다. 하지만... 꽤 많은 후회와 상당한 양의 삽집을 함께 하고 있다.

Library ([ underscore, jquery, jquery.wookmark, jquery.imageloaded ])

jquery 는 당연한 얘기일테고, backbone을 사용하니 underscore 도 마찬가지로 필수 항목. 이번에 underscore를 사용하며 bind 와 bindAll 의 유용하지만 지랄맞은 사용방법이나 포함된 여러 function 에 만족하고 있다. wookmark 는 레이아웃 정렬에 사용, imageloaded 는 간단하게 $().load 로 어찌 해보려다가 ie 에서 지랄맞은 반응을 보여줘서 결국 가져다 쓰게 되었다.

HTML Templete ( Dot )

backbone.js 가 기본적으로 가지는 html parser가 있는데, php 에서 보던 문법이 마음에 들지 않아 바꾸었다. 이상하게 저걸 치는게 손이 더디다. 처음에는 mustache 스타일로 바꾸는 것으로 만족하려 했지만 이것저것 걸리는게 많아 아예 엔진을 바꾸기로 했다.  Dot를 선택한 이유는 jsperf 에 올려진 테스트 결과를 보고 결정했다.

Javascript compiler ( null )

coffeescript 를 눈여겨 보고 있지만 개인적으로 커피스크립트로 짜여진 코드의 이해가 어려워 손대지 못하고 있다.


Server side

Language ( node.js )

물논, 고로코 말고. javascript 야 말로 다룰줄 아는 유일한 언어. 선택의 여지가 없다. 좀 익숙해지면 ruby 나 python 써봐야지.

WebApp framework ( express )

node 라면 당연 express 인거지. 최근들어 선택의 여지가 많아보이지만 딱히 더 강력해보이지 않아 그냥 사용했다. 결정적으로 찾아볼 수 있는 글이 많고, 문서화가 잘 되어있다.

ODM ( mongoose )

mongoDB npm 패키지가 있고 사용방법도 거의 유사해 mongoose 가 말하는 odm 이 정확히 뭔지 잘 모르겠지만, 여튼 mongoose 외에는 문서화된 내용이 더 적어 선택의 여지가 없어보인다. 하지만 mongoose 도 마찬가지로 자세히 설명된 사용방법을 찾기가 정말 힘들다. 공홈의 문서는 없는 것보다야 낫지만 부족하다. 이럴거면 차라리 다른 DB를 선택하는게 어떨까 싶은 정도. Amazon DynamoDB 를 눈여겨 보고 있다.

request / communication ( socket.io )

express router 에게 ajax로 데이터를 주고 받는 일을 아예 없애버리고 몽땅 socket 으로 넘기도록 했는데, 덕분에 굉장한 삽집을 경험하고 있다. 진짜 이건 실제 프로젝트라면 쓰고 싶지 않다. 공홈의 부실한 문서와 내 코드가 문제인지 socket이 문제인지 세상이 문제인지 고민하게 만드는 지랄맞은 결과물 등, 현재 프로젝트에서 가장 많은 바보짓을 유발하고 있다.


DB

mongoDB

mongoose 와는 별개로, 우선 mongoDB의 key-value store 방식이 매우 마음에 든다. mysql 로 뭔가 만들때의 테이블 구조와 고민들에 비하면 이건 뭐 시작이 너무 쉽다. 다수 사용자와 샤딩 얘기 나오면 어찌될지는 모르겠다.

redis

mongoDB와 달리, 세션 정보와 socket의 data store를 위해 사용했다.처음에는 무료 호스팅을 받아 사용했지만 사용량 제한도 너무 적고, 커넥션 갯수 제한 때문에 자꾸 worker가 죽어나가고 에러 뜨고 지랄옘병을 해대서 ec2에 redis를 설치해 사용중이다. socket.io 와 연계해 사용하는 것 때문에 삽질이 많다.


Equipment

서버를 어디에 올릴지는 아직 고민중이다. 지금 하나 쓰고 있는 까페24 가상호스팅을 하나 더 받을까, 아니면 aws 를 써볼까 생각중이지만, 현 단계에서는 미정.

mongoDB 는 무료 호스팅을 하나 받아 쓰고 있으며,

redis 를 위해서 free tier micro ec2 인스턴스 하나가 돌고 있다.

// 02

사실  장점만 보고 그저 써보려는 욕심에 가져다 쓰는 것들이 많았다. 이게 효율적인가 하는 질문에 대해서는 현재까지는 그렇지 않은 것으로 보인다, 라고 답하고 싶다.

Comment Stream