마이데이터 (MyData)

핵심 인사이트 (3줄 요약)

본질: 기관과 기업이 독점하던 개인 데이터의 통제권을 정보 주체(개인)에게 돌려주어, 본인의 데이터를 원하는 곳으로 이동시키고 활용할 수 있도록 하는 '개인정보 자기결정권'의 실현 체계이다.

가치: 스크래핑 방식의 보안 취약성을 극복하고 표준화된 Open API를 통해 데이터를 안전하게 유통하며, 개인 맞춤형 초개인화 자산관리 및 헬스케어 서비스 등을 창출한다.

융합: OAuth 2.0 기반의 강력한 인가(Authorization) 모델, FIDO 기반 신원 증명 기술과 결합하여 무신뢰(Zero Trust) 환경에서도 데이터 유출을 방어한다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

마이데이터(MyData)는 정보 주체인 개인이 본인의 정보를 적극적으로 관리, 통제하고 이를 신용평가, 자산관리, 건강관리 등에 주도적으로 활용하는 일련의 패러다임이다. 과거에는 개인이 발생시킨 금융 내역이나 진료 기록을 기업이 독점하여(Silo) 비즈니스 이득을 취했다. 그러나 데이터 주권 의식이 향상되고 EU의 GDPR이 제정됨에 따라, 개인은 자신의 데이터를 제3자에게 전송하도록 요구할 수 있는 '데이터 이동권(Right to Data Portability)'을 보장받게 되었다. 이는 단순한 규제 컴플라이언스가 아니라, 흩어진 개인 데이터를 통합하여 이전에 없던 초개인화 가치를 창출하는 혁신적 비즈니스 기반이 된다.

이 도식은 데이터 통제권 패러다임이 기업 중심에서 정보 주체(개인) 중심으로 어떻게 이동했는지를 보여주는 문제 배경 시각화이다.

[As-Is: 기업 독점형]
개인 활동 ──> [A은행 DB] (접근 불가/고립)
          ──> [B병원 DB] (종속성 심화)
         (데이터 파편화 및 개인 소외)

[To-Be: 마이데이터 아키텍처]
[A은행] ──(전송 요구)─┐
                     ↓
[B병원] ──(API 전송)─> [정보 주체(개인) & 마이데이터 사업자] ──> 초개인화 서비스 혜택

이 도식의 핵심은 데이터 통제 권한의 헤게모니가 기업 내부에서 중앙의 사용자 중심으로 역전되었다는 점이다. 이런 배치는 정보 주체가 개별 서비스에 묶이지 않고 플랫폼 독립성을 획득하게 함을 의미하며, 따라서 시스템 전체의 혁신 동력은 단위 서비스의 기능보다는 API 상호운용성과 전송의 안전성에 의해 결정된다. 실무에서는 이러한 주도권 변화를 수용하기 위해 레거시 시스템을 표준 API 스펙에 맞춰 개방하는 작업이 선결되어야 한다.

📢 섹션 요약 비유: 마치 각기 다른 은행에 묶여있어 인출할 수 없던 예금을, '오픈 뱅킹 통합 통장' 하나로 모아서 언제든 원하는 곳으로 이체하고 종합적인 자산 관리를 받는 것과 같습니다.

Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

마이데이터 서비스 시스템은 정보 제공자, 정보 수신자(마이데이터 사업자), 정보 주체, 그리고 중계 기관이라는 4개의 핵심 축으로 구동된다.

구성 요소	역할	내부 동작	프로토콜/기술	비유
정보 주체	개인정보의 소유자	전송 요구권 행사, 동의/철회	스마트폰 App, 전자서명	고객
정보 제공자	기존 데이터 보유 기관	API를 통한 데이터 개방 (은행, 병원 등)	Open API, API Gateway	기존 금고
마이데이터 사업자	데이터 수신 및 서비스 제공자	데이터 수집, 융합, 맞춤형 서비스 제공	데이터 레이크, 분석 AI	자산 관리사
중계/인증 기관	인가 및 토큰 발급 중계	통합 인증, 토큰(Access Token) 발급	OAuth 2.0, mTLS, FIDO	신분증명센터

핵심 원리는 스크래핑(Scraping)을 전면 금지하고, 보안이 강화된 표준 Open API와 OAuth 2.0 기반 인가 프레임워크를 사용하는 것이다.

이 흐름도는 사용자가 전송 요구를 했을 때, OAuth 2.0 기반으로 어떻게 인증과 인가가 이루어지고 데이터가 안전하게 이동하는지 보여준다.

[정보 주체]            [마이데이터 사업자]             [통합 인증 기관]               [정보 제공자 (은행)]
     │                        │                              │                             │
  ① 통합조회 요구 ─────────> │                              │                             │
     │                        │ ── ② 통합 인증 및 인가 요청 ──> │                             │
     │ <── ③ 인증/동의창 제공 ─ │ <───────── (리다이렉트) ───────┘                             │
  ④ 본인인증 & 동의 ───────> │                              │                             │
     │                        │ <── ⑤ Access Token 발급 ──────────┘                             │
     │                        │                                                             │
     │                        │ ── ⑥ Data 요청 (with Token) ─────────────────────────────> │
     │                        │ <── ⑦ 표준 JSON Data 응답 ─────────────────────────────── │
  ⑧ 융합 결과 뷰 제공 <────── ┘                                                             │

이 흐름의 핵심은 마이데이터 사업자(수신자)가 고객의 ID/PW를 직접 수집하지 않는다는 점이다. 이런 배치는 크리덴셜(비밀번호) 유출로 인한 2차 피해를 근본적으로 차단하기 때문이며, 따라서 시스템 성능은 API 토큰의 검증 속도와 암호화 복호화(TLS) 과정의 오버헤드에 크게 영향을 받는다. 실무에서는 이 지점의 인가 지연 시간과 토큰 만료 갱신(Refresh Token) 로직의 예외 처리를 반드시 정밀하게 설계해야 한다.

마이데이터에서 사용되는 사용자 동의 정보(Consent)는 아래와 같은 포맷으로 관리된다.

// 마이데이터 동의 영수증(Consent Receipt) 예시 스니펫
{
  "consentId": "CST-2024-987654",
  "subjectId": "user123_hash",
  "grantedTo": "MyDataCorp_App",
  "purpose": "맞춤형 자산 관리 서비스 제공",
  "dataScope": ["account_balance", "transaction_history"],
  "retentionPeriod": "2025-05-23T00:00:00Z",
  "status": "ACTIVE"
}

📢 섹션 요약 비유: 마치 예전에는 내 금고 열쇠(ID/PW)를 비서(스크래핑 업체)에게 아예 맡겼다면, 이제는 비서에게 '특정 시간, 특정 서랍만 열 수 있는 임시 출입증(Access Token)'만 발급하여 안전하게 심부름을 시키는 것과 같습니다.

Ⅲ. 융합 비교 및 다각도 분석 (Comparison & Synergy)

마이데이터 기술의 핵심 전환점은 기존의 '스크래핑(Scraping)' 방식에서 '표준 API(Application Programming Interface)' 방식으로의 진화다.

항목	화면 스크래핑 (Screen Scraping)	오픈 API (Open API)	판단 포인트
수집 원리	봇(Bot)이 화면 HTML/DOM 파싱	규격화된 JSON/XML 엔드포인트 호출	데이터 정합성
보안성	고객 ID/PW를 제3자가 보관해야 함 (매우 취약)	OAuth 토큰 기반 인가 (안전, ID/PW 불필요)	자격증명 보관 주체
서버 부하	제공자 서버(웹) 부하 매우 높음	경량화된 트래픽, 세밀한 제어 가능	트래픽 오버헤드
운영 유지보수	UI/UX 변경 시 파서 전면 수정 필수 (비용 폭증)	백엔드 로직 변경에도 인터페이스 유지 가능	시스템 결합도

마이데이터는 **인공지능(AI) 및 지식 그래프(Knowledge Graph)**와 융합할 때 진정한 위력을 발휘한다. 단순한 잔액의 총합을 보여주는 수준을 넘어, 통신 데이터, 결제 데이터, 건강 데이터를 그래프 형태로 연결하여 "이 고객이 이번 달 의료비 지출이 늘었으니 관련 보장성 보험을 추천해야겠다"와 같은 인과 추론적 분석을 수행할 수 있게 된다.

이 도식은 스크래핑 방식의 아키텍처 한계와 오픈 API 방식의 구조적 차이를 나타낸 대조 매트릭스이다.

[스크래핑의 락 경합 및 병목 구조]
마이데이터 앱 ─(ID/PW 전달)─> 스크래핑 서버 ─(무한 크롤링)─> [제공자 Web 서버] (과부하 발생!)

[Open API의 토큰 기반 병렬 구조]
마이데이터 앱 ─(Token 전달)─> [API Gateway (Rate Limit)] ─(경량 쿼리)─> [제공자 DB] (부하 통제 가능)

이 구조 차이의 핵심은 API Gateway의 통제력 개입 여부이다. 오픈 API 방식은 API 게이트웨이를 통해 속도 제한(Rate Limit)과 할당량(Quota) 제어가 가능하다. 반면 스크래핑 방식은 단건 지연은 고사하고 방어 메커니즘을 뚫기 위해 시스템 자원을 비정상적으로 낭비하며, 트래픽 변동이 큰 환경에서는 제공자 서비스 전체를 마비시킬 위험이 있다.

📢 섹션 요약 비유: 화면 스크래핑이 요리사(수집기)가 남의 식당 주방에 몰래 들어가 레시피를 훔쳐보는 것이라면, 오픈 API는 정식으로 재료 창구에 메뉴를 주문하여 깔끔하게 포장된 식재료(JSON)를 받아오는 것과 같습니다.

Ⅳ. 실무 적용 및 기술사적 판단 (Strategy & Decision)

실무에서 마이데이터 시스템을 구축하거나 연동할 때, 기술사와 아키텍트는 극도의 보안성과 트래픽 조절 능력을 설계해야 한다.

실무 시나리오 1: 마이데이터 API 전송 집중 트래픽 대응

상황: 매일 자정, 수백만 사용자의 앱이 동시에 백그라운드 데이터 갱신을 요청하여 정보 제공자 은행 서버에 대규모 트래픽 스파이크(Thundering Herd) 발생.
판단: 클라이언트 앱에서 동기식(Synchronous) 일괄 호출을 지양하고, 시스템 부하를 분산시키는 Jitter(난수) 기반의 백오프 재시도 로직을 구현해야 한다. 또한 API Gateway에서 과도한 트래픽에 대해 HTTP 429 (Too Many Requests)를 반환하는 서킷 브레이커를 적용하여 DB 장애 전파를 막아야 한다.

도입 체크리스트

인증/인가: OAuth Refresh Token 생명 주기 관리 및 탈취 대비 취소(Revoke) 로직이 구현되었는가?
무결성: 데이터 전송 시 mTLS(Mutual TLS) 상호 인증을 통해 인가받지 않은 노드의 API 탈취를 방지했는가?
거버넌스: 사용자의 동의(Consent)가 철회되었을 때, 지체 없이 데이터 레이크 내의 파생 데이터까지 하드 삭제(Hard Delete) 또는 파기 처리가 보장되는가?

안티패턴: 동의 철회 데이터의 Soft Delete 방치 사용자가 마이데이터 서비스 탈퇴 및 데이터 삭제(잊힐 권리)를 요구했음에도, 분석계 DB에 플래그(is_deleted=true)만 변경하고 물리적 파기를 누락하는 경우가 흔하다. 이는 명백한 법률 위반이며, 추후 데이터 유출 사고 발생 시 기업에 치명적인 페널티를 안겨준다. 반드시 배치 잡(Batch Job)을 통해 정기적으로 물리 블록을 덮어쓰거나(Zero-out) 삭제 증명서를 남겨야 한다.

이 도식은 마이데이터 인프라에서 장애 및 침해가 발생할 수 있는 취약 지점과 방어선을 보여준다.

[모바일 App] ==(TLS)==> [API Gateway] => [Authorization Server] => [Microservices] => [DB]
      ▲                       ▲                       ▲                                ▲
    단말 해킹            DDoS / API Abuse     Token 탈취 / 재사용             동의 철회 데이터 잔류
  (난독화 대응)        (Rate Limit 방어)    (짧은 수명 / mTLS 방어)          (완전 파기 배치 적용)

이 도식의 핵심은 모든 구간 계층마다 독립적인 방어 기제가 필요하다는 점이다. 이런 배치는 제로 트러스트(Zero Trust) 철학을 반영한 것이며, 따라서 하나의 방어선(예: API Gateway)이 뚫리더라도 내부 인가 서버가 토큰 유효성을 다시 검증해 대형 사고를 막아낸다. 실무에서는 이 지점의 로그를 SIEM 등과 연동하여 비정상적인 전송 요구 패턴을 실시간으로 관찰해야 한다.

📢 섹션 요약 비유: 마이데이터 시스템은 튼튼한 금고 문(API Gateway)을 만드는 것뿐만 아니라, 고객이 언제든 "내 물건을 당장 폐기해 줘"라고 했을 때 즉시 파쇄기에 넣을 수 있는 파기 절차(데이터 삭제 거버넌스)가 완벽히 준비되어야 비로소 완성됩니다.

Ⅴ. 기대효과 및 결론 (Future & Standard)

마이데이터의 확산은 단순히 IT 시스템 연동의 변화가 아니라, 데이터 경제의 패러다임을 B2C에서 C2B(개인이 기업을 통제)로 역전시키는 촉매제이다.

구분	정보 주체 (개인)	마이데이터 사업자	정보 제공 기관
가치	데이터 주권 회복, 맞춤형 통합 서비스	데이터 획득 비용 절감, 신사업 창출	타 산업 데이터 융합 기회
운영	편의성 극대화, 인증 일원화	스크래핑 비용 절감, 합법적 수집	API 관리 체계 전환, 트래픽 최적화

미래 전망: 초기 금융 분야(오픈뱅킹 중심)에서 시작된 마이데이터는 의료(마이헬스웨이), 공공(공공 마이데이터), 통신, 교육 등 **'전 분야 마이데이터(All-MyData)'**로 확산될 것이다. 장기적으로는 중앙 기관이 데이터를 중계하는 방식에서 벗어나, 개인이 개인 데이터 저장소(PDS: Personal Data Store)를 스마트폰 등 로컬에 소유하고 서비스 쪽에 분석 권한만 잠시 위임하는 분산형 아키텍처(DID 연계)로 발전할 것이다.

참고 표준:

금융 마이데이터 표준 API 가이드 (KOR): 금융보안원이 주관하는 전송 규격
GDPR Article 20: 데이터 이동권(Right to data portability) 법적 근거
OAuth 2.0 / OIDC: 인가 및 인증 국제 표준 프레임워크

마이데이터 시스템의 미래 진화 방향을 보여주는 로드맵 다이어그램이다.

[1단계: 부문별 고립] ──> [2단계: 금융 중심 마이데이터] ──> [3단계: 이종 산업 연계] ──> [4단계: Web3 분산형 PDS]
(스크래핑/불안정)           (Open API/OAuth 정착)        (의료, 통신, 공공 융합)       (개인 로컬 저장/DID 결합)

이 로드맵의 핵심은 데이터 저장소의 중심축이 기업 서버(1~3단계)에서 궁극적으로 개인의 단말(4단계)로 이동한다는 점이다. 이는 중앙화된 허니팟(Honeypot) 리스크를 원천적으로 제거하기 위함이며, 따라서 향후 엣지 컴퓨팅 기술과 분산 ID 기술이 마이데이터 아키텍처를 주도하게 될 것이다. 실무에서는 지금의 중앙형 마이데이터를 설계할 때부터 분산 환경을 고려해 식별자를 강결합시키지 않아야 한다.

📢 섹션 요약 비유: 마치 처음에는 동네 병원 차트만 보다가(1단계), 전국 은행 통장을 다 보게 되고(2단계), 나중에는 내 건강, 지갑, 스마트폰 기록을 모두 모아 내 방 비밀 금고(PDS)에만 보관하고 남들에겐 필요한 것만 보여주는 완벽한 독립(4단계)을 이루는 것과 같습니다.

📌 관련 개념 맵 (Knowledge Graph)

오픈 API (Open API) | 외부 시스템이 마이데이터 플랫폼의 기능과 데이터에 안전하게 접근할 수 있도록 규격화된 프로토콜 인터페이스.
OAuth 2.0 (Open Authorization) | 사용자 비밀번호 제공 없이 제3자 앱에 접근 권한(Token)을 위임하는 마이데이터 인가의 핵심 프레임워크.
데이터 이동권 (Right to Data Portability) | 정보 주체가 자신의 데이터를 기계 판독 가능한 형식으로 돌려받거나 타 기관으로 전송 요구할 수 있는 법적 권리.
API 게이트웨이 (API Gateway) | 외부의 무수한 데이터 전송 요청에 대해 인증, 라우팅, 속도 제한을 수행하는 시스템 최전방 수문장.
분산 신원 증명 (DID) | 중앙 기관 없이 정보 주체가 직접 본인의 신원을 증명하고 관리할 수 있어 마이데이터의 궁극적 목표와 부합하는 기술.

👶 어린이를 위한 3줄 비유 설명

마이데이터는 예전에 은행 아저씨나 병원 선생님이 꽉 쥐고 안 주던 '내 숙제와 성적표(데이터)'를, 내가 원할 때 언제든 돌려받을 수 있는 마법의 권리예요.
예전에는 다른 학원에 성적표를 주려면 내가 직접 뛰어가야 했지만, 이제는 내가 버튼 하나만 누르면 안전한 파이프(오픈 API)를 통해 알아서 슝 날아간답니다.
이렇게 모인 내 모든 정보들을 똑똑한 로봇 비서에게 보여주면, 나에게 딱 맞는 용돈 기입장이나 운동 계획표를 뚝딱 만들어줘서 내 생활이 훨씬 편해져요.