개발 slecs

예금주명 검증으로 계좌 인증 정확도 강화

목차

계좌 인증은 결제 시스템의 핵심 신뢰 포인트다. 특히 B2B나 정산 플랫폼에서는 계좌 이체 시 송금처와 수취처가 일치하는지 확인하는 게 중요한데, 기존엔 계좌번호 자체만 검증하고 소유주(예금주명)는 별도 확인 없이 진행해왔다. 이번에 그 부분을 보강하고 동시에 구식 1원인증 방식의 UI 잔재도 정리했다.

예금주명 검증이 필요했던 이유

계좌번호만으로는 실제 그 계좌의 주인이 맞는지 보장할 수 없다. 특히 다음과 같은 시나리오를 생각해보면 명확해진다:

  • 사용자가 계좌번호를 입력할 때 한 자리 틀리거나 타사 동명이인 계좌를 등록하는 경우
  • 정산 대상자의 계좌가 바뀌었는데 시스템에 반영 안 된 경우
  • 리스크: 돈이 엉뚱한 사람 계좌로 가거나, 나중에 분쟁 발생

금융 기관의 실명계좌 조회 API를 통해 계좌번호로부터 예금주명을 받아올 수 있는데, 사용자가 입력한 예금주명과 실제 계좌의 예금주명을 대조하면 한 단계 더 안전해진다. 특히 한글 오타 (예: "이준호" vs "이준호"), 띄어쓰기, 괄호(애칭) 처리 등을 고려하면 정확한 검증 로직이 필요하다.

작업 내용: 검증 로직 추가와 레거시 정리

변경 영역 내용
Java 비즈니스 로직 예금주명 대조 검증 메서드 추가, 기존 계좌번호 유효성만 확인하던 부분 확장
JSP 화면 1원인증 관련 안내 문구 제거, 현행 인증 방식(예금주명 검증)으로 통일

계좌 인증 흐름은 이렇게 변했다:

Before:

사용자 입력(계좌, 예금주명) 
→ 계좌번호 형식 체크만 수행 
→ 등록 완료

After:

사용자 입력(계좌, 예금주명)
→ 계좌번호 형식 체크
→ 금융사 API로 계좌 조회
→ 예금주명 일치 여부 대조
→ 불일치 시 사용자에게 재확인 요청
→ 등록 완료

한편 1원인증은 과거에 계좌 소유권을 검증하는 방식이었지만(실제로 1원을 이체해서 수령하는지 확인), 요즘엔 더 간편한 API 기반 검증으로 전환된 상태였다. 그런데도 화면과 코드 곳곳에 1원인증 관련 문구가 남아있어 사용자 혼동을 유발할 수 있었다. 이번 작업에서 그런 잔재들을 정리했다.

회고: 작은 개선의 누적과 기술 부채 정리

이런 작업이 흥미로운 이유는 두 가지다.

첫 번째, 검증 로직 강화의 심리 원칙. 시스템이 "엄격한" 게 항상 좋은 건 아니지만, 돈이 오가는 영역에선 한 번의 실수 비용이 크다. 계좌명 검증이 한 두 건 추가 확인만 늘리더라도, 그로 인해 방지되는 송금 오류는 카스터머 신뢰로 돌아온다. 각 기능팀에서 "이 정도면 충분한가?"를 자문하는 태도가 중요하다.

두 번째, 레거시 제거의 타이밍. 1원인증 문구는 금주 중심으로만 봐서는 "제거할 게 어디 있나" 싶을 수 있지만, 누적되면 다음 사람이 유지보수할 때 혼란을 준다. "이 옛날 방식은 아직 쓰나?"라는 질문이 계속 생기는 것도 인지 부담이다. 작은 정리라도 주기적으로 하면 코드베이스의 "신뢰도"가 올라간다는 걸 느낀다.

팀 입장에서 이 PR은 크지 않은 작업이지만, 지금까지 인증 부분에서 예금주명을 왜 안 봤는지, 1원인증은 언제부터 쓰지 않았는데 왜 아직 남아있었는지 묵직하게 생각해볼 계기가 됐다.


🛒 이 글과 어울리는 추천 상품

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.

댓글 0

첫 댓글 달아줘.