실제 계정, 실제 사고, 실제 조사 결과에 대한 실습 현장 보고서 — 에이전트가 틀린 두 가지 사항을 포함하여 CloudWatch를 기준으로 주장 하나하나를 검증합니다.

목차

1. 왜 또 다른 DevOps Agent 포스팅인가
2. AWS DevOps Agent의 실체
3. 필요한 다섯 가지 명사: Agent Space, Topology, Skills, Journal, Goal
4. 사용 전 예측 가능한 가격 책정
5. 실험실: 진단 가능한 방식으로 고장 나도록 설계된 서버리스 주문 API
6. 20분 만에 온보딩하기 — 그리고 발목을 잡는 네 가지 요소
7. 에이전트에 알람 연결하기: 두 가지 경로와 선택 방법
8. 의도적으로 운영 환경(Production) 망가뜨리기: 분 단위 사고 기록
9. 증거 체인: 에이전트가 실제로 활용할 수 있는 것들
10. 에이전트에게 질문하기 — 그리고 답변을 거부한 순간
11. 조사 내용, 주장별 검증
12. 두 번째 근본 원인(Root Cause), 그리고 그것이 증명하는 것
13. 에이전트의 마음 읽기: API를 통한 감사 저널(Audit Journal)
14. 문제 해결 및 예방 조치가 제공해야 할 것
15. 루프 닫기: EventBridge, 티켓, Slack, 그리고 Kiro로의 인계
16. 에이전트를 자신만의 것으로 만들기: Skills, Instructions, Triggers, 커스텀 SRE 에이전트
17. 비용 및 환경 삭제 방법
18. 솔직한 성적표
19. 부록: 복사해서 붙여넣는 체크리스트

1. 왜 또 다른 DevOps Agent 포스팅인가

AWS DevOps Agent에 관한 대부분의 포스트는 동일한 흐름을 따릅니다. "MTTR(평균 복구 시간)을 최대 75%까지 낮춘다"는 수치를 인용하고, 아키텍처 다이어그램을 붙여넣고, 근본 원인 분석(Root Cause Analysis) 스크린샷을 보여준 뒤, 온콜(On-call) 문제가 해결되었다고 결론을 내립니다.

예외적인 사례들이 있습니다. AWS의 Networking & Content Delivery 및 Security 블로그에는 고장 난 워크로드(workload)를 배포하고, CloudWatch 알람을 에이전트(agent)에 연결하며, 실제 시나리오를 단계별로 진행하는 진정으로 훌륭한 가이드가 있습니다. 제가 이 경로를 가장 먼저 발견한 척하기보다는, §7에서 이들을 참조하겠습니다.

하지만 이 블로그들은 모두 외부에서 내부로(outside in) 작성되었습니다. 즉, '여기에 기능이 있고, 이렇게 작동한다'는 식입니다. 이 포스트는 내부에서 외부로(inside out) 작성되었습니다. 즉, 해당 기능을 평가하라는 요청을 받은 월요일 오전 9시에 여러분이 실제로 갖게 될 질문들에 대해 다룹니다:

• 온보딩(onboarding) 과정 중 무엇이 고장 나는가?
• 내 알람은 CloudWatch 알람이다. 이것들이 어떻게 에이전트에 도달하는가? (네이티브 트리거(native trigger)는 없다. AWS는 두 가지 서로 다른 브리지(bridge)에 대한 샘플을 제공하며, 이들은 동일하지 않다 — §7.)
• 이것이 실제로 작동하고 있는지, 아니면 그냥 가만히 있는 것인지 어떻게 알 수 있는가?
• 장애당 비용은 달러로 얼마인가?
• 근본 원인 분석(Root Cause Analysis)이 틀렸을 때, 어떻게 알 수 있는가?

마지막 질문이 바로 이 포스트가 존재하는 이유입니다. 저는 한 가지 이상의 그럴듯한 원인으로 실패하도록 설계된 애플리케이션을 구축했고, 이를 고장 낸 뒤 에이전트에게 그 여파를 넘겨주고 에이전트가 생성한 모든 수치를 CloudWatch와 대조하며 확인했습니다. 에이전트는 결론은 맞혔지만 두 가지 메커니즘 세부 사항은 틀렸습니다. 그리고 그 틀린 두 가지 중 하나는 엔지니어가 존재하지 않는 설정값을 찾으러 다니게 만들었을 것입니다.

아래의 모든 내용은 2026년 7월 31일 us-west-2 리전의 실제 AWS 계정에서 가져온 것입니다. 모든 타임스탬프(timestamp), 용량 수치 및 에러 카운트는 CloudWatch 또는 에이전트 자체 출력에서 복사되었습니다. 어떤 것도 재구성하거나 예시로 만든 것이 아닙니다. 계정 ID(Account ID), 에이전트 스페이스 ID(Agent Space ID) 및 API ID는 <account-id>와 <agentSpaceId>로 가려졌으며, 그 외의 모든 것은 원문 그대로입니다.

2. AWS DevOps Agent의 실체

AWS DevOps Agent는 re:Invent 2025에서 발표된 프리뷰(preview)를 거쳐 2026년 3월 31일에 정식 출시(GA)되었습니다. 이는 Kiro 및 보안 테스트 에이전트(security testing agent)를 포함하는 AWS의 "프런티어 에이전트(frontier agents)" 제품군 중 하나로, 단순히 모델을 얇게 감싼 래퍼(wrapper)가 아니라 메모리(memory), 정책(policies), 평가(evaluations) 및 관찰성(observability)을 위한 전용 인프라를 갖춘 Amazon Bedrock AgentCore를 기반으로 구축되었습니다.

이 에이전트는 두 부분으로 나뉩니다.

운영 환경(Production operations) (GA). 이것이 오늘 여러분이 주목해야 할 부분입니다.

릴리스 관리 (Release management) (프리뷰, us-east-1 전용). 릴리스 준비 상태 검토(Release readiness review) 및 자율 릴리스 테스트(autonomous release testing)를 수행합니다. 머지(merge) 전에 변경 사항의 영향 범위(blast radius)와 권한 확장(permission expansion)을 검토한 다음, 정적 테스트 세트(static suite)를 실행하는 대신 변경 사항에 특화된 테스트를 생성합니다. 프리뷰 기간 동안은 무료입니다. 진정으로 흥미로운 기능이지만, 별도로 평가해야 합니다: 리전(region)이 다르고 성숙도(maturity)가 다릅니다.

실행 위치. 이 글을 쓰는 시점을 기준으로 11개 리전에서 실행됩니다: us-east-1, us-west-2, ca-central-1, sa-east-1, ap-south-1, ap-southeast-1, ap-southeast-2, ap-northeast-1, eu-central-1, eu-west-1, eu-west-2.

사람들이 놓치는 부분: 에이전트 스페이스(Agent Space)는 에이전트 스페이스 자체가 위치한 곳과 관계없이, 연결된 계정의 어느 리전에 있는 리소스든 모니터링합니다. 에이전트 스페이스 리전은 워크로드(workload)와 맞추기 위해서가 아니라, 데이터 거주성(data residency)과 팀의 물리적 근접성을 고려하여 선택합니다. 리전마다 하나씩 가질 필요는 없습니다.

기존에 보유한 것들과의 차이점

• vs. Amazon DevOps Guru — DevOps Guru는 머신러닝 (ML) 이상 탐지 (anomaly detection) 도구입니다. 지표 (metrics), 로그 (logs), 이벤트 (events), 트레이스 (traces)로부터 정상적인 운영 범위를 학습한 다음, 편차를 식별하고 이를 인사이트 (insights)로 집계합니다. 반면 DevOps Agent는 '조사 (investigation)'를 수행합니다. 가설을 세우고, 이를 검증하기 위해 로그, 코드, 배포 이력을 쿼리(query)하며, 완화 계획 (mitigation plan)이 포함된 결론을 작성합니다. 탐지 (detection) 대 진단 (diagnosis)의 차이입니다. 역할이 다르며, 이름에서 암시하는 것보다 중첩되는 부분이 적습니다.
• vs. 코딩 에이전트 (coding agent) + CloudWatch MCP 서버 — 솔직한 비교를 하자면, 정답은 '컨텍스트 (context)와 거버넌스 (governance)'입니다. 코딩 에이전트에 연결만 해준다면 CloudWatch를 쿼리할 수 있습니다. 하지만 코딩 에이전트가 할 수 없는 일은, 지속적으로 갱신되는 교차 계정 토폴로지 (cross-account topology)를 유지하거나, 엔지니어별 개별 설정 없이 팀 전체와 이를 공유하거나, 에이전트가 접근할 수 있는 범위에 대해 IAM 경계 (IAM boundaries)를 강제하거나, 모든 추론 단계에 대해 변경 불가능한 감사 저널 (immutable audit journal)을 유지하는 것입니다. §12는 이것이 왜 중요한지에 대한 구체적인 예시입니다.
• vs. SRE — 대체제가 아닙니다. 잠들지 않는 매우 빠른 초동 조치자 (first responder)이며, 여전히 사용자가 확인해야 하는 존재입니다. §11.

3. 반드시 알아야 할 다섯 가지 명사

이 개념들을 건너뛴다면 문서가 안개 속처럼 느껴질 것입니다.

에이전트 공간 (Agent Space) — 에이전트가 볼 수 있는 범위(어떤 AWS 계정, 어떤 서드파티 도구, 어떤 MCP 서버, 어떤 사용자)를 정의하는 논리적 컨테이너입니다. 격리 (Isolation)는 실제로 구현됩니다. 전용 IAM 역할 (IAM roles)을 통한 AWS 계정 격리, 사용자 액세스 격리, 그리고 데이터 격리가 이루어집니다. 즉, 조사 내용, 채팅 이력, 권장 사항이 공간 간에 유출되지 않습니다. 운영 환경 (prod) 대 비운영 환경 (non-prod), 또는 비즈니스 단위별로 별도의 공간을 사용하십시오.

토폴로지(Topology) — 리소스와 그 관계를 자동 발견한 지도입니다. 백그라운드 학습 에이전트가 인프라, 원격 측정 데이터(telemetry), 코드를 스캔하여 애플리케이션 및 서비스 경계를 추론합니다. 제 계정에서는 CloudFormation 스택 경계만으로 리소스를 애플리케이션별로 정확하게 그룹화했고, CDKToolkit과 aws-sam-cli-managed-default를 스캐폴딩(scaffolding)으로 명시적으로 제외했습니다. 이것이

한 달에 10회의 조사를 수행하는 소규모 팀: 약 $40. 80회의 조사와 100회의 채팅을 수행하는 활발한 팀: 약 $344. AWS 자체 예시에 따른 엔터프라이즈 규모: 약 $2,366.

공짜 돈(Free money), 중요도가 높은 순서대로:

1. AWS Support 크레딧 (AWS Support credits). 유료 지원 플랜을 사용하는 경우, 전월 지원 요금의 일정 비율만큼 매월 DevOps Agent 크레딧을 받습니다: Unified Operations는 100%, Enterprise는 75%, Business Support+는 **30%**입니다. 크레딧은 10일까지 발행되며 해당 월 내에 적용되고, 월말에 만료됩니다. 많은 Enterprise Support 고객들에게 이는 DevOps Agent를 사실상 무료로 만들어 줍니다. 처음부터 비즈니스 케이스를 구축하기 전에 이 부분을 먼저 확인하십시오.
2. 신규 고객을 위한 2개월 무료 체험 (Two-month free trial): 첫 운영 작업(operational task) 시작 시점부터 적용됩니다. 체험 기간 동안 매월 최대 10개의 에이전트 공간(agent spaces), 20시간의 조사(investigations), 15시간의 평가(evaluations), 20시간의 온디맨드 작업(on-demand tasks)이 제공됩니다.
3. 신규 AWS 고객을 위한 AWS 프리 티어 (AWS Free Tier) 무료 플랜에 포함되어 있습니다.
4. 릴리스 관리(Release management)는 프리뷰(preview) 기간 동안 무료입니다.

가격 페이지에 나와 있지 않은 비용: 에이전트가 대리인으로서 귀하의 CloudWatch 요금을 발생시킵니다. 에이전트가 실행하는 모든 Logs Insights 쿼리 및 트레이스 검색(trace retrieval)은 CloudWatch 표준 요율에 따라 청구됩니다. 로그 그룹의 채팅(log) 양이 많다면 이는 무시할 수 없는 금액입니다. 이에 대한 예산을 책정하십시오.

언제든지 자신의 사용량을 확인할 수 있습니다:

aws devops-agent get-account-usage --region us-west-2

{
  "monthlyAccountInvestigationHours":   { "limit": -1, "usage": 0.0 },
  "monthlyAccountEvaluationHours":      { "limit": -1, "usage": 0.0 },
...

limit: -1은 설정된 상한선(cap)이 없음을 의미합니다. 네 번째 카테고리에 주의하십시오: 시스템 학습 시간(system learning hours)은 별도로 측정되며, 백그라운드 학습 에이전트는 인시던트(incident) 발생 여부와 관계없이 실행됩니다.

이 포스트의 실제 측정 비용

§10의 채팅 세션과 §11의 조사를 마친 후의 실제 측정값은 다음과 같습니다:

그 결과 중 두 가지가 저를 놀라게 했으며, 이 두 가지는 모두 계획 단계에서 고려할 가치가 있습니다.

대화 비용이 조사 비용보다 3.3배 더 많이 들었습니다. AWS를 포함한 모든 가격 책정 예시는 조사를 과금 단위 (billable unit)로 하여 구성되어 있습니다. 실제로 이번 조사는 3.2분 동안 실행되어 가격 페이지에서 사용하는 8분이라는 수치보다 훨씬 적게 걸린 반면, 조사에 이르기까지 거친 몇 차례의 채팅 턴 (chat turns)은 10.5분의 에이전트 시간을 소모했습니다. 각 답변이 빠르기 때문에 채팅은 무료처럼 느껴지지만, 실제로는 그렇지 않으며 조용히 누적됩니다. 만약 이를 팀 단위로 도입한다면, 당신을 놀라게 할 항목은 조사 비용이 아니라 monthlyAccountOnDemandHours가 될 것입니다.

조사 비용이 예산보다 저렴할 수 있습니다. 3.2분 동안 진행된 이번 조사는 커피 한 잔 값보다 적게 들었으며, 4개의 서비스를 연관시키고 두 가지 원인이 얽힌 장애 체인 (failure chain)을 재구성했습니다 (§11). 만약 비용 문제로 조사를 망설이고 있다면, 실제 수치는 당신의 직감보다 아마 더 낮을 것입니다.

사용량을 확인하는 데 있어 한 가지 주의할 점은, 사용량은 달력 기준 월 단위로 초기화되며 usagePeriodStartTime이 당신이 보고 있는 기간을 알려준다는 것입니다. 저의 장애 상황은 UTC 기준 7월 31일 늦은 시간에 발생했고 조사는 8월 1일에 이루어졌기 때문에, 두 항목은 서로 다른 청구 기간에 나타났습니다. 만약 한 쪽만 확인한다면