이룸 프로젝트의 한 챕터를 마치며
항해 18기 실전 프로젝트를 무사히 마쳤습니다. 6주 간의 프로젝트를 끝내며 홀가분하다는 마음도 크지만, 어떤 부분이 부족한지 잘 알고 있기에 아쉬운 마음도 큽니다. 따라서 저희 이룸은 본업이 있는 한 명을 제외하고 이룸을 개선, 발전시키는 2차 프로젝트에 착수하기로 했습니다. 2차 착수는 항해 발표회에서 받은 피드백을 기반으로 합니다.
발표회에서 받은 질문과 피드백들
1. RDS 연결부분 트러블 슈팅에 대해 자세히 설명해 주세요.
2. nginx에서 로드밸런싱을 도입한 전후 성능테스트는 해 보셨나요?
3. 테스트코드는 앞으로 어떻게 발전시킬 예정이세요?
4. 채팅내역을 Redis에 저장하는 이유가 무엇인가요? 중요한 정보는 db에 저장하는 게 좋아 보이는데요.
5. refresh token rotation에 대해 설명해 주세요.
6. CI/CD를 도입한 이유가 무중단 배포만을 위한 건지 버전 관리를 위한건지 궁금합니다.
7. 아키텍쳐는 도커 이미지가 아니라 컨테이너별로 수정하세요.
8. 카카오 로그인할 때 get 메서드를 사용하는 이유가 따로 있나요?
9. HttpStatus 가 OK밖에 없는데 다른 상태 코드는 왜 사용 안 하셨나요?
10. access token과 refresth token의 유효 기간은 각각 어떻게 설정되어 있나요?
11. 서버측에서 refresh token을 재갱신하는 코드가 작성되어 있나요?
12. 오류발생시 모니터링을 할 수 있는 툴이 있나요? '핀포인트'를 추천합니다.
13. 서버가 죽었을 때의 대응 프로세스가 있으면 좋겠습니다.
14. redis에 리프레시 토큰을 저장하는 이유가 뭔가요?
15. 팀 컨벤션이 있나요?
16. 프로젝트 하면서 가장 힘들었던 점은 무엇인가요?
17. 되돌아간다면 다르게 해 보고 싶은 것은 무엇인가요?
멘토님 질문
1. sse와 웹소켓의 차이를 설명해 주세요.
2. 채팅은 어떻게 구현했고 채팅은 어디에 어떻게 저장하는지 말씀해 주세요.
3. Redis의 직렬화와 역직렬화에 대해서 설명해 주세요.
검정색 : 해당 부분 담당자로서 답변해 드린 질문들
파란색 : 팀을 대표해 답변해 드린 질문들
프로젝트의 개선 방안
- 아키텍처와 채팅 관련 질문이 다수였으나 담당자 제외 나머지 백엔드 팀원들이 해당 사항에 대해 잘 알지 못해 답변이 막혔을 때 서포트 해 주지 못함
- 서버 버전 관리와 다운되었을 때 대응 방안 마련해야 함
- 성능 테스트 / 모니터링 툴 등 기능 구현 외 성능 개선에 집중해야 할 필요성 있음
- 데이터 베이스 선택의 이유와 그 구조를 아는 것이 매우 중요.
- 전역 에러 처리로 http status code 주는 부분 전체적으로 수정해야 함
팀 프로젝트를 하며 가장 힘들었던 점
이것은 취업을 위한 프로젝트이니, 각 팀원이 하나의 기술(강점)을 가져가야 한다고 생각했습니다. 따라서 팀원들에게 한 가지 일을 맡기고 자신의 일에만 집중할 것을 주문하였습니다. 각자의 일을 잘하면 아무 문제도 없을 것이라 판단한 것입니다. 하지만 이 운영 방식은 다른 사람의 코드에 귀기울이지 못하고, 누군가 어려움에 처했을 때 도움을 주지도 못하는 문제를 발생시켰습니다.
그러던 중, 다른 팀장과 이 일을 의논하다 생각 전환의 계기를 얻었습니다. 이 프로젝트는 앞으로 마주할 기나긴 협업 과정의 첫 걸음이며, 협업이란 서로의 일을 이해하고 돕는 것임을 깨달았습니다. 따라서 팀원들에게 지금까지의 운영 방식이 미숙했음을 사과하고 남은 3주 동안 하루에 1시간 반씩 코드 리뷰하는 시간을 제안하였습니다. 대화의 장이 열리자 각자의 코드를 읽고 이해하고 질문할 수 있었으며, 자신이 쓴 코드를 설명하는 과정에서 팀원 모두 코드에 대한 이해도가 상승하였습니다.
팀원들을 챙겨 주려 한 것이 오히려 부정적인 결과를 초래했다는 사실에 마음이 아프고 팀원들에게 매우 미안했습니다. 그러나 이 부분은 꼭 개선해야 한다고 생각하여 프로젝트가 이미 반 이상 지난 시점이었지만 개선을 제안하였습니다. 이 일을 통해 잘못된 의사결정을 빠르게 수정하는 것이 얼마나 중요한지 깨달았습니다.
팀 프로젝트를 하며 가장 잘했던 점
끝까지 팀원을 믿고 기다려 주었습니다. 항해 18기에서 스프링은 3조와 4조였습니다. 그중 저희 4조는 인원이 비교적 부족할 뿐더러, 챌린지 팀에 있던 두 분이 3조로 가게 되어 상대적으로 실력이 부족해 보일까 봐 걱정이 되었습니다. 더불어 CI/CD가 3주 이상 소요되어 백엔드 1명은 아예 기능 구현에 참여하지 못하고 있었습니다. 3일 만에 CI/CD를 끝내고 백엔드 4명이 개발에 뛰어든 3조와 자꾸 비교하게 되었습니다.
그러나 팀장을 포함해 모든 팀원이 CI/CD를 맡은 팀원에게 압박을 가하지 않았으며 일찍 기능 구현을 끝낸 백엔드 팀원이 CI/CD로 합류하면서 결국 배포 자동화에 성공하였습니다. 팀 분위기를 '다 해낼 수 있으니 믿고 기다리겠다'로 만들기 위해 노력했고, 이러한 분위기가 형성되면서 팀원들이 편안하게 일할 수 있었다고 생각합니다.
되돌아간다면 다르게 해 보고 싶은 점
그럼에도 불구하고 CI/CD는 오래 걸렸다고 생각합니다. 되돌아간다면 백엔드 3명이 처음부터 CI/CD에 뛰어들어, 서로 의견을 교환하며 빠르게 배포 자동화를 구축할 것입니다.