실전 프로젝트-이룸(E-room)

📕📚실전 프로젝트 회고록- 이룸

📌 최종발표회(3/11 마무리)

실전프로젝트-BE 깃허브 주소

📌 피드백

최종발표회 때 받은 피드백과 질문 리스트

1. RDS 연결부분 트러블 슈팅이 발생한 이유
2. nginx에서 로드밸런싱을 도입한 전후 성능테스트
3. 테스트 코드 작성 시 여러 예외 발생 시나리오가 있었다면 설명해주세요
4. 채팅내역을 Redis에 저장하는 이유
5. refresh 토큰 로테이션에 대해 설명해주세요
6. CI/CD를 도입한 이유가 무중단 배포만을 위한 것이였는지, 버전 관리를 위한 건지
7. 아키텍쳐에서 도커 컨테이너별로 표현하는 것이 좋습니다
8. 카카오 로그인 할 때 API를 GET으로 사용하는 이유
9. HttpStatus가 OK밖에 없는데 다른 상태코드는 사용을 왜 안했는지
10. Refresh토큰 과 Access토큰 유효기간 설정 되어있는지
11. 서버측에서 리프레시 토큰을 재갱신하는 코드가 작성되어있나요?
12. 오류발생시 모니터링을 할 수 있는 툴이 있나요? (네이버 핀포인트, 뉴랠릭 추천합니다)
13. 서버에 장애가 있거나 죽었을 때 대응하는 프로세스가 있는지
14. redis의 리프레시 토큰을 저장하는데 이유가 뭔가요?
15. 팀 컨벤션(초기에 작성했는지 중간에 확립이 되었는지)?

멘토님 질문

1. SSE와 소켓의 차이
2. 채팅은 어떻게 구현했고 채팅은 어떻게 저장하는지
3. Redis의 직렬화와 역직렬화에 대해서 설명해주세요

📌 개선사항

• 아키텍쳐 설계는 주관적이라 정답은 없지만 안 죽는 서버는 없으므로 그런 경우 어떻게 대응하는지에 대한 프로세스를 설계해봐야한다
• 현재는 서버 하나에 여러 서비스가 있는데 기능 별로 서버를 여러대로 나누어야 한다
  (MSA 구조로 개발해보는 것도 좋은 경험이고 DB 분리해보는 것도 좋지만 그 전에 서비스라도 분리해보는 작업을 해볼 것)
• 에러 대응하는 것이 중요, 장애 안나는 아키텍쳐는 없다
• 성능 테스트 / 모니터링 툴을 사용해볼 것
• 현재 사용하고 있는 DOCKER가 버전 관리하기에 좋다. 버전 관리를 적용해보도록
• Redis는 인메모리 캐시로 휘발성의 특징을 가지고 있다. 중요한 데이터는 주로 Redis에 저장하지 않는데 데이터베이스의 사용과 목적에 대해서 깊이 생각해볼 것

📌 팀 프로젝트를 하며 어려웠던 점

• 처음 CI/CD와 무중단 배포를 시도하면서 초기에 빠르게 인프라를 구축하고 안정화된 서버를 팀원들한테 제공을 해야한다는 부담감이 있었고
• 수많은 방식 중 우리 프로젝트에 가장 적합한 방식이 무엇인지, 비용은 프로젝트 예산 내에서 해결되도록 어떻게 구성해야할지에 대한 선택지와 고민이 길어졌다.
• 약속한 시간은 있고 트러블 슈팅은 끝이 없었다. 약 3주라는 긴 시간을 사용하면서 팀원들에 대한 미안함이 커졌고
• 내가 올바른 방향으로 트러블 슈팅하고 있는지, 완성할 수 있는지, 기초가 잘못되었는지 확신이 없었던 시간들이 가장 나에게는 어려웠다.
• 멘토님에게도 설명을 드렸지만 코드를 다 보여드릴 수 없었고 설명에도 한계가 있었다. 결국은 내가 스스로 찾고 해결해야 했다.

📌 터닝포인트

1. 이왕 해결해야 한다면 CI/CD 무중단 배포 관련 에러를 많이 겪어본 사람이 되자라는 마인드로 생각을 전환했다
   • 많은 레퍼런스를 찾아보면서 왜 안되는 건지에 대한 트러블슈팅을 차근차근 짚어보았고
   • 처음부터 끝까지 내가 구현하고자 하는 욕심보다는 성공한 코드나 깃헙들을 많이 찾아보고 적용해보게 되었다

• 힘들었던 CICD / 무중단 배포를 완료하고 모든 과정을 떠올려보니 앞으로 새로운 기능을 구현하는 것이나
• 웬만한 트러블 슈팅도 두렵지 않을 것 같다는 생각이 들었다
• 실제로 이 후 구현한 실시간 채팅을 계획한 기간보다 빠르게 구현할 수 있었다

1. 팀원들과 진행한 코드리뷰
   • 내가 무엇을 하고 있고 내가 왜 이 방식을 선택했으며 내가 어떻게 코드를 작성하고 있는지에 대해서
   • 서로를 이해하고 질문하는 시간은 생각의 폭을 넓히게 된 경험이였다
   • 내가 놓쳤던 관점을 다른 사람이 짚어주고 채워주는 공동체성도 함께 느낄 수 있었다

📌 다시 프로젝트를 시작한다면?

1. 이미 기능 구현한 레퍼런스를 적극 참고한다
2. 기술 스택의 사용 이유와 장단점, 다른 방식과 차이점, 이후 사용할 수 있는 툴에 대해 충분히 숙지하고 이해한 다음 팀원들과 나누고 상의한다
3. 트러블 슈팅은 잘 기록하여 동일한 트러블 슈팅이 반복되지 않도록 한다
4. 적절한 시간 분배를 하고 계획한 기간이 지나면 붙들고 있지않고 다른 조에서 같은 기능을 구현한 팀원을 찾아가거나 멘토님께 적극적으로 질문한다

📌 이룸 미니 프로젝트

실전 프로젝트는 종료되었지만 발표회 때 받았던 피드백과 개선사항을 바탕으로 미니 프로젝트를 진행하기로 했다
좋은 팀과 팀원들을 만남에 감사하다 :)

• 기간: 3/12(화) ~ 4/12(금)
• 목적: 프로젝트의 부족한 부분을 보완하고 포트폴리오에 적을 만한 기능을 한 가지 이상 제대로 달성한다
• 해야 할 일:
  하루 3시간씩 코딩! 코드를 놓지 말 것
  코드 리팩토링 및 심화된 기능 구현 (발표회에서 받은 피드백을 중심으로)
  1일 1커밋
  블로그 꾸준히 작성
• 일정: 매일 아침 9~12시 or 오후 6~9시 (유동적)
  1주: 코드 리팩토링 및 지금까지 한 부분 확실히 이해하고 정리하기
  2~3주: 기능 구현
  4주: 추가 작성한 코드 리팩토링 및 기능 구현 마무리. 포트폴리오 정리

[FE]

• 리팩토링(axios, 컴포넌트, 스타일)
• 웹 소켓, 캔버스 API, 임시저장
• 알림 기능 붙여보기
• 성능 점수 개선(라이트 하우스 => 이미지 압축)
• 에러바운더리 서스팬스(에러 관리 한번에)
• 라우터 레이즈
  [BE]
• 서버 버전 관리
• 서버가 다운 되었을 때 대응 프로세스 도입
• 모니터링 툴
• 성능 테스트 (엔진엑스 도입 전후 등)
• 채팅내역 저장 (redis 외 다른 선택지 고민)
• 전역 에러 처리
• 테스트 코드 (여러 예외 사항들 포함하여)
• 알림 기능 (프론트와 붙여보기 + 심화 구현)
• 성능 개선 (쿼리 중심 / 영속성 컨텍스트 등 JPA 심화)

📌 현 프로젝트에서 가장 문제라고 생각되는 부분과 이유

1. 에러처리 핸들러가 제대로 되어있지 않은 점
   • 에러 발생 시 구체적인 에러의 이유를 알 수 없어서 시간이 오래 걸리고 안전하지 않다
2. Redis 성능테스트를 진행하지 않았다는 점과 Redis 인메모리 캐시의 휘발성의 특징에 대한 해결책이 없다는 점
   • Redis 적용 전 후 구체적인 수치로 어떤 점이 이전보다 좋아졌다는 것을 설명할 수 없고
   • 왜 Redis를 사용하는 지에 대한 근거와 이해도가 부족함
3. 서버 장애에 대한 대응이 없다는 것
   • 서비스가 중단되는 사태가 발생하지 않도록 더 안전하게 인프라를 구축하고 여러 경우에 대비하는 것이 중요하다는 생각이 들었다