잔액원장 라벨 오매핑 수정

잔액원장 화면의 라벨 오류를 잡고, PDF 영수증에 카드 정보 렌더링을 붙인 작업이다.

왜 이 두 가지를 한 커밋에

compliance 쪽 작업이라 맥락이 겹쳤다. 잔액원장 라벨 정정은 운영자가 화면을 보다가 "이 항목 이름이 이상하다"고 올린 이슈였고, PDF 영수증 카드 렌더는 동일한 compliance 도메인의 detail 뷰에서 출력 요건이 추가된 케이스였다. 두 건 모두 detail.jsp를 건드리는 작업이라 자연스럽게 하나의 feat으로 묶었다. 평소엔 관심사 분리를 강조하는 편인데, 동일 화면·동일 기능 영역 안에서 발생한 수정이라 이번엔 묶는 게 리뷰어 입장에서도 더 읽기 편하다고 판단했다.

작업 내용

라벨링 정정 (잔액원장)

잔액원장 항목의 레이블이 실제 원장 구조와 맞지 않았다. 레이블은 일종의 계약이다. DB 컬럼명, 쿼리 매퍼 alias, JSP 출력 키, 화면 텍스트가 전부 일치해야 운영자든 감사자든 혼선이 없다. 이번 건은 JSP에서 노출하는 한글 텍스트가 실제 원장 항목 정의와 달라서, 보는 사람마다 해석이 달라지는 상황이었다.

수정 경로를 따라가면 이렇다.

이 흐름대로 한 레이어씩 내려가며 alias가 흘러가는지 확인했다. sqlmap의 resultMap alias가 틀리면 그 위 레이어는 전부 엉뚱한 값을 들고 다니게 되는데, 이번 케이스가 딱 그 경우였다. VO 필드 자체는 맞는데 alias가 다른 항목과 섞여 있었다.

<!-- 정정 전 -->
<result column="bal_amt" property="useAmt" />

<!-- 정정 후 -->
<result column="bal_amt" property="balAmt" />

이런 식의 오매핑은 테스트 단계에서 잘 안 잡힌다. 값이 숫자이고, 비슷한 금액대면 육안으로 보기 전까진 모른다. compliance 화면처럼 원장 수치를 직접 보여주는 영역일수록 리뷰할 때 alias 체인을 끝까지 추적하는 습관이 필요하다고 팀원들한테도 말해둔 부분이다.

PDF 영수증 카드 렌더

detail.jsp 안에서 PDF 출력 분기가 있었는데, 카드 결제 케이스일 때 카드 관련 항목들이 아예 빠진 채로 출력되고 있었다. 요건 자체가 뒤늦게 확정됐고, 초기 구현 시점엔 카드 시나리오가 스펙에 없었던 것으로 보인다.

<%-- 카드 렌더 분기 추가 --%>
<c:if test="${detail.payMethod eq 'CARD'}">
  <tr>
    <th>카드사</th>
    <td>${detail.cardCmpnNm}</td>
    <th>승인번호</th>
    <td>${detail.aprNo}</td>
  </tr>
  <tr>
    <th>할부개월</th>
    <td>${detail.instlMm}개월</td>
    <th>카드번호</th>
    <td>${detail.maskCardNo}</td>
  </tr>
</c:if>

PDF 출력용 뷰는 일반 화면 뷰와 공유하는 경우가 많아서, 분기 처리가 뷰 안에 그대로 들어가는 구조가 흔하다. 다만 카드번호처럼 민감 항목은 마스킹된 값(maskCardNo)을 명시적으로 쓰는 게 원칙이다. 이 부분은 utl 쪽 클래스에서 마스킹 처리 후 VO에 담아서 내려오는 구조라 뷰에선 그냥 쓰면 된다. 뷰에서 직접 마스킹하는 패턴은 로직이 흩어지니까 지양한다.

회고

compliance 도메인 작업은 "정확성"이 전부다. 기능이 화려할 필요가 없고, 숫자 하나, 레이블 하나가 틀리면 신뢰 자체가 깨진다. 이번 라벨 오류처럼 운영 중에 발견된 건 항상 찜찜하다. 초기 구현 리뷰 때 쿼리 alias까지 같이 봤어야 했다는 생각이 든다. 앞으로 팀 리뷰 체크리스트에 "sqlmap alias → VO 필드 → 뷰 출력 키 일치 여부" 항목을 명시적으로 넣어둘 생각이다.

PDF 영수증 쪽은 요건이 늦게 들어온 케이스였는데, 이런 상황에서 "일단 공통 뷰에 분기 추가"가 최선인지는 늘 고민이다. 출력 항목이 결제 수단별로 계속 늘어나면 뷰가 지저분해진다. 규모가 커지면 결제 수단별 부분 템플릿을 따로 빼는 쪽이 맞겠지만, 지금 단계에선 오버엔지니어링이라 판단했다.

끝.