입금자명 파싱 다단계 분류와 정산 계좌 조회 엔드포인트 분리

입금자명 파싱, 정규식 한 줄로는 안 됨

문자 메시지에서 입금자명 뽑는 로직 손봤음. 처음엔 정규식 한 줄로 끝낼 수 있을 줄 알았는데, 실제 데이터 까보니 케이스가 너무 많았음.

• 은행마다 메시지 포맷이 다름 (콜론 위치, 줄바꿈, 특수문자)
• 영문/한글 이름 혼합
• 법인명 뒤에 담당자명 붙는 케이스 ((주)○○ 홍길동)
• 광고 문구가 본문에 끼어드는 메시지

기존엔 단일 패턴으로 모든 메시지 처리하다 보니 매칭 실패율이 꽤 높았음. 메시지 종류를 먼저 분류하고, 분류별로 다른 추출 규칙을 태우는 식으로 바꿈.

INPUT  : "[Web발신] ○○은행 입금 100,000 홍길동 잔액..."
STEP 1 : 메시지 타입 판별 (입금/출금/광고)
STEP 2 : 발신처별 토큰 위치 매핑
STEP 3 : 이름 후보 정규화 (공백/특수문자 제거)
OUTPUT : "홍길동"

폴백 패턴도 하나 둠. 분류 실패해도 최소한 숫자/금액 토큰 제외한 한글 토큰을 후보로 잡도록.

파트너 은행 정보 조회 엔드포인트 분리

파트너가 등록한 정산 계좌 정보를 다른 모듈에서 가져갈 일이 많아져서, 별도 조회 엔드포인트로 뺐음. 기존엔 파트너 상세 응답에 통째로 묶여 내려갔는데, 은행 정보만 필요한 호출에서도 큰 페이로드를 받아야 해서 비효율적이었음.

권한 체크는 따로 분리함. 내부 호출 경로와 사용자 호출 경로 섞이기 시작하면 나중에 권한 사고 나기 딱 좋음.

사이드 작업 — 푸터 정렬, 스토어 스타일

작업 중 눈에 들어온 푸터 정렬 깨짐과 스토어 페이지 스타일 보정도 같이 묶어 처리. 원래 별 커밋으로 빼고 싶었는데, 같은 페이지에서 발견한 거라 한 PR로 묶는 게 리뷰어 입장에서 편함. 분리해야 할 만큼 크지도 않았음.

회고

• 파싱 로직은 "한 정규식으로 끝낸다"는 욕심부터 버려야 함. 입력 다양성을 먼저 인정하고 분류 단계를 두는 게 나았음.
• API 응답을 풀로 내려주는 습관은 호출자가 늘기 시작하면 빠르게 비용으로 돌아옴. 처음부터 좁게 짜는 쪽이 옳았음.
• UI 자잘한 깨짐은 발견 즉시 같이 처리. 별 티켓으로 빼면 영원히 안 고침.

다음