Rhythmga.me 프로젝트 #1 / 도구 준비와 구조 설계

Rhythmga.me 프로젝트의 구조격인 where 서브프로젝트의 개발을 시작하기 전, 몇년간 많은 고민과 깊은 후회 그리고 짊어져야 할 부담감 같은것들을 안은채로 있었다.

그렇기에 CodeIgniter, Laravel, 많은것들로 프로토타입도 제작하고 뒤엎어봤지만, 만족할만한 결과물은 썩 나오지 못했다.

그렇다고 CMS를 안찾아본건 아니다. XE1, XE3 등 모든 가능성을 두고 찾아봤지만 러닝커브 자체부터가 만만치 않았으며 디버깅 및 CMS 코어 자체의 무게감 등 모든 요소를 고려해야겠기에 반려되었다.

그렇기에 내가 내린 결론은 다음과 같았다.

백엔드 : Node.js(ThinkJS)
프론트엔드 : Material Design Lite
DB : RethinkDB

백엔드는 Non-blocking IO를 자랑하는 Node.js를 사용한다. ES6지원이 최근 추가되기도 하였고, 만족할만한 IO에 퍼포먼스를 보여준다. 물론 사용자가 좀 늘어나면 램 확충이나 V8엔진의 GC로 인해 다시 생각해보긴 해야겠지만, 아직은 만족스럽다.

프레임워크인 ThinkJS의 경우 생산성을 높여주는 ES6/ES7기반 MVC 패턴의 프레임워크다. 치후360 백엔드팀에서 개발해서 깃허브 이슈에도 중국어로 쓰여있는게 단점이다. 그리고 결정적으로 메뉴얼 내용이 빈약하다. 그렇지만, 생산성을 높일만한 내용들로만 구성되어있어 아주 알차게 사용하고있다. PHP에서 CodeIgniter를 사용하던 느낌, 그 느낌 그대로다. 느낌만 그대로지 내용물은 오히려 더 괜찮다(ES6를 먹은탓일까). 그렇지만 라우팅부분이 빈약하기도 하고, 자동 라우팅이 마음에 들지 않아 라우터 부분은 고쳐 사용해야겠다는 판단이 앞선다.

Material Design Lite를 사용한 이유는 모바일/데스크톱에서 단기간에 같은 경험을 주어 사용자들을 만족시키고 싶었던게 주된 이유다. 그렇지만 Material Design Lite를 사용한게 지금 가장 후회스러운 선택이 되고있다. 다음 프로젝트때는 절대로 쓰지 않으리라. 참고로 다음 프로젝트때는 단순 반응형 모듈로 부트스트랩4를 사용하려고 한다. em단위로 바뀌어서 마음에 든다.

RethinkDB는 강력한 스트리밍 기반의 NoSQL 데이터베이스다. 이 DB를 고른 이유는 다음과 같은데

  1. 사용자들은 주로 반복되는 형태의 쿼리요청을 한다. 그 과정에서 구조를 바꾸지 않고 몇년간 단순히 아웃스케일 방식으로 성능을 늘리려면, 서버의 반응속도마저 아낄 수 있는 데이터베이스를 사용해야한다.
  2. 서브프로젝트인 where에 사용되는 지도기반 서비스에서 되게 유용하게 사용 가능하다(사용자의 거리에 따른 쿼리 요청 반영. 예를들면 500m -> 1km -> 5km -> 10km 식)
  3. NoSQL이니까. 모델링 부담이 이전 RDBMS에 비해 전혀없다.
  4. 스트리밍 기능이라는 특수한 목적의 NoSQL 데이터베이스이기에. 실시간의 I/O가 많은 데이터베이스들에 유리할것같았다.

그렇게 국내에는 사용자라고는 눈꼽만큼도 찾아볼 수 없는 RethinkDB와 ThinkJS라는 생소한 물건들을 통해서 개발을 시작하고 있다.

물론 다른 도구를 생각해본적도 있다. 나중에 중요한 데이터들에 대해서는 RDBMS의 사용을 고려하고있지만, 현재 지금으로써는 RDBMS를 사용하는 가능성은 0퍼센트에 수렴하고있다.

그리고 구조의 경우 현재 개발서버/라이브 서버 두개로 나누어 운영하려고 한다.

서버호스팅은 GMO International의 ConoHa에서 받고있다. 국내에서 클라우드 쓸일은 1에도 없다. 이말인 즉슨 서버는 무조건 해외에서 운영시키려고 한다.

글로벌 진출을 염두하고있냐면 무조건 대답은 No다. 서버 메인터넌스로 인한 문제가 생겨도 국내 서버들은 죽어도 안쓸거다. 회선장난질과 말도안되는 비용요구로 인해 지친지도 꽤 오래되었다. AWS도 생각안하고있다.(무자본 스타트업에게 있어서 AWS 프리티어를 사용하고도 상회하는 금액은 고통스럽다)

차후 사용자가 많을경우 DB서버만 아웃스케일링 방식으로 운영하려고한다. 세션의 경우 SSO인증도 필요해서, Redis가 필요하지 않을까 싶었지만 1코어 안에 다수 사이트가 운영되는 구조(모듈방식)이라 Redis가 굳이 필요할까 생각된다.

배포 및 운영의 경우 pm2를 이용하려고 한다. 배포도구로 Grunt와 Gulp를 많이 생각하고있었는데, Gulp의 경우 메뉴얼이나 플러그인들이 원하는대로 작동하지 않는 경우가 많아서 스트레스가 끝까지 받은 상태이다. pm2의 같은 경우 모니터링에 있어서 좋은 이야기도 많고 나도 만족스럽게 사용하였으니까 계속 쓰려고한다.