토스를 열면 국민은행, 신한은행, 우리은행 잔액이 한 화면에 뜹니다. 카카오뱅크에서 다른 은행 계좌로 이체할 때도 별도 앱 설치 없이 그 자리에서 끝납니다. 불과 몇 년 전까지만 해도 은행마다 앱을 따로 깔고, 공인인증서를 옮겨 다니며 로그인해야 했던 시절과 비교하면 격세지감입니다. 이 모든 편리함의 뒤에는 오픈뱅킹(Open Banking) API라는 기술 인프라가 자리 잡고 있습니다.

여름 휴가를 앞두고 여행 자금을 정리하거나, 여러 계좌에 흩어진 잔액을 한눈에 파악하고 싶을 때 우리는 자연스럽게 통합 금융 앱을 꺼냅니다. 하지만 서로 다른 은행의 데이터가 어떻게 하나의 앱으로 흘러 들어오는지, 내 금융 정보가 제3의 앱을 거치면서 정말 안전한 것인지 궁금해 본 적은 없으신가요? 오늘은 오픈뱅킹 API의 기술 원리부터 보안 아키텍처, 그리고 여름 재정 관리에 바로 활용할 수 있는 실전 팁까지 낱낱이 풀어보겠습니다.

오픈뱅킹 이전 시대 — 스크린 스크래핑이라는 위태로운 다리

오픈뱅킹이 등장하기 전에도 여러 은행 계좌를 한 번에 보여주는 서비스는 있었습니다. 대표적인 것이 스크린 스크래핑(Screen Scraping) 방식입니다. 이 방식은 사용자의 인터넷뱅킹 아이디와 비밀번호, 인증서 정보를 제3자 앱이 직접 받아서 은행 웹사이트에 자동 로그인한 뒤, 화면에 표시된 잔액이나 거래내역을 긁어오는 것입니다.

기술적으로 말하면, 헤드리스 브라우저(Headless Browser)나 HTTP 클라이언트가 은행의 인터넷뱅킹 페이지에 접속하고, HTML을 파싱하여 원하는 데이터를 추출합니다. 마치 사람이 직접 로그인해서 화면을 읽는 과정을 소프트웨어가 자동화한 것이죠.

문제는 명확했습니다. 첫째, 사용자의 인증 정보를 제3자에게 그대로 넘겨야 했습니다. 아이디, 비밀번호, 심지어 공인인증서 파일까지 핀테크 업체의 서버에 보관되는 구조였습니다. 둘째, 은행 웹사이트의 HTML 구조가 바뀌면 스크래핑이 즉시 깨졌습니다. 은행이 화면을 리뉴얼할 때마다 핀테크 업체는 파서(Parser)를 수정해야 했고, 그 사이 서비스가 중단되곤 했습니다. 셋째, 은행 입장에서는 자동화된 대량 접속을 정상 사용자와 구분하기 어려워 보안 위협으로 간주하기도 했습니다.

이런 불안정하고 위험한 구조를 대체하기 위해 등장한 것이 바로 표준화된 오픈뱅킹 API입니다. 은행이 공식적으로 데이터를 내어주는 문(API)을 열어두면, 핀테크 앱은 사용자 비밀번호를 받을 필요 없이 허가된 경로로만 데이터에 접근할 수 있게 됩니다.

오픈뱅킹 API의 기술 구조 — 금융결제원이 놓은 표준 철로

한국의 오픈뱅킹 시스템은 금융결제원(KFTC)이 중앙 허브 역할을 맡고 있습니다. 영국이나 유럽의 오픈뱅킹이 각 은행에 직접 API를 구축하도록 규정한 것과 달리, 한국은 금융결제원이라는 단일 게이트웨이를 통해 모든 은행의 API가 통합 제공됩니다. 이 차이가 한국 오픈뱅킹의 가장 큰 기술적 특징입니다.

중앙 집중형 API 게이트웨이

핀테크 앱이 특정 은행의 계좌 잔액을 조회하고 싶다면, 그 은행의 서버에 직접 요청을 보내는 것이 아닙니다. 대신 금융결제원의 오픈뱅킹 API 게이트웨이에 표준 형식의 요청을 보냅니다. 게이트웨이는 요청을 받아 인증과 권한을 확인한 뒤, 해당 은행의 내부 시스템으로 중계합니다. 은행의 응답은 다시 게이트웨이를 거쳐 표준 형식으로 변환된 후 핀테크 앱에 전달됩니다.

이 구조의 장점은 거대합니다. 핀테크 업체는 20개가 넘는 은행의 각기 다른 시스템을 개별적으로 연동할 필요 없이, 금융결제원의 단일 API 규격만 구현하면 모든 은행과 연결됩니다. 은행 역시 수백 개의 핀테크 업체를 각각 관리하는 대신 금융결제원과의 연동 하나만 유지하면 됩니다. 일종의 허브 앤드 스포크(Hub-and-Spoke) 아키텍처인 셈입니다.

RESTful API와 표준 데이터 형식

오픈뱅킹 API는 REST(Representational State Transfer) 아키텍처를 따릅니다. HTTP 프로토콜 위에서 동작하며, 각 기능은 고유한 URL 엔드포인트로 구분됩니다. 예를 들어 잔액 조회, 거래내역 조회, 이체 요청이 각각 별도의 엔드포인트를 가집니다.

요청과 응답의 데이터 형식은 JSON(JavaScript Object Notation)으로 통일되어 있습니다. 과거에 한국 금융권에서 흔히 쓰이던 XML 전문이나 고정 길이 전문 방식과 비교하면 훨씬 가볍고 처리 속도가 빠릅니다. 모바일 환경에서 불필요한 데이터 전송을 줄이는 데도 유리합니다.

주요 API 엔드포인트는 크게 세 가지 카테고리로 나뉩니다. 조회 API(잔액 조회, 거래내역 조회, 계좌 실명 조회), 이체 API(출금이체, 입금이체), 그리고 관리 API(등록 계좌 관리, 토큰 갱신 등)입니다. 각 API는 요청 파라미터, 응답 필드, 에러 코드가 금융결제원의 기술 규격서에 상세하게 정의되어 있어서, 어떤 은행의 데이터를 요청하든 동일한 형식으로 응답을 받을 수 있습니다.

핀테크 이용기관 등록과 API 키 발급

아무나 오픈뱅킹 API를 호출할 수 있는 것은 아닙니다. 핀테크 업체가 오픈뱅킹을 이용하려면 금융위원회에 등록된 핀테크 이용기관이어야 합니다. 등록 과정에서 사업 적합성, 정보보호 체계, 이용자 보호 방안 등을 심사받습니다.

심사를 통과하면 금융결제원으로부터 클라이언트 ID(client_id)와 클라이언트 시크릿(client_secret)이 발급됩니다. 이것은 해당 핀테크 업체를 고유하게 식별하는 자격 증명으로, 모든 API 호출 시 이 정보가 포함되어야 합니다. 마치 건물 출입증처럼 API 게이트웨이가 “이 요청은 등록된 정당한 업체에서 온 것인가”를 확인하는 데 쓰입니다.

OAuth 2.0 기반 인증 — 비밀번호 없이 권한만 빌려주는 기술

오픈뱅킹의 핵심 보안 메커니즘은 OAuth 2.0 프로토콜입니다. OAuth 2.0은 “사용자가 자신의 비밀번호를 제3자에게 알려주지 않고도, 특정 데이터에 대한 접근 권한을 위임할 수 있게 하는” 표준 프로토콜입니다. 구글이나 카카오 소셜 로그인에서도 같은 프로토콜이 쓰이지만, 금융 분야에서는 보안 수준이 한 단계 더 높게 적용됩니다.

인증 흐름의 네 단계

오픈뱅킹에서 OAuth 2.0 인증이 작동하는 흐름을 구체적으로 살펴보겠습니다.

1단계 — 동의 요청(Authorization Request)
사용자가 핀테크 앱에서 ‘계좌 연결하기’ 버튼을 누르면, 앱은 사용자를 금융결제원의 인증 페이지로 리다이렉트합니다. 이 페이지에서 사용자는 어떤 은행의 어떤 계좌에 대해 어떤 권한(잔액 조회, 거래내역 조회, 이체 등)을 허용할 것인지 직접 선택합니다.

2단계 — 본인 확인(Authentication)
사용자가 동의 항목을 선택하면, 금융결제원은 본인 확인 절차를 진행합니다. 여기서 중요한 점은 본인 확인이 금융결제원의 페이지 내에서 이루어진다는 것입니다. 핀테크 앱은 이 과정에 전혀 개입하지 않으며, 사용자의 인증 정보(비밀번호, 생체 정보 등)를 볼 수도 없습니다. 이것이 스크린 스크래핑과의 결정적 차이입니다.

3단계 — 인가 코드 발급(Authorization Code)
본인 확인이 완료되면, 금융결제원은 핀테크 앱에 일회용 인가 코드(Authorization Code)를 전달합니다. 이 코드는 매우 짧은 유효 시간(통상 수 분)을 가지며, 한 번 사용되면 폐기됩니다.

4단계 — 접근 토큰 교환(Token Exchange)
핀테크 앱은 인가 코드를 금융결제원의 토큰 발급 서버에 제출하여 접근 토큰(Access Token)과 갱신 토큰(Refresh Token)을 발급받습니다. 이후 모든 API 호출은 이 접근 토큰을 HTTP 헤더에 포함시켜 이루어집니다.

토큰의 수명과 갱신 메커니즘

접근 토큰에는 유효 기간이 설정되어 있습니다. 오픈뱅킹에서 접근 토큰의 유효 기간은 보통 90일이며, 만료되면 갱신 토큰으로 새 접근 토큰을 발급받을 수 있습니다. 갱신 토큰의 유효 기간은 더 길지만, 이 역시 영구적이지는 않습니다.

이 설계에는 보안적 의미가 있습니다. 만약 접근 토큰이 유출되더라도 유효 기간이 지나면 자동으로 사용할 수 없게 되므로, 피해 범위가 시간적으로 제한됩니다. 또한 사용자는 언제든 동의를 철회하여 발급된 토큰을 무효화할 수 있습니다. 이는 마치 집 열쇠를 빌려준 뒤 언제든 자물쇠를 바꿀 수 있는 것과 같습니다.

스코프(Scope) 기반 권한 제어

OAuth 2.0에서 특히 중요한 개념이 스코프(Scope)입니다. 스코프는 접근 토큰이 어떤 종류의 데이터에 접근할 수 있는지를 세밀하게 제한합니다. 예를 들어 잔액 조회만 동의한 사용자의 토큰으로는 이체 API를 호출할 수 없습니다. 핀테크 앱이 나중에 더 많은 권한을 필요로 하면, 사용자에게 다시 동의를 받아 스코프를 확장해야 합니다.

이런 최소 권한 원칙(Principle of Least Privilege)이 기술적으로 강제되므로, 단순히 계좌 조회 서비스를 이용하기 위해 가입했는데 어느 날 갑자기 이체가 실행되는 일은 구조적으로 불가능합니다.

API 호출 한 건이 거치는 여정 — 잔액 조회를 예로

이론적인 구조를 이해했으니, 실제로 여러분이 앱에서 잔액 조회 버튼을 누를 때 어떤 일이 벌어지는지 따라가 보겠습니다.

첫 번째, 앱의 서버가 API 요청을 구성합니다. 사용자의 접근 토큰, 조회할 계좌의 핀테크 이용번호(실제 계좌번호를 대체하는 고유 식별자), 그리고 거래 고유번호를 포함한 HTTP 요청을 만듭니다. 이 요청은 TLS 1.2 이상으로 암호화된 채널을 통해 전송됩니다.

두 번째, 금융결제원의 API 게이트웨이가 요청을 수신합니다. 게이트웨이는 가장 먼저 접근 토큰의 유효성을 검증합니다. 토큰이 만료되지 않았는지, 요청된 API가 토큰의 스코프 범위 안에 있는지, 호출 빈도가 허용된 한도를 초과하지 않았는지(Rate Limiting)를 확인합니다.

세 번째, 게이트웨이가 해당 은행의 중계 시스템으로 요청을 전달합니다. 금융결제원과 각 은행 사이에는 전용선 또는 VPN 기반의 보안 채널이 구축되어 있습니다. 게이트웨이는 표준 형식의 요청을 해당 은행의 내부 전문 형식으로 변환(매핑)한 뒤 전달합니다.

네 번째, 은행의 코어뱅킹 시스템이 잔액 정보를 반환합니다. 은행은 계좌의 실시간 잔액 데이터를 금융결제원으로 보내고, 게이트웨이는 이를 다시 표준 JSON 형식으로 변환하여 핀테크 앱의 서버에 응답합니다.

다섯 번째, 앱이 화면에 잔액을 표시합니다. 이 전체 과정이 통상 1~3초 이내에 완료됩니다. 사용자가 여러 은행의 잔액을 동시에 조회하면 앱의 서버가 각 계좌에 대한 API 요청을 병렬(Parallel)로 발송하여 응답 시간을 줄입니다.

이 과정에서 주목할 점은, 핀테크 앱의 서버가 사용자의 실제 계좌번호를 알 필요가 없다는 것입니다. 오픈뱅킹은 각 연결된 계좌에 핀테크 이용번호라는 대체 식별자를 부여합니다. 핀테크 앱은 이 번호만으로 조회와 이체를 수행하며, 실제 계좌번호는 금융결제원과 은행 사이에서만 매핑됩니다. 이 또한 스크린 스크래핑 시대와 본질적으로 다른 보안 설계입니다.

보안 아키텍처 — 내 금융 정보는 어떻게 보호되는가

오픈뱅킹이 편리하다는 건 알겠는데, 제3자 앱을 통해 은행 데이터가 오가는 구조가 과연 안전한 것인지 의문을 가지시는 분도 많을 것입니다. 오픈뱅킹 시스템에 적용된 다층 보안 구조를 하나씩 살펴보겠습니다.

전송 구간의 암호화

모든 API 통신은 TLS(Transport Layer Security) 1.2 이상의 암호화가 필수입니다. 이는 핀테크 앱 서버와 금융결제원 게이트웨이 사이의 통신이 도청이나 변조로부터 보호된다는 의미입니다. 금융결제원과 각 은행 사이의 내부 통신 역시 별도의 전용 보안 채널로 보호됩니다.

추가로 상호 TLS(Mutual TLS, mTLS) 인증이 적용되는 구간도 있습니다. 일반적인 TLS가 서버의 신원만 확인하는 것과 달리, mTLS는 클라이언트(핀테크 서버)의 신원도 인증서를 통해 검증합니다. 즉 API 게이트웨이에 접근하는 서버 자체가 등록된 핀테크 이용기관의 서버가 맞는지를 암호학적으로 확인하는 것입니다.

API 호출 제한과 이상 탐지

API 게이트웨이에는 Rate Limiting(호출 빈도 제한)이 적용됩니다. 특정 핀테크 앱이 비정상적으로 많은 API 요청을 보내면 자동으로 차단됩니다. 이는 탈취된 토큰을 이용한 대량 데이터 수집 시도를 막기 위함입니다.

또한 금융결제원은 API 호출 패턴을 모니터링하여 이상 거래를 탐지합니다. 예를 들어 평소 잔액 조회만 하던 계정에서 갑자기 대량 이체 요청이 발생하거나, 새벽 시간대에 비정상적인 조회 패턴이 감지되면 알림이 발동됩니다. 이는 기존 금융권의 FDS(이상거래탐지시스템)와 유사한 원리가 API 레벨에서도 작동하는 것입니다.

핀테크 기업에 대한 보안 심사

오픈뱅킹 이용기관으로 등록하려면 정보보호 관리체계에 대한 심사를 통과해야 합니다. 사용자 데이터의 암호화 저장, 접근 로그 관리, 개인정보 처리 방침, 침해사고 대응 계획 등이 심사 항목에 포함됩니다. 등록 이후에도 정기적인 보안 점검과 취약점 진단을 받아야 하며, 기준에 미달하면 이용 자격이 정지될 수 있습니다.

쉽게 말해, 오픈뱅킹 생태계에 참여하는 핀테크 기업은 입구에서부터 엄격한 보안 검증을 거친 업체라는 의미입니다. 물론 이것이 100%의 안전을 보장하지는 않지만, 스크린 스크래핑 시절에 사실상 무심사로 운영되던 것과는 비교할 수 없는 수준의 안전장치입니다.

데이터 최소화 원칙

오픈뱅킹 API의 설계에는 데이터 최소화(Data Minimization) 원칙이 반영되어 있습니다. API 응답에는 요청된 범위의 데이터만 포함되며, 불필요한 추가 정보는 전달되지 않습니다. 예를 들어 잔액 조회 API의 응답에는 잔액과 계좌 식별 정보만 포함되지, 전체 거래 내역이나 개인 신상 정보가 함께 딸려오지 않습니다.

또한 핀테크 앱이 수집한 금융 데이터의 보관 기한도 규정되어 있습니다. 서비스 제공에 필요한 최소 기간만 보관하고, 사용자가 서비스를 해지하거나 동의를 철회하면 해당 데이터를 파기해야 합니다. 이러한 규정이 기술적으로 강제되는 동시에 제도적으로도 감독되는 이중 구조입니다.

여름 재정 관리에 오픈뱅킹 200% 활용하기

기술 원리를 이해했으니, 이제 실생활에 적용해 볼 차례입니다. 특히 여름은 휴가비, 에어컨 전기료, 각종 시즌 지출이 늘어나는 시기인 만큼, 여러 계좌에 분산된 자금을 효율적으로 관리하는 것이 중요합니다.

계좌 통합 관리로 여름 자금 흐름 한눈에 보기

월급 계좌, 적금 계좌, 생활비 계좌, 비상금 계좌를 서로 다른 은행에 분산해 두신 분이 많습니다. 오픈뱅킹을 활용하는 통합 금융 앱에서 모든 계좌를 연결해 두면, 여름 휴가 예산을 잡을 때 각 은행 앱을 따로 열어볼 필요 없이 총 가용 자금을 즉시 파악할 수 있습니다.

특히 토스, 뱅크샐러드 같은 앱의 자산 현황 대시보드는 오픈뱅킹 API의 잔액 조회와 거래내역 조회를 결합하여 계좌별 입출금 추이를 시각화합니다. 여름 시즌에 어떤 카테고리의 지출이 늘어나고 있는지를 한 화면에서 추적할 수 있으므로, 예산 초과를 사전에 방지하는 데 효과적입니다.

이체 수수료 절약의 숨은 공신

오픈뱅킹 출범 이전에는 타행 이체 수수료가 건당 500~1,000원 수준이었습니다. 오픈뱅킹이 표준 인프라를 제공하면서 은행 간 이체의 기술적 비용이 대폭 낮아졌고, 이는 수수료 인하 경쟁으로 이어졌습니다. 현재 대부분의 은행과 핀테크 앱에서 월 일정 횟수의 타행 이체가 무료로 제공되는 배경에는 오픈뱅킹의 기술적 효율화가 있습니다.

여름 휴가를 함께하는 친구들과 비용을 정산할 때, 서로 다른 은행 계좌 간 이체가 빈번하게 발생합니다. 오픈뱅킹 덕분에 이 과정이 무료이자 실시간으로 이루어진다는 점을 떠올리면, 우리가 일상적으로 누리는 편의의 기술적 무게를 실감할 수 있습니다.

앱 선택 시 확인할 보안 체크포인트

오픈뱅킹을 활용하는 앱을 선택할 때 몇 가지 확인해 볼 점이 있습니다.

• 금융위원회 등록 여부 — 앱 소개 페이지나 이용약관에서 ‘오픈뱅킹 이용기관 등록’ 또는 ‘전자금융업자 등록’ 여부를 확인합니다. 등록된 업체만이 공식 오픈뱅킹 API에 접근할 수 있습니다.
• 동의 항목의 세분화 — 계좌 연결 시 잔액 조회, 거래내역 조회, 이체 등의 권한을 개별적으로 선택할 수 있는지 확인합니다. 모든 권한을 한꺼번에 동의하도록 강제하는 앱보다는, 필요한 권한만 선택할 수 있는 앱이 보안 원칙에 더 부합합니다.
• 동의 철회 경로 — 서비스를 더 이상 이용하지 않을 때 연결된 계좌의 동의를 쉽게 철회할 수 있는지 확인합니다. 금융결제원의 오픈뱅킹 포털에서 직접 연결된 서비스 목록을 조회하고 해지할 수도 있습니다.
• 생체 인증 또는 PIN 잠금 — 앱 자체에 지문, 안면 인식, 또는 별도 PIN 잠금이 설정 가능한지 확인합니다. 오픈뱅킹의 보안이 아무리 견고해도, 잠금 해제된 스마트폰을 분실하면 앱 내에서 계좌 정보가 노출될 수 있습니다.

정기적인 연결 계좌 점검 습관

여름은 각종 여행 관련 앱이나 새로운 금융 서비스를 시도해 보는 시기이기도 합니다. 이런저런 앱에 계좌를 연결하다 보면, 더 이상 쓰지 않는 서비스에 계좌가 연결된 채로 방치되는 경우가 생깁니다.

금융결제원 오픈뱅킹 홈페이지에서 본인 인증 후 ‘이용내역 조회’를 하면, 현재 어떤 핀테크 서비스에 어떤 계좌의 어떤 권한이 연결되어 있는지 전체 목록을 확인할 수 있습니다. 사용하지 않는 서비스의 연결은 그 자리에서 바로 해지할 수 있으므로, 분기에 한 번 정도 점검하는 습관을 들이면 좋습니다.

특히 여름 휴가 전후로 한 번 점검해 두면, 불필요한 데이터 공유 경로를 정리하면서 마음 놓고 여행을 다녀올 수 있습니다.

오픈뱅킹의 다음 단계 — 마이데이터와의 융합

오픈뱅킹이 은행 계좌의 조회와 이체를 표준화했다면, 마이데이터(MyData)는 그 범위를 카드, 보험, 증권, 통신, 공공 데이터까지 확장한 개념입니다. 기술적 기반은 유사합니다. 표준 API, OAuth 2.0 인증, 데이터 최소화 원칙이 그대로 적용되면서, 더 넓은 범위의 금융 데이터를 사용자의 동의하에 한 곳에 모을 수 있게 됩니다.

오픈뱅킹과 마이데이터의 기술적 융합이 진행되면서, 앞으로 우리가 사용하는 금융 앱은 단순한 계좌 조회를 넘어 보험 만기 알림, 카드 혜택 비교, 투자 포트폴리오 분석까지 하나의 인터페이스로 제공하게 됩니다. 그 모든 것의 출발점이 바로 오늘 살펴본 오픈뱅킹 API입니다.

은행 앱을 따로따로 열며 잔액을 확인하던 시절은 이미 지나갔습니다. 오픈뱅킹이라는 기술 인프라 위에서 금융은 점점 더 열리고, 연결되고, 편리해지고 있습니다. 다만 그 편리함을 안전하게 누리려면, 오늘 살펴본 것처럼 그 속에서 어떤 기술이 내 정보를 보호하고 있는지를 이해하고, 동의 관리와 보안 설정이라는 최소한의 관리 습관을 유지하는 것이 중요합니다. 이번 여름, 여행 자금을 정리하면서 연결된 계좌 목록도 한 번 점검해 보시는 건 어떨까요.

이미지는 Leonardo AI 로 생성되었습니다.