파트너 포털 수수료 화면에서 내 수익 미리보기 섹션 제거

파트너 포털 수수료 화면에서 "내 수익 미리보기" 섹션을 제거했다. 변경 파일은 뷰/스타일 1개. 커밋 크기만 보면 사소해 보이지만, 수정 판단 자체가 꽤 오래 걸렸다.

수익 미리보기 섹션은 파트너가 현재까지 쌓인 수수료를 실시간에 가깝게 확인할 수 있도록 만들어진 UI였다. 의도는 좋았는데, 문제는 "미리보기"라는 이름이 암시하는 것처럼 확정된 수치가 아니었다는 점이다. 집계 기준 시점, 정산 보류 건, 부분 취소 케이스가 섞이면 숫자가 실제 정산액과 어긋나는 경우가 있었다. 특정 상황-구체적으로는 정산 주기 경계에 걸친 엣지 케이스-에서 계산이 잘못된 값을 뱉거나 오류로 빠졌다.

이걸 고치려면 크게 두 갈래였다: 로직을 손봐서 엣지 케이스를 전부 커버하거나, 섹션 자체를 없애거나. 전자를 택하려면 집계 쿼리와 상태 머신 양쪽을 건드려야 해서 범위가 커지고, 수정 도중 다른 케이스를 건드릴 위험도 있었다. 이미 화면 다른 곳에 정확도 높은 정산 내역이 있어서 미리보기가 제공하는 가치 자체도 중복이었다. 그래서 제거 쪽으로 결론 냈다.

무엇을 수정했는가

렌더링 쪽은 해당 섹션 마크업과 조건부 노출 로직을 제거했다. 스타일도 함께 정리-섹션이 사라지면서 레이아웃 여백이 달라지는 부분이 있어서 CSS도 같이 손봤다. 뷰/스타일 파일 하나에 다 담겼다.

수정 전에 먼저 확인한 것들:

• 같은 집계 로직이 다른 화면이나 API에 중복으로 쓰이는지
• 해당 섹션을 다른 컴포넌트가 참조(import하거나 slot으로 쓰는지)하는지
• 제거 후 빈 자리가 레이아웃을 깨는지

중복 참조가 없었고, 레이아웃은 CSS 조정으로 깔끔하게 정리됐다.

- <section class="revenue-preview">
-   <h3>내 수익 미리보기</h3>
-   <RevenuePreviewWidget :summary="revenueSummary" />
- </section>

/* 수수료 화면 레이아웃 */
.commission-layout {
-  display: grid;
-  grid-template-rows: auto 1fr auto;
+  display: grid;
+  grid-template-rows: auto 1fr;
}

실제 파일 구조는 다르지만 변경 방향은 이런 식이다. 섹션 마크업과 연결된 데이터 바인딩을 떼고, 그 자리를 차지하던 그리드 트랙도 제거했다.

금융 도메인에서 UI 제거가 까다로운 이유

금융/정산 화면에서 숫자를 보여주는 컴포넌트를 없애는 건 생각보다 무겁다. 기능적 삭제인데 사용자 입장에서는 "원래 있던 숫자가 사라졌다"로 읽힐 수 있다. 이 경우엔 대체 화면이 명확히 있었고 미리보기 특성상 비확정 수치였기 때문에 제거 결정이 깔끔했지만, 그렇지 않은 상황이라면 숨기기(feature flag)나 안내 문구 교체를 먼저 검토해야 할 거다.

이번엔 첫 번째 줄이 맞았다. 대체 화면이 있고, 미리보기는 중복이었고, 정확하지 않은 숫자를 굳이 보여줄 이유가 없었다.

수정 후 검증

변경 후엔 버그를 직접 재현해서 섹션이 사라졌는지 확인하고, 남은 수수료 화면이 레이아웃 깨짐 없이 정상 렌더링되는지 봤다. 다른 정산 화면과 숫자를 cross-check하는 과정도 거쳤는데, 이건 "내가 건드린 게 다른 곳에서 숫자를 바꾸지 않았나"를 확인하는 작업이다. 뷰 파일만 건드렸으니 집계 로직엔 손을 안 댔지만, 그래도 한 번은 확인하는 게 습관이 됐다.

버그 수정 때마다 적용하는 체크:

• 같은 패턴이 다른 경로에도 있는지 (중복 코드 탐색)
• 수정이 기존 정상 케이스를 망가뜨리지 않는지 (회귀 방지)
• 해당 화면에서 실제 동작 확인
• 관련 숫자를 다른 화면과 cross-check

네 가지가 다 통과되면 커밋. 이 중 하나라도 찝찝하면 일단 멈추고 다시 본다.

사내 서비스를 만들다 보면 기능 하나가 단순히 화면에 버튼 하나 추가하는 것으로 끝나지 않는다는 걸 계속 체감한다. SQL 집계, 상태 머신, 예외 처리, 화면 렌더링, 권한 체크가 전부 엮여 있어서 어느 하나만 빠뜨려도 숫자가 맞지 않거나 특정 사용자에게 이상한 화면이 나온다. 특히 정산 도메인은 숫자 하나가 틀리면 신뢰가 무너질 수 있어서 꼼꼼함이 기본값이어야 한다. "대충 맞는 것 같다"로 넘어가면 반드시 다시 돌아온다.

이번 작업은 커밋 단위는 작았지만, 판단 자체가 그냥 픽스인지 제거인지를 먼저 결정해야 했다는 점에서 단순하지 않았다. 작은 커밋이 많다는 건 그 판단들이 쌓인다는 의미이기도 하다.