🎯 AI 시대의 인프라 엔지니어링: Terraform 학습 원칙과 생존 전략
“AI는 ‘어떻게(How)‘를 잘하고, 사람은 ‘왜(Why)‘를 알아야 한다.”
1. 기술적 난제: AI가 짜주는 코드, 과연 완벽할까?
최근 AI(Claude, Gemini 등)의 코딩 능력이 비약적으로 발전하면서, 복잡한 HCL(HashiCorp Configuration Language) 문법도 순식간에 작성해 줍니다. “VPC와 EC2, RDS를 구성하는 테라폼 코드를 짜줘”라고 하면 에러 없는 깔끔한 코드를 반환합니다.
하지만 여기에 치명적인 함정이 있습니다. AI는 코드가 문법적으로 ‘동작’하게 만드는 데는 탁월하지만, 그 인프라가 비즈니스 목적에 부합하는지, 보안적으로 안전한지, 비용 효율적인지는 책임지지 않습니다. 예를 들어, AI는 단순히 “비용을 줄여달라”는 요청에 아웃바운드 트래픽 보호를 위한 NAT Gateway를 삭제하는 코드를 제안할 수 있습니다. 당장의 에러는 없겠지만, 프로덕션 환경에서는 심각한 보안 및 운영 리스크를 초래하는 선택입니다.
2. 해결을 위한 선택: AI와 인간의 명확한 역할 분담
성공적인 인프라 관리를 위해서는 AI가 잘하는 것과 사람이 반드시 판단해야 하는 영역을 명확히 구분해야 합니다.
🤖 AI가 압도적으로 잘하는 것 (How)
- 문법 및 템플릿 작성: HCL 문법 작성 및 코드 오류 수정
- 반복 작업 자동화: 비슷한 리소스(Subnet, Route Table 등)의 반복 생성
- 문서화: 코드의 목적을 설명하는 주석 및 리드미 작성
- 트러블슈팅: 복잡한 에러 메시지 해석 및 기본적인 해결 방안 제시
🧠 사람이 반드시 책임져야 하는 것 (Why)
- 아키텍처 설계: “왜 Private Subnet에 배치해야 하는가?”, “NAT Gateway가 정말 필요한가?”
- 비용 최적화 (FinOps): “이 아키텍처를 유지하면 한 달에 얼마가 청구되는가?”
- 보안 판단: “이 Security Group의 인바운드 규칙(0.0.0.0/0)이 타당한가?”
- 비즈니스 맥락 이해: 서비스의 트래픽 패턴, 회사의 장애 허용 범위(SLA)
- 운영 경험 (Postmortem): “과거에 이런 구조로 배포했다가 어떤 장애를 겪었는가?“
3. 극복과 성장: 테라폼 실력을 높이는 5가지 현실적인 방법
AI에게 무비판적으로 의존하지 않고, 진짜 ‘내 실력’으로 만들기 위한 5단계 실전 학습법입니다.
① 직접 깨져보며 체감하기 (Failure Driven Learning)
terraform destroy를 실수로 실행하여 데이터가 날아가는 경험 → 백업과 Deletion Protection의 중요성 체감- Public Subnet에 DB를 올렸다가 외부 접근을 허용하는 경험 → 네트워크 격리와 보안 설계의 필요성 이해
- 불필요한 리소스 방치로 요금 폭탄을 맞는 경험 → 비용 관리 및 리소스 수명 주기 관리 습관화
② plan 결과를 직접 읽고 검증하는 습관
AI가 작성한 코드든, 복사해 온 코드든 적용 전 반드시 변경 사항을 직접 읽어야 합니다.
terraform plan -out=tfplan
terraform show tfplan이 과정을 통해 의도치 않은 리소스 삭제나 변경이 없는지 눈으로 확인하는 것이 엔지니어의 핵심 책임입니다.
③ 상태 파일(State)에 대한 깊은 이해
Terraform의 코어는 코드가 아니라 terraform.tfstate 파일입니다.
terraform state list
terraform state show aws_instance.backendState가 무엇인지 명확히 알아야만 형상 불일치(Drift) 해결, 기존 리소스 가져오기(import), 그리고 협업 시 상태 충돌 문제를 해결할 수 있습니다.
④ 나만의 모듈 직접 만들어보기
남이 만든 퍼블릭 모듈(Terraform Registry)만 가져다 쓰기보다는, VPC나 EC2 생성을 위한 모듈을 직접 설계하고 추상화해 봅니다. 이 과정을 통해 변수(variables)와 출력(outputs), 구조화의 원리를 깊게 이해할 수 있습니다.
⑤ AWS 콘솔에서 수동으로 먼저 만들어보기
테라폼 코드부터 짜기 전에, AWS Management Console에서 직접 VPC → Subnet → EC2 → ALB 순서로 클릭해가며 리소스를 생성해 봅니다. GUI 환경에서 리소스 간의 **의존 관계(Dependency)**를 몸소 체감한 후에 코드로 옮기면 아키텍처가 머릿속에 훨씬 선명하게 그려집니다.
💡 결론
AI는 훌륭한 ‘작업자(Doer)‘이지만 ‘설계자(Architect)‘는 아닙니다. AI가 코드를 작성해 주면 항상 스스로에게 **“왜 이렇게 설계했지?”**라고 되물어야 합니다. 이 질문에 명확히 답할 수 없다면, 그 코드는 아직 내 것이 아니며 프로덕션 환경에 적용해서도 안 됩니다.