인사이트리포트

들어가며

마이데이터 서비스

정보주체의 뜻에 따라 개인정보를 통제하고 활용하는 ‘마이데이터’ 개념의 확산과 함께 국내에서도 2020년 8월 데이터 3법 시행과 2023년 3월 개인정보 전송요구권이 포함된 개인정보 보호법 개정안이 공포되며 본격적인 마이데이터 서비스의 시대가 열리고 있다.

특히, 개인신용정보의 통합 조회를 제공하는 금융분야 마이데이터 서비스는 2022년 1월 태동 이후 23년 5월 현재 총 64개 업체가 본허가 사업자로 참여하고 있으며, 31개 업체가 허가심의 대상으로서 또한 참여를 준비하고 있다.

서비스에서 활용할 마이데이터의 범위도 지속적으로 확대되고 있는데, 금융분야는 22년 하반기부터 표준 API 2.0 업그레이드 과정을 통해 신용정보 제공 범위가 확대되었고 개인정보보호위원회 주관의 전 분야 마이데이터도 22년에 5대 분야(교육, 국토·교통, 문화·여가, 유통, 정보·통신) 표준화를 진행한 데 이어 23년에도 고용·노동 등의 분야로 그 범위를 확대할 예정이다.

마이데이터 사업자의 고민

현재 시장에 출시된 마이데이터 서비스는 신용정보 통합 조회, 금융상품 추천, 자산 및 소비 분석 등으로 UX/UI 편의성 외에는 큰 차별점 없이 유사하다

그렇다 보니 사업자로서는 보다 고도화된 차별적인 서비스에 대한 고민이 깊어지고 있으며 그 노력 중 하나가 수집 데이터의 범위를 확대함으로써 정보주체에게 더 개인화되고 생활에 밀착된(여러 분야가 연계된) 서비스를 제공하려는 것이다.

이를 위해 다수 사업자가 마이데이터 제공 범위의 확대를 요청해 왔으며, 이에 부응하여 마이데이터 표준 API 2.0은 장기인보험 외 단기보험이나 물보험, 펀드 외 신탁/ISA 투자상품, 개인형퇴직연금(IRP) 외 확정급여형(DB)/확정기여형(DC) 등으로 그 범위가 확대되었다.

하지만, 이와 같은 표준 API 변경을 참여기관이 무작정 반길 수 만은 없는 것이 API를 통해 정보를 제공해야 하는 정보제공자도 그렇지만 이 API를 호출하고 그 응답 데이터를 수집하는 사업자에게도 표준 API의 변경이 서비스 기획 및 시스템 구축·운영에 부담을 주기 때문이다.

더욱이 한 번의 구축이나 업그레이드로 끝나는 것이 아니고, 적용시점 별 단계적 적용이나 이후 마이데이터 범위 확대와 그에 따른 지속적인 표준 API 변경 대응이 상시적으로 필요하다.

이에, 변경된 API와 확대된 정보를 기반으로 한 서비스 기획 뿐만 아니라 △마이데이터 표준 API 규격에 빠르게 대응하고 △운영 중인 서비스에 문제가 발생하지 않게 안정적인 동작을 보장하도록 구축·운영되는 시스템이 더욱 서비스의 경쟁력이 될 것으로 예상된다.

그리고 개인신용정보를 넘어 다른 마이데이터 정보까지(의료 및 공공정보, 개인정보 보호법 개정안의 개인정보 전송요구권에 따라 진행될 개인정보) 그 범위가 확대되면서 이러한 시스템에 대한 요구는 갈수록 커질 것이다.

[그림1] 금융분야 개인신용정보 정보맵

[그림2] 의료공공분야 정보맵

마이데이터 테스트 환경의 필요성

서비스 경쟁력을 갖추기 위해 마이데이터 표준 API와 그 변경에 빠르고 안정적으로 대응하는 시스템을 구축·운영하기 위해서는 각 개발 단계별로 마이데이터 생태계를 반영한 테스트 환경이 필요하게 된다.

• 서비스 구축

마이데이터 서비스는 업권별 정보제공자에 대한 API 호출을 통해 개인신용정보를 수집하는 것이 기본으로서, 모든 업권의 모든 API에 대한 호출 테스트가 필요하다.

또, 종합포털-인증기관-정보제공자 참여주체 모두와 API 연계가 되어야 서비스 구축이 가능하므로, 이 3가지 API(지원-인증-정보제공) 모두를 테스트할 수 있어야 한다.

• 표준 API 변경 대응

마이데이터 표준 API는 2021년 9월 1.0 버전 최종본이 나온 이후 2022년 10월 2.0 버전이 공표되어 1년 정도 주기로 메이저 버전이 변경되고 있다.

하지만 API는 참여기관의 현실적인 요구나 자체적인 규격 오류 등으로 인해 한 번에 최종 확정되지 않고 여러 회에 걸쳐 변경이 발생하게 되며, 실제로도 2.0 버전 공표 전에 1차(22년 12월), 2차(23년 4월), 3차(23년 5월), 4차(23년 6월) 반영 과정이 있다.

이와 같은 API 변경에 대응하려면, 추가·변경된 API에 대한 테스트 데이터 확보, 기존 서비스 기능의 리그레션(regression) 여부 확인을 위한 테스트가 필요하다. 더욱이 API 주요 버전이 변경되면 서비스의 기능적합성 심사도 새로 받아야 하는데, 표준 API 2.0 버전을 반영한 실제 사업자 목록을 보면 23년 4월 기준 16개로 총 60여 개 사업자 중 30퍼센트에 지나지 않다.

이와 같이 API 변경에 대한 대응 수준에 따라 사업자 간 차이가 발생하면, API 변경을 신속하게 한 사업자는 보다 풍부한 정보 수집을 통해 사용자에게 더 매력적이고 창의적인 서비스를 제공할 수 있음은 자명할 것이다.

• 통합 및 성능 테스트

마이데이터 서비스 시스템 구축을 위해서는 단위 테스트, 통합 테스트, 성능 테스트 과정이 모두 필요하다.

이 중 통합 테스트를 위해서는 다수의 고객 계정과 해당 고객의 업권별 테스트 데이터가 구비되어야 하며, 성능 테스트를 위해서는 다량의 동시 호출에 대한 응답 서버가 필요하다.

타 정보제공자 대상으로 이런 통합·성능 테스트를 한다면 테스트 고객 데이터를 맞추는 것도 일이고 또 고객별로 충분한 자산 데이터를 가지고 있지 않을 수 있다. 또한 성능 테스트는 집중적인 시스템 부하가 걸리는 일이라 이를 받아 줄 정보제공 서버를 섭외하기도 쉽지 않다.

따라서 다수 고객·업권·자산 유형별 테스트 데이터가 확보된 가상의 정보제공 테스트 환경을 자체 개발 환경 내에 갖고 있어야 하며, 이 테스트 환경의 가상 정보제공자 호출로써 테스트를 진행해야 효율적인 진행이 가능하다.

• 서비스 신규 기획과 검증

마이데이터 서비스는 API 변경이 되지 않는 상황에서도, 새로운 기획이 추가되거나 새로운 업권·정보제공자를 지원하여 서비스 범위와 상품이 확장됨에 따라 계속적인 변경이 발생한다. 새로운 데이터로 기획된 서비스를 빠르고 완성도 있게 개발하기 위해서는 해당 업권의 정보제공자와 실제로 연동해서 테스트하는 것보다는, 해당 업권의 특성을 반영한 테스트 데이터를 확보하고 서비스 기획에 대한 프로토타입(prototype)을 빠르게 개발하는 것이 효율적이다.

마이데이터의 전 업권을 지원하는 테스트 환경이 있다면 테스트 환경에서 제공하는 해당 업권의 API와 테스트 데이터를 통해 빠르게 프로토타이핑하여 서비스 기획과 그 구축 시스템에 대한 검증이 가능하다.

특히, 추후 금융분야를 넘어 훨씬 다양한 분야에 존재하는 개인의 정보를 마이데이터로서 활용할 수 있게 되면 새로운 정보와 API를 활용한 서비스 기획과 이에 대한 검증·프로토타이핑이 더 중요해질 것이다.

[그림3] 마이데이터 서비스의 확장

마이데이터 테스트의 어려움

위에 기술한 바와 같이 마이데이터 서비스 구축과 운영을 효율적으로 하기 위해서는 상시적인 테스트 환경이 필요하지만, 실제로 구축하는 일은 생각보다 쉽지 않다.

표준 API가 변경되어 새로운 API가 추가되었다고 가정해 보겠다.

사업자는 공개된 표준 API 명세에 따라 API 호출 시스템을 개발한 후 △자체 단위 테스트 △마이데이터 테스트베드를 통한 테스트 △실 정보제공자와 CBT(Closed-Beta Test) 등을 통해 검증하게 된다.

하지만 테스트 과정이 어렵고, 또 일부의 정상적인 데이터로만 테스트가 가능하다는 맹점이 있다.

마이데이터 테스트베드를 통한 테스트는 △테스트를 위한 소스 수정 필요(특정 HTTP 헤더 추가 등) △전 업권에 대한 테스트 데이터가 구비되어 있지 않음 △실 환경과 유사한 데이터가 아닌 랜덤(random) 데이터 등의 이유로 테스트 범위가 제한적이다.

실 정보제공자와 붙는 CBT가 서비스를 테스트할 수 있는 가장 확실한 방법이지만, 해당 업권의 정보제공자와 인적·물리적 연결을 맺기가 어려워(담당자 매칭, 방화벽 오픈, 테스트 계정 매칭 등) 실제로는 주요 업권의 일부 정보제공자와만 테스트를 하는 실정이다. 정보제공자마다 표준 API 대응 속도나 상황이 달라 시행일정 전 유예기간 동안에는 해당 버전을 지원하는 정보제공자를 찾는 것도 일이 된다.

전 업권을 위한 테스트 환경은 데이터 양과 업권 특성에 따른 데이터 특성을 고려해야 한다는 점도 마이데이터 테스트를 어렵게 한다.

한 고객이 하나의 정보제공자에만 가입되어 있다고 가정해도 자산 목록, 자산 유형별 기본/추가 정보, 최대 5년치 거래내역 등 최소 수십여 개 데이터를 확보해야 하고 성능 테스트를 위해 다수의 고객이 필요한 경우라면 그 어려움은 더 커진다.

그리고 어렵게 테스트 데이터를 확보하여 기본적인 표준 API 호출 테스트를 한다고 해도, 업권별 자산 유형에 따른 테스트 케이스(test case)를 추가적으로 고려해야 하는 문제가 남아 있다.

가령 은행업권 마이너스 통장은 수신인 동시에 여신(대출)의 성격도 가지기 때문에, 마이너스 통장의 정보를 정확히 수집하기 위해서는 수신 API 외에 대출 API의 호출이 추가적으로 필요하다. 이에 따라 △마이너스 통장이 있는 케이스 △정보 수집 이후 마이너스 통장이 해지된 케이스를 모두 테스트해야 서비스에서 정상적인 정보 수집이 가능하다.

카드업권 가족카드의 경우도 카드 명의자와 사용자가 다르고 또 명의자는 사용자의 일부 정보만 조회할 수 있기 때문에 가족카드를 보유한 테스트 고객이라는 케이스를 확보해야 한다. 이런 케이스를 사전에 확보해서 테스트하지 않으면 명의자에게 사용자의 민감 정보가 노출되는 서비스의 방어 로직이 제대로 되어 있는지 사전에 확인하여 오류를 예방하기가 어렵다.

[그림4] 자산 유형에 따라 달라지는 API 호출

 그리고, 고객의 다양한 자산 상황에 따른 시나리오를 가정한 테스트도 요구된다.

서비스 운영 중에 겪은 실제 사례 중에 △200여 개의 계좌를 가진 고객 △100개 이상의 정보제공자에 가입된 고객 △일 거래내역이 1만 건 이상인 고객이 있었는데, 이런 예외적인 상황을 고려하지 못한 채 서비스가 기획·구축되면 사용자 UX가 매끄럽지 못하고 처리 성능이 보장되지 않는 시스템 구조 설계가 나오게 된다.

마이데이터 서비스는 타 마이데이터 서비스와 비교가 쉽다 보니, 예외 상황에 대한 UI/UX를 잘 설계해야 사업자 브랜드에 부정적인 영향을 주지 않는다. 표준 API 규격에 50여 개의 예외 상황 코드가 정의되어 있는데 각 상황에 대한 메시지를 사용자에게 적절히 제시하고 행동을 유도하려면 여러 가지 상황을 시뮬레이션 할 필요가 있다.

아래와 같은 다양한 예외 상황을 감안해 사용자에게 노출할 메시지와 UX를 다듬고 API 호출 재시도 등의 시스템 설계를 고려해야 한다.

• 정보제공자로부터 응답이 늦어 요청 타임아웃이 발생하는 경우
• 정보제공자로부터 서버 에러를 응답 받는 경우
• 고객이 전송 요구한 여러 정보제공자 중 일부 정보제공자가 정보 수집이 실패하는 경우
• 서비스에서 요청 값을 잘못 전달해 클라이언트 에러를 응답 받는 경우
• 정보제공자의 시스템 점검이나 장 초반/마감 등 정보 수집이 불가능한 경우
• 전송요구 기간이 만료되어 정보 수집이 실패하는 경우
• 전송요구 기간이 도래되어 고객에게 전송요구 연장 알림을 보내는 경우 등
• 고객이 정보제공자로부터 탈퇴한 경우 등

마이데이터 테스트 환경 구축을 위한 고려 사항

마이데이터 서비스의 테스트에는 위에서 살펴본 것과 같은 어려움이 존재하기 때문에 API mock(단순 가상 응답) 같은 기존의 API 테스트 환경으로는 대응이 어렵습니다.

따라서 마이데이터 서비스 신규 구축이나 기존 서비스 확장 시에는 구축 기간 단축과 지속적인 유지보수를 위해 마이데이터를 위한 별도의 테스트 환경을 자체 구축하거나 마이데이터 테스트 특화 솔루션을 이용하는 방식으로 진행하게 될 것입니다.

이렇게 테스트 환경을 설계·구축 혹은 솔루션을 선정·도입할 때 고려해야 할 내용을 전체적으로 정리하면 다음과 같습니다.

• 전 업권 API 지원

서비스 기획 및 개발에 폭넓게 활용할 수 있으려면 일부 주요 업권이 아닌 전 업권의 API에 대한 가상 응답을 지원해야 한다. 총 100여 개에 달하는 업권 API의 가상 응답이 현실성 있게 제공되어야 필요할 때 언제라도 서비스를 점검하여 기능적합성 심사, 서비스 업그레이드 등 주요 이벤트에 빠르게 대응할 수 있다.

• 전 마이데이터 참여주체 지원

마이데이터 전송요구를 위한 완전한 과정을 테스트할 수 있으려면 표준 API를 제공하는 다른 참여주체(종합포털 및 인증기관)에 대한 가상 응답을 지원해야 한다.

특히, 마이데이터 종합포털은 사업자가 종합포털로 API를 호출하는 경우 외에 종합포털이 사업자로 API를 호출하는 경우도 있기 때문에 사업자 API 서버에 대한 가상 호출도 지원해야 한다.

• 신속한 표준 API 반영

API 추가, 항목의 필수 값이나 길이 변경, 코드 값 추가 등 표준 API가 변경될 때마다 그 변경 내용을 테스트 환경이 빠르게 반영해야 서비스의 빠른 검증과 안정적인 개발이 가능하다.

• 다양한 테스트 데이터와 시나리오 지원

표준 API에 따른 테스트 데이터를 자유롭게 생성하거나 사업자 보유 테스트 데이터를 활용할 수 있는 방법을 제공해야 필요에 맞는 데이터를 확보할 수 있다.

또, 고객의 다양한 자산 상황별 시나리오를 테스트할 수 있는 데이터를 제공해야 이를 통해 다양한 API 호출 흐름과 서비스 로직을 점검하여 문제를 파악할 수 있다. 가령 은행업권 마이너스 통장의 테스트 데이터라면 수신 정보 외에 대출 거래내역 데이터가 함께 제공되어야 한다.

• 예외 상황 지원

정상적인 API 응답 외 예외 상황을 테스트할 수 있는 기능을 제공해야 한다.

△표준 API 규격에 정의된 예외 상황 코드를 가상 응답 △정보제공자와의 네트워크 단절 상황 시뮬레이션(접속 불가, 처리 지연에 따른 타임아웃 등)을 통해 서비스에서 예외 상황을 감안한 처리를 쉽게 할 수 있다.

마치며

정보주체의 개인정보로 마이데이터 표준화가 확장되고 신용정보도 지속적으로 추가됨에 따라 마이데이터를 활용하는 마이데이터 서비스의 기회는 커져 갈 것이다.

이에 따라 마이데이터 서비스 참여와 확장을 원하는 사업자도 늘어가고 서비스 시스템의 구축과 변경이 요구되며, △개발 기간 단축 △다양한 상황을 선제적으로 고려한 안정적인 서비스 개발 △표준 API 변경에 대한 빠른 대응 △기획된 서비스의 빠른 구축과 검증을 위해서는 이 시스템 개발을 처음부터 뒷받침하는 테스트 환경의 중요성도 함께 부각될 것이다.

에스코어는 컨설팅과 IT 역량을 결집해 마이데이터 사업자가 필요로 하는 다양한 솔루션과 서비스를 제공하고 있다. 에스코어와 함께 마이데이터 사업에 참여해 지속적인 성공에 이르기를 기대한다.