마이데이터 API 전환, 스크래핑 보다 왜 안전 할까?

마이데이터 API 전환 전, 저는 위험한 방식을 매일 지켜봤어요

저는 은행에서 근무할 때 미래금융채널기획, O2O전략, 옴니채널전략, 그리고 핀테크 시장 조사 업무를 책임지고 있었어요.

그래서 핀테크 앱을 직접 체험해봐야 했어요.

토스와 뱅크샐러드 앱에 처음 가입하고 주요 서비스를 이용하려고 클릭하는 순간, “은행 아이디와 비밀번호를 입력해 주세요”라는 팝업이 떴어요.

저는 깜짝 놀랐어요.

“아이디와 비밀번호를?” 은행원으로서 보안의 중요성을 누구보다 잘 알았으니까요. 하지만 서비스가 어떤 건지 벤치마크해야 했기에 어쩔 수 없이 입력하고 체험을 했던 기억이 아직도 생생해요.

저는 놀랐지만, 당시 수백만 명의 금융 소비자는 아무 거리낌 없이 핵심 인증 정보를 앱에 입력했어요. 은행에서 받지 못한 서비스를 한 화면에서 받게 되는 새로운 경험이 너무 좋았기 때문이었죠.

저는 은행의 IT 시스템을 가장 가까이서 관리하면서, 현업에서 어쩔 수 없이 스크래핑 방식을 도입해 특정 업무를 수행했던 시절이 있었어요. 그때 내부 모니터링 화면에 찍히는 ‘비정상적 대량 로그인’ 기록들을 보며 매일같이 불안을 느꼈어요.

이 불안이 막연한 게 아니었어요. 은행 리테일사업본부 시절, 이커머스 입점 소상공인을 위한 매출 담보대출 상품을 기획할 때였어요.

대출금을 안전하게 회수하려면 주기적으로 소상공인의 이커머스 매출 현황을 확인해야 했는데, 방법은 단 하나뿐이었어요. 사업자의 아이디와 비밀번호를 받아 은행이 대신 로그인해서 데이터를 긁어오는 스크래핑 방식이었어요.

결국 그 상품은 출시가 무산되면서 그때는 스크래핑을 도입하지 않았어요. 하지만 그 이후 다른 특정 업무에서는 어쩔 수 없이 스크래핑 방식을 도입해야 했어요.

개인의 모든 금융 정보를 다루는 마이데이터 사업에서 이런 방식이 계속됐다면, 대한민국 금융은 개인정보 유출 사고의 우려를 항상 품고 살 수밖에 없는 시대가 시작됐을 거예요.

스크래핑이 위험했던 진짜 이유

스크래핑이란, 핀테크 앱이 여러분 대신 은행 홈페이지에 접속해서 화면에 보이는 잔액과 거래 내역을 그대로 긁어오는 방식이에요.

이걸 설명할 때 제가 자주 떠올리는 경험이 있어요. 10년 전, 퇴직하고 은행 본점 21층에 있는 부서를 방문할 일이 있었어요. 1층 로비에서 안내 직원에게 신분증을 맡기고 출입증을 교부받았어요.

그런데 그 출입증으로 21층뿐 아니라, 아는 직원이 있는 다른 층까지 제약 없이 다 들어갈 수 있었어요.

그런데 3년 전, 다시 본점을 방문할 일이 있어 갔더니 분위기가 달라져 있었어요.

안내 직원이 “몇 층, 어느 부서에 가시나요?”라고 물어봤어요. 알고 보니 이제는 방문하려는 부서만 열리는 출입증을 발급하고 있었어요.

제가 가야 하는 그 부서만 출입할 수 있는, 딱 그만큼의 권한만 주는 시스템으로 바뀌어 있었던 거예요.

스크래핑은 10년 전 그 신분증과 같아요. 한 번 맡기면 건물의 모든 층을 제약 없이 들어갈 수 있는 권한을 통째로 넘기는 방식이에요.

문제는 명확했어요.

고객의 인증 정보가 제3자 서버에 저장되는 것 자체가 심각한 보안 구멍이었고, 수백만 명이 동시에 데이터를 긁어가는 새벽 시간대엔 은행 서버가 트래픽 폭주로 다운 위기를 맞았어요.

사고가 나도 은행 잘못인지 핀테크 잘못인지 책임 소재가 모호했고, 당시 스크래핑은 제도권 밖의 그레이존에 머물러 있었어요.

마이데이터 API 전환, 스크래핑보다 안전한 이유는 이거예요

마이데이터 API 전환은 이 문제를 해결하기 위한 거였어요.

출입증을 건물 전체가 아니라 목적지 층만 열리게 바꾼 것처럼, 표준 API도 딱 필요한 데이터만, 정해진 방식으로만 오가게 만들었어요.

구체적으로 무엇이 달라졌는지, 스크래핑과 표준 API를 4가지 기준으로 비교하면 이래요.

▲ 스크래핑과 표준 API 방식 비교 (직접 재구성)

이렇게 데이터 수집 방식부터 책임 소재까지, 모든 단계에서 안전장치가 새로 생긴 거예요.

마이데이터 안전을 지키기 위한, 417개 기관이 맞춘 거대한 퍼즐

이 전환의 중심에는 보안 규격을 관리한 금융보안원과, 마이데이터 포털을 운영한 신용정보원이 있었어요. 하지만 현장 실무자들에게는 지옥 같은 난관이 기다리고 있었어요.

417개 금융기관이 동시에 연동 테스트를 해야 했던 게 가장 큰 난관이었어요.

저는 마이데이터 API 전환을 위한 검증 작업을 하면서 고생도 많이 했지만, 그만큼 보람도 컸어요.

한번은 수신업무 중 계좌상세 API 데이터를 검증하는데, 모 저축은행 계좌 상세정보에서 계좌 신규일과 만기일이 서로 바뀌어 들어온 걸 발견했어요.

전직 은행원이었기에 발견할 수 있었던 오류예요. 신규일이 만기일보다 늦을 수는 없거든요.

▲ 형식은 정상이지만 신규일·만기일이 뒤바뀐 데이터 오류 사례 (직접 재구성)

그런데 날짜 필드에 정상적인 날짜 포맷으로 데이터가 들어와 있어서, 일반 개발자라면 “날짜 타입 필드에 일자가 잘 들어왔네” 하면서 그냥 검증을 통과시켰을 거예요.

이런 오류는 보통 SI 개발 프로젝트가 끝나고 운영 단계에 들어서야 발견되는 경우가 많아요.

연동 테스트 과정도 만만치 않았어요.

A은행 데이터가 완벽하게 들어와도 B카드사가 안 되면 연동 자체가 불가능했어요. 수백 개 기관이 거대한 퍼즐을 동시에 맞추는 과정은 그야말로 전쟁터였어요.

데이터 형식이 1바이트만 달라도 에러가 났고, 이 미세한 오류를 잡아내는 작업이 정식 시행일인 2022년 1월 5일 직전까지 이어졌어요.

마이데이터 API 전환이 만든 진짜 변화는 내 데이터는 안전하다

이 혹독한 과정을 거쳐 완성된 API 환경은 소비자에게 분명한 변화를 가져왔어요.

더 이상 핀테크 앱에 은행 비밀번호를 입력하지 않아도 돼요.

간편 인증만으로 연결이 가능해졌어요.

내가 동의한 정보만 제공되고, 언제든 즉시 전송 중단을 요청할 수 있어요.

초기 492개였던 정보 항목은 API 고도화(2.0)를 통해 720개로 확대됐어요.

사고가 나도 신용정보법에 따른 피해 보상과 책임 기준이 명확해졌고요.

이렇게 어렵고 힘들었던 마이데이터 API 전환은, 결국 금융 소비자들에게 “내 데이터는 안전하다”는 메시지를 전하는 작업이었어요.

그래도 안전을 택한 이유, 현장에서 본 마이데이터 API 전환

API 전환 프로젝트는 솔직히 힘들었어요.

예상보다 훨씬 긴 개발 기간, 수백억 원의 비용, 수천 명의 인력이 투입된 대장정이었어요. 당초 계획했던 2021년 말 적용을 미루고 2022년 1월에야 정식으로 문을 열 수 있었어요.

그런데도 왜 이 고통스러운 과정을 감내했을까요?

편리하다는 이유만으로 고객의 비밀번호를 제3자에게 넘기는 방식은 절대 지속 가능하지 않았기 때문이에요.

21층만 가면 되는데 건물 전체를 열어주는 출입증을 계속 쓸 수는 없었던 거죠. 안전하고 투명한 방식으로 데이터를 다루는 것, 그게 마이데이터 API 전환이 스크래핑보다 안전할 수밖에 없었던 이유예요.

대한민국 금융의 새로운 패러다임이 바뀌는 그 현장에 직접 참여했던 한 사람으로서, 제가 갖고 싶었던 감회는 하나였어요. “금융 마이데이터는 안전하다”는 자부심이었어요.

다음 편에서는 국내 5대 은행 마이데이터 서비스를 정밀 비교해서, 과연 내 주거래 은행 서비스가 가장 똑똑한지 날카롭게 분석해드릴게요.

뱅커노트 (Banker’s Note)
30년 금융 현장의 경험을 바탕으로, 스크래핑의 위험에서 API의 시대로 넘어온 대한민국 디지털 금융의 뒷이야기를 생생하게 기록합니다.

함께 읽으면 좋은 글

• 6편 | 마이데이터 서비스 5대 은행 비교 — 내 주거래 은행이 최선일까?
• 9편 | 마이데이터를 은행이 두려워하는 이유 — 은행 내부에서 본 지각 변동