금융 IT에서 ‘표준’이 이기고, ‘기능’이 지는 이유
대부분의 팀은 금융 서비스를 “기능 경쟁”으로 정의합니다. 더 빠른 송금, 더 예쁜 대시보드, 더 많은 자동분류 같은 것들 말이죠.
그런데 금융은 이상하게도, 시간이 갈수록 기능보다 표준이 승자를 만들었습니다. 카드 결제는 네트워크 표준이 지배했고, 국제 송금은 메시지 표준이 지배했으며, 이제는 데이터 공유(오픈파이낸스)가 동의·권한 표준을 중심으로 재편되는 중입니다.
이 글의 목표는 단순 트렌드 소개가 아닙니다. “우리 서비스가 금융 데이터/결제를 다룬다면, 지금 당장 어디에 투자해야 장기적으로 이기는가”를 한 번에 끝내는 기준을 제시합니다.
시장이 바뀌는 신호는 ‘새 기능’이 아니라 ‘책임의 이동’이다
규제가 생기면 현장은 귀찮아합니다. 하지만 금융 IT에선 규제 변화가 곧 책임의 이동이고, 책임이 이동하면 제품 구조가 바뀝니다.
유럽에서는 PSD3/PSR 패키지 논의가 진행되며(2025년 말 기준 정치적 합의가 발표된 것으로 알려짐), 결제 사기·오류에 대한 책임과, 결제 과정의 확인(예: 수취인 확인 같은 메커니즘) 요구가 강화되는 흐름이 있습니다. 이건 “법무 체크리스트”가 아니라 프로덕트 설계 요구사항입니다.
왜냐하면 책임이 커지면, 가장 먼저 바뀌는 건 UI가 아니라 데이터 모델과 거래 전 검증 로직이기 때문입니다.
금융 IT를 3개의 표준 레이어로 다시 그려보기
금융 IT를 “은행 API 연동”으로만 보면 매번 프로젝트가 땜질로 끝납니다. 대신 표준을 3층으로 나눠 보세요.
레이어 1: 결제 메시지 표준(송금·정산의 언어)
대표가 ISO 20022입니다. 국제 결제 메시지가 더 풍부한 구조화 데이터를 담는 방향으로 이동하면서, 단순 포맷 변경이 아니라 컴플라이언스·리스크·분쟁 처리가 같이 바뀝니다.
특히 국제 송금/결제에 관여한다면 “메시지 마이그레이션”은 백엔드 작업이 아니라, 데이터 품질을 이용해 사기·오류를 줄이는 전략입니다. (참고: SWIFT의 ISO 20022 CBPR+ 구현 안내는 공식 페이지가 가장 정확합니다.)
레이어 2: 데이터 공유 표준(계좌·거래·자산 데이터의 언어)
미국 쪽에서는 FDX 같은 데이터 공유 API 표준이 빠르게 고도화되고 있습니다(동의/권한, 투자·보험 데이터 확장, 문서화 개선 등). 핵심은 “어떤 필드를 주고받나”가 아니라 동의의 수명주기(발급-갱신-철회-감사)가 표준에 내장된다는 점입니다.
레이어 3: 동의·권한·감사(누가 무엇을 언제까지 볼 수 있나)
오픈파이낸스는 ‘데이터를 열어준다’가 아니라 권한을 산업 표준으로 관리한다에 가깝습니다. 여기서 승부는 기술이 아니라 운영입니다.
권한이 많아질수록 고객은 불안해하고, 규제기관은 기록을 요구하며, 사업자는 장애가 났을 때 책임을 떠안습니다. 그래서 동의/권한은 보안팀의 일이 아니라 매출의 제약조건이 됩니다.
비교 표: ISO 20022 vs 오픈파이낸스 API(예: FDX) — 헷갈리기 쉬운 차이
| 구분 | ISO 20022(CBPR+ 등) | 오픈파이낸스 API(예: FDX) |
|---|---|---|
| 무엇을 표준화하나 | 결제/보고 메시지 구조(국제 송금·정산의 “문장”) | 소비자 금융 데이터 공유(계좌·거래·자산의 “레코드”) |
| 가장 큰 효과 | 구조화 데이터 증가 → AML/제재/분쟁 처리 고도화 | 데이터 포터빌리티 → 비교·추천·자동화 서비스 확장 |
| 실패 패턴 | 포맷 변환만 하고 데이터 품질/검증 로직을 못 따라감 | 권한/동의 운영을 UI로만 처리하고 감사·철회가 무너짐 |
| 제품에 미치는 영향 | 거래 전 검증, 예외처리, 사후 리컨실리에이션 설계가 핵심 | 동의 UX, 권한 범위 설계, 데이터 최소화, 로그/감사가 핵심 |
실전 의사결정: “우리는 무엇을 먼저 해야 하나?” 결정 트리
아래 질문에 “예”가 나오는 쪽부터 투자 우선순위를 잡으면, 유행이 아니라 구조에 돈을 쓰게 됩니다.
- 국제 결제/송금/정산을 직접 다루거나 파트너가 그 영역에 있나?
- 예 → ISO 20022 메시지 대응을 “포맷 전환”이 아니라 리스크/분쟁 비용 절감 과제로 정의
- 아니오 → 다음 질문
- 계좌/거래/자산 데이터를 모아 분석·추천·자동화를 하고 있나?
- 예 → 동의/권한/철회/감사를 제품 코어로 끌어올려야 함
- 아니오 → 다음 질문
- 우리 서비스의 경쟁력이 “기능”이 아니라 연결(제휴/연동)에서 나오나?
- 예 → API 표준/스키마/권한 모델을 먼저 정리해야 제휴 확장이 빨라짐
- 아니오 → 기능 투자도 가능하지만, “책임 이동” 신호를 주기적으로 점검
팀이 바로 써먹는 체크리스트: 오픈파이낸스/금융 API에서 사고 나는 지점 10개
- 권한 범위가 과한가? “필요한 데이터만”이 아니라 “필요한 기간만”까지 설계했나
- 동의 철회가 실시간으로 반영되나, 아니면 배치로 뭉개지나
- 재동의/갱신 정책이 UX와 운영 비용을 폭발시키고 있진 않나
- 감사 로그가 “누가/언제/무엇을/왜”까지 재현 가능한 형태인가
- 데이터 정합성이 깨질 때(은행별 스키마 차이, 누락 필드) 제품이 어떻게 버티나
- 거래 전 검증(수취인 확인, 이상 징후 탐지 등)에서 실패 시나리오가 정의돼 있나
- 장애 시 책임이 우리에게 쏠릴 수 있는 구간(캐시, 재시도, 중복 처리)을 알고 있나
- 분쟁 처리 프로세스가 고객센터 매뉴얼이 아니라 데이터로 자동화되어 있나
- 파트너 온보딩이 문서/가이드/샌드박스까지 포함해 “제품”으로 관리되고 있나
- 규제 변경을 ‘컴플라이언스 이벤트’가 아니라 ‘제품 스펙 변경’으로 다루는 루틴이 있나
이 주제로 돈 버는 팀의 방식: 기능보다 ‘비용구조’를 바꾼다
금융 IT에서 큰 돈은 “새 기능”이 아니라 비용구조의 개선에서 나옵니다.
예를 들어, 메시지 표준(ISO 20022)에서 더 풍부한 데이터를 쓰면 제재/AML/리컨실리에이션에서 재작업이 줄고, 오픈파이낸스 표준(예: FDX)의 동의 모델을 제대로 구현하면 권한 분쟁과 민원이 줄어듭니다.
투자자 관점에서도 같습니다. “사용자 수”보다 분쟁/사기/오류 비용이 내려가는 구조가 있는 회사가 오래 갑니다.
마지막 처방: 지금 당장 해야 하는 3가지
- 우리 비즈니스가 ‘결제 메시지’인지 ‘데이터 공유’인지 먼저 분류하고, 표준 레이어를 결정한다
- 동의/권한/감사를 UI가 아니라 “운영 가능한 시스템”으로 재정의한다
- 책임 이동 신호(사기 책임, 확인 의무, 투명성 요구)를 모니터링하고 제품 스펙에 반영한다
금융 IT의 본질은 “더 많은 데이터를 가지는 것”이 아니라, “더 많은 책임을 감당할 수 있게 설계하는 것”입니다.
참고로 읽을 만한 1차 출처
ISO 20022(CBPR+) 구현 흐름은 SWIFT 공식 안내가 가장 신뢰도가 높습니다.
EU 결제 서비스 규제 패키지(PSD3/PSR) 관련 공식 문서 맥락은 EUR-Lex에서 확인할 수 있습니다.