compliance 감사 쿼리 필터 오염 제거

오늘은 compliance 관리 화면에서 발견된 두 가지 버그를 같이 잡았다. 하나는 감사 목록 조회 시 불필요한 sysIdFilter 조건이 섞여 들어가는 문제, 다른 하나는 cashflow 실패 행이 시각적으로 구분되지 않아 운영자가 육안으로 걸러내기 어려웠던 문제였다.

왜 이 두 이슈를 같은 커밋에 묶었나

규모가 작은 픽스 두 개를 따로 PR 내면 리뷰 비용이 배가 된다. 둘 다 compliance 화면이라는 도메인 맥락을 공유하고, 하나는 백엔드 쿼리·컨트롤러 레이어, 다른 하나는 프론트 스타일링 레이어라 서로 충돌 가능성이 거의 없었다. 팀 내에서는 "같은 화면, 같은 배포 단위에 물려 있는 핀포인트 수정이면 하나로 묶어도 된다"는 기준을 쓰고 있어서 이번엔 같이 올렸다.

sysIdFilter 제거 — 왜 감사 로그에 시스템 ID 필터가 끼면 안 되나

관리자감사 쿼리는 말 그대로 전체 운영자 행위를 조회하는 목적으로 만들어진 것이다. 그런데 어느 시점에 비슷한 쿼리를 복붙하면서 sysId = #{sysId} 조건이 쿼리 매퍼에 슬그머니 남아 있었다. 결과적으로 특정 sysId 기준으로만 감사 로그가 필터링되어, 운영자는 "왜 이 행위자의 로그가 안 보이지?" 같은 혼란을 겪게 되는 구조였다.

컨트롤러(내부 클래스)와 쿼리 매퍼를 같이 건드린 이유가 여기 있다. 쿼리만 고쳐도 당장 동작은 맞아지지만, 컨트롤러에 파라미터 바인딩이 남아 있으면 나중에 누군가 다시 조건을 추가할 여지가 생긴다. 흔적 없이 깔끔하게 정리하는 게 맞다고 판단했다.

이런 류의 버그는 대부분 "공통 DTO/파라미터 객체를 재사용하면서 불필요한 필드가 딸려오는" 패턴에서 발생한다. 감사·컴플라이언스 쿼리처럼 조회 범위가 명확히 전체여야 하는 경우는 DTO 단에서부터 필드 자체를 빼두는 게 안전하다.

<!-- Before -->
<select id="selectAdminAuditList" ...>
  SELECT * FROM admin_audit
  WHERE 1=1
  AND sys_id = #{sysId}   <!-- 이게 문제 -->
  ORDER BY reg_dt DESC
</select>

<!-- After -->
<select id="selectAdminAuditList" ...>
  SELECT * FROM admin_audit
  WHERE 1=1
  ORDER BY reg_dt DESC
</select>

cashflow 실패 행 시각 구분 — CSS/SCSS 작업 내용

cashflow 목록에서 결제 실패나 처리 오류 행이 성공 행과 동일하게 렌더링되고 있었다. 운영자가 수동으로 한 줄 한 줄 상태 컬럼을 읽어야 했고, 특히 데이터가 많은 날에는 실패 건을 놓치는 사고가 날 뻔한 상황이기도 했다.

수정은 _compliance.scss와 apple.css 두 파일을 건드렸다.

• SCSS에서 .cashflow-row--failed 같은 상태 클래스 기준으로 배경색·텍스트 색상 처리
• detail.jsp에서 서버 사이드 렌더링 시 실패 상태 값에 따라 해당 클래스를 조건부 적용
• apple.css는 빌드 산출물 혹은 사이트별 오버라이드 파일로, SCSS 변경분이 반영된 형태로 같이 업데이트

// _compliance.scss
.cashflow-row {
  &--failed {
    background-color: rgba(220, 53, 69, 0.08);
    color: #c0392b;

    td {
      font-weight: 500;
    }
  }
}

<%-- detail.jsp 일부 --%>
<tr class="cashflow-row ${row.status eq 'FAIL' ? 'cashflow-row--failed' : ''}">
  ...
</tr>

시각적 구분이라는 게 개발자 입장에선 사소하게 느껴질 수 있는데, 운영자 입장에서는 인지 비용을 확 줄여주는 작업이다. 특히 컴플라이언스·정산 계열 화면은 실수가 곧 비용으로 직결되는 맥락이라 이런 UX 디테일을 빠르게 처리하는 게 중요하다고 본다.

회고

이번 작업에서 배운 건, 감사/컴플라이언스 계열 쿼리는 일반 목록 쿼리보다 조건 오염에 훨씬 민감하게 리뷰해야 한다는 것. 일반 목록이라면 필터 하나 빠지거나 더 붙어도 UX 이슈지만, 감사 로그라면 곧바로 "데이터 누락 → 감사 신뢰성 훼손"으로 이어진다. 코드 리뷰 체크리스트에 "감사/로그 쿼리는 전체 범위 필터 여부 확인" 항목을 명시적으로 추가해야겠다고 팀에 공유할 예정이다.

끝.