왜 당신의 테라폼 코드는 팀을 위험에 빠뜨리는가?
안녕하세요, 15년 차 서버 개발자이자 클라우드 인프라 아키텍트입니다. 오늘은 개발팀의 심장을 덜컥 내려앉게 만드는 '인프라 사고'에 대해 이야기해 보려 합니다. 여러분은 혹시 금요일 오후, 배포 버튼을 눌렀다가 프로덕션 DB가 사라지거나 네트워크가 단절되는 악몽 같은 경험을 해보신 적이 있나요? 솔직히 고백하자면, 저는 주니어 시절 테라폼(Terraform) 상태 파일(State File) 관리 소홀로 실제 운영 중인 서비스의 데이터베이스를 초기화할 뻔한 아찔한 경험이 있습니다. 그때 등줄기에 흐르던 식은땀의 온도와 팀장님의 싸늘한 눈빛을 저는 10년이 지난 지금도 생생하게 기억합니다. 😅
테라폼을 처음 배우면 대부분 로컬 컴퓨터에서 terraform apply를 실행하며 희열을 느낍니다. 혼자 공부할 때는 아무런 문제가 없죠. 내 컴퓨터에 생성된 terraform.tfstate 파일이 나의 인프라 지도가 되어주니까요. 하지만 팀 프로젝트에 투입되는 순간, 이 로컬 방식은 시한폭탄이 됩니다. 옆 자리 동료가 네트워크 설정을 변경하고 퇴근했는데, 내가 그 사실을 모르고 구버전 상태 파일로 배포를 한다면 어떻게 될까요? 서로 다른 상태 파일을 가진 두 사람이 동시에 인프라를 건드린다면? 상상만 해도 끔찍한 'Race Condition(경쟁 상태)'과 리소스 충돌이 발생합니다.
실제로 제가 컨설팅했던 A 핀테크 스타트업의 경우, 5명의 개발자가 각자의 로컬 상태 파일로 AWS를 관리하다가 리소스 ID가 꼬이는 대형 사고가 발생했습니다. 서로 다른 상태 파일이 동일한 리소스를 덮어쓰기 하면서 인프라 정합성이 깨져버린 것이죠. 결국 이를 복구하는 데만 시니어 엔지니어 3명이 투입되어 꼬박 3일이 걸렸습니다. 비용으로 환산하면 수천만 원의 인건비가 허공으로 날아간 셈이고, 서비스 신뢰도 하락은 돈으로 환산할 수도 없었습니다. 이처럼 '협업' 환경에서 테라폼의 상태 관리는 단순한 권장 사항이 아니라 생존을 위한 필수 조건입니다.
많은 분들이 "그냥 깃(Git)에 상태 파일을 올려서 공유하면 되지 않나요?"라고 묻습니다. 하지만 이는 보안상 최악의 선택이자 아마추어적인 발상입니다. 상태 파일에는 RDS의 마스터 비밀번호, IAM 액세스 키, 프라이빗 IP 주소 같은 민감 정보가 평문(Plain Text)으로 저장될 수 있기 때문입니다. 게다가 깃은 동시에 파일을 수정하는 것을 막아주는 '실시간 잠금(Locking)' 기능이 없습니다. 우리는 더 똑똑하고, 더 안전하며, 더 자동화된 방법이 필요합니다.
그래서 오늘 우리는 업계 표준(De Facto Standard)이라 불리는 AWS S3와 DynamoDB를 활용한 원격 상태 관리 및 잠금 전략을 아주 깊이 있게 파헤쳐 볼 겁니다. 단순히 설정하는 법을 넘어, 왜 이 구조가 필요한지, 내부적으로 어떤 원리로 동작하는지, 그리고 실전에서 마주칠 수 있는 함정들은 무엇인지 제가 겪은 수많은 시행착오를 바탕으로 낱낱이 알려드리겠습니다. 커피 한 잔 넉넉히 준비하시고, 천천히 따라오세요. ☕
Terraform State: 인프라의 영혼을 다루는 법
상태 파일(tfstate)의 정체와 중요성
테라폼에서 terraform.tfstate 파일은 단순한 JSON 결과물이 아닙니다. 저는 이것을 '인프라의 영혼'이라고 부릅니다. 테라폼은 실제 클라우드 환경(AWS)과 여러분이 작성한 코드(.tf 파일) 사이의 괴리를 이 상태 파일을 통해 파악합니다. 이 파일은 현재 배포된 리소스의 모든 ID, 속성, 메타데이터, 그리고 의존성 관계를 담고 있는 거대한 장부와 같습니다.
예를 들어, 여러분이 EC2 인스턴스 하나를 코드로 정의했다고 가정해 봅시다. 테라폼이 이를 AWS에 생성하면, AWS는 i-1234567890abcdef0 같은 고유 인스턴스 ID를 반환합니다. 테라폼은 이 ID를 상태 파일에 기록해 둡니다. 나중에 여러분이 인스턴스 타입을 t2.micro에서 t3.medium으로 변경하려고 할 때, 테라폼은 이 상태 파일을 보고 "아, 사용자가 새로운 서버를 만드는 게 아니라 기존 i-1234567890abcdef0 인스턴스를 수정하려고 하는구나"라고 정확히 인식하는 것이죠.
만약 이 상태 파일이 사라지거나 손상된다면 어떻게 될까요? 테라폼은 실제 리소스가 존재하는지 모르게 됩니다. 그래서 멀쩡히 살아있는 서버를 놔두고 똑같은 서버를 하나 더 만들려고 하거나(중복 생성), 기존 리소스를 관리 대상에서 제외해 버리는 '고아 리소스(Orphaned Resource)' 문제를 일으킵니다. 이는 관리되지 않는 리소스로 인한 보안 구멍은 물론, 매달 청구되는 클라우드 비용 폭탄의 주범이 되기도 합니다.
특히 팀 단위 협업에서는 '단일 진실 공급원(SSOT, Single Source of Truth)'이 반드시 필요합니다. 팀원 A가 네트워크 서브넷을 수정했다면, 팀원 B의 테라폼도 그 사실을 실시간으로 알아야 합니다. 로컬에 저장된 상태 파일로는 물리적으로 이것이 불가능합니다. 이것이 우리가 상태 파일을 내 컴퓨터가 아닌, 인증된 팀원 모두가 접근 가능한 안전한 원격 저장소(Remote Backend)에 두어야 하는 근본적인 이유입니다.
제가 경험한 바로는, 상태 파일 관리가 체계적이지 않은 프로젝트는 시간이 갈수록 '누더기 인프라'가 됩니다. 수동으로 콘솔에서 고친 내용과 코드가 달라지는 'Configuration Drift'가 발생하고, 결국 테라폼을 포기하고 다시 수동 관리로 돌아가는 안타까운 경우도 많이 봤습니다. 이를 방지하기 위해 S3 백엔드는 가장 강력하고 검증된 솔루션입니다.
왜 하필 S3와 DynamoDB인가?
AWS에는 EBS, EFS 등 수많은 저장소가 있는데 왜 하필 S3일까요? 그리고 왜 데이터베이스인 DynamoDB가 굳이 필요할까요? 이 조합은 전 세계 테라폼 커뮤니티에서 가장 널리 쓰이는 '국룰' 조합입니다. 그 이유는 크게 세 가지로 요약할 수 있습니다: 압도적인 내구성, 철저한 보안, 그리고 완벽한 잠금 기능입니다.
첫째, S3는 99.999999999% (일레븐 나인)의 내구성을 자랑합니다. 여러분의 맥북 하드 디스크보다 수억 배는 안전하죠. 또한 S3의 '버전 관리(Versioning)' 기능을 켜두면, 상태 파일이 변경될 때마다 과거 기록이 모두 남습니다. 실수로 상태 파일을 깨먹더라도 언제든지 1분 전, 1시간 전, 심지어 일주일 전 상태로 되돌릴 수 있다는 뜻입니다. 이 롤백 기능 덕분에 저도 몇 번이나 지옥에서 살아 돌아왔습니다.
둘째, DynamoDB는 State Locking(상태 잠금)을 위해 사용됩니다. S3는 파일 저장소이지 잠금 장치가 아닙니다. 누군가 terraform apply를 실행하는 순간, 테라폼은 DynamoDB 테이블에 "나(User A) 지금 작업 중이야, 아무도 건드리지 마!"라는 표식(Lock)을 0.1초 만에 남깁니다. 다른 팀원이 동시에 명령어를 실행하면, DynamoDB의 이 표식을 보고 "아, 지금 누가 작업 중이네. 대기해야겠다"라고 판단하고 에러를 띄웁니다. 이것이 바로 동시성 문제를 해결하는 핵심 열쇠입니다.
셋째, 비용 효율성입니다. S3에 저장되는 텍스트 파일 용량은 매우 작고, DynamoDB의 읽기/쓰기 횟수도 배포할 때만 발생하므로 프리 티어(Free Tier) 범위 내에서 충분히 운영 가능합니다. 기업 환경이라 해도 월 몇백 원 수준에 불과합니다. 적은 비용으로 엔터프라이즈급 안정성을 얻을 수 있는 최고의 가성비 조합인 셈이죠.
이 구조를 이해하지 못하고 단순히 "블로그에서 하라니까" 설정하는 것과, 원리를 알고 적용하는 것은 천지차이입니다. 원리를 알면 에러가 났을 때 어디를 봐야 할지 직관적으로 알 수 있습니다. S3는 '데이터의 저장', DynamoDB는 '동시성 제어'. 이 두 가지 명확한 역할 분담을 꼭 기억해주세요.
관리 방식 비교: 로컬 vs Git vs S3 백엔드
테라폼 상태 관리 방식은 프로젝트의 규모와 팀의 성숙도에 따라 달라질 수 있습니다. 하지만 협업이 전제된다면 답은 정해져 있습니다. 아래 비교표를 통해 각 방식의
댓글
댓글 쓰기