Terraform Associate 004 #9 HCP Terraform: workspace, variable set, 정책, 드리프트 감지

5 분 소요

마지막 범위는 HashiCorp의 관리형 플랫폼, HCP Terraform입니다(옛 이름 Terraform Cloud로 더 알려져 있고, 시험·문서에 두 이름이 섞여 나올 수 있습니다). 트랙에서는 운영 #6에서 플랫폼 비교의 한 항목으로만 다뤘는데, 004는 이 영역의 출제 폭을 넓혔으므로 개념 구조를 제대로 세워 둘 필요가 있습니다. 실습 없이도 풀 수 있도록 “무엇이 무엇을 담고, 무엇이 어디서 실행되는가"의 구조 중심으로 정리하겠습니다.

workspace: CLI 워크스페이스와 다릅니다 #

가장 중요한 구분부터 짚겠습니다. HCP Terraform의 workspace는 CLI의 terraform workspace 명령과 이름만 같고 다른 개념입니다.

  • CLI 워크스페이스: 같은 설정에서 state만 여러 벌 갖는 로컬 기능입니다. 실전 #9에서 한계를 짚고 채택하지 않았습니다.
  • HCP workspace: 플랫폼의 관리 단위입니다. 하나의 설정(보통 저장소 하나 또는 디렉터리 하나)에 대한 state, 변수, 실행 이력, 권한이 workspace 하나에 묶입니다. 로컬로 치면 “백엔드 key 하나 + 그 운영 화면"에 해당합니다.

이 구분 자체가 단골 문항입니다. 그리고 project는 여러 workspace를 묶는 상위 폴더로, 팀·서비스 단위의 권한 관리 경계가 됩니다. 구조는 “조직(organization) → project → workspace"의 3층입니다.

실행 방식: VCS, CLI, API #

HCP Terraform에서 plan·apply가 시작되는 경로는 세 가지이며, 각각의 성격을 구분합니다.

  1. VCS 연동(VCS-driven): 저장소와 workspace를 연결하면, PR에 plan이 붙고 병합이 apply를 트리거합니다. 운영 #1에서 GitHub Actions로 직접 조립한 흐름을 플랫폼이 내장 제공하는 형태이며, 시험이 기대하는 “팀 표준” 경로입니다.
  2. CLI 연동(CLI-driven): 로컬에서 terraform 명령을 치되 실행은 HCP의 원격 환경에서 일어납니다. 설정의 cloud 블록으로 연결합니다.
  3. API 연동(API-driven): 외부 시스템이 API로 실행을 트리거합니다. 커스텀 파이프라인용입니다.

원격 실행의 공통 이점은 자격 증명과 state가 로컬에 없다는 것, 실행 이력이 플랫폼에 남는다는 것입니다. run trigger(한 workspace의 apply 완료가 다른 workspace의 실행을 촉발)는 운영 #5의 스택 간 의존을 플랫폼 기능으로 잇는 장치라는 위치까지 알아 두면 충분합니다.

변수와 variable set #

workspace에는 테라폼 변수와 환경 변수를 등록할 수 있고 sensitive 표시가 가능합니다. 출제 포인트는 variable set입니다. 여러 workspace에 공통으로 주입되는 변수 묶음으로, “모든 workspace에 같은 클라우드 자격 증명을 공급"하는 표준 방법입니다. workspace마다 복사해 등록하는 선택지는 오답 방향이고, 우선순위는 workspace 개별 변수가 variable set보다 우선합니다(좁은 쪽이 이기는 기초 #3 이래의 일관된 원리입니다).

정책: Sentinel·OPA와 두 가지 실패 #

정책 코드화(policy as code)는 plan과 apply 사이에 규칙 검사를 끼워 넣는 기능입니다. HashiCorp의 Sentinel 또는 OPA로 정책을 쓰며, “인스턴스 타입은 허용 목록만”, “태그 필수” 같은 규칙이 plan 결과에 대해 평가됩니다. 시험 구분 포인트는 실패의 강도입니다.

  • hard-mandatory: 위반 시 무조건 차단. 우회 불가.
  • soft-mandatory: 위반 시 차단하되, 권한 있는 사람이 명시적으로 오버라이드하고 진행할 수 있음.
  • advisory: 경고만 남기고 진행.

운영 #4에서 CI에 스캐너로 조립했던 가드레일의 플랫폼 내장판이라고 이해하면 위치가 잡힙니다.

드리프트 감지와 그 밖의 기능 #

  • 드리프트 감지(drift detection): 플랫폼이 주기적으로 실제 인프라와 state를 대조해 어긋남을 알립니다. 운영 #2에서 cron 워크플로로 직접 만든 감지기의 내장판입니다. health assessment의 일부로, continuous validation(설정의 check 블록을 지속 평가, #7의 그 check)과 짝으로 나옵니다.
  • 비공개 레지스트리: 조직 전용 모듈·provider 레지스트리를 제공합니다. 조직 표준 모듈 배포의 정답 방향입니다.
  • Terraform Enterprise: HCP Terraform의 자체 호스팅판입니다. 기능은 같은 계열이고 설치 위치가 다르다는 구분만 나옵니다.

요금 티어 세부는 출제보다는 상식 수준으로, 무료 티어가 존재하고 상위 티어에서 정책·거버넌스 기능이 열린다는 정도면 충분합니다.

정리 #

이번 글에서 다룬 내용입니다.

  • HCP workspace는 CLI 워크스페이스와 다른 개념으로, state·변수·실행 이력을 담는 관리 단위이며 project가 그 상위 묶음입니다
  • 실행 경로는 VCS, CLI, API 세 가지이고 VCS 연동이 팀 표준 경로입니다. run trigger가 workspace 간 의존을 잇습니다
  • variable set은 여러 workspace 공통 변수의 표준 공급법이며, workspace 개별 변수가 우선합니다
  • 정책은 Sentinel·OPA로 plan과 apply 사이에 평가되며, hard·soft-mandatory·advisory의 강도 구분이 출제 축입니다
  • 드리프트 감지·continuous validation은 트랙에서 직접 조립한 장치들의 내장판이고, Enterprise는 자체 호스팅판입니다

다음 글(#10 모의고사)이 마지막입니다. 아홉 편의 범위 전체에서 50문항을 뽑아 해설과 함께 풀어 보겠습니다.

X