IT/일반 IT

해외송금은 어떻게 움직일까?

BBungyaLog 2026. 10. 23. 18:52

SWIFT에서 Finternet까지, 국제 금융 인프라의 변화

금융 데이터를 빠르게 보내는 일과, 돈의 이전을 최종적으로 확정하는 일은 서로 다른 문제다.

 

국내에서는 계좌이체를 하면 몇 초 안에 상대방이 돈을 확인하는 경우가 많다. 그런데 해외송금에서는 수취까지 시간이 걸리고 중간 수수료나 환율 때문에 실제 도착 금액을 이해하기 어려울 때가 있다.

 

인터넷으로 정보는 즉시 전달되는데, 국경을 넘는 돈의 이동은 왜 복잡할까?

국제 금융에서는 메시지 전송 외에도 여러 기관의 장부 갱신, 통화 교환, 유동성 확보, 규제 확인이 연결돼야 한다. 시스템이 서로 연결돼 있다는 사실만으로 이 과정이 모두 동시에 끝나는 것은 아니다.

 

이번 글에서는 SWIFT와 기존 국제 금융의 구조를 살펴본 뒤, Finternet과 토큰화 기반 인프라가 무엇을 바꾸려는지 정리한다.

1. 메시지 vs 청산 vs 결제

해외송금을 이해하려면 ‘송금 처리’라는 표현 안에 여러 단계가 있다는 점부터 알아야 한다.

 

메시지 전달 지급 지시와 관련 정보 교환 누구에게 얼마를 지급하라는 요청인가?
청산(Clearing) 지시 확인, 대사, 결제할 의무 산정 등 각 기관이 무엇을 주고받아야 하는가?
결제(Settlement) 자금 등의 이전으로 의무 이행 실제로 의무가 이행됐는가?
결제완결성(Finality) 이전이 최종적이고 취소 불가능하게 확정 언제부터 최종 결과로 인정하는가?

표는 개념을 단순화한 것이다. 실제 시스템에서는 일부 단계가 통합되거나 서로 다른 방식으로 구현된다.

특히 결제완결성은 화면에 ‘성공’이라고 표시하는 것보다 넓은 개념이다. 시스템의 규칙과 법적 기반까지 연결된다. 금융시장인프라 원칙도 명확한 결제완결성과 법적 근거를 중요하게 다룬다. CPMI-IOSCO 금융시장인프라 원칙

 

따라서 다음 상태는 구분해서 봐야 한다.

요청을 접수했다
      ↓
지급 메시지를 전달했다
      ↓
기관 간 의무가 결제됐다
      ↓
수취인이 자금을 이용할 수 있다

모든 거래가 정확히 이 순서로 진행되는 것은 아니지만 각 상태가 가리키는 대상은 다르다.

2. SWIFT는 국제 금융에서 어떤 역할을 할까?

SWIFT는 은행과 금융기관 등이 금융거래 관련 메시지를 안전하고 표준화된 방식으로 교환하는 네트워크다.

기존 SWIFT 메시징의 중심 역할은 지급 지시와 금융정보를 전달하는 것이다. SWIFT 공식 설명도 실제 자금 이전은 은행 등 관련 기관을 통해 이루어진다고 구분한다. SWIFT 공식 소개

 

가상의 예시로 표현하면 다음과 같다.

한국 기업
   ↓ 지급 요청
한국 은행
   ↓ 금융 메시지 교환
관련 금융기관
   ↓
해외 수취 은행
   ↓
해외 거래처

메시지가 전달되는 동안 관련 기관들은 각자의 계좌와 장부를 갱신하고 필요한 절차를 수행한다. 메시지 경로와 실제 결제 경로가 항상 단순한 일대일 관계인 것도 아니다.

SWIFT는 수취 은행에 지급이 도달한 시점과 최종 고객 계좌에 입금되는 시점 사이에서도 지연이 발생할 수 있다고 설명한다. 따라서 네트워크의 전달 속도와 사용자가 체감하는 전체 소요시간을 구분해야 한다. SWIFT의 지급 처리 설명

이후 살펴보겠지만 SWIFT도 기존 메시징에 더해 공유원장 기반 기능을 개발하고 있다.

3. 해외송금에서는 왜 여러 은행이 등장할까?

모든 은행이 세계의 모든 통화와 지급결제 시스템에 직접 참여하기는 어렵다.

그래서 다른 은행과 관계를 맺고 계좌와 서비스를 이용하는 환거래은행(Correspondent Banking) 구조를 활용한다.

 

예를 들어 한국 은행이 외국 은행에 보유한 외화 계좌를 통해 지급을 처리할 수 있다.

이때 자주 등장하는 용어가 다음과 같다.

Nostro 계좌 우리 은행이 다른 은행에 보유한 계좌
Vostro 계좌 다른 은행이 우리 은행에 보유한 계좌

같은 계좌를 어느 은행의 입장에서 보느냐에 따라 표현이 달라질 수 있다.

국경을 넘는 지급은 이런 계좌 관계와 각국의 지급결제 시스템을 조합해 처리된다. BIS도 환거래은행 구조에서 외환 교환, 사전 자금 확보, 시스템 간 상호운용성을 주요 과제로 설명한다. BIS: Payments without borders

유동성을 미리 준비하는 비용

은행이 필요한 통화의 지급을 처리하려면 사용할 수 있는 자금이 있어야 한다.

관련 계좌에 미리 잔액을 확보하면 지급 실패 가능성을 줄일 수 있지만 여러 곳에 자금이 묶이는 비용이 발생한다. 다른 은행이 신용을 제공하는 구조라면 그에 따른 위험도 고려해야 한다. BIS의 국경 간 유동성 설명

빠른 메시징만으로 해결하기 어려운 부분이다.

4. 국제 지급의 지연은 어디서 발생할까?

국제 지급에서는 여러 종류의 마찰이 겹친다.

요인 발생할 수 있는 문제
통화 차이 환율 결정과 외화 유동성 확보
운영시간 차이 국가별 영업일·결제시간 불일치
데이터 차이 정보 누락, 형식 변환, 추가 확인
규제 차이 관할별 확인 사항과 제한 검토
기관 간 연결 여러 시스템의 상태와 결과 조정

연방준비제도의 국경 간 지급 설명도 통화, 시간대, 규제 차이와 환거래은행 관계, 유동성 문제를 주요 과제로 다룬다. Federal Reserve: Cross-Border Payments

 

여기서 IT 관점의 핵심은 여러 기관이 각자 관리하는 상태를 일관되게 맞추는 일이다.

한 기관에서는 처리가 끝났는데 다음 기관에서 정보가 부족할 수 있다. 지급 지시는 유효하지만 결제할 자금이 준비되지 않았을 수도 있다.

이 문제를 개선하는 방향은 다음처럼 나눌 수 있다.

  • 기관들이 더 정확한 데이터를 교환하도록 한다.
  • 기존 지급 시스템의 연결과 운영 방식을 개선한다.
  • 여러 자산과 결제 단계를 함께 처리할 새로운 구조를 만든다.

ISO 20022, 지급 시스템 연계, 토큰화와 공유원장은 각각 이 중 일부를 다룬다.

5. ISO 20022는 금융 메시지의 공통 언어다

ISO 20022는 금융정보를 공통된 의미와 구조로 모델링하고 메시지를 정의하는 국제 표준 체계다.

단순히 파일 확장자를 바꾸는 작업으로 보기보다는, 금융기관이 교환하는 데이터의 의미를 맞추는 기반으로 이해하는 편이 좋다. ISO 20022 공식 FAQ

예를 들어 지급 관련 정보를 구분된 항목으로 다루면 다음 업무를 지원할 수 있다.

  • 송금인과 수취인 정보 처리
  • 지급 목적과 참조정보 연결
  • 자동 대사
  • 규제 확인과 예외 처리

하지만 형식이 같다고 데이터 품질까지 보장되지는 않는다. 같은 필드라도 입력 기준과 사용 규칙이 맞아야 한다.

SWIFT의 관련 전환에서는 2025년 11월 22일 CBPR+ 지급지시 메시지의 MT·ISO 20022 공존 기간이 종료됐다. 이를 모든 금융 메시지와 전 세계 시스템이 같은 날 일괄 전환됐다는 의미로 확대해서는 안 된다. SWIFT ISO 20022 구현 안내

이 표준의 역할은 정보를 더 잘 교환하도록 돕는 것이다. 그 자체가 결제 자산이나 새로운 지급 네트워크는 아니다.

6. Finternet은 무엇일까?

Finternet은 여러 금융 생태계를 인터넷처럼 상호 연결하자는 미래 금융 시스템의 비전이다.

Agustín Carstens와 Nandan Nilekani가 2024년 BIS 워킹페이퍼에서 제안했다. 특정 제품이나 이미 전 세계에서 운영되는 단일 네트워크의 이름으로 읽으면 부정확하다. Finternet 원문

구상의 중심에는 사용자가 금융기관과 자산 종류 사이의 장벽을 덜 느끼면서 금융서비스를 이용하도록 하자는 목표가 있다.

 

이를 위해 원문은 다음 기반을 함께 다룬다.

  • 경제, 금융 구조
  • 토큰화 등 디지털 기술
  • 법률, 규제, 거버넌스
  • 상호운용성, 검증 가능성, 보안과 개인정보 보호

즉, 기술적인 연결만으로 완성되는 구상이 아니다.

예를 들어 다른 기관에 있는 자산을 담보로 사용하면서 대출과 결제를 연계하려면, 데이터와 자산 이전뿐 아니라 권리의 유효성, 담보 집행, 참여기관의 책임도 정해져야 한다.

또한 해당 워킹페이퍼의 견해는 저자들의 것이며, BIS나 회원 중앙은행 전체의 공식 입장을 반드시 뜻하지는 않는다. BIS 워킹페이퍼 설명

7. 토큰화는 기존 디지털 장부와 무엇이 다를까?

은행 예금과 증권은 이미 전산 장부로 관리된다.

그렇다면 토큰화가 추가로 제공하려는 기능은 무엇일까?

BIS는 토큰화를 기존 장부에 있는 실물·금융자산에 대한 권리를 프로그래밍 가능한 플랫폼에 기록하는 과정으로 설명한다. 이를 통해 메시지, 대사, 자산 이전을 더 긴밀하게 결합하는 가능성을 제시한다. BIS: 차세대 통화·금융 시스템

예를 들어 증권 거래에서 다음 조건을 연계할 수 있다.

매수자의 지급 준비 확인
          +
매도자의 증권 이전 준비 확인
          ↓
연결된 조건을 충족하면 교환 실행

핵심은 자산을 표현한 데이터와 그 자산에 적용되는 처리 규칙을 같은 흐름으로 다룰 수 있다는 점이다.

다만 토큰을 발행했다는 사실만으로 현실의 권리가 새로 생기는 것은 아니다. 토큰이 어떤 청구권을 나타내며 누가 이행 책임을 지는지 정해져야 한다.

무엇이 토큰화됐는지도 중요하다

표현 대상 확인해야 할 내용
상업은행 예금 어느 은행에 대한 청구권인가?
중앙은행 준비금 어떤 참여자가 보유·이용할 수 있는가?
증권 어떤 법적 권리와 이전 절차를 나타내는가?
기타 지급 수단 발행자·상환 조건·보호 장치는 무엇인가?

이름에 ‘토큰’이 붙었다고 같은 위험과 법적 성격을 갖는 것은 아니다.

8. 통합원장에서는 무엇을 통합하려는 걸까?

Unified Ledger·통합원장은 토큰화된 자금과 자산, 관련 거래 규칙을 함께 처리할 수 있도록 하는 구상이다.

관련된 상태 변경을 조정해 여러 기관의 순차적인 확인과 대사 부담을 줄이려는 목적이 있다.

 

하지만 ‘통합’이 반드시 전 세계가 하나의 데이터베이스를 공유한다는 뜻은 아니다.

BIS는 단일 원장부터 서로 연결된 원장까지 여러 구조를 설명하며, 프로그래밍 가능성과 결합 가능성, 데이터·거버넌스의 독립성 사이에서 선택이 필요하다고 본다. BIS: 통합원장 아키텍처

 

예를 들어 국가별 데이터 보관 요건이 다르면 모든 정보를 한곳에 모으기 어려울 수 있다. 여러 원장을 연결하면 각자의 통제는 유지하기 쉽지만, 원장 사이의 상태를 맞추는 작업이 복잡해진다.

 

따라서 “원장을 합치면 해결된다”보다 다음 질문이 먼저다.

어떤 상태를 함께 확정해야 하고, 어떤 정보와 통제는 분리해야 할까?

9. 원자적 결제는 무엇을 해결할까?

원자성·Atomicity는 연결된 작업을 모두 실행하거나, 모두 실행하지 않는 방식으로 다루는 성질이다.

외환 거래를 생각하면 의미가 분명해진다.

거래 당사자 A의 통화 지급
             ↕ 조건 연결
거래 당사자 B의 다른 통화 지급

한쪽 지급만 최종 완료되고 반대쪽 지급이 실패하는 위험을 줄이려면 두 이전을 연결해야 한다.

이와 관련된 대표 개념이 다음과 같다.

  • PvP·Payment versus Payment: 서로 다른 통화의 지급을 연결
  • DvP·Delivery versus Payment: 증권 등의 인도와 대금 지급을 연결

금융시장인프라 원칙도 연결된 의무의 최종 결제가 조건부로 함께 이루어지도록 하는 원칙을 다룬다. 이 접근은 기존 금융시장에서도 사용되며, 토큰화 플랫폼은 이를 구현·확장하는 방법을 연구한다. CPMI-IOSCO 금융시장인프라 원칙

원자성이 있더라도 유동성 부족, 잘못된 지시, 운영 장애까지 사라지는 것은 아니다. 어떤 작업 범위에 원자성을 적용했고, 외부 시스템과 법적 확정까지 어떻게 연결했는지 확인해야 한다.

10. 중앙은행 돈은 왜 계속 등장할까?

은행 계좌의 예금과 은행이 중앙은행에 보유한 준비금은 역할이 다르다.

상업은행 예금 고객이 상업은행에 갖는 청구권
중앙은행 준비금 상업은행 등이 중앙은행에 보유하는 결제 자산

은행 간 지급에서는 중앙은행 돈이 최종 결제의 기준 자산으로 중요한 역할을 한다. BIS와 중앙은행들의 공동 보고서도 기존의 이층 구조와 중앙은행 결제 자산이 통화에 대한 신뢰를 뒷받침한다고 설명한다. BIS: 기술혁신과 도매 중앙은행 돈

토큰화된 예금과 중앙은행 준비금을 함께 다루려는 프로젝트도 이 구조와 연결된다.

형태와 처리 방식은 바꾸되, 어떤 기관의 부채를 주고받으며 최종적으로 무엇으로 결제하는지 명확하게 하려는 것이다.

일반 사용자가 쓰는 소매형 CBDC와 금융기관 간 결제용 중앙은행 돈도 구분해야 한다. 도매 결제 실험이 곧 모든 국민을 위한 새 지갑 서비스의 도입을 뜻하지는 않는다.

11. 실제로 어디까지 진행됐을까?

Project Agorá: 다중통화 도매 지급 실험

Project Agorá는 BIS와 국제금융협회 IIF가 추진하는 민관 협력 프로젝트다.

토큰화된 상업은행 예금과 중앙은행 준비금을 공유된 프로그래밍 가능 플랫폼에서 결합해 국경 간 도매 지급을 개선할 수 있는지 살핀다.

공식 페이지에 따르면 2026년 7월 통제된 환경에서 실가치 테스트를 수행했다. 금융기관과 중앙은행 28곳이 참여했으며, 총거래 규모는 약 80만 스위스 프랑 상당이었다. 한국은행도 해당 테스트 참여 중앙은행에 포함된다. BIS Project Agorá

이는 실제 가치를 사용한 시험이라는 점에서 의미가 있다. 다만 제한된 참여자와 거래 시나리오에서 수행한 테스트이며, 일반 고객에게 개방된 전 세계 상용 서비스로 해석해서는 안 된다.

또한 24시간 처리를 지향하는 설계와 실제 테스트가 24시간 연속 운영을 입증했는지는 별개의 문제다.

SWIFT 공유원장: 기존 시스템과 연결하는 접근

SWIFT는 2026년 7월 9일, 블록체인 기반 공유원장이 초기 사용을 위한 준비를 마쳤다고 발표했다.

이 구조에서는 은행들이 자체 원장에 발행한 토큰화 예금을 조정하고, 최종 결제는 기존 시스템을 통해 완료하는 방식을 설명한다. SWIFT 공유원장 발표

이후 Standard Chartered와 HSBC도 해당 원장을 활용한 실거래를 발표했다. 설명에 따르면 두 은행 사이 의무를 기록·매칭·상계하고 기존 시스템에서 최종 결제를 수행했다. Standard Chartered 공식 발표

여기서는 공유원장에서 처리했다는 사실과 중앙은행 돈으로 최종 결제가 끝났다는 사실을 구분해야 한다.

Nexus: 기존 즉시지급 시스템을 연결하는 방향

모든 개선이 토큰화 원장을 필요로 하는 것은 아니다.

Project Nexus는 각국의 국내 즉시지급 시스템을 연결해 국경 간 지급을 지원하는 접근이다. BIS Project Nexus

현재 금융 인프라를 개선하는 길에는 메시지 표준화, 기존 시스템 연계, 공유원장 실험이 함께 존재한다.

12. SWIFT와 Finternet을 같은 종류로 비교하면 어려운 이유

지금까지의 내용을 나란히 두면 차이가 보인다.

항목 성격 중심 역할
SWIFT 기존 메시징 운영 중인 네트워크 금융 지시와 정보 교환
ISO 20022 표준 체계 금융 데이터의 의미와 구조 정렬
Finternet 미래 금융 시스템 비전 금융 생태계의 상호 연결
통합원장 인프라 설계 접근 자금·자산·처리 규칙의 연계
Project Agorá 실험 프로젝트 토큰화 기반 다중통화 도매 지급 검증
SWIFT 공유원장 초기 활용·실거래 검증이 진행되는 기능 은행의 토큰화 예금 처리 조정
Nexus 지급 시스템 연결 접근 국내 즉시지급 시스템 간 연계

따라서 “Finternet이 SWIFT를 대체하는가?”라는 질문만으로는 변화의 방향을 충분히 설명하기 어렵다.

SWIFT 같은 기존 참여자가 새로운 원장 기능을 추가할 수도 있고, 새로운 플랫폼이 기존 메시지 표준과 결제 시스템을 사용할 수도 있다.

앞으로 무엇이 바뀌는지는 어떤 업무가 어느 계층으로 이동하는지를 살펴봐야 알 수 있다.

13. 앞선 신원과 AML 주제는 어디에 연결될까?

금융 인프라가 빨라져도 거래 당사자와 권한, 위험을 확인하는 문제는 남는다.

디지털 신원 거래를 요청한 주체가 누구인가?
LEI 정확히 어느 법적 실체가 참여하는가?
vLEI 조직을 대신하는 사람의 역할은 무엇인가?
AML·고객확인 어떤 거래 관계이며 위험에 맞는 확인을 했는가?

이 표는 역할을 연결한 설명이다. 모든 프로젝트가 해당 기술을 필수로 사용한다는 뜻은 아니다.

새로운 플랫폼에서는 이런 확인을 거래 준비 단계와 연결하는 설계를 시도할 수 있다. Project Agorá도 규제 준수, 결제완결성, 개인정보 보호 같은 법적·운영적 문제를 함께 검토한다. BIS Project Agorá

확인 절차를 자동화하더라도 판단 근거와 책임이 없어지는 것은 아니다. 오히려 거래가 빨라질수록 실행 전 확인과 예외 처리의 중요성이 커진다.

14. 개발자는 어떤 질문으로 인프라를 평가해야 할까?

새로운 금융 기술을 볼 때 처리 속도와 원장 종류 외에도 확인할 항목이 있다.

다음은 시스템을 검토하기 위한 질문이다.

상태 접수·승인·자금 이용 가능·최종 결제를 구분하는가?
자산 무엇에 대한 청구권이 이동하는가?
실패 처리 일부 시스템 장애 시 어떤 상태로 남는가?
중복 방지 재시도 때문에 지급이 두 번 실행되지 않는가?
유동성 필요한 통화와 자금은 언제 확보하는가?
법적 기반 어느 규칙에 따라 이전이 최종 확정되는가?
보안·권한 누가 어떤 거래를 실행하고 승인할 수 있는가?
운영 기존 장부와 대사하고 장애 후 복구할 수 있는가?

특히 하나의 SUCCESS 상태로 모든 결과를 표현하면 문제가 생기기 쉽다.

메시지 전송에 성공했지만 결제는 대기 중일 수 있다. 고객이 자금을 사용할 수 있어도 은행 간 최종 결제는 나중에 이루어지는 구조일 수 있다.

시스템의 상태 모델은 실제 금융상의 책임과 확정 시점을 반영해야 한다.

국제 금융 인프라의 변화는 정보를 보내는 속도와 함께 서로 다른 기관의 장부·자산·규칙을 얼마나 일관되게 연결하는지에서 평가할 수 있다. Finternet과 관련 실험을 읽을 때도 이 기준을 적용하면, 기술적 가능성과 실제 운영 성과를 구분하기 쉬워진다.

참고 자료