Terraform으로 Azure 인프라를 코드로 정의하다

KT와 Microsoft가 파트너십을 맺고 Azure 클라우드를 본격적으로 쓰기 시작하면서, 현재까지 여러 분야의 다양한 서비스가 구축되고 있습니다.

Azure 클라우드를 사용하는 초반에는 포탈에서 일일이 클릭하며 인프라를 만드는 작업이 반복했습니다. 환경이 복잡해지고 규모가 커질수록 이런 수작업은 실수와 장애로 이어지기 쉬웠고, 운영 효율성에도 한계가 있었죠. 우리는 이 문제를 해결하기 위해 Terraform을 이용한 Infrastructure as Code(IaC) 도입을 결정했습니다.

Azure 라는 퍼블릭 클라우드 환경을 기반으로, 반복 작업을 제거하고 표준화된 인프라 운영을 실현하는 것이 우리의 첫 번째 목표였습니다.

Terraform 도입 배경

Terraform을 이용한 IaC를 도입하게 된 계기는 단순한 자동화의 필요 때문만은 아니었습니다. 우리가 실제로 마주한 문제는 인프라 환경의 복잡도 증가, 그리고 그에 따라 발생하는 사람 중심 운영 방식의 한계였습니다.

반복되는 클릭 작업: 환경이 늘어날수록 똑같은 리소스를 여러 번 만들고 설정해야 했습니다. 이를 위해 별도의 가이드 문서를 작성해두었지만, 수동 작업에서 오는 실수는 피할 수 없었습니다.
리소스 설정 및 네이밍 규칙과 같은 표준 불일치: 리소스 구성을 할 때에는 네이밍 규칙을 포함한 표준에 맞는 구성이 필수적이지만, 사람이 수동으로 설정하다 보니 자주 누락이나 차이가 발생했습니다. 특히 라우팅 테이블 설정이나 가상 네트워크 설정 같은 세부 항목에서 문제가 발생하곤 했습니다.

Terraform을 도입함으로써 우리는 다음을 기대했습니다.

모듈 - 컴포넌트화를 통한 재사용성 확보: 자주 쓰는 리소스를 모듈로 만들면 반복 작업이 사라지고 실수도 줄어듭니다.
인프라를 선언적으로 정의: 어떤 상태가 되어야 하는지를 코드로 명시할 수 있어, 일관성 유지와 관리가 수월합니다.
버전 관리 및 협업 가능: Git과 연계해 코드 리뷰, 변경 이력 추적, 롤백 등이 가능해집니다.
플랫폼 독립성: AWS, GCP 등 다양한 클라우드에 적용할 수 있어, 장기적으로 멀티 클라우드 전략에도 대응할 수 있습니다.

Terraform으로 Azure 인프라 정의하기

Terraform 도입 이후 가장 먼저 고민한 것은 인프라를 코드로 어떻게 구조화할 것인가였습니다. 단순히 리소스를 모듈화하는 것만으로는 복잡한 시스템 구성을 효율적으로 관리하기 어려웠기 때문에, 코드의 확장성과 관리 편의성을 고려해 모듈(module)과 컴포넌트(component) 개념을 분리하여 설계했습니다.

디렉토리 구조: module vs component

Terraform 코드의 상위 디렉토리 구조는 다음과 같은 기준에 따라 구분했습니다:

modules/: 리소스 단위의 재사용 가능한 모음. 예: VM, AKS, DB 등
components/: 모듈들을 조합하여 실제 인프라를 구성하는 단위. 동일한 목적/생명주기를 가지는 리소스를 하나의 컴포넌트로 구성하고, 단일 상태파일(tfstate) 로 관리

terraform/
├── modules/
│   ├── aks/
│   ├── vm/
│   ├── paasdb/
├── components/
│   ├── network/
│   │   ├── main.tf
│   │   ├── variables.tf
│   │   ├── var.auto.tfvars
│   ├── common/
│   │   ├── ...
│   ├── keyvault/
│   │   ├── ...1
2
3
4
5
6
7
8
9
10
11
12
13
14

이 구조는 다음과 같은 장점을 가집니다.

리소스 재사용 극대화: 모듈은 여러 컴포넌트에서 공통으로 활용 가능
관리 단위 명확화: 컴포넌트 단위로 상태 파일 분리 가능해, 변경 관리/롤백이 쉬움
구현과 배포의 유연성: 각 컴포넌트는 독립적인 배포 단위로 취급 가능

상태 관리(Backend)

Terraform 상태파일은 공통 인프라에 존재하는 Azure Storage를 백엔드로 사용하여 각 컴포넌트별로 분리 관리했습니다.

terraform {
  backend "azurerm" {
    resource_group_name  = "tfstate-rg"
    storage_account_name = "tfstateacct"
    container_name       = "tfstate"
    key                  = "network.tfstate"
  }
}1
2
3
4
5
6
7
8

이로 인해 다음과 같은 이점이 있었습니다.

환경별 분리보다 기능별 분리에 초점을 둔 유연한 상태 관리
충돌 방지 및 병렬 작업 가능
컴포넌트별 롤백 및 추적이 쉬움

이러한 구조는 Terraform 코드의 표준화, 재사용성, 협업 효율성을 높이는 데 크게 기여했습니다. 모듈화된 코드와 컴포넌트 단위의 상태 관리로 인해 신규 리소스 추가나 변경 시에도 전체 시스템에 미치는 영향을 최소화할 수 있었고, 신규 인프라 담당자가 업무에 적응하는 시간 또한 단축할 수 있었어요.

자동화로 얻은 운영 효율성

Terraform을 통해 인프라를 코드로 관리하게 되면서, 우리는 반복적인 수작업을 줄이고 점진적으로 운영 자동화 체계를 갖춰 나가고 있습니다.

현재는 아직 완전한 자동화 단계에 도달하진 않았지만, GitHub Actions를 활용한 자동화를 도입하고 있으며, 향후에는 코드 병합만으로도 변경 사항 검토 및 리소스 생성까지 자동으로 이뤄지는 구조를 목표로 하고 있습니다.

GitHub Actions 기반 워크플로우 구축

현재 우리는 Terraform 코드 변경 사항을 GitHub에 PR(Pull Request)로 등록하고, 리뷰 및 병합하는 과정을 통해 인프라를 관리하고 있습니다. 이 과정에서 GitHub Actions를 이용하여 다음과 같은 워크플로우를 구현하고 있습니다.

별도의 브랜치를 이용하여 작업 진행 → terraform plan workflow 를 수행하여 변경 사항 검증
검증 이후 코드 병합
병합 이후 terraform apply workflow 를 수행

현재는 terraform plan과 최종 배포(terraform apply) 모두 검토 후 수동으로 GitHub Portal에서 실행하고 있습니다. 이는 안정성과 검증 단계를 우선시하기 위한 선택이지만, 중장기적으로는 terraform apply까지 자동화하여 병합만으로 리소스가 반영되도록 발전시킬 계획입니다.

자동화 도입의 효과와 기대

현 시점에서 GitHub Actions를 도입한 것만으로도 다음과 같은 긍정적 변화가 있었습니다.

인프라 변경사항이 명확히 드러나고, 팀 내 협의 및 리뷰가 수월해짐
인프라 변경 이력이 코드 저장소에 남아 추적 가능
병렬 작업을 통한 작업 효율성 증가

향후 apply까지 자동화되면 다음과 같은 효과를 기대할 수 있습니다.

배포 시간 단축: 수동 명령어 입력 없이도 리소스 반영
운영 일관성 확보: PR 기반 검증 → 반영이라는 안정적인 흐름 정착
팀 간 협업 강화: 누구나 일관된 방식으로 인프라에 기여 가능

Terraform과 GitHub Actions를 연계한 자동화는 단순한 편의성을 넘어, 검증과 협업, 안정성까지 고려한 인프라 운영 방식으로 자리 잡아가고 있습니다.

지금은 그 첫걸음 단계지만, 향후에는 보다 완전한 GitOps 기반의 자동화 구조로 나아갈 수 있을 것입니다.

기술 내재화를 위한 여정과 우리가 얻은 것들

Terraform을 중심으로 한 IaC(Infrastructure as Code) 기반의 인프라 운영은 단순한 자동화 도구 도입을 넘어서, KT 클라우드 기술력 내재화의 중요한 기점이 되었습니다. 초기에는 낯선 HCL 문법과 Terraform 구조를 이해하는 데 적지 않은 시간이 필요했지만, 점차적으로 내부 표준을 세우고, 모듈화와 컴포넌트화 전략을 정립해가며 조직 전체의 역량을 끌어올릴 수 있었습니다.

Microsoft와의 협업으로 시작된 기술 내재화

이번 프로젝트는 Microsoft와의 긴밀한 기술 협업을 통해 출발했습니다. Azure 환경에서의 리소스 설계 및 구현에 대한 초기 가이드를 함께 다듬고, Terraform 모듈 구성 방식이나 Best Practice 공유를 통해 보다 체계적인 접근 방식을 구축할 수 있었습니다.

Microsoft와의 기술 협업 과정에서 팀원들이 Terraform 자체에 대한 이해를 깊이 있게 쌓았고, Azure 리소스 구조에 대한 통찰을 얻게 되었습니다. 이 경험은 향후 비슷한 요구가 발생했을 때 외부 도움 없이도 유연하게 설계하고 대응할 수 있는 토대가 되었습니다.

우리가 진짜로 얻은 것들

이번 IaC 도입과 자동화 환경 구축 과정을 통해 얻은 가장 큰 성과는 단순한 ‘시간 절약’이 아니었습니다. 진짜로 얻은 것은 “기술을 내 것으로 만든 경험” 이었습니다.

다음은 그 여정에서 우리가 얻은 주요한 것들입니다.

반복 작업의 제거와 실수 감소수작업으로 리소스를 만들 때마다 발생했던 오타, 누락, 순서 오류 등 문제들이 사라졌습니다.
변경 이력의 추적 가능성과 감사 기능 강화모든 변경은 Git을 통해 기록되며, 누가 어떤 변경을 했는지 언제든지 추적할 수 있게 되었습니다.
DevOps 문화로의 전환 기반 마련단순 인프라 담당자가 아니라, 코드를 통해 시스템을 설계하고 개선할 수 있는 DevOps 마인드셋을 팀 전반에 확산시켰습니다.
기술 독립성 확보외부 기술 지원 없이도 필요한 리소스를 설계하고 배포할 수 있는 자율성과 자신감이 생겼습니다.

Terraform을 통한 Azure 인프라 관리 체계의 도입은 단순한 툴셋의 변화가 아니라, 조직의 인프라 운영 문화를 바꾸는 전환점이었습니다. 자동화와 코드 기반 운영은 끝이 아니라 시작이며, 우리는 이제 그 위에서 더 높은 효율과 안정성을 향해 도전할 수 있는 기반을 갖추었습니다.

마치며

Terraform은 도입 그 자체보다, 도입 이후 어떻게 활용하고 내재화하느냐가 더 중요합니다. 저희는 앞으로 다음과 같은 방향으로 발전시켜나가려 합니다.

신규 모듈 개발 및 운영 고도화
GitHub Actions를 활용한 자동화 고도화
IaC 기반 거버넌스 내재화

이번 IaC 프로젝트를 통해 KT는 수작업에서 자동화로, 외부 의존에서 기술 자립으로 한 걸음 더 나아갔습니다. 그리고 이 경험은 단순한 프로젝트 완수에 그치지 않고, 앞으로의 클라우드 전환과 운영 혁신을 이끄는 기반이 될 것입니다.

Terraform과 GitHub Actions, 그리고 Azure를 연결하는 이 여정은 이제 막 기반을 다졌을 뿐입니다. 앞으로 더 많은 실험과 시도, 개선을 통해 더 나은 자동화, 더 강한 기술력으로 나아가고자 합니다.

Terraform을 이용한 Azure 인프라 구축 환경 개선