3차 데모데이 시간이 돌아왔다 사실 이 글을 쓰기 시작한 것은 8월 7일인데 업로드 하는 시간이 좀 걸린 것 같습니다. 3차 데모데이는 나와 프론트 크루인 도밥이 함께 진행했습니다. 오랜만에 사람들 앞에서 이야기를 하려고 하니 많이 떨렸습니다.
3차 데모데이의 핵심은 프론트 크루와 협업을 한 것 그리고 개발과정에서 각 파트별로 발생한 문제점을 어떻게 해결을 했는지 공유하는 시간이었습니다.
지난 데모데이 피드백 반영
2차 데모데이에 대한 정보를 확인하고 싶으시면 https://velog.io/@seokhwan-an/2차-데모데이-회고 를 확인해 주세요
지난 데모데이에서 받았던 피드백은 킬링파트를 투표한 경우 너무 많은 정보를 제공한다는 것이었습니다. (투표한 킬링파트의 순위와 킬링파트를 친구들에게 공유 독려 메시지) 이를 아래와 같이 단일 정보만 전달하는 것으로 수정했습니다.
각 파트별 문제가 사항 및 해결방법 공유
프론트에서 발생한 문제는 도밥이 잘 설명해주었고 제가 백엔드에서 발생했던 문제와 어떻게 해결을 했는지에 대해서 설명을 했습니다. 백엔드와 관련된 문제는 크게 2가지였습니다. 그 문제는 N + 1 문제와 배포를 자동화하는 과정에서 서버(spring)가 계속 올라가지 않았던 문제가 있었고 그 해결 방안에 대해서 설명했습니다.
먼저 배포과정에서 서버(spring)가 올라가지 않는 상황과 어떻게 해결을 했는지에 대해 설명하겠습니다.
배포가 진행되는 과정을 간단하게 설명하면 배포가 진행되면 ec2에 있는 runner가 배포스크립트를 실행하여 서버가 올라가는 것입니다. 문제사항을 분석하는 중에 github action이 마무리가 되고 kill process -OOOO 이라는 문구가 나타는 것을 확인했습니다. 이를 통해서 github action이 종료가 되면 spring을 실행하는 process가 죽는 상황임을 인지했습니다. 이를 해결하는 방안으로 jar 파일을 실행하는 명령어에 Root 권한을 부여하여 github action이 종료되더라도 서버를 올리는 것은 종료되지 않도록 했습니다.
다음은 N + 1 문제입니다. 문제사항을 간단하게 설명을 하면 song과 killingPart의 관계가 1 : N이고 killingPart와 like의 관계가 1 : N인 상황에서 song을 조회하는 과정에서 불필요한 쿼리가 발생하는 문제였습니다. 이에 대한 설명은 https://velog.io/@seokhwan-an/노래-데이터를-조회하는데-발생한-N-1-해결하기 을 참고하시면 좋을 것 같습니다.
프론트와 백엔드가 협업한 내용
프론트 크루들과 함께 작업한 내용은 서비스 환경을 구축하는 것이었습니다. 프론트 크루들 중에 배포를 경험한 크루들이 많지 않아서 같이 진행하면서 요청의 흐름을 파악하는데 함께 했습니다.
위의 사진과 같이 서비스환경을 구축했습니다. 요청 흐름에 대해서 간단하게 설명하겠습니다. 요청이 들어오게 되면 api 요청은 spring으로 포트포워딩을 하여 spring으로 부터 응답을 받도록 구성했습니다. 그렇지 않는 요청에 대해서는 프론트 파일을 불러오도록 처리를 했습니다. (포트포워딩 처리는 nginx에서 처리했습니다.)
이 과정을 거치면서 팀원들 모두가 요청흐름에 대해서 파악할 수 있는 시간이 되어서 좋았습니다.
코치님의 피드백
- 현재 킬링파트를 조회하는 경우 노래 클릭 → 킬링파트 듣기 → 노래 나가기 → 다른 노래 클릭 → 킬링 파트 듣기 → 노래 나가기의 과정이 발생하는데 이 부분에서 반복되는 사용자의 행동을 줄이는 것이 더 편의성을 높일 수 있을 것 같다.
데모데이를 통해 느낀점
이번 데모데이를 직접 발표하면서 느낀 점은 제가 했던 작업이어도 사람들 앞에서 말하는 것이 쉽지 않는 것이라는 것을 느꼈습니다. 그래서 앞으로는 제가 작업한 것을 직접 말로 해보면서 제가 정말로 이해를 한 것인지를 계속 체크해야 할 것 같습니다. 여기까지는 개인적으로 느꼈던 것이고 2주동안 팀원들과 많은 작업을 했는데 옆에서 지켜본 결과 팀원 모두가 새로운 것을 배우는데 두려워하지 않고 적용해 나가는 것이 배울 점이라고 느꼈습니다.
