전통적인 은행의 소켓 통신방식 소개

전통적인 은행의 소켓 통신방식 소개

안녕하세요? 케이뱅크에서 대외기관 인터페이스 업무를 담당하고 있는 오현철입니다. 오늘은 은행에서 사용하는 아주 낡은 기술에 대한 이야기를 나누는 자리를 가져보고자합니다. 아직도 금융기관에서 활발히 사용중인 독특한 통신방식에 대해 그 배경과 장단점을 소개하고 문제점을 해결하는 방법에 대해 이야기해보겠습니다.

 

일반적인 TCP 소켓통신

요즘은 http프로토콜을 활용한 api통신이 주류를 이루고 restful api 방식이 보편화 되어가는 시대입니다. 그러나 전자금융의 근간이되는 금융공동망 거래는 아직 TCP 방식과 같은 한 세대 이전의 고전적인 통신방식을 고수하고 있습니다. 일반적인 TCP통신방식은 아래와 같이 설명할 수 있습니다. 예시를 한번 보시죠.

(상황) 철수와 영희는 같은 공간에서 서로 눈을가리고 정보를 주고받습니다.

• 먼저 철수가 말합니다. “영희야 안녕?(SYN)”
• 이어 영희가 대답을 하죠. “응! 철수야 안녕?(SYN-ACK)”
• 그리고 이어 철수가 대답합니다. “응! 안녕!(ACK)”

상대방이 거절하는 경우도 있습니다(RST)

이것은 우리가 잘알고 있는 TCP 연결의 기본 방식인 “3 way handshake” 방식을 수행한 것입니다. 여전히 서로는 눈을 가리고 있어서 상대방이 어떤 상태인지 알수가 없지만 목소리로 주고 받았던 연결절차를 믿고(EASTABLISHED) 서로 대화를 시작합니다.

• “영희 오늘 점심 뭐먹었어?(PSH)”
• “응, 상하이스파이시 버거먹었어(ACK, PSH)”
• “응(ACK)”.

정상적으로 정보가 교환되었고 이제 연결을 종료합니다.

• “잘있어(FIN)”
• “응!(FIN-ACK)”, “너도 잘있어(FIN)”
• “응!(FIN-ACK)”

이렇게 4-way handshake로 종료까지 완벽하게 수행하였습니다. 일반적인 방식은 이렇게 하나의 질문을 보내고 답변을 받기 위해서

• (연결)-(질문)-(답변)-(종료)

의 절차를 수행하게 되고, 이러한 절차는 매 요청마다 반복적으로 발생합니다. 여기까지는 특이점이 없습니다.

정상적인 요청과 응답과정

 

전용회선이라는 제약사항

금융결제원 통신방식은 이런 기본적인 TCP 통신방식을 약간 변형합니다. 연결절차와 종료절차를 생략해 버립니다. 연결과정은 딱 한 번만 수행하고 질문과 답변을 반복적으로 수행하는 거죠.

• (연결)-(질문1)-(답변1)-(질문2)-(답변2)-…..

매 요청마다 연결과 종료를 위해 커뮤니케이션 하는 활동들도 전용회선 환경에서는 부하가 될수 있다고 생각했던 모양입니다. 그래서 연결은 단 한차례만 수행한 채 데이터만 지속적으로 주고 받습니다. 특별한 일이 없는 한 연결을 종료하지 않습니다.

게다가 데이터 포맷도 메타정보가 많이 포함되는 xml이나 json을 사용하지 않고 약속된 길이의 value만 전송하는 fixed length 방식을 사용합니다. 이런 특이한 방식을 사용하는 이유는 아마도 매월 구독비용을 내야만하는 전용회선의 대역폭이 사내망처럼 대역폭이 그리 넉넉하지 않은 까닭이라 추측해봅니다.

전용회선 인프라를 제공하는 국내 통신3사

이런 방식은 꽤나 장점이 큽니다. 연결과 종료 과정이 생략된 채로 데이터만 주고 받기 때문에 굉장히 빠릅니다. 그리고 꼭 필요한 데이터만을 전송하기 때문에 전송효율이 매우 좋습니다. 이런 특징은 대량거래에 매우 적합한 방식입니다. 시중은행 하나의 금융결제원 거래량이 하루 약 3~5천만건 정도라고 하니 공동망에 참가하는 금융기관 전체를 놓고 본다면 납득할만 합니다. 이런 통신방식은 적은 대역폭을 가지고 최대의 처리량을 뽑아 낼 수 있는 이른바 가성비의 절정이라 말씀드릴 수 있습니다.

철수와 영희는 이렇게 (연결절차)와 (종료절차)를 생략하기로 약속하고 최초 한 번만 연결한 뒤에 질문과 답변을 반복적으로 이어갑니다. 그러나 이러한 통신 설계는 아래와 같이 몇가지 문제점이 생깁니다.

 

문제점과 해결방법

① 좀비세션

너 거기에 있고 나 여기에 있어

(상황) 갑자기 근처에서 돌이 날아와 영희를 때리고(!) 이내 영희는 쓰러집니다. 작별 인사절차도 없이 기절했습니다. 눈을 가리고 있던 철수는 여전히 상대가 살아있다고 믿고(EASTBLISHED) 데이터를 요청하고 그 응답을 기다리지만 상대방은 반응은 싸늘합니다. 이 상태를 전문용어(?)로 좀비라고 합니다. 철수는 이런 좀비 상태를 스스로 벗어날 수 없습니다. (종료절차)를 수행해야 하는데 자신은 종료조건이 아니며, 상대방은 종료를 할 수 없기에 결국 철수는 서비스 불능상태가 됩니다.

(해결) 이런 상태를 능동적으로 벗어나기 위한 여러가지 활동들이 있습니다. OS 단에서 제공하는 네트워크 옵션을 활용하는 방안(keep_alive)이 있습니다. 상대방과 데이터가 없는 상태가 몇 분동안 지속되면 헬스체크 패킷을 보내봅니다. 응답이 안올경우 몇차례 더 시도해본뒤 상대방 상태가 이상하다고 감지되면 AP에게 RST과 같은 시그널을 주는 방식이죠.

그러나 각 금융사의 서버환경은 같지 않기 때문에 아예 업무 전문 설계시 적당한 시간마다 주기적으로 “너 거기에 있어?” 라고 물어보는 ‘테스트콜’거래를 만들어 활용하는 경우가 있습니다. 주기적으로 테스트콜 전문을 발생시켜서 응답이 없는 경우 초기화 절차를 수행하도록 하여 서비스 불능상태를 막아보고자 하는 것이죠.

 

② 데이터의 시작과 끝

투머치토커

(상황) 이번 상황은 철수가 할 말이 너무 많은 상황입니다. “제가 LA에 처음갔을때 … 1990년 고딩2때 청주에서 전국체전이 열렸어요. 그리고 주간야구라는 당시에 유일했던 야구잡지사에서 글을쓰는 기자 분이 그라운드 안에서 내게 인사를 건냈죠… ” 영희는 듣자듣자 하니 어디까지가 요청의 끝인지를 알수가 없습니다. 비슷한 문제가 무전기를 사용하는 환경에서도 발생하는데 이런 문제를 해결하기 위해 워키토키(무전)에서는 아래와 같은 방식을 약속해서 데이터의 끝을 구분 짓기도 합니다. 예를 들면,

근무시간 농땡이는 참을 수 없지

• 빅보스 스피킹, 이쁜이 나와라 ‘오바’
• 이쁜이 나왔다, 무슨일인가? ‘오바’

여기서 ‘오바’가 바로 그런 데이터의 끝을 알려주는 역할을 수행합니다. TCP 어플리케이션 환경에서도 이러한 ‘딜리미터 방식’을 사용하기도 했습니다. 그런데 가끔 그 ‘오바’도 데이터로 활용 되어야하는 상황이 생기고 이런 문제들 때문에 지금은 잘 사용하지 않습니다. 지금은 다음과 같은 방식을 사용하고 있습니다.

말을 시작할때 내가 몇 글자를 말할건지 먼저 이야기 하기로 서로 약속합니다.

• 0005밥은먹었니
• 0005네먹었어요
• 0015야구는언제부터시작하게된건가요
• 8374제가LA에있을때…(이하생략)

이런식으로요. 상대망이 얼마나 말할지 예측이 되고 아주 효율적입니다. 그렇지만 프로그램 문제로 인해 0005를 말하고 네 글자만 말하는 경우 문제가 생깁니다.

• 0005밥먹었니

처럼 말이죠. 영희는 나머지 1글자가 도착할때까지 그대로 대기합니다(PENDDING). 결국 철수는 영희의 응답을 받지못해 답답해하며 요청을 포기하고(TIMEOUT) 다음 질문을 던지게 되지만,

• 0008영희야밥먹었냐고

영희는 다음질문의 첫번째글자인 ‘0’을 이전데이터의 마지막 데이터로 취급해 버리게 됩니다. 결국 첫번째 요청은 철수가 포기한 요청에 대한 처리가 되고, 두번째 요청은 길이부에 오류(008영)가 나면서 요청 자체를 읽지 못하는 경우가 생기기 됩니다.

(해결) 잘만들어진 프로그램에서는 이런경우가 발생하기 드물지만 간혹 처리할 수 있는 인코딩 범위를 벗어나는 한글이 주입되는 경우 발생할 수 있습니다. 프로그램의 언어에 따라 이런 인코딩오류에 대한 처리방식이 서로 달라 길이가 어긋나는 경우가 생기는겁니다.

여럿 개발자를 고통받게 한 그 아파트 네이밍

• 더샾아파트(MS949) → 더?아파트(KSC5601)
• 똠방각하(MS949) → ?방각하(KSC5601)

실제로 실무에서 이런 케이스로 인해 길이 계산에 오류가 발생하는 케이스가 종종 발생합니다. 길이는 최종 송신직전에 매번 계산하도록 프로그램하고, 취급할 수 있는 한글의 범위를 미리 약속해두는것이 좋습니다(인코딩).

 

③ 이중화 문제

(상황) 아까처럼 영희가 돌을 맞고 쓰러져도 철수의 서비스는 계속 되어야 합니다. 그래서 영희의 복제인간인 영희2 를 구성합니다. 영희 1과 영희2가 동시에 서비스를 제공하기 때문에 이제 영희1이 쓰러지더라도 영희2가 응답을 처리해줄 겁니다. 그렇게 하기 위해서 영희1과 영희2를 대표할 수 있는 영희대표(L4)가 하나 필요합니다. 이 대표는 영희 1과 영희2 각각에게 공평하게 요청을 나누어줄 것입니다. 그러기 위해서 최초에 언급했던 (연결)-(요청)-(응답)-(종료) 사이클을 봤을때 (연결절차) 단위로 요청을 나누어 주면 됩니다.

그러나 금융공동망 연계 환경에서는 (문제점) 부분에서 다루었던 것처럼 (연결절차)와 (종료절차)가 생략되어 있기 때문에 이 영희대표는 작업을 분배할 수 없고 최초 연결이 성사되었던 그 영희1만(또는 영희2만)이 모든 요청을 처리할 수 밖에 없게 됩니다. 영희2를 만들었지만 결국 철수는 영희1하고만 대화를 하게되고 상황은 이전과 크게 다르지 않습니다.

• 철수 → 영희1 : (연결)-(요청1)-(응답1)-(요청2)-…
• ⠀⠀⠀⠀ 영희2 : Zzz…

영희2가 자연스럽게 왕따가 되는 과정

(해결) 이런 경우 철수도 두 명을 만들면 되긴합니다. 철수1이 영희1에게 요청하고 철수2가 영희2에게 요청하면 어느정도 부하 분산이 가능합니다. 그렇지만 동적인 유량제어를 기대하고 도입했던 영희대표(L4)의 역할이 이런 통신방식에선 좀 의미가 작습니다. 실무에서는 각 금융사의 운영 방침에 따라 영희2를 벤치에 대기시켜놓고 영희1에게서 문제가 생기면 영희2를 교체 투입하는 형태로 운영하는 경우도 많이 있습니다.

 

마무리

이렇게 금융결제원 기반의 전통적인 은행의 통신방식을 아주 가볍게 소개해 봤습니다. 연결을 한 번 맺어놓고 끊지 않는 이러한 독특한 방식으로 인해 어플리케이션 개발자들이 은행과 연계시 기술적인 어려움을 호소하기도 합니다. 지금은 전용회선 기술도 좋아져 예전처럼 알뜰하게(?) 쓰는것 만이 능사가 아닌 시대가 됐습니다. 때문에 굳이 이런 불편한 기술을 사용하지 않아도 됩니다만 국내 금융공동망 설계전환 자체가 적지 않은 비용을 치러야하는 국가차원의 일이기 때문에 쉽게 그 기술이 없어지지 않는것 같습니다.

마이데이터의 목적

그래도 이미 오픈뱅킹과 마이데이터 업무를 통해 경험했듯이 많은 핀테크 업체가 금융공동망에 손쉽게 참여할 수 있는 새로운 환경이 준비되었고 고객은 이런 채널을 통해 새로운 금융 서비스를 경험할 수 있게 되었습니다. 이런 새로운 트렌드의 금융서비스 역시 기존 금융공동망의 안정성을 기반으로 탄생할 수 있었던게 아닐까 생각해봅니다.