[컴퓨터월드] 클라우드를 효율적으로 운영하며, 데브옵스(DevOps)를 성공적으로 구현하기 위한 방법으로 ‘IaC(Infrastructure as Code)’가 떠오르고 있다. IaC는 개발자가 직접 코드를 작성해 인프라를 생성하고, 배치, 관리하는 기술이다. 개발자들은 IaC를 이용해 개발하기 전 수행해야 했던 번거로운 클라우드 인프라 설정 작업을 줄이고, 개발과 운영을 유기적으로 만들 수 있다. ‘IaC’에 대한 관심이 높아지자 솔루션 공급업체들이 시장 진입을 서두르는 등 빠르게 움직이고 있다. 새롭게 떠오르고 있는 기술, ‘IaC’에 대해 알아봤다.

개발과 운영의 경계 허문다

IaC는 애플리케이션 개발과 운영에 필요한 인프라를 코드로 자동 생성·배치·관리하는 것이다. 인프라에 대한 정보가 담긴 코드들을 하나의 스크립트에 작성하면, IaC 툴이 스크립트에 맞춰 CSP의 클라우드 서비스와 연동해 인프라를 생성한다. 쉽게 표현하면 IaC 툴은 ‘배우’고, 스크립트는 ‘시나리오’에 해당한다고 보면 된다. 연극의 스토리를 전개할 수 있는 단어와 문장들이 담긴 시나리오를 보고 배우가 연기하는 것과 같다는 것이다.

인프라 프로비저닝(설정과정: Provisioning)을 자동화한다는 것은 개발자가 애플리케이션을 개발하거나 배포할 때마다 서버, 운영체제(OS), 스토리지 및 기타 인프라 구성 요소를 수동으로 설치하고 관리할 필요가 없다는 것을 의미한다.

일반적으로 프로비저닝이라는 용어는 IT 환경에서 운영 담당자가 개발자가 사용할 컴퓨터에 필요한 컴퓨팅 자원과 저장소 또는 기타 서비스를 설치한다는 의미로 사용된다.

통상 개발자들이 애플리케이션을 개발할 때 가장 먼저 하는 일은 운영팀과 협의해 인프라를 설치하는 것이다. 이 때 개발자는 개발에 필요한 자원을 운영팀에 요청하고, 운영팀은 서버, 라우팅 항목, 데이터베이스(DB) 구성 및 로드 밸런서를 수동으로 개발자의 작업 컴퓨터에 설치한다. 이후 설치된 컴퓨터를 개발자에게 전달한다.

이 때 운영팀이 인프라를 잘못 설치할 경우 다운타임이 발생할 수도 있으며, 문제 해결에 많은 시간이 필요할 수도 있다.

IaC는 이러한 기존 개발환경이 갖는 문제들을 해결할 수 있을 것으로 기대를 모으고 있다. IaC는 개발자로 하여금 ▲IT 인프라 환경의 자동 프로비저닝과 워크플로우 호환 ▲인프라 규모와 상관없는 관리의 용이성 ▲빠른 재해복구 환경 구축 ▲멀티·하이브리드 클라우드 구현 등 5가지 이점을 코드 작업으로 누릴 수 있게 해준다.

먼저 IaC는 ‘IT 인프라 환경을 자동으로 프로비저닝’ 해준다. 간단한 파일과 코드를 사용해 인프라, 네트워킹, 부하 분산, 클라우드 IAM(Indexed Access Method) 등을 포함한 환경을 비롯해 테스트나 QA 등을 위한 인프라 환경도 구축할 수 있도록 해준다. 이 과정에서 인프라를 생성하기 위한 운영팀의 실수나 오류를 줄여 효율성도 높아진다. IaC를 이용할 경우 스크립트 내 코드 수정을 통해 손쉽게 자원을 생성하고, 업데이트하거나 삭제할 수도 있다.

IaC는 인프라 규모에 제약이 없어 관리도 용이하다. 코드를 스크립트에 작성할 때 VM의 개수와 상관없이 필요한 만큼 생성할 수 있다. 인프라 구성요소 역시 세분화해 자동으로 결합할 수 있기 때문에, 개발자가 부분적으로 제어할 수 있다. VM 100대를 사용한다고 가정할 경우, 50대에는 마리아 DB를, 50대에는 오라클을, 또 관리자 권한은 100명에게 나눌 수도 있다. 네트워크나 저장소, 데이터베이스(DB) 등과 같은 리소스를 쉽게 관리할 수 있다는 얘기다.

클라우드로 애플리케이션을 개발할 때 클라우드 서비스 제공사의 ‘포털’에서 인프라를 생성한다. 이 때 CSP의 웹 포털에서는 원하는 자원을 한 가지만 선택할 수 있기 때문에, 자원의 수가 많아질수록 비례해서 작업도 늘어나게 된다. 가령, 웹 포털에서 생성하고자 하는 자원의 종류가 15가지라면, 15번의 개별 작업이 필요하다. 그러나 IaC를 이용할 경우 이처럼 번거로운 클라우드 인프라 생성 과정을 줄일 수 있다.

IaC는 ‘빠른 재해복구 환경’도 구축할 수 있도록 해준다. 기존 애플리케이션의 인프라와 구성을 코드로 확인할 수 있어 문제가 발생하더라도 빠르게 조치를 취할 수 있다. 또 개발팀과 운영팀 모두가 스크립트를 검토할 수 있기 때문에 지속 통합·지속 배포(CI·CD) 파이프라인을 구축해 문제가 발생한 곳이 어느 지점인지 쉽게 확인할 수 있다. 부적절한 인프라 변경사항을 바로 알아내 재해 복구를 할 수 있다는 것이다.

모은정 클루커스 개발팀 리더는 “개발 직원이 퇴사할 때 애플리케이션에 대한 정보를 인수인계해야 하는데, 그렇지 못한 경우가 있다. 이 경우 IaC를 통해 애플리케이션을 개발했다면 스크립트에 애플리케이션에 대한 인프라 정보가 담겨있어, 새로운 직원이 오더라도 손쉽게 애플리케이션에 대한 버전관리가 가능하다”고 설명했다.

이어 그는 “IaC 스크립트를 사용할 경우 몇 번이고 같은 환경을 구성할 수 있어 소프트웨어의 개발 기한을 단축할 수 있다. 적시에 제품을 개발해야 하는 개발자에게 큰 도움이 될 것”이라고 말했다.

IaC는 멀티·하이브리드 클라우드를 구현하는 데에도 적합하다. IaC로 컨테이너(Container) 환경을 만드는 것이다. 컨테이너는 온프레미스부터 퍼블릭 클라우드, 프라이빗 클라우드 등 인프라에 제약을 받지 않는다는 점에서 멀티·하이브리드 클라우드에 적합하다. 컨테이너는 인프라 위에 OS를 구성하고 그 위에 컨테이너 엔진을 설치하며, 바로 위에 설치되는 컨테이너에 애플리케이션과 WAS(Web Application Server)가 담기는 구조다. 하부 자원에 대한 종속 없이 스스로 가동될 수 있어 멀티·하이브리드 클라우드 환경에 적합하다. 이처럼 컨테이너와 생성된 컨테이너를 관리하는 시스템인 ‘쿠버네티스(Kubernetes)’도 IaC로 쉽게 관리할 수 있다. 애플리케이션을 개발하기 위해 스크립트에 인프라 코드를 작성할 때 컨테이너에 대한 정보와 이를 관리할 쿠버네티스 서비스를 담기만하면 된다.

2가지 코드 작성 방식

IaC를 사용하기 위해서는 원하는 인프라 구성을 코드형태로 스크립트에 기술해야 한다. 작성 방식은 사용하고자 하는 IaC 툴에 따라 순차적인 명령을 주는 방식인 ‘명령형(Imperative)’과 최종 결과물을 구성하는 방식인 ‘선언형(Declarative)’ 2가지로 나뉜다.

먼저 ‘명령형’의 경우 인프라에 대한 코드가 적힌 스크립트를 IaC 툴로 생성하는 방식이다. 이 방식은 스크립트에 인프라에 대한 자원과 구성에 대한 코드가 모두 포함돼야 한다. 때문에 개발자가 애플리케이션을 개발하기 위해 필요한 인프라에 대한 모든 것을 코드로 작성할 수 있어야 한다.

‘명령형’의 경우 솔루션을 통해 인프라를 프로비저닝 하는데, 이때 하나씩 주어진 명령을 수행하며 인프라를 생성한다. 이런 이유로 스크립트에 코드를 작성하는 순서가 절대로 바뀌어서는 안 된다. ‘명령형’ 방식의 IaC 솔루션을 사용해 스크립트를 작성하기 위해선 고도의 전문성이 요구되는 이유다.

모은정 클루커스 개발팀 리더는 “‘명령형’은 윈도우 도스(DOS) 명령처럼 명령어를 작성하는 개념이다. 가령, 어떤 VM으로 몇 개를 사용한다고 결정하게 되면, 삭제할 수 없고 바로 VM이 생성된다. 또 인프라를 코딩하는 순서 역시 바뀌면 안된다”면서, “비교적 ‘선언형’에 비해 전문성이 필요하다”고 설명했다.

‘선언형’은 최종 결과물이 어떻게 나올지 구상한 후 모듈 형식으로 작성한다. 한 마디로 프로비저닝할 인프라의 최종 상태를 지정하게 되면, IaC 툴이 나머지를 알아서 처리해준다는 것이다. 또한 순차적으로 코드를 작성해야 하는 ‘명령형’과는 다르게 생성하고자 하는 서비스 별로 ‘선언’하기만 하면 된다.

CSP는 ‘A’, 리전은 ‘B’, 스토리지는 ‘C’, 쿠버네티스는 ‘D’ 등과 같이 작성하면 IaC 툴이 인프라를 생성한다. 현재 IaC SW 대부분은 ‘선언형’을 채택하고 있다. AWS의 클라우드 서비스에서 IaC를 적용하는 것을 예로 들면, ‘AWS S3 API create-bucket’, ‘my-first-website-cloud-native-website’, ‘리전 EU-센트럴1’ 등과 같은 코드를 하나의 스크립트에 작성하기만 하면 된다.

3단계로 구동

앞서 2가지 방식으로 스크립트를 작성하더라도 ▲초기 인프라 설정 ▲인프라 관리 ▲인프라 애플리케이션 배포 등의 3단계를 거친다. 또한 각 단계에 적용되는 IaC 툴 역시 다양하다.

먼저 ‘초기 인프라 설정’ 단계에서는 말 그대로 IT 인프라를 설정하는 단계다. 사용자가 인프라를 사용할 수 있도록, 스크립트를 통해 인프라를 프로비저닝 한다는 것이다. 여기에서 사용할 수 있는 IaC 솔루션은 ‘팩커(Packer)’, ‘베이그런트(Vagrant)’ 등이 있다.

‘인프라 관리’ 단계에서는 앞서 생성된 인프라를 관리한다. 이 단계에서는 생성된 인프라를 수정, 재사용, 인프라 작업 정보, 이력 등 인프라에 대한 전반을 관리한다. 아울러, 다음 단계에서 진행될 ‘인프라 애플리케이션 배포’ 작업에 앞서 애플리케이션 배포를 위한 과정을 개발하기도 한다. 여기에서 주로 사용되는 IaC 솔루션으로는 ‘테라폼’, ‘베이그런트’, ‘솔트스택(Saltstack)’, ‘앤서블(Ansible)’, ‘퍼펫(Puppet)’, ‘셰프(Chep)’ 등을 들 수 있다.

‘인프라 애플리케이션 배포’ 단계에서는 준비된 애플리케이션 서버에 애플리케이션의 새 버전을 배포한다. 자바나 DB부터 CI·CD 파이프라인 관리 도구와 컨테이너 오케스트레이션 툴까지 애플리케이션의 개발 환경을 구성하고 관리한다. 이 단계에서 인프라에 대한 애플리케이션 구성과 테스트 환경을 생성하며, 보안에 대한 관리 절차도 세우게 된다. 사용되는 IaC 솔루션은 ‘클라우드인잇(Cloud-init)’, ‘CF엔진(CFEngine)’, 솔트스택’, ‘앤서블’, ‘퍼펫’, ‘셰프’ 등이다.

‘인프라 애플리케이션 배포’ 단계 외에도 ‘배포 애플리케이션 관리 단계’도 있지만, 대개 인프라 애플리케이션을 배포하고 나서 이를 위한 관리도 함께 진행하고 있다. ‘인프라 애플리케이션 배포’ 단계에서 사용되는 ‘클라우드인잇’, ‘CF엔진’, 솔트스택’, ‘앤서블’, ‘퍼펫’, ‘셰프’ 등의 툴로 배포된 인프라 애플리케이션을 관리한다.

이 같은 오픈소스들을 기반으로 많은 기업들은 다양한 IaC 솔루션을 만들어내고 있다. 하지만 기술이 성숙하지 않은 현 상황에서는, 인프라 운영을 위한 모든 과정을 대체할 수는 없어 각 단계에 맞는 IaC 툴을 적절히 섞어서 활용해야 한다.

‘테라폼’ 및 ‘앤서블’ 각광…향후 고성장 기대

아직 IaC 기술이 성숙하지 않았지만 IaC 대한 국내 기업들의 관심은 뜨겁다. 국내 IaC 시장 확대 가능성이 크다는 것이다. 특히, 국내 기업들이 본격적으로 클라우드를 도입하면서, 이를 효율적으로 운영할 수 있는 솔루션에 대한 수요가 크게 늘어나고 있다는 사실을 감안하면 더욱 그렇다. 클라우드 운영을 보다 효율적으로 할 수 있는 대안으로 IaC 툴에 집중하고 있다.

IaC 툴 가운데 특히 인기를 끌고 있는 제품이 있다. 바로 ‘테라폼(Terrafom)’과 ‘앤서블(Ansible)’이다. ‘테라폼’은 하시코프(Hashicorp)에서 오픈소스로 개발한 ‘IaC’ 도구로, 인프라 자동화를 목표로 설계됐다. 서버 등과 같은 기본적인 인프라 배포에 최적화돼 있다. 테라폼은 ‘하시코프 설정 언어(HCL, Hashicorp Configuration Language)’를 사용해 클라우드 리소스를 생성한다. AWS, 구글 클라우드 플랫폼(GCP, Google Cloud Platform), 마이크로소프트 애저(Microsoft Azure)와 같은 주요 클라우드 서비스를 비롯한 다양한 클라우드 서비스들을 생성할 수 있다. 이를 위해 하시코프 측은 AWS, MS, 구글 클라우드 등과 협력관계를 맺었기에 가능하다고 설명했다.

이를 통해 테라폼만으로 복수의 클라우드 리소스를 코드로 관리하는 것이 가능하다. 가령, 컴퓨팅 자원은 AWS에서, DNS(Domain Name System)는 클라우드플레어에서, DB는 히로쿠(Heroku)에서 가져올 수 있다.

‘앤서블’은 여러 개의 서버를 효율적으로 관리하기 위해 고안된 IT 환경 자동화 도구다. 앤서블은 레드햇이 후원하는 오픈소스 커뮤니티 프로젝트로, 인프라 프로비저닝부터 관리 및 애플리케이션 구축까지 자동화할 수 있도록 설계됐다. 테라폼과 다르게 앤서블은 설치된 인프라를 자동으로 관리하는데 초점이 맞춰졌다. 앤서블은 ‘선언형’의 코드 작성 방식을 채택하고 있으며, ‘플레이북’이라고 하는 ‘AML 구성 언어’로 작성해야 한다. 그 이후에 인프라에 원하는 상태를 지정한 다음 프로비저닝을 수행할 수 있도록 한다. 앤서블은 도커(Docker) 컨테이너 및 쿠버네티스(Kubernetes) 배포의 프로비저닝 자동화에 적합하다.

테라폼과 앤서블을 함께 사용해도 된다. 예를 들면 테라폼을 이용해 네트워크 토폴로지(VPC, 라우팅 테이블), 데이터 저장소(MySQL), 로드 밸런서 및 서버를 포함한 인프라를 배포한 후에, 자동화 애플리케이션인 앤서블 배포하면 클라우드 인프라를 보다 효율적으로 관리할 수 있다.

이 같은 오픈소스 기반의 IaC 툴도 있지만, CSP에서 직접 개발한 IaC 서비스도 있다. 대표적으로 AWS의 경우 자체적으로 개발한 IaC 툴인 ‘AWS 클라우드 포메이션(AWS CloudFormation)’이 있다. 하지만 AWS의 클라우드 서비스만 지원한다는 한계를 갖고 있다. 때문에 멀티 클라우드 환경을 구현하고자 하는 기업들에게는 ‘테라폼’이나 ‘앤서블’과 같은 IaC 툴이 각광받고 있다.

현재 ‘테라폼’을 국내 시장에 공급하고 있는 기업은 하시코프다. 하시코프는 메가존, 베스핀글로벌과도 파트너십을 체결하기도 했다. 최근에는 클루커스와 파트너십을 맺고 비즈니스를 강화하고 있다. 하시코프는 국내 시장 공략을 위해 클루커스에게 IaC 주요 기술에 대한 심층 기술 교육을 실시하는 등 기술 지원에 대한 투자를 확대하고 있다. 또한 엔터프라이즈향 특화 서비스 개발은 물론 공동 마케팅도 진행할 예정이다.

홍성완 클루커스 대표는 “IaC는 클라우드를 도입하려는 고객들에게 특정 클라우드에 구애받지 않고 프라이빗 클라우드까지도 관리할 수 있는 도구이기 때문에 관심이 늘어나고 있다”면서, “점차 ‘테라폼’으로 관리할 수 있는 영역이 확대되고 있어 향후 이 시장은 고속성장이 확실시 된다”고 전망했다.

이어 그는 “클루커스 역시 고속 성장이 확실시 되는 이 시장공략을 위해 파트너십을 체결했다. ‘테라폼’, ‘볼트(Vault)’, ‘노마드(Nomad)’, ‘콘솔(Consul)’ 등 4가지 IaC 툴을 패키지화해 고객들에게 공급할 예정이다. 또한 단순한 리셀링보다 기술적으로 잘 활용할 수 있도록 기술 지원에도 적극 나설 것”이라고 덧붙였다.

또 다른 IaC 툴인 ‘앤서블’의 경우 레드햇 주도로 공급하고 있다. 주로 오픈소스 ‘앤서블’에 레드햇이 보유한 기술력과 노하우를 덧붙여 다양한 솔루션으로 판매하고 있다. 레드햇은 현재 ‘레드햇 앤서블(Red Hat Ansible)’, ‘레드햇 오픈시프트’ 또는 쿠버네티스, 테라폼 및 깃허브 등으로 구성된 시스템들을 조합해 고객들에게 제공하고 있다. 그 가운데, 레드햇의 ‘앤서블 오토메이션 플랫폼’의 경우 시장조사기관 포레스터리서치가 발간한 보고서에서 ‘리더’를 차지하는 등 기술력을 인정받고 있다. 이 플랫폼은 기업이 인프라, 네트워크, 클라우드, 보안 등 IT 운영 및 개발에 있어 보다 손쉽게 자동화를 구현할 수 있도록 지원한다.

한 업계 담당자는 “현실적으로 모든 기업이 IaC를 사용할 수는 없다. 또 모든 기업들이 그럴 필요도 없다. 하지만 분명히 IaC를 통해 기업의 IT 환경을 변화하고자 하는 기업이 늘어나고 있다”며, “기업들이 자사 IT 환경과 상황을 파악하고 적절한 방향과 솔루션을 찾는다면, 경쟁력을 높이고, 민첩성을 확보하면서 발전해나갈 것”이라고 강조했다.

IaC는 IT 개발과 운영을 유기적으로 혼합하는 데브옵스를 구현할 수 있고, 인기를 더해가는 클라우드 인프라 사용의 효율성을 가져다줄 수도 있다. IaC 수요 기업은 물론 공급 기업도 늘어나는 이유다. 국내 IaC 시장 성장이 확실시 되는 가운데, 이를 둘러싼 기업들의 경쟁도 치열해지고 있다.