도구 비교 글은 많지만, 실제 현장에서는 “기능”보다 우리 조직의 승인/감사/보안정책 변화를 얼마나 잘 흡수하느냐가 비용을 결정합니다. 이 글에서는 Terraform과 OpenTofu를 단순 스펙이 아니라 거버넌스(라이선스) + IaC 운영(의존성·라이프사이클·상태) + 승인 프로세스 적합성 관점에서 정리해봅니다.
1) Terraform vs OpenTofu, 핵심 차이는 “기술”보다 “거버넌스”에서 시작합니다
Terraform: 성숙한 표준과 엔터프라이즈 채택
Terraform은 IaC 생태계에서 사실상 업계 표준에 가깝습니다. 광범위한 provider 지원, 모듈 생태계, 조직 내 레퍼런스(운영 경험자, 레거시 코드)가 이미 쌓여 있는 경우가 많아 도입/확장 비용이 낮아지는 강점이 있습니다.
OpenTofu: 라이선스 변화 이후 등장한 “완전 오픈소스” 포크
OpenTofu는 HashiCorp 라이선스 변경 이후 등장한 포크로, 커뮤니티 거버넌스와 Terraform 호환성을 핵심 가치로 내세웁니다. 즉 “기술적으로는 비슷하게 보이는데, 장기적으로 누가 룰을 정하고 어디로 갈 것인가”가 선택의 출발점이 됩니다.
현실적인 결론: “둘 중 하나”가 아니라 “병행 평가”가 자연스럽습니다
많은 Terraform 코드는 OpenTofu에서도 큰 수정 없이 동작합니다. 그래서 조직 입장에서는 단일 선택보다, 컴플라이언스/전사 전략/거버넌스 요구에 따라 병행 테스트 후 표준화로 가는 그림이 흔합니다.
2) 의사결정 기준은 “호환성”만이 아니라 “운영 호환성”입니다
대화에서 처음 나온 기준은 호환성, 범용성, 우리 환경 적합성이었습니다. 여기에 저는 한 가지를 더 얹고 싶습니다. IaC 도구에서 진짜 비용은 “코드가 돌아가느냐”보다 다음에서 터집니다.
- state 마이그레이션 위험(특히 조직/프로젝트가 커질수록 치명적)
- provider / module 버전 정책(핀ning 전략, 업그레이드 윈도우, 호환성 깨짐)
- 팀 운영 방식과의 결합도(workspace 전략, 권한 모델, CI/CD 파이프라인)
- 승인 프로세스와 감사 요구(누가 무엇을 근거로 승인하는지)
즉, Terraform vs OpenTofu 비교는 “언어/CLI가 비슷한지”가 아니라, 우리 조직의 운영 조건을 얼마나 안정적으로 만족시키는지로 봐야 합니다.
3) 우리 조직에서 가장 중요한 기준: “승인 프로세스가 어디에 고정되나”
대화에서 우선순위는 명확했습니다. 승인 프로세스가 가장 중요하고, 일반적으로 팀장이 내용을 확인하고 승인합니다. 이 구조에서 흔히 생기는 문제는 두 가지입니다.
- 승인 근거가 사람의 맥락/시간에 의존합니다.
- 팀장에게 승인 권한이 몰리면 병목이 됩니다.
그래서 도구 선택에서 정말 중요한 질문은 이것입니다.
- 승인은 PR diff를 보고 하는가, plan 결과를 보고 하는가?
- 정책 위반은 사람의 체크리스트로 잡는가, policy-as-code로 자동 차단하는가?
- apply 권한은 개발자에게 있는가, 운영/플랫폼팀으로 분리되는가?
Terraform/OpenTofu 자체의 차이도 있지만, 실제로는 “도구”보다 **승인 파이프라인(통합 방식)**이 의사결정의 무게중심이 됩니다.
4) IaC 안정성의 본체: depends_on, lifecycle, 그리고 state 운영
거버넌스 이슈가 아무리 커도, 운영에서 사고를 막는 건 결국 “IaC 기본기”입니다. 특히 승인 프로세스가 강한 조직일수록 plan/apply 단계에서 다음 항목이 중요해집니다.
4.1 의존성 관리: 암묵적 vs 명시적(depends_on)
Terraform/OpenTofu는 기본적으로 리소스 참조로 의존성을 추론하지만, 운영에서는 “실제로는 연결돼 있는데 코드상 참조가 없는” 케이스가 자주 발생합니다. 이럴 때 명시적으로 고정하는 게 depends_on입니다.
resource "aws_iam_role_policy_attachment" "attach" {
role = aws_iam_role.app.name
policy_arn = aws_iam_policy.app.arn
depends_on = [aws_iam_role.app]
}
- 승인자가 plan을 볼 때 “왜 이 순서로 바뀌는지”를 이해하기 쉬워집니다.
- 배포 실패 후 재시도(retry) 시에도 예측 가능성이 올라갑니다.
4.2 lifecycle 규칙: 안전장치(그리고 승인 품질의 레버)
승인 프로세스가 중요한 조직에서는 lifecycle이 곧 “운영 안전장치”입니다.
resource "aws_security_group" "app" {
name = "app-sg"
lifecycle {
prevent_destroy = true
}
}
prevent_destroy: 실수로 destroy가 뜨는 순간을 구조적으로 차단합니다.create_before_destroy: 교체(replace) 리소스가 뜰 때 다운타임을 줄이는 전략입니다.ignore_changes: 외부에서 바뀌는(또는 바뀌어도 허용할) 속성을 승인 대상에서 제외할 때 씁니다.
이 규칙들은 단순한 “기능”이 아니라, 승인의 기준을 코드로 고정하는 방법이기도 합니다. 팀장 승인 구조에서는 특히 효과가 큽니다. 승인자가 모든 맥락을 기억하지 않아도, 위험한 변경을 시스템이 막아주기 때문입니다.
4.3 state / workspace: 도구 선택보다 더 큰 “조직 확장성” 변수
확장성은 멀티클라우드만 의미하지 않습니다. 저는 “리소스/팀/계정이 늘어도 운영이 되는가”가 더 본질이라고 봅니다. 그때 병목은 state 운영에서 터집니다.
- state 접근 권한이 섞여 있으면 승인/감사가 불가능해집니다.
- workspace 전략이 없거나 난립하면, “어디가 프로덕션인지”부터 혼란스러워집니다.
결국 Terraform/OpenTofu 중 무엇을 쓰든, state 분리 전략과 접근 통제가 승인 프로세스의 토대가 됩니다.
5) “보안정책이 자주 바뀌는 조직”에서의 선택 포인트
대화에서 나온 또 하나의 핵심은 이것이었습니다.
- 상위/하위 레이어의 기술 스택 변화에 빠르게 대응
- 특히 보안정책이 자주 바뀌므로 유연하게 작동
이런 조직에서는 도구 비교가 다음 질문으로 이어져야 합니다.
- 보안정책 변경을 모듈 내부에 흡수할 것인가, **별도 정책 레이어(CI 게이트, policy-as-code)**로 뺄 것인가?
- 정책 변경이 잦을수록 “변경의 영향 범위를 작게” 만들기 위해
모듈 경계, 버전 핀ning, 롤아웃 전략이 더 중요해집니다. - 유연성을 위해 동적 구성(조건/for_each)을 과하게 쓰면 plan 가독성이 떨어져
승인 품질이 하락할 수 있습니다. (유연성 ↔ 승인 가능성의 트레이드오프)
즉 “보안정책 변화에 빠르게 대응”하려면, Terraform/OpenTofu 자체 비교보다 운영 설계가 먼저입니다. 도구는 그 설계를 잘 받쳐주는 쪽을 고르면 됩니다.
마무리
Terraform vs OpenTofu 선택은 “스펙 비교”보다 거버넌스(라이선스/커뮤니티) + 운영 호환성(state·의존성·lifecycle) + 승인 프로세스 적합성으로 결정하는 게 현실적입니다. 특히 팀장 승인처럼 사람이 최종 책임을 지는 구조라면, 승인 부담을 줄이고 사고를 막기 위해 lifecycle/state/정책 자동화를 어떤 방식으로 설계할지부터 정리해보는 걸 추천합니다.
