Final Project Log

Final Project Log - 3

자율학습 코딩봇 2021. 12. 12. 18:44

3주차가 종료되고 다시 한번 회고를 남기고자 다시 블로그로 돌아왔다.

원래 처음 계획은 파이널 프로젝트를 하면서 하루 혹은 2일에 한 번은 블로그에 글을 남겨야겠다고 생각을 했었는데 역시 생각대로 되지 않는 것 같다. 갑작스럽게 일이 많이 생겨서 글을 쓰는 짬을 내기 어렵거나 하는 경우도 생기고 시간은 생겼는데 의외로 회고할 점들이 많지 않아서 차라리 이럴거면 주간으로 몰아서 작성하는 것이 나을지도? 하는 생각이 들었다.

확실히 주간으로 하면 쓸 내용은 많아진다. 하지만 당시의 기억들이 새록새록한 시점은 아니다보니 생각보다 쓰는 내용의 디테일 잘 남아있진 않는 듯 하다. 이러한 부분과 관련해서는 회고거리를 평소에 따로 조금씩 작성을 하고 주간에 취합해서 블로그에 올리는 것으로 방향을 고쳐봐야겠다.

1. 현재 상황

현재 백엔드 단위에서는 최초에 목표했던 최소 단위의 과제는 모두 달성을 한 상태이다. 초반에 이메일 발송 모듈이나 NestJS에 대한 적응이 되지 않은 상태다보니 예상보다 진행속도가 나오질 않았다. 그래서 주말에도 정신을 놓고 계속해서 작업을 해서 예상한 것보다도 빠르게 완료된 듯 하다.

특히 진행이 느려졌던 요인으로 내 생각에는 이메일 모듈 활용하면서 발생된 에러나 mongoose 쿼리문을 학습하면서 생겼던 것으로 기억되었다. 이메일 관련 부분은 단발성으로 문제되는 부분(smtp 관련)을 이해하고 나니 이후에는 쭉쭉 진행되었고, mongoose는 CRUD에 관한 부분을 한번 작성하고 이후 유사한 경우에는 기존 내용을 활용하여 진행속도가 훨씬 빨라졌다.

앞으로 남은 내용들은 배포에서 도커 적용이나 추가적인 유지 보수 혹은 그 외 관련된 기능들을 추가적으로 반영해보는 과제들만 남아있다. 개인적으로는 도커 배포를 좀 해보고 싶긴 한데 현재 Github과 연동하여 EC2에 대한 자동 배포가 진행되고 있다. 그래서 어느 부분부터 건드려 진행하여야 기존 내용과의 충돌을 피하면서 적용할 수 있을지 찾아보고 있는 중이다.

2. 금주 학습 내용

| NestJS 파일 구조에 대한 고찰

NestJS는 Express와 다르게 자체적으로 코드 작성에 엄격한 룰이 존재한다. 따라서 Express 서버를 활용하는 것보다 기본적으로 개념적인 부분에 대한 학습이 필요했다. module, controller, service 파일이 기본적으로 존재하는데 module의 경우에야 명확한 차이가 코드만 봐도 눈에 보이는데 controller와 service는 팀원들간에 명확하게 관련된 내용을 조정하지 않으면 순식간에 그 경계가 애매해지는 경우가 생겼다.

controller는 라우팅을 담당하고 service는 애플리케이션의 비즈니스 로직을 구성한다. 하지만 여차해서 무지성으로 코드를 작성하는 경우에는 controller 파일에 라우팅과 비즈니스 로직이 모두 들어가는 경우가 생기기 시작했다. 그리고 우리 프로젝트에서는 별도로 repository.ts 파일까지 module들 마다 추가로 생성하게 되면서 service와 repository의 경계도 애매해졌었다. 그래서 이러한 구조에 대해서 한번 백엔드 팀원과 상의하여 규칙을 정하고 그 외의 부분들도 명칭을 적용하는 것에 대해 상의를 했다.

그렇게 해서 정리된 내용은 간단하게 다음과 같았다.

- controller: 라우팅, service에서의 비즈니스 로직 함수만 호출

(단 하나의 함수만 호출 - 모든 로직을 service에 맡김)

- service: 지정된 라우트에서 필요한 로직을 모두 구현, repository의 함수만 호출함

- repository: DB에 대한 기본 CRUD 함수.
종복 사용 가능성이 있고, 로직이 반영되지 않은 함수

NestJS에선 구조에 대해서 사전 설정된 내용을 활용하도록 구성되어있지만 실제로는 활용함에 있어 팀원과 어느 정도의 상의가 필요함을 이해했다. 그렇게 위의 기준대로 코드를 작성하고 난 뒤 크게는 repository의 함수를 재사용하여 활용하는 경우가 늘어나게 되었다. 그리고 controller와 service 등의 전반적인 통일성이 증가하여 이후 코드들을 수정할 때, 좀 더 용이한 것을 느꼈다.

| Error Message

First Project에서도 error 처리를 진행했었지만, Final Project에서는 좀 더 이 부분을 가다듬고 싶어서 백엔드 팀원과 함께 전체적으로 한 번 에러메시지를 다듬는 과정을 진행했다. 에러메시지를 잘 다듬어 놓는 경우라면 결과적으로는 기대한 것 만큼 성공적인 성과가 나오진 않았다.

try... catch... 구문을 사용해서 에러를 잡아내는데 에러 메시지 내용이 중간에 몇번 중첩이 되면서 나오는 결과물들이 의도한 것과 다르게 표기되었었다. 그리고 여러가지 에러가 발생될 수 있을만한 경우들을 확인해야 했는데 시간 부족으로 파악이 어려웠다. 상황 가정에 대한 부분들을 모두 정리해야되는데 경험 부족인지 딱 생각을 할 때, 명확하게 떠오르지 않았다. 결국 제한적으로 에러 상태코드만 정리하고 에러에 대한 자세한 내용은 적용을 하지 못했다.

에러 메시지와 관련된 부분은 추후에 시간이 확보된다면 에러객체 등과 관련해서도 학습하고 try... catch... 구문 활용에 대한 내용을 여러번 실습하여야 어느 정도 이해가 가능할 것으로 보인다.

3. 에러 핸들링

| Mongoose 업데이트 함수 관련

한 번은 특정 도큐먼트 내 배열을 업데이트하는 함수를 작성하여야 했다. 이 때 배열의 element는 서브 도큐먼트인데 서브도큐먼트의 id 값을 찾고 그 서브도큐먼트의 내부 요소에 대한 변경이 필요했다. $elemMatch를 사용해서 특정 서브도큐먼트의 배열 내 순서를 확인하고 여기서 확인되는 배열 index 값의 요소를 업데이트하는 방식으로 CRUD 작성을 시작했는데, 분명 멀쩡하게 작성했는데 DB가 업데이트 되지 않는 상황이 생겼다.

처음에는 mongoose의 findByIdAndUpdate 메소드를 활용해서 작성했었다. 그런데 계속해서 DB에 업데이트 되지 않는 문제가 발생되었고, 원인을 찾는 과정에서 Query에 작성했던 조건문과 그 뒤의 업데이트 내용이 잘못 적혔던 것으로 추정했다. 그러던 중 인터넷으로 찾아본 예시에서는 findOneAndUpdate를 사용한 것을 보고 메소드만 변경을 했더니 정상적으로 원하던 내용이 반영된 것을 확인했다.

사실 메소드 자체의 기능에 있어서 동일한 기능을 하여야 하는 함수이지만, 이러한 이해하기 어려운 차이점을 발견하고 향후에는 필요한 경우가 아니라면 CRUD에서 findById보다는 findOne을 써야되겠다고 생각하게 되었다.