카테고리 없음

Terraform의 태그와 태그_all 필드의 차이점

개(dog)발~개발자 2025. 7. 6. 14:09

1. Introduction

Terraform은 클라우드 리소스를 코드 형태로 관리하기 위한 강력한 도구이다. 클라우드 리소스를 관리할 때, 비용 추적, 소유권 식별, 자동화, 접근 제어 정책 적용 등을 위해 태그(Tag)를 사용하는 것은 매우 중요한 모범 사례이다.

이 아티클에서는 Terraform을 사용하여 AWS 리소스에 태그를 지정하는 방법을 살펴본다. 특히, 리소스 속성인 tags와 tags_all의 차이점에 대해 깊이 알아본다.

테라폼이란

Terraform(테라폼)은 HashiCorp에서 개발한 오픈 소스 "코드형 인프라(Infrastructure as Code, IaC)" 도구입니다. 테라폼을 사용하면 클라우드(AWS, GCP, Azure 등) 또는 온프레미스 환경에서 서버, 네트워크, 데이터베이스 등 다양한 인프라 리소스를 코드로 선언하고 자동화하여 구축, 변경, 삭제, 버전 관리할 수 있습니다.

주요 특징은 다음과 같습니다.

  • 코드 기반 인프라 관리: 사람이 읽을 수 있는 코드(HCL: HashiCorp Configuration Language)로 인프라를 정의합니다. 즉, 수동으로 클릭해서 서버를 만드는 것이 아니라, 코드를 작성하고 실행하면 필요한 인프라가 자동으로 만들어집니다.
  • 멀티 클라우드 지원: AWS, GCP, Azure, 네이버클라우드 등 다양한 클라우드 서비스와 온프레미스 환경을 하나의 도구로 관리할 수 있습니다.
  • 자동화와 일관성: 반복적인 인프라 작업을 자동화하고, 코드로 모든 변경 사항을 기록해 일관성과 재현성을 확보할 수 있습니다.
  • 버전 관리 및 협업: Git 등 버전 관리 시스템과 연동해 인프라 변경 이력을 추적하고, 여러 명이 협업할 수 있습니다.

테라폼의 기본 동작 순서는 다음과 같습니다.

  1. 코드 작성: HCL로 필요한 인프라 리소스를 선언합니다.
  2. 계획(plan): 선언한 인프라가 실제로 어떻게 변경될지 미리 확인합니다.
  3. 적용(apply): 선언한 대로 인프라를 실제로 생성, 수정, 삭제합니다.
  4. 파괴(destroy): 모든 리소스를 한 번에 제거할 수 있습니다.

이처럼 테라폼은 인프라를 코드처럼 다루어 자동화, 일관성, 효율성, 협업을 크게 높여주는 현대 IT 환경에서 널리 사용되는 필수 도구입니다

2. Terraform's default_tags Block

Terraform AWS 제공자(provider)는 default_tags 블록을 제공한다. 이를 통해 해당 제공자에 의해 생성되는 모든 리소스에 공통적으로 적용될 태그를 중앙에서 정의할 수 있다.

provider.tf 파일에 다음과 같이 설정할 수 있다.

Terraform
provider "aws" {
  region = "us-east-1"
  default_tags {
    tags = {
      "ManagedBy"   = "Terraform"
      "Project"     = "Baeldung"
      "Environment" = "Dev"
    }
  }
}

이렇게 설정하면, 이 aws 제공자를 통해 생성되는 모든 리소스는 기본적으로 위 세 개의 태그(ManagedBy, Project, Environment)를 상속받게 된다.

3. Resource-Level Tags

개별 리소스 수준에서도 tags 인수를 사용하여 태그를 지정할 수 있다. 이는 특정 리소스에만 적용되는 태그를 추가하거나, 제공자 수준에서 정의된 기본 태그를 재정의(override)하는 데 사용된다.

예를 들어, main.tf 파일에 aws_instance 리소스를 정의하면서 고유한 태그와 재정의된 태그를 추가해 보자.

Terraform
 
resource "aws_instance" "baeldung_instance" {
  ami           = "ami-0c55b159cbfafe1f0" # us-east-1, Amazon Linux 2
  instance_type = "t2.micro"

  tags = {
    "Name"        = "Baeldung-Instance"
    "Environment" = "Production" # 기본 태그 'Dev'를 재정의
  }
}

이 aws_instance 리소스는 "Name"이라는 고유 태그를 가지며, "Environment" 태그의 값은 제공자 수준의 "Dev" 대신 "Production"으로 설정된다.

4. tags vs. tags_all

이제 핵심적인 차이점을 살펴보자. Terraform에서 리소스를 정의하면, 해당 리소스는 tags와 tags_all이라는 두 가지 읽기 전용 속성(attribute)을 노출한다.

  • tags: 리소스 블록 내에서 명시적으로 정의된 태그만을 포함하는 맵(map)이다. 제공자로부터 상속된 기본 태그는 포함하지 않는다.
  • tags_all: 리소스에 적용되는 모든 태그의 최종 병합 결과를 포함하는 맵이다. 제공자의 default_tags와 리소스의 tags가 합쳐진 결과물이다. 만약 키(key)가 충돌하면 리소스 수준의 태그가 우선권을 가진다.

위 예제에서 aws_instance.baeldung_instance에 대해 각 속성이 어떤 값을 가지는지 outputs.tf 파일을 통해 확인해 보자.

Terraform
 
output "instance_tags" {
  value = aws_instance.baeldung_instance.tags
}

output "instance_tags_all" {
  value = aws_instance.baeldung_instance.tags_all
}

terraform apply를 실행한 후 출력된 결과는 다음과 같다.

tags 속성의 출력:

instance_tags = {
  "Name" = "Baeldung-Instance",
  "Environment" = "Production"
}

결과에서 볼 수 있듯이, tags 속성은 aws_instance 블록 내에 직접 정의된 태그들만 보여준다.

tags_all 속성의 출력:

instance_tags_all = {
  "ManagedBy" = "Terraform",
  "Project" = "Baeldung",
  "Environment" = "Production",
  "Name" = "Baeldung-Instance"
}

tags_all 속성은 제공자의 default_tags와 리소스의 tags가 모두 병합된 최종 결과를 보여준다. "Environment" 태그는 리소스 수준에서 정의한 "Production"으로 올바르게 재정의되었다.

5. Comparison Table

tags와 tags_all의 차이점을 명확하게 이해하기 위해 아래 표로 정리했다.

구분 tags tags_all
포함 내용 리소스 블록에 명시적으로 정의된 태그만 포함한다. 제공자 수준의 기본 태그(default_tags)와 리소스 수준 태그가 모두 병합된 최종 결과이다.
상속 제공자로부터 태그를 상속받지 않는다. 제공자로부터 태그를 상속받는다.
재정의 재정의 개념이 적용되지 않는다. (자기 자신만 표시) 키가 충돌할 경우, 리소스 수준의 태그가 제공자 수준의 태그를 재정의한다.
주요 용도 특정 리소스에 어떤 태그가 직접 할당되었는지 확인할 때. 리소스에 최종적으로 적용된 모든 태그의 전체 그림을 확인하거나 다른 리소스에서 참조할 때.
Sheets로 내보내기

6. Conclusion

이 아티클을 통해 Terraform의 tags와 tags_all 속성 간의 명확한 차이를 알아보았다.

  • tags는 리소스에 직접 할당된 태그만을 나타낸다.
  • tags_all은 제공자 기본 태그와 리소스 태그가 병합된 최종 태그 집합을 나타낸다.

이 차이점을 이해하는 것은 Terraform 코드를 디버깅하고, 리소스에 적용된 태그를 정확히 파악하며, 일관성 있는 태그 전략을 유지하는 데 매우 중요하다. 일반적으로 리소스에 적용된 전체 태그를 참조해야 할 때는 tags_all을 사용하는 것이 권장된다.

 

 

원본: https://www.baeldung.com/ops/terraform-tags-vs-tags_all