국제은행간통신협회(SWIFT) 결제망 아키텍처

SWIFT(Society for Worldwide Interbank Financial Telecommunication)는 전 세계 은행들이 다른 나라에 있는 은행과 금융 거래를 하기 위해 사용하는 메시징 시스템. 벨기에에 본부가 있으며, SWIFT 코드라 불리는 8-11자리 식별자로 송금 은행, 수신 은행을 식별함.

SWIFT 코드는 1975년경 자체적인 형식으로 개발되었으나, 1994년 ISO 9362로 국제 표준이 정의되었음. 이후 두 번 더 개정되어 현재 사용되고 있는 것은 2014년판. 구체적인 형식은 에스토니아의 핀테크 기업인 Wise (구 Transferwise)가 제공하고 있는 아래 페이지에서 볼 수 있음:

https://wise.com/gb/swift-codes/bic-swift-code-checker

맨 앞의 4자리는 은행. 다음 2자리는 국가. 다음 2자리는 지역. 그리고 마지막으로 선택 사항인 3자리 지점. 예를 들어서 SWIFT 코드가 'SMCOGB2LXXX' 라면, 영국(GB)에 있는 SMCO 은행 2L 지역 XXX 지점을 가리킴. 기본적으로 은행에 부여되는 것이지만, 가장 많은 수요가 송금 수요인 만큼 국가간에 돈을 주고받을 일이 많은 다국적 대기업들도 SWIFT 코드를 발급받아서 사용하는 경우가 많음 - 거꾸로 이야기하자면 SWIFT 결제망에서 퇴출되면 금융 거래에 타격을 입음. 이란과 북한의 경우 당연히(?) SWIFT에 접근이 불가능함.

이 글은 『가상 면접 사례로 배우는 대규모 시스템 설계 기초 (System Design Interview)』의 저자인 알렉스 쉬가 설명한 SWIFT 시스템의 기술적인 구조.

1. 돈을 주고받는 당사자인 Bank, Bank로부터 요청을 받아 처리하는 Regional Processor(RP), RP로부터 요청을 받아 송금 관련 기록을 저장하는 Slice Processor(SP)가 있음. 편의상 A쪽 Bank/RP/SP와 B쪽 Bank/RP/SP가 있다고 치겠음.
2. Bank(A)가 Bank(B)로 보내는 송금 요청을 RP(A)로 보냄. RP(A)는 요청의 유효성을 검증한 뒤 SP(A)로 요청을 전송. SP(A)는 요청을 저장한 뒤 RP(A)에는 요청이 처리되었다는 응답을, RP(B)에는 송금 요청을 보냄.
3. 응답을 받은 RP(A)는 Bank A에 송금 요청이 접수(ACK) 혹은 거부(NAK)되었다는 응답을 보냄. SP(A)의 요청을 받은 RP(B)는 메시지를 임시로 저장한 뒤 (역자 주: 아마 내부 log 자료구조에 fsync로 저장하는 듯) 메시지에 고유한 번호(MON)를 발급한 뒤 SP(B)에 전달.
4. SP(B)는 MON의 유효성을 검증하고, 인가(authorization) 작업을 수행한 뒤 RP(B)에 "Bank B에 돈을 보내라"는 메시지를 보냄.
5. RP(B)가 Bank B에 메시지를 전달. Bank B는 이를 받아서 저장한 뒤 실제로 돈을 지급하고, 성공 여부(UAK/UNK)를 RP(B)에 전달.
6. RP(B)는 송금 결과 report를 생성해서 SP(B)에 전달. SP(B)는 이를 저장한 뒤 SP(A)에 사본을 전달. SP(A)는 이를 다시 저장.

1975년경 만들어진 시스템이지만, 현대 Event-driven microservice의 요소가 전부 들어가 있음. SP는 메시지 형태로 송금 요청과 결과 report를 저장하고, RP는 SP를 사용해서 Bank의 요청에 대한 서비스를 제공함. RP는 Bank의 송금 요청을 받거나, 자기가 맡은 구역에 들어 온 송금 요청을 역시 자기가 맡은 구역의 Bank에 요청하는 역할만 함. 결과적으로 모든 송금 관련 요청은 보낸 쪽 SP와 받는 쪽 SP에, 요청과 처리 결과가 하나씩 저장되게 됨. Bank 입장에서는 SP가 전혀 보이지 않음.