Final Project Log - 2

 

---

파이널 프로젝트를 시작한지 2주가 지났다. 퍼스트 때도 2주 동안 많은 에러와 버그들을 마주했지만 이번에는 더욱 만만치 않음을 느꼈다. 아무래도 새로 활용하는 스택 중 서버 메인 스택이 지난번과 큰 차이가 있음에 따라 더 많은 버그를 마주한 듯 했다. 이번에는 마주쳤던 문제들에 대한 회고를 다뤄보고자 한다.

 

1. AWS SES

NestJS 공식문서에도 소개가 있지만 메일 발송 모듈이 존재한다. 이번 프로젝트에서 사용자 인증에서 메일 발송이 필요하여 메일 발송과 관련된 내용을 작업했다. 그런데 메일을 발송하기 위해서는 smtp 서버 활용이 필요했고 이 때문에 간단하게 smtp와 imap에 대해서도 살펴보게 되었다. 

 

서비스에서 이메일을 보내게될 때, 가급적이면 구매해둔 서비스의 도메인 주소를 활용하고자 했다. 그래서 기존에 도메인을 구매했던 AWS의 SES (Simple Email Service)를 활용하여 이메일 도메인으로 레코드를 생성하고 smtp 활용을 추진했다. 그렇게 적용한 와중에 이메일이 정상적으로 발송되지 않는 이슈가 생겼다.

 

이 때, 해결 방법을 찾는다고 거의 하루가 꼬박 걸린 듯 하다. 처음에는 nestjs-mailer 모듈이 npm으로 설치 시, nestjs의 버전과 맞춰지지 않아서 인스톨하면서 부터 원활하게 진행되지 않았다. 그래서 모듈 문제일 가능성이 큰 것으로 보고 다른 모듈들도 찾아보고 별짓을 다 해본 듯 하다. 그런데 아무리 봐도 나와 동일한 에러가 생겼다는 경우를 찾기가 힘들었다.

 

내 경우에는 처음에 메일이 아예 정상적으로 발송되지 않는 문제였는데 이메일 주소를 만지작 거리다보니 구매한 도메인을 활용한 도메인으로만 이메일 수신, 발신이 가능했던 것이다. 그 동안에는 고객에게 메일을 보내는 상황을 가정하고 수신을 gmail 등으로 테스트 하고 있었다. 그래서 smtp 서버를 구글이나 네이버 등을 활용해서 모듈을 활용하니까 메일이 정상적으로 발송되었다.

 

그래서 이상함을 느끼고 AWS SES의 smtp에 대해 열심히 찾아본 결과 AWS SES에서 도메인으로 smtp 서비스를 시작하면 샌드박스 모드가 바로 적용되어 동일한 도메인끼리만 수신 발신이 가능했다. 샌드박스를 해제하면 자유롭게 이메일 발송이 가능하다고 하지만 이에 대해서는 aws 고객센터에 영문(혹은 일본어)으로 자세한 설명으로 사유를 설명해줘야 한다. 심지어 시간도 좀 걸릴 수 있다고 한다.

(나도 사유를 적어 보냈는데 바로 안되길래 냅다 손절하고 구글을 쓰기로 했다)

 

자세한 내용은 아래에 모두 친절하게 설명되어 있다.

https://docs.aws.amazon.com/ses/latest/DeveloperGuide/request-production-access.html

 

 

2. AWS 코드 디플로이 에러

배포를 위해서 AWS의 코드 파이프라인을 활용했고, 그 과정에서 에러가 있었다. 기존에 생성해둔 EC2가 영문도 알 수 없게 갑자기 CPU 사용량이 폭증하면서 맛이 가버렸는데 그래서 EC2를 새롭게 생성해서 작업을 했다.

 

그런데 코드 파이프라인이 자동으로 잘 진행이 되다가 소스 부분을 넘어서 디플로이 과정에서 각 이벤트 시작조차 진행이 되지 않는 것을 확인했다. 이 경우에는 에러로그가 뜨거나 하는 경우가 아니라 찾아보기도 애매했는데 전체적으로 한번 점검을 돌리면서 에러를 잡으려고 했다. 

 

확인을 해본 결과 자동 배포되도록 지정해둔 EC2에 IAM 권한 부여가 되지 않아 발생된 문제임을 확인했다. IAM은 보통 특정한 AWS 계정에 게스트 사용자 처럼 계정을 만드는 것으로 이해해뒀었는데 자동 배포를 위해서는 EC2에 권한 부여가 필요했음을 다시 한번 깨달았다.

 

해당 부분을 개선하니 코드 파이프라인이 다시 원활하게 작동했다.

 

 

 

3. NestJS, Mongoose 에러

이 부분은 솔직히 에러란 에러는 별개 다 터져서 정리도 못했다. 발생하는 대로 냅다 얼른 검색해보거나 구조를 보면서 해결했었다. 하지만 대부분은 NestJS의 구조에 대해서 개념이 제대로 인식되지 못한 부분이거나 혹은 Mongoose에러였다. mongoDB의 기본 쿼리문이나 CRUD 명령어가 모두 객체 프로그래밍의 메소드들과 매우 닮아있다. 그래서 어지간한 부분들은 모두 기존에 mongoDB 에서 쓰던 것과 동일하게 활용이 가능했다. 그런데 몇개 부분에서 활용하는 달라지는 것들이 있어서 그것들 때문에 몽구스 문서를 보면서 시간을 다소 썩힌 것도 있는 것 같았다. NestJS는 거의 삽입이나 데코레이터 활용에 따른 에러가 많이 발생되었던 듯 하다. 지금은 당장의 시간문제 때문에 당면 문제를 해결하는 것에 집중하느라 정확하게 공부하는 것이 힘들지만 이에 대해서는 나중에 시간이 될 때 좀 더 공부를 하면 좋을 것 같다.