pile·
인프라 / DevOps·LY CorporationLY Corporation·

코드형 인프라(IaC)로 자동화에서 AI까지: OpenTofu와 ChatOps 도입기

LY Corporation SRE1팀이 여러 팀에 산재한 인프라 관리 방식을 OpenTofu(Terraform 오픈소스 포크)와 Terragrunt 기반 IaC로 통합한 전 과정을 다룬다. 300여 대 VM, 160개 LB, 350개 DNS 레코드를 포함한 약 1,500개 리소스를 코드화하고, AI 에이전트와 MCP를 결합해 Slack 자연어 요청만으로 인프라 변경이 가능한 ChatOps 파이프라인까지 구현했다.

핵심 포인트
  • OpenTofu+Terragrunt 조합으로 7개 서비스 1,500개 리소스를 코드화. Terragrunt의 DRY 원칙으로 root.hcl에 공통 설정을 한 번만 정의하고 환경별 입력값만 별도 관리
  • Phase 1에서 Import 자동화 스크립트(조회→코드 변환→State 연결→Plan 검증)로 1개 서비스를 마이그레이션해 모듈·파이프라인·정규화 스크립트를 검증한 후 Phase 2에서 나머지 서비스로 확산
  • Drift Check(코드와 실제 인프라 불일치 자동 감지)를 매일 실행하고 Slack으로 알림해 콘솔 임의 변경을 사전 차단
  • 웹 대시보드 DOM을 파싱해 HCL 코드를 자동 생성하는 Chrome 확장 프로그램으로 기존 대시보드 습관과 IaC 워크플로우를 연결
  • MCP로 OpenTofu 저장소를 AI 에이전트에 연결, Slack 자연어 요청→Terragrunt 코드 생성→PR 자동 생성→사람 리뷰 후 배포 ChatOps 파이프라인 구현. 인프라 변경 소요 시간 수십 분→수 분으로 단축
상세 정리
  • 도입 배경: 팀별 인프라 관리 도구가 대시보드·스크립트·위키로 분산돼 추적 곤란, 중복 작업, 휴먼 에러 위험이 커졌다. "인프라도 코드처럼 리뷰·버전 관리·재현 가능해야 한다"는 철학에서 출발
  • 도구 선택: Terraform 대신 OpenTofu를 선택한 이유는 HCL 문법 호환성 유지와 오픈소스 라이선스. Terragrunt로 DRY 원칙을 확장해 공통 설정을 한 번만 정의하고 각 환경별 입력값만 별도 관리
  • Import 자동화: 기존 리소스 조회→코드 변환→State 연결→Plan 검증 4단계를 스크립트로 자동화. VM은 개별 인스턴스, LB는 리스너·풀 포함, DNS는 존-레코드 관계, K8s는 클러스터-노드 풀 구조, IMON은 팀→알림그룹→알림규칙→알림모니터 계층 구조로 리소스 유형별 전략이 달랐다
  • 정규화 함정: 코드-State-실제 인프라 3자 불일치를 네트워크 ID·이미지 ID 등 표현 방식 통일로 해결. LB 네이밍의 하이픈·언더스코어 호환성 문제는 Provider에 직접 기여해 수정. UUID 리전 불일치는 모듈 내 매핑 로직 추가로 대응
  • Chrome 확장 프로그램: 웹 대시보드 DOM에서 설정값을 읽어 HCL 코드로 변환. "대시보드 대체"가 아닌 "대시보드→코드 다리" 역할로 기존 습관과 IaC 워크플로우를 자연스럽게 연결해 학습 장벽을 낮춤
  • GitOps 파이프라인: PR 생성→Plan 자동 댓글→CODEOWNERS 필수 리뷰어 지정→머지 시 Apply→Slack 성공/실패 알림. Drift Check는 매일 자동 스캔해 불일치 발견 시 Slack 알림, .driftignore로 의도적 예외 관리
  • 모니터링 코드화: 알림 임계치를 PR 한 번으로 여러 개 동시 수정 가능. 변경 사유가 커밋 메시지에 자동 기록되고 동일 알림 구조를 새 서비스에 복사해 적용 가능
  • AI ChatOps: Slack에서 "서버 1대 더 추가해줘" 자연어 요청→AI가 기존 코드 패턴 참고해 Terragrunt 파일 수정→PR 자동 생성·plan 결과 Slack 공유→사람 리뷰 후 배포. 알림 수신 시엔 AI가 IaC로 현황 즉시 파악 후 스케일 아웃 코드를 자동 생성해 PR에 이유·알림·plan 결과를 기록
  • 셀프서비스: 기존에는 모든 변경이 SRE 팀을 거쳐야 했으나 이제 개발팀 직접 작성·AI 에이전트 경유·모니터링 트리거 3가지 경로로 분산. 세 경로 모두 동일 GitOps 파이프라인 통과
  • 온보딩 효과: 저장소와 PR 이력만으로 인프라 구조와 의사결정 맥락 파악 가능. 시니어만 알던 지식이 코드와 커밋 이력으로 자동 공유됨
  • 확산 성과: Phase 1에서 1개월간 도구·파이프라인·정규화 스크립트·가드레일을 확립한 후 Phase 2에서 나머지 서비스를 빠르게 마이그레이션. 현재 관리 VM 약 300대, LB 160개, DNS 레코드 350개, 코드화 리소스 약 1,500개
왜 읽나OpenTofu/Terragrunt로 다중 서비스 인프라를 GitOps로 통합하고 AI 에이전트 ChatOps까지 연결하려는 SRE·DevOps 엔지니어에게 마이그레이션 전략·Drift 관리·AI 파이프라인 구현까지 단계별 실전 레퍼런스.
LY Corporation
LY Corporation 블로그
원문은 여기서 이어서 읽을 수 있어요
원문 읽기
읽음 (0)

이 글과 비슷한

  1. 인프라 / DevOps·AWS KoreaAWS Korea Tech·

    엔터프라이즈 보안 요구사항을 충족하는 프라이빗 Amazon Bedrock AgentCore 구축하기

    Amazon Bedrock AgentCore의 VPC egress 기능(2026년 4월 추가)을 활용해 온프레미스 LLM·사내 IdP·사내 MCP 서버에 인터넷 노출 없이 연결하는 방법을 다룬다. 규제 산업 엔터프라이즈가 기존 사내 자산을 그대로 유지하면서 Bedrock AgentCore를 안전하게 구축하기 위한 구성 가이드다.

    요약 이어보기
    #mcp#amazon-bedrock#vpc+2
  2. 인프라 / DevOps·gitlab-engGitLab Blog·

    OpenTofu와 Argo CD로 구성하는 GitLab 기반 AWS 제어 플레인

    GitLab을 단일 제어 플레인으로 삼아 OpenTofu로 AWS 인프라를 프로비저닝하고, Argo CD로 GitOps 기반 애플리케이션 배포까지 자동화하는 엔드투엔드 튜토리얼이다. VPC·EKS 클러스터 구성부터 Helm 기반 툴 설치, 샘플 앱 배포까지 모든 과정이 GitLab CI/CD 파이프라인으로 연결된다.

    요약 이어보기
    #kubernetes#aws-eks#gitops+2
  3. 인프라 / DevOps·AWS KoreaAWS Korea Tech·

    Amazon Bedrock 기반 사내 LLM, 키 발급부터 비용 차단까지: F&F의 LiteLLM 게이트웨이 운영 사례

    패션 기업 F&F가 Amazon Bedrock과 LiteLLM 프록시를 결합해 구축한 사내 LLM 플랫폼 운영 사례다. API 키 셀프서비스 발급, 모델별 접근 승인 워크플로, 사용자·프로젝트별 예산 자동 차단까지 전 과정을 직접 구현한 아키텍처 결정과 운영 교훈을 공유한다.

    요약 이어보기
    #kubernetes#amazon-bedrock#litellm+2