<aside> 💡 수료 후, 이력서에 우리가 만들어낸 내용들을 꼼꼼하게 채워넣어야겠죠? 우리 프로젝트의 강점을 잘 녹여내기 위해 회고록 양식을 공유 드립니다. 프로젝트와 작성하시는 회고록을 기반으로 다음 주 멘토님들께서 순회할 예정이니, 새롭게 추가/개선할 기능이나 수정 방향성에 대해서 깊은 고민을 할 수 있는 기회가 되길 바랍니다 😊

</aside>

3주차까지의 후기 및 소감

<aside> 📢 중간 발표 이전 기재

</aside>

1. MVP 중간발표 자료(기입)

1. 프로젝트 정보

   • 서비스명: Want It

   • 서비스 기획 의도:

     • 개인의 애장품, 가치가 높은 물품, 현재는 구할 수 없는 물품등 단순히 사고 팔기에는 아쉬운 물건들을 경매를 통해 그 가치를 보다 높게, 보다 자유롭게 책정받을 수 있는 플랫폼을 만들고자 하였다.

   • 프로젝트 한 줄 설명: 개인의 물품을 경매에 올릴 수 있는 경매 플랫폼

   • 최종 MVP 스펙:

     • 로그인/회원가입(소셜 로그인, 이메일 인증)
     • 메인페이지(캐러셀, 카테고리)
     • 포인트 서비스(입/출금/내역조회)
     • 경매 서비스(상품 등록, 입/낙찰, 실시간 호가 서비스)
     • 마이페이지(프로필 수정, 비밀번호 수정, 내 경매물품 정보 수정)
     • 관리자 페이지 (전체 user 조회, 경매 상태 강제 변경)
     • 판매 금지 상품 키워드 검열
     • 알림 : 푸시 알림, 낙찰 메일 알림

   • 서비스 배포 URL: ####Not Yet######

   • 팀 노션 URL:

     오중포문

2. 기술적 의사결정 & 트러블슈팅 기록

• 프로젝트를 진행하면서 직면한 문제를 어떤 과정으로 해결 하셨는지, 스택별로 기록 해 주세요

• 기술적 의사결정을 기본으로, 트러블슈팅도 있다면 기록해둡시다.

  • 예시 (Token 전략)

  도입 이유	access token과 refresh token의 보안 강화
  문제 상황	access token 만 사용할 경우, 보안을 위해 만료시간을 짧게 설정하여, 사용자의 불편함을 야기 할 수 있음.
  해결 방안	- access token 과는 별도로 refresh token을 추가로 생성해, refresh token보다는 만료시간을 길게 설정함.

  • refres token을 TTL을 설정할 수 있는 Redi로 관리하기로 함. | | 의견 조율 | refresh toke, accesstoken을 발급하고, 만료된 refresh token이 탈취되어 제3자가 접속하면, acceesstoken을 발급받아 서비스에 접근이 가능하다는 문제가 여전히 남아있음. | | 의견 결정 | https를 도입해서 jwt 토큰 탈취에 대한 위험성을 대비하고 보완하도록 하자 |

  도입 이유	refresh token을 Redis로 관리
  문제 상황	짧은 만료시간을 가진 access token을 보완하고자 refresh token도 함께 사용하고자 함,
  access token 보다 긴 만료시간을 부여하고, 이를 별도로 관리해줘야 함.
  해결 방안	1안) redis를 통해 관리할 경우, TTL로 이를 쉽게 관리할 수 있고, redis를 사용해 데이터 응답을 빨리 받을 수 있음.
  2안) SQL 데이터베이스로 관리 할 경우, 별도의 테이블을 만들고 TTL을 직접 관리해야하고, 복잡한 쿼리를 실행해야 할 수 있음
  의견 조율	refresh token을 redis에 userId와 함께 , 만료시간을 설정하여 저장하고 관리하자
  의견 결정	로그인 시, access token과 refresh token을 생성해 , access token 만 user 에게 반환하고, refresh token은 redis 에 저장한다. 만료된 access token으로 User가 서비스에 접근 시, access token 에 담긴 userId 를 통해 redis에서 refresh token 을 찾아와 access token을 재발급해준다. refresh token이 설정해둔 만료기간이 끝나면 redis에서 자동 삭제된다.

  문제 상황	낙찰시 웹 푸시 알림 보내기
  해결 방안	1안) SSE 사용

  • SSE를 사용하면 클라이언트가 subscribe를 하게 되고, 설정한 시간동안 그 subscribe의 유효성이 존재하기 때문에 별도의 추가 요청 없이 지속적으로 서버에서 클라이언트로 응답을 보내줄 수 있다.

  2안) FCM 사용

  • 하루에 한번 정해진 시간에 낙찰 이벤트가 발생하고 단 한번만 낙찰자에게 푸시 알림이 전송되기 때문에 유저가 사이트에서 알림을 허용해 두면 낙찰시에 알림이 전송될 수 있도록 할 수 있다. | | 도입 이유 | 웹 푸시 알림에 대한 실시간성의 연결의 필요성 | | 의견 조율 | 하루에 한번만 전송되는 웹 푸시 알림에도 실시간성의 연결이 필요한가? → 필요 없을 것 같다고 판단. 지속적인 변화 혹은 알림이 아닌 한번만 보내면 되기에 FCM이 더 적절하다고 생각했다. 또한, FCM을 이용하면 유저가 직접 알림을 받을지 안받을지를 허용하는 alert가 발생하기에 유저 편의성이 증가할 것이라고 판단했다. | | 의견 결정 | FCM을 이용해서 유저가 직접 알림 허용을 하고 그에 대한 토큰을 발행한 후 낙찰시 한번만 알림을 보낼 수 있도록 하기로 했다. SSE로도 구현 가능한 기능이지만, 실시간으로 연결할 필요가 없는 기능에 지속적인 연결이 다건 존재한다면 서버에 부하가 갈 것이라고 생각하였고, 이는 당연히 불필요한 리소스 낭비라고 판단하였다. |

  도입 이유	SSE → 실시간 호가 서비스
  문제 상황	경매 서비스의 특성상 입찰가가 변화하는 것을 실시간으로 보여줘야함,
  HTTP통신은 요청이 있어야 응답을 보낼 수 있기 때문에 기존의 방식으로는 무리가 있음을 알게됨
  해결 방안	1안) Polling
  2안) Long Polling
  3안) WebSocket
  4안) Spring SSE
  의견 조율	Polling - 실시간이라 보기엔 약간의 차이가 발생, 무의미한 통신이 발생

  Long Polling - 실시간 서비스이지만, 응답 : 요청 = 1:1 이므로 데이터의 변경이 잦아지면 네트워크 사용량이 증가함

  WebSocket - HTTP와는 다른 통신 프로토콜 이므로 익히는데 시간이 걸림 양방향 통신이 가능하지만 실시간 호가 서비스는 단방향 통신이면 충분하므로 후보에서 제외 | | 의견 결정 | SSE : 실시간 호가 서비스는 서버→클라이언트 로의 단방향 통신의 성격이 강하기 때문에 SSE가 적합 기존의 HTTP 통신 방식을 사용 이벤트가 발생할 때마다 클라이언트로 데이터 전송 | | 개선사항 | SSE connection량 증가한 경우 어떻게 대응할지

  • 오토스케일링의 문제가 발생 가능 → SSE 전용 서버 사용? |

<aside> 📢 중간 발표 이후 기재

</aside>

3. 중간발표 피드백 기록

• 월요일에 대면 피드백을 꼼꼼히 기록해두고, 개선이 필요한 사항에 적용해봅시다.
• React 예시
• 중간 발표 피드백

4. 중간 발표 후 회고 (예시)

1) 미구현 된 MVP 기능

• 목록

2**) 추가/개선 할 기능과 그 이유**

• 예시

3**) 추가/개선할 기능을 어떻게 구현 할 것인지**

• 예시