Level 300

인프라 성숙도 문제

인프라 라이프사이클 관리 (Infrastructure Lifecycle Management, ILM)를 위한 업계 표준 성숙도 모델 — "클라우드 성공을 위한 엔터프라이즈 청사진 (Enterprise Blueprint for Cloud Success)"으로 널리 알려진 — 은 Day 0 / Day 1 / Day 2+ 운영 모델에 걸쳐 세 가지 도입 단계를 정의합니다:

단계	중점 사항	Day 0 (Build)	Day 1 (Deploy)	Day 2+ (Manage)
1. 도입 (Adopting)	IaC를 통한 개별 팀의 프로비저닝	인프라 코드 작성, 에이전트 템플릿 + Kiro IDE를 통한 스캐폴딩, VCS를 통한 협업	CLI/CI를 통한 프로비저닝	수동 모니터링
...

이 모델은 수천 개의 조직이 수동 프로비저닝에서 셀프 서비스 플랫폼으로 나아갈 수 있도록 안내해 왔습니다. 그러나 실제로 업계의 대부분의 엔터프라이즈 팀은 3단계에서 한계에 부딪힙니다. 운영은 여전히 반응적(reactive)입니다. 보안 탐지 결과는 대시보드에 쌓이고, 드리프트(drift)는 다음 감사 전까지 감지되지 않으며, 비용 이상 징후는 피해가 발생한 지 몇 주 후에나 나타나고, 사고 대응은 VPC가 어떻게 구성되었는지 기억하는 단 한 명의 엔지니어에게 의존합니다.

누락된 단계는 자율(Autonomous) 단계입니다 — 이 단계에서는 AI 에이전트가 인프라 결정을 내리고, 티켓 없이 탐지 결과를 수정하며, 사고가 발생하기 전에 이를 방지합니다.

이 포스트는 AWS AI 에이전트 서비스(Continuum, DevOps Agent, FinOps Agent)를 ThothCTL 프레임워크와 결합하여, 셀프 서비스를 넘어 자율 운영(self-operating)으로 나아가는 폐쇄 루프(closed-loop) 인프라 라이프사이클을 구축하는 4단계 참조 아키텍처로 청사진을 확장합니다.

아키텍처 개요

확장된 청사진은 성숙도 모델에 네 번째 열인 **자율(Autonomous)**을 추가하여 Day 0/1/2 패턴을 이어갑니다:

AI 에이전트: 기능 및 책임

AWS Continuum (기계 속도의 보안)

AWS Continuum (2026년 6월 발표)은 사용자가 정의한 가드레일(guardrails) 내에서 발견부터 우선순위 지정, 취약점 공격 가능성 검증(exploitability validation), 그리고 조치(remediation)에 이르기까지 취약점의 전체 생명주기(full lifecycle)를 기계의 속도로 처리하는 최첨단 AI 네이티브 보안 플랫폼입니다.

기능 (Capability)	기술적 세부 사항 (Technical Detail)	트리거 (Trigger)
위협 모델링 (Threat Modeling)	설계 문서 또는 소스 코드로부터 STRIDE 위협 모델을 자동 생성	수동 / 개발 전 단계
...

"Security Agent"로부터 변경된 점: Continuum은 이전의 AWS Security Agent 기능을 흡수하고 확장합니다. 침투 테스트(Penetration testing)와 코드 스캐닝(code scanning)은 유지되지만(현재 "Continuum 침투 테스트" 및 "Continuum 코드 스캐닝"으로 명칭 변경), 핵심적인 추가 사항은 **폐쇄 루프 취약점 생명주기(closed-loop vulnerability lifecycle)**입니다. Continuum은 단순히 취약점을 찾는 것에 그치지 않고, 우선순위를 정하고, 공격 가능성을 증명하며, 롤백 안전성(rollback safety)을 보장하며 조치합니다.

주요 아키텍처 결정 사항: Continuum은 애플리케이션 코드(application code) 계층(Python, Java, Node.js)에서 작동합니다. 인프라 코드(infrastructure code)(Terraform, HCL)의 경우, Terraform 리소스 의미론(semantics)을 이해하는 보완적인 IaC 전용 스캐너(Checkov, Trivy, KICS, OPA)가 필요합니다. Continuum은 Lambda 핸들러에서의 SQL 인젝션(SQL injection)은 잡아내지만, HCL에서 암호화가 누락된 S3 버킷을 플래그(flag)로 표시하지는 않습니다. 두 계층이 모두 필요합니다.

4단계(Stage 4)와의 부합성: Continuum은 보안 팀의 역할을 수동 분류(manual triage)에서 방향 설정 및 결과 승인으로 전환합니다. 인간은 가드레일(승인된 라이브러리, 암호화 요구 사항, 심각도 임계값)을 정의하고, Continuum은 해당 경계 내에서 자율적으로 작동합니다. 이는 당사의 성숙도 모델(maturity model) 중 "자가 치유(self-heal)" 열과 직접적으로 매핑됩니다.

⚠️ 가용성(Availability): 코드 취약점용 AWS Continuum은 제한적 프리뷰(gated preview) 상태입니다 (2026년 6월). 위협 모델링은 프리뷰 단계입니다. GuardDuty 및 Security Hub와 함께 작동합니다.

AWS DevOps Agent

AWS DevOps Agent는 릴리스 관리(release management)(프리뷰)와 운영(production operations)(GA)을 아우릅니다.

기능 (Capability)	기술적 세부 사항 (Technical Detail)	통합 (Integration)
릴리스 준비 검토 (Release Readiness Review)	프로덕션 요구 사항, 종속성 안전성, 사용자 정의 표준에 따라 코드를 평가	CI/CD 파이프라인
...
통합 방법 (Integration methods) (아키텍처에 매우 중요):

• MCP (Model Context Protocol) — 외부 도구 서버 등록 (Streamable HTTP + OAuth/SigV4)
• 웹훅 (Webhooks) — 모니터링 도구로부터의 HMAC 또는 Bearer 토큰
• 에이전트 클라이언트 프로토콜 (Agent Client Protocol) — 프로그래밍 방식의 호출
• CI/CD — GitHub/GitLab 네이티브 통합

핵심 아키텍처 통찰 (Key architectural insight): DevOps 에이전트는 커스텀 MCP 서버 (custom MCP servers) 등록을 지원합니다. 이는 MCP를 준수하는 엔드포인트를 노출하는 모든 도구가 장애 조사(incident investigation) 또는 릴리스 검증(release validation) 중에 호출될 수 있음을 의미합니다. 저희 프로젝트에서는 내부 ThothCTL MCP 서버를 등록하여, DevOps 에이전트가 장애 분류(incident triage) 중에 IaC 드리프트(drift) 상태와 모듈 인벤토리를 조회할 수 있도록 했습니다. 이를 통해 온콜(on-call) 엔지니어의 컨텍스트 스위칭(context-switching)을 줄였습니다.

⚠️ 가용성 참고 사항 (Availability Note): AWS DevOps Agent 릴리스 관리(Release Management)는 프리뷰(preview) 단계입니다 (2026년 6월 기준 us-east-1, us-west-2). 장애 조사(Incident Investigation)는 10개 이상의 리전에서 GA(General Availability) 상태입니다. AWS Continuum은 제한적 프리뷰(gated preview) 단계입니다 (2026년 6월). 현재 상태는 AWS Regional Services에서 확인하십시오.

AWS FinOps 에이전트 (AWS FinOps Agent)

AWS FinOps 에이전트 (퍼블릭 프리뷰, 2026년 6월)는 비용 이상 현상을 조사하고, 자연어로 비용 관련 질문에 답하며, 반복적인 FinOps 워크플로우를 자율적으로 실행하는 **클라우드 재무 관리를 위한 프런티어 AI 에이전트 (frontier AI agent for cloud financial management)**입니다.

기능 (Capability)	기술적 세부 사항 (Technical Detail)	트리거 (Trigger)
비용 이상 현상 조사 (Cost Anomaly Investigation)	비용 급증을 CloudTrail 이벤트와 상관 분석 → 근본 원인 + 책임 소유자 식별	이벤트 트리거 (비용 이상 탐지 (Cost Anomaly Detection))
...
통합 방법 (Integration methods):

• Jira — 조사 결과가 포함된 티켓을 생성하여 리소스 소유자에게 전달
• Slack — 팀 채널에 이상 징후 요약본 게시
• AWS Management Console — 대화형 UI(Conversational UI)를 갖춘 웹 애플리케이션

핵심 아키텍처 통찰 (Key architectural insight): 사후 대응적인 월간 검토 방식의 수동 FinOps 패턴과 달리, FinOps 에이전트(FinOps Agent)는 지속적으로 실행됩니다. 각 팀과 관련된 특정 달러 임계값 이상의 이상 징후만 조사하도록 구성하여, 경고 피로(Alert fatigue)를 줄이는 동시에 영향력이 큰 변경 사항을 몇 주가 아닌 몇 시간 내에 포착할 수 있도록 합니다.

⚠️ 가용성 (Availability): AWS FinOps Agent는 us-east-1 리전에서만 퍼블릭 프리뷰 (public preview) 상태입니다 (2026년 6월 기준). 모든 상용 리전의 비용 데이터를 관리합니다. 프리뷰 기간 동안에는 월간 사용량 제한 내에서 무료로 제공됩니다.

우리는 ThothCTL의 비용 분석을 **배포 전 예산 게이트 (pre-deploy budget gate)**로서 CI/CD 파이프라인에 직접 통합합니다. (배포 후 이상 징후를 조사하는) FinOps Agent와 달리, 이 게이트는 예산을 초과하는 배포가 프로덕션 환경에 도달하는 것을 **방지 (prevents)**합니다. ThothCTL은 Terraform 플랜(plans)과 CloudFormation 템플릿을 오프라인에서 모두 분석하며, 추정치를 위해 AWS 자격 증명(credentials)이 필요하지 않으므로 모든 파이프라인 단계에서 안전하게 실행할 수 있습니다:

# 배포 전 비용 추정 — Terraform 플랜 및 CloudFormation 템플릿 모두 지원
tofu plan -out=tfplan && tofu show -json tfplan > tfplan.json

...

통합된 의사결정 흐름 (The Unified Decision Flow)

에이전트들이 하나의 자동화된 파이프라인으로 구성되는 지점은 다음과 같습니다:

우리는 단일 에이전트가 전체 라이프사이클을 소유할 수 없다는 점을 배웠습니다. 보안 에이전트(Security Agent)는 IaC(Infrastructure as Code)의 의미론(semantics)을 이해하지 못하고, DevOps 에이전트(DevOps Agent)는 모듈 인벤토리를 알지 못하며, FinOps 에이전트(FinOps Agent)는 영향 범위(blast radius)를 평가할 수 없습니다. 돌파구는 MCP를 통해 이들을 **조합(composing)**하는 데서 나옵니다. ThothCTL의 의사결정 엔진이 오케스트레이션 지점(orchestration point)이 되어 모든 소스로부터 신호를 집계하고, PR(Pull Request)당 하나의 감사 가능한(auditable) 의사결정을 생성합니다. 인간은 임계값을 설정하며, 시스템은 그 임계값 내에서 기계의 속도로 작동합니다.

통합 계층으로서의 MCP (MCP as the Integration Layer)

여러 에이전트를 조합하기 위한 아키텍처의 핵심은 **MCP (Model Context Protocol)**입니다. AWS DevOps Agent와 IaC 도구 모두 MCP 인터페이스를 노출하거나 소비할 수 있습니다:

책임 경계 매트릭스 (Responsibility Boundary Matrix)

명확한 경계는 에이전트 간의 중복을 방지하고 에스컬레이션 경로(escalation paths)를 정의합니다:

생명주기 단계 (Lifecycle Phase)	IaC Security Scanner	AWS Continuum	AWS DevOps Agent	AWS FinOps Agent
설계 (Design)	—	STRIDE 위협 모델 (문서/코드로부터 자동 생성)	—	—
...
핵심 통찰 (Key insight): IaC 스캐닝과 Continuum 사이에는 중복이 없습니다. 이들은 서로 다른 코드 계층에서 작동합니다. Continuum은 애플리케이션 코드에 대한 전체 취약점 생명주기를 처리하며, ThothCTL은 IaC 특화 스캐닝, 드리프트(drift) 및 PR 결정을 처리합니다. DevOps Agent는 배포 후 (post-deploy) 전문가입니다. FinOps Agent는 지속적인 비용 (continuous cost) 계층입니다. MCP는 이들이 서로를 호출할 수 있게 해주는 상호 운용성 프로토콜(interoperability protocol)입니다.

문제가 발생했을 때: 에이전트 실패 모드 (Agent Failure Modes)

자율적이라는 것이 감독이 필요 없다는 의미는 아닙니다. GFT에서는 각 에이전트의 실패 모드에 대해 명시적인 폴백 경로(fallback paths)를 설계했습니다:

실패 모드 (Failure Mode)	영향 (Impact)	폴백 전략 (Fallback Strategy)
대규모 PR에 대한 Continuum 타임아웃	PR이 검토 단계에서 멈춤	15분 타임아웃 → Checkov 전용 스캔 + 수동 검토로 폴백
...
핵심 설계 원칙 (Key design principle): 모든 자율적 행동은 감사 가능(auditable)해야 하며 되돌릴 수(reversible) 있어야 합니다. 결정 엔진은 모든 점수 계산을 로그로 남기며, thothctl ai-review history 명령어를 통해 완전한 추적성(traceability)을 제공합니다.

thothctl 프로젝트와 문서는 다음에서 찾을 수 있습니다:

thothforge / thothctl

내부 개발자 플랫폼(internal developer platform) 내에서 효율적인 관리 및 자동화를 위해 설계된 명령줄 인터페이스(CLI) 도구입니다.

Thoth Framework

Thoth Framework는 인프라, DevOps, DevSecOps, 소프트웨어 개발자 및 플랫폼 엔지니어링 팀을 위해 비즈니스 목표에 맞춰 설계된 내부 개발자 플랫폼 (Internal Developer Platform) 작업을 생성하고 관리하기 위한 프레임워크입니다:

1. 실수 최소화 (Minimize mistakes)
2. 속도 향상 (Increase velocity)
3. 제품 개선 (Improve products)
4. 컴플라이언스 준수 (Enforce compliance)
5. 종속성 감소 (Reduce lock-in)

매핑 메커니즘 (Mapping Mechanisms)

비즈니스 목표 (Business Objective)	메커니즘 (Mechanism)	구현 (Implementation)
실수 최소화 (Minimize mistakes)	의미 있는 기본값 (Meaningful defaults)	템플릿 (Templates)
...

Thoth를 사용하면 명령줄(command line)을 통해 개발자 제어 평면(Developer Control Plane)을 확장 및 운영할 수 있으며, 내부 개발자 플랫폼을 통해 개발자 경험(developer experience)을 활성화할 수 있습니다.

도구 (Tools)

ThothCTL

내부 프레임워크(Internal Frameworks)의 도입을 가속화하고, 내부 개발자 플랫폼(Internal Developer Platform)과의 재사용 및 상호작용을 가능하게 하는 패키지입니다.

사용 사례 (Use cases)