클라이언트-서버 프로젝트 분리하기
cover 출처: 위키피디아
맨 처음 프로젝트에선 깃허브에서 하나의 저장소에서 client와 server 코드를 모두 저장했다. 그러나 당시 익숙지 않아 package.json 및. gitignore에서, 또는 일하고 있는 코드들에서 충돌이 났다.
왜 그랬냐면, 예를 들어 백엔드 팀에서 테스트한다고
- client 코드를 테스트 겸 고친다든지,
프런트 팀에서 테스트한다고
- server 코드를 잠시 고치고 원상 복귀하지 않은 채
저장소에 pull request를 날리는 경우가 생기곤 했다. 아무리 조심하자고 프런트-백엔드 팀끼리 강조했지만 야근과 스트레스가 많아지면서 이런 건 사람에게 기대면 안 되는 것으로 결론을 지었다.
그래서 이후부턴 packagae.json을 아예 client와 server각각 하나씩 따로 가져가기로 했다. 그땐 그나마 이게 나아 보였다.
당시엔 팀으로 일하고 있으니깐 이런 충돌이 났던 것이고, 이제는 혼자 client & server 코드를 만지니까 그냥 단일 package.json구성과 당연히 하나의 깃 저장소로 프로젝트를 진행 중에 있었다.
2주 전부터, semantic-ui 스타일링을 만지작 거리고 있었다. server & client 기능을 개발하면서 스타일링을 간단하게나마 입히기 시작했는데, 이게 admin dashboard를 아무리 내가 잘 만들어도 이미 만들어져 있는 것을 따라가지 못할 거란 생각이 들었다. form이나 navbar 까진 그래도 해보란 했는데 스타일 젬병인 나는 Grid 쪽에서 아예 포기를 해 버렸다.
템플릿의 한 종류그래 익숙해지기 전까진 나와있는 템플릿을 쓰면 되겠다 생각이 들었다. 아니 왜 지금까지 그런 생각을 안 했지??? client & server 코드 혼자 만드는 것도 시간이 많이 걸리는데 CSS까지 혼자 할 거란 막연한 생각을 했던 것 같다. 진짜 안타깝다. 아니, 이제라도 알았으면 된 거다.
현재 React.js 에선 bundling용도로 webpack을 쓰고 있는데 HMR 등 개발 속도에 도움을 주는 각종 플러그인 옵션을 쓰고 있으므로 webpack 자체에서 dev-server까지 쓰는 상황이었다. 여기에 하나의 webpack에서 node server 쪽 bundling까지 같이 하고 싶었다. 별도의 webpack 및 build 환경을 가져가는 건 비효율적으로 보였기 때문이다.
정말 그럴까?
라는 의문을 시작으로 검색을 좀 해봤다. 왜냐하면 한 달 전, React 블로그 강좌로 유명한 velopert님께서 나중에 프로젝트할 땐 server/client를 아예 분리해서 하는 게 나아 보인다는 말이 생각났기 때문이다.
그래서 검색을 더 해 보니, 실제로 여러 회사에서 아예 깃 저장소 자체를 분리해서 관리하는 것이 관리 및 유지보수 측면에서도 장점이 있다고 했다. 하긴 build run 할 때만 약간 귀찮을 따름이지 굳이 합칠 필요도 없어 보였다.
그림과 같지만 DB는 개발중이라 로컬에 저장 예정 (출처: baatz.io)일단 해보고, 장단점을 다시 블로그에 올려보도록 하자.
