구성하고, 관리하고, 확장하는 테라폼의 정석 빠르게 변화하는 클라우드 환경에서 인프라를 안정적으로 운영하려면 선언만으로는 부족하다. 이 책은 테라폼을 실무에 제대로 적용하기 위한 실전 가이드다. 상태 관리, 실행 환경 분리, 커스텀 모듈 설계, 다양한 프로바이더 연용 등 핵심 개념을 하나씩 짚어간다. 또한, YAML과 CSV를 활용한 입력값 관리, 키클록 등 오픈소스 연동, 멀티 리전 환경 구성까지 실제 업무에 적용 가능한 예제를 담았다. 테라폼을 더 깊이 이해하고 안정적으로 운영하고 싶은 사람에게 이 책은 훌륭한 출발점이 되어줄 것이다.

저자 : 홍수민 카카오페이증권의 DevOps 플랫폼 개발자. AWS 파트너사, 오늘의집, 캐치테이블 등 다양한 IT 스타트업에서 밀도 높은 경험을 쌓으며 성장해왔다. 클라우드와 테라폼의 매력에 빠져 솔루션 아키텍트에서 DevOps 엔지니어로 전환했으며, 현재는 코드 기반으로 인프라 자원을 관리하고 새로운 기술을 우선적으로 검증하는 업무를 담당하고 있다. 최근에는 AI 기술에도 관심을 두고 다양한 프로젝트를 수행 중이며, 특히 카카오페이증권의 AI 챗봇 ‘춘시리’ 개발 경험을 기술 블로그를 통해 공유하기도 했다. 재미있고 새로운 기술에 끊임없이 도전하며, 오늘도 흥미로운 기술을 찾아 탐구 중이다. 현재 카카오톡 오픈채팅방을 통해 'Terraform 질문공부방'을 운영하고 있다. 저자 : 정윤의 유저 리서치 SaaS를 서비스하는 스타트업인 디비디랩의 CTO. 최고의 개발팀을 경험하고 싶은 열망으로 오늘도 고군분투하고 있다. AWS와 오늘의집 등 국내외 다양한 규모의 조직에서 클라우드 기반의 개발과 시스템 설계를 수행하였으며, 수년간 테라폼과 같은 코드형 인프라를 기반으로 클라우드 자원을 운영해왔다. 패스트캠퍼스에서 ‘실무 장애 대응 프로세스로 끝내는 장애율 0% 서비스 운영의 모든 것’이라는 주제로 장애 대응 관련 온라인 강의를 하고 있으며, 멘토링 플랫폼 F-Lab에서는 현업 백엔드 및 DevOps 엔지니어를 대상으로 멘토로 활동하고 있다.

추천의 글 xii 베타리더 후기 xx 시작하며 xxv 이 책에 대하여 xxviii PART I 왜 테라폼인가? CHAPTER 1 클라우드와 코드형 인프라스트럭처 3 1.1 클라우드 컴퓨팅 vs. 온프레미스 컴퓨팅 3 1.2 클라우드 네이티브 패러다임 5 1.3 클라우드 인프라의 복잡성과 관리의 어려움 6 1.4 선언형 IaC 도구의 필요성 9 CHAPTER 2 우리는 왜 테라폼을 쓰는가? 11 2.1 선언형 인프라 관리 11 2.2 다양한 프로바이더 12 2.3 선언형 스크립트 언어 14 2.4 하시코프 설정 언어에 대한 오해 16 PART II 테라폼 기본 CHAPTER 3 테라폼 작동 방식 21 3.1 테라폼 프로젝트 구조 21 3.2 테라폼 상태의 역할 22 3.3 테라폼 명령과 작동 26 3.4 테라폼 프로바이더 31 CHAPTER 4 테라폼 기본 문법 34 4.1 데이터 타입 34 4.2 반복문 35 4.3 조건문 42 4.4 for 표현식 44 4.5 테라폼 블록 49 4.6 테라폼 함수 59 CHAPTER 5 테라폼 모듈 66 5.1 모듈 사용 66 5.2 모듈 작성의 기본 구조 70 PART III 테라폼 기능별 실무 사례 CHAPTER 6 실행 환경 관리 79 6.1 실행 환경을 분리하지 않을 때의 문제점 79 6.2 실행 환경 분리 사례 81 6.3 테라폼 워크스페이스? 85 CHAPTER 7 다양한 인라인 블록 86 7.1 중첩 블록 86 7.2 다이내믹 블록 87 7.3 중첩 블록 vs. 별도 리소스 블록 90 7.4 생명주기 블록 92 CHAPTER 8 유효성 검사 95 8.1 검사 블록 95 8.2 생명주기 블록 96 8.3 체크 블록 98 CHAPTER 9 유틸리티 모듈 만들기 104 9.1 AWS의 메타데이터 가져오기 104 9.2 두 AWS 프로바이더가 동일한지 체크하기 107 9.3 리스트 내의 맵 합치기 109 PART IV AWS 모듈 사례 CHAPTER 10 모듈을 직접 만드는 이유와 만드는 방법 117 10.1 공개 모듈 vs. 직접 만든 모듈 117 10.2 모듈을 쉽게 만드는 방법 118 CHAPTER 11 YAML 파일로 관리하는 VPC 모듈 만들기 122 11.1 입력값 정하기 123 11.2 입력값을 모듈에 전달할 방법 정하기 126 11.3 모듈 만들기 130 11.4 변수 유효성 검사 149 11.5 모듈 출력값 설정 162 11.6 더 고려해볼 만한 것 163 CHAPTER 12 CSV 파일로 관리하는 보안 그룹 모듈 만들기 166 12.1 입력값 정하기 166 12.2 입력값을 모듈에 전달할 방법 정하기 168 12.3 모듈 만들기 174 12.4 변수 타입 유효성 186 12.5 모듈 출력값 설정 187 12.6 더 고려해볼 만한 것 187 CHAPTER 13 VPC와 보안 그룹 모듈의 출력값을 활용하는 EC2 모듈 만들기 189 13.1 입력값 정하기 189 13.2 입력값을 모듈에 전달할 방법 정하기 195 13.3 모듈 만들기 198 13.4 변수 유효성 검사 207 13.5 모듈 출력값 설정 217 13.6 더 고려해볼 만한 것 218 CHAPTER 14 다른 실행 환경의 출력값을 참조하는 네트워크 실행 환경 구성하기 220 14.1 미리 고려해야 할 점 220 14.2 실행 환경 재구성하기 221 14.3 요구사항 정리하기 223 14.4 원격 상태 설정하기 224 14.5 입력값과 전달 방식 정의하기 226 14.6 모듈 만들기 231 14.7 유효성 검사 236 14.8 모듈 출력값 설정 238 14.9 더 고려해볼 만한 것 238 PART V 다양한 프로바이더 활용 예제 CHAPTER 15 하시코프 공식 유틸리티 프로바이더 241 15.1 테라폼 프로바이더 티어 241 15.2 랜덤 프로바이더 242 15.3 HTTP 프로바이더 244 15.4 로컬 프로바이더 246 15.5 널 프로바이더와 terraform_data 리소스 249 15.6 그 외 252 CHAPTER 16 쿠버네티스 관련 프로바이더 256 16.1 쿠버네티스 프로바이더 256 16.2 헬름 프로바이더 270 16.3 커스텀 리소스과 Kubectl 프로바이더 284 CHAPTER 17 키클록 프로바이더로 AWS SSO 구현하기 292 17.1 테라폼 키클록 프로바이더 설정하기 294 17.2 키클록과 AWS SAML 간 연동을 위한 리소스 생성 297 17.3 키클록 그룹과 AWS IAM 역할 매핑하기 301 17.4 키클록 사용자로 AWS 로그인 테스트하기 309 17.5 더 고려해볼 만한 것 311 APPENDIX 테라폼 Q&A APPENDIX A 테라폼을 사용하면서 생기는 문제는 어떻게 트러블슈팅하나요? 315 APPENDIX B 테라폼 작업할 때 팀원들과 잘 협업하는 방법이 있나요? 320 APPENDIX C 이미 존재하는 인프라 리소스를 테라폼으로 관리하고 싶어요 325 APPENDIX D 테라폼 관련 서드파티 오픈소스 도구는 어떤 걸 쓰세요? 331 APPENDIX E 테라폼의 라이선스가 변경된다고 하는데 문제없을까요? 336 찾아보기 339

테라폼의 HCL은 배우기 어렵다는 인식이 있는 것이 사실이다. 하지만 HCL은 JSON이나 YAML과 같은 선언형 설정 언어일 뿐이며, 리소스의 필드 참조나 리소스 사이의 참조 등을 오히려 JSON이나 YAML보다 더 쉬운 방법으로 정의할 수 있게 해준다. 실제로 HCL로 작성할 수 있는 모든 스크립트는 동등한 JSON 기반 설정 문법(JSON Configuration Syntax)을 사용해 작성할 수 있다. 더 나아가면 HCL은 이론상 당연히 동등한 YAML로도 표현이 가능하다. JSON은 YAML의 부분집합이기 때문이다. / HCL은 그저 JSON과 YAML 설정 파일을 인프라 관리자의 입장에서 조금 더 수월하게 작성하기 위해 만들어진 언어이며, JSON과 동등하다. (17쪽)

모듈 안에 서브 디렉터리로서 모듈을 또 정의하여 사용할 수 있다. 이를 중첩 모듈(nested module)이라고 한다. 일반적으로 컬렉션을 순회하며 반복적으로 리소스를 생성하거나 할 때, 상당히 넓은 범위의 리소스가 매 순회 시마다 만들어져야 할 수도 있다. 이럴 때 단순히 for_each나 for 등을 많은 종류의 리소스에 동시에 사용해서 구현할 수 있는데, 쉽게 예상할 수 있듯이 오류의 소지가 크다. 이럴 때 중첩 모듈로 순회에 따르는 액션을 정의해서 루트 모듈의 가독성을 높이는 방법을 사용해볼 수 있다. 중첩 모듈은 테라폼의 공식 컨벤션상 /modules 서브 디렉터리에 두는 것이 일반적이나 합리적인 이유가 있다면 컨벤션을 따르지 않아도 올바르게 작동한다. (74쪽)

AWS 메타데이터는 실무상 다양한 환경과 프로젝트에서 수시로 사용하는 값이기 때문에 생각보다 자주 호출할 필요가 있다. 예를 들면 모듈 안에서 각 리소스에 계정 정보를 태그로 지정하는 것도 흔히 사용하는 패턴이다. 또한, 현재 참조하고 있는 계정이나 리전에 따라 다른 리소스를 만들기 위해서 분기 처리를 할 수도 있다. / 그러나 이러한 상황마다 AWS 메타데이터의 값을 매번 직접 호출하는 것은 코드 유지 보수 측면에서 효율적이지 않다. 이유를 설명하자면, 우선 AWS 메타데이터의 값에서 아이디는 aws_caller_identity, 앨리어스는 aws_iam_account_alias, 리전 정보는 aws_region라는 서로 다른 데이터 블록을 통해 각각 받아와야 한다. 그런데 메타데이터의 정보가 필요할 때마다 내가 원하는 정보가 어느 데이터 블록에 있는지 확인해야 하는 것은 번거롭다. 또한 이 상태에서 그냥 메타데이터를 다수의 데이터 블록을 호출하는 방법으로 알아내야 한다면, 반복적이고 장황한 코드를 작성하게 되어 가독성과 유지 보수성이 훼손된다. (105쪽)

VPC 모듈과 마찬가지로, 보안 그룹 모듈에서도 다른 리소스에서 참조할 만한 값을 출력 블록으로 설정한다. 이번 모듈에서 새롭게 생성한 리소스는 보안 그룹과 보안 그룹 규칙뿐이다. 보안 그룹 규칙의 식별자를 보안 그룹 모듈 밖에서 직접 사용하는 경우는 거의 없으므로, 출력값으로 설정할 만한 것은 보안 그룹의 아이디뿐이다. / 그러므로 보안 그룹 모듈의 출력 블록으로 모듈에서 생성한 모든 보안 그룹의 아이디를 맵 형식으로 내보내도록 정의하기로 한다. 이를 위해서 보안 그룹을 가리키는 리소스 블록인 aws_security_group.this에 for 표현식을 적용하고, 키와 값을 가리키는 매개변수를 사용해 k =〉 v.id 형태로 맵을 정의한다. 그 결과, 보안 그룹의 이름을 통해 보안 그룹의 아이디를 얻어낼 수 있는 출력 블록이 만들어진다. (187쪽)

널 프로바이더(%00; provider)는 실제 리소스를 생성하지 않는 가상의 리소스가다. 실제 리소스를 다루지 않는 대신, 템플릿이나 외부 스크립트를 실행하거나 단순한 워크플로를 제어하는 데 사용한다. 예를 들어 테라폼에서 지원하지 않는 API 요청을 전송하거나, 리소스 생성 흐름을 제어하고 싶은 경우에 사용할 수 있다. / 다만 대부분의 경우에는 널 프로바이더 없이도 스크립트 실행이나 리소스 제어가 가능하며, 널 프로바이더를 사용하면 코드를 이해하기 어려워지기 때문에 사용하는 것을 권장하지 않는다. 또한 테라폼 버전 1.4부터는 terraform_data6라는 이름의 같은 역할을 가진 테라폼 기본 리소스 타입이 도입되어 널 프로바이더를 사용할 필요가 사라졌다. 실제로 두 리소스를 비교하면 %00;_resource의 triggers 속성이 terraform_data에서는 triggers_replace로 바뀐 부분을 제외하면 나머지는 모두 동일하다. (249쪽)

아틀란티스(Atlantis)는 대표적인 테라폼의 협업을 위한 오픈소스 도구다. 테라폼의 코드 변경사항이 리포지터리에 푸시되었을 때, 자동으로 플래닝이나 반영 명령을 수행하는 등의 규칙을 설정할 수 있으며, 일관된 테라폼 실행 환경까지 제공하므로 추천할 만하다. 그렇다고 해서 모든 테라폼 프로젝트에 아틀란티스를 반드시 적용해야 한다는 것은 아니다. 우선 테라폼을 관리하는 팀원이 적을 경우, 아틀란티스로 인해 얻는 이점보다 아틀란티스를 설치하는 데 드는 비용이 더 들어갈 수도 있기 때문이다. 인프라를 다루는 도구이므로 기본적으로 사내망 안에서 설치해야 하기 때문에 서버 비용도 고려해야 하고, 처음 설치하는 사람에겐 파이프라인 구현까지 학습 곡선으로 작용하므로 반드시 필요한지 확인해보고 도입하는 것을 추천한다. (333쪽)

테라폼, 한번 써봤다면 이제는 제대로 빠져들 차례 IaC(코드형 인프라)는 더 이상 선택이 아니다. 실무에서 안정적이고 일관된 인프라를 운영하려면, 코드로 선언하고 관리하는 방식이 필수가 되었다. 그 중심에 있는 도구가 바로 테라폼이다. 그런데 문제는 여기서 시작된다. 테라폼 설치와 리소스 선언은 쉽다. 문제는 그다음이다. 상태 관리는 어떻게 할까? 실행 환경은 어떻게 나눌까? 모듈은 어디서부터 어떻게 쪼갤까? 테라폼을 ‘잘’ 쓰려면 단순히 선언하는 것만으로는 부족하다. ‘terraform apply’ 한 줄로는 실무가 굴러가지 않는다. 이 책은 문법만 훑는 입문서가 아닌, 실무에 바로 적용할 수 있는 실전형 가이드다. 왜 테라폼을 써야 하는지부터 선언만으로는 해결되지 않는 설계와 운영 방법까지 단계별로 짚어준다. 1부에서는 IaC의 필요성과 테라폼을 선택한 이유를 설명하고, 2부에서는 테라폼의 작동 방식, HCL 문법, 상태 파일과 커스텀 모듈의 핵심 개념을 정리한다. 3부에서는 모듈과 프로바이더 구성 방법을 중심으로 실행 환경 분리와 유효성 검사 등 실무 예제를 통해 테라폼 활용법을 설명한다. 4부에서는 VPC, 보안 그룹, EC2 등 AWS 인프라를 모듈 단위로 설계하고 구현하는 방법을 다룬다. 5부에서는 쿠버네티스, 헬름, 키클록 등 오픈소스 도구와의 테라폼 연동 방식을 실제 사례와 함께 소개한다. 부록에서는 기존 인프라에 테라폼을 도입할 때 주의할 점, 라이선스 변경 이슈 등 실무자라면 궁금해할 내용을 Q&A 형식으로 담았다. 이 책은 단순한 선언을 넘어 구조적이고 일관된 인프라를 설계하고 운영하는 방법을 알려준다. 반복은 줄이고, 다양한 환경에 유연하게 대응하며, 코드 한 줄로 인프라를 조율하는 감각을 키울 수 있다. 책을 따라가다 보면 어느새 테라폼의 효율성에 빠져 '이제 테라폼 없이는 인프라를 관리할 수 없다'고 느끼게 될 것이다. 대상 독자코드로 인프라를 다스리고 싶은 인프라 엔지니어자동화로 배포 스트레스를 줄이고 싶은 DevOps 엔지니어장애 없는 운영을 꿈꾸며 복구 시나리오까지 챙기는 SRE 주요 내용테라폼의 작동 원리와 상태 관리 이해실무에 맞춘 커스텀 모듈 설계와 활용AWS 인프라 구성 자동화 예제다양한 프로바이더와 오픈소스 연동멀티 리전, 계정 환경을 위한 구조 설계테라폼 운영과 도입을 위한 실무 팁