나의 성장일지 4편

 

나의 성장일지 3편

 

내가 만든 서비스는 그 후로 약 1년간 운영되었다. 

 

코로나에 걸린 사람이 기침을 하듯 에러를 뱉는 일은 일상다반사였지만 그때마다 서비스를 재시작하며 약 1년간 운영했다.

 

에러를 트러블 슈팅한다는 것은 상상도 할 수 없었다. 

 

겨우 1년이 지났지만 나는 내가 짠 코드를 이해할 수 없었다. 

 

 

그 기간 동안 나는 Node을 익히기 시작했다. 

 

이유는 없었다. 

 

Python은 뭔가 Web service를 하는데 적합하지 않다고 생각했다. 

 

그때 즈음 동기가 본인이 Front end를 해보고 싶다며 Vue.js를 익히기 시작했다.

 

 

팀에 개발이 가능한(말 그대로 가능만 한) 인원이 2명이 되었다. 

 

능숙하진 않았지만 Back-end 한 명, Front-end 한 명으로 구색은 갖추었다. 

 

 

Node를 익히면서 프로젝트 구조에도 관심을 가지기 시작했다.

 

내가 만든 코드는 모놀로식했다. 

 

하나의 코드 베이스에 모든 기능과 View를 넣었다. 

 

당시에는 구조에는 관심이 없었으며 기능만 동작하면 된다는 생각이 만연했고, 주기적으로 업데이트나 버그 픽스를 하지 않았기에 괜찮았다.

 

 

하지만 조금 더 배운 시선에서 바라본 나의 서비스는 너무 엉망징창이였다.

 

그래서 리팩터링을 결심하였다. 

 

 

MSA를 고려할 필요는 없었다.

 

서비스는 작은 규모였고 트래픽 또한 많지 않았다. 

 

 

우선 BE와 FE를 나누기로 했다.

 

BE에 Express를 사용하고 FE에 Vue.js를 사용하여 개발하기로 하였다. 

 

BE에서 API를 제공하면 FE에서 받아서 랜더링 하기로 했다. 

 

 

당시에는 이 구조가 아주 괜찮다고 생각했다.

 

BE와 FE를 나누자 각자의 기능에 집중할 수 있었고 막히는 부분에 대해서 토론할 수 있었다. 

 

DB도 MySQL에서 MongoDB로 바꾸었다.

 

이유는 없었다. 

 

그냥 그게 하고 싶었다.

 

 

개선된 프로젝트 구조

 

 

그렇게 순조롭게 개발을 진행하며 일정을 맞추었다. 

 

최종 시연이 1주 정도 남았을 때에 또 한 번에 시련이 찾아왔다.

 

어제까지 잘 되었던 코드가 무언가 삐걱대기 시작했다. 

 

FE 쪽에서 관리하던 코드가 변경되었다. 

 

하지만 변경된 부분이 어딘지 몰랐다. 

 

서로 시간이 맞지 않아 커뮤니케이션에 문제가 생겼다. 

 

그리고 더 큰 문제는 FE의 코드가 어떤게 최신 버전인지 알 수 없었다. 

 

그 당시 우리는 코드가 변경될때마다 압축을하여 보관했다.

 

 

 

 

 

젠장

 

 

 

우린 코드 형상 관리 시스템을 사용할 줄 몰랐다.