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 ..

Ingress-NGINX를 4년 넘게 써왔다. 그동안 별문제 없이 잘 굴러갔는데, 올해 초부터 팀 내부에서 Gateway API로 넘어가야 하는 것 아니냐는 이야기가 계속 나왔다. 근거는 나쁘지 않았다. Gateway API v1.5가 2026년 2월에 나오면서 상당수 기능이 Stable로 승격됐고, 6월에 v1.6까지 이어졌다. Ingress에 없던 표준 트래픽 분할, 리트라이 버짓, BackendTLSPolicy 같은 것들이 실제로 필요했다.두 달 넘게 검토했고, 결론은 "전면 이관은 아니고, 신규 서비스부터 단계적으로"였다. 그 결정에 이르기까지 뭘 봤는지 정리해둔다.뭐가 다른가가장 큰 차이는 리소스 모델이다. Ingress는 하나의 오브젝트가 라우팅과 컨트롤러 설정을 다 짊어진다. 그래서 어노테이..

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

ndots:5, 왜 우리 Pod은 DNS 하나 찍는 데 다섯 번을 물어보는가DNS 지연 얘기를 하면 다들 NodeLocal DNSCache부터 붙이라고 한다. 맞는 얘기다. 근데 그 앞에 왜 이런 일이 벌어지는지 원리를 짚고 넘어가는 사람은 의외로 적더라. 우리 팀도 몇 달 전 P99가 튀는 걸 잡으렬고 노드로컬 캐시부터 붙였는데, 그때는 됐지만 나중에 다른 클러스터에 적용할 때 왜 되는지 설명을 못 해서 좀 창피했다.그래서 이 글은 ndots가 뭐고, 왜 하필 5이며, 그 값 하나가 어떻게 매 요청마다 5~6번의 DNS lookup을 유발하는지 밑바닥부터 파본다. 최근 Medium 등에서 "ndots:5 latency tax"라는 표현이 다시 돌기 시작한 것도 이유가 있다.resolv.conf가 실제로..

작년 이맘때만 해도 사내에서 "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..

Terraform 1.11에서 S3 backend에 use_lockfile = true 옵션이 GA로 들어온 뒤로, 팀에서도 슬슬 DynamoDB lock table을 걷어내자는 얘기가 나왔다. 이유는 단순했다. DynamoDB 테이블 하나 유지하려고 IAM 정책 관리, provisioned capacity 알람, TTL 스크립트까지 붙어 있는 게 웃긴 상황이었다. state 파일 하나 지키자고 별도 서비스를 하나 더 굴리는 셈이니까.그런데 "S3 하나로 lock까지 다 처리한다"는 말이 처음엔 어색했다. S3는 오래도록 eventual consistency로 유명했던 스토리지고, DynamoDB의 conditional write처럼 원자적인 락을 걸 수 있는 프리미티브가 없다고 알고 있었기 때문이다. ..

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

애플리케이션에 DB 비밀번호를 어떻게 넣어놓고 계셨나요. 우리 팀은 예전에 Kubernetes Secret에 base64로 넣어놓고, 분기마다 수동으로 로테이션했다. 근데 이게 몇 년 이어지다 보니 문제가 쌓였다. 누가 언제 그 시크릿을 봤는지 감사 로그가 없고, 로테이션 날에는 여러 서비스가 동시에 재기동되면서 P99 레이턴시가 튀었다. 결국 Vault Dynamic Secrets로 넘어갔는데, 처음 설정할 때 헤맨 부분이 좀 있어서 정리해둔다.이 글은 PostgreSQL 기준이지만 MySQL이나 MongoDB도 큰 틀은 같다. 최근 Vault 1.19에서 rotation_schedule 필드로 크론 스타일 스케줄이 정식 지원되면서 static role 운용이 훨씬 편해졌다.Dynamic Secrets..

BuildKit을 쓰기 시작한 지 꽤 됐다. DOCKER_BUILDKIT=1 넣는 건 이제 반사적으로 나온다. 그런데 얼마 전 팀 내부에서 "왜 RUN apt-get install이 캐시된 건 알겠는데, --mount=type=cache를 걸었을 때 도대체 뭐가 저장되고 뭐가 재사용되는 거냐"는 질문을 받고 답을 얼버무렸다. 그날 저녁에 소스와 문서를 뒤져가며 정리한 내용을 여기 남긴다.이 글은 실행 가이드는 아니다. BuildKit이 캐시를 어떻게 표현하고, 어디에 저장하고, 어떤 기준으로 재사용을 판단하는지 흐름을 따라간다. docker buildx build --cache-to=type=registry 를 쳤을 때 그 뒤에서 일어나는 일이 궁금한 사람이 대상이다.LLB — 캐시의 진짜 단위먼저 알아..