유튜브 · 블로그 · 노션 등에 흩어진 자기계발 콘텐츠를 저장해 두고도, 어디에 저장했는지 몰라 다시 찾지 못하는 문제를 인터뷰와 설문으로 확인하고 기획한 서비스입니다. 링크를 저장할 때 카테고리 · 태그 · 메모로 맥락을 남기고, 카카오톡 알림으로 다시 보도록 리마인드하며, 제목 · 태그 · 플랫폼 필터 검색으로 저장한 콘텐츠를 되찾을 수 있습니다. 저는 백엔드에서 카카오 소셜 로그인과 JWT 인증, 카테고리 · 태그 도메인, 회원 관리를 맡았습니다. 서비스를 배포까지 마쳤고, Leets 5기 프로젝트 3팀 중 운영진 평가 1위를 받았습니다.
프론트엔드가 카카오 인증 후 받은 인가 코드와 Redirect URI를 GET /api/v1/auth/login/kakao로 전달하면, 서버가 카카오 토큰 발급 → 사용자 정보 조회 → 회원 저장(최초 로그인 시 가입) → JWT 발급을 하나의 트랜잭션에서 처리하고 토큰을 응답 body로 반환합니다. 재로그인 시에는 사용자가 바꾼 닉네임을 카카오 닉네임으로 덮어쓰지 않도록 했습니다.
Refresh Token의 서명 · 만료를 검증한 뒤, DB에 저장된 사용자의 Refresh Token과 일치하는지 확인합니다. Access Token은 매번 새로 발급하고, Refresh Token은 남은 유효 기간이 설정한 기준보다 짧을 때만 교체해 DB에 갱신합니다.
if (shouldReissueRefreshToken(refreshTokenRemainingTime)) {
String reissuedRefreshToken = jwtProvider.createRefreshToken(user);
user.updateJwtTokens(reissuedAccessToken, reissuedRefreshToken);
} else {
user.updateJwtAccessToken(reissuedAccessToken);
}처음에는 북마크가 있으면 카테고리 · 태그를 삭제할 수 없게 했지만, 사용 흐름에 맞춰 정책을 바꿨습니다. 카테고리를 삭제하면 하위 태그 · 북마크 · 북마크-태그 매핑을 함께 삭제하고, 태그는 어떤 북마크의 유일한 태그일 때만 삭제를 막아 북마크가 태그 없이 남지 않도록 했습니다.
PR마다 작업 내용과 Swagger · DB 테스트 결과를 함께 남겨, 프론트엔드와 백엔드 팀원 모두 변경 사항을 빠르게 확인할 수 있었습니다. 카테고리 · 태그 삭제 정책처럼 기획이 바뀐 부분도 테스트 케이스를 붙여 공유하며 맞춰 갔습니다.
인증 흐름을 서버 기준으로만 먼저 설계해, 프론트엔드와 연동하는 단계에서야 로그인 리다이렉트 · 403 반환 · 재발급 API 접근 같은 문제를 발견했고 마감 직전에 수정이 몰렸습니다. 회원 상태 필드처럼 스키마가 바뀔 때 기존 데이터를 수동으로 맞춰야 했던 점도 아쉬웠습니다.
로그인 · 토큰 만료 · 재발급처럼 클라이언트와 맞물리는 흐름은 설계 단계에서 응답 형식과 상태 코드까지 먼저 합의하고, Security 설정을 포함한 인증 흐름을 통합 테스트로 검증해 보고 싶습니다. 스키마 변경도 마이그레이션 도구로 이력을 관리해 보고 싶습니다.