Terraform Associate 004 #2 IaC 개념과 테라폼의 목적: 정의 문항 정복
첫 시험 범위는 정의의 영역입니다. “IaC의 이점이 아닌 것은?”, “테라폼이 멀티 클라우드를 다루는 방식은?” 같은 문항들로, 개념 자체는 기초 #1에서 다 만난 것들입니다. 함정은 익숙함에 있습니다. 아는 내용이라 대충 읽다가, 선택지의 미묘한 표현 차이(멱등성 대 원자성, provider 대 provisioner)에 걸리는 영역이기 때문입니다. 시험의 언어로 다시 정렬하겠습니다.
IaC의 정의와 이점 #
시험이 기대하는 정의는 이렇습니다. 인프라를 수동 절차가 아니라 기계가 읽을 수 있는 정의 파일로 프로비저닝·관리하는 방식. 이점을 묻는 문항에서 정답 후보가 되는 키워드는 다음입니다.
- 재현성: 같은 코드는 같은 인프라를 만듭니다. 환경 복제와 재해 복구의 기반입니다.
- 버전 관리: 인프라 변경이 Git 이력·리뷰·롤백의 대상이 됩니다.
- 자동화: 사람의 콘솔 조작을 CI 파이프라인으로 대체합니다.
- 일관성(드리프트 감소): 코드가 유일한 진실이 되어 환경 간 어긋남이 줄어듭니다.
반대로 “IaC의 이점"으로 아닌 것을 고르라는 문항에서는 “인프라 비용 자체의 감소”, “장애의 원천 차단” 같은 과장 선택지가 미끼로 나옵니다. IaC는 관리 방식의 개선이지 요금표나 하드웨어를 바꾸는 것이 아닙니다.
선언형과 멱등성 #
- 선언형(declarative): 원하는 최종 상태를 기술하면 도구가 도달 방법을 계산합니다. 테라폼의 방식입니다.
- 명령형(imperative): 수행할 절차를 순서대로 기술합니다. 셸 스크립트의 방식입니다.
- 멱등성(idempotency): 같은 작업을 여러 번 적용해도 결과가 같은 성질입니다. 테라폼 apply는 이미 일치하는 리소스를 건드리지 않으므로 멱등합니다.
시험 표현으로 다지면, 테라폼 설정 파일은 “무엇을 원하는가"를 담지 “어떻게 만드는가"의 절차를 담지 않습니다. plan이 현재 상태와 원하는 상태의 차이를 계산해 실행 계획을 만드는 구조(기초 #1의 선언형 동작)가 이 성질들의 출처입니다.
테라폼의 목적: 시험이 미는 세 가지 #
“왜 테라폼인가"를 묻는 문항의 정답 축은 세 가지입니다.
- 멀티 클라우드·provider 생태계: 테라폼 코어는 클라우드를 모릅니다. AWS, Azure, GCP는 물론 SaaS까지 provider 플러그인이 담당하고, 같은 HCL 문법으로 수천 개 provider의 리소스를 다룹니다. “각 클라우드의 전용 도구를 배우지 않고 한 워크플로로 통일"이 시험이 기대하는 이점 서술입니다.
- state를 통한 추적: 테라폼은 관리 중인 리소스를 state에 기록해, 코드·state·실제의 비교로 변경을 계산합니다. “state의 목적은?“에 대한 답은 실제 인프라와 설정의 매핑을 유지해 plan을 가능하게 하는 것입니다. 상세 구조는 #5에서 다룹니다.
- 실행 계획(plan): 적용 전에 무엇이 바뀔지 보여 주는 단계가 워크플로에 내장되어 있습니다. 리뷰와 안전의 근거입니다.
자주 나오는 구분 문항 #
이 영역의 함정 선택지들은 비슷한 단어의 역할 구분에서 나옵니다. 표로 눌러 둡니다.
| 용어 | 역할 | 헷갈리는 상대 |
|---|---|---|
| provider | 클라우드·서비스 API와의 연결 플러그인 | provisioner(생성 후 스크립트 실행, 최후 수단) |
| resource | 관리 대상 인프라 객체 선언 | data source(읽기 전용 조회) |
| Terraform(코어) | 그래프 계산·plan·state 관리 바이너리 | provider(실제 API 호출 담당) |
| HCL | 사람이 쓰는 설정 언어(JSON 호환 표기도 존재) | YAML(테라폼과 무관, 미끼 선택지 단골) |
특히 provisioner는 “테라폼이 권장하는 구성 관리 방법"처럼 포장된 오답으로 자주 나옵니다. 공식 입장은 최후의 수단(last resort)이며, 구성 관리는 이미지 빌드나 전용 도구에 맡기는 것이 권장입니다.
테라폼의 구조: 바이너리 하나, 플러그인 여럿 #
아키텍처 문항 대비로 구조를 한 번에 정리합니다. 테라폼은 단일 바이너리(코어)이며, init 때 설정에 선언된 provider 플러그인을 내려받아 함께 동작합니다. 코어가 설정과 state로 의존성 그래프를 만들고 plan을 계산하면, provider가 각 리소스의 CRUD를 실제 API 호출로 수행합니다. “테라폼은 어떻게 새 서비스가 나와도 지원하는가"의 답이 이 플러그인 구조이고, 기초 #1의 비교표에서 본 경쟁 도구 대비 생태계 우위의 기술적 배경이기도 합니다.
정리 #
이번 글에서 다룬 내용입니다.
- IaC의 이점 키워드는 재현성, 버전 관리, 자동화, 일관성입니다. 비용·장애의 원천 해결 같은 과장 선택지가 미끼입니다
- 테라폼은 선언형이고 apply는 멱등합니다. 설정은 최종 상태를 담고 절차를 담지 않습니다
- 테라폼의 목적 문항은 멀티 클라우드 provider 생태계, state 기반 추적, 실행 계획 세 축으로 답합니다
- provider와 provisioner, resource와 data source의 역할 구분이 함정 단골이며, provisioner는 최후 수단입니다
- 코어는 그래프와 plan, provider는 API 호출이라는 분업 구조를 기억합니다
다음 글(#3 테라폼 기본기)에서는 설치와 버전 관리, provider 설정으로 들어갑니다. 버전 제약 연산자와 잠금 파일이라는, 시험이 유난히 좋아하는 두 주제가 있는 영역입니다.