멈춘 화면은 그대로,
비어 있던 서버만 채웁니다

[화면 개요 및 목적]

독자는 3화까지 읽고 멈췄습니다. 화면은 이미 있지만 '결제하고 바로 읽기'를 눌러도 아무 일이 일어나지 않는 상태 — 이것이 지금 플랫폼이 매출 0원인 이유입니다. 우리는 이 버튼 뒤의 서버 로직만 정확히 채웁니다.

[핵심 기능 로직]

버튼을 누르는 순간 주문 스냅샷(작품·화·금액·수수료율)을 그대로 얼려 저장합니다. 이후 작품 가격이 바뀌어도 이 주문의 정산 금액은 절대 변하지 않습니다. [제안서 역제안 02 — 불변 정산 원장] / [데모 Step 1과 연결]

• OrderSnapshot 생성 · 가격/수수료율 동결
• 기존 상세 화면 마크업 무수정 연동

[화면 개요 및 목적]

결제창에서 '승인 완료'가 떠도 아직 주문은 확정이 아닙니다. 브라우저가 닫히거나 네트워크가 끊기면 결제만 되고 주문은 사라지는 사고가 여기서 납니다. 이 화면은 그 구간을 눈에 보이게 만든 설계입니다.

[핵심 기능 로직]

주문 확정은 오직 PG 서버 웹훅으로만 처리합니다. 같은 웹훅이 두 번 와도 결과는 한 번만 반영되며(멱등), 웹훅이 늦으면 조회 API로 자동 보정합니다. [데모 Step 2와 연결]

• Webhook 기반 결제 확정 · 멱등 키 처리
• PaymentEventLog 상태 전이 추적

[화면 개요 및 목적]

결제가 확정되는 순간 두 가지가 동시에 일어납니다. 독자에게는 열람 권한이 열리고, 작가의 정산 원장에는 판매 기록이 쌓입니다. 이 둘이 한 트랜잭션으로 묶여 있어야 '돈은 받았는데 못 읽는' 상황이 생기지 않습니다.

[핵심 기능 로직]

환불이 발생해도 기존 기록을 삭제하지 않고 반대 부호의 새 기록을 추가합니다. 그래서 어제의 정산 잔액을 오늘 다시 계산해도 같은 값이 나옵니다. [제안서 역제안 02 / 데모 Step 3과 연결]

• 열람 권한 부여 + 원장 적재 단일 트랜잭션
• Spring Security · 구매자 전용 콘텐츠 접근 제어

[화면 개요 및 목적]

작가가 가장 자주 여는 화면입니다. '이번 달에 얼마 들어오나'라는 단 하나의 질문에 즉시 답하도록, 실지급액을 화면에서 가장 큰 글자로 배치했습니다.

[핵심 기능 로직]

수수료율(20%)과 원천징수율(3.3%)은 코드가 아니라 설정값입니다. 클라이언트가 정책을 늦게 확정해도 개발이 멈추지 않고, 나중에 바뀌어도 과거 정산은 그대로 보존됩니다.

• SettlementPolicy 설정값 분리 (수수료·세율)
• 원장 집계 캐시 · 작품별 판매 롤업

[화면 개요 및 목적]

이 프로젝트에서 가장 중요한 화면입니다. 잔액을 더하고 빼는 방식이면 환불 한 건에 정산이 무너지고, 어디서 틀어졌는지 아무도 모릅니다. 그래서 모든 금액 이동을 한 줄씩 쌓는 원장 방식으로 설계했습니다.

[핵심 기능 로직]

SALE / FEE / REFUND / FEE_REVERSAL / PAYOUT 다섯 가지 유형만으로 모든 상황을 표현합니다. 어떤 시점의 잔액이든 그 시점까지의 기록을 더하면 나옵니다. [제안서 역제안 02의 핵심 증거 / 데모 Step 3과 연결]

• settlement_ledger · append-only 설계
• 환불 시 역기록(reversal) 자동 생성

[화면 개요 및 목적]

작가가 실제로 돈을 받는 마지막 관문입니다. 계좌 실명 확인, 세금 구분, 원천징수 계산, 증빙 서류까지 — 개발이 아니라 세무·운영에서 사고가 나는 구간이라 화면에서 미리 전부 보여줍니다.

[핵심 기능 로직]

신청 즉시 해당 금액을 HOLD 상태로 잠급니다. 잠긴 금액은 다음 회차 정산에 이중으로 잡히지 않으며, 관리자 승인 후에만 PAYOUT 기록으로 전환됩니다.

• Data Aggregation & Visualization
• 정산 명세서·원천징수영수증 자동 발급

[화면 개요 및 목적]

매달 말일 밤에 한 번 도는 배치입니다. 이 배치가 실패하면 다음 날 137명의 작가가 동시에 문의를 넣습니다. 그래서 진행률과 로그를 화면에서 직접 보게 만들었습니다.

[핵심 기능 로직]

배치는 몇 번을 다시 돌려도 같은 결과가 나오도록 설계합니다(멱등). 중간에 서버가 죽어도 이어서 재실행하면 되고, 중복 정산이 발생하지 않습니다. [데모 Step 2와 연결]

• SettlementCloseJob · 멱등 재실행 지원
• 예외 건 자동 HOLD · 실시간 로그 스트림

[화면 개요 및 목적]

돈이 실제로 빠져나가는 유일한 지점입니다. 화면을 숨기는 것만으로는 부족하고, 서버가 요청자의 권한을 매번 확인해야 합니다. 기존 관리자 화면은 그대로 두고 인가 로직만 서버에 붙입니다.

[핵심 기능 로직]

일반 사용자·작가 계정이 같은 주소를 직접 호출해도 서버가 403으로 거부합니다. 승인 행위는 누가 언제 무엇을 승인했는지 감사 로그로 남습니다.

• Spring Security · ROLE_ADMIN 메서드 인가
• 승인 감사 로그 (actor · time · amount)

[화면 개요 및 목적]

재개장 이후 클라이언트가 매일 확인하게 될 화면입니다. PG에 실제로 들어온 돈과 우리 원장이 계산한 금액이 같은지를 하루 한 번 자동으로 맞춰 봅니다.

[핵심 기능 로직]

차액이 1원이라도 생기면 해당 주문번호가 즉시 목록에 뜨고 지급 배치는 자동으로 멈춥니다. 잘못된 돈이 나가는 것보다 하루 늦게 나가는 것이 언제나 낫습니다. [제안서 역제안 02·03 / 데모 Step 4와 연결]

• 일 배치 대사 · 불일치 시 지급 자동 중단
• Issue Tracking & Status Management