MEAN 프로젝트 경험 공유

MEAN이란 Mongodb, Expressjs, Angularjs, Nodejs의 줄임말입니다.  작년 5월부터 MEAN stack으로 작업을 했고 이 프로젝트가 이제 production에서 사용되고 있어서 경험담을 공유해 볼까 합니다. 비단 MEAN 뿐만 아니라 프로젝트의 몇 가지 원칙에 대해서도 경험을 공유합니다.

1. angularjs는 배우긴 어렵지만 생산성은 정말 뛰어났습니다.

jquery로 개발 주로 하셨던 분들은 선언적 프로그래밍의 패러다임인 angularjs가 굉장히 어렵게 느껴질 겁니다. 저의 경우 학습 곡선이 아주 완만했습니다. angularjs의 홈페이지 도큐먼테이션은 정말 형편없습니다. 알았던 개념도 여기 문서를 보고 나면 다시 헷갈려지니까요.

그래도 개념 파악을 어느 정도 마치고 나면 생산성은 정말 좋습니다. model-view가 확실히 구분되어지기 때문에 특히 view단이 자주 바뀌는 상황에서는 정말 에러없이 view code 수정 가능했습니다. 특히 수행했던 프로젝트가 상세 기획서를 직접 만들어 가면서 개발했기 때문에 수정이 많았는데 이때 angularjs가 없었다면 생산성이 나오지 않았을 것입니다.

2. angularjs의 단점은 digest 속도와 횟수, 그리고 IE 8.0 지원안함입니다.

angularjs의 가장 큰 특징이 two-way binding입니다. 처음에는 편하구나 하고서 쓰게 되지만 익숙해 지고 나면 속도가 신경쓰이게 됩니다. 특히 model이 변경되었을 때 digest 호출은 angularjs가 관리하기 때문에 몇 번이 호출되는지 알 수가 없고 보통 여러번 호출되기 때문에 rendering 속도는 당연히 느려집니다. one-time binding을 적극 채택한다고 해도 모자란 점은 좀 있고요.

그리고 한국의 windows xp 사용자가 20% 넘는 점을 감안하면 angularjs 1.3에서 IE 8.0을 지원안하는 것은 큰 벽입니다. B2C 서비스를 만들려고 하는 개발자에게는 angularjs 1.3이 큰 도전이라고 할 수 있겠죠.  그래서 angularjs를 admin 툴이나 mobile 전용 페이지에서만 채택한 경우가 많은 것이고요.

3. nodejs의 비동기 프로그래밍은 생각보다 어렵습니다.

callback hell을 피하기 위해서 async라는 비동기 제어 라이브러리를 사용했습니다. 그러나 비동기 프로그래밍의 특성상 꼭 callback을 호출해 주어야 하고 실수라도 해서 callback을 호출하지 않는다면 실행이 안되는 문제가 발생합니다. 특히 conditional이 많은 경우에 조심해야 하고요.

mongoosejs만 사용하는 초기에는 코드가 간단해서 문제가 없었으나 migration script처럼 computation-bound 로직이 생기면 이제 여러개의 비동기 함수들을 엮어서 프로그래밍을 해야 되기 때문에 바로 문제가 되더군요. 

CRUD 정도의 간단한 서버 API에서는 nodejs 추천드리고요, computation이 많은 서버 로직 개발에는 비추합니다.

4. mongodb의 가장 큰 문제는 트랜잭션이 없는 것입니다.

OLTP에서 트랜잭션을 쓰지 않고 개발을 한 경우는 이번이 처음이었습니다. 사실 저는 지금까지 모두 Relational DB를 써서 개발을 했었는데요. 

트랜잭션이 없기 때문에 normalization을 안 하고 하나의 collection에 모는 방법을 썼습니다. 그랬더니 개발이 진행될 수록 하나의 중심 collection이 비대해지는 문제가 있더군요. 그렇다고 해서 완전히 transaction을 피한 것도 아니었습니다. 결국 하나의 요청에서 여러 개의 collection을 변경하는 경우가 생겼고 이경우 에러 처리를 직접 개발해야 되었습니다. 

OLTP 성의 서비스 개발에는 rdb가 아직 답이 아닌가 싶습니다.

참고로 mongoosejs의 middleware 개념은 정말 좋았습니다.  validation, delete cascading의 경우에 mongoosejs의 middleware를 사용하면 좋습니다.

5. mean.io의 디렉토리 구조는 영 아니었습니다.

mean.io로 프로젝트 디렉토리 구조를 썼는데 권하고 싶지 않습니다. 그 이유는 하나의 package가 server, public 을 갖기 때문입니다. server, public이 global하게 분리되는 것이 좋습니다. 왜냐면 하나의 기능은 server 만 가질 때도 있고 public만 가질 때도 있고 server, public이 기능이 다르기 때문입니다.

6. API 기반 개발을 할 걸 그랬습니다.

mean.io 기반으로 개발을 하다 보니 SPA임에도 API가 선명하게 드러나지 않게 되었습니다. 처음부터 API를 명확하게 하고 개발을 진행했어야 했습니다. 그렇게 되면 server도 expressjs/nodejs에 종속될 필요가 없고 client code도 angularjs뿐만 아니라 다양하게 지원이 가능합니다. 

7. full stack 개발자를 구하는 것은 참 어려웠습니다.

이 프로젝트의 가장 큰 특징중에 하나는 한 사람이 기능 하나를 온전히 맡아서 front-end, back-end, data model을 온전히 개발해 내는 것이었습니다. 이것을 full stack 개발이라고 하는데요. 이렇게 진행한 이유는 처음에 있던 개발자들이 경험이 많은 시니어들이었기 때문입니다. 그러나 추후에 개발자들이 충원이 되면서 이 원칙은 준수가 굉장히 힘들었습니다.

우선 주니어 개발자들의 경우 경험이 없기 때문에 모든 부분 부분이 도전이었습니다. front-end 만 해도 어려운데 back-end, data model까지 보기가 벅차 했습니다. 

그리고 특정 부분의 개발 경험만 있던 시니어 개발자의 조인 또한 문제였습니다. full stack 개발 자체에 동의하지 않았기 때문에 마찰이 생길 수 밖에 없었습니다.

그러나 만약 소속원들의 경험이 풍부하고 모두 full stack 개발에 동의한다면 full stack 개발은 엄청난 만족도와 개발 속도를 안겨 줄 수 있을 것입니다. 

일반적인 회사에서는 모든 구성원들이 full stack 개발에 모두 동의하지 않기 때문에 이 경우에는 권장하고 싶지 않습니다. full stack 개발에 동의하는 개발자들을 구하기가 쉽지 않기 때문입니다.

to be continued.