일괄전송(배치전송) 사라지길 기원하며 - 들어가기 전

아주 머나먼 옛 시절, 1990년대. 인터넷이 갓 보급되기 시작했을 무렵, 금융 시스템은 지금 우리가 쓰는 멀티 클라우드나 마이크로서비스 따위는 꿈도 못 꾸던, 그야말로 구린 서버에 구린 언어로 굴러가고 있었다. COBOL이 주력이고, 장비는 거의 산업유물급이었다. 그 당시 인터넷 속도는 지금처럼 "광속"과는 거리가 멀었다. 데이터는 귀하디귀했고, 대역폭은 '혈압'처럼 아껴 써야 하는 자원이었다.

 

예를 들어, 은행이 고객 정보를 담은 1MB짜리 파일을 전송하려 한다면? 지금이야 눈도 깜빡이기 전에 전송되겠지만, 그때는 그 1MB 하나가 네트워크를 통째로 마비시킬 수 있었다. 실시간 거래? 당연히 문제가 생긴다. 누군가가 이체하려는 찰나, 뒷단에서 대용량 파일이 씽씽 나가고 있다면? 거래 지연은 물론, 장애까지 직행이다.

 

그래서 등장한 해결책이 바로 "일괄전송(배치전송)"이라는 개념이다. 단순히 파일을 묶어서 한 방에 보내는 게 아니다. 큰 데이터를 작은 단위로 쪼개서, 마치 온라인 거래처럼 한 건 한 건씩 전송하고, 나중에 다시 서버 측에서 조립하는 방식이다.

이 기술은 당시로서는 혁신적이었다. “와... 이걸 생각해낸 사람은 천재다”란 말이 자연스럽게 나왔고, 우후죽순 은행들이 이 방식을 도입하기 시작했다. 다만 문제는 각 은행이 자기 입맛대로 프로토콜을 정의했다는 것. 말이 프로토콜이지, 지금 보면 ‘자기만의 룰북’에 가까운 포맷들이다.

 

그 결과, 2025년 오늘날까지도 여전히 살아남아 현역으로 뛰고 있는 수많은 각양각색 배치 프로토콜들이 존재한다. 그리고 우리는 그 프로토콜을 해석하고, 포맷 맞추고, 트랜잭션을 붙잡느라... 매일을 보내고 있는 것이다.

 

금융업에 처음 들어와서 일괄전송이라는 단어를 처음 접한 신입이라면, 아마도 이렇게 생각할지도 모른다.
“뭐지…? 왜 파일을 이렇게 보내지? 그냥 HTTP나 FTP로 전송하면 되는 거 아닌가요?” ...나도 그랬다.

그 의문은 아주 자연스러운 반응이다. 그리고 바로 그런 분들을 위해, 또 언젠가 이 일괄전송(배치전송)이라는 구시대의 유물이 역사 속으로 사라지길 기원하는 마음을 담아, 일괄전송 글을 써보려 한다.

 

잘 오셨습니다, 종사자 여러분.
지옥의 일괄전송 세계에 입장하셨습니다.