로그인 이력 적재와 가상계좌 필터 제거로 컴플라이언스 정비

로그인 이력 적재 로직을 붙이면서, 동시에 가상계좌 번호 필터를 걷어냈다.

두 작업이 같은 커밋에 묶인 게 처음엔 조금 어색해 보일 수 있는데, 실제로는 compliance 도메인 정리라는 같은 맥락 위에 있었다. 회원의 접근 기록을 남기는 것과, 화면에서 불필요한 민감 정보 필터를 제거하는 것 — 둘 다 "무엇을 기록하고, 무엇을 노출하지 않을 것인가"라는 컴플라이언스 관점의 질문에서 나온 작업이었다.

로그인 이력 적재, 왜 지금?

사내 서비스에서 회원 로그인 이력을 관리하는 건 감사 추적(audit trail) 측면에서 기본 중에 기본이다. 누가, 언제, 어디서 접근했는지 남겨두지 않으면 나중에 문제가 생겼을 때 추적 자체가 불가능해진다. 운영자 입장에서도, 보안 담당자 입장에서도 이 데이터는 꽤 중요하게 쓰인다.

이번에 건드린 파일은 크게 세 곳이다.

유틸 클래스 쪽에서 이력을 쌓는 메서드를 작성하고, 쿼리 매퍼에서 실제 INSERT 쿼리를 정의했다. 패턴 자체는 전형적인 MyBatis 기반 iBatis 스타일의 흐름이라 크게 복잡하지 않았지만, 어떤 시점에 이력을 적재할 것인지가 핵심 결정 사항이었다.

// 로그인 성공 후 이력 적재 패턴 (일반 예시)
public void insertLoginHistory(LoginVO loginVO) {
    loginVO.setLoginDt(new Date());
    loginVO.setLoginIp(RequestUtil.getClientIp());
    loginHistoryMapper.insertLoginHistory(loginVO);
}

이런 류의 이력 적재는 로그인 성공 시점에 걸어야 하는지, 아니면 세션 생성 이후에 걸어야 하는지 항상 약간의 고민이 생긴다. 실패 이력도 남길 것인지, IP는 프록시를 어떻게 처리할 것인지 — 작은 기능처럼 보여도 세부 결정이 꽤 많다. 이번엔 성공 케이스 우선으로 정의했다.

vbank_num 필터 제거

detail.jsp에서 vbank_num(가상계좌번호) 필터를 걷어낸 부분이 흥미로웠다.

원래 이 필터가 붙어있던 이유는 아마 화면 출력 시 민감 정보를 마스킹하거나, 조건에 따라 노출을 제한하려는 목적이었을 것이다. 그런데 compliance 상세 화면은 운영자 혹은 내부 담당자가 보는 영역이라, 해당 필터가 오히려 필요한 정보를 가리는 문제가 있었다. "보호를 위해 걸어둔 필터가 정작 담당자의 업무를 방해하는" 전형적인 케이스다.

• 고객 대상 화면: 민감 정보 마스킹 필요
• 내부 운영자 / compliance 담당자 화면: 원본 데이터 확인 필요
• 같은 필터를 양쪽에 그대로 적용하면 운영 효율이 떨어짐

이런 경우엔 필터 자체를 없애는 게 아니라, 화면 컨텍스트(대상 사용자)에 따라 적용 여부를 분기하는 게 더 좋은 방향이다. 이번엔 compliance detail이라는 명확한 내부용 화면에서만 제거했으니, 범위는 잘 잡혔다고 본다.

작게 보이는 커밋의 결정들

변경 통계가 미지정이라 라인 수는 알 수 없지만, 파일 세 개를 건드린 이 커밋은 실제 동작 범위 대비 겉으로 드러나는 코드 양이 적은 편이다. 이런 작업일수록 코드 리뷰 때 놓치기 쉬운 부분들이 있다.

• 이력 테이블 DDL이 선행되어 있는지
• 트랜잭션 경계가 의도대로 동작하는지 (이력 적재 실패가 로그인 자체를 막으면 안 됨)
• vbank_num 필터 제거가 다른 화면에는 영향을 주지 않는지

팀원들에게 리뷰 요청할 때 이 세 가지를 체크리스트로 같이 공유했다. 작은 변경일수록 "왜 이걸 건드렸는지" 컨텍스트를 코드 외부에서 전달하는 게 중요하다고 생각한다. 커밋 메시지만으로는 그 맥락이 다 담기지 않으니까.

다음엔 로그인 실패 이력도 같이 쌓는 방향으로 확장할 것 같다.