이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.
TL;DR
대규모 인프라를 코드로 관리하고 GitOps로 배포하며, Slack AI 에이전트로 코드 생성을 자동화한 사례를 설명한다.
인프라를 코드로 선언하는 IaC 도입의 필요성이 커지자 OpenTofu와 Terragrunt로 모듈화와 DRY 원칙을 적용했고, 기존 리소스를 Phase 1 임포트로 코드화하며 Phase 2 확산의 디딤돌을 만들었다. Chrome 확장과 Opentalk 같은 도구와 문화적 확산 채널을 통해 서비스 간 일관된 변경 흐름을 구축했고, Drift 체크를 통한 자동 모니터링과 변경 이력 관리로 운영 안정성과 온보딩 속도가 크게 향상되었다.
마지막으로 AI 에이전트를 Slack과 연결해 자연어 요청으로도 코드 생성 및 PR 생성이 가능해지며, 인프라 운영의 자기주도성과 확장성이 강화되었다. 이로써 인프라와 코드의 경계가 허물어지며 인간과 AI가 함께 읽고 작성하는 생산적 파이프라인이 형성되었다.
섹션별 상세
서비스와 자원이 증가하면서 운영의 복잡도가 커졌고, 여러 팀이 각자 다른 방식으로 인프라를 다루는 비일관성이 문제로 대두되었다. 입력으로 원하는 인프라 상태를 선언하고 변경 이력을 Git에 남겨 PR 리뷰를 거치며 배포하는 GitOps로 전환했다. 현재 약 1,500개의 리소스가 코드로 선언되고, 7개 서비스의 인프라 변경이 모두 PR/CI/CD 파이프라인으로 적용되며 차이가 자동으로 탐지된다. 이로써 변경 이력의 투명성, 재현성, 거버넌스가 확보되고 운영의 신뢰성과 확장성이 크게 향상되었다.
도입 초기에는 OpenTofu와 Terragrunt를 도입해 Terraform 호환 구문(HCL)을 유지하되 오픈소스 라이선스로 운영하는 방식을 선택했고, 모듈화를 통해 VM, LB, 모니터링 구성 등을 재사용 가능한 단위로 분리했다. Terragrunt를 통해 상위 루트에 공통 설정을 두고 환경별 차이만 Inputs로 남겨 DRY 원칙을 적용했고, 모듈의 버전 관리로 환경 간 영향 확산을 제어했다. 이 두 도구의 합으로 인프라 정의의 재현성과 확장성을 확보했고 Phase 1의 임포트 작업과 이후 확장을 위한 파이프라인 설계의 기반이 되었다.
Phase 1 임포트 설계—운영 중이던 자원을 코드로 옮기려면 안전성이 최우선이었고, 자원별로 다른 임포트 방식이 필요했다. 자동 임포트 스크립트를 설계해 자원을 탐지하고 코드로 변환한 뒤 실제 인프라 상태에 연결하고 OpenTofu Plan으로 변경을 예측하도록 했다. 네트워크 ID/이미지 ID 차이의 정규화, Kubernetes가 생성한 VM의 관리 주체 구분 등 리소스별 특성에 맞춘 분기처리를 도입해 계획의 불필요한 차이와 충돌을 줄였다. 이 단계의 성공은 Phase 2의 대규모 확산에 필요한 신뢰성과 일관성을 확보했다.
Phase 2 확산 및 운영 흐름—서비스 확산과 운영 흐름. Phase 2에서는 모듈과 임포트 스크립트를 재사용해 다른 서비스에도 같은 파이프라인을 빠르게 적용했다. Chrome 확장과 Opentalk를 통해 현장에 확산시키고, PR 기반의 변경 흐름과 GitOps 파이프라인으로_PLAN_·리뷰·적용의 흐름을 일관되게 유지하며 Drift 체크를 매일 수행했다. 이로써 문서는 코드로 대체되고 누구나 코드로 인프라를 이해하고 변경할 수 있는 환경이 만들어지며 운영 효율이 크게 향상됐다.
Drift 및 Monitoring as Code—운영 자동화의 가치와 한계. 도입 이후 모든 변경은 Git에 기록되고 Drift Check로 코드의 선언 상태와 실제 인프라의 차이를 매일 확인한다. 드리프트는 콘솔 변경이 코드와 다를 때 탐지되며 Slack 알림으로 즉시 대응이 가능하다. 모니터링 경보도 코드로 관리되면서 단일 PR로 다수 알림의 임계값을 변경할 수 있게 되었고, 변경 이력은 감사와 온보딩에 도움을 준다. 이로 인해 운영 안정성과 신규 팀원의 빠른 적응이 크게 향상되었다.
AI 에이전트 도입—자연어에서 코드로, 인프라 운영의 Self-Service 강화. OpenTofu 저장소를 MCP 기반 AI 에이전트에 연결해 Slack에서 자연어 요청을 받으면 기존 코드 패턴을 참조해 Terragrunt 코드를 생성하고 PR을 자동으로 생성한다. 계획 결과가 PR에 첨부되어 리뷰를 거치면 배포가 자동으로 수행되므로 반복 작업의 부담이 줄고 운영 속도가 높아진다. 모니터링 알람 구성도 에이전트가 코드로 자동 생성 가능하며, 온보딩과 협업이 더욱 원활해진다.
용어 해설
- OpenTofu
- — OpenTofu는 Terraform의 오픈소스 포크로, 기존 Terraform 구문(HCL)을 유지하면서 오픈 소스 라이선스로 제공되어 기존 모듈과 프로바이더 구조를 재활용할 수 있게 한다. 이를 통해 인프라 구성을 코드로 선언하고 재사용 가능한 모듈 단위로 관리하는 데 초점을 맞춘다.
- Terragrunt
- — Terragrunt는 OpenTofu/Terraform 환경에서 중복 구성을 줄이기 위한 래퍼 도구로, 상위 루트에 공통 설정을 두고 환경별 차이만 Inputs로 남겨 DRY 원칙을 적용하게 한다.
- Verda
- — Verda는 LY Corporation의 내부 클라우드 플랫폼으로 VM/LB/DNS 등 인프라 자원을 코드로 관리하는 서비스다. 이를 통해 리소스 관리의 일관성과 자동화를 추진한다.
- IMON
- — IMON은 LY의 내부 모니터링 도구로, 알림 규칙과 모니터링 구성을 코드로 관리하는 파이프라인의 일부로 사용된다.
- GitOps
- — GitOps는 인프라를 코드로 선언하고 Git을 단일 진실 소스로 삼아 변경 관리와 자동 배포를 수행하는 운영 철학이다.
기술
- OpenTofu
- Terragrunt
- Verda
- IMON
- Kubernetes
- GitHub
- Slack
활용 사례
- IaC 도입으로의 전환
- GitOps 파이프라인 구축
- Drift 자동 탐지
- 모니터링을 코드로 관리
- AI 에이전트 기반 인프라 자동화
AI 분석 전체 내용 보기
AI 요약 · 북마크 · 개인 피드 설정 — 무료
출처 · 인용 안내
원문 발행 2026. 06. 22.수집 2026. 06. 22.출처 타입 RSS
인용 시 "요약 출처: AI Trends (aitrends.kr)"를 표기하고, 사실 확인은 원문 보기 기준으로 진행해 주세요. 자세한 기준은 운영 정책을 참고해 주세요.
