유럽의 주요 지역(EU 및 EEA)은 2018년 1월에 PSD2가 발효된다. 이를 기점으로 고객이 은행 또는 파트너에 의해 만들어진 애플리케이션을 통해 자신의 데이터에 접근할 수 있는 오픈 뱅킹 서막이 오를 것이다. 현재 유럽 주요 은행들은 오픈 뱅킹 대응을 위해 오픈 API를 중심으로 한 디지털 생태계 구축을 서두르고 있다.

그림2. BBVA 오픈 API 마켓(BBVA은행은 오픈 플랫폼 전략을 통해 비금융까지 포괄하는 비즈니스 확대를 추진하고 있음. 2017년 5월, BBVA API Market을 오픈하여 고객의 뱅킹 데이터를 3rd 파티가 활용할 수 있게 하고 있음)

오픈 API를 통해 고객 데이터를 은행 외부의 새로운 서비스 공급자에게 개방하는 것이 확대됨에 따라, API 런칭 및 라이프사이클 관리, 보안성 강화가 중요해지고 있다. 이로 인해 은행 내ㆍ외부 접점에 API 게이트웨이(Gateway) 운영을 고려하는 사례가 많아지고 있다.

금융업에서 오픈 API 기반 생태계의 안정적 구축과 운영을 위해 필요한 API 게이트웨이 구성 요구사항을 정리하면 아래와 같다.

- API Proxy 중재, 조율ㆍ조합, 데이터 변환

- 오픈 API 등록 및 관리, 통제를 위한 거버넌스

- 오픈 API에 대한 보안(접근 제어, 민감 정보 암호화, 유통 데이터 무결성 검증, 위협 방어)성

- 오픈 API 포털 및 커뮤니티, 샌드박스 지원

- 클러스터링, 유량제어, 프로토콜 변환 등 기술 지원

- 사용자 및 조직, 협약, 미터링 및 빌링, 모니터링ㆍ리포트

- 오픈 API 설계, 개발ㆍ문서화 등 개발 라이프사이클 지원

위 요구사항을 충족하며 API 게이트웨이를 구축하는 경우, 일반적으로 아래 [그림3]와 같이 API 게이트웨이 통해 은행 내부 코어시스템과 외부 서비스를 직접 연결하는 아키텍처를 구성할 것이다.

 

그림3. API 게이트웨이(GW)와 코어 뱅킹 시스템 간 직접 연계 방식의 오픈 API

이 경우 생태계에 참여하는 외부 서비스 제공자(3rd 파티)들로부터 생산된 기술 환경과 수준이 다양한 서비스를 연동하기 위해서는 ① 코어 뱅킹 시스템이 직접 빈번한 변경을 통해 대응하거나, ② API 게이트웨이에서 외부 서비스 요구에 따라 코어 뱅킹 시스템과의 연결 코디네이션을 담당해야만 하는데 두 가지 방식 모두 부담스러울 수 밖에 없다. 특히, 코어 뱅킹 시스템을 통한 대응은 서비스 연계 개발에 소요되는 리드타임이 길어질 수 있고 안정적인 운영을 추구하는 코어 업무 및 운영조직과의 충돌이 우려될 수 있다.

앞에서 제기한 문제를 해소하기 위해서 보다 면밀한 오픈 API 전략에 기초해 API 오픈 범위, 적합한 게이트웨이 구성 모델 선택과 게이트웨이와 코어시스템 간 명확한 R&R정의가 수반된 API 게이트웨이 구축이 필요하다.

먼저 API 게이트웨이 적용 형태를 살펴보면, 서비스 제공 수준에 따라 [그림4]와 같이 3가지 형태로 분류할 수 있다.

A. Proxy 모델은 API 게이트웨이의 가장 전형적인 형태로 뱅킹 서비스를 게이트웨이 후선에 구축하여 게이트웨이의 서비스 부담을 최소화하되 외부로의 오픈, 보안성 및 기술적인 공통사항 처리에 집중하는 모델이다.

B. 조합 및 조율 모델은 뱅킹 서비스 시스템에서 제공하는 기초 서비스를 게이트웨이에서 조합ㆍ조율하여 새로운 서비스를 제공하는 모델로서, 후선 뱅킹 시스템의 변경을 최소화하면서 새로운 서비스를 제공할 때 유용하다. 단순한 조합 수준으로 해결할 수 있으면, API 게이트웨이의 조합 기능을 활용하여 처리한다. 또한 다소 복잡하거나 추가 로직이 필요하면, 기존의 재사용 가능한 서비스 시스템과 추가 서비스만 구현한 시스템을 게이트웨이에서 조합하여 처리한다. 하지만, 이러한 서비스 유형이 많아지면 API 게이트웨이의 성능 및 관리 비용이 증가하고, 시스템 간 역할과 책임이 모호해질 수 있어 아키텍처에 대한 철저한 관리와 통제가 필요하다.

C. API 자체 서비스 모델은 API 게이트웨이에서 개발 도구(프로그래밍 언어 또는 SQL 등 데이터베이스 질의 언어)를 이용해 자체적으로 서비스 로직을 구현한 형태이다. 새로운 비즈니스 모델에 대한 개념검증(PoC) 및 프로토타입을 개발하거나, 단순한 업무지만 빠른 개발이 필요할 경우 적용하면 효과적이다. 하지만 서비스가 많아지고 지속성이 길어지면, 게이트웨이의 부담이 커지고 보안 위협에 노출될 가능성을 높아져 전반적 시스템 안정성이 저하될 수 있다.

제공서비스의 양, 복잡도, 조직 역할과 역량에 적합한 API 게이트웨이 적용 모델을 선택해야만 한다.

API 오픈 범위 및 참여자에 따라서 API 게이트웨이 R&R이 달라진다. 오픈 범위를 금융회사 내부, 금융그룹 내부, 금융업계, 금융과 비금융 사이, 규제 수준이 상이한 국가 사이 등 오픈 범위에 따라 제공 서비스 및 보안 요구 수준이 달라지므로 초기에 그 범위를 명확히 해야 한다. 금융회사 내에서는 공용 API 게이트웨이를 구축하여, 외부 오픈이 필요한 API는 한 곳에서 관리한다. 금융그룹 내에서는 각 계열사별로 API 게이트웨이를 구축하여, 고객 및 그룹 외부 니즈(Needs)에 신속하게 대응하고 그룹 시너지, 브랜딩 및 일관성을 위해 대표 API 게이트웨이를 구축하는 방향을 권고 한다. 

별도의 오픈 플랫폼이 있는 경우에는 플랫폼의 역할에 따라 API 게이트웨이 구성과 역할이 달라진다. 외부 조달 서비스(outside-in)와 금융회사 내부 서비스(inside-out)를 모두 오픈 플랫폼의 프론트엔드를 통해 제공할 경우, API 게이트웨이는 플랫폼 내부 모듈로 구성하며, API 게이트웨이는 서비스 요청을 플랫폼의 코어로 전달하는 역할만 한다. 만일 오픈 플랫폼이 외부 조달 서비스를 담당할 경우에는API 게이트웨이를 플랫폼과는 독립적으로 구성하며, 금융회사 내부 서비스 제공을 위해서는 직접 코어 뱅킹 시스템과 연계한다. 

 

고객의 대표적인 API 사용 케이스는 [그림5]와 같다. 

①과 같이 고객이 금융회사 외부 3rd 파티 앱을 통해 뱅킹 서비스를 이용할 경우에는 API 게이트웨이는 외부로부터 요청받은 서비스를 오픈 플랫폼 코어에 전달할 수 있도록 처리한다.

②와 같이 코어뱅킹을 통해 처리한 결과를 외부에 제공할 경우, API 게이트웨이를 통할 것인지 그렇지 않을 것인지 결정이 필요한데 금융회사 내ㆍ외부를 모두 포괄하는 양방향 API 접근 통제를 위해서는 게이트웨이를 경유하는 것을 권고한다.

③과 같이 금융회사 오픈 플랫폼 자체 앱에서 내부용(Private) API를 접근할 때, 오픈 플랫폼 코어를 직접 호출할 지, API 게이트웨이를 경유할 것인지 여부를 결정해야 한다. 이 경우 주로 오픈 플랫폼 코어를 직접 접근하게 되는데, 이를 게이트웨이에 등록 관리함에 따른 일원화된 보안, 정책 및 거버넌스 적용의 장점과 게이트웨이 미등록 시 얻을 수 있는 개발 생산성 및 성능 개선 효과에 대한 의사결정이 필요하다.

최근 EU, 영국, 미국 등에서는 금융, 의료, 통신, 공공 등 여러 산업분야에서 진행중인 마이데이터(MyData)나 미국 의료 및 에너지 산업에서 진행중인 블루ㆍ그린 버튼(BlueㆍGreen Button)과 같은 오픈API를 이용한 고객 데이터의 개방과 공유가 점차 확대되고 있다.  우리나라도 이러한 변화에 대비하여, 본격적인 오픈 뱅킹 및 API 전략을 수립하고, 앞서 설명한 API 게이트웨이 구성을 포함한 안정적인 오픈 아키텍처를 구축할 필요가 있다. 앞으로 기업에게 API 경제(Economy)에서의 경쟁력 확보가 시장 주도권 확보를 위한 필수조건이 될 것이다.

- 끝 -