클라우드의 이점을 모두 활용하기 위해서는 새로운 형태의 애플리케이션 개발이 필요하다. ‘클라우드 네이티브(Cloud-Native)’ 개발이 바로 이에 해당되며, 애플리케이션을 신속하게 구축하고 업데이트하면서 품질을 개선하고 위험을 감소시키는 접근 방식이다. 이를 통해 대응 능력, 확장성, 내결함성을 갖춘 애플리케이션을 퍼블릭, 프라이빗 또는 하이브리드 클라우드 환경이든 어디에나 구축할 수 있다.

클라우드 네이티브 개발은 애플리케이션을 시장에 신속하게 제공하기 위한 필수 항목이자 클라우드 형태에 상관없이 온디맨드로 클라우드 컴퓨팅 성능을 무제한으로 활용해 애플리케이션을 구축하고 실행하는 방법론이다. 적합한 툴과 기술을 갖추면 개발자가 더욱 빠르게 새로운 애플리케이션을 개발할 수 있고, 기존 애플리케이션을 최적화해 빠르게 변하는 고객 요구를 충족하기에 적합하다.

이렇게 개발된 클라우드 네이티브 애플리케이션은 애플리케이션 배포 위험을 낮추면서 속도와 유연성 및 품질을 높이기 위해 클라우드 컴퓨팅 모델을 활용한다. 즉, 애플리케이션이 배포되는 위치가 아니라 애플리케이션이 구축, 배포 및 관리되는 방식에 중점을 두고 있는 것이 특징이다.

클라우드 네이티브 애플리케이션은 프라이빗, 퍼블릭 및 하이브리드 클라우드 환경 전체에 지속적인 개발과 자동화된 관리 환경을 제공하기 위해 특별히 설계된 애플리케이션이자 탄력적으로 결합된 소규모의 독립적인 서비스 컬렉션이다. 이들 애플리케이션은 사용자 피드백을 신속하게 통합해 지속적으로 개선하는 기능을 비롯한 비즈니스 가치를 제공할 수 있도록 설계됐다.

다시 말해 클라우드 네이티브 애플리케이션 개발은 새로운 애플리케이션을 구축하고, 기존 애플리케이션을 최적화하고, 모든 환경을 연결하는 작업을 가속화할 수 있는 방법이며, 클라우드 네이티브의 목표는 비즈니스 요구사항의 변화 속도에 맞춰 사용자들이 원하는 애플리케이션을 제공하는 것이라 할 수 있다.

컨테이너 기술 각광
특정 서비스를 제공하기 위해서는 이를 구동할 인프라가 있어야 하며, 보통 서버가 그 역할을 맡는다. 그러나 레거시 환경에서 서버를 구성하고 관리하는 것은 결코 쉬운 일이 아니다. 처음 장비를 구매해 배송이 이뤄지면 운영체제(OS)를 설치하고, 웹 애플리케이션 서버(WAS) 등을 구축한 이후에 애플리케이션을 올리는 과정을 거쳤다. 이 모든 단계가 완료되기까지 상당한 시간이 필요하며, 전문적인 서버 지식을 갖춘 엔지니어의 손길을 거쳐야만 했다.

이 같은 방식은 시간이 지나며 한계점을 노출하기 시작했다. 기술의 발전으로 서버의 성능은 나날이 좋아졌으나 정작 해당 서버에서 구동되는 애플리케이션 서비스가 소모하는 하드웨어 자원은 일부에 불과해 사실상 자원의 낭비가 심해졌기 때문이다. 같은 애플리케이션이라 하더라도 이전에는 서버 자원의 80%를 사용했다면, 이제는 20%도 채 사용하지 못하는 경우가 빈번해졌다. 유휴자원이 발생한다는 것은 그만큼 과지출이 일어났다는 것을 의미하며, IT 담당자들로서는 고민에 빠질 수밖에 없었다.

이후 가상화 기술이 등장하면서 자원 활용률 문제가 어느 정도 해소됐다. 하나의 시스템을 논리적으로 여러 개의 시스템처럼 활용할 수 있게 되면서 단일 서버에 여러 개의 애플리케이션을 올려 서비스하는 것이 가능해졌고, 이를 토대로 유휴자원을 줄일 수 있었기 때문이다.

다시 시간이 지나 현재로 이어지면서 가상화 기술도 최근 IT 트렌드를 쫓아가기에 부족하다는 평가가 나오고 있다. 가상화가 하드웨어 기반의 자원 격리를 통해 자원 활용률을 높이는데 기여한 것은 맞지만, 가상화 환경에서 애플리케이션 서비스를 제공하려면 서버에 하이퍼바이저(Hypervisor)와 게스트(Guest) OS를 설치하고, WAS를 올려 애플리케이션을 설치하는 그 과정마저 바뀐 것은 아니었기 때문이다.

가상화 기술과도 유사한 개념인 ‘컨테이너’는 애플리케이션 실행에 필요한 파일과 라이브러리(lib)를 패키지화한 후, 필요할 때마다 이를 실행시켜 동일한 환경을 이용할 수 있도록 하는 역할을 한다. 실제 제품 수출입 시에 활용하는 철제 포장 용기인 ‘컨테이너’와 역할이 유사해 애플리케이션 실행에 필요한 파일과 라이브러리 등을 간편하게 패키지화할 수 있으며, 자유롭게 이동시키고 쉽게 이식도 가능하다.

가령 WAS 위에 애플리케이션을 배포한다면 WAS와 애플리케이션을 함께 넣어 패키징 한다. 하지만 애플리케이션은 자주 바뀔 수 있기에 새로 패키징 할 때마다 버전이 늘어나게 되는 문제점이 있다. 그러나 WAS는 변하지 않기 때문에, 한 개의 WAS에 변화된 애플리케이션 버전만 추가하는 방법으로 효율적인 활용이 가능하다.

뿐만 아니라 자원 격리 기술은 컨테이너 호스트를 장비에 올릴 때 하드웨어 자원을 격리해줌으로써 VM을 사용할 때와 같은 효과를 제공한다.

이처럼 컨테이너를 활용할 경우 하나의 이미지로 파일을 패키징하기에 원하는 시점에 원하는 장비로 이미지 파일을 편리하게 옮겨 애플리케이션 서비스를 구동할 수 있다. 이는 여러 대의 장비에서 서비스를 올리고 내리는 관리가 간편해진다는 것을 의미한다. 이미지 파일에 서비스 구동에 필요한 것들을 다 넣어뒀기 때문에 호스트 OS 상에서 별도의 세팅을 할 필요도 없다.

자원 효율성·OS 호환성 등 강점
클라우드 환경이 확산되면서 컨테이너 기술에 대한 인기가 상승한 요인은 애플리케이션 이동과 배포가 수월해졌다는 점도 있지만, 이외에도 자원 효율성, 자원 격리, 호환성, 오토스케일링(Auto-Scaling), 마이크로서비스, 관리 편의성 등이 뒷받침됐기 때문인 것으로 평가된다.

최근 베어메탈 환경은 컴퓨팅 기술의 발전으로 인해 많은 수의 CPU 코어가 제공된다. 단일 애플리케이션의 성능을 온전히 내려면 베어메탈 환경을 이용하면서 최대의 자원을 활용할 수 있도록 구성하겠지만, 실제로 이렇게 이용하는 경우는 극히 일부를 제외하면 드문 편이다. 이에 단일 장비에서 가상화 기술과 같은 자원 격리를 통해 여러 개의 WAS와 애플리케이션을 구동하는 방식이 활용된다.

그러나 그중 하나의 애플리케이션이 잘못 구성돼 무한루프 현상을 보이며 인프라 자원을 모두 소진할 경우 다른 WAS와 애플리케이션은 제대로 동작을 하지 못하는 불상사가 일어날 수 있다. 말 그대로 장애 아닌 장애 상태를 맞이하게 되는 셈인데, 컨테이너 기술은 할당된 자원을 완벽하게 격리하기 때문에 특정 WAS와 애플리케이션에서 시스템 전체의 자원을 소비하는 문제를 막는다. 이를 통해 보다 효율적으로 인프라 자원을 활용할 수 있다.

컨테이너 기술의 또 다른 장점으로 OS 간 호환성이 높다. 베어메탈을 비롯해 장비에 설치된 OS 버전이 다를 경우, 같은 벤더의 WAS를 사용한다 해도 쓸 수 있는 버전이 달라진다. 이에 필요할 때마다 WAS 구성을 해야 하는 불편함이 생긴다.

자원을 효율적으로 사용하자는 목표 아래 VM 기술이 등장했지만, 각 VM 간 호환성은 떨어진다는 문제가 있다. 가령 특정 벤더의 VM을 만들어 이용하다가 벤더와의 갈등이나 비싼 유지보수 비용, 기술지원 불만 등으로 인해 이탈하려 해도, 막상 시스템 자원을 옮길 비용이 새로 시스템을 구축하는 비용과 큰 차이가 없을 정도로 비싸기에 어쩔 수 없이 벤더에 종속되는 경우도 많다.

이에 반해 컨테이너는 오픈 컨테이너 이니셔티브(OCI) 프로젝트가 지난 2015년부터 추진되면서 기술 표준화를 위해 움직이고 있다. 벤더마다 독점적으로 보유하고 있는 기술이 아니라 공개 산업 표준의 파일 포맷과 이를 구동시키는 런타임 표준에 대한 작업이 이뤄지고 있는 것이다. 이로 인해 cri-o로 불리는 경량의 OCI 호환 컨테이너 런타임이 개발되기도 했다.

오토스케일링으로 확장도 간편하게
가령 설이나 추석 등 명절 기차표 예매 시에는 평소 대비 어느 정도 트래픽이 몰리는지 예상이 가능해 미리 자원을 증설해서 대비할 수 있지만, 태풍이나 홍수 등 자연재해가 갑작스럽게 발생했을 때 특정 정부·공공기관 사이트에 관련 정보를 조회하고자 대량의 트래픽이 몰리는 것을 예측하기는 어렵다. 앞서 언급한 온라인 개학 상황도 마찬가지다.

예측 가능한 상황에 미리 대비해서 준비하는 것과 예기치 못한 상황에도 유연하게 대처가 가능하도록 하는 것은 전혀 다른 이야기다. 컨테이너는 컴퓨터 자원이 갑작스럽게 늘어나더라도 자동적으로 확장될 수 있는 오토스케일링 옵션 설정이 가능해 갑작스러운 환경 변화에도 효율적으로 대응이 가능하다.

오토스케일링은 생성된 서버가 자동으로 애플리케이션과 연동되는 기능으로, 예상치 못한 트래픽이 갑자기 발생할 경우에도 자동으로 여유 서버를 할당해줘 서비스가 다운되는 현상을 막는다. 그리고 다시 트래픽이 감소하면 여유 서버 기동을 중지하고 서비스에 필요한 만큼의 운영 환경을 갖춰 클라우드 이용료가 과다하게 부과되는 것을 막는다.

컨테이너를 근간으로 하는 플랫폼 혹은 PaaS 솔루션 등은 대부분 오토스케일링 기능을 제공한다. 자동 자원 확장을 위해 개발자나 운영자가 별도로 개발하고 추가할 필요가 없다. 단지 원하는 값만 세팅해주면 되며, 임계치를 늘리거나 줄이는 것으로써 간단히 설정 가능하다. 그러나 애플리케이션이 MSA로 구현되지 못하면 클라우드 활용에 있어 가장 큰 혜택이라 할 수 있는 오토스케일링 효과를 누릴 수 없기에 온프레미스 데이터센터에 있던 애플리케이션을 복사해서 클라우드에 얹어놓은 수준에 불과한 ‘리프트 앤 시프트(Lift & Shift)’가 아닌 클라우드 네이티브 애플리케이션으로의 전환은 반드시 필요하다.

빠른 서비스 배포 지원
오늘날 지능형 컴퓨팅 기술로 인해 세상은 더욱 복잡한 환경으로 바뀌고 있다. 코드 작성을 시작하기도 전에 운영을 걱정해야 할 정도다. 소비자는 IT가 전례 없는 민첩성을 기반으로 무결점의 애플리케이션과 서비스를 제공해 주기를 기대한다. 각 단계를 확실히 매듭짓고 난 후 다음 단계로 넘어가는 워터폴 모델의 소프트웨어 개발 방식이나 12~18개월 단위의 소프트웨어 배포 주기는 현재 IT 환경에 적합하지 않다.

은행, 금융, 통신 등의 분야에서는 애플리케이션 제공이 지연되거나 속도를 위해 품질을 희생할 경우 고객 이탈과 가입자당 평균 수익에 큰 영향을 받는다. 대다수 IT 부서는 현업 부서로부터 고객 요구사항에 부응하는 보다 강력한 애플리케이션을 이전보다 빠르고 비용 대비 효과적인 방식으로 제공해 달라는 압박을 받고 있다.

IT 부서가 현업 요구를 지원함에 있어 가장 큰 어려움은 전통적으로 경계가 구분된 개발과 운영 환경을 통합하는 것이다. 지금까지는 개발과 운영의 경계가 분명해 소프트웨어 개발 라이프 사이클(SDLC) 운영에 많은 비용이 소요됐다. 개발과 운영을 병행하는 ‘데브옵스’는 이에 대한 해결책으로 현재 각광 받고 있다.

데브옵스는 단어에서 알 수 있듯이 개발(Dev)과 운영(Ops)이 합쳐진 개념으로, ‘개발된 코드(소프트웨어)를 서비스로 반영하기 위한 효과적인 일의 방법’으로 요약된다. 가령 개발 팀에서는 풀 스택(Full-Stack) 개발자라는 용어를 사용하면서 한 명의 개발자가 여러 전문지식을 동시에 갖고 UI, 데이터베이스 설계, 코드 배포까지 할 수 있는 역할을 기대하기도 하는데, 그 기대가 데브옵스를 구현하는 것과 유사하다.

그동안 국내 인터넷 서비스들은 주로 새벽 시간에 서비스를 점검하면서 오류를 패치하거나 새로운 기능들을 배포하곤 했다. 반면 아마존, 페이스북 등이 국내 서비스처럼 점검 시간을 갖는 경우는 드물며, 어느 날 갑자기 새로운 기능과 서비스들이 제공되고 있는 것을 볼 수 있다. 말 그대로 무중단 서비스, 실시간 배포가 이뤄지고 있으며, 이는 데브옵스를 통해야만 가능하다.