이득:
- IaC 개념과 Terraform의 작업 주기(초기화, 계획, 적용, 상태, 모듈)를 이해하고 인공 지능이 안전한 HCL 초안을 생성하도록 하는 능력
- 적용 전 각 변경 사항을 계획으로 확인하고 예상치 못한 파괴/교체 라인을 포착하는 기능
- 코드에서 비밀을 유지하고 상태를 안전하게 유지하며 IAM 권한을 최소화하는 원칙을 적용하는 능력
과거에는 가상머신 생성, 네트워크 설정, 보안규칙 추가 등 클라우드 패널을 클릭하면 서버 설정이 가능했습니다. 이 방법은 느리고 오류가 발생하기 쉬우며 반복할 수 없었습니다. 동일한 환경을 두 번째로 설정하는 것은 거의 불가능했습니다. 오늘날 인프라는 코드로 관리됩니다. IaC(Infrastructure as Code)는 서버, 네트워크, 데이터베이스 등 클라우드 자원을 수동이 아닌 텍스트 파일로 기술하는 접근 방식입니다. 이러한 파일은 버전 제어(Git)에 있습니다. 누가 무엇을, 언제, 무엇을 변경했는지 확인할 수 있습니다. 하나의 명령으로 동일한 인프라를 정확히 동일한 방식으로 여러 번 설정할 수 있습니다.
가장 일반적인 IaC 도구는 Terraform입니다. Terraform은 HCL(HashiCorp 구성 언어 - Terraform의 구성 언어)이라는 읽기 가능한 언어로 작성한 정의를 가져와 클라우드 공급자(AWS, Azure, GCP)의 API로 변환하고 리소스를 생성합니다. AI는 HCL을 매우 잘 알고 복잡한 블록을 빠르게 생성합니다. 그러나 IaC에서는 실수로 인한 비용이 높습니다. 잘못된 정의 하나가 전체 프로덕션 데이터베이스를 지울 수 있습니다. 그렇기 때문에 Terraform의 황금률은 모든 변경 사항을 구현하기 전에 '계획'으로 확인하는 것입니다.
Terraform의 런타임
Terraform은 세 가지 기본 명령으로 작동합니다. 이는 AI 출력을 제어하기 위한 전제 조건이라는 것을 알고 있습니다.
- `terraform init`: 프로젝트를 시작하고 필요한 공급자 플러그인을 다운로드합니다.
- `terraform plan`: 현재 상황과 원하는 상황을 비교하여 추가할 내용, 변경할 내용, 삭제할 내용을 표시합니다. 아무것도 구현하지 않습니다. 가장 중요한 보안 단계입니다.
- `terraform apply`: 실제로 계획을 적용하여 리소스를 생성/수정합니다.
또한 두 가지 개념이 중요합니다. 상태(상태 파일): Terraform이 관리하는 리소스의 현재 상태를 유지하는 파일입니다. 일반적으로 두 사람이 동시에 변경하거나 파괴할 수 없도록 원격의 잠긴 창고에 보관됩니다. 모듈: 재사용 가능한 구성 패키지; 예를 들어, 많은 프로젝트에서 "네트워크 설정" 모듈을 사용할 수 있습니다.
팁: Terraform 출력에서 가장 위험한 신호는 계획 출력의 파괴 또는 -/+(교체) 행입니다. 이는 리소스가 삭제된다는 의미입니다. 계획에서 예상치 못한 파괴가 보이면 절대 신청하지 말고 먼저 왜 나타나는지 이해하십시오.
단계별: AI로 IaC 작성
- 원하는 인프라를 명확히 합니다. "eu-central-1에 VPC 1개, 서브넷 2개, 보안 그룹 1개, t3.micro EC2 1개"와 같이 구체적으로 설명하세요.
- 공급자와 버전을 지정합니다. 어떤 클라우드, 어떤 Terraform 및 공급자 버전인가요? 버전을 지정하지 않으면 AI가 오래되었거나 호환되지 않는 구문을 반환할 수 있습니다.
- HCL 초안을 작성하십시오. 또한 변수와 출력을 요청합니다.
- 비밀을 꺼내세요. 비밀번호, 키 등의 값은 코드가 아닌 변수와 비밀 금고로 들어가야 합니다.
- 'init' + 'plan'을 실행하세요. 계획 출력을 한 줄씩 읽습니다. 예상치 못한 삭제가 있는지 확인하세요.
- 작게 시작하여 점차적으로 구현하십시오. 먼저 격리된 테스트 계정/환경에 적용하세요.
보안: IaC 관련 위험
IaC는 강력한 만큼 위험합니다. 세 가지 중요한 사항:
- 상태 파일에 비밀이 있습니다. Terraform 상태는 데이터베이스 비밀번호와 같은 민감한 값을 일반 텍스트로 유지하는 경우도 있습니다. 절대로 State를 공개 저장소에 두지 마십시오. 암호화되고 액세스가 제한된 원격 백엔드를 사용합니다.
- HCL에 비밀을 포함하지 마세요. 비밀번호="prod123"과 같은 줄은 Git 기록에 영구적으로 기록됩니다. 대신 변수를 사용하고 런타임 시 환경 변수(TF_VAR_...) 또는 비밀 저장소에서 값을 제공하세요.
- 매우 광범위한 IAM 권한. AI는 때때로 "작동하게 만들기" 위해 Action: "*"(모든 것을 허용)와 같은 블록을 생성합니다. 이는 취약점입니다. 필요한 최소 권한으로 권한을 좁힙니다.
주의: 비밀이 Git 기록에 들어가면 과거의 비밀로 남아 있으므로 파일을 삭제하더라도 손상될 수 있습니다. 실수로 커밋한 경우 즉시 보안 비밀을 취소하고 교체하세요. 삭제하는 것만으로는 충분하지 않습니다.
위험한 계획 표시 표
계획 인쇄물
의미
무엇을 해야할지
+만들기
새로운 리소스가 추가됩니다
일반적으로 안전하지만 검토해 보세요.
~ 내부 업데이트
출처는 현장에서 바뀔 예정입니다
영향 확인(중단이 발생합니까?)
-/+ 교체
삭제 후 다시 생성됩니다.
주의: 데이터 손실이 발생할 수 있습니다.
- 파괴하다
자원이 파괴됩니다
중지: 예상하지 못한 경우에는 절대 신청하지 마세요.
세 개의 미니 케이스
사례 1 — 3시간 안에 2일 작업. 한 팀은 새로운 테스트 환경(VPC, 서브넷, RDS 데이터베이스, ECS 클러스터)을 설정하기 위해 Terraform을 작성하려고 했으나 방금 HCL로 이동했습니다. 그들은 AI에 아키텍처와 버전을 설명하고 모듈식 청사진을 제작했습니다. 그들은 계획에 따라 각 모듈을 검증하고 3시간 만에 실행했습니다. 수동으로 시행착오를 거치려면 이틀이 걸릴 것입니다.
사례 2 — 계획이 삭제되었습니다. 엔지니어는 AI 생성 업데이트 코드를 적용하지 않고 계획을 실행했습니다. 출력에는 -/+ 프로덕션 데이터베이스 교체가 포함되어 있습니다. AI는 교체할 수 없는 필드를 교체하려고 시도했는데, 이는 데이터베이스를 삭제하고 다시 생성하는 것을 의미합니다. 엔지니어는 적용을 중단하고 안전한 방법으로 변경했습니다. 계획하는 습관이 재난을 막았다.
사례 3 - 묻힌 비밀 유출. 주니어, YZ 발행 db_password = "S3cret!" 라인을 그대로 커밋하고 밀었다. 코드 검토에 걸렸습니다. 비밀번호는 즉시 취소 및 변경되었으며, 값은 변수로 이동되어 비밀 금고에서 공급되었습니다. 교훈: HCL에는 일반 텍스트 비밀이 없습니다.
복사 가능한 템플릿 4개
1) 인프라 초안 생성:
Terraform(버전 ~> 1.7)을 사용하여 [CLOUD: AWS]에 다음 인프라를 작성합니다. [SOURCE LIST]. 지역 [X]. 규칙:- 모든 중요한 값을 변수로 만들고 HCL에 포함하지 마세요.- 공급자 버전을 수정하세요(required_providers).- IAM 권한을 최소화하고 "*"를 사용하지 마세요.- [X, Y]를 출력으로 반환합니다. 코드를 모듈식으로, 설명과 함께 제공하세요.
2) 계획 결과 해석:
아래의 'terraform 계획' 출력을 분석하세요. 나열하세요:(1) 어떤 리소스가 추가/변경/삭제되었는지,(2) 데이터 손실 또는 중단 위험이 있는 행,(3) 신청하기 전에 물어봐야 할 3가지 질문.계획: [출력]
3) 보안을 위해 기존 HCL을 검사합니다.
보안을 위해 다음 Terraform 코드를 확인하세요. 내장된 비밀, 지나치게 광범위한 IAM 권한, 개방형 네트워크 규칙(0.0.0.0/0), 암호화되지 않은 저장소? 중요성과 수정 사항의 순서대로 각 결과를 작성하십시오. 코드: [HCL]
4) 반복되는 코드를 모듈로 변환합니다.
다음 반복 Terraform 코드를 재사용 가능한 모듈로 변환합니다. 어떤 값이 변수여야 하고, 모듈 인터페이스는 무엇이어야 합니까? 또한 예제 사용법을 보여줍니다. 코드: [HCL]
약한 프롬프트 / 강한 프롬프트
약함: "Terraform을 사용하여 데이터베이스를 생성합니다."
결과: 어떤 클라우드, 어떤 엔진, 어떤 버전이 암호화되었는지 여부가 불분명합니다. 레거시 구문을 사용하면 AI는 암호를 코드에 포함하는 공개적으로 사용 가능한 예를 제공할 수 있습니다.
Strong: "Terraform ~> 1.7을 사용하여 AWS에서 RDS PostgreSQL 15 인스턴스를 생성합니다. 비밀번호 변수를 만들고 코드에 포함하지 마세요. 스토리지는 암호화되어 퍼블릭이 아닌 프라이빗 서브넷에서만 액세스할 수 있습니다. 공급자 버전을 수정합니다. 엔드포인트를 출력으로 반환합니다."
차이점: 두 번째 프롬프트는 엔진, 버전, 암호화, 네트워크 제약 조건 및 비밀 규칙을 제공합니다. 출력은 안전하고 prod에 가깝습니다.
일반적인 실수
- '계획'을 세우지 않고 '신청'하다. IaC에서 가장 비용이 많이 드는 실수입니다. 항상 먼저 계획을 세우십시오.
- HCL에 비밀을 삽입합니다. Git 기록에 영구적인 유출을 생성합니다.
- 저장 상태가 안전하지 않습니다. 암호화되지 않고 잠금 해제된 공개 상태는 재앙입니다.
- 버전을 수정하지 않습니다. 버전을 지정하지 않고 공급자를 사용하면 나중에 갑작스러운 오류가 발생할 수 있습니다.
- *`조치: ""`와 같은 광범위한 권한.** 최소 권한의 원칙을 위반합니다.
- 예상치 못한 '파괴'를 무시합니다. 질문 없이 계획에 삭제 라인을 적용합니다.
요약하면
IaC는 인프라를 반복 가능하고 버전 관리 가능하며 감사 가능한 코드로 전환합니다. 가장 일반적인 도구는 Terraform입니다. AI는 신속하게 HCL 스텁을 생성하지만 버전, 클라우드별 세부 정보 및 보안 규칙을 제공해야 합니다. Terraform의 절대적인 규칙: 계획에 따라 모든 변경 사항을 확인하고, 예상치 못한 삭제를 쿼리하고, 코드에서 비밀을 보호하고 상태를 안전하게 유지하는 것입니다. 계획 출력의 파괴 및 교체 행은 가장 주의 깊게 읽어야 하는 부분입니다.
응용과제
위의 "인프라 스케치 생성" 템플릿을 사용하여 AI가 작은 인프라(예: 스토리지 버킷 및 액세스 정책)를 생성하도록 하세요. 그런 다음 (1) "심사" 템플릿을 사용하여 코드에 포함된 비밀 또는 * 권한을 확인합니다. (2) 가능하다면 테스트 계정에서 init + plan을 실행하고 "계획 해석" 템플릿을 사용하여 계획 출력을 읽습니다. (3) 예상치 못한 삭제/변경 사항을 기록해 둡니다.
체크리스트
- [ ] 프롬프트에 클라우드, Terraform/공급자 버전, 암호화/네트워크 제약 조건을 추가했습니다.
- [ ] 코드에는 일반 텍스트 비밀이 없습니다. 정밀도 값은 가변적입니다.
- [ ] IAM/권한을 최소한의 권한으로 좁혀서 * 사용하지 않았습니다.
- [ ] 적용하기 전에 계획을 실행하고 출력을 한 줄씩 읽었습니다.
- [ ] 계획에 예상치 못한 파괴/교체가 없음을 확인했습니다.
- [ ] 암호화되고 잠겨 있으며 제한된 백엔드에 상태가 유지된다고 확신합니다.