들어가며 — 편리함 뒤에 숨겨진 위험
마이데이터 API 전환, 왜 필요했을까요?
혹시 몇 년 전에 토스나 뱅크샐러드에 처음 가입하면서 이런 화면을 보신 적 있으신가요?
“은행 아이디와 비밀번호를 입력해 주세요.”
지금 생각하면 아찔한 일입니다.
내 은행 로그인 정보를 제3자 앱에 통째로 넘기는 것이니까요.
그런데 당시 수백만 명의 사람들이 아무 거리낌 없이 입력했습니다.
그만큼 통합 자산 조회 서비스가 편리하고 필요했으니까요.
저는 당시 은행 IT 시스템을 가장 가까이에서 다뤘던 사람으로서,
이 상황을 내부에서 지켜보며 상당히 불편했습니다.
오늘은 그 시절 이야기와 함께, 왜 스크래핑에서 API 방식으로 전환해야 했는지,
그 현장의 진짜 이야기를 전해드리겠습니다.
스크래핑이란 무엇인가 — 집 열쇠를 통째로 넘기는 방식
스크래핑(Scraping)을 쉽게 설명하면 이렇습니다.
토스 앱이 여러분 대신 은행 홈페이지에 로그인해서,
화면에 표시되는 잔액·거래 내역 등을 긁어오는 방식이에요.
마치 누군가에게 집 열쇠를 통째로 맡기고 “필요한 것만 가져오세요”라고 하는 것과 같습니다.
이론적으로는 필요한 것만 가져오겠지만, 집 안의 모든 것에 접근할 수 있는 거죠.
기술적으로는 이렇게 작동했어요.
사용자 아이디·비밀번호 입력 → 핀테크가 은행 시스템에 대신 로그인 → 화면 데이터 자동 수집 → 앱에서 통합 표시
겉으로 보기에는 편리했지만,
내부적으로는 심각한 문제들이 있었습니다.
은행원이 직접 겪은 스크래핑의 실제 사례
저는 외환은행 리테일사업본부에서 제휴업무를 담당하면서 스크래핑의 문제를 누구보다 가까이에서 경험했습니다.
당시 저는 위메프 등 이커머스 입점 사업자를 대상으로 한 매출 담보대출 상품을 기획했어요.
이커머스에 입점해서 장사하는 소상공인들은 상품 판매 후 정산을 최소 45일에서 60일 후에 받는 구조였습니다.
자금이 급한 영세 사업자들에게 은행이 먼저 대출금을 지급하고,
정산일에 에스크로 계좌에서 대출금을 먼저 회수하는 방식이었죠.
문제는 이 구조를 실행하려면 사업자의 이커머스 계정에 은행이 주기적으로 접속해서 매출 현황을 확인해야 했다는 거예요.
즉 사업자의 아이디·비밀번호 또는 인증서를 위임받아 은행이 마치 사업자인 것처럼 이커머스에 스크래핑하는 방식이었습니다.
지금 생각해도 아찔해요.
그런데 당시에는 이 방법 외에 다른 선택지가 없었습니다.
지금도 일부 업무에서는 이 방식이 사용되고 있어요.
이 경험이 마이데이터에서 반드시 API 방식을 써야 한다는 확신을 갖게 해줬습니다.
개인의 모든 금융정보를 취급하는 마이데이터에서 스크래핑 방식을 쓴다면 개인정보 유출에 무방비로 노출되는 것이니까요.
스크래핑의 네 가지 문제점
첫째, 보안 위협이었습니다.
고객의 아이디·비밀번호가 제3자 서버에 저장된다는 것 자체가 심각한 보안 구멍이었어요.
만약 핀테크 서버가 해킹된다면 수백만 명의 은행 로그인 정보가 한꺼번에 유출될 수 있는 구조였습니다.
실제로 당시 은행 IT 보안팀에서는 스크래핑 서비스를 통한 이상 로그인 패턴을 지속적으로 모니터링했어요.
“이 로그인이 고객 본인인가, 핀테크 앱인가“를 구분하는 것 자체가 어려웠거든요.
둘째, 시스템 과부하였습니다.
수백만 명의 사용자 데이터를 동시에 긁어가니 은행 서버에 예상치 못한 트래픽이 발생했습니다.
특히 새벽 시간대에 일괄 업데이트가 몰리면 시스템이 버거워지는 상황이 생겼어요.
정상적인 고객 거래에 영향을 줄 수도 있었죠.
셋째, 책임 소재가 불분명했습니다.
사고가 났을 때 은행 잘못인지, 핀테크 잘못인지 경계가 모호했습니다.
고객 입장에서는 “내가 비밀번호를 직접 줬으니 은행도 핀테크도 책임 없다”는 상황이 될 수 있었어요.
넷째, 법적 근거가 없었습니다.
당시 스크래핑은 법적으로 허용된 방식이 아니었습니다.
일종의 그레이존에 있었던 거죠.
은행 입장에서는 막기도 애매하고 허용하기도 불편한 딜레마였어요.
API 전환 — 집 열쇠 대신 특정 방만 여는 열쇠
금융위원회는 마이데이터 제도를 설계하면서 처음부터 표준 API 방식을 채택했습니다.
API(Application Programming Interface)
쉽게 말하면 ‘공식 데이터 연결 창구’입니다.
은행이 공식 창구를 하나 만들어두고,
허가받은 사업자만 그 창구를 통해 정해진 정보만 가져갈 수 있게 하는 방식이에요.
집 열쇠를 통째로 주는 게 아니라,
특정 방만 열 수 있는 열쇠를 발급해주는 것이죠.
간단하게 스크래핑과 표준 API 방식을 비교해봤습니다.
API 전환, 현장에서 겪은 네 가지 난관
신정원·금융보안원의 역할
마이데이터 API 전환에서 핵심 역할을 한 두 기관이 있어요.
- 금융보안원 → 마이데이터 보안 인증, API 보안 규격 관리
- 신용정보원(신정원) → 마이데이터 종합포털 운영, API 명세서 배포, 정보제공자·수신자 관리
417개 정보제공자가 각자 다른 방식으로 데이터를 보내는 것을 표준화하는 엄청난 작업을 이 두 기관이 주도했습니다.
첫 번째 난관 — 레거시 시스템
은행의 핵심 시스템은 20~30년 된 것들이 많습니다.
새로운 API 규격에 맞춰 데이터를 내보내려면 이 오래된 시스템을 건드려야 했는데,
잘못 건드리면 은행 전체 업무가 마비될 수 있었어요.
마치 달리는 자동차의 엔진을 교체하는 것과 같았습니다.
해결책은 별도의 마이데이터 제공자 시스템을 새로 구축해서,
레거시 시스템에서 필요한 데이터만 추출해,
API 형식에 맞게 가공한 후 대외망을 통해 사업자에게 제공하는 방식이었습니다.
두 번째 난관 — 데이터 표준화
각 은행마다 데이터를 저장하는 방식이 달랐습니다.
같은 항목인데 A은행은 이렇게 보내고, B카드사는 저렇게 보내는 경우가 수백 개 항목에 걸쳐 발생했어요.
저도 이 작업이 프로젝트에서 가장 힘들었습니다.
데이터를 검증하다가 이상한 값이 나오면 해당 기관에 직접 연락해서 의미를 물어보고,
다시 규정 포맷으로 재전송 요청하고,
신정원에 반영 요청하는 과정을 수없이 반복했어요.
세 번째 난관 — 동시다발적 구축
417개 기관이 동시에 API를 개발하고 테스트해야 했습니다.
A은행이 준비됐어도 B카드사가 안 되면 연동이 안 돼요.
수백 개 기관이 모두 맞춰야 하는 거대한 퍼즐 맞추기였습니다.
네 번째 난관 — 끊임없는 오류
처음 API를 연동하면 반드시 오류가 납니다.
데이터 형식이 미묘하게 달라서 생기는 오류들을 하나하나 잡아가는 작업이 시행 직전까지 이어졌어요.
API 전환이 가져온 변화
어렵게 전환한 만큼 달라진 것들이 많았습니다.
소비자 입장에서
더 이상 은행 비밀번호를 핀테크 앱에 입력하지 않아도 됩니다.
간편 인증으로 동의하면 안전하게 데이터를 연결할 수 있게 됐어요.
데이터 범위도 명확해졌습니다.
내가 동의한 정보만 제공되고, 언제든지 철회할 수 있어요.
처음 시행 당시 492개였던 제공 정보 항목은 API 2.0 업그레이드로 720개로 확대됐습니다.
법적 보호도 생겼습니다.
사고가 나면 신용정보법에 따라 명확한 책임 소재와 피해 보상 기준이 생겼어요.
마치며 — 불편함을 감수한 이유
API 전환 과정은 솔직히 힘들었습니다.
금융 마이데이터 서비스 구축에는 수백억원 이상의 비용과 수천 명의 인력이 투입됐습니다.
개발 기간 역시 예상보다 훨씬 길어졌어요.
그 결과 당초 계획했던 2021년 12월 1일 본 적용을 하지 못하고,
한 달간의 시범운영을 거쳐 2022년 1월 5일로 연기해서 정식 시행하게 됐습니다.
그런데 왜 이 불편함을 감수했을까요?
소비자의 데이터 권리를 지키기 위해서입니다.
편리하다는 이유로,
내 비밀번호를 제3자에게 넘기는 방식은 지속 가능하지 않았습니다.
안전하고 투명한 방식으로 데이터를 다루는 것.
그것이 마이데이터 제도의 출발점이었습니다.
다음 편에서는 국내 5대 은행 마이데이터 서비스를 비교해드리겠습니다.
뱅커노트 (Banker’s Note)
30년 금융 현장의 경험을 바탕으로 디지털 금융과 마이데이터 이야기를 쉽게 풀어갑니다.