코드형 인프라(IaC)란 무엇인가?

IaC는 인프라를 소프트웨어로 취급합니다. 팀은 애플리케이션 코드에 사용하는 것과 동일한 방식으로 인프라를 버전 관리하고 테스트 및 배포하기 위해 IaC를 사용합니다. 

이 접근 방식을 통해 팀은 번거롭고 오류가 발생하기 쉬운 기존의 수동 구성을 우회할 수 있습니다. 수동 구성에는 개별 서버 설정, 콘솔 기반 관리 및 문서화되지 않은 변경 사항이 포함되는 경우가 많습니다.

대신 팀은 필요한 리소스(서버, 네트워크, 데이터베이스, 보안 정책)와 구성 방법을 명시한 인프라 요구사항을 구성 파일에 정의합니다. 이러한 파일은 버전 제어 시스템에 저장되어 추적, 검토 및 롤백 기능을 제공합니다.

IaC는 코드와 자동화를 사용하여 IT 인프라를 라이프사이클 전반에 걸쳐 관리하는 광범위한 인프라 자동화 관행의 핵심 요소입니다. IaC를 사용하면 개발자는 애플리케이션을 개발하고 테스트 또는 배포할 때마다 인프라 구성 요소를 수동으로 프로비저닝하지 않아도 됩니다. 이러한 자동화를 통해 조직은 비용을 관리하고 위험을 줄이며 새로운 비즈니스 기회에 신속하게 대응할 수 있습니다.

조직이 클라우드 네이티브 아키텍처를 채택함에 따라 IaC의 중요성은 더욱 커지고 있습니다. 오늘날 IT 환경은 멀티 클라우드, 수천 개의 컨테이너 그리고 분산 마이크로서비스로 구성됩니다. 팀은 매일 수백 개의 애플리케이션을 빈번하게 배포하고, 인프라를 지속적으로 프로비저닝, 확장 및 폐기합니다. 한때 몇 대의 서버만 관리하던 수동 프로세스로는 이러한 아키텍처를 관리할 수 없습니다.

IaC는 이러한 복잡한 환경을 다음과 같은 세 가지 핵심 방식으로 관리합니다.

• 대규모 운영: 여러 환경에 걸쳐 수천 개의 서버, 컨테이너 및 클라우드 리소스를 구성하고 유지 관리합니다.
  
  
• 배포 주기 가속화: 시간이 오래 걸리는 수동 구성 없이 수요 변화에 맞춰 인프라를 즉시 확장합니다.
  
  
• 일관성 보장: 보안 취약성, 규정 준수 위반 및 서비스 중단으로 이어질 수 있는 인적 오류 및 구성 드리프트를 제거합니다.

예를 들어 블랙 프라이데이를 준비하는 소매업체는 몇 시간 안에 100~1,000대의 서버를 확장해야 할 수 있습니다. IaC를 사용하면 이러한 확장이 미리 정의된 템플릿을 기반으로 온프레미스와 클라우드 인프라 전반에서 자동으로 진행됩니다. 이러한 확장 기능은 각각의 새 서버가 동일한 보안 및 규정 준수 구성을 유지하도록 보장합니다.

IBM 기업가치연구소(IBV)에 따르면 경영진의 65%는 IaC와 같은 자동화 기술이 IT 팀의 생산성을 향상시키고 있다고 보고했습니다.

IaC는 반복 가능한 워크플로우와 자동화된 툴링을 결합합니다. 워크플로(작성, 버전 관리, 프로비저닝 및 배포)는 팀이 인프라 요구 사항에서 배포된 리소스로 전환하는 방식을 정의합니다. 구성 파일, 버전 제어 시스템 및 자동화 엔진과 같은 도구는 인프라를 정의하고 추적하며 생성하는 메커니즘을 제공합니다.

이러한 요소들은 함께 작동해 인프라 관리를 오류 발생 가능성이 높은 수동 프로세스에서 자동화되고 반복 가능한 기능으로 전환합니다. 팀은 소프트웨어에서와 같이 고유한 버전을 갖춘 상태로 인프라를 코드로 작성하며, 필요할 때 동일한 환경을 배포합니다.

IaC 워크플로는 다음과 같은 네 단계를 따릅니다.

개발자는 Java™ 또는 Python으로 애플리케이션 코드를 작성하는 것과 유사한 방식으로 HCL, YAML 또는 JSON과 같은 언어를 사용하여 IaC 스크립트를 생성합니다. 팀은 필요한 리소스와 구성 방법을 지정하는 인프라 정의를 작성합니다. 이들은 종종 오류 검사 및 자동 완성 기능을 제공하는 통합 개발 환경(IDE)에서 이러한 파일을 작성합니다.

코드는 Git이나 GitHub와 같은 버전 제어 시스템(소스 제어 또는 소스 코드 리포지토리라고도 함)에 저장됩니다. 버전 제어는 변경 사항을 추적하고 대체 버전을 유지 관리하며, 문제가 발생할 경우 팀이 이전 버전으로 복원할 수 있도록 지원합니다.

자동화 엔진은 구성 파일을 읽고 지정된 인프라 리소스를 프로비저닝합니다. 이 단계에서는 코드를 실제 인프라로 변환합니다. 즉, 가상 머신(VM)을 생성하고 네트워크를 구성하며, 데이터베이스와 보안 그룹을 설정합니다. 프로비저닝 프로세스는 멱등성이므로 여러 번 실행해도 결과가 변하지 않으며 중복 리소스를 생성하지 않습니다.

팀은 스크립트를 실행하여 다양한 환경에 인프라를 배포하며 IaC는 환경 전반에 걸쳐 일관된 구성을 보장합니다. 스크립트의 일관성은 애플리케이션에 대한 소프트웨어 변경 사항이 자동으로 프로덕션 환경에 릴리스되는 지속적인 배포를 사용할 때 가장 효과적입니다. 

자동화된 도구는 코드를 통해 인프라를 정의하고 추적하며, 생성할 수 있는 수단을 제공합니다.

구성 파일은 인프라를 정의합니다. 구성 파일은 HCL, JSON, YAML 또는 도메인 특화 언어로 작성할 수 있습니다. 이러한 파일은 자동화 도구가 읽고 실행할 수 있는 형식으로, 필요한 인프라(서버 수, 규모, 네트워크 설정 등)를 정확하게 설명하는 청사진입니다.

이러한 파일은 팀의 신뢰할 수 있는 단일 소스 역할을 하며 여러 환경에서 일관성을 유지하는 데 도움이 됩니다. 팀이 자산을 추가할 때마다 이러한 파일은 업데이트, 재사용 또는 새로운 설치에 맞게 활용할 수 있습니다. 

버전 관리 시스템은 각 파일의 이력을 저장합니다. 이 시스템은 원본 코드와 누가 언제 어떤 내용을 수정했는지를 포함한 모든 변경 사항을 추적합니다. 이러한 추적 기능을 통해 팀은 변경 사항을 파악하고 삭제를 복원할 수 있으며 문제가 발생할 때 롤백할 수 있습니다.

버전 제어를 통해 조직은 인프라를 자동화로 결합되는 모듈 단위로 나눌 수 있습니다. 이러한 모듈식 접근 방식은 복잡한 환경을 구축하고 업데이트하며, 버전을 관리하는 데 도움이 됩니다. 또한 중복을 줄이고 스크립트를 더 쉽게 테스트하고 재사용할 수 있도록 합니다.

자동화 엔진은 사전 정의된 코드를 사용하여 프로비저닝 및 구성을 자동화합니다. 이러한 엔진은 구성 파일에 정의된 인프라를 실행하여 코드를 서버, 네트워크, 데이터베이스 등 실제 IT 리소스로 변환합니다.

일부 엔진은 AWS CloudFormation, Azure Resource Manager 또는 Google Cloud Deployment Manager와 같은 클라우드에 특화되어 있습니다. Terraform, Terraform의 오픈 소스 포크인 OpenTofu 그리고 Python 등 범용 프로그래밍 언어를 사용하는 Pulumi 등은 모든 클라우드 환경에서 실행됩니다.

이러한 자동화 엔진은 종종 Kubernetes와 같은 오케스트레이션 도구와 결합되어 대규모 환경에서 리소스와 워크로드를 효율적으로 조율합니다.

IaC 도구는 애플리케이션 프로그래밍 인터페이스(API)를 통해 클라우드 플랫폼과 자주 연동됩니다. 이러한 API 연동으로 IaC 도구는 클라우드 서비스와 직접 통신해, 수동 콘솔 조작 없이 프로그래밍 방식으로 리소스를 생성 및 관리할 수 있습니다.

또한 IaC는 신뢰성을 확보하는 데 도움이 되는 표준 소프트웨어 개발 관행을 도입합니다. 자동화된 테스트를 통해 인프라 구성을 배포 전에 검증할 수 있으며 장애나 보안 취약점으로 이어질 수 있는 오류를 사전에 식별할 수 있습니다. 일부 버전 제어 시스템은 코드가 변경될 때 자동으로 이러한 테스트를 실행하여, 모든 수정 사항이 프로덕션에 반영되기 전에 검증되도록 합니다.

IaC를 구현할 때 조직은 두 가지 주요 사항을 결정해야 합니다. 하나는 인프라를 정의하는 방식(선언형 대 명령형)이며, 다른 하나는 인프라가 배포 후에도 변경 가능한지(가변형 대 불변형) 여부입니다.

선언형과 명령형 접근법의 차이는 인프라 코드를 작성하는 방식에 있습니다.

선언형 접근법(함수형 또는 선언적 IaC라고도 함)이 가장 일반적인 방법입니다. 사용자가 원하는 상태(예: "이 사양을 가진 서버 3대 필요")를 명시하면 IaC가 구현을 처리합니다. IaC는 리소스를 생성하고 필요한 소프트웨어를 설치하며, 상호 종속성을 해결하고 버전 관리를 자동으로 수행합니다.

명령형 접근법(절차형 접근법이라고도 함)에서는 사용자가 인프라를 프로비저닝하는 단계별 명령을 직접 작성해야 합니다. 즉, “먼저 서버를 생성하고, 다음으로 소프트웨어를 설치한 후, 이러한 설정을 구성한다”처럼 명령어를 정확한 순서로 지정해야 합니다. 이 접근 방식에는 더 높은 전문성이 요구되고 일관성 유지가 어려울 수 있습니다.

가변형 인프라는 프로비저닝 후에도 변경할 수 있지만 불변형 인프라는 프로비저닝 이후 변경이 불가합니다.

가변형 인프라는 특정 애플리케이션 요구사항이나 긴급 보안 패치와 같은 임시 변경이 필요한 상황에서 유연성을 제공합니다. 그러나 이러한 유연성은 일관성을 해치고 버전 추적을 어렵게 만들 수 있습니다.

대부분의 조직은 불변형 인프라를 선택합니다. 서버나 구성을 변경하려면 팀은 인프라 전체를 새로운 리소스로 교체해야 합니다.

이 방식이 부담스럽게 들릴 수 있지만, 실제로는 여러 가지 측면에서 유용할 수 있습니다. 첫째, 불변형 인프라는 구성 드리프트를 제거합니다. 드리프트는 가변형 인프라에서 흔히 발생하는 문제로, 시간이 지남에 따라 수동 변경 사항이 누적되어 여러 환경 간의 일관성 유지가 점점 더 어려워지는 현상입니다.

둘째, 불변형 인프라는 각 변경 시 새로운 버전이 지정된 인스턴스를 생성하기 때문에 신뢰할 수 있는 버전 관리와 롤백 기능을 제공합니다. 즉, 팀은 이전의 어떤 구성으로도 즉시 되돌릴 수 있습니다.

마지막으로 클라우드 기반 IaC를 사용하면 신규 인프라를 몇 분 만에 빠르게 프로비저닝할 수 있습니다. 따라서 처음에는 전체 인프라 리소스를 다시 프로비저닝하는 일이 비현실적으로 보일 수 있지만, 실제로는 처음 예상보다 훨씬 더 실용적입니다.

코드 기반 인프라 관리를 자동화함으로써 IaC는 다음과 같은 여러 혜택을 제공합니다.

IaC는 인프라가 소프트웨어 개발의 속도에 맞춰 운영될 수 있게 하여 DevOps 관행에 필수적인 역할을 합니다.

IaC가 없다면 인프라 프로비저닝이 병목 지점이 될 수 있습니다. 코드 배포는 몇 분이면 가능하지만, 인프라 설정은 수 시간 또는 수일이 걸릴 수 있습니다. 예를 들어 새로운 데이터베이스를 추가하려면 인프라 팀에 티켓을 제출하고 며칠을 기다려야 할 수도 있습니다.

IaC는 인프라 배포에 지속적 통합(CI)과 지속적 배포(CD)를 적용하여 이러한 격차를 해소합니다. 인프라 코드와 애플리케이션 코드를 별도의 절차로 처리하지 않고 병렬로 테스트, 검증 및 배포할 수 있습니다.

실제로는 인프라 코드가 애플리케이션 코드와 함께 버전 관리 시스템에 존재하는 경우가 많습니다. 개발자가 변경 사항을 커밋하면 CI/CD 파이프라인은 IaC 템플릿을 사용해 테스트 인프라를 프로비저닝하고, 자동화된 테스트를 실행하며, 동일한 템플릿을 통해 프로덕션 환경에 배포할 수 있습니다. 이를 통해 개발, 테스트, 스테이징, 프로덕션 등 모든 환경이 동일한 인프라 구성을 갖도록 보장합니다.

주요 이점은 일관성입니다. IaC가 없으면 테스트 환경과 프로덕션 환경이 일치하지 않아 환경 차이가 발생하고 배포 실패로 이어질 수 있습니다. IaC는 테스트에서 잘 작동한 설정이 프로덕션 환경에서도 동일하게 작동하도록 보장합니다. 이는 두 환경이 동일한 인프라 정의를 사용하기 때문입니다. 팀은 풀 리퀘스트를 통해 인프라 변경 사항을 검토하고 수정 이력을 추적하며 필요할 경우 롤백할 수 있습니다. 즉, 인프라를 애플리케이션 코드와 동일한 엄격한 기준으로 관리합니다.

IaC 도구는 인프라를 생성하고 배포하는 프로비저닝 도구와 배포 후 인프라를 유지 관리하는 구성 관리 도구의 두 가지 주요 범주로 나뉩니다.

일부 도구는 멀티 클라우드 환경(여러 제공업체에서 동작)을 지원하는 반면 다른 도구는 특정 플랫폼에 특화되어 있습니다.

조직에서는 일반적으로 두 가지 범주의 도구를 결합하여 완전한 IaC 파이프라인을 구축합니다.

프로비저닝 도구는 서버, 네트워크, 스토리지 시스템 등 인프라 리소스를 생성하고 배포합니다. 이러한 도구는 인프라 구성 요소의 초기 설정과 구성을 중점적으로 수행하며 인프라 요구 사항을 실제로 운영 가능한 리소스로 변환합니다. 

IBM 계열사인 HashiCorp의 Terraform은 모든 클라우드 환경에서 실행 가능한 IaC 도구이며, 선언형 구성을 사용해 다양한 플랫폼의 인프라를 관리합니다.

팀은 HCL(HashiCorp 구성 언어)로 인프라 정의를 작성하고 동일한 코드를 AWS, Azure, Google Cloud 또는 온프레미스 데이터 센터에도 배포할 수 있습니다. 이러한 이식성 덕분에 조직은 공급업체 종속을 피하고 각 클라우드 공급자의 강점을 기반으로 조합하여 사용할 수 있습니다. 예를 들어 컴퓨팅에는 AWS를, 머신러닝에는 Google Cloud를 활용할 수 있습니다.

또한 Terraform은 여러 공급업체에서 동시에 리소스를 프로비저닝하여 배포 속도를 높입니다. 리소스 간의 종속성을 분석하여 서로 독립적인 리소스는 병렬로 생성할 수 있습니다. 예를 들어 AWS 서버 10대와 Azure 데이터베이스 5개를 서로 종속성 없이 배포할 경우 Terraform은 15개의 리소스를 순차적으로 생성하지 않고 동시에 배포하여 배포 시간을 단축합니다.

AWS CloudFormation은 AWS 인프라를 위한 Amazon 고유의 IaC 솔루션입니다. 팀은 JSON 또는 YAML 템플릿을 사용해 EC2 인스턴스부터 Rational Directory Server 데이터베이스까지 전체 애플리케이션 스택을 정의합니다. CloudFormation은 리소스 종속성을 자동으로 처리하여 올바른 순서로 생성하고 오류가 발생할 경우 롤백합니다.

AWS 전용이지만, CloudFormation은 AWS 서비스와 깊이 통합되어 있으며 새로운 서비스에 대해서도 즉각적인 지원을 제공합니다. AWS를 주력 플랫폼으로 사용하는 조직은 AWS의 네이티브 성능과 독점 기능 접근성을 선호할 수 있습니다.

Azure Resource Manager (ARM)는 Azure 인프라를 위한 Microsoft의 네이티브 IaC 도구입니다. Azure 전용이지만 플랫폼과 깊이 통합되어 있습니다.

조직은 ARM 템플릿(JSON 형식)을 사용해 Azure 리소스를 정의하고 배포하며 관리합니다. ARM에는 보안을 위한 역할 기반 액세스 제어, 조직을 위한 리소스 태그 지정, 실수로 인한 삭제를 방지하는 잠금, 리소스가 올바른 순서로 배포되도록 보장하는 종속성 매핑 등의 내장 기능이 포함되어 있습니다. 

Google Cloud Deployment Manager는 YAML 또는 Python 템플릿을 사용해 Google Cloud 배포를 오케스트레이션하는 Google의 네이티브 IaC 도구입니다. 플랫폼에 특화된 도구이지만 Cloud Storage(데이터 저장), Compute Engine(VM), Cloud SQL(데이터베이스) 등 여러 서비스를 아우르며, 리소스를 생성하고 구성해 이들이 완전한 스택처럼 함께 동작하도록 지원합니다.

구성 관리 도구는 프로비저닝 이후에도 인프라를 지속적으로 관리하여 시스템이 올바르게 구성되고 패치되며 일관성을 유지하도록 지원합니다. 

Ansible®은 Red Hat®이 제공하는 자동화 도구로, 대상 시스템에 에이전트를 설치하지 않고도 구성을 관리할 수 있습니다. 즉, Ansible은 관리 대상 서버에 별도의 소프트웨어를 설치할 필요가 없으며 SSH를 통해 직접 서버에 연결해 명령을 실행합니다.

이와 같은 에이전트리스(Agentless) 방식으로 Ansible은 클라우드, 온프레미스 그리고 하이브리드 환경 모두에서 동작합니다. 팀은 원하는 시스템 상태를 정의하는 YAML 플레이북을 작성하며, Ansible은 시스템이 해당 상태와 일치하도록 보장합니다. Ansible은 Docker 컨테이너 및 Kubernetes 배포 관리에도 널리 활용됩니다.

Puppet은 선언형 구성을 기반으로 클라우드, 온프레미스 및 데이터 센터 환경에서 대규모 인프라를 관리합니다.

수천 대의 서버를 지속적으로 점검하여 정의된 구성과 일치하는지 확인하고 편차가 발생하면 이를 자동으로 수정합니다. Puppet은 언제 어떤 변경이 이루어졌는지 보여주는 자세한 보고서를 생성하므로 대규모 배포에 효과적입니다.

Chef는 ‘쿡북(Cookbook)’과 ‘레시피(Recipe)’를 이용해 클라우드, 온프레미스, 하이브리드 등 모든 환경에서 인프라 구성을 정의합니다.

많은 조직이 테스트 프레임워크 때문에 Chef를 선택합니다. 팀은 프로덕션에 적용하기 전 테스트 환경에서 구성을 검증할 수 있습니다. 이와 같이 문제를 조기에 발견하는 접근 방식은 인프라 업데이트가 자주 이루어지거나 강력한 테스트 프레임워크를 중시하는 조직에서 선호될 수 있습니다.