중계결제 바텀시트에 브랜드 이용안내 노출 기능 추가
목차
relay-pay 영역에 기능 하나를 추가했다. 중계결제 바텀시트에 브랜드 이용안내를 노출하는 것. 변경된 파일은 SQL 매퍼 1개, 뷰/스타일 1개. 파일 수만 보면 작은 작업이지만 실제로는 쿼리 설계부터 화면 렌더링까지 수직으로 한 줄을 다 뚫은 작업이었다.
중계결제 바텀시트는 사용자가 결제 전 최종 확인하는 지점이다. 여기서 브랜드별 이용안내를 보여주려면, 기존 API 응답에 해당 데이터가 없었기 때문에 쿼리 레벨부터 새로 설계해야 했다. 단순 UI 추가였으면 컴포넌트 하나 끼워 넣고 끝이었겠지만, 없던 데이터를 만들어야 한다는 게 포인트였다.
설계할 때 생각한 것들
금융/결제 도메인 특성상 데이터 정합성이 가장 먼저였다. 새 필드 하나를 추가할 때 기존 집계나 상태값이 틀어지면 다른 화면의 숫자까지 영향을 받는다. 그래서 이번 작업에서도 쿼리를 작성하고 나서 실행 계획을 먼저 확인했다.
고려한 항목들을 정리하면:
- 기존 결제 집계 데이터와의 정합성 유지 - 새 조인이 기존 row를 뻥튀기하거나 누락시키지 않는지
- 실시간 갱신 필요 여부 - 브랜드 이용안내 텍스트는 세션 중 바뀔 일이 거의 없어서 폴링보다 초기 로드 시 한 번 가져오는 방식으로 결정
- 예외 케이스 방어 - 브랜드 이용안내가 등록되지 않은 케이스, NULL, 권한 없는 접근 모두 방어 분기 처리
- 성능 영향도 - 기존 쿼리에 조인 하나가 추가되는 구조라 실행 계획 확인 후 인덱스 타는지 검증
쿼리 쪽 변경은 대략 이런 구조였다. 기존 매퍼에 메서드 하나를 추가하고, 브랜드 이용안내 텍스트를 가져오는 SELECT를 붙였다.
<!-- SQL 매퍼 예시 패턴 -->
<select id="selectBrandUsageGuide" parameterType="map" resultType="BrandUsageGuideDto">
SELECT
b.brand_id,
b.usage_guide,
b.guide_updated_at
FROM brand_usage_guide b
WHERE b.brand_id = #{brandId}
AND b.use_yn = 'Y'
</select>
NULL이 올 수 있는 필드라 서비스 레이어에서 Optional로 감싸고, 뷰에는 가이드 텍스트가 있을 때만 영역 자체를 렌더링하도록 조건 분기를 뒀다. 없으면 없는 대로 화면에 빈 블록이 뜨는 게 아니라 아예 노출하지 않는 방식.
검증 방법
구현 후 검증은 두 단계로 했다.
첫 번째는 브랜드 이용안내가 있는 케이스와 없는 케이스를 직접 바텀시트에서 열어 확인. 텍스트가 정상적으로 뜨는지, 없는 케이스는 해당 영역이 아예 숨겨지는지.
두 번째는 cross-check. 이 기능을 추가하면서 결제 집계 화면의 숫자가 변하거나 기존 데이터가 깨지면 안 되기 때문에, 변경 전에 스크린샷으로 수치를 기록해두고 변경 후 같은 화면을 열어 비교했다. 숫자가 하나라도 다르면 원인을 추적해야 한다는 기준으로.
| 검증 항목 | 확인 방법 |
|---|---|
| 이용안내 정상 노출 | 바텀시트 직접 열어 렌더링 확인 |
| 이용안내 없는 케이스 | NULL 브랜드로 바텀시트 열어 영역 미노출 확인 |
| 기존 집계 수치 정합성 | 변경 전후 스크린샷 비교 |
| 쿼리 성능 영향 | 실행 계획 확인, 기존 대비 응답시간 측정 |
작업 후기
사내 결제 서비스를 다루다 보면 "기능 하나 추가"가 얼마나 여러 레이어를 건드리는지 매번 실감한다. 바텀시트에 텍스트 하나 보여주는 것도 쿼리, 매퍼, 서비스, 뷰, 스타일이 다 연결된다. 어느 한 레이어에서 방어가 빠지면 특정 브랜드에서만 이상한 화면이 나오거나 NULL 에러가 터진다.
금융/결제 도메인에서 "대충 맞는 것 같다"는 선택지가 없다. 숫자가 1원이라도 다르거나 이용안내 내용이 잘못 노출되면 신뢰 문제로 직결된다. 그래서 꼼꼼함이 기본값이어야 한다는 걸 팀 전체가 공유하고 있고, 이번 작업도 그 기준으로 진행했다.
커밋은 논리적으로 독립된 단위로 쪼갰다. 쿼리 추가, 서비스 메서드 연결, 뷰 렌더링 이렇게 세 커밋. 파일 두 개 고쳤는데 커밋을 왜 세 번 하냐 싶을 수 있는데, 나중에 특정 변경에서 버그가 발생했을 때 어느 커밋이 원인인지 바로 좁혀지는 게 이 습관의 이유다. 커밋 메시지도 "무엇을 했다"보다 "왜 했다"를 담으려고 노력한다. 3개월 후에 git log를 볼 때 의도가 남아있어야 하니까.
댓글 0
첫 댓글 달아줘.