당근 플래너

예상질문

스크립트

• 발표 구성

  • 서비스 간단소개(20초정도..?)
  • 시연영상(1분)
  • 아키텍쳐 설명(1분)
  • 기술적 의사결정(1분30초)
  • 추후 개발 및 기술적 도전 계획(1분30초**)**

• 준비

  <aside> 📢 18일(수) 밤까지 : 아래 각 항목들 키워드 참고하셔서 자유롭게 작성해주세요!

  19일(목) : 발표 자료 노션 정리 & 시연 영상 촬영 → 제출(24:00)

  20일(금) : 멘토님 사전 질문 확인 & 발표 준비

  </aside>

  참고

  ‣

  • 아키텍쳐(1분)

    

  • 기술적 의사결정(1분30초)

    • 레디스 [성원, 진]

      도입배경

      유저들의 로그인 상태를 유지시키기 위해 리프레시토큰을 사용할 예정

      문제상황

      (백)

      리프레시 토큰을 관리할 장소와 방법 필요

      방안

      1. MySQL에 저장하고 로그아웃마다 삭제
      2. Redis 사용

      의견

      1. MySQL

         1. 주기적으로 만료된 토큰을 제거해야 함(TTL관리, 스케쥴러)
         2. 리프레시토큰 업데이트, 삭제 비용

      2. Redis

         1. 데이터 유효기간 설정 가능
         2. 탈취되었을 경우, 보안상의 이점 있음.

         (유저가 로그아웃 하기 전에 AT가 탈취된 경우, 로그아웃 후에 RT가 삭제되더라도 탈취한 AT로 접근할 수 있기 때문에 로그아웃 시. AT를 블랙리스트에 저장) 방식처럼 관리가 필요 → 이 경우 AT으로 요청이 들어올 때 마다 블랙리스트에 있지 않은지 확인하는 로직 필요)

         1. Refresh 토큰 조회 속도 빠름, 빠른 발급 속도로 병목x (확장성을 고려했을 때)
         2. DB부하 감소

         

         ⇒ 레디스 사용!

    • 리프레시토큰 [강산, 진]

      • 도입이유 : 서비스의 특성상 유저가 서비스에 오래 머무를 가능성이 높다. 따라서 유저의 로그인 상태를 유지시킬 필요가 있다. 동시에 UX를 고려하면 리프레시토큰을 도입하는 것이 좋음.

      • 문제상황: 만료된 Access Token의 재발급은 언제가 좋을까? , JWT를 저장할 위치는?(FE)

      • 해결방안

        <만료된 Access Token의 재발급 시점>

        1. 만료된 Access Token으로 요청이 왔을 때, 토큰 만료 response를 보내고 Refresh Token으로 재발급 request 다시 보내기
        2. 일정 시간 마다 새로운 Access Token 발급해주기
        3. 프론트에서 Access Token이 만료되지 않아도 특정 트리거가(ex. 페이지 이동, 마우스 클릭등 ) 발생할 때마다 Access Token을 재발급

      • 의견 조율

        <만료된 Access Token의 재발급 시점>

        • 1번 해결방안 채택시, 사용자가 인가가 필요한 작업을 요청할 때만 토큰이 재발급 되기 때문에 경제적이라고 생각, 토큰이 만료된 경우 결국 요청은 2번 보내지게 됨
        • 2번 해결방안 채택시, 일정 시간 마다 토큰을 재발급 받는 로직을 짜면 되기 때문에 편리하지만, 계속 토큰 재발급 요청을 보내기 때문에 비효율적일 수 있음.
        • 3번 해결방안 채택시, 비효율적이지만 보안적으로 이점이 클 수 있음.
        • FE에서 로컬스토리지에 저장하기로함.

      • 의견 결정:

        각 방식에 장/단점이 있지만, 과 DX를 고려하여 만료된 Access Token으로 요청이 왔을 때, 토큰 만료 response를 보내고 Refresh Token으로 재발급 request 다시 보내는 방식과 로컬스토리지 저장방식을 선택함.

    • Server-Sent Events

      • 도입이유 : 그룹에 초대받을 때 알림을 받을 수 있도록 하기 위함
      • 문제상황 : 그룹을 만든 사람이 있고 일반 회원이 있을 때, 일반 회원은 어떤 그룹에서 초대가 되었는지 어떻게 알고 승인을 할지 거절을 할지 결정을 해야한다. 이때, 가장 쉬운 접근 방법으로 알림을 사용할 것인데, 이때 통신을 어떤 방법으로 할지에 대한 고민
      • 해결방안
        • HTTP는 비연결성이라는 특징을 가지고 있어서 연결을 끊어버림 → 이로 인해 알림 메세지를 주려고 해도 연결이 되지 않아 보낼 수 없는 상황이 발생
        • 따라서 실시간 웹 애플리케이션 개발 시 사용되는 기법을 활용
        1. Polling
        2. Long Polling
        3. Server-Sent Events
        4. WebSocket
      • 의견 조율
        1. Polling
           • 클라이언트가 지속적으로 요청을 보내고 Event가 발생하면 해당 Event에 대한 결과를 리턴 받음 → 실시간으로 동작한다고 보기에 어려움이 있음
        2. Long Polling
           • 지속적인 요청이 아닌 연결 유지 시간을 좀더 길게 잡음(긴 Connection을 가질 수 있게 Request를 보냄) → 다수의 클라이언트에게 동시에 이벤트가 발생될 경우 Response를 보내고 Request를 다시 보내야하기 때문에 순간적인 부담이 급증.
           • Polling은 HTTP를 통해 통신하기 때문에 Request/Response 모두 Header가 불필요하게 크다는 단점
        3. Server-Sent Events(SSE)
        4. WebSocket
      • 의견 결정 : WebSocket은 양방향 통신에 적합하고 SSE는 단방향 통신에 적합하다. 우리가 사용할 알림 서비스는 단지 알림을 받는 사람 입장에서는 전혀 요청을 하지 않고 서버에서만 응답을 받는 단방향 시스템이기 때문에 SSE에 더 적합하다고 생각했다.

  • 추후 개발 및 기술적 도전 계획(1분30초)

• 멘토님 예상질문

• 중간 발표 예상 질문