MSA, 쿠버네티스, 데브옵스 등 기술 기준 요구…애플리케이션 단 접근해야
[아이티데일리] 기업들의 클라우드로 전환은 이제 거부할 수 없는 흐름이 됐다. 애플리케이션이 비즈니스 경쟁력을 좌우하는 상황에서 클라우드가 주는 유연함과 확장성 없이 고객의 다양한 요구사항에 대응할 수 없게 된 것이다. 그렇다고 무작정 클라우드 전환만을 서두를 수는 없다. 클라우드 전환만으로 애플리케이션의 유연함과 확장성을 담보할 수 없기 때문이다. 기업들은 클라우드가 주는 장점을 온전하게 누리는 방안을 모색하기 시작했으며 ‘클라우드 네이티브(Cloud Native)’라는 개념이 문제의 해결책으로 떠오르고 있다. ‘클라우드 네이티브’는 클라우드 바람이 불고 있는 국내 클라우드 시장에서도 관심의 표적이 되고 있다.
클라우드 네이티브 중요성 부각
기존 클라우드 컴퓨팅의 대명사로 여겨져온 서비스형 인프라(IaaS)는 애플리케이션을 개발하기 위한 서버, 스토리지 등 주로 컴퓨팅 인프라 자원에 초점이 맞춰졌다. 하지만 실제 기업의 비즈니스를 책임지는 애플리케이션의 효율을 높이는 데에는 직접적인 영향을 미치지 못했다. 기업들은 애플리케이션을 효율적으로 설계, 개발, 배포, 운영하기 위한 방안을 찾아나섰는 데 그 해답으로 클라우드 네이티브에 주목하기 시작했다.
네이티브(Native)의 사전적 의미는 ‘선천적인’, ‘본래’ 등이다. 사실 네이티브라는 용어는 디지털 환경에 친숙한 10~20대를 일컫는 ‘디지털 네이티브 세대’라는 말에 사용되며 우리에게 친숙하게 다가왔다. IT 분야에서 네이티브라는 용어는 이제 클라우드에 접미사로 붙어 사용되고 있을만큼 널리 사용되고 있는데 ‘클라우드 환경에 친화적인 애플리케이션’을 위한 개념과 기술을 의미한다.
클라우드 네이티브라는 개념은 2015년 클라우드 네이티브 컴퓨팅 재단(CNCF, Cloud Native Computing Foundation)에서 처음 내세웠다. 클라우드 컴퓨팅 모델의 장점을 최대한 활용할 수 있는 애플리케이션을 개발하고, 구축하며 실행하는 방법론을 의미한다. 설계할 때부터 클라우드 환경에 맞게 애플리케이션의 아키텍처를 설계해 클라우드 환경에 대한 종속을 없애겠다는 것이 골자다. 이 방법론에는 기술적인 요소와 솔루션, 조직 문화 등이 포함된다.
클라우드 네이티브는 기업들이 애플리케이션 경쟁력을 확보할 수 있다는 점에서 애플리케이션 혁신의 새로운 트렌드로 떠올랐다. 현재 대부분 기업들은 애플리케이션을 기반으로 비즈니스를 하고 있다. 이는 곧 애플리케이션의 경쟁력이 기업의 비즈니스 경쟁력과 직결된다는 것을 의미한다. 자동차 회사인 메르세데스 벤츠부터, 전통적인 제조사 제너럴일렉트릭(GE)까지 대부분 기업들이 애플리케이션 전문기업을 표방하고 있다는 점이 이를 잘 보여주고 있다.
기업들은 고품질의 애플리케이션과 고객의 피드백을 빠르게 반영하기 위해 클라우드 네이티브에 투자하고 있다. 전통적인 애플리케이션 구조로는 고객의 피드백을 유연하고 신속하게 반영하는데 한계가 있다. 인프라 트렌드가 클라우드로 변하는 과정에 발맞춰 새로운 애플리케이션 구조 역시 바뀌어야 한다는 것이다. 클라우드 네이티브 환경에 최적화된 애플리케이션은 종속성을 없앨 수 있을 뿐만 아니라 개발에서 관리까지 전반적인 라이프사이클을 효율적으로 개선할 수 있다.
특히 최근들어 멀티, 하이브리드 클라우드의 수요가 늘어나면서 클라우드 네이티브의 중요성은 더욱 강조되고 있다. 멀티, 하이브리드 클라우드는 복수 개의 클라우드 인프라를 활용하는 방법론으로 애플리케이션이 다양한 CSP의 클라우드 환경에서 운영된다는 것을 의미한다. 달리 말하면 정도의 차이는 있겠지만 클라우드 서비스 사업자(CSP)에 종속될 수밖에 없다는 뜻으로 종속을 탈피할 수 있는 새로운 기술이나 방법을 강구해야 한다는 것이다.
이에 대해 이진현 맨텍 상무는 “CSP는 무슨 하이퍼바이저를 사용하는지, 인프라에 대한 구조는 어떠한지 구체적으로 말해주지 않는다. 이는 개발자가 기존에 개발했던 애플리케이션이 어떠한 인프라에 탑재될지 모른다는 의미다. 때문에 당장 문제가 발생하지 않더라도 향후 호환성에 문제가 발생할 수 있게 되며, 타 CSP로의 전환도 힘들어지게 된다”고 설명했다.
이러한 문제는 클라우드 네이티브로 해결할 수 있다. 일반적으로 클라우드 네이티브를 구성하는 3가지 기술 요소로 마이크로서비스 아키텍처(MSA, MicroService Architecture)와 컨테이너(Container) 그리고 데브옵스(DevOps) 개발 방법론 3가지를 꼽는다. 클라우드 네이티브는 인프라의 종속을 탈피할 수 있다는 점 때문에 특히 멀티, 하이브리드 클라우드 사용이 늘어날수록 주목도가 높아지고 있다.
Q. 클라우드 네이티브를 구현하기 위해 조직이 어떻게 변해야 하는지.
A. 핵심은 애자일하게 바뀌어야 한다는 점이다. 개발자나 운영자가 경직된 업무 프로세스 상에서 정해진 업무만 하는 것이 아니라 서로 반복적으로 협업하면서 사이클을 구성할 수 있어야 한다. 세상이 바뀌면서 사람들은 다양한 서비스와 빠른 서비스를 원한다. 이에 대응하기 위해 애자일한 방식으로 조직 구조가 바뀌어야 한다.
아울러 다양한 업무를 할 수 있도록 재교육도 제공해야 한다. 실제 한 고객사 중 과거 서버, 네트워크 등 인프라 운영을 도맡아 수행하던 직원이 있었는데, 그 직원은 기업에서 클라우드 네이티브 환경으로 팀을 축소하자 기존 해오던 업무를 그만둘 수밖에 없었다. 또 이 직원은 클라우드라는 새로운 기술을 익혀야 한다는 두려움에 떨어야 했다. 이러한 직원이 생겨나지 않도록 기업은 재교육을 통해 신기술을 익힐 수 있도록 지원해야 한다.
Q. 유연하게 조직 구조를 개선한 사례를 소개해달라.
A. 아무래도 클라우드 기술 역량이 높은 기업이 조직 구조를 유연하게 잘 만들고 있다. 대표적으로 게임사가 그렇다. 게임사는 새로운 게임 서비스를 개발하는 직원, 운영하는 직원 등 모두 IT에 친숙하다. 이들 직원의 클라우드 기술 역량은 상당히 높은 수준이다. 실제로 한 고객사는 컨테이너 개발자가 타 운영팀 직원들과 협업하길 원했고, 직원들도 이 개발자와 다양한 작업을 수행했다. 그만큼 수평적이고 유연한 조직 구조라는 것이다. 또 직원들 역시 신기술에 거부감이 그리 크지 않아 유동적으로 팀을 구성하고 싶어 하는 것으로 알고 있다.
Q. 네이버클라우드는 클라우드 네이티브를 어떻게 지원하는지.
A. 고객이 SI 기업과 기초적인 컨설팅을 끝낸 후 애플리케이션 개발과 설계 단계에 돌입했을 때 네이버클라우드가 투입된다. 네이버클라우드는 고객이 설계하고 개발하고자 하는 애플리케이션을 클라우드 환경에서 최적화될 수 있도록 MSA, 데브옵스, CI/CD, 컨테이너, 쿠버네티스 등 클라우드 상품을 제안하고, 또 이를 토대로 아키텍팅 작업도 지원한다.
클라우드 네이티브를 제대로 구현하려면 컨설팅에 많은 투자가 필요하다. 우리는 고객에게 허황된 목표를 심어주지 않는다. 고객이 클라우드 네이티브를 통해 가치를 만들어내고 신기술을 도입해 비즈니스 토대를 마련하고자 목표를 제시할 때 다양한 상품으로 지원한다. 클라우드 네이티브는 사실 CSP에게 불리한 면이 있다. 매출면에서 고객이 종속되는 것이 좋지만 클라우드 네이티브는 그 반대이기 때문이다.
그럼에도 네이버클라우드는 고객이 애플리케이션을 혁신하기를 원한다면 종속을 피할 수 있는 다양한 상품을 제시하고 있다. 추후 고객은 우리의 상품 품질을 보고 지속적으로 관계를 이어갈 것이라고 확신한다.
세 가지 요소 갖춰야
클라우드 네이티브는 인프라에 대한 접근보다 애플리케이션에 대한 접근에 초점이 맞춰져 있다. 애플리케이션을 얼마나 신속하게 배포할 수 있고, 애플리케이션이 인프라의 종속을 얼마나 탈피했는지가 중요하다는 얘기다.
일반적으로 클라우드 네이티브를 구현했다고 평가할 수 있는 기준으로 마이크로서비스 아키텍처(MSA)와 컨테이너 개념, 데브옵스 개발 방법론 등 3가지를 꼽는다.
먼저 MSA는 기존 온프레미스 제품이나 인프라를 클라우드로 옮겨 사용하던(Lift and Shift) 애플리케이션의 구조를 클라우드 환경에 적합하도록 아키텍처를 잘게 나누는 아키텍처 방법론이다. MSA는 처음부터 애플리케이션 아키텍처의 여러 기능을 한데 묶어 통으로 설계하는 것이 아니라, 지속적으로 변화할 수 있는 구조로 구성해 고객이 요구할 때 혹은 비즈니스 환경이 변할 때 대응할 수 있도록 유연하게 만드는 것이 핵심이다.
현재 국내 많은 기업이나 기관들이 사용하는 애플리케이션은 하나의 큰 덩어리 형태인 모놀리식(Monolithic) 아키텍처가 대부분이다. 기능을 업데이트하거나, 버그를 개선하기 위해서 애플리케이션의 모든 기능을 멈춰야만 하는 구조다.
그러나 MSA는 애플리케이션을 서비스 단위의 블록으로 잘게 나눠 구성한다. 특정 기능을 업데이트하거나 버그가 발생했을 때 문제가 있는 서비스 블록만 중지한 후 업데이트하는 방식이기 때문에 나머지 서비스들은 정상 구동된다. 최근 국내 기업과 공공기관에서 MSA로 아키텍처를 개선하려는 움직임을 보이고 있는 것도 이런 이유 때문이다.
그렇다면 서비스 블록을 나누는 기준은 무엇일까. 이에 대해 한기웅 네이버클라우드 클라우드 솔루션 아키텍트팀 리더는 “각 MSA 서비스 블록을 구분하는 기준은 기업마다 다르다. 가령 A라는 쇼핑몰 기업에서는 장바구니 기능과 주문취소 기능을 하나의 서비스 블록으로 구성할 수도 있지만, B라는 게임사에서는 아이템 구매 기능과 결제 연동 기능을 하나의 서비스 블록으로 구성할 수 있다”면서, “기업의 비즈니스 전략에 맞게 서비스 블록을 구성하면 된다. 1개의 블록에 1개의 기능을 담던, 2~5개의 기능을 담던 기업의 비즈니스에 적합하게 구성하면 된다”고 설명했다.
이 과정에서 기능들이 API로 구성돼 있다면 이를 관리하고 API 호출을 처리할 수 있는 ‘콩(Kong)’이나 ‘엔진엔스(NginX)’ 등의 오픈소스 API 게이트웨이가 앞단에 위치해야 하고, 컨테이너 기반 서비스 메시(Service Mesh)로 구현했다면 ‘이스티오(Istio)’와 같은 오픈소스를 활용해 연동하면 된다.
다음으로 컨테이너의 활용도 중요하다. 컨테이너는 2000년대 중반에 처음 소개된 개념으로 기업들의 애플리케이션 개발환경을 유연하고 민첩하게 만들 수 있도록 해준다. 컨테이너가 클라우드 네이티브의 핵심인 이유는 개발 환경과 운영 환경의 간극을 좁혀 클라우드의 종속 없이 애플리케이션을 어디서든 자유롭게 배포하고 운영할 수 있기 때문이다. 컨테이너는 컨테이너라는 그릇에 애플리케이션과 구성 기능을 이미지화 시킨 후, 이를 ‘라이브러리(lib)’, ‘바이너리(bin)’ 폴더에 옮겨 넣기만 하면 운영 환경이 다른 OS라도 구동할 수 있다는 이점이 있다.
일반적으로 애플리케이션은 개발자가 개발한 환경에서 원활하게 구동된다. 하지만 개발 환경에서 문제없이 운영되던 애플리케이션도 환경이 바뀌면 문제가 생기기 마련이다. 일례로 개발자는 우분투 OS 환경에서 SW를 개발했지만, 운영팀이 다른 OS를 사용하게 되면 개발 환경에서 보여줬던 기능과 성능에 차이가 발생할 수 있다. 하지만 컨테이너라는 하나의 박스에 애플리케이션을 구성하는 기능을 담을 경우 하단 인프라의 종속을 없애 민첩성을 확보할 수 있다. 클라우드 네이티브 환경을 구현하기 위한 인프라로 컨테이너가 떠오르는 이유이다.
다음으로는 데브옵스 개발 방법론을 구현해야 한다. 데브옵스는 개발과 IT 운영사이의 소통과 협업 및 통합을 강조하는 애플리케이션 개발 방법론으로 빠르게 개발하고 배포하는 데 초점이 맞춰졌다. 애플리케이션 개발을 빠르게 하기 위해선 ‘계획’, ‘개발’, ‘테스트’, ‘릴리즈’, ‘운영’ 등 5단계를 각 단계에 맞는 툴을 사용해 일련의 과정을 하나의 자동화 파이프라인으로 만들어야 한다.
특히 데브옵스 개발 방법론이 효과를 거두기 위해서는 조직 부분도 개선돼야 한다. 김대환 클루커스 클라우드 컨설팅 그룹 매니저는 “기업의 조직적이 애자일(Agile)하게 합쳐져야 한다. 애자일하게 합쳐진다는 말은 개발 부서와 운영 부서가 작은 단위의 팀으로 구성돼야 한다는 의미다. 이는 사실 현업에서는 그리 반길만한 일은 아니다. 통상 개발과 운영부서는 조직 속성상 약간의 갈등관계에 있다. 다만 해외에서는 이 두 부서가 서로 친하면 친할수록 기업의 조직 구조는 애자일해진다는 말도 있다. MSA, 데브옵스가 갖춰진 클라우드 네이티브를 추구한다면, 기업의 조직도 잘게 나뉘어야 함은 물론이고 개발과 운영, 배포, 테스트 등 모든 업무를 한 팀에서 유기적으로 진행할 수 있어야 한다”고 강조했다.
레드햇 관계자 역시 “직원들의 역할을 점검해 직무를 재정의하고 지속적인 재교육을 수행해야 한다. 이것이 디지털 혁신을 위한 필수요소”라면서, “내부에서 유능한 인재를 유지할 방안을 모색하는 동시에 조직의 계층 구조를 없애고 부서 간의 협업문화를 조성해야 하며, 빠른 시작과 경험에 익숙한 조직 문화를 만들어야 한다”고 조언했다.
기업들이 위에서 언급한 3가지 방법론을 구현하는 것은 쉽지 않다. 이와 관련, 나무기술 관계자는 “서비스형 플랫폼(PaaS) 기술은 MSA, 서버리스, API·이벤트 인프라 제공 및 관리 등 각종 요소 모듈 서비스를 포함하는 클라우드 네이티브에 맞춰졌다”면서, “다만 이와 같은 기술은 어렵고 복잡해 직접 확보하기가 어렵다. CSP는 퍼블릭 클라우드 형태로, PaaS 기업은 구축형 서비스로 클라우드 네이티브의 기술을 제공하고 있다. 비즈니스에 맞게 이 솔루션과 서비스를 사용한다면 클라우드 네이티브 환경을 구현할 수 있을 것”이라고 설명했다.
MSA 핵심은 서비스 블록 통신체계…API와 서비스 메시 비교해야
업계 관계자들은 클라우드 네이티브를 구성하는 요소 가운데 특히 MSA의 중요성을 강조한다. 그도 그럴 것이 컨테이너와 데브옵스 등 2가지 개념과 방법론은 애플리케이션을 구성하는 아키텍처가 잘게 나뉘어 있어야 한다는 전제조건 즉 MSA를 요구한다. 그래야만 마이크로서비스 아키텍처로 구성된 애플리케이션을 각 기능 별로 컨테이너에 담아 쿠버네티스로 관리할 수 있고, 잘게 나뉜 애플리케이션을 신속하게 개발하고 배포하며 관리하고 수정할 수 있는 데브옵스 파이프라인을 적용할 수 있기 때문이다.
MSA는 사실 클라우드 네이티브와 함께 나온 새로운 개념이 아니다. 17년 전 서비스 지향 아키텍처(SOA, Service Oriented Architecture)라는 지금의 MSA와 비슷한 개념이 존재했었다. SOA는 애플리케이션을 비즈니스적 의미를 갖는 기능 단위로 묶어 표준화된 호출 인터페이스를 통해 서비스 컴포넌트로 재조합해 업무를 구현하는 아키텍처를 의미한다.
지금 MSA가 떠오르고 있다는 것은 어찌보면 SOA가 실패했다는 의미일 수 있다. 비즈니스 로직에 집중하고 기능을 중심으로 서비스를 분리한다는 개념인 SOA는 MSA와 여러모로 유사한 부분이 많다. SOA는 분산처리 환경에서 발생하는 문제를 해결하기 위해 엔터프라이즈 서비스 버스(ESB, Enterprise Service Bus)를 사용했지만, 당시의 서비스 블록 간의 통신 기술, 기능 등의 이유로 처음 크게 주목 받았던 것과는 달리 성과를 보지 못했다.
이에 대해 박종하 메가존디지털 이사는 “ESB는 SOA 단에 위치해 서비스 블록 별로 통신을 담당하는 장치였다. 하지만 중앙집중형으로 구성된 ESB는 공통 기능이 거대해지면서 이를 원활히 처리하지 못했다. 당시 RDB 중심의 애플리케이션 구조를 유지한 형태로 설계한 것이 부족함의 이유”라고 설명했다. 그는 SOA는 기존 모놀리식에서 MSA로 가기 전 과도기적인 구조를 지향했지만, MSA가 성공한 이유에 대해 서비스 블록의 응집도를 높이고, 결합도를 최대한 낮추는 설계, 그리고 서비스 블록 간의 API 통신을 처리할 수 있는 기술을 들었다. 지금의 블록 간의 통신 연계 기술로 MSA를 구현할 수 있다는 것이다. 박종하 이사는 “MSA를 구성하는 방식에 따라 통신 방식도 나눠진다. 각 블록이 API로 구성됐다면 API 게이트웨이를, 컨테이너 기반 서비스 메시로 구성했다면 쿠버네티스 기반 서비스 메시 ‘이스티오’로 구성하면 가능하다”고 설명했다.
현재 MSA 방식으로 나뉜 서비스 블록의 통신을 처리할 수 있는 방식으로 API 게이트웨이와 서비스 메시쉬 오픈소스 ‘이스티오’ 2가지가 있다. 2가지 방식은 각각 장단점이 존재한다.
먼저 API 게이트웨이로 서비스 블록 간의 통신을 처리하는 방식이다. API 게이트웨이로 연결하기 위해서는 MSA 작업 시 각 서비스 블록을 API로 나눠야한다는 전제가 붙는다. 이렇게 나뉜 API 서비스 블록을 API 게이트웨이라는 중간 매개를 둬 연결성을 확보하는 것이다. 현재 API 게이트웨이는 주로 외부 기능을 연계하기 위해 사용되고 있다.
API 게이트웨이는 각 서비스 블록에서 발생한 API를 처리해 특정 서비스 블록의 기능을 호출한 서비스 블록과 연계한다. 이를 위해 API 게이트웨이에 각 서비스 블록의 API를 등록하는 작업이 선행돼야 한다. API 게이트웨이는 서비스 블록의 API 리스트를 참고하여 호출 요청에 맞도록 전달한다.
서비스 메시 오픈소스인 ‘이스티오’로 서비스 블록을 연결하는 방식도 있다. 이를 사용하기 위해서는 아키텍처를 구성하는 서비스 블록을 각 서비스 메시 형태로 구현해야 한다. 쉽게 설명하자면 잘게 나뉜 애플리케이션의 기능을 개별 컨테이너에 올리고, 이를 쿠버네티스로 관리하는 방식이다. 사실상 이 방식이 업계 표준으로 자리잡고 있다.
컨테이너를 관리하는 ‘쿠버네티스’는 ‘인그레스’라고 하는 오픈소스를 통해 일부 통신을 처리하고 있다. 하지만 이는 완벽하지 않다. 때문에 별도의 컨테이너 간 통신을 위해 오픈소스를 이용한다. 이때 사용되는 오픈소스가 바로 ‘이스티오’다. 현재 레드햇 ‘오픈시프트(OpenShift)’, VM웨어 ‘탄주(Tanzu)’, 나무기술 ‘칵테일 클라우드(Cocktail Cloud)’, 맨텍 ‘아코디언(accordion)’ 등에 ‘이스티오’가 탑재돼 있다.
MSA 기반 애플리케이션을 구동하기 위해서는 API 게이트웨이와 서비스 메시 중 하나를 선택해야 하는데, 현재 서비스 메시가 더 인기를 끌고 있다. 물론 어느 것이 더 좋다고 할 수는 없다. 기업 상황에 맞게 장단점을 따져 결정해야 한다.
먼저 API 게이트웨이는 각 서비스 블록과 중앙에 독립적으로 설치되기 때문에 용량이 적다. 서비스 메시는 각 쿠버네티스 내 ‘팟(Pod)’ 마다 ‘사이드카(Sidecar)’라고 하는 별도의 콘트롤러 에이전트를 설치해야 한다. 때문에 API 게이트웨이보다 용량이 큰 편이다.
이는 달리 말하면 API 게이트웨이는 장애가 발생할 경우 타 서비스 블록으로 번지게 된다. 이를 위해 이중화 및 삼중화 등 별도의 작업이 필요하다. 하지만 서비스 메시는 분산 형태로 구성돼 장애가 발생해도 타 서비스로 전이되지 않는다. 장애에 대한 대처가 쉽다는 것이다.
이와 관련, 안남수 클루커스 어카운트 테크니컬 서비스 매니저는 “사실 서비스 메시의 장애 대처 방식이 클라우드 환경에 보다 가깝다. 과거 애플리케이션에 장애가 발생하면 원인을 분석하고 수정해 재배포하지만, 클라우드 환경에서 장애가 발생하면 발생한 것을 버리고 다시금 과거 애플리케이션 사양을 복사해 배포하는 방식”이라면서, “API 게이트웨이의 중앙집중적인 방식은 한 번 장애가 발생하면 큰 문제를 야기하기 때문에 서비스 메시에 관심을 갖는 고객들이 더 많다”고 설명했다.
아울러 비용 측면에서도 차이가 존재한다. 업계에 따르면, API 게이트웨이가 서비스 메시보다 상대적으로 비싸다. API 게이트웨이는 기본적으로 1년에 약 1억 원이며, 기술지원에 대한 비용 역시 4~5천만 원에 달한다고 한다. 현재 API 게이트웨이 오픈소스로는 ‘콩’과 ‘엔진엑스’가 존재한다. 외부 API 게이트웨이를 연동하는 방식도 존재한다. 대부분 금융분야 대외 채널 연계 비즈니스를 수행하는 업체의 API 게이트웨이가 사용된다.
넷플릭스가 구현한 MSA 방식
클라우드에 적극적이었던 넷플릭스(Netflix)는 탄력적인 애플리케이션 서비스의 필요성을 깨닫고 서킷 브레이커 패턴의 ‘하이스트릭스(Hystrix)’, 서비스 디스커버리 패턴의 ‘유레카(Eureka)’, 모니터링 서비스인 ‘터빈(Turbine)’ 등의 컴포넌트를 개발해 ‘넷플릭스 OSS’로 공개했다.
더 나아가 오픈소스 애플리케이션 개발 프레임워크인 ‘스프링 프레임워크(Spring Framework)’에 ‘넷플릭스 OSS’를 통합해 ‘스프링 클라우드 넷플릭스(Spring Cloud Netflix)’를 마이크로서비스를 구현할 수 있도록 제공하고 있다.
다만, 넷플릭스 OSS는 자바로 개발돼 라이브러리를 포함하고 코드에 관련된 컴포넌트를 추가해야 하는 등의 제약이 존재한다. 또한 당시 가상머신(VM)이 클라우드에서 애플리케이션을 실행하는 유일한 방법이었기 때문에, ‘넷플릭스 OSS’도 VM에 최적화돼있어 최신의 운영 환경을 모두 수용하지 못하는 단점이 있다.
Q. 메가존디지털에 대해 소개해달라.
A. 메가존디지털은 메가존 그룹에서 디지털 전환을 전담하는 부문이다. 기업이 클라우드로 전환하는 데 필요한 전략을 수립하고 실행하는데 요구되는 역량부터 클라우드 네이티브, 아키텍처, 데이터, AI, 메타버스 등 다양한 기술 역량을 보유하고 있다. 메가존 그룹의 고도화된 프로젝트 관리 역량을 기반으로 다양한 클라우드 네이티브 성공 사례들을 보유하고 있다.
더 나아가 디지털 서비스 플랫폼 제공사로서 고객의 비즈니스에 클라우드가 줄 수 있는 가치를 적극 제공하고자 한다. 타 클라우드 기업들이 IaaS에 초점을 맞추고 있다면, 메가존디지털은 애플리케이션에 초점을 맞추고 있다. 애플리케이션 단에서 워크로드를 클라우드 환경에서 최적화하는 방법과 더 나아가 마이그레이션 서비스도 제공하고 있다.
Q. 클라우드 네이티브 환경은 어떤 기업에 적합한가.
A. 당연하게도 클라우드 컴퓨팅을 활용하면서 애플리케이션에 대한 혁신으로 비즈니스를 만들고자 하는 기업에 적합하다. 데이터가 1년에 수백 기가, 테라바이트 단위로 발생하는 기업이라면 클라우드 네이티브 환경에서 데이터를 활용해 비즈니스 애플리케이션에 꾸준한 변화를 주고 새로운 비즈니스 방법을 만들어낼 수 있다. 클라우드 환경에 저장되는 데이터를 데이터 분석 서비스에 적용해 인사이트를 만들어내고, 인사이트를 비즈니스 애플리케이션에 접목해 비즈니스를 창출하려는 기업이라면 클라우드 네이티브가 정답이다.
이와 반대로 직원 20명 규모로 ERP나 액셀을 사용하고, 꾸준히 비슷한 데이터가 발생하는 업체라면 클라우드 네이티브 환경으로 가야 할지 생각해봐야 한다. 이 경우 기존 것을 유지하는 것이 오히려 ROI 측면에서 유리할 수 있다고 본다. 물론 기존 애플리케이션을 혁신하고, 이를 토대로 비즈니스도 함께 혁신하고자 한다면 클라우드 네이티브 환경으로 가는 것이 좋다.
Q. 클라우드 네이티브가 고객의 비즈니스에 어떠한 가치를 줄 수 있는지.
A. 비즈니스를 언제든 확장할 수 있는 뼈대를 만들어 놓았다고 생각하면 된다. 사실 클라우드 환경을 구현하는 것은 쉬운 일이 아니다. 특히 클라우드 네이티브 환경은 정적이라기 보다는 끊임없이 자동화해 나가는 조직 유연성도 추구하고 있기 때문에 비즈니스 가치를 높여가는 데 핵심이 된다. 한 예로 글로벌 진출을 고려하고 있다면, 글로벌 피처를 반영할 수 있도록 애플리케이션 구조 설계를 하고, 향후 해당 글로벌 진출에 맞춰 해당 서비스 블록만 추가하거나 관련 서비스 블록만 구현하면, 빠르게 글로벌 시장에 타임 투 마켓을 할 수 있다.
예를 들어 다양한 고객사나 시장 환경이 늘어나 애플리케이션 변경에 대한 필요가 폭증해도, 연관된 영역의 서비스 블록만 수정하면 되기 때문에 애플리케이션의 복잡성 증가를 최소화할 수 있고, 민첩성을 높일 수 있다.
“3가지 개념과 방법론은 어디까지나 CNCF의 기준”
“사실 국내에서는 MSA, 컨테이너, 데브옵스 등 3가지 개념과 방법론이 클라우드 네이티브의 표준과도 같다. 하지만 이는 클라우드 네이티브 컴퓨팅 재단(CNCF)에서 제시한 기준일 뿐이다. 클라우드 네이티브의 진정한 의미는 일반적으로 잘 알려진 클라우드 컴퓨팅의 장점 5가지를 모두 포함하면 된다. MSA로 아키텍처를 나누고, 컨테이너를 관리할 수 있는 쿠버네티스를 도입하는 것만이 클라우드 네이티브가 아니다. 기존에 사용하던 온프레미스에 다양한 기능의 SaaS를 함께 사용해 비즈니스 혁신을 완성했다면 이 자체도 클라우드 네이티브라고 할 수 있다. 단지 3가지 개념과 방법론은 클라우드 네이티브 구현을 돕는 도구라고 생각하면 된다.”
클라우드 네이티브를 구성하고 있는 MSA, 컨테이너, 데브옵스 등 3가지 개념과 방법론을 반드시 도입해야 하느냐는 질문에 대해 박종하 메가존디지털 이사가 강조한 말이다.
세계적으로 클라우드 네이티브를 주도하는 재단이 있다. 바로 CNCF다. CNCF에서는 클라우드 네이티브의 중요성을 강조하며, 갖춰야 하는 사양에 대해 정리한 ‘트레일 맵(Trail Map)’을 공개한 바 있다. CNCF의 클라우드 네이티브의 기준은 아키텍처 레이어의 경우 IaaS가 클라우드 네이티브 특성을 가져야 하고, 그 위에 구축되는 애플리케이션도 클라우드 네이티브 특성을 확보해야 한다.
구체적으로 인프라는 컨테이너 방식이어야 하며, 아키텍처는 마이크로서비스 아키텍처, 느슨한 결합(Loosely Coupled), API 베이스 등으로 구현돼야 한다. 이에 대해 박종하 메가존디지털 이사는 “느슨한 결합이라는 용어는 40년 전에 주장됐다. 애플리케이션과 로직 간 결합이 느슨해야 한다는 뜻이다. 쉽게 말해 애플리케이션을 구성하는 작은 구성 요소 서비스 간의 응집도는 높지만, 결합력은 낮아야 한다는 것”이라면서, “CNCF는 클라우드 거래의 특성을BASE(Basic Availability, SoftState, Eventual Consistency)로 설명하고 있다. 용어는 생소하지만 확장성을 높이고, 앞서 표현했던 높은 응집도와 낮은 결합력을 위한 아키텍처 설계에 기반이 되는 모델이다. 아울러 데이터에 대한 부분도 MSA 서비스 블록에 독자적으로 탑재돼야 한다. 데이터베이스(DB), 이벤트 소싱, CQRS(Command, Query, Responsibility Segregation) 등도 아키텍처 설계에 반영해야 된다는 의미”라고 설명했다.
다음으로 구축과 배포는 자동화돼야 하고 상세한 텔레메트리 체계가 구현돼야 하며 주도적인 조치가 가능해야 한다. 개발과 운영 환경, 프로세스는 데브옵스 개발 방법론을 토대로 애자일하게 구현해야 하며, 기업의 조직도 클라우드 네이티브 환경에 적합하게 구현돼야 한다.
클라우드 네이티브 전문기업들은 이러한 CNCF의 ‘트레일맵’을 따르는 것도 좋지만, 경제성 관점에서 클라우드 네이티브에 접근해야 한다고 주문한다. 기존에 운영하던 애플리케이션에 대한 변동 사항이 크지 않고 지속적으로 유지되는 애플리케이션이라면, 굳이 클라우드 네이티브가 트렌드라는 이유로 MSA, 컨테이너 등을 도입하지 않아도 된다는 얘기다. MSA와 컨테이너, 데브옵스 등의 개념과 방법론을 따르고 이를 비즈니스 애플리케이션에 적용하기 위해서는 자본과 인력은 물론 많은 시간이 필요하다. 기회비용을 따져 비즈니스의 경제성을 높일 수 있도록 해야 한다는 것이다.
박종하 메가존디지털 이사는 “꾸준히 유지되는 애플리케이션에 특정 기능을 추가하고 싶다면, 기존 애플리케이션의 아키텍처를 재구성하고 API 게이트웨이를 적용하기 보다는 고품질의 SaaS도 함께 활용해서 구축하는 것이 클라우드 네이티브가 추구하는 개념에 부합한다”면서, “이와 반대로 계속해서 새로운 서비스를 만들어내고, 고객의 요구사항에 끊임없이 애플리케이션을 업데이트해야 할 경우라면 MSA나 컨테이너 도입 등을 고려해볼만 하다”고 강조했다.
클루커스에서 컨설팅과 아키텍처 개선 업무를 수행하는 안남수, 김대환 매니저 역시 “클라우드 네이티브 환경을 성공적으로 구축했다고 하는 넷플릭스의 경우 7년에 달하는 시간을 투자했다. 여기에는 기존 인프라, 애플리케이션에 대한 아키텍처 작업과 같은 기술적인 부분부터 기업 문화와 조직 변화도 포함됐다”며, “IT 전문 인력이 많은 넷플릭스조차 오랜 시간과 비용, 인력 감축 등을 진행했다. 클라우드 네이티브는 단기간에 완성하는 것이 아니라 지속적인 투자가 필요하다는 것을 의미한다”고 말했다.
Q. 클루커스가 생각하는 클라우드 네이티브는.
A. 클라우드 네이티브는 클라우드 컴퓨팅의 장점을 애플리케이션에 적용하지 못한데서 출발했다. 실제 일부 고객은 처음 클라우드로 애플리케이션을 옮기기만 하면, 자동으로 확장하고 관리할 수 있다고 생각한다. 하지만 이는 잘못된 생각이다. 빠르게 클라우드로 옮길 경우 VM 기반으로 옮기는 경우가 많은데, 고객은 기존 환경과 다를 바 없이 느낄 것이다. 이처럼 VM 기반의 클라우드 환경으로 옮기게 되면 애플리케이션까지 장점을 누리기 쉽지 않다.
클라우드 네이티브는 이러한 단점을 상쇄하면서 장점을 극대화할 수 있는 하나의 방법이다. 이를 위해선 IaaS가 아닌 PaaS에서 애플리케이션에 접근해야만 한다. 현재 PaaS 시장이 크게 늘고 있고, 클라우드 추세도 PaaS로 옮겨가고 있다. 이는 클라우드 네이티브의 장밋빛 전망을 뒷받침하는 방증이다.
Q. 클라우드 네이티브에 대한 전망은.
A. 클라우드 네이티브와 관련된 시장, 기술, 제품은 모두 블루오션이라고 생각한다. 관련 시장은 고성장할 것이고, 제품과 기술은 모두 고도화될 것이다.
올해 들어 클라우드 네이티브에 대한 분위기가 달아오르고 있다. 실제 많은 고객이 클라우드 네이티브 환경을 구현하기 위해 데브옵스, CI/CD, MSA 등과 관련된 PoC를 요구하고 있다. 실제 클라우드를 도입했던 A사의 경우 정식 프로젝트가 아님에도 PoC를 제안하기도 했다. 아울러 타 클라우드 기업과 협업하던 곳에서도 쿠버네티스 도입과 관련해 우리에게 문의하기도 했다. 클라우드를 도입한 기업들이 클라우드 네이티브에 관심을 보이고 있다는 것은 시장이 크게 성장할 것을 암시한다고 볼 수 있다.
Q. 클라우드 네이티브에 대한 기술 역량은 어떻게 확보하고 있는가.
A. 클라우드 네이티브 기술 역량을 확보하기 위한 전제조건은 클라우드에 대한 전문성이다. 클루커스는 마이크로소프트(MS)의 클라우드인 ‘애저(Azure)’와 데이터 분석에 대한 기술 전문성을 가진 MSP다. MS 애저에서는 ‘애저 오픈시프트’, ‘애저 스프링클라우드’, ‘애저 쿠버네티스’ 등과 같은 클라우드 네이티브 환경을 만들 수 있는 서비스를 제공하고 있다. 클루커스는 이러한 클라우드 상품은 기본이고, 데이터 분석, 데이터 활용, AI/ML 서비스 등까지 전문성을 고도화하고 있다. 아울러, 데브옵스 엔지니어와 같은 클라우드 네이티브 특화 전문 인력도 확보하고 있다.
클루커스는 고객이 클라우드 네이티브에 대해 갈피를 잡지 못하고 있는 경우가 종종 있는데, 이런 고객을 위해 기존 시스템에 대한 컨설팅 부분과 애플리케이션 워크로드를 담당하는 컨설팅 등 2가지로 구분해 서비스를 제공하고 있다.
장밋빛 전망에 시장 참여기업 늘어
클라우드 네이티브에 대한 장밋빛 전망이 이어지자 기업들의 시장 참여도 활발해지고 있다. MSA, 컨테이너 관리 플랫폼, 데브옵스를 플랫폼 형태로 제공하고 있는 PaaS 기업부터, AWS, MS, GCP, 네이버클라우드 등 CSP와 메가존, 클루커스와 같은 클라우드 관리 서비스 제공사(MSP)까지 모두 이 시장에 뛰어들고 있다.
업계 관계자들은 모두 클라우드 네이티브 시장에 참여한 기업들이 크게 늘어날 것으로 전망한다. 지난달 레드햇이 발간한 ‘2021 레드햇 클라우드 네이티브 개발 전망 보고서’ 역시 이러한 전망에 힘을 싣고 있다. 레드햇 보고서에 따르면, 클라우드 네이티브를 구현하기 시작한 기업은 다양한 기능을 고도화하고, 애플리케이션에 대한 혁신을 위한 예산도 늘려나갈 것으로 보인다. 또한 클라우드 네이티브를 도입한 기업의 51%는 소프트웨어 제공 주기가 1~4주 사이지만, 클라우드 네이티브 채택이 지연되고 있는 기업의 15%은 소프트웨어 제공 주기가 7~12개월로 나타났다.
클라우드 네이티브에 대한 효과가 나타나자 이에 대한 기업들의 예산도 덩달아 증가하고 있다. 클라우드 네이티브를 구현한 기업 중 73%가 향후 1년 안에 클라우드 네이티브 예산을 늘릴 계획이라고 답한 것. 레드햇 측은 “이는 클라우드 네이티브가 단순한 유행이 아니라는 보여준 것이다. 향후 애플리케이션 개발 및 현대화에 자주 사용되는 방식으로 빠르게 자리 잡고 있다는 점은 확실하다”고 설명했다.
기업들의 클라우드 네이티브 시장 접근은 업체 성격에 따라 각각 다른 형태로 나타나고 있다.
나무기술과 맨텍, 레드햇 등은 PaaS 제품을 앞세워 클라우드 네이티브를 구현하고 있다. 이들 기업은 단독으로 고객에게 클라우드 네이티브 환경을 구현해줄 수는 없다. IT 컨설팅 전문 기업과 협력 관계를 맺고 비즈니스를 진행하고 있다. 기업의 한 담당자는 “실제 고객이 클라우드 네이티브를 구현해달라고 찾아오는 경우가 있다”면서, “하지만 IT 컨설팅 기업이 IT 환경 분석을 하고, 이후 PaaS 기업들로부터 솔루션을 도입해야 한다. 컨설팅 측면에서 PaaS 기업이 담당할 수도 있있지만, 고객이 스스로 기존 환경에 대한 분석과 비즈니스 전략을 수립하는 것이 중요하다”고 설명했다.
클라우드 관리 서비스 제공사(MSP)는 컨설팅에 주력하고 있다. 메가존 그룹의 경우 메가존디지털에서 디지털 전환과 관련된 비즈니스를 추진하고 있다. 메가존디지털은 클라우드 비즈니스 전략과 실행 역량 등을 컨설팅하고, 클라우드 네이티브와 관련된 MSA, 데브옵스, PaaS 등과 관련된 서비스를 제공하고 있다. 다양한 성공 사례도 보유하고 있는 메가존디지털은 구체적인 사명을 밝힐 순 없지만 수백억 원에 달하는 대기업의 클라우드 네이티브 프로젝트를 성공적으로 수행하기도 했다.
클루커스 역시 컨설팅과 교육 등을 위주로 클라우드 네이티브 환경 구현에 힘을 쏟고 있다. 이 회사는 시스템 변경을 위한 컨설팅과 특정 워크로드에 대한 컨설팅 등 구체적인 컨설팅 서비스를 제공하고 있다. 특히 마이크로소프트(MS)의 ‘애저’의 기술력을 인정받아 대기업 H사로부터 클라우드 네이티브와 관련된 데브옵스, CI/CD 프로젝트 러브콜을 받기도 했다.
네이버클라우드는 고객이 클라우드 네이티브를 구현할 수 있도록 퍼블릭 클라우드 상품으로 제안하고 있다. 클라우드 상품에는 MSA, 컨테이너 관리 플랫폼 쿠버네티스, CI/CD 파이프라인 등 다양하다. 한기웅 네이버클라우드 클라우드 솔루션 아키텍트팀 리더는 “CSP 입장에서 고객이 네이버클라우드에 종속되면 안정적으로 비즈니스를 유지할 수 있다. 하지만 네이버클라우드는 고객이 종속되지 않게끔 고객에게 상품을 제안한다. 쿠버네티스 상품, CI/CD 상품 등이 바로 그 예시다”라면서, “클라우드 네이티브 환경에서의 가치를 느끼는 고객이라면 다시금 네이버클라우드의 상품을 찾을 것이다. 고객에게 클라우드 네이티브 가치를 전달할 수 있는 컨설팅과 아키텍처링, 상품 등을 제안하고 있다”고 강조했다.