<배포의 늪.... feat. 처음이라 어색해서 1편>

강민수·2022년 1월 16일
0

진실의 방

목록 보기
24/26

드디어.

3주 간 우리 팀의 노력이 담긴 최종 결과물을 세상에 공개하는 시간이다. 처음 배포를 하다보니, 여러 시행 착오를 참 많이 겪기도 했다. 이번에는 그때 배포의 늪에 빠져 허우적 거렸던 이야기를 한 번 해보겠다.

01) aws 셋팅의 실패.

사실 aws 셋팅하는 것에는 큰 어려움은 없었다. 멘토분들이 가이드 해놓은 가이드 절차에 따라 무리 없이 설정이 가능했다. 다만, 문제는 처음하다 보니 잘못된 설정이 문제가 된 경우가 대부분이었다.

먼저, 프론트 엔드는 셋팅이후, 백엔드 셋팅 중간에 아마존 서버에 db를 연결시키는 작업에서 문제가 생겼었다.

npx prisma db push라는 명령어를 쳤는데, 계속 에러가 뜨는 것이 아닌가...

뭔가 잘못됨을 직감한 뒤,

01. .env 파일 오타 점검

첫 번째로, 보안상의 이유로 .env파일을 공개할 수 는 없지만, 혹시나 오타가나거나 잘못된 것이 없는 지 점검했다.

하지만, 문제를 찾을 수 없었다.

그렇다면, 문제는 aws 초기 셋팅에 있을 것이라는 생각이 들었다. 그래서 aws rds라는 일종의 db 저장소의 셋팅으로 갔다.

그러다 팀원 중 한 사람이 내게 이렇게 물었다.

민수님! 혹시 db 보안 그룹 문제 있는 거 아닌가요?

그래서 필자는 바로 db 보안 그룹을 확인해 봤다.

현재는 위처럼 필자가 프로젝트로 설정해 놓은 보안그룹이 설정되어 있었다. 하지만, 이게 사실은 default 값으로 설정되어 있었던 것이다..ㅜㅜ

그러다보니 당연히 기본 aws 설정이었기에... db 접근이 불가능한 것이 당연했다.

02. 다시 초기 셋팅...

필자는 이 보안그룹을 설정에서 바꿀 수 있는 방법을 계속 찾아봤지만, 찾기 어렵기도 했고, 바꾸기 힘들다는 결론을 내렸다.

그래서 멘토 재준님께 해당 상황을 질문드리니, 이 경우에는 rds db 설정할 때 설정하는 것이라, 웬만하면 그냥 db를 다시 만들고 지금 만든 db는 삭제하라고 하셨다.

그래서 눈물을 머금고 삭제를 해 버렸다.

그리고 다시 가이드를 살펴보자,

아! 내가 이 보안 셋팅을 기본 default를 삭제하지 않고 그냥 넘겨버렸구나.... ㅜㅜ

라는 것을 깨달았다. 그리고 다시 셋팅 후

npx prisma db push를 치자. 정상적으로,

db가 잘 연결 된 것으로 나왔다.

후~ 한 시름 이제야 덜었다.... 물론 이제 시작이긴 했지만. ㅋㅋㅋ

03. 갑작스러운 db 실종 사건?

01. 첫 시작은 프론트 연결 후.

말 그대로 프론트는 ec2를 통해 클론을 받고,

cd <front-repo>
npm run distribute 

를 통해 데이터를 받아오는 것을 제외한 기본적인 html은 잘 받아와 지는 것을 확인했다.

그리고나서 바로 다음 백엔드로 넘어가 모든 설정을 마치고,

cd <back-repo>
npm run distribute

를 하자마자,

다음과 같은 오류가 떴다.

결국 db를 못 찾아온다는 소리인데.... 또 뭐가 문제일지 고민해 봤지만, 팀원들 모두 같은 상황이었다. 그래서 필자는 팀원들을 대표해서 멘토 재준님게 다시 줌으로 도움 요청을 드렸다.

02. 디버깅 후 문제 체크.

그러자, 그는 이 경우에는 디버깅을 해 봐야 한다면서, 일단 통신 상태부터 보자고 하셨다.

그래서 필자는 브라우저 창에서 개발자 도구의 네트워크 탭을 열었다.

서버는 잘 연결된 것을 볼 수 있었다.

그렇다면, 결국 문제는 서버 통신이 아닌, 다른 것에 문제가 있었다.

일단 하나씩 해결해 보기로 했다.

03. 프론트 .env 체크.

가장 먼저, 프론트에서 목데이터 조차 불러오지 못하는 문제에 대해 해결해야 했다. 이건 분명, db 서버의 문제라기보다는 프론트에서 코드의 문제라는 생각이 들었다.

01) 스크립트 문제?

그래서 일단, 팀원들이 스크립트 안에 delete가 문제라고 해서, 일단 그것부터 지웠다.

당시 우리는 딜리트가 초기 랜더이기에 필요가 없다고 생각했고, 그래서 이건 지워도 되겠다는 생각에 이렇게 했다. 후술하겠지만, 그래서 이후에 가이드 사항도 수정되긴했다. 물론 이게 문제는 아니었다. 프론트는...

02) .env 파일 수정.

그다음은 바로 env 파일을 켜봤다. 그랬더니 문제가 바로 발견되었다. 바로... 서버 호스트를 안 넣어 버린 것이었다... ㅋㅋㅋㅋ

그래서 코드 수정 후,

npm run build 
npm run distribute

를 하자,

이제 프론트 메인 화면까지는 잘 나오게 바뀌었다.

잠깐 여기서 그냥 디스트리뷰트만 하면 안 된다...

why? npm run build를 통해 수정사항을 반영해야만 해당 코드가 제대로 반영된다. 그 이후에 다시 디스트리뷰트를 하면 그때서야 반영된 코드가 반영된 채로 디스트리뷰트가 되는 것이다.

참! 그리고 추후에 알게된 사실인데, 원래는
front 코드가 바뀌었을 경우 (main에 새로운 코드가 merge)

cd <front-repo>
git pull origin main
npm run build

를 해줘야 한다. 다만, 필자는 이러한 이유때문에 빌드만 실행했다.
이유는 다음과 같다.
frontend 배포 명령어인 pm2 serve의 경우에는 클라이언트가 요청할 때,

<front-repo>/build

폴더에서 파일을 응답 해주기 때문에 npm run build만 수행하셔도 괜찮습니다!

뒤 늦게서야 첫 시도라 많이 미숙한 것 같다는 생각이 들었다.

다만, 여기까지만 하면 아직 반쪽짜리 사이트다... 사실 데이터가 제대로 나오지 않으면 다음 리스트와 디테일 페이지는 아무 의미가 없기에... 백엔드 해결은 무조건 해야만 했다.

백엔드 배포 과정이 우리 기수의 가장 힘든 부분이지 않나 싶다. 그러면서 배운 것도 많아서 1편으로 마무리 하려고 했으나, 다음 편에서 자세히 정리하면 좋을 것 같아 다음 편으로 넘기겠다.

그러면 다음 백엔드 편에서 배포 시에 필자가 만난 오류와 더불어

profile
개발도 예능처럼 재미지게~

0개의 댓글