[프로젝트 회고] 모두의 후기 userNickname 쿠키 추가와 검색 응답 정리

들어가며

모두의 후기 프로젝트에서 로그인 후 프론트엔드가 사용자 정보를 활용해야 하는 상황이 있었다.

기존에는 로그인 시 accessToken, refreshToken, userEmail 중심으로 쿠키가 발급되었다.
하지만 화면에서는 사용자 닉네임도 자주 필요했다.

닉네임을 얻기 위해 매번 별도 API를 호출하는 것보다, 로그인 시 userNickname 쿠키를 함께 발급하면 프론트엔드에서 사용자 표시가 더 간단해질 수 있다고 판단했다.

이 작업과 함께 검색 API 응답 타입도 정리했다.

userNickname 쿠키 추가

JwtTokenService의 로그인 토큰 발급 로직을 수정했다.

기존에는 로그인 성공 시 다음 쿠키를 발급했다.

• accessToken
• refreshToken
• userEmail

여기에 userNickname을 추가했다.

• accessToken
• refreshToken
• userEmail
• userNickname

이를 위해 createUserNickname(String nickname) 메서드를 추가하고, 로그인 응답에서 닉네임 쿠키가 함께 생성되도록 했다.

왜 쿠키로 내려줬나

프론트엔드에서는 로그인 직후 사용자 닉네임을 화면에 표시해야 했다.

닉네임 하나를 가져오기 위해 추가 API를 호출하는 방식도 가능하지만, 로그인 응답에서 함께 내려주면 초기 화면 구성에 필요한 요청을 줄일 수 있다.

다만 고민도 있었다.

닉네임은 민감 정보는 아니지만, 사용자 식별 정보다.
쿠키에 평문으로 저장하는 방식이 항상 좋은 선택은 아닐 수 있다.

그래서 PR에서도 추후 JWT payload나 암호화된 claim 기반으로 제공하는 방향을 고려할 필요가 있다고 정리했다.

테스트 보강

쿠키가 하나 추가되면 테스트도 바뀌어야 한다.

JwtTokenServiceLoginIssueTest를 추가하고, 기존 JwtTokenServiceTest도 수정했다.

검증한 내용은 다음과 같다.

• 로그인 시 4개 쿠키가 발급되는지
• accessToken 존재 여부
• refreshToken 존재 여부
• userEmail 값 검증
• userNickname 값 검증
• HttpOnly, Secure, SameSite 옵션 확인

이 작업을 하면서 인증 관련 기능은 작은 변경도 테스트가 중요하다는 것을 다시 느꼈다.

쿠키 이름 하나가 틀리면 프론트엔드에서 바로 문제가 발생할 수 있다.

SearchController 응답 타입 정리

같은 PR 흐름에서 SearchController 응답 타입도 정리했다.

기존에는 일부 검색 API에서 SliceBoardResponse를 사용했지만, 응답 의미에 맞게 BoardSearchResponse로 정리하는 방향을 잡았다.

또한 /search, /reviews API에서 CustomPageResponse, CustomSlicePageResponse를 적용해 응답 구조의 일관성을 맞추었다.

이 작업은 닉네임 쿠키 추가와 성격이 조금 다르지만, 프론트엔드가 API를 사용하기 쉽게 만드는 목적은 같았다.

배운 점

이번 작업에서 배운 것은 작은 사용자 정보도 API 계약의 일부라는 점이다.

백엔드 입장에서는 쿠키 하나 추가하는 작업처럼 보일 수 있다.
하지만 프론트엔드 입장에서는 로그인 후 화면 구성 방식이 바뀌는 작업이다.

그래서 다음을 명확히 해야 한다.

• 어떤 쿠키가 발급되는지
• 쿠키 이름은 무엇인지
• 값은 어떤 의미인지
• 보안 옵션은 어떻게 설정되는지
• 프론트엔드는 어떤 상황에서 사용할지

또한 검색 응답 타입을 정리하며, API 응답 구조가 일관되어야 협업이 편해진다는 점도 다시 느꼈다.

마무리

userNickname 쿠키 추가는 작은 기능처럼 보였지만, 인증 흐름과 프론트엔드 사용자 경험을 함께 생각하게 만든 작업이었다.

앞으로 인증/사용자 정보와 관련된 변경을 할 때는 보안, 테스트, 프론트엔드 사용성까지 함께 확인해야겠다.