day-log

라이선스 이슈로 시끄러웠던 게 벌써 2년 전이다. 그때는 "일단 지켜보자"로 넘어간 팀이 많았는데, 요즘 다시 이 얘기가 올라온다. 나도 최근에 팀 내부에서 마이그레이션 검토를 했고, 결과적으로는 OpenTofu 쪽으로 기울었다. 이유를 정리해본다.지금 어디까지 왔나Terraform은 1.15 라인이 stable, 1.16이 alpha다. OpenTofu는 1.12.2가 stable. 버전 넘버만 보면 Terraform이 앞서가는 것 같지만 실제 CLI 오픈소스 기능은 그 반대다.HashiCorp가 BSL로 넘어간 뒤 IBM에 인수됐고, 오픈소스 CLI에는 신규 기능이 거의 안 들어간다. 대신 HCP Terraform(관리형)과 AI 어시스트 쪽으로 투자가 몰려 있다. 반면 OpenTofu는 Linux ..

작년 이맘때만 해도 이 얘기를 꺼내면 팀 슬랙 채널이 뜨거워졌다. HashiCorp가 BSL로 라이선스를 바꾼 뒤 OpenTofu 포크가 나왔고, 마침 우리 팀은 Pulumi로 옮겨야 하나 하는 논의도 있었다. 1년 반 정도가 흘렀고, 세 도구 모두 조금씩 다른 방향으로 자라났다. OpenTofu는 최근 1.9까지 오면서 state 암호화 같은 걸 Terraform보다 먼저 넣었고, Terraform은 HCP 통합을 계속 강화하고 있고, Pulumi는 여전히 "진짜 프로그래밍 언어로 IaC"라는 자리를 지키고 있다.우리 팀은 6개월 동안 세 개를 실제 프로젝트에 나눠 쓰면서 비교해봤다. 결론부터 말하면 하나로 통일하지 못했다. 상황마다 다르더라. 이 글은 그 과정에서 느낀 것들이다.라이선스와 거버넌스, ..

지난 3주 동안 팀 인프라 코드를 Terraform 1.5.7에서 OpenTofu 1.10으로 넘겼다. "5분이면 된다"는 블로그 글들에 낚였다. 실제로는 5분이 아니라 3주였고, 그 중 절반은 예상 못 한 곳에서 시간이 갔다.기록해둔다. 언젠가 같은 삽을 뜨는 사람이 이 글을 보길.왜 굳이 지금 옮겼나솔직히 얼마 전까지는 옮길 이유가 별로 없다고 봤다. HCL 문법도 거의 같고 프로바이더도 호환되고, 우리 팀 규모(모듈 40개, workspace 12개)에서 라이선스 이슈가 당장 발등의 불도 아니었다.바뀐 계기는 두 가지였다.첫째, state encryption. OpenTofu 1.10에는 native state encryption이 들어있는데 Terraform은 아직 없다. 우리는 지금까지 S3 b..

새벽 2시에 알림이 울렸다. 배포 파이프라인이 Error acquiring the state lock을 뱉고 멈춰 있었다. 락 ID를 들고 DynamoDB 콘솔에 들어가 강제로 항목을 지우고, 파이프라인을 재실행. 익숙한 절차였다. 근데 그날따라 이 절차가 어이없게 느껴졌다.우리 팀은 Terraform 1.11 무렵부터 S3 backend + DynamoDB 락을 써 왔다. 몇 년 잘 돌던 조합이다. 그런데 올봄에 팀 내부 논의 끝에 DynamoDB 락 테이블을 정리하기로 했다. 이유는 두 가지였다. 하나는 Terraform과 OpenTofu 양쪽 다 S3 네이티브 락을 밀고 있고 DynamoDB 방식이 사실상 deprecated가 됐다는 것. 다른 하나는 우리 조직에 IaC state가 40개 넘게 흩..

작년 이맘때만 해도 사내에서 "OpenTofu 쓸까요?" 얘기가 나오면 반응은 두 종류였다. "일찍 넘어가는 건 위험하다" 아니면 "어차피 언젠간 넘어갈 텐데". 그 사이에서 결정을 못 하고 시간이 흘렀다.포크된 지 만 3년, BSL 전환 이슈가 터진 지도 그만큼 지났다. 이제는 어느 쪽이든 "지켜본다"라는 답이 힘을 잃었다. Fidelity가 상태 파일 5만 개, 리소스 400만 개를 OpenTofu로 옮겼다는 발표가 올해 초에 나왔고, 우리 팀 슬랙에도 그 링크가 다시 돌았다. 결국 지난달 두 주짜리 스파이크를 잡고 실제로 병행 운영을 해봤다. 그 기록을 정리한다.두 도구가 실제로 얼마나 벌어졌나핵심 CLI 동작만 놓고 보면 plan, apply, import, state mv 같은 워크플로우는 99..

Terraform을 몇 년 굴려본 팀이면 한 번쯤은 겪는 상황이 있다. state 파일 하나에 리소스가 500개, 800개 넘게 쌓이면 plan 한 번 돌리는 데 몇 분씩 걸리고, 누구 하나가 apply 걸어놓으면 다른 사람은 하염없이 기다려야 한다. 그러다 어느 날 실수로 리소스 하나 잘못 지우면 blast radius가 너무 커서 롤백도 쉽지 않다.우리 팀도 초기에는 그냥 terraform/ 폴더 하나에 다 몰아넣고 시작했다. 편하긴 한데, 팀 규모가 커지고 환경이 dev/stage/prod로 늘어나면서 이 구조가 점점 부담스러워졌다. 이 글은 state 파일을 어떻게 쪼개고, 원격 백엔드는 어떻게 설정하고, drift는 어떻게 감지하는지 실무 관점에서 정리한 가이드다.최근에 OpenTofu 1.10..

작년까지만 해도 "OpenTofu는 아직 지켜봐야지" 하는 분위기가 있었다. 그런데 올해 들어 상황이 좀 달라졌다. 우리 팀에서 최근 IaC 도구 재검토를 하면서 정리했던 내용을 공유하려고 한다. 결론부터 말하면 케이스 바이 케이스인데, 그 "케이스"를 어떻게 나눠서 봐야 하는지가 핵심이었다.시장 점유율만 놓고 보면 Terraform이 여전히 우세하다. 2026년 4월 기준으로 OpenTofu 채택률이 12% 정도, Terraform은 여전히 30%대 후반이다. 근데 이 숫자만 보면 안 되는 게, 신규 프로젝트에서 OpenTofu를 선택하는 비율이 훨씬 높다. 기존 Terraform 자산이 없는 팀 기준으로만 보면 이야기가 완전히 달라진다.라이선스 문제, 실제로 회사에 영향을 주나이게 우리 팀에서 가장 ..

OpenTofu 1.7에서 state 암호화 기본 기능이 들어온 지도 꽤 됐다. 근데 막상 켜본 분들 중에 method 블록만 설정하고 fallback은 그냥 비워두는 경우가 많더라. 우리 팀도 처음에 그랬다. 결론부터 말하면, fallback 빼면 마이그레이션 순간에 무조건 한 번은 깨진다.무슨 상황에서 깨지나평문 state 파일이 있는 워크스페이스에 처음 암호화를 켤 때가 문제다. OpenTofu는 terraform.encryption 블록에서 지정한 method로 state를 읽으려고 시도하는데, 기존 파일은 평문이라 못 푼다. Error: Failed to decrypt state 한 줄 던지고 끝.키 로테이션도 마찬가지다. PBKDF2 패스프레이즈를 바꿨다? 새 키로 옛날 state는 못 연다...