2025년 1월 17일(금) 주간 개발트렌드

![image](https://librarian-blog-images.s3.ap-northeast-2.amazonaws.com/b28d786c-9ec3-46ec-8055-adcd53a303c5_thumbnail_2.png)

## Cloud / DevOps — OpenTofu 1.9, Terraform 대안 IaC가 본격적으로 성숙

OpenTofu가 **25년 1월 10일 OpenTofu 1.9**를 정식 출시했습니다.

이번 버전의 핵심 기능은 **Provider에 `for_each`를 사용할 수 있게 된 것**입니다.

AWS Multi-Region이나 Kubernetes Multi-Cluster처럼 동일한 Provider를 여러 설정으로 반복해서 사용해야 하는 Infrastructure에서 중복 Configuration을 크게 줄일 수 있게 됐습니다.

이외에도 `-exclude` 옵션, Backend와 Encryption 개선, CLI 기능과 성능 개선 등이 포함됐습니다.

[OpenTofu - OpenTofu 1.9.0](https://opentofu.org/blog/opentofu-1-9-0/)

---

### Infrastructure as Code

IaC(Infrastructure as Code)는 Cloud Infrastructure를 Console에서 직접 생성하는 대신 Code로 정의하고 관리하는 방식입니다.

```text
Infrastructure

VPC
EC2
RDS
S3
Kubernetes
Load Balancer

        ↓

Configuration Code
```

예를 들어 AWS Resource를 다음과 같이 선언할 수 있습니다.

```hcl
resource "aws_s3_bucket" "example" {
  bucket = "example-bucket"
}
```

Infrastructure 변경 사항을 Git으로 관리할 수 있기 때문에 Application Code와 비슷한 방식으로 Infrastructure를 운영할 수 있습니다.

```text
Infrastructure Code
       ↓
Git
       ↓
Review
       ↓
Plan
       ↓
Apply
       ↓
Cloud Infrastructure
```

---

### Terraform 중심의 IaC 생태계

Declarative IaC 영역에서 오랫동안 대표적인 도구는 Terraform이었습니다.

```text
Infrastructure Code
       ↓
Terraform
       ↓
Provider
       ↓
AWS / GCP / Azure / Kubernetes
```

Terraform Provider 생태계를 통해 다양한 Infrastructure를 동일한 방식으로 관리할 수 있다는 것이 큰 장점이었습니다.

OpenTofu 역시 Terraform과 호환되는 IaC Tool을 목표로 발전하고 있습니다.

```text
IaC

├─ Terraform
└─ OpenTofu
```

OpenTofu의 기능이 계속 확대되면서 기존 Terraform 사용자도 실제 Infrastructure 환경에서 비교할 수 있는 선택지가 생기기 시작했습니다.

---

### Multi-Region Infrastructure의 문제

예를 들어 AWS Infrastructure를 세 개 Region에 배포한다고 가정해보겠습니다.

```text
AWS

├─ ap-northeast-2
├─ us-east-1
└─ eu-west-1
```

각 Region에서 동일한 Infrastructure Module을 사용하려면 Region별 Provider Configuration이 필요합니다.

기존에는 다음과 같은 중복 설정이 발생할 수 있었습니다.

```hcl
provider "aws" {
  alias  = "seoul"
  region = "ap-northeast-2"
}

provider "aws" {
  alias  = "virginia"
  region = "us-east-1"
}

provider "aws" {
  alias  = "ireland"
  region = "eu-west-1"
}
```

Region이 늘어날수록 같은 Provider Configuration이 계속 반복됩니다.

```text
Region 증가
    ↓
Provider Block 증가
    ↓
Configuration 중복 증가
```

---

### OpenTofu 1.9의 Provider `for_each`

OpenTofu 1.9에서는 Provider 자체에 `for_each`를 사용할 수 있게 됐습니다.

```hcl
variable "regions" {
  type = set(string)
}

provider "aws" {
  alias    = "by_region"
  for_each = var.regions

  region = each.value
}
```

예를 들어 다음 Region 목록을 전달하면,

```hcl
regions = [
  "ap-northeast-2",
  "us-east-1",
  "eu-west-1"
]
```

하나의 Provider Configuration에서 여러 Provider Instance를 생성할 수 있습니다.

```text
provider "aws"
      ↓
   for_each
      ↓
┌───────────────┬────────────┬───────────┐
ap-northeast-2  us-east-1    eu-west-1
```

반복되는 Infrastructure Configuration을 훨씬 간결하게 표현할 수 있게 된 것입니다.

---

### Module과 결합

실제 Infrastructure에서는 Provider만 생성하는 것으로 끝나지 않습니다.

각 Region에 동일한 Infrastructure Module을 배포할 수 있습니다.

```text
Regions
   ↓
Provider for_each
   ↓
Module for_each
   ↓
Multi-Region Infrastructure
```

개념적으로 다음과 같은 구조입니다.

```hcl
module "deploy" {
  source = "./deploy"

  providers = {
    aws = aws.by_region[each.key]
  }

  for_each = var.regions
}
```

하나의 Module을 여러 Region에 반복해서 적용할 수 있습니다.

```text
./deploy

├─ VPC
├─ Subnet
├─ ECS
├─ Load Balancer
└─ Database
```

이를 여러 Region에 배포한다면,

```text
                deploy module
                     ↓
       ┌─────────────┼─────────────┐
       ↓             ↓             ↓
    Seoul        Virginia       Ireland
```

같은 Infrastructure Pattern을 만들 수 있습니다.

---

### 왜 중요한가

IaC의 가장 큰 장점 중 하나는 **반복되는 Infrastructure를 추상화할 수 있다는 점**입니다.

```text
Infrastructure Pattern
        ↓
      Module
        ↓
재사용
```

하지만 Provider Configuration 자체가 반복되면 Infrastructure 규모가 커질수록 Root Module의 코드가 복잡해질 수 있습니다.

```text
Module

재사용 가능


Provider

Region마다 반복
```

OpenTofu 1.9에서는 Provider도 반복 가능한 Resource처럼 다룰 수 있게 되면서 Multi-Region Architecture를 더 선언적으로 표현할 수 있게 됐습니다.

---

### Multi-Region에서 특히 유용하다

Global Service에서는 여러 Region에 동일하거나 비슷한 Infrastructure를 배포하는 경우가 있습니다.

```text
Global Service

             Global DNS
                 ↓
      ┌──────────┼──────────┐
      ↓          ↓          ↓
    Korea        US       Europe

    VPC         VPC         VPC
    App         App         App
    DB          DB          DB
```

Region이 두세 개라면 직접 Provider를 정의해도 큰 문제가 아닐 수 있습니다.

하지만 Region이 계속 늘어나면 상황이 달라집니다.

```text
3 Regions
→ 관리 가능


10 Regions
→ Provider 설정 증가


20 Regions
→ 중복 Configuration 증가
```

Provider Iteration은 이런 Infrastructure를 Data-driven 방식으로 관리할 수 있게 합니다.

```text
Region List
    ↓
Provider 생성
    ↓
Infrastructure 생성
```

---

### Kubernetes Multi-Cluster에서도 활용 가능

비슷한 문제는 Kubernetes Multi-Cluster 환경에서도 발생합니다.

```text
Kubernetes

├─ Cluster A
├─ Cluster B
├─ Cluster C
└─ Cluster D
```

각 Cluster를 Provider Configuration으로 관리하는 경우 반복 설정이 발생할 수 있습니다.

```text
Cluster
  ↓
Provider Configuration
```

Provider Iteration을 활용할 수 있는 구조에서는 Cluster 목록을 기준으로 Configuration을 구성하는 방식이 가능해집니다.

```text
Cluster List
     ↓
Provider Iteration
     ↓
각 Cluster
     ↓
Infrastructure / Resource
```

Multi-Region뿐 아니라 **동일한 Provider를 여러 Configuration으로 사용하는 Infrastructure**에서 의미가 있는 기능입니다.

---

### IaC에서는 중복 코드도 위험하다

Infrastructure Code에서 중복은 단순한 가독성 문제만은 아닙니다.

예를 들어 Region별 설정이 각각 존재한다고 가정해보겠습니다.

```text
Seoul Provider
Virginia Provider
Ireland Provider
```

새로운 Configuration을 추가하면서 한 Region만 수정하지 못할 수도 있습니다.

```text
Seoul
→ Updated

Virginia
→ Updated

Ireland
→ Missing
```

Infrastructure Configuration Drift가 발생할 가능성이 커집니다.

반복 구조를 하나의 선언으로 관리하면 이런 문제를 줄일 수 있습니다.

```text
Single Definition
      ↓
Iteration
      ↓
Consistent Configuration
```

---

### OpenTofu가 독자 기능을 추가하기 시작했다는 의미

OpenTofu가 처음 등장했을 때 가장 중요한 질문 중 하나는 기존 Terraform Configuration과 얼마나 호환되는가였습니다.

하지만 프로젝트가 발전하면서 단순 Compatibility를 유지하는 것뿐 아니라 **독자적인 IaC 기능을 추가하는 단계**로 이동하기 시작했습니다.

Provider `for_each`는 대표적인 사례입니다.

```text
초기 OpenTofu

Terraform Compatibility
        ↓
Migration 가능성 확보


이후 OpenTofu

Compatibility
      +
New Features
      ↓
독자적인 IaC Platform
```

Terraform의 대체 구현에 머무르지 않고 자체 Roadmap을 가진 Infrastructure Tool로 발전하는 흐름입니다.

---

### `-exclude` 옵션

OpenTofu 1.9에는 `-exclude` 옵션도 추가됐습니다.

기존에는 `-target`을 이용해 특정 Resource만 대상으로 Plan이나 Apply를 수행할 수 있었습니다.

```bash
tofu apply -target=aws_instance.api
```

`-exclude`는 반대로 특정 Resource를 제외하고 실행하는 방식입니다.

```bash
tofu apply -exclude=aws_instance.legacy
```

개념적으로는 다음과 같습니다.

```text
Infrastructure

Resource A
Resource B
Resource C
Resource D

      ↓

-exclude Resource C

      ↓

A
B
D
```

Infrastructure Operation의 대상 범위를 좀 더 유연하게 제어할 수 있게 된 것입니다.

---

### 그렇다고 부분 Apply를 일상적으로 써야 하는 것은 아니다

`-target`이나 `-exclude` 같은 기능은 유용하지만 전체 Infrastructure State를 기준으로 관리하는 Declarative IaC의 기본 원칙과는 다른 특수한 Operation입니다.

```text
일반적인 IaC

전체 Configuration
       ↓
Desired State
       ↓
Plan
       ↓
Apply
```

따라서 특정 장애 대응이나 Migration 같은 상황에서는 유용할 수 있지만 일반적인 배포 Workflow에서는 전체 Dependency 관계를 확인하는 것이 중요합니다.

---

### Provider Iteration에도 제약은 있다

OpenTofu 1.9의 Provider `for_each`가 모든 경우에 자유롭게 사용할 수 있는 것은 아니었습니다.

당시에는 몇 가지 제약이 존재했습니다.

대표적으로 Provider Iteration에 사용하는 값은 **정적으로 결정할 수 있어야 했습니다.**

```text
가능

Variable
Local


제한

Resource 결과
Data Source 결과
```

또한 `for_each`를 사용하는 Provider에는 Alias가 필요했습니다.

```hcl
provider "aws" {
  alias    = "by_region"
  for_each = var.regions
}
```

즉 새로운 기능이 강력하기는 하지만 기존 Infrastructure를 Migration할 때는 동작 방식과 제한 사항을 이해해야 했습니다.

---

### IaC Tool을 선택하는 기준도 달라진다

Infrastructure Tool을 선택할 때 단순히 Syntax만 비교하는 것은 부족합니다.

실제 운영에서는 다음 요소가 중요합니다.

```text
IaC Platform

├─ Provider Ecosystem
├─ Module Ecosystem
├─ State Management
├─ Backend
├─ CI/CD Integration
├─ IDE Support
├─ Community
├─ License
└─ Long-term Governance
```

IaC는 Infrastructure 전체를 관리하기 때문에 한번 도입하면 교체 비용도 상당할 수 있습니다.

---

### Terraform과 OpenTofu

OpenTofu가 성장하면서 Infrastructure Team에서는 다음과 같은 선택지가 생겼습니다.

```text
Infrastructure as Code

        ┌─────────────┐
        │             │
    Terraform      OpenTofu
```

기존 Terraform 사용 조직이라면 다음을 검토할 수 있습니다.

```text
현재 Configuration 호환성

Provider 지원

State 호환성

CI/CD Pipeline

Module

팀 경험

향후 Roadmap
```

단순히 Open Source라는 이유만으로 Migration하는 것보다는 실제 Infrastructure 요구사항과 운영 비용을 기준으로 판단해야 합니다.

---

### DevOps 관점에서 중요한 변화

OpenTofu 1.9에서 중요한 부분은 기능 하나가 추가됐다는 것 이상입니다.

Terraform이 사실상 중심이었던 Declarative IaC 영역에서 **실제 Production 환경에서 비교할 수 있는 또 다른 생태계가 지속적으로 성장하고 있다는 점**입니다.

```text
과거

Terraform
    ↓
대표적인 Declarative IaC


변화

Terraform
    ↕

OpenTofu
```

Tool 간 경쟁이 생기면 Provider, State Management, Language Feature, Developer Experience 같은 영역에서도 발전이 이어질 수 있습니다.

---

### Infrastructure도 Application처럼 추상화한다

Provider Iteration은 Infrastructure Code가 일반 Programming Language의 추상화 방식과 점점 비슷해지고 있음을 보여줍니다.

Application에서는 반복 코드를 Function으로 줄입니다.

```text
Repeated Code
     ↓
Function
```

Infrastructure에서는 Module과 Iteration을 사용합니다.

```text
Repeated Infrastructure
        ↓
Module
+
for_each
```

Provider까지 Iteration할 수 있게 되면서 Infrastructure Configuration 자체를 더욱 Data-driven하게 만들 수 있습니다.

```text
Configuration Data
       ↓
IaC Logic
       ↓
Infrastructure 생성
```

---

### 실무 영향

OpenTofu 1.9의 Provider Iteration은 특히 다음과 같은 환경에서 의미가 있습니다.

```text
Multi-Region AWS

Multi-Zone Infrastructure

Multiple Kubernetes Clusters

Multiple Cloud Accounts

반복 Provider Configuration
```

기존에는 Region이나 Cluster가 늘어날 때마다 Provider Configuration을 복사해야 했다면,

```text
기존

Region 추가
   ↓
Provider Block 복사
   ↓
Module Configuration 복사
```

OpenTofu 1.9에서는 다음과 같은 방향으로 구성할 수 있습니다.

```text
Region 추가
   ↓
Region List 수정
   ↓
Provider Iteration
   ↓
Infrastructure 생성
```

Infrastructure Code의 반복과 관리 부담을 줄일 수 있는 것입니다.

동시에 OpenTofu 자체도 단순한 Terraform 호환 프로젝트를 넘어 **자체적인 기능을 추가하며 독립적인 IaC Platform으로 발전하는 모습**을 보여주기 시작했습니다.

결국 OpenTofu 1.9은,

> **Terraform 중심이었던 IaC 생태계에서 OpenTofu가 실제 Infrastructure 운영을 위한 대안으로 성장하고 있음을 보여주는 Release**

라고 볼 수 있습니다.

Infrastructure Team 입장에서도 이제 IaC Tool을 선택할 때 단순히 기존 표준을 따르는 것이 아니라 **기능, 호환성, 라이선스, 생태계와 장기적인 Governance까지 함께 비교해야 하는 환경**으로 변화하고 있습니다.

2025년 1월 10일(금) 주간 개발트렌드

독자의 메모