이번 2편은 1편에 이어, 예고했듯이 백엔드 단에서 문제 해결을 중점으로 기술하겠다.
✔️ 1. 오류 확인.
이전 편에서
npm run distribute 시에 아래와 같은 오류가 발생한다고 했다.
이번에는 생각보다는 그렇게 어렵지 않게 해결할 수 있었다.
👿2. 스크립트가 문제?
이전 시리즈에서 언급했듯이 필자와 팀원들 모두 똑같은 문제가 발생한 결과.
스크립트에서 아래와 같이 delete로 적었던 부분이 문제라는 생각이 들었다.
사실 우리는 배포 가이드 상에서 큰 문제가 있겠냐는 의구심을 안 했지만, 서버 자체를 불러오지 못 하는 것에는 이 문제가 가장크다고 생각했다.
이유는 구글링 해 보니, 저 옵션은 사실 이미 서버가 한 번 돌아간 운영 중인 서버에서 리로드 했을 때는 문제가 없다. 그런데, 저걸 우리처럼 서버를 한 번도 활성화 시키지 않은 상태에서는 바로 삭제를 해 버리기 때문에 계속 해당 서버 뒤에 켜져도 무용지물이 되는 것이었다.
따라서 우리는 저 스크립트 명령어를 지우고 한 번 npm run distribute를 적어봤다.
아! 참! 참고로 이 부분은 당연한 얘기지만, vsc 로컬에서 작업하면 안 된다... ㅎㅎ ssh로 시작하는 ec2 서버에서 클론 받은 작업 폴더로 들어가 터미널에서 작업하고 수정해야만 반영된다.
무튼 그랬더니, 배포까지는 잘 완료가 되었다.
😂 3. 하지만 아직 한 가지 문제가 더 남았으니...
서버 배포까지는 잘 되었지만, 정작 사이트에 접속해 보니, 아직 빈화면만 보였다. 즉, 데이터가 아직 입력이 안 된 것이었다.
우리 모두는 데이터가 당연히 따로 넣지 않아도, 들어가서 굳이 넣을 필요가 없을 것이라는 착각을 해 버렸다.
오잉? 데이터는 당연히 다시 넣어야죠 ㅎㅎ 구글링해서 찾아보시면 하실 수 있을 겁니다.
멘토 재준님은 그렇게 한 마디 남기셔다. 그렇다. 데이터까지 제대로 연동 시켜줘야만 했던 것이다.
💾 4. 데이터 연동 작업의 시작.
우리는 각자 데이터 연동을 하기 위해 구글링을 시작했다. 필자 역시 계속 구글링을 했지만, 이게 참...
생각보다 자료는 많은데, 생각보다 정작 쉽게 설명된 것들은 많지 않았다.
그러다 문득, 어떤 조합을 발견했다.
바로 아래 블로그들을 참조했다.
https://scshim.tistory.com/218
https://hello-gg.tistory.com/56
즉, 하나는 mysql을 사용하기 쉽게 만든 워크 벤치라는 소프트웨어와 아마존 rds 서버를 연동시키는 내용이었다. 또 밑에 블로그는 워크 벤치를 통해 sql덤프 파일 형식의 데이터를 삽입하는 방법을 적은 내용이었다. 이 둘을 조합시켜면 가능하지 않을까?라는 의문부호와 함께 시작했다.
🖇 1) MySQL 워크벤치(Workbench)와 연결
시작화면에서 MySQL Connections 버튼을 클릭.
Setup New Connection 화면에서 RDS 연결을 위한 IP 확인 및 보안 설정 변경을 위해 AWS RDS 페이지로 이동.
기존에 생성한 데이터베이스를 클릭.
이동한 페이지에서 연결 & 보안 - 엔드포인트의 주소를 기억해둔다. IP 주소를 입력할 때 사용된다.
다시 MySQL 워크벤치로 돌아와서 Setup New Connection 화면에 연결을 위한 값들을 입력한다.
Connection Name: 해당 연결을 식별하기 위한 이름
Connection Method: Standard (TCP/IP)를 선택
Hostname: 위의 RDS 페이지에서 알아본 엔드포인트를 입력
Port: 3306를 입력
UserName: 데이터베이스 생성시 설정한 마스터 사용자 이름 입력
Store in Keychain: 해당 버튼을 클릭하고, 데이터베이스 생성시 설정한 비밀번호 입력
위 설정이 끝나면, Test Connection을 클릭.
연결이 성공하면 다음과 같은 팝업을 볼 수 있다. 이제 OK 버튼을 눌러 데이터베이스 화면으로 이동하면 끝.
🗂 2) 워크 벤치에서 이제 데이터 임포트!
이제 여기까지 왔으면 8부 능선은 넘은 셈이다. 이제 다음은 데이터 임포트 시키는 과정이다.
1. 맨 위의 탭 Server -> data import
2. start import!
이후에, sql 파일 불러올 파일 경로 탐색해서 파일을 찾고, 아래에 디폴트 타겟 스키마에서 현재 서버에 어떤 스키마에 데이터를 넣을 것인지 선택해 주고 스타트 임포트를 누르면 끝난다.
그렇게 필자도 임포트 석세스로 끝났다.
🤦🏻♂️ 3) 하지만, 또....
그런데, 필자는 또 문제에 직면하고 만다.. ㅜㅜ
바로 데이터는 잘 들어가서 화면이 보이는데, 너무 초기 데이터를 넣어버렸던 것...
그게 무슨 말이냐면, 전체 데이터 원본을 넣지 않고 초기에 상품 10개짜리만 넣어버렸다. 그래서 화면에 데이터가 10개 뿐이었다.
필자는 진짜 이런 타입인 것 같다. ㅎㅎ 뭐~ 물론 이걸통해 워크 벤치하는 방법과 큰 깨달음을 얻기는 했지만...
팀원들과 이 문제를 공유했지만, 그들 역시 워크 벤치 초보자이자, 이런 경우는 처음보는 지라... 멘토 재준님께 또 질문드렸다.
😊 4) npx prisma db push의 의미
상황 설명을 드리자, 그러면 일단 테이블부터 차라리 지우는 것이 낫겠다고 하셨다. 왜냐면 어차피 테이블에 데이터가 중복이기에... 문제가 발생하는 것이었기에... 물론 필자 역시 그렇게 생각이 들어 테이블을 삭제하려고 했지만...
이미 중복된 프라이머리 키들이 물려 있어서 삭제가 안 된다는 오류 창을 발견했다.
그러자 그는 아래와 같이 방법을 해 보라고 했다.
저기서 오른쪽 버튼을 클릭하고 그냥 드롭 스키마를 하라고 했다...
필자는 망설여졌지만, 그의 큰 그림을 믿고 일단 눈물을 머금고 또 db를 날렸다...
그리고는 다시 그는 내게 이런 질문을 던졌다.
민수님! 그러면 지금과 같이 db 스키마를 아예 날리면 어떻게 해야 하나요?
나는 당황스러웠다. 당연히 일일이 다 적어야 하는 가 아닌가라고 생각도 했지만, 그는 내게 여태 해왔던 명령어들을 잘 생각해 보라고 했다.
그렇게 1분 정도 흘렀을까...
"설마? npx prisma db push? 요?"
"한 번 해 보시죠!" 그의 말에 긴가민가하면서 명령어를 다시 쳤다.
그랬더니 워크 밴치를 새로고침하니 사라졌던 스키마 구조가 다시 생겼다.
와~ 진심으로 해당 명령어에 대해 내가 잘 몰랐다는 생각을 했다.
또 무지성으로 그냥 쳤구나.. 라는 반성과 함께 재준님의 설명을 들었다.
우리가 사실 db push를 그냥 아마존 서버와 연결해 주는 작업이라고만 생각하는데, 그것도 맞지만 사실은 db의 스키마를 생성해 주는 역할을 하는 것이 본질이다.
마지막으로 필자의 성공적인 배포와 더불어 화면을 공유드린다.
이렇게 사실 마무리 지으려고했으나, 멘토 재준님이 배포 가이드상에서 추가하신 내용이 있어 그 부분을 다음편에서 정리하고 최종 배포 소감으로 마무리 하겠다.
