코드형 인프라(IaC)는 컴퓨팅 인프라를 관리하고 프로비저닝하는 방법론입니다. 수동으로 물리적 하드웨어를 조정하거나 대화형 구성 도구를 사용하는 대신, 구성에 기계 가독형 정의 파일을 사용합니다. 팀은 개발자가 애플리케이션 코드를 처리하는 것과 동일한 방식으로 인프라 설정을 처리하여 네트워크, 가상 머신, Kubernetes 클러스터, 데이터베이스, 부하 분산기의 배포를 빠르고 안정적으로 자동화할 수 있습니다. 최신 DevOps 관행의 구성요소 역할을 하며 조직이 일관성과 속도를 유지하면서 확장할 수 있도록 지원합니다.
IaC는 코드를 통해 프로비저닝 프로세스를 자동화하여 Cloud 콘솔에서 수동으로 설정할 필요가 없도록 합니다. 먼저 개발자가 원하는 인프라 사양을 구성 파일에 정의합니다. 이 구성 파일은 일반적으로 버전 제어 시스템에 저장됩니다. 그러면 Terraform과 같은 자동화 도구가 이러한 파일을 처리하고 클라우드 제공업체에 필요한 API 호출을 수행하여 실제 리소스를 생성, 업데이트 또는 삭제합니다. 이 워크플로는 일반적으로 코드(정의)에서 버전 제어, CI/CD 파이프라인을 거쳐 프로비저닝에 이르는 경로를 따릅니다.

IaC를 구현할 때 팀은 일반적으로 선언적 접근 방식과 명령형 접근 방식 중에서 선택합니다. 주요 차이점은 최종 결과에 중점을 두는지 아니면 최종 결과에 도달하기 위한 단계에 중점을 두는지에 있습니다.
접근 방법 | 설명 | 예 |
선언적 | 최종 상태가 어떤 모습이기를 원하는지 정의합니다. 도구가 해당 상태를 달성하는 데 필요한 단계를 파악합니다. 이는 Terraform 및 Kubernetes와 같은 도구의 최신 표준입니다. | "각각 8GB RAM이 있는 가상 머신 3개를 원해." |
명령형 | 순서대로 실행할 특정 명령어 또는 스크립트를 나열하여 인프라를 변경하는 방법을 정의합니다. | "스크립트 A를 실행하여 서버 1을 시작합니다. 그런 다음 스크립트 B를 실행하여 네트워크를 구성합니다. 그런 다음 스크립트 C를 실행합니다..." |
접근 방법
설명
예
선언적
최종 상태가 어떤 모습이기를 원하는지 정의합니다. 도구가 해당 상태를 달성하는 데 필요한 단계를 파악합니다. 이는 Terraform 및 Kubernetes와 같은 도구의 최신 표준입니다.
"각각 8GB RAM이 있는 가상 머신 3개를 원해."
명령형
순서대로 실행할 특정 명령어 또는 스크립트를 나열하여 인프라를 변경하는 방법을 정의합니다.
"스크립트 A를 실행하여 서버 1을 시작합니다. 그런 다음 스크립트 B를 실행하여 네트워크를 구성합니다. 그런 다음 스크립트 C를 실행합니다..."
IaC는 검색 증강 생성(RAG) 애플리케이션과 같은 일반적인 배포 패턴을 지원할 뿐만 아니라 복잡한 운영 배포의 과제를 해결하는 데도 도움이 됩니다.
엔터프라이즈는 종종 다양한 환경에서 워크로드를 실행해야 합니다. 팀은 Terraform과 같은 도구를 사용하여 단일 구성 워크플로로 Google Cloud, 다른 클라우드 환경, 온프레미스 데이터 센터 전반에서 리소스를 동시에 배포하고 관리할 수 있습니다. 따라서 플랫폼마다 다른 독점 도구를 학습해야 하는 복잡성이 줄어듭니다.
개발자는 새로운 기능을 테스트할 안전한 장소가 자주 필요합니다. IaC를 사용하면 팀에서 프로덕션을 정확히 미러링하는 임시 '스테이징' 환경을 가동하고, 테스트를 실행한 다음, 환경을 즉시 폐기할 수 있습니다. 이렇게 하면 테스트 정확성을 보장하면서 24시간 연중무휴로 실행되는 영구 스테이징 서버를 유지하는 비용을 절감할 수 있습니다.
치명적인 리전 서비스 중단이 발생하면 수동 복구에 며칠이 걸릴 수 있습니다. IaC는 '코드형 재해 복구'를 지원하므로 조직은 기존 코드 정의를 사용하여 다른 리전에서 전체 인프라를 신속하게 다시 프로비저닝할 수 있습니다. 이를 통해 다운타임을 획기적으로 줄이고 비즈니스 연속성을 보장할 수 있습니다.
IaC를 도입하면 IT 운영을 현대화하려는 조직에 상당한 이점을 제공할 수 있습니다.
속도
자동화를 사용하면 며칠 또는 몇 주가 아닌 몇 분 만에 복잡한 환경을 배포할 수 있습니다.
일관성
동일한 코드가 매번 동일한 환경을 배포하기 때문에 IaC는 수동 임시 변경으로 인해 서버가 일관성을 잃는 '구성 드리프트'를 제거합니다.
비용 절감
팀은 주말에 개발 환경을 끄는 등 필요하지 않은 리소스를 쉽게 중지하여 클라우드 비용을 관리할 수 있습니다.
버전 제어
인프라가 코드로 정의되므로 인프라 변경의 전체 기록이 한곳에 저장됩니다. 이를 통해 누가 무엇을 변경했는지 쉽게 추적하고 문제가 발생한 경우 이전 버전으로 롤백할 수 있습니다.
Google Cloud는 초기 설계부터 배포, 지속적인 관리에 이르기까지 코드형 인프라 여정을 지원하는 포괄적인 도구 모음을 제공합니다. App Design Center는 사전 빌드된 참조 아키텍처를 탐색, 맞춤설정, 빌드할 수 있는 훌륭한 시작점입니다. 이를 통해 단 한 줄의 코드를 작성하기 전에 Google Cloud 권장사항을 기반으로 애플리케이션 스택을 설계하여 처음부터 인프라를 잘 설계할 수 있습니다.
설계가 완료되면 Google Cloud의 개방형 생태계를 통해 코드로 쉽게 구현할 수 있습니다. 이 플랫폼은 Terraform과 같은 오픈소스 표준을 사후 고려 사항이 아닌 핵심 요소로 취급합니다. Infrastructure Manager와 같은 서비스를 사용하면 Terraform을 직접 사용하여 Google Cloud 리소스를 배포하고 관리할 수 있으며, Config Connector를 사용하면 Kubernetes를 통해 Google Cloud 리소스를 관리하여 클라우드 인프라와 컨테이너 조정 간의 격차를 해소할 수 있습니다.
Cloud Resource Manager는 조직, 폴더, 프로젝트를 포함한 Google Cloud 리소스 계층 구조를 프로그래매틱 방식으로 관리하는 서비스 역할을 합니다. 많은 팀이 IaC를 사용하여 가상 머신과 같은 리소스를 배포하는 반면, Cloud Resource Manager를 사용하면 프로젝트 구조 자체를 코드로 정의할 수 있습니다. 이를 통해 팀은 일관된 Identity and Access Management(IAM) 정책과 조직 제약 조건으로 새로운 환경을 자동으로 설정하여 처음부터 인프라에 거버넌스를 적용할 수 있습니다.
IaC를 사용하는 가장 가치 있는 방법 중 하나는 '내 머신에서는 작동했는데 왜 프로덕션에서는 작동하지 않지?'라는 일반적인 개발자 문제를 해결하는 것입니다. 임시 환경을 만들어 이 문제를 해결할 수 있습니다.
이 워크플로에서는 개발자가 pull 요청(PR)을 열면 IaC 도구가 앱의 임시 격리된 사본을 자동으로 가동합니다. PR이 병합되면 환경이 자체적으로 소멸됩니다.
이 기능을 사용하려면 Terraform 코드에 하드 코딩된 이름이 없어야 합니다. 변수를 사용하여 모든 PR에 대해 고유한 리소스를 만들어야 합니다.
main.tf(스니펫)
cloudbuild.yaml에서 Cloud Build가 제공하는 _PR_NUMBER 대체 변수를 사용하여 PR 번호를 Terraform에 삽입합니다.
cloudbuild.yaml(스니펫)
이 워크플로를 사용하면 IaC가 정적인 유지보수 작업에서 검토 주기를 가속화하는 동적인 생산성 도구로 전환됩니다.