배경

전 회사에서 퇴사한지 3개월 하고도 1주일이 지났다. 퇴사 후 가장 기대했던 건 내가 원하는 개발에 모든 시간을 쏟을 수 있다는 것이었다. 나는 회사를 다니면서도 기존의 PHP 개발에서 다른 언어로 바꾸고 싶은 욕망이 있었으며, 더 나은 커리어 설계를 위해 퇴사를 하게 되어 비슷한 시기에 퇴사한 직원과 함께 새로운 프로젝트를 시작했다. 사내에서 주력 언어가 node.js는 아니었지만 그 전부터 socket.io 기반 채팅 서버, 크롤러 등 모듈화된 서비스는 node.js로 작업하였고, 플랫폼 전환 시점 이후 추가되는 기능도 역시 node.js 기반 서비스 단위로 모듈화 하여 작업했다. 그래서 어느정도 기본 경험은 있는 상태라 판단하고 바로 프로젝트 작업에 착수했다.

nBase

처음 목표는 간단했다. 정확히 무엇을 만들지 정하지는 않았지만, 그동안 작업했던 베이스 코드 및 프레임워크와, 머릿속에 있는 개발하면서 겪은 이슈들을 토대로 새로운 웹 프레임워크에 마이그레이션하는 것이 목표였다. 당시 외주가 들어올 수도 있는 상황이어서 들어왔을 시 작업할 수 있도록 갖춰놓는 목표도 있었다. 정 안들어오면 그냥 토이 프로젝트라도 진행하고, 이름 자체도 node base 또는 new base. 별 뜻은 없다. 이름 짓는데에 고민하기 싫었다.

타임라인

아래부터 서술하는 기록은 개인 bear 에디터에 메모한 것들, 커밋 로그 등에서 히스토리를 추려내어 작성했다. 다소 틀린 점이 있을 수도 있다.

2월 말 - 기술 스택 정하기

우선 기술 스택부터 정해야 했다. 프론트엔드는 잠시 보류하고 백엔드부터 작업했다. 퇴사 전 사내에서 계획했던 기술 스택은 백엔드는 크게 node.js, typescript, 프레임워크는 NestJS, TypeORM, GraphQL, 프론트엔드는 기존의 angularJS에서 Angular로 전환하는 것이 목표였다. 이 스택을 가져올까 생각했다가 우리에게 맞는 스택을 하나하나 재 리서치했다. 그 결과는 NestJS 대신 express, typeORM 대신 sequelize, graphQL 미사용이었다. 첫번째로 NestJS는 기능은 많으나 이것들을 모두 이용하기엔 런닝커브와 규모가 크다 생각하여 raw한 express로 점진적으로 개발하다가, 필요 시 nestJS로 전환하는 쪽으로 방향을 정했다. 두번째로 sequelize를 사용한 이유는, npm 규모와 역사를 비교해 봤을때 sequelize가 더 커서 이슈 검색 시 개발자 풀 규모 등에서 안정적이라 생각하여 택했다. 마지막으로 GraphQL은 물론 좋은 통신 방법이긴하지만 전에 맛보기로 공부해봤을 때, resolver 구현에 공수가 많이 들어가고, 서버와 클라이언트 전부 맞춰 구현해야 하기 때문에 실제로 프로덕션에 도입한 케이스가 많지 않아 조금 더 지켜보고 도입하기로 결정하였다.

3월 1주

기술 스택은 정했고, 기존에 작업했던 프레임워크를 기준으로 기능들을 하나하나 붙이기 시작했다. api 서버를 만들 계획이므로 뷰(V)는 따로 다루지 않았다. 기본적인 CRUD 기능 작업, 더 나아가 다양한 relation 케이스도 리서치했으며, model단에서 데이터를 가져올때 조건에 따라 where절을 직접 만드는 대신 sequelize의 scope를 적극 적용하는 리팩토링 과정이 있었다. 그 후엔 미들웨어 - guard, pipe, error handling, log(winston), 필수 기능 - 유저 관리(JWT, Passport) 등을 아주 간단히 적용해보았다. 일정을 보면 알겠지만 각 라이브러리의 기능을 깊게 숙지했다고는 말할 수 없다. 하지만 기본 기능으로 작동하게끔 연결하고 추후 개선해 나가는 전략을 취했다.

3월 2주

어느 정도 틀이 잡혔으니, 원래 목표에 있었던 typescript로 전환하는 작업을 했다. 각종 빌드 이슈들을 잡으며 (package.json, tsconfig.json tsconfig-path 등) 코드에 기본적인 틀은 녹여내었다. 또한 관리할 서비스가 늘어나면서 dependancy를 어떻게 관리할지에 대한 고민 생겼고 고민끝에 InversifyJS 대신 심플한 typedi를 선택했다. 이번주 미팅에 많은 사항이 결정되었는데. 백엔드뿐만 아니라 프론트엔드, 이 둘을 배포할 인프라 프로세스 정책 등을 픽스했다. 프론트엔드 - react vs vue? -> 러닝커브 이슈로 우선 vuejs로 진입 인프라 - 어떤 클라우드를 쓸지 고민했는데, 같이 하는 팀원이 GCP를 추천해서 우선 GCP로 전행, 도메인은 일단 바로 구매하는 대신 내가 가지고 있는 kimjbstar.com을 사용하고 추후 바꾸기로 결정했다. 프론트엔드는 같이 하는 팀원이 집중적으로 리서치하고, 나는 GCP, docker, CI/CD를 위한 github action을 리서치하기로 했다.

3월 3주

실무에서 쓰진 않았지만 개인적으로 django, rails를 잠깐 공부한 적이 있다. 거기에서 매력적이었던 기능이 migration인데, migration은 일종의 databse schema 형상 관리라고 생각하는데, schema 변경 시 그 "변경 기록"을 쌓아 관리하는 방식이다. 그 중 django의 makemigration은 마지막 "변경 기록"과 현재 model(entity) class들의 변화를 감지하여 새 변경 기록을 generate해 주는 기능이다. 이 기능을 지원하는 라이브러리가 하나도 없었다! sequelize(js) 기반 generator는 있었는데 이 마저도 대응 sequelize 버전이 낮았고, 나는 sequelize에 decorator 패턴 및 typescript와 integrate된 버전을 사용하고 있었고(sequelize-typescript) 여기 위에선 작동하지 않았다. 그래서 저 라이브러리의 코드 및 기능을 따와 typescript 기반 위에서도 돌아가도록 하는 개인 라이브러리를 만들게 되었다. 추후 자세히 설명하겠다.

이것과 별개로 이번주 미팅에서는 클라우드 서비스 관련 얘기를 다시 했는데 GCP를 사용하는게 크게 메리트가 없다고 판단하여 AWS를 전환하기로 결정했다. 그에 따라 기존에 리서치하느라 구성했던 gcp 프로젝트 삭제, gcloud 배포 github action 등을 aws 기반으로 전환해야 했다. 또한 ECR, ECS를 도입하여 container 기반 배포를 본격 도입하기로 결정했고, 비록 백엔드만이지만 container orchestraion(일종의 managing)이 되는 pool 구성 및 배포 프로세스를 나름 정립했다.

3월 4주

다음 태스크로는 API 문서 페이지를 생성해주는 swagger 도입이 있어 리서치해본 결과, swagger가 동작하는 방식 자체가 코드 내에 있는 decorator를 긁어 문서를 생성해주는 방식으로 보인다. 꼭 이것때문이 아니더라도 decorator 패턴을 도입하고 싶었고, 전에 고민했던 dependancy 이슈도 보면 이 모든 것을 nestJS에서 기본적으로 해결해주고 있다. 그래서 기존 코드를 전부 들어내고 nestJS 및 decorator 패턴 도입을 완료하였다.

3월 5주 - 4월 1주

내 프로젝트에 임시로 만들어 놓았던 sequelize-typscript-migration 모듈을 개별 프로젝트로 분리하는 작업을 했다. 그에 맞춰서 별게로 실행되게끔 빌드 셋팅, 개별 실행 스크립트 추가 및 리팩토링 작업을 하였다. 그 후 npm 및 github에 public하게 배포하여 기존 nbase 프로젝트와 완전 분리에 성공했다.

sequelize-typescript-migration 라이브러리 npm 배포

4월 2주

이번주는 scaffold 구현 위주로 작업했다. 모델 추가 시 기존 모듈을 복사해서 만드는 과정에서, 모델 schema를 json으로 정의하고, 그에 따라 컨트롤러, 모델 등 CRUD 코드를 generate해주는 기능이다.

4월 3주 - 4주

기본적인 jest 리서치 후 단위 테스트 기능을 추가했다. 추가적으로 전 회사에서 하던 픽스쳐 관리 방식도 벤치마킹했는데

차이점이 있다면 ORM을 통한 relation 분석 자동화를 통해 더 고도화 시켰다. 픽스쳐를 관리하긴 하되 dumpdata를 통해 최신 스키마로부터 항상 새로 가져올 수 있는 기능을 추가했다. 성능 이슈로 mocha로 전환

단위테스트 도입 - TDD, 단위 테스트, fixture

4월 5주

테스트를 하기 위해선 데이터를 다뤄야 하는데 조금 더 재미있고 의미있는 데이터로 하고 싶어서 토이 프로젝트 주제를 고민하기 시작했다. "1초만에 노래 듣고 맞추기" 토이 프로젝트 기획 및 스키마 구성 개발에 착수하면서 실제로 migration을 해보니 sequelize-typescript-migration 의 여러 한계가 발견되었다. constraint 대응도 안되있고... 그런데 TypeORM을 다시 리서치해보니 잘 돌아가는 migration 기능이 있었다. 그래서 모든 코드를 갈아없고 TypeORM으로 전환 작업에 들어갔다.

5월 ~

just1s 프로젝트 본격 시작, 주1회 미팅이 아닌 매일 출근식으로 결정, 갈산역 에서 매일 모임, 트렐로에 작업 사항 기록 프론트엔드도 본 작업 시작