Rhythmgame 프로젝트 / #4 안녕

사실상 프로젝트 폐기를 결정했다.

솔직히 꽤 힘든결정이였다. 근 4년간 준비해온 모든 작업물과 아이디어를 폐기한다는건 참 힘든 일이다.

주변에 포트폴리오와 프로젝트 개요를 들고가면 모두들 ‘아이디어는 좋지만 수익성에 대해서 의문이다’ 라는 말이 돌아왔다.

스타트업에게 있어서 필수불가결 조건으로써 통용되는것중 하나, 바로 ‘안정성’과 ‘수익성’에 가로막혔다. 프로젝트 개발은 가능하나 혼자서 운용한다면 안정성이 확보되지 않으며, 수익성도 확대화시키거나 해당 시장을 확대시킴으로써 새로운 시장수익을 창출하는것도 아니란 이야기를 한입에 담았다.

그래서 포기하려고한다. 몇몇 통합하려고 했던 프로젝트들은 따로 개별분리하여 취미삼아 시간날때 개발할려고 한다.

rhythmga.me이라는 도메인도 안타깝지만 슬슬 버릴때가 되지않았나 싶기도 한다. (도메인 네이밍 자체는 괜찮아서 커뮤니티를 만들까 아니면 다른곳에 활용할까 고민중이다)

그렇다면, 기존에 쌓은 스택과 연구의 결과들은?

이건 새로운 프로젝트로 시작한다. 물론 창업하진 않으려고 한다. 취미가 잘맞는 몇분들과 이야기해서 새로운 프로젝트로 시작하는것을 목표로 두고있다.

잘되어봤자 다들 정기적으로 모여서 치킨에 맥주 한잔씩 할정도가 될거라 생각한다.

그리고 새로운 프로젝트에 대해 연재를 시작할것이다. 기존 프로젝트 이야기에서는 개발이야기만 줄창 늘어놓았었으니, 이번엔 주로 UI/UX에 대한 이야기를 해보려고 한다.

깊은 지식은 아니지만 어느정도 서비스 개발이나 커뮤니티 개발, 디자인을 생각한다면 읽어도 괜찮ㅇ르 수준으로 만들고싶다.

Rhythmga.me 프로젝트 / #3 클라이언트 사이드 ‘템플릿’ 프로그래밍

“울고싶어요”

프레임워크간에 이견차를 좁히지 못하는 나의 절규섞인 목소리다. 들렸다면 다행이고, 안들렸다면.. 음 좀더 청취해보는걸 권장한다.

서버사이드로는 Hapi에서 Nunjucks를 선택했지만, 데이터바인딩이나 복잡한 방식에 있어서 Nunjucks는 어울리지 않았다.

고민을 몇개월간 해봤지만, 결론이 나질 않는 이 x같은 상황에서 답은 별로 없었다.

그리하여, 대안에 대한 단점만 적어봤다.

  • React
    • 진짜 얜 몇달을 봐도 갈피를 못잡겠음.
    • 너무 산넘고 강넘고 물건너가는 느낌
    • 뭔놈의 업데이트만 하면 못써
    • 너도 데이터 바인딩이 마음에 안들어
  • Vue.js
    • 데이터 바인딩이 마음에 안들어
    • 느려
  • Backbone.js
    • 적당히 괜찮음
    • 근데 얘도 오래되었고, 오히려 기피하는사람들이 더 많아서
    • 유행 지났나봐..
  • Angular1
    • 너무 오래됨
    • 템플릿 방식 극혐
    • 최적화 극혐
    • 코드 극혐
  • Angular2
    • 너무 정보가 없음
    • 템플릿 방식 그저그럼
    • Typescript 극혐
    • 제발 더 배우라고 하지마
  • Riot.js
    • 스코프 형태는 신기한데
    • 코드가 지저분해지고
    • 템플릿이 무너지고
    • 가정이 황폐화되고

그 와중에 React로 결정하게되었는데, 그 이유는

  1. React는 React Native라는 툴이있다.
  2. 적어도 애드온 호환작업은 패치로그보고 해주면 되지않을까
  3. 적어도 개발사인 페이스북에서 실제로 쓰는거니까.

라는 이유였다.

이제서야 React로 인한 고통은 시작되었다.

Rhythmgame 프로젝트 #2 / 현황

꽤 긴 공백이 있었지만, 그래도 적을건 적어야한다. 그렇기에 적는다.

국방 스타트업챌린지 참가.

군장병 대상으로 하는 스타트업 대회가 열렸다. 지적재산권 보장도 되어있어, 놓치지 않고 참여하기로 결정했다.

1차 서류 통과 여부는 13일날 발표된다.

프로젝트에 대해 더 큰 그림을 그릴 수 있으며, 더욱 더 사업 모델을 확고히 하는 좋은 계기가 된것같다.

서브프로젝트

보이진 않지만 열심히했다.

현재 커밋량 73개, 실 프로그래밍량 3천줄 가량으로 집계하고있다. 다시 재작성하는 등 코드 증/감량 감안한 결과이다.

진행하는동안, 다음과 같은 사항에 대한 지식을 습득했다.

  • Javascript ES6(Promise, shorthand, Classes)
  • Node.js
    • Hapi.JS
    • Grunt
    • Nunjucks
  • RethinkDB
  • CSS3(기존 지식 + rem/em 개념과 생각 그리고 px단위의 함정에 대해)

아직 한참 많은게 남았지만, 그런것에 비하면 계속 꾸준히 준비, 공부해왔으리라 장담한다.

2차 구조 변경

구조를 바꾸는 일은 정말 많은 생각을 하게 만들지만, “내가 만들면 되지!” 라는 생각으로, Hapi를 기반으로 해서 다시금 만들었다.

고통스러우며 고통스러웠다.

생산성이 도저히 안나는 Node의 기초적인 상태와, 초기부터 만든다는 ‘from Basement’에 대한 압박감은 정말 진심 모든 의욕을 꺾어버린다.

백엔드: Node.JS(Hapi.JS + Core) (Core는 자체제작)
프론트엔드: Bootstrap4 + Core(자체제작)
DB: RethinkDB

이리하다가 무중단 개발 + 실시간 디플로잉이 되는 구조를 만들었지만, 구조 자체가 지금 ‘매우’변태스럽다. 누구한테 ‘잡숴봐’하면서 권유하기에는 싫은정도.
(마치 고오오급레스토랑스를 보는 일반인들의 느낌이라 생각하면 된다.)

그리고 첫번째 포스트에 적어놨던 ‘GC때문에 조금 생각해봐야 된다’가 결국 터졌다. 메모리 누수로 인한 평소 80MB대 구동에서 200MB로 급작스레 증가를 눈앞에서 보고있다..

멘탈이 절로 몸안에서 빠져나갈것같다.

앞으로 메모리세이프 방식의 코딩방식도 배워야할것이라. 줄지않는 체크리스트에 또 한줄이 늘었다.

그리고 Material Design을 사용하지 않게되었는데, 그 이유는

  1. HTML이 지저분해진다
  2. 매터리얼 관련 항목 말고는 매우 무겁다
  3. 자바스크립트 의존하는게 많아진다. 메모리누수와 직결되는 문제

앞으로 이 포스팅을 또 쓸날이 올지 모르겠는데..

적어도 전역하기 전까지는 아마 없지 않을까..? 싶다.

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의 같은 경우 모니터링에 있어서 좋은 이야기도 많고 나도 만족스럽게 사용하였으니까 계속 쓰려고한다.