입금 확인을 자동화하려면 먼저 은행 파일을 읽어야 합니다. 그리고 여기가 첫 난관입니다. 은행 입출금 내역 파일은 표준이 없습니다. 은행마다 컬럼 구성이 다르고, 같은 은행도 인터넷뱅킹과 앱의 내려받기 양식이 다르며, 상단에 계좌 정보 블록이 붙어 헤더 위치도 제각각입니다. 공동구매 주문 도구의 입금 확인 기능을 만들며 정리한 입출금 내역 파싱의 실무 설계입니다.
입출금 내역의 헤더는 내용으로 찾는다
은행 파일의 전형적인 구조는 이렇습니다. 상단 몇 행에 계좌번호·조회 기간 같은 요약 정보, 그 아래 어딘가에 컬럼 헤더 행, 그리고 데이터 행들. 문제는 요약 블록의 높이가 은행과 양식마다 달라 "몇 번째 행이 헤더"라고 못 박을 수 없다는 점입니다.
해법은 헤더를 내용으로 찾는 것입니다. 우리는 "순번", "거래일시" 같은 헤더 특유의 문구가 함께 나타나는 행을 상단에서 탐색해 헤더로 확정하고 그 아래부터를 데이터로 읽었습니다. 이 방식이면 요약 블록이 몇 행이든, 은행이 어디든 같은 코드로 읽힙니다. 유동적인 헤더 위치를 텍스트 탐색으로 잡는 이 기법은 광고 정산 파일에서도 똑같이 유효했습니다(매체별 정산서 양식 차이).
값의 정규화: 금액, 날짜, 그리고 이름
헤더를 잡았으면 값을 표준화할 차례입니다.
- 금액: "143,000"처럼 콤마가 섞인 문자열을 숫자로 바꿉니다. 빈 값과 기호는 0으로 처리하고, 입금·출금이 별도 컬럼인 양식과 부호로 구분되는 양식을 모두 흡수합니다.
- 날짜: "2026-01-08 14:22", "26.01.08"처럼 형식이 섞여 들어와 여러 포맷을 순차 시도하는 파서로 정규화합니다.
- 입금자명: 매칭의 핵심 필드입니다. 은행 양식에서 이 값이 담기는 컬럼("거래기록사항", "내용", "적요")이 제각각이라 컬럼 매핑에 포함해 뽑아냅니다. 고객들이 여기에 "니니-딸기"처럼 주문 힌트를 붙이는 관행이 있어, 원문을 자르지 않고 그대로 보존하는 것이 뒤 단계(매칭)에 중요합니다.
정규화 규칙은 파서 한곳에 모읍니다. 새 은행 양식이 나타나면 규칙 한 곳을 보강하면 되고 매칭·집계 같은 뒤 단계는 표준화된 값만 다루므로 영향이 없습니다.
입금만 남기기, 그리고 중복 막기
입금 확인 용도라면 두 가지 선별이 더 필요합니다.
첫째, 입출금이 섞인 내역에서 입금 행만 남깁니다. 금액이 양수인 행, 또는 입금 컬럼에 값이 있는 행이라는 규칙으로 거릅니다. 출금 행이 섞여 들어가면 매칭 후보만 늘어납니다.
둘째, 중복 유입의 차단입니다. 은행 내역은 "이번 주 것"을 받는다는 것이 기간을 겹치게 받기 마련이라 같은 입금 건이 여러 파일에 등장합니다. 우리는 거래일시·금액·입금자명 조합을 동일성 기준으로 삼아 이미 등록된 건은 저장 단계에서 걸렀습니다. 파일을 몇 번을 겹쳐 올려도 입금 건은 한 번만 존재합니다. 이 재유입 안전장치의 일반 원리는 재수집 중복 방지 설계에서 다룹니다.
| 파싱 단계 | 처리 | 흡수하는 다양성 |
|---|---|---|
| 헤더 탐지 | 특유 문구로 행 탐색 | 은행 · 양식별 요약 블록 높이 |
| 값 정규화 | 금액 · 날짜 · 이름 표준화 | 표기 형식의 차이 |
| 행 선별 | 입금 행만 통과 | 입출금 혼재 |
| 중복 차단 | 자연 키로 저장 단계 필터 | 기간 겹친 파일 재업로드 |
민감 데이터라는 자각
은행 내역은 개인정보 덩어리입니다. 입금자 실명, 계좌 흔적, 거래 패턴이 들어 있습니다. 파싱 설계와 별개로 취급 원칙이 필요합니다. 데이터는 사용자 로컬에만 두고 외부 전송을 만들지 않기, 화면과 내보내기에서 필요한 필드만 다루기, 그리고 개발·테스트 과정에서 실데이터를 코드 저장소에 넣지 않기입니다. 마지막 항목은 우리 스스로도 돌아보게 된 지점인데, 참조용 샘플 파일의 관리가 허술하면 도구가 아니라 데이터에서 사고가 납니다.
이 파싱이 들어간 도구의 전체 이야기는 카페 댓글 주문 정리 자동화 사례에서, 파싱된 입금이 주문과 만나는 다음 단계는 입금자명 자동 매칭에서 이어집니다.
자주 묻는 질문
은행마다 파일 양식이 다른데 하나의 파서로 읽을 수 있나요?
가능합니다. 헤더를 행 번호가 아니라 특유 문구의 탐색으로 찾고 금액·날짜·입금자명의 표기 차이를 정규화 규칙으로 흡수하면 은행이 달라도 같은 코드로 읽힙니다. 새 양식이 나타나면 규칙 한 곳만 보강하면 됩니다.
같은 내역 파일을 두 번 올리면 어떻게 되나요?
저장 단계의 중복 차단이 있으면 문제없습니다. 거래일시·금액·입금자명 조합으로 동일 건을 판정해 이미 있는 입금은 건너뜁니다. 기간이 겹치게 내려받는 것이 일상인 은행 내역에서는 이 장치가 필수입니다.
입금자명 컬럼이 은행마다 다른데 어떻게 찾나요?
은행별로 입금자명이 담기는 컬럼("내용", "적요", "거래기록사항" 등)을 컬럼 매핑에 등록해 뽑습니다. 이때 값을 가공하지 않고 원문 그대로 보존하는 것이 중요합니다. 송금 메모에 붙는 주문 힌트가 뒤 단계 매칭의 단서가 되기 때문입니다.
은행 내역 데이터는 어떻게 다뤄야 안전한가요?
로컬 보관을 기본으로 하고 외부 전송 경로를 만들지 않는 것이 첫째입니다. 화면·내보내기에는 필요한 필드만 쓰고 개발 과정의 참조 샘플이 코드 저장소에 섞여 들어가지 않도록 관리해야 합니다. 파싱 기술보다 데이터 취급 규율이 사고를 가릅니다.