"올해 금융권의 화두는 앱 현대화”

한국IBM 진승의 클라우드컴피턴시센터 상무

"올해 금융권의 화두는 앱 현대화다. 금융 비즈니스와 상품의 변화에 맞게 앱 자체를 재설계해야 한다. 앱이 현대화되지 않으면, 인프라를 클라우드로 바꿔도 비즈니스 민첩성을 위한 탄력성, 확장성, 고가용성 확보에 한계가 있다."

진승의 한국IBM 클라우드컴피턴시센터 상무는 최근 인터뷰에서 국내 금융권의 디지털 트랜스포메이션 흐름에 대해 이같이 말했다.

국내외 금융권은 어느때보다 빠르게 변화하고 있다. 기존의 금융 영역을 지키면서도 디지털 환경에 적합한 새 비즈니스를 모색해야 하는 상황이다. 시중 은행을 비롯해 카드, 보험, 증권 등의 업계도 디지털 트랜스포메이션에 적극적으로 나서고 있다. 진승의 상무에 따르면, 국내 금융권의 디지털 트랜스포메이션은 ‘클라우드 전환’에 초점을 맞춘다. 기존 인프라를 IaaS 형태의 클라우드 서비스로 바꾸는 작업이 활발히 진행되고 있다. 때문에 디지털 전환보다 ‘클라우드 전환’이란 용어가 더 많이 들려온다.

한국IBM 진승의 상무

진승의 상무는 우리나라 금융권에 불고 있는 ‘클라우드 전환’ 바람에 회의적인 입장이다. 많은 금융기관이 인프라 전환에 집중하다보니, 실제 비즈니스 변화에 대응할 수 있는 애플리케이션 차원의 전환이 부족하다는 것이다. 많은 돈을 들려 클라우드 인프라를 갖췄는데, 기존 시스템을 그대로 이동시키다보니 비용 절감도, 비즈니스 민첩성 확보도 달성하지 못한다는 설명이다.

"클라우드 전환 효과는 뭐냐가 이슈다. 인프라 효율화를 통한 비용 절감을 바라지만 현실은 그렇지 않다. 초기 투자 없는 퍼블릭 클라우드는 사용량 과금이라 비즈니스 성장에 따라 비용이 늘어난다. 프라이빗 클라우드는 당연히 선투자를 하니 BEP 시점이 2~3년 이후다. 또 다른 이슈는 금융 비즈니스 모델의 변화다. 핀테크는 큰 문제가 없다. 그런데 금융 상품이 유통산업처럼 변하고 있다. 이벤트성으로 금융상품을 내놓고, 핀테크 채널 외에 상품기획부서가 새로 아이디어를 내고 만들어가는 것이다. 클라우드 전환을 했으니, IT적인 구현이 잘 돼야 보지만, 여기서 삐그덕거린다. 젊은 세대에 인기있는 적금 상품이 시스템 부하 때문에 서비스되지 못한다. 이에 금융권이 인프라만 아니라 비즈니스 민첩성을 가져야 한다는 숙제를 안게 됐다."

금융권이 클라우드 도입 시 범하는 실수는 기존 워크로드를 단순 이전 방식으로 100% 옮기는 것이다. 기존 워크로드를 단순 Lift & Shfit 방식으로 100% 옮길 경우 비용은 증가하고 리스크도 높아진다. 인프라 전환뿐 아니라 클라우드 환경 이점을 최대한 활용할 수 있는 구조로 앱을 수정해야 클라우드 전환의 효과가 나타날 수 있다.

"기존 금융권 앱 체계는 이미 프로비저닝된 것이고, 일정한 트랜잭션을 안정적으로 처리하는 데 초점을 맞추므로 예측 가능하게 시스템을 설계할 수 있다. 반면, 마케팅 이벤트 성격의 앱은 역동적인 변화를 수용해야 한다. 예를 들어, 국내 시중은행들이 금리 좋은 단기 상품을 출시했을 때 IT 시스템이 다운되는 경우가 많다. 이는 앱이 미리 계획된 트랜잭션 용량 처리에 최적화된 형태로 설계됐기 때문에 마케팅 이벤트, 캠페인 형태의 대고객 서비스로 인한 동적인 수요에 탄력적으로 대응하기 어렵기 때문이다. 두 가지 방법을 사용할 수 있다. 하나는 기존 앱을 고쳐서 만드는 ‘컨테이너화’다. 컨테이너를 기반으로 비즈니스 민첩성을 지원하도록 앱을 바꾸는 것이다. 새롭게 처음부터 만드는 앱은 클라우드 네이티브 개발방법론을 적용해 새로  개발하게 된다."

요약하면, 일단 기존 앱과 신규 개발 앱을 컨테이너 기반으로 구축한다. 신규 개발 앱의 경우 클라우드 네이티브 방법론을 처음부터 도입하면 된다. 이렇게 되면 향후 마이크로서비스 아키텍처(MSA)를 도입해갈 때 유리해진다.

많은 기업들이 전략 수립 단계에서 클라우드 네이티브 기반의 앱 현대화를 ‘마이크로서비스 아키텍처’ 기반의 전면 전환으로 접근하고 있다. 하지만 기업이 보유한 기존 앱 중에도 MSA 적용이 가능한 게 있고, 반대인 경우도 있다.

"고객이 이 지점을 혼돈한다. 마이크로서비스아키텍처(MSA)가 버즈워드처럼 도니까 모든 것에 도입해야 한다고 생각한다. 마이크로서비스 아키텍처는 클라우드 네이티브 개발방법론으로 돼야 맞다. 고객이 기존 앱을 MSA로 바꾸길 시도했다가 실패하고, 새로 개발하는 것에만 MSA를 도입한다. 클라우드 네이티브 방법론으로 신규 앱을 만들어서 디지털 금융기업과 경쟁하면서, 기존의 서비스도 컨테이너로 전환해야 한다. MSA는 기술적인 관점에서 애플리케이션 분리와 통합을 강조하는 것이 아니라 비즈니스 도메인 관점의 앱 모듈화를 통해 비즈니스 니즈에 따라 탄력적으로 변경 가능한 구조로의 진화를 목표로 하는 것이다. 따라서 기존 앱에 대한 완전한 이해를 바탕으로 비즈니스 도메인 전환 설계 역량이 확보되지 않은 상태에서 전부 당장 MSA 기반으로 옮기고자 하는 것은 비현실적인 목표다."

앱 현대화를 할 때 왜 하필 컨테이너일까. 이에 대해 진 상무는 인프라 자원을 표준화된 풀 체제로 운영함으로써 효용성(Utilization)을 높이기 위해서라고 설명한다.

"컨테이너 기술의 장점은 이식성이 좋다는 점이다. 또 자원 요구사항의 부하도 적어 경제적인 솔루션으로 알려져 있다. 사실 컨테이너가 중요한 게 아니다. 컨테이너는 기업의 디지털 서비스를 위한 환경일 뿐이다. 인프라 자원을 풀 체제로 가는 것을 목표로 한다. 스펙 기준을 정의해서 표준화하는 것이다. 컨테이너 기반으로 가면, 표준화된 풀을 만들어 두고, 앱 개발이나 실제 서비스나 풀을 가져다가 묶어서 논리적으로 할당해주고 앱을 배포할 수 있게 할 수 있다. 금융회사와 자회사 모두가 표준 풀 안에서 효율성을 높이는게 필요하다. 여기까지 가는 단초가 컨테이너다. 자원을 표준화하고 풀 체제로 유지하면 그에 배포되는 앱도 그 풀에 탑재되기 좋게 바뀌어야 한다. 표준화했는데 어떤 앱은 너무 커서 풀에 예외사항을 만들면 이전과 같아진다. 앱이 표준에서 잘 돌아가도록 어느정도 사이즈로 기존 걸 분할해야 한다."

모듈화, 표준화로 가는 가운데 앱의 구조를 어떻게 컨테이너로 바꿔야 할까.

"은행은 데이터를 제공하는 계층이 있고, 중간에 데이터를 질의해서 가져오는 중간 시스템도 있다. 그 앞에 고객 접점 시스템이 있는 것이다. 모바일이나 웹으로 들어가서 계좌를 조회하거나 이체하는 게 3단계 계층으로 이뤄진다. 일단 고객 접점 부분의 앱은 100% 컨테이너화 대상이다. 여기에 추가로 플러스 알파의 새 기능을 붙일 수 있다. 트래픽 증가에 유연하게 대응할 수도 있고, 새 기능 적용이 빨라진다. 컨테이너화 한다면 개발부터 배포까지 일련의 과정에 데브옵스 툴체인을 넣고, 자동화를 넣어야 한다. 컨테이너화와 클라우드 네이티브를 함께 가져갈 때 아래는 데브옵스로 다 통일돼야 하는 것이다."

한국IBM 진승의 상무

거대한 한덩어리로 이뤄진 코드를 쪼개는 일이 쉬워보이진 않는다. 대대적인 코드 리팩토링이 필요할 수도 있다. 진 상무는 IBM이 역할을 할 수 있다고 설명했다.

"자바 기반 웹 애플리케이션의 경우 WAR 형식으로 내부에서 배포된다. 그리고 여러 WAR를 모아EAR로 통합해서 배포된다. 여기서만 착안해도 쉽게 접근할 수 있다. IBM은 클라우드 트랜스포메이션 어드바이저란 툴을 갖고 있다. 이 툴을 돌리면 고객사의 EAR 앱을 코드 스캐닝 하고, WAR 간의 의존성을 체크한다. 참조하는 부분 가운데 연결을 끊어도 상관없는 것을 찾아내고, 패턴으로 들어간 코드를 찾아준다. 툴이 리포트를 내놓고, WAR 내에 마이그레이션 아티팩트 생성을 가이드한다. 어떤 라이브러리를 교체하라는 추첞도 한다. 이런 기계적 진단 외에도 앞 단에서 전환할 대상 앱을 선정할 때 정성적으로 거를 수도 있다. 컨테이너라이제이션 오퍼니티란 기준이 있다. 코드 자체에 앱 수행되는 패턴을 보니 스파이크가 없고 꾸준하다면 코드를 바꾸지 않아도 된다. 우선순위에서 중간이하고, QA 테스트 시 항상 문제없고 기능 여건 추가없는 히스토리면 굳이 손댈 필요없다. 이렇게 먼저 필터링하고, 컨테이너화 대상을 찾고, 툴을 돌려서 그 대상에 대해서 마이그레이션 아티팩트를 만들면서 간다. 이를 컨테이너라이제이션 웨이브라 표현한다."

MSA는 현재까지 가장 진화된 IT 시스템 체계다. MSA로 가기까지 컨테이너 외에도 많은 준비가 필요하다. 일단 데이터베이스의 문제다.

"MSA로 가려면 데이터도 쪼개 놓은 컨테이너 안에 들어가야 한다. 금융권의 데이터 처리는 중앙집중화돼 있었다. 그걸 분할해서 앱에 넣었을 때 무슨 일이 발생할지 불확실하다. 서비스 중에 데이터에 문제가 생기면, 장애에 대응할 방법이 없다. 데이터는 리스크가 있으므로 단계적으로 현대화하는 게 좋다. 이는 데이터베이스 현대화라고 따로 부른다. 일단 앱만 일단 고쳐도 효과가 나타나므로 앱부터 먼저 바꾸고 새로 만드는 앱을 MSA에 맞는지 보면서 경험을 쌓아야 한다."

MSA나 디지털 전환에서 IT 운영 모델로 많이 거론 되는 게 지속적개발/지속적전달(CI/CD), 혹은 데브옵스(DevOps)다. IT 플랫폼을 컨테이너 중심으로 가면서, 그에 상응하는 개발, 운영 체계를 바꾸는 것이다. 사실 앱 현대화는 이 부분까지 포함한다. 앱 배포 형식은 컨테이너로, 앱 개발 및 운영 프로세스는 데브옵스로 바꾸는 게 필요하다.

"앱 현대화를 하다보면 아키텍처에만 초점을 맞출 수 있다. 앱 구조를 풀에 배포하게 만들어놓고 앱 배포 방식은 전과 똑같이 개발 끝나고 중간에 모아서 스테이징에 넣어서 선검증을 한다. 그를 다시 옮겨서 운영에 적용한다. 프로세스는 그대로인데, 앱을 현대화하고 스크럼으로 2주만에 개발하고, 배포해 3주 후 서비스 출시하려 한다. 품질 보증과 배포 절차가 바뀌지 않다보니 개발은 끝났는데 서비스가 안나오는 보틀넥이 걸린다. 개발부터 테스트, 운영까지 자동화돼야 한다. 이를 건드리지 않고 앱 구조만 바꾼다고 해서 비즈니스 민첩성이 보장되지 않는다."

진 상무는 특정 기술에만 이목이 집중되는 현상을 경계해야 한다고 조언했다. 컨테이너, 마이크로서비스, 클라우드, 데브옵스 툴 등 기술과 솔루션의 단어에 몰입하면 전체적인 프로세스와 체계를 갖추는데 실패할 수 있다.

"보통 유행하는 단어 자체에 초점을 준다. 전체를 다 봐야 한다. 이 모든 게 물려서 IT 인프라부터 그위의 플랫폼, 앱 아키텍처, 그를 사용하는 개발자와 품질검증팀의 거버넌스 프로세스도 바뀌고, 툴도 바뀌어야 한다. 모두 한번에 가줘야 실질적인 민첩성 효과가 나온다. 그래야 운영효율화로 비용절감했다는 효과를 기대하는 게 아니라, 새 수익원을 창출하고, 새 고객을 더 유치하는데 도움을 줘서 매출을 생성시킨다는 효과를 기대할 수 있다. 디지털 전환의 기대 효과는 명확하다. 효율화가 IT뿐 아니라, 조직 자체인 사람, 기술, 프로세스 전반에서 이뤄지는 것이다. 여기서 클라우드란 매우 광범위한 툴인 것이고, 클라우드 자체에서 가치를 찾으면 답이 안 나온다. 현업 관점에서 숙제가 있을 텐데, 그럼 클라우드로 숙제를 해결해볼까 하는 생각이 바람직하다."

그는 일차적인 컨테이너화, 앱 현대화가 디지털 트랜스포메이션의 좋은 출발점이라고 했다.

"컨테이너화는 경영층의 비즈니스 목표 중 하나인 ‘Faster Time to Market’을 디지털 서비스 관점에서 구현하게 하는 기반 기술 요소다. 1차적으로 컨테이너화한 애플리케이션 중 기대효과, 전환 가치 평가를 통해 선별된 대상 중심으로 MSA, 서버리스 기반의 애플리케이션 고도화로 가는 지름길이 마련되는 것이다. 컨테이너화하면 클라우드 서비스 사업자가 제공하는 데이터 분석, AI, IoT,블록체인 등의 신기술 요소를 쉽게 연계해 서비스 개발 생산성을 높일 수 있는 구조로 자연스럽게 진화할 수 있다."