지난 정부부터 디지털 뉴딜 사업으로 명명된 공공기관의 클라우드 전환 사업이 2023년 들어 새로운 국면을 맞고 있다. 원래의 계획은 2025년까지 공공기관의 클라우드 전환율을 100% 달성을 목표로 했지만 새 정부가 들어서며, ‘디지털플랫폼정부’라는 기치 아래 2030년까지 전환을 늦추고 단순한 ‘리프트 앤 시프트(Lift&Shift)’ 방식의 클라우드 전환이 아닌 ‘클라우드 네이티브(Cloud Native)’ 도입으로 대폭 수정되었다. 정부당국은 자체적으로 2022년까지는 클라우드 전환 ‘1기’, 올해부터는 ‘2기’로 구분 짓고 디플정위원회가 추진하는 2기의 경우 마이크로서비스아키텍처(MSA)까지도 적용할 수 있는 클라우드 네이티브의 방향으로 전환되고 있다.

이에 금융기관 또한 단순 클라우드 도입이나 전환이 아닌 클라우드 네이티브에 대한 관심도가 증폭되기 시작했으며, 실제 선도 사례를 중심으로 클라우드 네이티브로의 전환을 위한 다수의 컨설팅 사업들이 포착되고 있다.

이번 리포트를 통해 디지털플랫폼 및 애플리케이션 현대화의 가장 근간을 이루는 클라우드 네이티브에 대한 개념과 실제 금융투자업계에서 선도 도입된 사례를 살펴보도록 하겠다.

클라우드 네이티브 아키텍처 개념

클라우드 네이티브 아키텍처(Cloud Native Architecture, CNA)는 클라우드 환경에서 응용 프로그램을 개발하고 운영하는 방식으로, 하드웨어와 운영체제에 종속되지 않는다. 이를 통해 기업은 빠르고 안정적인 서비스를 제공하며 비용과 시간을 절약할 수 있는 것이다. CNA를 적용하기 위해 MSA(MicroService Architecture), 컨테이너, DevOps 등의 기술이 필요하고, 이러한 기술은 애플리케이션을 작은 단위로 개발하고 운영하거나, 빠른 배포와 안정적인 서비스 제공을 가능하게 한다.

디지털 전환의 ‘인프라=클라우드’라는 공식이 성립하게 되면서 클라우드 네이티브 아키텍처(이하 ‘CNA’)가 자주 언급되고 있다. 우리말로 ‘클라우드 친화적’으로 해석될 수 있는데, CNA를 명확히 정의하거나 이것이 지향하는 목표가 무엇인지 명확히 이해하는 사람들을 그리 많지 않은 듯하다. CNCF(클라우드 네이티브 컴퓨팅 재단)에서는 이를 다음과 같이 정의하고 있다.

영어 원문의 나열된 문구들을 중심으로 CNA에 대하여 일반인들도 알아듣기 쉽게 정의해 보기로 하자. CNCF에서 정의한 내용들 중 몇 가지 키워드가 있다.

‘동적인 환경에서 확장 가능한’, ‘느슨하게 결합된 시스템’, ‘자동화’, ‘최소한의 노력’, ‘벤더 중립적’ 등이다. 이런 키워드들을 살펴보면 CNA가 추구하는 지향점이 무엇인지 정의를 다음과 같이 내릴 수 있다. ‘응용프로그램을 개발 및 운영함에 있어 하드웨어와 운영체제에 비종속적으로 응용프로그램이 호스팅 될 수 있도록 컴퓨팅 환경을 마련하는 것’이다.

알다시피 애플리케이션을 호스팅할 때 늘 인프라와 OS에 대한 호환성이 요구되어 왔다. 과거 메인프레임과 유닉스 시절에는 하드웨어에 대한 종속성이 있었고 2000년대 중반 이후 x86기반이 산업계 표준 하드웨어로 떠오를 때는 윈도우(Windows)나 리눅스(Linux) 같은 OS, 혹은 하이퍼바이저에 대한 종속성이 존재해왔었다. 과거에는 개발자들이 어떠한 애플리케이션을 개발할 때 어떤 플랫폼에 호스팅될 지 예측 가능했지만 현재의 클라우드 세상에서는 이를 예측하기가 쉽지 않다. 개발이 진행되는 기간보다 플랫폼의 변화 주기가 더 짧아지고 이에 대한 선택지가 매우 다양해 졌기 때문이다.

이로 인해 개발자들은 개발 완료 시점에서 결정된 플랫폼과의 호환성을 맞추기 위해 다시 수정하거나 새로 개발해야 되는 최악의 상황을 만나지 않고자 어떤 플랫폼이더라도 호환성이 보장되는 방식의 아키텍처링을 고려하지 않을 수 없게 되었다. 즉 다양한 물리, 가상, 클라우드, OS 배포판, 환경변수 등에 상관없이 애플리케이션이 기동될 수 있는, 플랫폼 환경에 종속적이지 않은 아키텍처를 착안했고, 이것이 CNA의 지향점이다. 다시 말해 CNA의 지향점은 바로 비종속성인 것이다.

이러한 클라우드 네이티브는 클라우드 컴퓨팅과는 차이가 있다. 얼핏 비슷한 개념으로 보이나 두 가지는 확실히 개념이 다르다. 클라우드 컴퓨팅은 사설이던 공용이던 클라우드 서비스 제공자가 사용자의 요청에 따라 컴퓨터의 자원 즉 서버, 스토리지, 네트워크 등의 인프라적 요소를 제공하는 개념이다. 반면 클라우드 네이티브는 클라우드의 특성을 최대한 활용하여 확장성, 안정성, 유연성을 가진 애플리케이션과 서비스를 설계, 개발 및 운영하는 개념이다. 따라서 클라우드 컴퓨팅이 주로 인프라스트럭처 관점에 접근하는 IaaS(서비스형 인프라)라고 본다면, 클라우드 네이티브는 애플리케이션과 개발 프로세스에 중점을 둔 PaaS(서비스형 플랫폼)에 가깝다.

그렇다면 CNA는 왜 대두되었을까? 다음의 3가지 요건을 만족하기 위함이다.

첫째는 속도전이다. 속도전은 비즈니스의 빠른 변화로 인해 애플리케이션의 배포 주기가 매우 짧아졌으며, 신규 혹은 개선된 애플리케이션의 보다 더 민첩한 라이프사이클 관리가 필요해졌다. 또한 이를 개발하기 위해 필요한 인프라의 준비는 자동화된 할당의 개념으로 바뀌어야 한다.

둘째는 무중단이다. 현대의 대부분의 비즈니스 활동은 IT를 근간으로 영위되며, 모바일 혁명으로 인해 때와 장소를 가리지 않고 서비스 요구가 발생한다. 따라서 인프라의 장애 및 재해 시에도 서비스에 영향이 없어야 하며, 애플리케이션의 배포와 롤백 시에도 서비스의 중단을 최소화해야 한다.

마지막은 확장성이다. 특정 이벤트 발생 시 서비스의 요구사항은 폭증할 수 있으며, 서비스 요구사항의 증가에 따라 유연하게 확장할 수 있는 서비스 아키텍처가 필요하다. 더 나아가 멀티 클라우드 간 서비스의 배포와 확장의 수용이 가능해야 한다.

이렇게 CNA가 제공하고자 하는 민첩성, 무중단, 확장성의 요건을 충족하기 위해 또 다음의 3가지 요소가 필요하다.

첫째는 MSA다. 비종속성의 견지에서 보았을 때 애플리케이션이 단일 서비스로 구성될 경우 특정 기능에 대해서만 개선이 필요하거나 신규 기능을 추가할 경우 이들은 단일 서비스 내 서로 종속된 관계(Tightly-coupled)에 놓일 수밖에 없으며, 의도치 않게 전체 애플리케이션에 대하여 영향을 끼칠 수밖에 없다. 따라서 애플리케이션을 작은 서비스 단위로 나누고 필요 시 서로 API를 통해 호출하는 방식의 상호 비종속적인 애플리케이션 아키텍처로 개발하여야 속도전, 무중단, 확장성의 요구사항에 유연하게 대처할 수 있다.

둘째는 DevOps다. 마이크로 서비스 단위로 나누어진 애플리케이션의 소스 코드 관리, 빌드, 단위 테스트, 동적 테스트, 통합 테스트, 배포 등의 애플리케이션의 라이프사이클을 유지할 때 민첩성을 확보하기 위해서는 지속적인 CI/CD의 자동화가 반드시 필요하며, 서비스 배포에 따른 다운타임이 허용되지 않는 만큼 무중단 배포 전략의 수립 또한 필수 불가결하다. 또한 배포된 애플리케이션의 서비스 요구가 폭증할 시 자동화된 서비스 확장과 멀티 클라우드로의 배포를 위한 전략 수립이 있어야 한다.

마지막은 컨테이너다. MSA로 잘게 나누어진 서비스를 호스팅하기 위한 서버의 형태는 무엇이 가장 적당할까? DevOps 구현을 위해 가장 적당한 서버의 형태는 무엇일까? 다양한 클라우드, 하이퍼바이저, OS 배포판에 호환성을 유지하며 애플리케이션을 배포할 수 있는 최적의 서버 형태는 무엇일까라는 물음에 가장 최적의 가상화 형태는 단연 컨테이너일 것이다.

금융권에서 확대되고 있는 CNA의 적용

국내는 금융 IT의 보수적 성향상 클라우드나 클라우드 네이티브의 적용이 해외 사례처럼 활발하지 않다. 하지만 금융권 내 디지털 전환에 대한 요구가 높아지면서 IT 인프라의 무한 확장성, 빠른 비즈니스의 변화에 대비하기 위한 민첩성, 오픈뱅킹에 따른 개방형 아키텍처, 이에 따른 더 높은 수준의 보안을 동시에 충족 시켜야 할 상황에 처해져 있다. 금융권에서는 다음의 영역에서 CNA를 적용하는 사례들이 증가되고 있다.

국내외 금융기관들이 클라우드 네이티브를 도입한 사례는 업종별로 다소 편차를 보이고 있으며, 확실히 국내가 해외보다는 3~4년 정도 시차를 두고 혁신이 진행되고 있다. 어찌 보면 기술은 이미 검증이 되었지만 결국은 실행을 위한 담대함이 언제 발동되는가의 시간 문제일 수 있다.

금융권에서도 클라우드 네이티브 아키텍처의 적용이 확대되고 있다. 여전히 보안과 안정성은 중요한 이슈이기 때문에 클라우드 네이티브 기술은 더 이상 선택 사항이 아니다. 금융회사들은 쿠버네티스와 같은 컨테이너 오케스트레이션 툴을 도입하고, 클라우드 네이티브 아키텍처를 적용, 민첩성과 생산성을 높여 인프라 종속성을 해방하며 애플리케이션의 라이프사이클을 자동화하고 서비스의 유연한 확장성을 확보한다. 국내 금융권에서는 현재 계정계보다는 주로 채널계를 중심으로 클라우드 네티이브의 도입이 활발하게 진행되고 있는 추세다.

CNA를 계획할 때, 의도치 않게 인프라의 구조 방식에 집중할 때가 많다. 즉 클라우드와 인프라 솔루션 제조사의 영업력에 의하여 하드웨어와 가상화 솔루션 중심으로 인프라 구축 사업으로 진행되는 경우가 많다. 성공적인 CNA(프로젝트적 측면에서 애플리케이션의 현대화와 디지털 전환의 근간이 되는 클라우드 인프라를 설계하고 구축하는 행위)를 위해서는 애플리케이션을 어떻게 개발하고 호스팅할 것인가에 집중해야 한다. 풀어서 설명하면 클라우드 중심의 개발과 인프라 구축을 위해서는 반드시 MSA로 애플리케이션을 설계하고 DevOps를 구축해야 하며, 인프라는 컨테이너 기반이어야 한다는 데 집중할 필요는 없다.

MSA로 개발된 애플리케이션은 상황에 따라 물리 서버나 가상서버에 호스팅할 수도 있다. 컨테이너가 더 효율적이기 때문에 컨테이너를 선호하는 것이지 MSA는 반드시 컨테이너에 호스팅되어야 한다는 절대적 등식은 없다. 반대로 기존 모놀리식 구조의 레거시는 컨테이너로 전환이 불가능하다는 등식 또한 성립되지 않는다. 또한 모든 애플리케이션이 DevOps 형태로 조직을 개편하고 CI/CD를 통한 자동화된 배포 방식을 무조건 따라야 되는 것도 아니다. 오히려 복잡도가 거의 없고 한 번 배포되면 변화가 거의 없는 애플리케이션(예를 들어 패키지 소프트웨어나 데이터베이스)은 CI/CD 파이프라인이 굳이 필요 없거나 물리 혹은 가상서버에 호스팅 하는 것이 더 효율적일 수도 있다. 어떻게 보면 CNA는 민첩성과 확장성이 요구되는 환경에서 더욱 큰 효과를 발휘한다. 따라서 대세보다는 생산성 극대화를 위하여 조직이 필요한 개발 환경과 운영 인프라의 필요 요소는 무엇인지를 먼저 정의 내려야 할 것이다.

* 저작권법에 의하여 해당 콘텐츠는 코스콤에 저작권이 있습니다.

* 따라서, 해당 콘텐츠는 사전 동의없이 2차 가공 및 영리적인 이용을 금합니다.