지난 몇 년간 인간의 개입 필요성을 줄여주는 자동화가 IT 분야의 주요 트렌드로 자리잡았다. 가상화는 개발자들이 생산 시스템과 격리된 공간에서 작업을 할 수 있는 가상 서버 공간을 탄생시켰다. 이제 20분 정도면 VM웨어(VMware)와 하이퍼-V(Hyper-V) 같은 하이퍼바이저를 구현할 수 있다.
그러나 가상 작업공간 프로비저닝이 늘 간단한 것은 아니다. 많은 시간이 필요한 프로세스가 요구될 수 있으며, 이를 구현할 전문성을 가진 사람이 없을 수도 있다. 개발자가 개발 작업을 위한 가상 환경을 요청한 후, VM 준비까지 2주를 기다려야 할 수 있다. 이런 상황에 IAC(Infrastructure as Code)가 필요하다.
IAC는 유연성이 떨어지는 스크립팅이나 수동 프로세스 대신 코드를 이용해 시스템을 자동으로 구축, 관리, 프로비저닝 하는 IT 인프라 프로비저닝 프로세스의 일종이다. 이에 따라 IAC를 때론 ‘프로그래밍이 가능한 인프라’라고 부르기도 한다. 당연한 말이지만 코드가 탄탄하면 프로세스를 앞당기고 인적 실수를 없앨 수 있다.
쏘우트워크스 유럽(ThoughtWorks Europe)의 지속적 전달(Continuous Delivery) 책임자인 키프 모리스는 “IAC는 클라우드, 마이크로서비스, 지속적 전달 시대에 IT 인프라를 관리할 수 있는 방법이다. IT 인프라를 소프트웨어처럼 다룬다는 기본 개념을 갖고 있다. 이는 손쉽고 빠르게, 안전하면서도 믿을 수 있게 변화를 추구하는데 도움을 준다”라고 설명했다.
코드를 이용함으로써 가상 머신이나 콘테이너를 설정 및 구성하는 프로세스를 자동화하면서 이를 반복적으로 빠르게 되풀이 하는 방안을 만들어낼 수 있다. 예를 들어 애플리케이션을 개발하는 가상 환경을 구축하고 싶다면, 동일한 코드를 실행시켜 VM 생성 프로세스를 반복할 수 있다.
IAC는 IT 프로세스를 자동화한다는 점에서 스크립팅과 다르지 않다. 그러나 스크립트에는 단점이 있다. 정적인(고정된) 단계를 자동화할 때 사용하기 때문에 복잡한 단계에 필요한 유연성이 없다는 단점이다.
반면 IAC는 스크립트와 같은 환경에 다용도의 코드를 사용할 수 있다는 장점이 있다. IAC는 생성할 인프라의 종류를 명령한다. 다시 말해, 수동으로 서버 팜을 구성할 필요가 없다. IAC가 대신 처리해주기 때문이다.
개발자들을 위해 기술 에반젤리즘 서비스를 제공하는 픽세이트(Fixate.io)의 공동 설립자 겸 데브봅스(DevOps) 애널리스트인 크리스 라일리는 이와 함께 코드가 문서화가 되는 효과도 있다고 설명했다. 그는 “변경 관리화 및 문서화 인프라와 관련된 프로세스 변화이다. 누구나 스크립트를 참조하고, 서버 종류나 노드 종류의 구성을 알 수 있다”라고 말했다.
IAC의 구성 요소
IAC가 제품이 아닌 방법론이라는 점을 유념해야 한다. IAC는 그저 빠르게 가상 환경을 배포할 수 있는 프로세스다.
IAC를 제대로 도입하기 위해서는 3가지 필요하다. 애자일 개발 프로세스, 디봅스 환경, 코드를 쓸 도구들이다. 디봅스와 애자일은 개발을 앞당기고, 개발자들이 자신의 업무를 더 빨리 완수할 수 있도록 만들어준다.
IAC는 속도가 강조되는 방법이기 때문에 애자일이 필수 요소가 된다. 라일리는 “개발 팀이 빠르게 움직이는 것이 중요하다. 개발 팀은 애자일을 이용한 소프트웨어 개발에 새로운 방법을 도입하고 있다. 속도가 빨라지고 있으며, 폭포수 개념이 사라졌다”라고 말했다.
모리스는 “애자일은 변화를 도입하고, 이를 예상했던 일로 처리하고, 긍정적으로 수용하는 것을 중시하는 개념이다. 변화를 문제점으로 봤던 기존 방식과는 차이가 있다”라고 말했다.
그는 이어 “자동화 툴을 이용한다고 해도 ‘석기 시대’의 방법론으로 인프라를 관리한다면 혜택을 제대로 누릴 수 없다. 테스트 기반의 개발, 지속적인 통합, 지속적인 전달 등 애자일 엔지니어링 기법을 활용하고 있다면 IAC는 보다 신뢰할 수 있고 도움이 되는 방법론일 수 있다”라고 설명했다.
이후 언어를 선택해야 한다. 대부분의 경우 셰프(Chef)나 퍼펫(Puppet) 중 하나를 이용한다. 두 언어 모두 이 기술에 적합하다. 셰프는 디봅스 환경에서 더 빨리 협력할 수 있게 도와주는 언어이고, 퍼펫은 인프라 구축 프로세스를 자동화하는 언어이다.
모리스는 “셰프와 퍼펫은 아주 성숙한 베스트 프랙티스라고 할 수 있다. 인프라를 관리할 수 있게 만들어진 언어다”라고 말했다.
가트너 애플리케이션 플랫폼 전략 담당 조사 디렉터인 숀 케네픽은 “셰프나 퍼펫은 작업을 손쉽게 만드는 프레임워크를 갖고 있다. 맞춤화 방법, 다른 사람들이 이를 재사용할 수 있게 만드는 방법이 중요하다. 셰프나 퍼펫은 다시 사용할 수 있는 객체를 만들 수 있게끔 도와줄 수 있다”라고 설명했다.
한편 IAC는 플랫폼에 구애 받지 않는다. 윈도우와 리눅스 모두에서 퍼펫과 셰프를 사용할 수 있다. 케네픽은 자신의 경우 리눅스 기반의 클라이언트에서 이용하고 있지만, 윈도우 환경을 이용하는 많은 고객들이 IAC를 문의해오고 있다고 전했다.
유일한 단점은 좋은 문서와 자료가 부족하다는 것이다. IAC는 새로운 개념이다. 엔터프라이즈 자바 개발 등과 달리 관심 있는 사람들이 연구할 내용이 많이 남아있다. 자바 코딩의 경우 수 많은 책과 웹사이트가 있다. 자바의 역사는 20년에 달하기 때문이다. 그러나 IAC의 역사는 2년에 불과하다.
IAC를 다룬 좋은 문서가 부족하다고 생각해 책을 저술하고 있는 모리스는 “개념과 많은 도구들이 성숙기에 도달하고 있다. 그러나 기업과 기관이 아직까지 이를 도입하는 방법, 프로세스와 체계 맞게 조정하는 방법을 찾고 있는 중이다”고 말했다.
그는 현재로서는 IAC에 대한 베스트 프랙티스를 배우고 싶다면 블로그 게시글과 기사를 읽거나, 디봅스 컨퍼런스에 참석해야 한다고 덧붙였다.
IAC의 장점
IAC를 도입하면 개발자들을 기쁘게 만들 수 있다. 특히 2가지 간접 혜택이 있다. 셰도우 IT(Shadow IT) 감소 및 비용 절감이다.
케네픽은 “뭔가를 더 빨리, 더 오류 없이, 더 낮은 위험에 실행 또는 구현할 수 있기 때문에 금전적인 이익이 있다. 맨아워(Man hours)를 4일에서 15분으로 단축할 수 있다. 사람들이 이렇게 절약한 시간에 다른 일을 할 수 있다는 의미이다. 따라서 시간 관리 측면에서도 장점이 있다”라고 말했다.
또 개발자들이 IT 부서가 작업을 할 수 있는 새 VM을 프로비저닝 하기 전까지 오랜 시간을 기다릴 필요가 없기 때문에 ‘음지의 IT’가 감소할 수 있다.
라일리는 “개발자들은 어떻게든 자신의 일을 추진하려는 경향을 갖고 있다. 개발자들은 지금 당장 필요한 VM을 갖기 원한다. 이에 관한 불만이 가장 높다. 이것이 불가능할 경우 버츄얼박스(VirtualBox)나 도커(Docker)를 찾게 될 것이다. 그런데 둘 모두 위험이 있다”라고 말했다.
그에 따르면 도커는 작업을 빨리 시작할 수 있는 이미지가 위치한 퍼블릭 허브다. 그런데 이미지나 코드의 출처를 알 수 없다는 문제점이 있다. 원하지 않는 앱, 스파이웨어, 맬웨어, 허트블리드(Heartbleed)가 들어 있을 수 있다. 감사를 할 수 있는 경로가 없기 때문에 문제의 근원을 추적해 파악할 방법이 없다.
현재 도커를 비롯해 DCHQ, Calm.io 등이 이 문제를 해결하기 위해 노력하고 있다. 후자는 도커 콘테이너와 관련된 프로비저닝과 감사 경로 구축에 도움을 주고 있다.
케네픽은 클라우드 환경에서 자원을 관리하는 역량이 향후 필요해질 것으로 예측했다. 그에 따르면 아마존이 클라우드에 IAC를 개발할 수 있는 도구를 제공하고 있는데, 아직은 이를 이용하기 어려울 때가 있다.
그는 “수년간 했던 일을 더욱 손쉽게 만들어주는 도구이다. 속도를 높이는 디봅스 방법론으로 자리매김했다”라며 하지만 개발자들의 전문성들이 이를 수용하는데 영향을 미친다고 말했다. dl-ciokorea@foundryco.com
