HomeAboutMeBlogGuest
© 2025 Sejin Cha. All rights reserved.
Built with Next.js, deployed on Vercel
♥️
2기 최종 프로젝트 팀별 공간
/
💸
10원모아10조❗️
/
❗
제출 서류 페이지
/
👨🏻‍🏫
중간 점검 - 멘토 코칭 기록
/
🙋🏻‍♂️
팀 10 백엔드 중간 피드백 면담
🙋🏻‍♂️

팀 10 백엔드 중간 피드백 면담

 

1. 유저 - 로그인

 
  • 비밀번호 형식을 조금 더 구체적으로 하면 좋을 것 같다. (특수문자 포함 등)
  • 정책이 바뀔 경우 사용자에게 안내하는 방법을 사용한다.
    • 사용자가 정책을 따르도록 요구하거나 강제한다.
    • 안 따르면 로그인 할 때마다 정책 안내를 보여줄 수 있다.
    •  
  • password는 길이만 validation만 했는데, 숫자나 문자 들어가는게 요즘 추세인데 그런것들을 하면 좀 더 좋았을 것같다.
    • 기존 유저들을 password를 안내해서 비밀번호 변경을 강제할 수 있을 것같다
    •  
  • login 할 때, Authorization Header 넣고도 로그인이 되는 상황이 되는데, 어떤 상황이 더 좋은 정책인지 고려해봐라.
    • access-token을 다시 줄 수도 있겠지만, 이미 로그인 되었다고 보여줄 수도 있을 것같다.
    •  
  • 유효한 access token 입니다. 는 왜?
    • 토큰을 탈취해서 악용한다면 ?
    • 마르코는 액세스토큰이 만료되었다면 로그아웃 된 상태가 아닐까 생각한다.
    • 자동로그인 만들 때는 어떻게 할 것인가?
    • 로그아웃이 없다. 로그아웃 상태를 고민해봐야한다.
    • 액세스 토큰도 저장이 필요하다.
    • 그래서 redis 필요하다.
 

2. 지출 & 수입

 
  • 수입 조회 도중 400으로 상태코드를 내려보냈는데 리소스가 존재하지 않을때 404가 더 맞는 것같다
  • 다른 유저의 유저카테고리의 아이디로 할 때 권한이 없다라는 메시지가 맞는지
  • 수입 등록 시 초(시간)을 넘겨주지 않는 이유?
    • 일반적으로 초까지는 저장하니까 질문해봤음
    • 프론트엔드 설득이 힘들어서 타협해 분까지만 저장하기로 함
 
날짜 형식이 잘못 되었을 때 터지는 exception이 많다
  • bind exception, time format excpetion 등 구체적인 예외 말고 통합적으로 예외를 던지고 싶다.
  • 저거를 위해서 excpetion handler를 따로 둬야 할까?
  • 슬랙 개인 질문으로
 
각 도메인의 PK를 pathvariable 로 하면 막 보낼 수 있다. (/api/v1/expenditures/1)
  • service에서 체크해야한다.
  • filter에서 공통로직으로 처리 할 수도 있다.
    • filter에서 repository를 가져와도 될까?
      • 된다. 상관없다. 많이 그렇게 한다.
      • 인증, 인가는 앞 단에서 막는 경우도 많다.
 
  • 숫자에 대한 제한(amount 필드)을 두어야 한다.
    • overflow 항상 염두해야한다.
    •  
       

3. 가계부 조회(핵심)

 
  • 일일 상세 내역조회 페이징 처리
    • 페이징 기준이 사용자가 작성한 날짜 (지금은 5일 치 날짜가 나옴)
    • 하나의 날짜에 데이터가 많으면 문제가 생길 수 있다.
      • 페이징 기준 재확립 필요 - 날짜가 아니라 지출, 수입 각 건에 대하여
 
  • 달력 조회
    • month가 왜 있는지?
      • 프론트에서 month 데이터 요청
    • path variable이 8.10 일까지 들어있는데 왜 월별 데이터가 나오나?
      • localdate를 사용해서 이상한 형식이 되었다.
      • year=2022&month=8 형태로 했을 듯
      • localdate가 리소스로서의 역할을 못하는 것같다.
 
  • 예산 등록, 수정을 한 번에 하려고 PUT을 사용함
    • 마르코도 똑같은 상황
      • 초기 값이 이미 세팅이 돼 있었다.
      • 사용자는 추가라고 생각했지만 실제로는 업데이트였다.
    • 이 방법이 잘못된 방법은 아니다.
      • 이유가 있으면 가능
 
 

4. 기타 피드백 및 회고

 
  • N + 1 문제는 잡았는가?
    • 캉테가 열심히 잡아줬다.
    • 최대한 줄이려고 노력하면서 작성
    • 팀원들이 서로 조언을 통해 해결 + 각자 쿼리 개수를 예상하면서 작성하여 큰 어려움이 없었다.
    •  
  • 프로젝트 하면서 힘들었던 거 다음 주 회고에 말하기
    • 문제 발생 → 해결
    • 문제 발생 → 해결 못함
    •  

5. 회고 요약

 
  • 회원 수정과 관련된 MyPage 빼고 현재 작성 예정된 API 대부분 작성
    • 전반적으로 잘 진행된 것같다!
  • 토큰 관리와 로그아웃 회원탈퇴 정책을 고려해보아야 한다.
  • 이미 로그인 된 회원에 대하여 ux적으로 잘 풀어내는 것도 중요하다.
  • 없는 리소스에 대한 요청을 400으로 내려주는 것은 어색하다 → 404가 더 적절해 보인다.
  • 페이징 기준 날짜가 아닌 사용자가 작성한 지출&수입 건에 대해서 고려해볼 것
  • localdate에서 year와 month만 쓴다면 날짜는 필요가없다.
    • 날짜가 필요없는데 localdate로 받는것은 localdate pathvariable이 리소스로서 제 역하을 못하는 것같다.
 
  • 팀 전원이 마르코 피드백을 통해 놓쳤던 부분 수정 및 보완하여 8.14까지 메인 개발 끝나고 남은기간 추후 테스트 및 리드미, 발표작성을 할 예정입니다.