day-log

작년까지만 해도 "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는 못 연다...

Terraform 1.10에서 use_lockfile = true 옵션이 추가됐고, 1.11에 와서는 experimental 딱지가 떨어졌다. DynamoDB 테이블 없이 S3만으로 state lock을 거는 기능이다.처음 봤을 때 솔직히 좀 의심스러웠다. lock 메커니즘이라는 게 결국 "동시에 한 명만 쓰게" 만드는 건데, S3는 object storage고 트랜잭션 같은 게 없는데 어떻게? 그리고 DynamoDB는 강한 일관성(strong consistency)을 보장하는 KV store니까 lock 용도로 충분히 합리적이었다. 굳이 S3로 갈아탈 이유가 있나 싶었다.근데 마이그레이션을 준비하면서 내부를 까보니, 생각보다 깔끔하게 잘 만들어둔 구조였다. 단순히 "DynamoDB를 안 써도 된다"는 ..

Terraform 쓰면서 가장 찜찜한 게 뭐였냐고 물으면, 솔직히 나는 terraform.tfstate에 시크릿이 평문으로 박히는 거였다. RDS 마스터 패스워드, API 토큰, OAuth 클라이언트 시크릿. data 블록으로 Secrets Manager에서 가져온 값조차 state에 그대로 기록된다.그동안은 state 백엔드(S3 + KMS)에 의존하거나, write-only 패턴을 억지로 끼워넣거나, 아예 Terraform 밖에서 처리하는 식으로 우회했다. 그런데 작년 말 1.10에서 나온 ephemeral resources가 1년 좀 넘게 실무에서 굴려보니 꽤 쓸 만하다. 최근 6월 기준 AWS, Azure, Vault, Kubernetes, random, 그리고 GCP 프로바이더까지 지원이 거의 ..

Composition Function을 쓰기 시작하면 한 번쯤은 이런 상황을 겪는다. XR을 만들었는데 리소스가 안 만들어지고, kubectl describe를 봐도 "function pipeline failed"만 나오고, 정확히 어느 단계의 어느 함수가 뭘 받아서 뭘 뱉었는지는 깜깜하다. 사실상 추측 디버깅이었다.v2.2에서 alpha로 들어왔던 Pipeline Inspector가 v2.3에서 beta로 승격됐다. OpenTelemetry 통합도 같이 들어와서 이제는 함수 파이프라인을 진짜로 들여다볼 수 있게 됐다. 우리 팀이 지난 2주간 도입하면서 정리한 내용을 공유한다.Pipeline Inspector가 정확히 뭘 보여주나이름이 좀 추상적인데, 실제로는 gRPC interceptor다. Cross..

이거 모르는 분 꽤 많더라. 우리 팀 모듈 plan에 8분 넘게 걸리던 게 4분으로 줄었다. 코드 한 줄도 안 고쳤다.뭐가 문제였냐면terraform plan 돌리면 기본적으로 state에 있는 모든 리소스를 클라우드 API에 한 번씩 조회한다(refresh). 리소스 200개짜리 모듈이면 200번 API 콜이 도는데, AWS provider 같이 throttling 걸리면 더 느려진다.CI에서 PR마다 plan을 돌리는 입장에서는, 매번 fresh한 state가 필요한 것도 아닌데 이 refresh 때문에 시간을 다 까먹는다. 특히 우리는 monorepo에 모듈 30개 있어서 PR 하나 올리면 plan job 30개가 동시에 돌고, 그러면 AWS API throttling까지 같이 터진다.그래서 이렇게..

작년 이맘때 Terraform 협업 도구를 새로 고르느라 한참 헤맸다. 그동안은 GitHub Actions 위에 얇은 래퍼 스크립트로 plan/apply를 돌렸는데, 모듈이 80개를 넘어가면서부터는 한계가 보였다. PR 코멘트에 plan 결과가 뒤죽박죽 붙고, 누가 언제 apply를 눌렀는지 추적이 안 되고, 가끔 두 사람이 같은 워크스페이스에 동시에 apply를 날려서 state lock 충돌이 나기도 했다.결국 후보를 Atlantis와 Spacelift로 좁혔다. 둘 다 후보로 올린 이유는 단순했다. Atlantis는 공짜고 자체 운영이 익숙했고, Spacelift는 영업 미팅 한 번 했을 때 "이 정도면 우리 페인 포인트는 다 풀리겠다" 싶은 인상을 받았기 때문이다. 1년이 지난 지금 시점에서 솔직..

Terraform ephemeral과 write-only, 1년 굴리고 정리한 진짜 사용 패턴작년 이맘때쯤 Terraform 1.10이 나왔고, 그때부터 ephemeral 블록과 write-only 인자를 본격적으로 우리 코드베이스에 섞기 시작했다. 1.11에서 managed resource에도 write-only argument가 들어오면서 본격적으로 "state에서 시크릿을 빼는" 작업을 했고, 지금은 1.15.3까지 와있다. 1년이 지난 지금 다시 보면, 처음에 우리가 잘못 이해하고 있던 것들이 꽤 있었다. 단순히 "state에 안 남는 변수"가 아니라, 라이프사이클 자체가 다른 객체라는 것을 운영하면서야 체감했다.이 글은 "ephemeral이 뭔지 알려주는" 글이 아니다. 그건 hashicorp ..