LabHub

블로그

오픈뱅킹과 마이데이터 API 아키텍처 — 금융 데이터 개방의 기술

2026-06-13 · 31 분 읽기 · #finance#open-banking#mydata#api#oauth2#fapi#architecture

한국어English日本語

들어가며 — 계좌 정보가 은행 담장을 넘기까지

하나의 핀테크 앱에서 여러 은행의 잔액을 한 번에 조회하고, 어느 은행 계좌로든 송금을 보내는 경험은 이제 당연해졌습니다. 그러나 이 당연함의 뒤에는 표준 API, 중계기관, 인증 체계, 동의 관리, 기관 간 정산이라는 거대한 인프라가 있습니다.

이 글에서는 한국의 오픈뱅킹 공동망과 마이데이터(본인신용정보관리업) 아키텍처를 중심으로, 금융 데이터 개방을 떠받치는 기술 구조를 살펴봅니다. 데이터를 제공하는 금융회사 측과 데이터를 이용하는 핀테크 측 양쪽의 구현 관점을 모두 다루고, 영국 오픈뱅킹·PSD2·FAPI 같은 글로벌 표준과의 비교도 곁들입니다.

이 글은 공개된 제도·표준의 구조를 기술 관점에서 정리한 자료이며, 특정 기관의 내부 사양이나 법률 해석에 대한 자문이 아닙니다. 실제 사업 추진 시에는 최신 규정과 공식 가이드라인을 반드시 확인하시기 바랍니다.

한국 오픈뱅킹 구조 — 공동망과 중계기관

한국 오픈뱅킹의 가장 큰 특징은 중앙 중계기관(금융결제원) 모델입니다. 핀테크 기업이 은행마다 개별 계약과 개별 연동을 하는 대신, 금융결제원의 오픈뱅킹 공동업무 시스템에 한 번 연결하면 참가 기관 전체와 통신할 수 있습니다.

[한국 오픈뱅킹 공동망 구조]

  핀테크 앱/이용기관                금융결제원                참가 금융회사
  ┌──────────────┐    표준 API   ┌──────────────┐   대외계   ┌──────────┐
  │  서비스 서버  │ ───────────▶ │  오픈뱅킹     │ ────────▶ │  A 은행   │
  │  (이용기관)   │ ◀─────────── │  중계 시스템  │ ◀──────── │  B 은행   │
  └──────────────┘    응답/콜백  └──────────────┘            │  C 저축은행│
                                      │                      └──────────┘
                                      ├─ 인증(토큰 발급/검증)
                                      ├─ 거래 중계·전문 변환
                                      ├─ 이용기관 관리·과금
                                      └─ 기관 간 정산

오픈뱅킹 API는 크게 조회와 이체 두 축으로 나뉩니다.

API 분류대표 API특징
조회잔액조회, 거래내역조회, 계좌실명조회읽기 전용, 상대적으로 단순
이체입금이체, 출금이체자금 이동, 멱등성·대사 필수
관리계좌등록·해지, 토큰 관리동의·등록 라이프사이클

이 중 가장 까다로운 것이 출금이체입니다. 이용기관의 요청으로 고객 계좌에서 돈이 빠져나가는 구조이므로, 사전 출금 동의 등록, 거래 한도, 그리고 응답 타임아웃 시의 미확인 거래 처리(앞선 원장 글에서 다룬 UNKNOWN 상태와 대사)가 모두 필요합니다.

마이데이터 아키텍처 — 전송요구권의 기술적 구현

마이데이터(본인신용정보관리업)는 개인이 자신의 신용정보를 "여기에서 저기로 보내라"고 요구할 수 있는 개인신용정보 전송요구권을 기술적으로 구현한 제도입니다. 오픈뱅킹이 계좌 중심의 조회·이체라면, 마이데이터는 은행·카드·보험·증권·통신 등 광범위한 업권의 정보를 표준 API로 수집하는 체계입니다.

[마이데이터 정보 흐름]

   고객 ──(전송요구+통합인증)──▶ 마이데이터 사업자 앱
                                      │
                                      │ 표준 API (REST, JSON)
                                      ▼
            ┌─────────────┬───────────────┬─────────────┐
            │  은행(정보제공자) │  카드사(정보제공자) │  증권사(정보제공자) │
            └─────────────┴───────────────┴─────────────┘
                                      │
            지원: 종합포털(지원센터), 인증중계, 표준 스펙 관리

핵심 구성요소는 다음과 같습니다.

표준 API 스펙의 형태 — 요청과 응답

마이데이터·오픈뱅킹 계열의 표준 API는 공통적으로 다음 형태를 가집니다. 실제 스펙의 필드명은 버전에 따라 다르므로, 구조 이해를 위한 단순화 예제로 봐주시기 바랍니다.

토큰 발급(OAuth 2.0 권한부여코드 방식 기반)은 대략 이런 흐름입니다.

POST /oauth/2.0/token HTTP/1.1
Host: api.provider.example
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code
&code=AUTH_CODE_FROM_CONSENT_FLOW
&client_id=CLIENT_ID
&client_secret=CLIENT_SECRET
&redirect_uri=https://app.example/callback

{
  "token_type": "Bearer",
  "access_token": "eyJhbGciOiJSUzI1NiIs...",
  "expires_in": 3600,
  "refresh_token": "rt_8f14e45fceea167a...",
  "scope": "bank.read card.read"
}

계좌 거래내역 조회 요청·응답의 단순화 예제입니다.

GET /v1/accounts/transactions?account_num=110-123-456789&from_date=20260601&to_date=20260613&limit=100 HTTP/1.1
Host: api.provider.example
Authorization: Bearer eyJhbGciOiJSUzI1NiIs...
x-api-tran-id: M2026061300001234567890

{
  "rsp_code": "00000",
  "rsp_msg": "success",
  "search_timestamp": "20260613091500",
  "next_page": "",
  "trans_list": [
    {
      "trans_dtime": "20260612143015",
      "trans_type": "03",
      "trans_class": "출금",
      "trans_amt": "50000",
      "balance_amt": "1250000",
      "trans_memo": "커피숍 결제"
    },
    {
      "trans_dtime": "20260611090000",
      "trans_type": "02",
      "trans_class": "입금",
      "trans_amt": "3000000",
      "balance_amt": "1300000",
      "trans_memo": "급여"
    }
  ]
}

스펙 읽을 때 주의할 실무 포인트입니다.

글로벌 비교 — 영국 오픈뱅킹, PSD2, FAPI

한국 모델을 더 잘 이해하려면 글로벌 표준과 비교하는 것이 좋습니다.

관점한국 (오픈뱅킹/마이데이터)영국 (Open Banking)EU (PSD2)
추진 방식중계기관 중심 공동망 + 법정 전송요구권규제 당국 주도, 표준화 기구(OBIE) 설립지침(Directive) 기반, 회원국별 이행
연결 구조중앙 중계 허브 경유기관별 API 직접 연결 + 디렉터리기관별 API, 표준은 시장 주도(Berlin Group 등)
인증 표준통합인증 + 기관별 토큰OAuth 2.0 + FAPI 프로파일강력한 고객 인증(SCA) 요구
대상 범위계좌·결제에서 전 업권 신용정보로 확장결제계좌 중심결제계좌·결제 서비스 중심

기술적으로 가장 참고할 만한 것은 FAPI(Financial-grade API) 보안 프로파일입니다. OpenID Foundation이 정의한 금융 수준 API 보안 표준으로, 일반 OAuth 2.0 대비 다음을 요구합니다.

한국 표준도 인증서 기반 상호 인증과 전문 서명을 요구한다는 점에서 지향점이 같습니다. 새로 시스템을 설계한다면 FAPI 2.0 Security Profile을 기준선으로 잡는 것이 안전합니다.

제공자 측 구현 — API 게이트웨이, 유량 제어, 과금

은행 같은 정보제공자 관점에서 오픈뱅킹·마이데이터는 "외부에서 들어오는 대량의 조회 트래픽"입니다. 내부 채널과 다른 특성을 이해해야 합니다.

[제공자 측 참조 아키텍처]

  중계기관/이용기관
        │
        ▼
  ┌────────────────────────────────────────────┐
  │ API 게이트웨이                              │
  │  - 클라이언트 인증(mTLS, 인증서 검증)        │
  │  - 토큰 검증, 스코프 확인                    │
  │  - 유량 제어(기관별/API별 rate limit)        │
  │  - 거래 ID 검증·로깅                        │
  └────────────────────────────────────────────┘
        │
        ▼
  ┌────────────────┐      ┌──────────────────┐
  │ 오픈API 서비스층 │ ───▶ │ 조회 전용 데이터층 │ ◀─ 계정계로부터 CDC/배치 복제
  │ (변환·조립)     │      │ (read replica/캐시)│
  └────────────────┘      └──────────────────┘
        │ 이체성 거래만
        ▼
  계정계 (원장)

핵심 설계 포인트입니다.

  1. 조회와 원장의 분리: 마이데이터 정기 전송은 새벽 시간대에 트래픽이 집중되는 특성이 있습니다. 이 조회 부하가 계정계 원장 DB를 직접 때리지 않도록, 조회 전용 복제본이나 캐시 계층으로 흡수합니다. 이체성 API만 계정계 경로를 탑니다.
  2. 유량 제어: 이용기관별·API별 호출 한도를 게이트웨이에서 강제합니다. 특정 사업자의 폭주가 전체 서비스에 번지지 않게 하는 1차 방어선입니다.
  3. 과금·통계: 오픈뱅킹 API는 건별 수수료 체계가 있으므로, 과금 기준이 되는 호출 기록을 유실 없이 적재해야 합니다. 과금 데이터와 운영 로그는 목적이 다르므로 분리 설계합니다.
  4. 스키마 버전 관리: 표준 스펙 개정 시 신구 버전 병행 기간이 있습니다. URL 버저닝과 필드 추가에 관대한(직렬화에 엄격하지 않은) 파서 정책이 필요합니다.

이용기관 측 구현 — 토큰 관리와 정기적 전송

핀테크·마이데이터 사업자 관점의 난제는 "수백만 사용자 x 수십 기관"의 토큰과 수집 스케줄을 관리하는 일입니다.

토큰 관리부터 보겠습니다.

정기적 전송 스케줄링은 일종의 분산 크롤링 설계입니다.

# 정기 전송 수집 스케줄러의 골격 (개념 예제)
def schedule_daily_collection(users, providers, window_start, window_end):
    """기관별 호출 한도와 시간 창을 지키며 수집 작업을 분산한다."""
    tasks = []
    for user in users:
        for p in user.consented_providers:
            tasks.append(CollectTask(user_id=user.id, provider=p))

    # 1) 기관별로 그룹화 → 기관별 동시성 상한 적용
    # 2) 시간 창 내 균등 분산(특정 분에 몰리지 않게 지터 부여)
    # 3) 실패 작업은 지수 백오프 재시도, 상한 초과 시 다음 주기로 이월
    for provider, group in group_by_provider(tasks):
        limit = provider.rate_limit          # 예: 초당 50건
        for i, task in enumerate(group):
            task.scheduled_at = spread_with_jitter(
                window_start, window_end, i, len(group))
            task.max_retries = 3
            enqueue(task, concurrency_key=provider.code, limit=limit)

운영에서 배우게 되는 포인트들입니다.

보안 요구 — 전송구간, 인증서, 클라이언트 인증

금융 데이터 개방 체계의 보안은 여러 겹으로 구성됩니다.

계층요구 사항구현 수단
전송 구간구간 암호화, 강한 TLS 설정TLS 1.2 이상, 최신 암호 스위트
클라이언트 인증기관 신원의 암호학적 증명mTLS 클라이언트 인증서, 전용선/VPN 병용
메시지전문 위변조 방지전자서명, 거래 ID와 타임스탬프 검증
토큰탈취 토큰의 재사용 방지송신자 구속(mTLS 바인딩), 짧은 만료
저장수집 정보·토큰 보호저장 시 암호화, 키 분리 보관, 접근 통제
운영이상 징후 탐지호출 패턴 이상 탐지, 인증서 만료 모니터링

실무에서 의외로 자주 터지는 사고는 화려한 해킹이 아니라 인증서 만료입니다. 기관 간 mTLS 인증서, 서명용 인증서, TLS 서버 인증서의 만료일을 자산 목록으로 관리하고, 만료 30일 전 알림과 교체 리허설을 운영 루틴에 넣어야 합니다.

동의 관리 시스템 설계 — 동의는 데이터다

마이데이터의 법적 기반은 고객 동의이므로, 동의 자체가 일급 데이터 모델이어야 합니다.

-- 동의(전송요구) 모델 예시
CREATE TABLE consents (
    consent_id      UUID PRIMARY KEY,
    user_id         BIGINT NOT NULL,
    provider_code   VARCHAR(10) NOT NULL,   -- 정보제공자
    scope_codes     TEXT[] NOT NULL,        -- 동의 정보 범위
    purpose_code    VARCHAR(10) NOT NULL,   -- 수집·이용 목적
    granted_at      TIMESTAMPTZ NOT NULL,
    expires_at      TIMESTAMPTZ NOT NULL,   -- 동의 유효기간
    revoked_at      TIMESTAMPTZ,            -- 철회 시각
    status          VARCHAR(10) NOT NULL    -- ACTIVE, EXPIRED, REVOKED
);

-- 동의 이력: 모든 상태 변화를 추가 전용으로 기록
CREATE TABLE consent_events (
    event_id        BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    consent_id      UUID NOT NULL REFERENCES consents(consent_id),
    event_type      VARCHAR(20) NOT NULL,   -- GRANTED, RENEWED, REVOKED ...
    event_at        TIMESTAMPTZ NOT NULL DEFAULT now(),
    channel         VARCHAR(20) NOT NULL,
    evidence_ref    TEXT                    -- 인증 기록 등 증적 참조
);

설계 원칙입니다.

데이터 표준화 문제 — 기관별 편차와 정규화 레이어

표준 API라고 해서 데이터가 균질하지는 않습니다. 같은 스펙이라도 기관별 해석과 데이터 품질에 편차가 있습니다.

따라서 이용기관 아키텍처에는 원본 보존 + 정규화 레이어의 2층 구조가 필요합니다.

[수집 데이터 정규화 파이프라인]

  표준 API 응답(기관별 원본)
        │  그대로 저장 (원본 불변 보존 — 재처리 가능성 확보)
        ▼
  raw_records (기관별 스키마 그대로)
        │  정규화: 코드 매핑, 금액 정밀도 통일, 시간대 통일,
        │          중복 제거(겹침 구간), 가맹점명 정제
        ▼
  canonical_transactions (서비스 공통 모델)
        │
        ▼
  서비스 기능 (자산 조회, 소비 분석, 신용 관리 ...)

원본을 보존하는 이유는 정규화 로직이 계속 진화하기 때문입니다. 가맹점명 정제 규칙을 개선했을 때 원본이 있으면 전체 재처리가 가능하지만, 정규화 결과만 남겼다면 되돌릴 수 없습니다.

장애와 품질 관리 — 기관별 SLA와 서킷브레이커

수십 개 기관과 연동하는 시스템에서 "전체 장애"보다 흔한 것은 "기관 한 곳의 부분 장애"입니다.

[기관별 서킷브레이커 상태 머신]

   CLOSED (정상)
     │  실패율 > 50% (최근 100건) 또는 연속 타임아웃 N회
     ▼
   OPEN (차단: 즉시 실패 응답, 큐 작업은 이월)
     │  쿨다운 경과 (예: 60초)
     ▼
   HALF-OPEN (탐색 호출 소량 허용)
     ├─ 성공 지속 ──▶ CLOSED 복귀
     └─ 실패 ──▶ OPEN 재진입 (쿨다운 증가)

비즈니스 활용과 한계

마지막으로 이 인프라 위에서 무엇이 가능하고 무엇이 어려운지 짚어보겠습니다.

가능해진 것들입니다.

여전히 어려운 것들입니다.

테스트 전략 — 테스트베드와 기관 시뮬레이터

연동 테스트에도 전략이 필요합니다.

설계 체크리스트

마치며

오픈뱅킹과 마이데이터는 "API 몇 개 연동"처럼 보이지만, 실제로는 인증·동의·표준화·장애 관리·정산이 맞물린 분산 시스템 설계 문제입니다. 특히 동의 관리와 기관별 품질 편차는 시작 전에는 과소평가되고 운영 후에는 가장 많은 시간을 가져가는 영역입니다. 이 글의 구조 — 중계 모델 이해, FAPI 수준의 보안 기준선, 원본 보존과 정규화 분리, 기관 단위 장애 격리 — 를 출발점으로 삼으시면, 데이터 개방 시대의 시스템을 한층 견고하게 설계할 수 있을 것입니다.

참고 자료

원문 보기: https://www.youngju.dev/blog/finance/2026-06-13-open-banking-mydata-api-architecture

댓글

아직 댓글이 없습니다.

로그인하면 댓글을 쓸 수 있습니다