보이스피싱 예방 로직 리팩토링으로 운영 안정성 개선

보이스피싱 예방 확인 로직은 금융·통신 서비스에서 꽤 민감한 영역이다. 사용자 행동을 가로채서 "이 거래 진짜 맞냐"고 묻는 흐름인데, 로직이 잘못 작동하면 정상 거래를 막거나 반대로 의심 거래를 그냥 통과시키는 사고가 날 수 있다. 그런 코드일수록 기능보다 가독성이 중요하다. 버그가 숨기 딱 좋은 구조로 방치되면, 나중에 수정할 때마다 긴장하면서 들여다보게 된다.

이번 작업은 기능 변경 없이 코드를 정리하는 리팩토링이었다. mainLayout 공통화도 함께 진행했고, 작업 규모 자체는 크지 않았지만 건드려야 할 포인트가 여러 군데 흩어져 있었다.

뭘 바꿨나

크게 네 가지였다.

• 중복 코드 제거 및 공통 메서드 추출
• 로그 레벨 정리 - 불필요하게 INFO로 찍히던 것들을 DEBUG로 내림
• 하드코딩 제거 및 상수화
• 메서드 네이밍 개선

그 중에서 가장 티가 나는 건 매직 스트링 제거였다. 코드 곳곳에 "ACTIVE" 같은 문자열이 직접 박혀 있으면, 오타가 나도 컴파일 단계에서 잡히지 않는다. 런타임에 조용히 틀린 분기로 흘러가고, 로그 없으면 추적도 힘들다.

// Before: 매직 스트링 하드코딩
if ("ACTIVE".equals(status)) { ... }

// After: 상수 활용
if (StatusConstants.ACTIVE.equals(status)) { ... }

이렇게 바꾸면 나중에 값이 바뀔 때 상수 하나만 수정하면 된다. 찾아서 교체하다가 하나 빠뜨리는 사고도 없어진다. 당장은 단순해 보이지만 팀 코드베이스가 커질수록 이런 차이가 유지보수 속도에 직접 영향을 준다.

로그 레벨 정리도 생각보다 중요하다. INFO로 박아둔 로그가 운영 환경에서 과도하게 쌓이면 정작 봐야 할 로그가 묻힌다. 보이스피싱 예방 로직처럼 트리거가 자주 걸리는 흐름이면 더 그렇다. 그래서 "이건 디버깅할 때만 필요하다" 싶은 것들은 전부 DEBUG로 내렸다.

테스트 없는 상황에서 리팩토링하는 법

솔직히 이 부분이 제일 부담스럽다. 자동화 테스트가 충분히 있으면 리팩토링 후 테스트 돌려보면 끝이다. 그런데 현실에서는 레거시 코드일수록 테스트가 없다. 보이스피싱 예방 로직도 그랬다.

이럴 때 쓰는 방식은 인풋/아웃풋 케이스를 직접 돌려보는 것이다. 조건 분기마다 전후 결과가 같은지 확인하고, 반환값이 달라지는 경우가 없는지 꼼꼼히 체크한다. 귀찮아도 이 과정을 건너뛰면 "기능은 그대로"라는 전제가 보장이 안 된다.

메서드를 추출하거나 공통화할 때 특히 주의할 점은, 원래 메서드가 암묵적으로 의존하던 상태나 사이드이펙트가 있는지 확인하는 것이다. 단순히 코드를 잘라서 옮겼는데 호출 순서나 컨텍스트가 바뀌면 미묘하게 다르게 동작할 수 있다.

리팩토링을 어떻게 습관으로 만들 것인가

완벽한 리팩토링을 한 번에 하려고 큰 태스크를 따로 잡는 방식은 대부분 안 된다. 일정 압박이 오면 밀리고, 밀리면 결국 안 하게 된다.

현실적으로 동작하는 방식은, 기능 개발이나 버그 수정으로 어차피 손대는 코드 주변을 그때그때 조금씩 정리하는 것이다. "Boy Scout Rule"이라고 부르는 방식인데, 내가 건드린 부분은 들어올 때보다 조금 더 깨끗하게 두고 나간다는 원칙이다. 매번 대규모 리팩토링이 아니라 작은 수정들이 쌓이는 거다.

이번 작업도 그 연장선이었다. 작업 규모가 크지 않아도, 이런 변경들이 누적되면 전체 시스템의 신뢰도가 달라진다. 읽기 어렵고 중복 많은 코드는 기능 추가할 때마다 부담을 준다. 그걸 조금씩 덜어내는 게 운영 안정성에 직접 기여한다고 생각한다.

특히 보이스피싱 예방처럼 민감한 도메인 코드는, 잘못 이해한 채로 수정할 위험이 있어서 가독성이 좋을수록 오히려 더 안전하다. 리팩토링이 기술 부채 청산만의 의미가 아니라 실질적인 안전망이 된다.