[HOTSPOT] 2026.06.14 - 매니저와 크리에이터 정산 내역 표시 개선을 실제 프로젝트에 적용한 과정

1. 이번 변경의 중심은 매니저와 크리에이터 정산 내역 표시 개선이었다

이번 작업은 새로운 역할을 추가하는 문제가 아니라, 이미 운영 중인 화면과 API가 실제 데이터 형태를 정확히 따라가도록 맞추는 작업에 가까웠다. 관리자 배너, 상품 목록, 정산 내역, 프로필 링크처럼 서로 다른 영역처럼 보이는 기능도 공통점은 같다. 화면이 기대하는 응답 구조와 서버가 돌려주는 데이터가 조금만 어긋나도 사용자는 빈 화면, 누락된 값, 잘못된 목록을 보게 된다.

그래서 이번에는 기능을 넓히기보다 오류가 난 지점을 좁게 따라갔다. API 응답 래퍼, 페이징 응답, 카테고리 조건, 프로필 URL 저장 여부처럼 작은 계약들을 다시 확인하고, 프론트엔드가 안전하게 값을 읽을 수 있도록 흐름을 정리했다.

2. 빈 화면 문제는 대개 데이터 계약에서 시작된다

관리자 배너 화면처럼 목록을 보여주는 페이지는 응답 형태가 조금만 달라져도 전체 화면이 멈춘 것처럼 보일 수 있다. 예를 들어 화면은 배열을 기대하는데 서버가 ApiResponse로 한 번 감싼 객체를 내려주면, 렌더링 코드는 데이터를 찾지 못한다.

const items = Array.isArray(response)
  ? response
  : response.data ?? response.content ?? [];

이런 fallback은 임시방편이 아니라, 실제 운영 중 API 응답 형태가 바뀌거나 페이징 응답으로 확장될 때 화면이 완전히 깨지는 것을 막는 방어선이다. 특히 관리자 화면은 데이터가 없어서 비어 있는지, 파싱 실패로 비어 있는지 구분할 수 있어야 한다.

3. 상품 목록과 카테고리는 같은 조건으로 조회되어야 한다

상품 목록에서 전체 카테고리나 특정 카테고리를 선택했을 때 일부 상품이 빠지는 문제는 저장된 데이터보다 조회 조건을 먼저 의심해야 한다. 같은 상태 조건을 쓰면서도 카테고리 조건을 붙이는 쿼리와 전체 조회 쿼리가 서로 다른 join이나 fetch 전략을 쓰면 결과가 달라질 수 있다.

Page<Product> page = category == null
    ? productRepository.findByStatus(status, pageable)
    : productRepository.findByCategoryAndStatus(category, status, pageable);

이번 수정의 핵심은 전체 조회와 카테고리 조회가 같은 기준으로 동작하도록 맞추는 것이다. 불필요한 EntityGraph나 count 쿼리의 join 문제를 줄이고, 프론트엔드에서는 페이징 응답을 안정적으로 풀어 목록을 만든다.

4. 정산 내역은 상태와 관계를 함께 보여줘야 한다

정산 화면은 단순 목록보다 민감하다. 매니저와 크리에이터의 제휴 관계, 종료된 파트너십, 정산 상태가 함께 얽혀 있기 때문이다. 그래서 화면에는 현재 활성 상태만이 아니라 종료된 관계에서 발생한 정산 내역도 필요한 맥락 안에서 보여줄 수 있어야 한다.

정산 API가 실패했을 때도 사용자가 원인을 알 수 있게 오류 텍스트를 보여주는 편이 낫다. 조용한 빈 화면은 데이터가 없다는 뜻인지, 권한이나 응답 형식이 잘못됐다는 뜻인지 판단할 수 없게 만든다.

5. 프로필 URL 저장은 입력부터 응답까지 왕복해야 한다

SNS URL이나 인스타그램 URL 같은 프로필 필드는 화면 입력값이 저장 요청에 포함되고, 백엔드 DTO에 저장되며, 다시 조회 응답으로 돌아와야 완성된다. 중간 한 곳에서만 빠져도 저장이 된 것처럼 보이다가 새로고침 후 사라지는 문제가 생긴다.

const payload = {
  nickname,
  introduction,
  channelUrl,
  snsUrl,
  instagramUrl,
};

작은 필드일수록 놓치기 쉽지만, 프로필 링크는 사용자가 외부 채널로 이동하는 실제 동선이다. 그래서 저장 payload와 응답 타입, 화면 표시 CSS까지 함께 확인해야 한다.

6. 정리

이번 작업에서 얻은 기준은 단순하다. 목록 화면은 응답 구조를 안정적으로 풀어야 하고, 상품 조회는 전체와 카테고리 조건이 같은 기준으로 움직여야 하며, 정산과 프로필 정보는 사용자가 다시 확인할 수 있는 형태로 남아야 한다. 기능을 추가하는 것보다 이미 있는 기능이 같은 데이터 계약 위에서 움직이게 만드는 일이 더 중요할 때가 있다.