인사이트리포트

상상하지 못했던 변화

지난 2022년 9월, 마이데이터 사업자들에게 청천벽력이 떨어졌다. 바로 “(의견조회용)금융분야 마이데이터 표준 API 규격 v2.0.pdf” 가 그것이다.

2021년부터 은행권을 시작으로, 카드, 보험, 금융투자, 핀테크 등 금융분야에서 몰아치던 마이데이터 서비스 구축사업이 이제 슬슬 자리를 잡아가고 있는데 마이데이터를 수집하기 위한 표준 API 가 업데이트가 예고된 것이다.

물론 표준 API 업데이트를 예상하지 못한 것은 아니다. 오히려 초기에 시스템을 구축한 사업자들은 표준 API v1.0 이 완성되어가는 과정에 구축 사업을 진행했기 때문에 그 누구보다 API 변경을 수시로 겪으며 서비스를 개시하였다. 하지만 서비스 오픈 후의 표준 변경은 얘기가 다르다. 알고 있었다고는 하더라도 막상 맞닥뜨려보니 예상했던 것과는 다른 혼돈이 그 안에 자리 잡고 있었던 것이다.

그간 API 업데이트에 대한 예상은 다음 2가지 맥락으로 예상되었다. 모든 API 가 v2 로 업데이트 되면서 일부 추가되는 API 가 있을 것이다. 최소 6개월간의 반영 유예기간을 두고, 정보제공자가 우선적으로 반영한 후 구축된 API 를 마이데이터 사업자가 연동하면서 v1, v2 가 동시에 제공되는 기간이 주어질 것이다.

결과적으로 두 가지 모두 예상을 빗겨나갔다. 이번 리포트를 통해 좀 더 자세히 들여다보자.

금융분야 마이데이터 표준 API 규격 v2.0 분석

일단, 변경항목은 8개 업권에서 총 66개로 파악된다.

숫자를 잘못 센 게 아니다. 총 11개 업권 중에 8개 업권만 v2.0 으로 변경된다. 할부금융, 보증보험, P2P 3개 업권의 API 는 v1.0 이 유지된다. 이 정도로 당황하기엔 이르다. 구체적인 항목을 들여다보자.

이 66개 항목 중 24개 항목은 API 변경이 아닌, 설명 변경과 정의 추가이다. 그렇다고 해서 시스템에 영향을 주지 않는다는 뜻은 아니다. 주로 v1.0 에서 명확하게 제시하지 않아서 정보제공자와 사업자들이 문의했던 내용들을 명시하는 부분이다 보니 일부 정보제공자와 사업자는 새로운 정의에 따라 구현 내용을 바꿔야 할 수도 있다. 예를 들면, 리프레시토큰의 유효 기간을 전송 요구 기간보다 같거나 길게 설정해야 한다는 항목 등이다.

나머지 42개 항목 중 33개 항목은 2022년 12월까지 정보제공자가 새롭게 반영할 내용이다. 이 중 15개 항목은 신규 추가 분으로 DB형 퇴직연금정보와 같이 새로운 자산을 제공하는 것으로, 사업자는 새롭게 제공되는 데이터에 맞춰 서비스를 추가/개편해야 한다.

그 외 23개 변경 항목은 2023년 6월까지 정보제공자가 반영할 예정이다. 이 중 신규 추가 분은 11개 항목으로 자동이체 등록정보나 피보험자 정보조회 등 기존 자산의 추가정보가 이에 해당한다. 주의 깊게 봐야 할 부분은 어떤 정보가 제공되느냐 보다 어느 시점에 제공되느냐다, 같은 v2.0 API 지만 절반은 2022년 12월부터, 나머지 절반은 2023년 6월부터 제공된다. 한가지 더, 10개의 변경 항목은 2022년 12월에 반영되었다가 2023년 6월에 변경된다.

아마 종전에 Open API 등을 통해 수집 시스템을 개발해본 개발자나 PL 이라면 이 부분에서 가슴이 먹먹해지는 것을 느낄 것이다. API 가 2차례에 걸쳐 나눠 반영되는 것도 곤란한데, 일부는 그 사이에 내용이 변경된다. 이 변경은 하나의 API 내에서 필드별로 나뉘는 것처럼 간단한 내용도 있지만 하나의 필드에 필수 제공 여부가 바뀌는 특이한 케이스도 존재한다. 수집한 데이터는 DB 에 적재 후 서비스하기 때문에 DB 의 필수 여부 스키마(Scheme)가 달라지는 것이다.

이런 단계별 API 반영은 마이데이터 사업자에게 어떤 영향을 주게 될까?

마이데이터 사업자의 고민

정보제공자는 주어진 기간에 맞춰서 v2.0 12월분과 6월분을 공개하고 최종적으로 22년 12월을 마지막으로 v1.0 을 중단하면 된다. 수월하게 진행하려면 2022년 12월까지 12월분, 6월분을 모두 구축해두고 시기에 맞춰 오픈/변경하면 된다. 별로 어려운 일은 아니다.

심지어 v2.0 에서 제외된 3개 업권은 아무런 변경 없이 강 건너 불구경을 할 수 있다.

반면 마이데이터 사업자는 고민에 빠진다. 2022년 12월부터 새로운 데이터가 들어오게 되는데 이걸 반영하려고 구축사업을 하자니 6개월 후에 또 다시 6월분을 반영한 구축사업을 해야 하기 때문이다. 마이데이터 서비스 하나로 한 해에 두 번의 구축사업을 하자니 부담이 클 수 밖에 없다. 그래서 2023년 6월 이후에 v2.0 을 모두 반영하는 한 번의 구축사업을 추진하는 결정을 내리게 된다. 이건 매우 합리적이다. 분명히 2023년 한 해는 마이데이터 사업자에게 주어진 유예 기간이기 때문에 최대한 넉넉하게 사용하면 비용과 일정을 모두 맞출 수 있다. 2023년 상반기 동안 일부 금융정보를 수집하지 못하기는 하지만 그렇다고 서비스에 지장을 주는 것도 아니다. v1.0 API 로 수집한 정보는 기존의 서비스를 그대로 지속 시켜줄 것이다.

그런데 몇 가지 걸리는 점이 있다. 만약에 어느 발 빠르고 여유로운 경쟁 사업자가 2023년의 시작과 동시에 서비스를 리뉴얼 한다면? 6개월 동안 고객의 이탈이 없기를 기도해야 하나? 새로 수집할 수 있는 데이터로 신박한 서비스를 해버리면?

또 다른 걱정은 구축사업을 수행할 때 발생한다. 분명 1년가량 잘 운영하던 서비스지만 새롭게 참여하는 개발사가 기존 v1.0 용 서비스를 이해하고 v2.0 으로 전환하는데 어려움은 없을까? API 가 변경된다는 건 DB 와 서비스가 모두 변경된다는 뜻이다. 아예 새롭게 DB 를 구축하는 경우라면 좀 나을지도 모르겠지만 이번 변경은 부분적이다. 아마 지난 구축사업에서도 11개 업권의 표준 API 를 분석해 이해하고 서비스를 기획하고 시스템을 설계하느라 개발사는 상당한 공을 들여야 했을 것이다. 그런데 남은 것은 운영시스템에 동작중인 서비스와 개발 산출물, 운영용 인수인계 문서뿐이다. v2.0 을 받아든 개발사는 v2.0 내용 파악도 버거운데 레거시 산출물과도 씨름해야 하는 것이다. 이 때 고려할 수 있는 유일한 해결책은 기존 개발사를 다시 선정하는 것인데, 이 또한 공정거래규정을 위반하지 않도록 주의해야 한다.

고민 없는 사업자도 있다

그렇다. 이런 고민을 하지 않는 사업자도 있다.

첫 번째는 충분한 개발인력을 바탕으로 서비스를 직접 개발한 사업자다. 마이데이터 개발/운영팀을 갖추고 있어서 어떤 변화에도 발 빠르게 대응하고 있는 곳이다. 아마도 손에 꼽겠지만 분명히 실존한다.

두 번째는 표준API 를 이용한 마이데이터 수집/적재를 마이데이터 서비스와 분리시켜 개발한 사업자다. v1.0 표준문서를 보고 향후 업데이트를 고려해 장기적인 관점으로 설계해둔 개발사가 있다면 가능하다. 또 다른 방법으로는 마이데이터 수집/적재를 전담하는 솔루션을 도입했다면 가능하다. 장기적인 설계는 솔루션 개발사에서 담당했을 테니 개발사는 서비스 개발에만 집중했을 것이고, 이후 표준API 변경에 대해서도 솔루션이 책임져줄 것이니 말이다.

이제 슬슬 답안을 보여줄 때가 된 것 같다.

마이데이터 수집/적재 시스템

마이데이터 서비스는 3가지 대외연계 포인트를 갖는다.

첫 째는 중앙 관제를 담당하고 있는 신용정보원의 마이데이터 종합포탈이고, 두 번째는 통합인증을 위한 인증서를 주고받는 통합인증기관, 마지막으로 고객의 신용정보를 보유하고 있는 정보제공자다.

종합포탈은 한 곳이지만, 통합인증기관은 현시점에서 10여 곳에 이르며, 정보제공자는 수백 곳에 지속해서 증가하고 있다. 이 경우 마이데이터 서비스가 이 모든 기관을 필요에 따라 연계하며 정보를 주고받는 것은 매우 복잡하다. API 호출/제공을 위해 API Gateway 를 거치는 것처럼, 마이데이터 수집/적재를 위한 별도의 시스템을 구성하고, 이를 통해 대외기관과의 통신을 일원화 한다면 마이데이터 서비스는 수백 곳의 기관에 대해 수백 개의 API 호출을 할 필요가 없어진다. 단지, 특정 고객의 정보에 대해 수집요청을 하고, 수집결과 적재된 데이터를 이용해 고객에게 서비스하면 된다. 이렇게 마이데이터 수집/적재에 대한 추상화 계층을 구성한다면 향후 표준API 가 어떻게 바뀌더라도 대응 지점을 구분하여 관리가 가능하다. 표준API 를 분석하는 대응 팀과 신규서비스 개발팀을 두고 각자의 일정에 맞춰 독립적으로 운영할 수도 있다.

마치며

이미 일부 사업자들은 자신들만의 플랫폼으로, 또는 전문 개발사가 제공하는 솔루션으로 이 구성을 도입했고, 이번 표준 API v2.0 에 대해 느긋하게 관망하고 있다. 이전부터 마이데이터 서비스에서 표준 API 를 직접 호출하도록 구성된 경우라면 지금이 변화할 기회다. 이왕 구축사업을 준비해야 한다면 한 걸음 더 먼 곳을 바라보며 제대로 준비하자.

아이디어는 주어졌다. 이제 이 아이디어를 실천할 의지를 일으키고, 협력자를 찾아야 할 때다.

데이터가 점점 중요해지는 디지털 트랜스포메이션의 시대에, 전사적으로 산출/관리해야 할 운영정보는 점점 많아지고, 데이터 정확도에 대한 요구사항도 점점 높아지는 상황에서, 데이터를 잘 활용하기 위한 기업들의 노력이 좋은 결실을 맺어 혁신 성장의 기틀을 세우기를 기원하겠다.