Zero to Developer

Onion Store와 내가 맡은 범위프로젝트 명: onion store인원: 5명프로젝트 기간: 10일배경: 한 명의 판매자가 직접 상품을 판매하는 단일 판매자 쇼핑몰주요 기능: 고객의 장바구니·주문·결제, 관리자의 상품·주문 관리, 채팅(cs)담당 : 결제, 환불요약처음에는 결제 기능을 구현하고, 결제창을 닫은 사용자의 미완료 주문을 정리하는 스케줄러를 붙이면 된다고 생각했다. 하지만 결제창 이탈을 처리하려는 작은 요구사항은 결제 상태 확인, 웹훅, 금액 불일치 취소, 부분 환불, 외부 결제 취소 결과를 다시 확인하는 방법에 대한 고민까지 이어졌다. 이번 글에는 짧은 기간의 팀 프로젝트에서 정책이 정해지지 않은 기능을 구현으로 먼저 해결하려 했을 때, 설계와 PR 단위가 왜 함께 어려워졌는지 돌아본다..

요약기존 Todo API를 Spring Boot 4.1.1 환경으로 옮기면서 단순히 의존성 버전만 올리는 데서 끝내지 않았다. JWT 인증 정보의 전달 방식, 매니저 등록 실패 시 남겨야 하는 로그의 트랜잭션 경계, 조회 API의 N+1과 집계 검색까지 함께 정리했다.이 글에서 다루는 범위는 다음과 같다.Java 17·Spring Boot 4.1.1·Gradle Wrapper 8.14.3 기반 실행 환경 정비HttpServletRequest attribute 기반 JWT 전달 구조를 Spring Security 표준 구조로 전환관리자 역할 변경 접근 로그와 담당자 등록 요청 로그의 목적 분리Todo 생성과 담당자 자동 등록, 요청 로그의 독립 트랜잭션 처리JPQL fetch join·@EntityGrap..

배경Spring Security로 JWT 인증·인가 구조를 전환한 뒤, USER 권한 토큰으로 관리자 API를 호출했다.기대한 결과는 403 Forbidden이었다.인증 성공하지만 ADMIN 권한 없음→ 403 Forbidden그런데 실제 응답은 401 Unauthorized였다. 더 혼란스러웠던 점은 애플리케이션 로그에 JWT 인증 성공까지 남았다는 것이다.JwtFilter 진입 - uri=/admin/users/1JWT 인증 성공 - userId=1, role=USER이 글은 “토큰 검증은 성공했는데 왜 최종 응답은 401이었는가”를 추적하며, JWT 필터와 Spring Security 인가 정책의 책임을 다시 나눈 기록이다.먼저 구분할 것: 401과 403은 실패 지점이 다르다관리자 API의 응답은..