가상 IBAN이란?
가상 IBAN(vIBAN)은 전용 대역에서 발급되어 하나의 마스터 계좌로 라우팅되는, 실제로 주소 지정이 가능한 국제 은행 계좌번호입니다. 다른 IBAN과 똑같이 입금을 받습니다. 납부자는 자신의 은행에서 일반 SEPA 계좌이체로 송금하면 됩니다. 다만 가상 IBAN 자체에는 잔액이 없습니다. 역할은 식별입니다. 가상 IBAN은 각각 한 명의 납부자 또는 하나의 용도에만 할당되므로, 입금이 들어오는 순간 누가 보냈고 무엇을 위한 돈인지 이미 알 수 있습니다. 자금은 자동으로 마스터 계좌에 모입니다. 가상 IBAN은 입금에 붙는 라벨일 뿐, 돈이 머무는 두 번째 장소가 아닙니다.
납부자마다 IBAN 하나. 이 한 가지 특성이 이 개념의 전부입니다. 왜 글 한 편을 쓸 만한 주제인지 알아보려면, 이것이 없애 주는 문제부터 살펴봐야 합니다.
진짜 문제: 입금과 납부자 매칭
월세, 구독료, 청구서 대금을 하나의 계좌로 계좌이체로 받는 사업자를 떠올려 보세요. 모든 입금이 같은 IBAN으로 들어오고, 누가 냈는지 알려 주는 단서는 납부자가 참조 필드에 적은 내용뿐입니다. 참조는 오타가 나거나, 전달 과정에서 잘리거나, 아예 비어 있기도 합니다. 참조가 깨진 €49.00 이체는 아직 €49.00의 인식된 매출이 아니라 하나의 처리 티켓입니다. 장부를 마감하기 전에 어느 고객의 어느 청구서인지 누군가 찾아내야 합니다.
거래량이 적을 때는 번거로운 정도입니다. 플랫폼 규모가 되면 하나의 부서가 필요해집니다. 매칭 엔진은 금액, 날짜, 유사한 참조 텍스트를 기준으로 후보 청구서에 점수를 매기고, 분류하지 못한 건은 사람이 처리하는 대기열로 넘어갑니다. 게다가 이 실패는 구조적입니다. 두 구독자가 같은 날 같은 금액을 참조 없이 입금하면 어떤 엔진도 둘을 구분할 수 없습니다. 구분에 필요한 정보가 애초에 결제에 담겨 있지 않았기 때문입니다.
납부자마다 IBAN 하나: 구조로 확보하는 식별
가상 IBAN 프로그램은 설계를 뒤집습니다. 모든 납부자에게 결제 내용을 정확히 적어 달라고 요청하는 대신, 모든 납부자에게 고유한 주소를 줍니다. 세입자, 구독자, 마켓플레이스 판매자 각각이 자신만의 IBAN으로 입금합니다. 참조 필드가 틀리거나, 비어 있거나, 다른 문자로 쓰여 있어도 입금은 스스로 신원을 밝힙니다. 신원을 계좌번호가 담고 있기 때문입니다.
계좌번호는 참조보다 훨씬 나은 신원 전달 수단입니다. IBAN에는 체크 디지트가 포함되어 있어, 잘못 입력한 IBAN은 이체가 실행되기 전에 납부자의 은행에서 검증 단계에 걸러집니다. 잘못 입력한 참조는 그대로 통과해 결국 여러분의 문제가 됩니다. 신원을 자유 입력 필드에서 주소로 옮기면, 오류 검사가 여러분의 백오피스에서 송금 은행으로 옮겨 갑니다.
납부자에게는 달라지는 것이 없습니다. 늘 하던 대로 뱅킹 앱에서 IBAN으로 송금하면 됩니다. 달라지는 쪽은 수취 측입니다. 입금에 이미 라벨이 붙어 도착하고, 참조 필드는 본래 있어야 할 자리인 메모로 돌아갑니다. 더 이상 식별 시스템이 아닙니다.
모든 납부자가 자신의 IBAN으로 입금하면, 들어온 입금이 의미할 수 있는 것은 단 하나입니다. 매칭 문제는 해결되는 것이 아니라 존재하지 않게 됩니다.
자금이 실제로 머무는 곳
내부적으로는 통화당 마스터 계좌가 정확히 하나입니다. 가상 IBAN은 프로그램 전용 대역에서 발급되며, 어느 가상 IBAN으로 보낸 입금이든 마스터 계좌로 정산됩니다. 관리해야 할 납부자별 잔액도 없고, 수천 개의 소규모 계좌에서 한 곳으로 자금을 옮기는 일일 스윕 작업도 없습니다. 자금 집중은 추가 이체가 아니라 라우팅으로 이뤄지므로, 그 추가 이체를 다시 대사할 필요도 없습니다.
이 점 때문에 가상 IBAN은 꼼수가 아닌 실제 수단이 됩니다. 어느 은행에서든 주소 지정이 가능하고, 일반 SEPA 입금처럼 청산되며, 납부자의 명세서에도 자신이 송금한 계좌로 표시됩니다. 없는 것은 일반 계좌에 딸려 오는 부담, 즉 자체 잔액과 할당·폐기를 넘어서는 수명 주기뿐입니다.
가상 IBAN이 아닌 것
가상 IBAN은 하위 계좌가 아닙니다. 하위 계좌는 잔액을 보유하고, 자금 충전과 회수가 필요하며, 운영해야 할 원장도 늘어납니다. 가상 참조번호도 아닙니다. 가상 참조번호는 여전히 참조 필드에 의존하고, 납부자가 문자열을 정확히 옮겨 적어야 합니다. 지갑도 아닙니다. vIBAN 자체에는 아무것도 저장되지 않습니다. 가상 IBAN은 라우팅이 뒷받침되는 주소이며, 들어오는 입금이 스스로 신원을 밝히게 하는 가장 좁은 구조입니다.
반환은 사유와 함께 돌아옵니다
결제는 들어오기만 하지 않습니다. 계좌가 해지되고, 은행이 입금을 거절하고, 납부자가 이체를 회수하기도 합니다. 수금 계좌가 하나뿐인 환경에서 반환은 작은 조사 작업입니다. 어떤 결제가 돌아왔는지, 누구의 결제였는지, 매칭된 원장 항목을 되돌려야 하는지 확인해야 합니다.
vIBAN 프로그램에서 반환은 데이터입니다. 사유 코드가 함께 오고, 원래 입금에 사용된 같은 가상 IBAN에 payment.returned 이벤트로 기록되며, 명세서에도 별도 건수로 집계됩니다. 티켓이 열리기 전에 누구의 결제가 왜 돌아왔는지 알 수 있습니다. 반환은 뒤쫓아야 할 미스터리가 아니라 처리할 행이 됩니다.
매칭 팀이 아닌 예외 대기열
어떤 설계도 무엇이든 100퍼센트 대사하지는 못합니다. 폐기된 vIBAN으로 입금이 들어오기도 하고, 중복 입금도 생기며, 누군가는 어떻게든 마스터 계좌로 직접 송금합니다. 목표는 예외를 불가능하게 만드는 것이 아니라 드물고 셀 수 있게 만드는 것입니다. Protocore vIBAN 데모에서는 입금의 99.6%가 자동으로 대사되고, 나머지는 납부자의 전체 이력이 첨부된 채 검토 대기열에 쌓입니다. 예외 처리가 은행 명세서와 스프레드시트가 아니라 맥락에서 시작되는 것입니다.
이 차이는 팀의 모습을 바꿉니다. 매칭 업무는 결제량에 비례해 늘어납니다. 입금이 늘면 미매칭 입금도 늘고, 사람도 더 필요합니다. 예외 처리는 예외의 양에 비례하고, 그 양은 설계 단계에서 이미 0에 가깝게 줄어 있습니다. 남은 인력은 다시 입력한 참조가 아니라 진짜 이상 징후를 다룹니다. 저희 스택에서 이 대기열은 운영 콘솔인 Protocore Center(/products/center)에 있으며, 모든 권한 작업에는 사유가 필요하고 감사 로그에 기록됩니다.
대량 발급, 용도 태그, 플랫폼
납부자마다 IBAN 하나라는 방식은 발급 비용이 들지 않아야 성립합니다. 세입자가 열두 명인 임대인은 vIBAN을 수작업으로 만들 수 있지만, 수천 명의 판매자를 온보딩하는 마켓플레이스는 그럴 수 없습니다. 그래서 발급은 대량 작업으로 이뤄집니다. vIBAN 데모에서는 납부자 2,400명의 CSV를 검증하고, 모든 행에 IBAN을 미리 보여 준 뒤, 한 번의 작업으로 발급합니다. 납부자 2,400명, 작업 한 번, 그 사이의 검토 단계 하나입니다.
용도 태그는 주소 수준에서 흐름을 분리합니다. 월세는 여기, 구독료는 저기, 마켓플레이스 정산은 별도 경로로 나뉩니다. 용도별 리포트는 프로젝트가 아니라 필터가 되고, 각 vIBAN은 CSV 또는 PDF 형식의 개별 명세서를 갖습니다. 그 아래에서는 마스터 계좌가 하나뿐인 기준 원장으로 유지됩니다. 납부자가 떠나면 해당 vIBAN은 폐기됩니다. 이력은 남고, 주소는 더 이상 새 입금을 받지 않습니다.
결제 스택에서의 위치
가상 IBAN은 수금 인프라입니다. 카드 결제가 늘 가지고 있던 것, 즉 결제와 별도로 입력하는 것이 아니라 결제 자체에 붙어 있는 신원을 계좌이체에도 제공합니다. Protocore 생태계에서는 Gateway의 계좌이체 결제 주문이 vIBAN 참조를 담고, 매칭 후 남은 예외는 Center에서 처리합니다. /products/viban의 제품 페이지에서는 이 글과 같은 데모 데이터로 발급, 공유, 매칭, 예외 처리, 리포트까지 전체 흐름을 볼 수 있습니다.
솔직한 한계도 짚어 둡니다. 한 달에 몇 건만 이체를 받는다면 참조 규칙과 10분 정도의 장부 정리로 충분합니다. 가상 IBAN이 제 몫을 하는 곳은 거래량 때문에 매칭이 하나의 업무 프로세스가 된 환경입니다. 임대 관리, 구독 수금, 마켓플레이스처럼 누가 입금했는지를 한 달에 수천 번 묻는 곳입니다.