스터디 진행 일시
날짜 : 9월 05일 (목요일) 시간 : 오후 6시 ~ 9시 (3시간) 장소 : 강남 (오프라인)


🔧 금주 스터디 일정
  • 아이스 브레이킹
  • [채팅 프로젝트] JWT 생성 및 필터 구조 코드 리뷰


코드 리뷰

채팅 프로젝트를 시작하면서 새롭게 다시 기본 구조부터 만들기로 하였다.

  • 인프라

    • 은지님

  • 백엔드

    • 은지님, 유경님, 근우님

  • 앱

    • 요한님

  • 웹

    • 소영님


이번 주 스터디에서는 근우님이 작성하신 JWT 생성 및 필터 로직을 주제로 라이브 코 드 리뷰를 진행하였다. 참고로 스터디의 코드 리뷰 문화는 다음과 같다.


  • 공격적인 리뷰는 지양합니다.
  • 잘 작성된 코드에는 칭찬을 아끼지 않습니다.
  • 수정이 필요한 코드에는 이유와 함께 관련 자료를 첨부하면 좋습니다.
  • 리뷰를 받는 사람은 열린 자세로 피드백을 받아들이고, 이해가 되지 않는 부분은 적 극적으로 질문하는 것이 좋습니다
  • 받은 피드백을 정리해 두고, 반복되는 패턴은 개인의 코드 작성 습관에 반영하면 성 장에 큰 도움이 됩니다


아래는 이번에 진행한 코드 리뷰의 일부이다.


코드 리뷰1

PR 올리신 근우님


코드 리뷰2

  • lazy의 역할이 무엇일까? 왜 SecreKey에 Lazy를 단 것일까?
    • lazy는 객체를 실제로 필요할 때 초기화하는 기능이다.
    • SecreKey에 달게 되면 처음 호출하기 전까지는 메모리에 올라가지 않고 호출되는 순간 코드가 실행되며 그 이후에는 캐시된 값을 반환하게 된다.
    • 이것은 안드로이드 앱의 역사적 배경과 관련이 있다.
      • 예전 안드로이드에서는 앱 실행 시, 모든 객체를 즉시 초기화하면 메모리 부족 이나 불필요한 초기화로 인해서 앱 충돌이 자주 났다.
      • 특히 SecretKey 같은 보안 객체는 앱 실행 직후 꼭 필요한 게 아니었기 때문에, lazy를 사용해 실제로 필요할 때 초기화되도록 해주었다. 지금도 lazy는 메모리 효율과 안정성을 높이는 좋은 습관으로 남아 있다.


코드 리뷰3

  • now()가 반환하는 시간은 기본적으로 UTC 기준이므로, 실제 서비스 환경에서는 KST 와 같은 타임존을 고려할 필요가 있다.


코드 리뷰4

  • 이 피드백을 계기로 예외 처리를 어디까지 담당해야 하는지, 그리고 try-catch의 범 위는 얼마나 가져가야 하는지에 대해 논의할 수 있었다.

    • 불필요한 중복 처리 지양: 이미 프레임워크(여기서는 Spring Security)가 적절히 처리하는 예외라면, 중복된 try-catch는 코드 가독성과 유지보수성을 떨어뜨릴 수 있다.

    • try-catch 범위 최소화: try 블록이 지나치게 넓으면 어디서 예외가 발생했는지추 적하기 어려워지고, 예상치 못한 예외까지 잡아버릴 수 있다. 따라서 필요한 최소 한의 범위에서만 사용하는 것이 좋다.

    • 직접 처리해야 할 경우: 로깅, 사용자 정의 메시지 전달, 특정 예외만 다른 방식 으로 처리해야 할 때는 try-catch가 필요하다.


코드 리뷰5

  • 토큰에 들어가는 데이터는 반드시 서버가 신뢰할 수 있는 정보(예: principal 객체) 에서 가져와야 한다는 점을 다시 한번 확인하는 것이 좋다.
  • 클라이언트 요청 값을 그대로 사용하는 경우, 악의적인 요청에 의해 잘못된 username이 들어갈 수 있고 이는 보안상의 취약점으로 이어질 수 있다.
  • 일관된 네이밍 컨벤션은 팀 협업과 유지보수에서 큰 차이를 만들어낼 수 있다.


코드 리뷰6

  • 책임 분리(Separation of Concerns) 측면에서 중요한 포인트이다.
  • Controller는 보통 요청을 받아 비즈니스 로직으로 전달하는 역할에 집중하는 것이 좋고, 보안이나 인증 관련 로직은 Filter나 SecurityConfig 쪽에서 담당하는 것이더 명확할 수 있다.
    • 이렇게 하면 코드 구조가 단순해지고, 재사용성도 높아지며, 보안 로직이 중앙화 된다는 장점이 있다.