ALLPICK

Java / Spring Boot / React / JWT

커밋 기록에는 이전 GitHub 닉네임 beancan0325로 보일 수 있습니다.

1. 프로젝트 소개와 설계 — 회원·판매자·관리자가 함께 쓰는 쇼핑몰 운영 플랫폼

팀 프로젝트 | 2026.04 ~ 2026.05

ALLPICK은 회원이 상품을 둘러보고 주문하고, 판매자가 상품을 등록·관리하며, 관리자가 승인·환불·문의 같은 운영 업무를 처리하는 쇼핑몰 플랫폼입니다. 같은 주문이나 상품 데이터라도 회원, 판매자, 관리자에게 허용되는 행동이 다르기 때문에 버튼 하나가 잘못 열리면 환불 처리나 판매자 승인 흐름이 어긋날 수 있습니다. 저는 관리자 페이지와 마이페이지를 중심으로 역할별 권한, 환불 상태, 판매자 상태에 맞는 동작만 가능하도록 정리했습니다.

담당 범위

관리자/마이페이지의 환불 상태, 판매자 상태 액션, 요청 토큰, 백엔드 가드를 다뤘습니다.

판단

화면 버튼과 백엔드 상태 전이는 같은 처리 가능 상태 규칙을 공유해야 한다고 보았습니다.

검증

프론트 가드, 토큰 선택, 백엔드 invalid transition 방어를 코드 증거로 보여줍니다.

한계

현재 페이지는 구현 증거 중심이며, 성능 수치나 운영 트래픽 결과는 과장해 적지 않았습니다.

기술 사례 1. 환불 상태를 버튼이 아니라 서버 전이 규칙으로 통제

위험한 상태: 관리자가 처리 불가능한 환불 상태에서도 완료 버튼을 누르거나, API를 직접 호출해 중간 단계를 건너뛰는 상태
결정: 프론트는 현재 상태에 맞는 액션만 노출하고, 백엔드는 ALLOWED_TRANSITIONS로 상태 전이를 다시 검증했습니다. 화면 가드는 편의 기능이고 최종 무결성은 서비스 계층이 지키도록 했습니다.
실제 코드: Frontend AdminRefundPage.jsx의 승인/거절 조건, Backend ClaimServiceImpl.java의 updateStatus와 허용 전이 맵
검증 근거: ClaimServiceImplTest.java에서 허용되지 않은 상태 전이와 처리 완료 상태의 재변경을 검증했습니다.
남은 한계: 운영 트래픽에서의 처리량을 측정한 사례는 아닙니다. 이 사례의 결과는 성능 향상이 아니라 잘못된 환불 상태 전이를 차단한 것입니다.

기술 사례 2. 관리자·판매자·구매자의 권한과 토큰 경계

위험한 상태: 화면 역할과 요청 토큰이 어긋나면 관리자 API에 일반 사용자 토큰을 보내거나, 다른 역할의 액션이 노출될 수 있습니다.
결정: 프론트 요청 계층에서 역할별 토큰을 선택하고, Spring Security URL 규칙과 서비스 검증을 함께 적용했습니다. UI 노출 여부만으로 권한을 신뢰하지 않았습니다.
실제 코드: Frontend api/index.js, Backend SecurityConfig.java, 전역 BusinessException / ErrorCode / GlobalExceptionHandler
검증 근거: 역할별 화면 흐름과 API 오류 응답을 함께 확인해, 실패가 임의 문자열이 아니라 일관된 에러 코드로 돌아오게 했습니다.
결론: 프론트와 백엔드의 책임을 겹쳐 두되, 최종 권한 판단은 서버가 소유하도록 정리했습니다.

기술 사례 3. 판매자 승인 상태와 관리자 액션의 정합성

위험한 상태: 이미 승인·거절된 판매자에게 승인 버튼이 다시 열리거나 API가 중복 처리를 허용하는 상태
결정: 관리자 화면은 판매자 상태별 버튼을 분리하고, 백엔드는 PENDING 상태에서만 승인·거절을 허용했습니다.
실제 코드: Frontend AdminMemberPage.jsx, Backend AdminSellerApprovalServiceImpl.java
검증 근거: AdminSellerApprovalServiceImplTest.java에서 PENDING 목록, 비대기 상태 승인·거절 실패, 상태 토글 제한을 확인했습니다.
결론: ALLPICK을 단순 CRUD가 아니라 여러 역할이 같은 데이터를 다룰 때 상태와 권한을 일치시키는 백엔드 문제로 다뤘습니다.

ALLPICK 환불 상태 흐름 다이어그램 — **환불 상태 흐름**
사용자 요청, 판매자 확인, 관리자 최종 승인/거절 단계를 분리했습니다.

ALLPICK 역할별 토큰 라우팅 표 — **역할별 토큰 라우팅**
관리자, 판매자, 구매자 요청이 서로 다른 토큰으로 백엔드 권한 검사를 통과합니다.

ALLPICK 상태별 액션 매트릭스 — **상태별 액션 매트릭스**
PENDING, APPROVED, SUSPENDED, REJECTED 상태에 따라 가능한 액션을 제한했습니다.

2. 주요 기능

판매자 확인 후 관리자 최종 처리

관리자는 IN_PROGRESS 상태의 환불 요청만 최종 승인/거절할 수 있게 프론트와 백엔드 기준을 맞췄습니다.

요청별 토큰 선택

관리자, 판매자, 일반 사용자 요청이 같은 axios 계층을 거쳐도 요청 성격에 맞는 토큰을 선택합니다.

판매자 상태별 버튼 제어

PENDING, APPROVED, SUSPENDED 상태에 따라 승인, 반려, 정지, 활성화 버튼 노출을 제한했습니다.

백엔드 2차 검증

프론트 조건과 별개로 허용되지 않은 상태 전이는 서비스 레이어에서 예외로 차단했습니다.

3. 프로젝트별 문제-해결

Refund Flow

관리자가 환불 요청을 바로 완료하면 판매자 확인 단계가 사라지는 문제

문제

관리자가 환불 요청을 바로 완료하면 판매자 확인 단계가 사라지는 흐름이 될 수 있었습니다.

원인

환불 요청의 책임이 사용자 요청, 판매자 확인, 관리자 최종 처리로 분리되어 있지 않았습니다.

해결

SUBMITTED -> IN_PROGRESS -> COMPLETED/REJECTED 상태 전이로 역할별 처리 단계를 나눴습니다.

결과

관리자는 IN_PROGRESS 상태의 환불 요청만 승인/거절할 수 있고, 백엔드에서도 허용되지 않은 전이를 차단합니다.

Role Token

관리자·판매자·구매자 요청이 같은 API 계층에서 섞이는 문제

문제

역할이 다른 사용자가 같은 요청 계층을 지나면 잘못된 토큰으로 API가 호출될 수 있습니다.

원인

관리자, 판매자, 일반 회원의 권한 기준이 다르지만 프론트 요청 흐름은 비슷한 구조를 공유했습니다.

해결

요청 성격에 따라 관리자 토큰, 판매자 토큰, 일반 사용자 토큰을 선택하도록 API 계층을 정리했습니다.

결과

같은 화면 흐름 안에서도 역할별 권한 검사를 백엔드가 일관되게 수행할 수 있습니다.

Admin State Guard

판매자 상태와 맞지 않는 관리자 버튼이 열릴 수 있는 문제

문제

이미 승인되었거나 정지된 판매자에게 승인/반려 같은 맞지 않는 액션이 노출될 수 있었습니다.

원인

PENDING, APPROVED, SUSPENDED 상태별로 가능한 관리자 액션이 다르지만 화면과 서버 조건이 분리되어 있었습니다.

해결

프론트 버튼 노출 조건을 상태별로 나누고, 백엔드에서도 PENDING 전용 guard와 상태 전이 검증을 추가했습니다.

결과

화면을 우회하더라도 이미 처리된 판매자 상태에는 잘못된 승인/반려 요청이 저장되지 않습니다.

4. 기능 화면과 코드 증거

ALLPICK 환불 승인 가드 코드 증거 — **환불 처리 가드**
관리자 버튼 조건과 백엔드 상태 전이가 같은 처리 가능 상태를 기준으로 움직입니다.

ALLPICK 환불 상태별 관리자 버튼 렌더링 코드 증거 — **처리 가능 상태 버튼**
IN_PROGRESS 상태일 때만 승인/거절 버튼을 렌더링합니다.

ALLPICK 환불 상태 전이 백엔드 차단 코드 증거 — **백엔드 상태 전이 차단**
허용되지 않은 환불 상태 전이는 서비스 레이어에서 예외로 막습니다.

ALLPICK 역할별 토큰 할당 코드 증거 — **토큰 선택**
API 요청 계층에서 역할에 맞는 토큰을 고른 뒤 백엔드 권한 검사를 통과합니다.

ALLPICK 판매자 상태별 버튼 제어 코드 증거 — **상태 제어**
APPROVED와 SUSPENDED 상태에 따라 정지/활성화 버튼을 바꿉니다.

ALLPICK 판매자 승인 대기 상태 검증 코드 증거 — **PENDING 전용 guard**
이미 처리된 판매자는 승인/반려 요청을 다시 받을 수 없게 검증합니다.

5. 협업 프로세스

담당 범위 분리

마이페이지와 관리자 페이지 흐름을 맡고, 주문/환불처럼 팀원 영역과 닿는 변경은 PR에서 언급했습니다.

Feature Branch

기능별 브랜치와 PR로 API 변경, 화면 상태, 백엔드 검증을 같이 리뷰했습니다.

Code Review

상태 전이, ErrorCode 의미, Controller/Service 검증 중복 여부를 리뷰 관점으로 확인했습니다.

라벨과 릴리즈 증거

팀 GitHub의 이슈, 라벨, 릴리즈 기준으로 변경 성격과 완료 범위를 정리합니다.

이소정

Backend Engineer