GDG 프로젝트 트랙 4기 BE 2차 개발코스 5,6주차 WIL

중간 데모데이 발표가 끝났다. 로컬에서 회원가입, 로그인 후 게시글 조회하는 화면까지 프론트, 백엔드 간에 연결하는 것까지 보여줄 수 있어서 만족스러웠다.

이후 피드백을 받았다. 요약해 보자면

아무 생각 없이 첫 화면을 어드민 페이지로 잡았는데 기획 의도에도 맞지 않을 뿐더러, 회사 홈페이지 같다는 피드백을 들었다.

따라서 메인 화면(게시글 볼 수 있음)을 디폴트 화면으로 두고, 작성이나 마이페이지 같은 기능 이용 시 로그인/회원가입 모달 사용하는 방향으로 바꾸기로 했다. 

그 외에 커밋 컨벤션, 브랜치 전략 등의 피드백을 받았다. 커밋 컨벤션의 경우, 병합을 제외하면 지키고 있어서 크게 어렵지 않았고, 브랜치 전략 같은 경우에는 기획 발표 이후 피드백에서는 팀원이 2명 뿐이라서 각자 이름 브랜치, develop 브랜치, main 브랜치로 두고 사용하라고 하셔서 그렇게 했을 뿐인데, 다른 피드백에서는 기능별로 브랜치를 판 후 병합 후 main에 최종으로 합치는 방식을 얘기하셔서 당황스러웠다. 백엔드 팀원 분과 상의 끝에 브랜치 전략은 그냥 원래대로 가기로 했다.
 
-한 것
 
게시글CRUD API 중 CUD 1차 제작

지역 인증이 아직 미구현되었고, 어떤 식으로 지역을 나눌 지 아직 정해지지 않아서 내가 임의로 지역 선택 로직을 작성해서 임시로 게시글 작성, 수정, 삭제 로직을 구현했다. 다만 파트 배분 회의 때 지역 도메인은 다른 팀원에게 맡기기로 하고, 내가 그 도메인에 맞춰(모듈처럼) 게시글 CUD를 다시 작성하기로 해서 아마 다시 작업하게 될 것 같다.

 

사실 내가 맡은 파트 중 가장 중요한 부분은 배포였다. 프론트 분들과 계속해서 현장에서 로컬 연결해서 기능을 맞춰볼 수는 없는 상황이라서 서둘러 배포를 성공시키기로 마음 먹었다. 인프런 JSCODE님의 강의를 따라서 배포를 시도했다. 사실 EC2 인스턴스를 생성하고, 정책 설정을 하는 부분은 예전에 ACC에서 공개 핸즈온 세션 같은 걸 열었을 때 비슷한 걸 해본 경험이 있어 생각보다 스무스하게 넘어갔다. AWS S3 버킷도 미리 생성해 두었다. 사실 버킷 생성은 별 게 없어서 5분도 안 걸렸던 것 같다 ㅎ

 

오히려 초기 환경 세팅 중 Docker desktop이 설치는 되었는데 엔진 구동에 실패해서 시간을 잡아 먹었다. 갤럭시북에서 작업 관리자에는 가상화가 켜져 있는데 정작 가상화 기능을 활용하는 Docker desktop 엔진은 구동에 계속해서 실패했다. 바이오스 창에 들어가 설정을 고치려 했으나, 갤럭시북은 바이오스에서 가상화 기능 설정하는 것을 막아두어서, 해제하려면 탈옥(?)같은 작업까지 해야한다고 했다. 그건 좀 위험해 보여서 가상화 체크 옵션을 껐다 켰다 반복하면서 재부팅을 반복하던 중 삼성 커뮤니티에서 가상화 머신 오류 -> 역으로 체크해제 하면 가상화 엔진이 작동한다는 꿀팁을 듣고 속아준다는 느낌으로 시도해서 결국 성공했다. 아직도 왜 이게 반대로 작동하는 지 모르겠다. 제미나이도 모른다. 노트북 빌드를 애초에 잘못 만든걸까,,,

이후 AWS EC2에 Docker파일을 배포했다. 프리티어 요금제 정책 변경으로 RDS 서버도 요금이 부과된다고 한다. 실사용자가 없으니까 돈이 많이 깨지지는 않겠지만 트래픽과 요금 예측이 안 가서 그냥 RDS 서버를 안 쓰는 쪽으로 하기로 했다. 다행히 강의에서 Docker Compose 기능을 알려줘서 서버와 DB 컨테이너를 배포하는 방식으로 배포했다.

 

사실 이 때, JWT 시크릿키 같은 기능은 백엔드 팀원 분이 하셔서 초기 서버 설정도 조금 애먹었다. 하지만 제미나이에게 초기 환경설정 방법을 물어보니 docker compose yml 파일로 설정하는 법을 숟가락으로 떠먹여줘서 쉽게 넘어갔다. 초기 설정을 잘 마치고 나니 서버가 중지되지 않고 잘 실행되었다.

 

그렇게 순조롭게 배포에 성공하나 싶었지만, 문제가 발생했다. 계속해서 서버가 켜졌다가 멈추는 현상이 발생한 것이다. 심지어 인스턴스 일시중지를 눌러도 한참동안 멈추지 않아 강제 중지를 반복하곤 했다. 사실 이 때 오후 2시에 팀원들과 만나기로 했는데 오전11시 쯤에도 이 문제를 해결하지 못해서 스트레스 받고 있던 도중, 삼국지의 조조가 휘하 장수에게 위급한 상황이 오면 열어보라고 한 꾀주머니 마냥 JSCODE님께서 마련해주신 서버가 멈출 때 대처사항 문서를 읽어보았다. 내용은 서버가 멈출 때 스왑 메모리를 이용하면 해결할 수 있다는 것과 스왑 메모리 사용하는 방법이었다. AWS EC2를 처음 써봐서 몰랐는데 micro t3의 메모리는 1GB에 불과하다고 한다. 근데 나는 Docker Compose로 이미 기능이 어느정도 개발된 서버에 DB까지 배포하려고 하니 메모리가 부족해서 자꾸 서버가 멈췄던 것이다. 오후 2시에 팀원들과 만났을 때 swap 메모리 사용법을 적용했고, 마침내 배포에 성공하게 되었다! 
 
이후 main 최신 사항과 병합 후 다시 재배포하고, 프론트 분들이 실제 서버와 연결해 집에서 개발을 이어나갈 수 있게 더미 데이터도 넣어주었다. 배포에 성공했으니 이제 개발다운 개발을 진행할 수 있을 것 같다.

 

남은 기간 동안 할 것은 다음과 같다. 아직도 갈 길이 멀다.

 
-백로그
게시글CRUD 완성(S3 연결 등)
배포 ide터미널 설정
도메인 연결 및 보안 설정
리팩토링(로깅, 예외처리 등)
(CICD)