1. API 소개 및 국내 금융권 Open API 플랫폼 구축 사례
2. 국내 금융권 Open API 플랫폼 구축 프로젝트와 주요 API들
3. 금융권 CNA(Cloud Native Application) 개발 방안
4. API 활용 방안과 API관리 시장 전망
[ 필자소개. 박용우, 유니버셜리얼타임㈜ 대표이사 ]
- 건국대학교 공과대학 컴퓨터공학과 박사
- JCO(JavaCommunity.Org한국자바개발자협의회) 초대회장
- 코드인스펙션 및 거래추적 등 애플리케이션 품질관리 전문
- 클라우드 네이티브 애플리케이션 구축 전문
- 국내 금융권 Open API 프로젝트 다수 수행
개인정보보호법에 따라 모든 금융사에는 DMZ가 존재하며, 금융사에 따라 DMZ와 내부망 사이에 채널망이 존재할 수도 있다.
DMZ는 외부에서 접근 가능한 구간이므로, ① API 게이트웨이에서 개인정보를 취급할 경우, API 게이트웨이를 채널망 또는 내부망에 두고,
DMZ 구간에는 API게이트웨이를 연계하기 위한 WEB 서버를 둔다. 내부 정보보안팀에서 큰 이상이 없다고 판단할 경우, API게이트웨이를 DMZ 구간에 두기도 한다.
다음으로, ② API 포털은 외부 이용기관의 관리자 또는 개발자가 접근할 수 있어야 한다.
또한, API포털은 회원가입을 하게 되므로 개인정보보호법에서 정의하고 있는 개인의 고유식별정보를 취급하거나 저장할 수 있다.
이러한 이유로, API 포털은 DMZ구간에 두는 것이 아니라 내부망(또는 채널망)에 두고, 외부에서 접근할 수 있도록 연계하기 위한 WEB서버를 DMZ에 두게 된다.
마지막으로, API 포털의 대부분의 주요 기능은 API게이트웨이의 admin API를 호출하는데, 이를 위해서는 API포털과 API게이트웨이의 망구성에 따라,
reverse proxy를 허용해 줘야 한다.
다음으로, 금융사에서 기 구축하여 홈페이지 또는 모바일 서비스를 하고 있는 레거시 서비스를 Open API로 서비스하기 위하여
③API 엔드포인트를 제공하기 위한 방법은 다음과 같이 3가지 방안이 존재한다.
1. API게이트웨이의 플러그인 커스터마이징
API게이트웨이에서 제공하는 플러그인(Custom Assertion)을 개발하여 레거시 서비스를 연계하는 방법
2. 자체 API 서버 구축
전자정부FW나 스프링FW, 또는 자바 RESTful 웹서비스FW 참조구현(RI; Reference Implementation)인
Jersey를 이용하여 REST API를 구현하여 레거시 서비스를 연계하는 방법
3 API 엔진 도입
MCI/EAI/FEP 등 인터페이스 시스템에서 관리하는 레거시 서비스에 대해 Open API로 서비스하기 위한,
인터페이스의 전문을 읽어들여 Open API 서비스를 위한 인터페이스 및 API를 생성하고,실행 함. 이와 함께, API실행 시에 체이닝거래 통제 및 거래추적 기능을 제공함.
각 방안으로 레거시 서비스를 연계하기 위해서는 각각 MCI/EAI/FEP 인터페이스 시스템을 이용하여 연계하거나 또는 직접(directly) 연계하는 방법이 존재한다.
다음으로, 금융사에서 기 구축되어 운영중인 ④레거시 시스템에서 제공하는 다양한 서비스는 폰뱅킹 채널, 홈페이지 채널, 또는 모바일 채널 등을 통해 이미 서비스를 제공하고 있다. 이러한 레거시 서비스에 대해 APIM 솔루션을 적용하여 API채널을 구축함으로써, 충성도 높은 고객을 확보하고 있는 다양한 제휴사를 통해 Open API를 이용한 신규 서비스를 할 수 있게 된다.
마지막으로, 토스와 같은 전문 핀테크 업체 등 ⑤ 외부기관은 금융사에게 오픈한 Open API를 활용하여 ⑤ 다양한 서비스를 개발하고,
이 서비스를 해당 핀테크 업체의 충성도 높은 고객을 위한 프리미엄 서비스를 제공할 수 있다. 이러한 다양한 서비스를 개발하는 개발자는 API 포털을 통해 해당 금융사에서 제공하는 Open API에 대한 명세확인 및 테스트를 진행하거나 Q&A 또는 포럼을 통해 해당 Open API에 대해 학습할 수 있다.
국내 금융권 API엔드포인트 구현 방안 비교 앞에서도 간단하게 살펴본 국내 금융권 API엔드포인트 구현 방안에 대해 비교해 보면 다음과 같다.
위의 표에서 보여주고 있는 금융권 API엔드포인트 구현 방안은
1) API게이트웨이에서 제공하는 방식을 이용하여 Custom Assertion을 개발하는 방법,
2) 기존의 홈페이지 서버 또는 모바일 서버를 구축하듯이 API 서버(WAS)를 구축하는 방법,
3) API Engine을 도입하여 레거시 서비스에 대한 전문을 기반으로 API 및 연계 인터페이스를 자동으로 생성하고, 안정적이고 편리한 API운영•관리 기능을 제공하는 방안 등이 있다.
API엔드포인트를 구현하기 위한 3가지 방법은 모두 레거시 시스템을 연계하는 MCI/EAI/FEP 등 인터페이스 솔루션을 연동하거나
또는 레거시 시스템을 직접(directly) 연계하는 세부적인 방안이 가능하다
국내 금융권 Open API 플랫폼의 H/W 및 S/W 구성 방안 구축하기 위한 H/W 및 S/W 구성에 대해 살펴보면 다음과 같다.
Open API 플랫폼을 구축할 때, API 게이트웨이/포털 WEB, API 게이트웨이, API 포털 WAS, API 엔진 등 주요 APIM 컴포넌트들은
기본적으로 운영 2대를 active-active 형태로 이중화 하고, 테스트(검증) 1대를 추가로 구성한다.
Open API 플랫폼을 구성하는 모든 서버는 기본적으로 Linux OS(또는 VM Ware)를 위한 하드웨어로 구성되며,
각 사의 정보보안 정책에 따라서는 Linux OS에 Secure OS가 함께 설치될 수 있다.
하드웨어는 CPU는 8Core, 메모리는 16GB 또는 32GB이며, 디스크는 500GB *2개 등을 갖는다.
다음으로, API 게이트웨이, API 포털, API 엔진 등 각 하드웨어에 설치되는 각각의 SW 구성은 다음과 같다.
API 게이트웨이를 Appliance로 설치할 경우, 복잡하게 생각할 필요없이 사양에 맞는 하드웨어만 있거나 또는 VMWare가 설치된 하드웨어만 있으면 된다.
API 포털은 기본적으로 Tomcat WAS를 사용하며, MySQL EE DBMS에 대해서는 고객사에서 구입하여 설치되어 있어야 하며,
만약 API 포털에 개인정보를 저장할 경우, DB 암호화 솔루션도 추가로 설치해야 한다. 마지막으로, API 엔진은 Postgre SQL 및 Redis 등의 오픈소스를 사용하고 있으며,
WAS 역시 기본적으로 Tomcat 오픈소스를 사용하고 있다. 물론, WAS는 JBoss, JEUS, WebLogic 등과 같은 상용 소프트웨어로 대체가능 하며,
Postgre SQL DBMS 및 Redis 글로벌 캐싱 솔루션 역시 Oracle 등과 같은 상용 DBMS 소프트웨어로 대체 가능하다. 필요에 따라, 백업 소프트웨어 등이 추가로 구성될 수 있다.
국내 금융권 Open API 플랫폼 구축 사례
비록 국내에서도 금융권에서의 사업이 활발해졌지만 한계점이 존재했다. 핀테크 기업들에 대응하고자 API 사업을 시작했지만, 구체적인 비즈니스 모델에 대한 고민이 부족했기 때문이다.
현재는 다양한 금융서비스들이 출현했지만 초기에는 개인정보보호법과 같은 컴플라이언스를 준수하면서도 이용자의 편의를 위한 방안으로 API를 활용하는 수준에 머물러 있었다.
금융권으로 시작된 API 사업은 이제 타 산업으로도 확산되고 있다. 운송업계에서도 공유경제 플랫폼을 구축하기를 원한다.
화물 배차 정보가 공개되면 운송기사들의 수익성을 한층 더 높여줄 수 있는 서비스가 만들어질 수 있기 때문이다. 제조업계에서도 API 체제 구축에 긍정적이다.
아직 비즈니스 측면에서의 고민은 부족하지만, 늘어나는 개발 요구에 빠르게 대응하고 적용하면서 내부 효율화를 도모할 수 있을 것으로 보고 있기 때문이다.
국내 금융권 Open API 플랫폼 API 개발 사례
NH핀테크 오픈플랫폼에서도 다양한 Open API를 제공하고 있으며, 여기서 제공되는 각 Open API는 판매하기 위해 각각에 가격이 부여되어 있다.
실제 NH핀테크 오픈플랫폼에서 제공하는 Open API 목록 및 각각의 API 정책에 대해서는 다음의 API 소개 싸이트를 참고하기 바랍니다.
https://nhfintech.nonghyup.com/svcportal/home/html/UIPD2080.html
다음은 필자가 참여한 Open API 플랫폼 구축 프로젝트에서 개발한 Open API 목록이다.
생명보험사에서 Open API 서비스를 제공하기 위해 공개한 Open API 목록이다. 아래의 표에서도 보여주고 있듯이, 모든 Open API는 HTTPS 방식으로 호출되기 때문에 URL을 정의해야 하며,
Open API를 실행하기 위한 요청/응답 데이터는 JSON 포맷을 따른다