실시간
뉴스

전문가칼럼

[전문가기고] 더 이상 미룰 수 없는 BaaS 전환, 아키텍처 설계 방안은?

서비스로서의 은행(BaaS)로 전환하는 금융의 미래②

은행업의 본질을 재정의하는 BaaS의 시대가 오고 있다. 서비스로서의 은행을 뜻하는 BaaS는 국내 시중은행들도 주목하는 비즈니스 모델로서 이미 BaaS 생태계 전환을 위한 준비에 나서고 있다. 3회에 걸쳐 전문가 기고를 통해 BaaS 시장의 동향과 구축 방향 등을 알아본다.

<순서>
1편. 은행업의 본질을 재정의하는 BaaS의 시대가 온다
2편. 더 이상 미룰 수 없는 BaaS 전환, BaaS 구현을 위한 아키텍처 설계 방안
3편. 이미 경쟁은 시작되었다! 현재 진행형인 BaaS 전략의 성공 여부를 가르는 출발점

은행권의 초미의 관심사로 BaaS(Banking as a Service)가 부상하면서 플랫폼 구축을 위한 아키텍처 설계 방안에 대한 논의가 본격화되고 있다.

BaaS는 이전에 하던 오픈 API를 통한 부가 서비스 공개와 차원이 다르다. 은행권은 계좌 조회, 계좌 이체, 예금 조회, 대출 조회, 외환 조회 같은 부가 서비스만을 API로 제공해왔다. 은행의 본업에 해당하는 예금과 적금의 수입 또는 유가증권 기타 채무 증서 발생, 자금 대출, 어음 할인, 내외국환 등은 API로 공개하지 않았다.

시스템 측면에서 보면 코어 뱅킹 영역에 있는 서비스는 API를 통해 외부 파트너를 위해 노출하지 않았다. 이런 추세가 BaaS로 인해 바뀌고 있다. BaaS는 은행의 본업과 관련된 서비스를 디지털 상품화하여 파트너 기업에게 제공한다.
그림 1. BaaS를 위한 IT기술 고려 사항
그림 1. BaaS를 위한 IT기술 고려 사항

모든 상품을 디지털로 제공하려면 기술적으로 아키텍처 전략 수립에 많은 시간과 노력을 기울여야 한다. BaaS는 개방형 IT 인프라를 바탕으로 API를 통해 외부 파트너와 개인이 은행의 인프라와 서비스에 손쉽게 접근할 수 있도록 한다. 이런 편의성과 유연성을 보장하는 방식은 크게 두 가지로 나누어 볼 수 있다.

하나는 오픈 API를 핵심으로 프라이빗 클라우드 환경에서 마이크로서비스 아키텍처를 구현하는 것이다. 코어 뱅킹 시스템을 클라우드로 마이그레이션하고 마이크로서비스 아키텍처로 전환하는 것은 신중한 계획과 실행이 필요한 복잡한 작업이다.

간단히 과정을 소개하자면 먼저 클라우드 마이그레이션 및 마이크로서비스 전환 전략이 데이터 개인정보 보호, 보안 및 금융 산업 규정과 같은 모든 관련 규제 요건을 준수하는지 확인해야 한다. 그런 다음 상세 마이그레이션 계획을 수립해야 한다. 마이그레이션은 보통 덜 중요한 시스템부터 시작하여 점차 더 중요한 시스템으로 대상을 넓혀 간다. 이 과정에서 데브옵스(DevOps) 파이프라인이 원활히 흘러 갈 수 있는 조직과 문화를 정착시켜야 한다.

다른 하나는 API 메시업 또는 API 통합을 통해 코어 뱅킹 레거시 시스템을 외부에 노출하는 접근이다. 이 방식의 핵심도 오픈 API다. 레거시 시스템을 최신 애플리케이션 및 서비스에 연결하는 API 계층을 만드는 것이다.

API 메시업 또는 API 통합은 코어 뱅킹 시스템을 통째로 바꾸지 않고 기존처럼 활용하면서 은행 본업에 해당하는 서비스를 외부 파트너에게 제공할 수 있다는 이점이 있다. API 메시업 또는 API 통합을 통한 API 제공 과정을 간단히 살펴보자면 먼저 API를 통해 노출할 대상, 목적, 서비스 범위 등을 포함한 명확한 API 전략을 수립한다.

이 과정에서 단일 API 게이트웨이 또는 여러 서비스를 위한 여러 게이트웨이 등 필요에 가장 적합한 API 메시업 또는 API 통합 유형도 정해야 한다. 전략 수립을 마친 다음에 레거시 시스템과 외부 서비스 사이의 가교 역할을 할 API 계층을 설계한다.

이 계층은 모듈식이고 확장 가능해야 하며 RESTful 아키텍처 및 JSON 같이 표준화된 데이터 형식 사용과 같은 API 설계 모범 사례를 따른다. 이후 API 게이트웨이와 함께 코어 뱅킹 레거시 시스템이 API 계층과 통신할 수 있는 전문 및 프로토콜 자동 전환을 담당하는 API 서버를 구현한다. DevOps 문화를 조성하는 것은 클라우드 및 마이크로서비스 아키텍처를 적용할 때와 다르지 않다.

어떤 접근을 하건 BaaS 구축 후 은행은 개발자 포털을 제공하고, 해커톤을 주최하고, API 사용에 대한 지원과 리소스를 제공하여 내부 및 외부 개발자 간의 협업을 장려해야 한다.
그림 2. BaaS를 위한 아키텍처 설계 방안
그림 2. BaaS를 위한 아키텍처 설계 방안
아키텍처 못지 않게 중요한 것이 오픈 API 전략 수립이다. 은행은 BaaS 구축에 앞서 B2B, B2C 또는 B2B2C 중 어떤 유형에 중점을 둘 것인지 결정하고 API를 통해 노출할 금융 상품 및 서비스 범위를 전략으로 구체화해야 한다.

그리고 RESTful 아키텍처를 사용하고 OAuth 2.0과 같은 업계 표준 인증 및 권한 부여 프로토콜을 통합하는 등 모범 사례에 따라 API를 설계하고 개발할 수 있는 가이드라인도 전략에 반영해야 한다. 더불어 개발자 포탈을 통해 API를 효과적으로 사용하는 방법에 대한 문서, 샘플 코드 등의 리소스 제공을 위한 기준도 세워야 한다.

거버넌스 체계를 세우는 것도 중요하다. 은행은 API에 대한 액세스를 관리하고 제어하기 위한 강력한 거버넌스 구조를 구현에 대한 방안을 전략에 녹여내야 한다. 예를 들어 데이터 개인정보 보호, 보안 및 규정 준수에 관한 정책과 지침을 정의하고 타사 개발자가 은행의 표준을 충족하는지 확인하기 위한 온보딩 및 심사 프로세스를 개발해야 한다.

마지막으로 BaaS 플랫폼 및 API 전략의 성공 여부를 평가할 수 있는 API 사용량, 새로운 파트너십, 수익 창출, 고객 만족도 같은 지표를 만들어 모니터링해야 하는 방안도 구체화해야 한다.
그림 3. 오픈 API 표준 기술
그림 3. 오픈 API 표준 기술

정리하자면 API화된 뱅킹 서비스를 BaaS를 통해 제공하기 위한 아키텍처 설계 및 API 전략 수립은 쉬운 일은 아니다. 하지만 언젠가는 해야 할 작업임에 틀림 없다. BaaS 없는 은행의 디지털 전환은 상상할 수 없는 시대가 코 앞에 다가왔다.
디지털데일리 네이버 메인추가
x