똑같은 실수를 하지 않기 위한 기록

개발 이야기는 인스타 easy_develop에도 올라옵니다!

 

지금까지의 백엔드 프로젝트

 프로젝트 개수로 따지자면 fastapi, express, mongodb, postgres, MYSQL 등 많이 다루어 본 것 같지만 제대로 된 프로젝트는 없었다. 코드는 구조가 없이 엉망진창, db는 local과 production이 구분되지 않아서 엉망진창 등등…. 그래서 이번에는 nest로 파일구조를 강제하고 local, production도 구분 지어서 제대로 된 프로젝트를 시작하였다.

 

프로젝트의 시작

 프로젝트의 첫 시작은 로컬 개발환경 세팅이다. 계획은 완벽했다. 로컬은 sqlite, production은 heroku의 postgres로 하고 환경변수를 설정해서 이를 구분 짓는다. 그러나 로컬환경인 sqlite부터 문제가 발생했다. nestjs의 typeorm에서는 entity를 저장하면 자동으로 table을 만들어준다. 그런데 entity를 만들어도 table이 만들어지지 않고 텅 빈 db 파일만이 생성될 뿐이었다. db 파일이 생성된 걸 보면 무언가 연결은 되었다는 건데 어디서 문제가 생긴 건지 찾기 위해서 4시간 동안 계속 구글에 검색하고, 내 프로젝트에 적용해보고의 반복이었다.

 

도커 시도해보기

 그러다 다른 사람들은 로컬 개발환경을 구성할 때 도커를 사용한다고 해서 이참에 도커를 배워보기로 했다. 도커를 그냥 깔 수는 없어서 window에 linux 명령어를 할 수 있게 해주는 window ternimal도 깔고, ubuntu도 설치한 뒤에 도커를 설치하였다. 그 후에도 nestjs postgres docker의 키워드로 계속해서 구글 검색 한 뒤에 postgres admin 툴인 pgadmin을 도커에 올리고 연결해보았다. 그러나 도커에 대한 개념도 명확하지 않고, 잘 되지도 않아서 도커는 다음 기회에 해보기로 했다.

 

문제 해결하기

 문제를 안 뒤에는 새로운 프로젝트에서 sqlite에 연결을 해보았고 너무나 쉽게 table이 생성되었다. 다음에는 이런 일을 겪지 않기 위해서 어디에서 문제가 생겼는지 찾아보니 dist 파일이 문제였던 것 같다. 버그를 재현할 수 없어서 정확하지는 않지만 추측해보자면, 처음에 nest의 controller, module이 제대로 등록되지 않은 채로 dist 파일이 만들어졌고(npm run start:dev가 아닌 npm run start을 한 것과도 관련이 있을 수 있음) 그 이후에는 만들어진 파일 때문에 코드를 정상적으로 수정해도 계속해서 오류가 나왔다.

 

 오류에 비해서 고치는데 너무 많은 시간이 걸렸다. 개발 단계를 0→1→2 순서대로 갈 때 2에서 문제가 생겨서 1→2에서만 그 원인을 찾은 것이 실책이었다. 0→1의 단계를 제대로 확인했으면 조기에 오류를 발견하고 해결했을 것이다. 하루 반 동안 고생하면서 깨달은 점이 두 가지가 있다. 첫 번째는 “모든 곳에서 오류를 의심하자”이고 두 번째는 “개발은 작은 단위부터 테스트하면서 하자”이다. 작은 단위부터 테스트했으면 시간을 아꼈을 것이고, 모든 곳에서 의심했으면 그 원인을 빠르게 찾을 수 있었을 것이기 때문이다.