장애(Incident) 상황에서 가장 힘든 부분은 대개 문제를 해결하는 것이 아니라, 수십 개의 도구에 흩어진 정보를 모아 도대체 무슨 일이 일어나고 있는지 파악하기 위해 허둥대는 과정입니다. 이것이 바로 AWS DevOps Agent가 메우고자 하는 격차이며, 여러분은 이미 AWS DevOps Agent가 해결하려는 문제가 무엇인지 이해하고 있습니다. AWS DevOps Agent는 운영을 위한 AWS의 자율 에이전트(Autonomous Agent)입니다. 장애가 발생하는 즉시 조사하고, 인프라를 충분히 학습하여 영향 범위(Blast Radius)를 추론하며, Slack이나 Jira와 같이 팀이 이미 사용 중인 도구들과 연결됩니다.

이 포스트에서는 직접 실습을 진행하며, 에이전트를 구축하고 온디맨드(On-demand) 및 자동 방식으로 조사를 수행하는 방법을 알아봅니다.

AWS DevOps Agent의 기초

AWS DevOps Agent가 수행하는 모든 작업은 Agent Space라고 불리는 컨테이너 내부에서 이루어집니다. Agent Space는 에이전트가 접근할 수 있는 AWS 계정, 통합(Integration), 사용자를 정확하게 정의하는 경계(Boundary)입니다. 이 경계를 이해하는 것이 가장 먼저 해야 할 일인데, 왜냐하면 이것이 제품의 나머지 기능이 구축되는 보안 모델(Security Model)이기 때문입니다.

이 경계 위에는 의도적으로 분리된 인터페이스가 존재합니다:

• 관리자용(For Administrators): 콘솔 또는 IaC를 통해 에이전트 설정을 수행합니다.
• 사용자용(For users): 조사 내용을 확인하고, 보고서를 생성하며, 맞춤형 에이전트를 생성하는 웹 앱(Web App)입니다.

AWS DevOps Agent 설정하기

첫 번째 Agent Space를 실행하는 과정은 다음 세 단계로 요약됩니다:

1. AWS Management Console에서 Agent Space 생성 — AWS Console → AWS DevOps Agent → Create Agent Space로 이동합니다. 또한 CLI, IaC(CloudFormation, Terraform)를 통해 DevOps 에이전트를 생성할 수도 있습니다.

에이전트 공간 (Agent Space)을 생성할 때 다음 사항을 명시해야 합니다:

- 이름 (Name): 귀하의 명명 규칙 (Naming convention)에 따라 지정
- 에이전트 공간용 IAM 역할 (IAM Role for Agent Space): 에이전트 공간이 AWS 리소스에 접근하는 데 사용하는 IAM 역할입니다. 이 블로그에서는 기본값 (Default)을 사용하겠습니다.
- DevOps 에이전트 웹앱용 IAM 역할 (IAM Role for DevOps Agent WebApp): 웹앱 (WebApp)이 에이전트 공간에 접근하는 데 사용하는 IAM 역할입니다.
- 암호화 키 (Encryption Key): AWS 관리형 키 또는 고객 관리형 키 (CMK). 생성 시에만 지정할 수 있으며, 나중에 구성할 수 없습니다.

데모 또는 테스트 환경의 경우, 기본 IAM 역할을 사용하십시오. AWS 관리형 AIDevOpsAgentAccessPolicy는 별도의 추가 설정 없이 즉시 읽기 전용 (Read-only) 권한을 제공합니다. 프로덕션 (Production) 환경에서는 이를 그대로 사용하지 마십시오. 테스트 환경의 조사 (Investigation) 과정에서 실제로 어떤 추가 권한을 요청하는지 모니터링한 후, 해당 권한들만 커스텀 역할 (Custom role)에 범위가 제한된 인라인 정책 (Scoped inline policies)으로 추가하십시오. 즉, 계정 전체가 아닌 리소스 단위로 제한(Resource-restricted)해야 합니다.

모든 필드 입력을 마쳤다면, 생성 (Create)을 누르십시오.

DevOps 에이전트 웹앱 접속하기

에이전트가 생성되면, 액세스 (Access) 탭에서 접속할 수 있습니다:

DevOps 에이전트는 다음과 같은 항목과 통합할 수 있습니다:

• 커뮤니케이션 채널 (Communication channel) - Slack, PagerDuty, ServiceNow
• 텔레메트리 도구 (Telemetry tools) - DataDog, NewRelic, Splunk, Grafana, Dynatrace
• 소스 코드 (Source code) - Github, Gitlab, AzureDevOps
• 제3자 MCP 서버 (3rd party MCP servers) 추가, A2A를 지원하는 원격 에이전트 (Remote agent)
• 웹훅 (Webhooks)

이러한 통합에 대한 자세한 내용은 다음 블로그에서 다루겠습니다.

온디맨드 조사 (On-Demand Investigation)

에이전트 공간 웹앱의 인시던트 대응 (Incident Response) 탭에서 언제든지 수동으로 조사를 시작할 수 있습니다. 조사하고자 하는 내용을 자유 형식의 텍스트 (Free-form text)로 설명하거나, 미리 구성된 세 가지 시작점 중 하나를 선택하여 시작할 수 있습니다:

• 최신 알람 (Latest alarm): 가장 최근에 트리거된 알람을 조사하며, 근본 원인 (Root cause)을 파악하기 위해 기반이 되는 메트릭 (Metrics) 및 로그 (Logs)를 분석합니다.
• AWS 플랫폼 상태 (AWS Platform health): AWS 측에서 계획된 변경 사항이 있는지 조사합니다.

저는 Check for stale/unused resources라는 프롬프트 (Prompt)를 사용했는데, 유휴 리소스 (Idle resources)에 대한 훌륭한 요약 정보를 반환해 줍니다.

데모 #1 : EC2 알람 조사

이 데모의 일부로 EC2 인스턴스를 생성하고, 의도적으로 CPU를 급증시키는 프로세스(stress-ng 사용)를 실행했습니다. DevOps 에이전트가 이를 조사할 수 있는지 확인해 보겠습니다.

위에서 볼 수 있듯이 DevOps 에이전트는 이것이 의도적인 CPU 급증이었음을 감지할 수 있습니다. 에이전트는 메트릭 (Metrics)과 CloudTrail 로그에 접근하고 이를 상호 연관 (Co-relating)함으로써 이 작업을 수행합니다. 장애 조사 (Incident investigation)의 근본 원인 (Root cause) 탭 아래에서 조사 과정의 공백 (Gaps)이 무엇인지 확인할 수 있습니다. 이 예시에서는 EC2에 대한 CloudWatch 로그가 없었기 때문에, DevOps 에이전트가 CPU 급증의 정확한 프로세스를 감지할 수 없었다는 점이 공백이었습니다.

자동화된 조사 (Automated Investigation)

누군가 문제를 인지하고 수동으로 조사를 시작하기를 기다리는 대신, AWS DevOps Agent는 무언가 발생(fire)하는 즉시 스스로 조사를 시작할 수 있습니다. 따라서 사후 대응적 (reactive) 접근 방식 대신, 선제적 (pro-active) 접근 방식을 취해 보겠습니다.

현재 CloudWatch 알람(alarm)의 액션(action) 대상으로 AWS DevOps Agent를 직접 지정할 수는 없습니다. 따라서 여기서는 약간의 트릭을 사용하여 Lambda를 대상으로 사용하겠습니다. 아래에 우리가 구성할 흐름을 확인해 주세요.

웹훅 통합 (Webhook Integration) - DevOps Agent

일반적인 웹훅 (generic webhook)을 구성하려면 다음 단계를 따르세요.

1. Agent Space → Capabilities 탭 → Webhook 섹션 → Configure로 이동합니다.

1. Generic webhooks: 'Generate webhook'을 선택한 다음, 인증 유형(auth type)을 선택합니다. HMAC (각 요청에 서명하며, x-amzn-event-signature 헤더를 통해 검증됨) 또는 API key (Authorization: Bearer 로 전송됨) 중에서 선택할 수 있습니다. 저는 HMAC 인증을 사용하겠습니다.

1. 엔드포인트(endpoint) URL을 복사하고 비밀키(secret/key)를 안전하게 보관하세요. 이는 한 번만 표시되며 다시 가져올 수 없습니다. 우리는 이를 Lambda의 일부로 구성할 것입니다.

Lambda 구성하기

다음 단계는 CloudWatch 알람으로부터 페이로드 (payload)를 읽어 AWS DevOps Agent로 전송하는 것입니다. 아래의 Lambda 코드 부분은 페이로드를 생성하고 이를 DevOps Agent로 전송하는 과정을 보여줍니다.

• Lambda를 위해 DEVOPS_AGENT_WEBHOOK_SECRET, DEVOPS_AGENT_WEBHOOK_URL 및 SERVICE_NAME이라는 3개의 환경 변수 (environment variables)를 설정했습니다.
• IAM 권한 (IAM Permission): AWS 관리형 권한인 AWSLambdaBasicExecutionRole을 사용합니다.

주의사항: DEVOPS_AGENT_WEBHOOK_SECRET을 환경 변수로라도 하드코딩(hard code)하는 것은 권장되지 않습니다. SSM Parameter Secure String 또는 Secrets Manager를 사용하고, SSM의 경로를 환경 변수로 설정해야 합니다.

def _build_payload(event):
    alarm_data = event.get("alarmData", {})
    alarm_name = alarm_data.get("alarmName", "Unknown Alarm")
...

CloudWatch Alarm 액션 설정 (Configure CloudWatch Alarm Action)

AWS Lambda가 준비되면, 액션 (action)이 포함된 기존 CloudWatch 알람을 편집할 수 있습니다.

데모 2: 자동 조사 (DEMO 2: Automated Investigation)

저는 CloudFront 뒤에 Webapp-URL-shortener를 배치했습니다. 이 웹앱의 일부로서 Lambda가 요청을 처리하는데, 이 앱에 의도적인 장애를 발생시키기 위해 Lambda의 동시성 (concurrency)을 0으로 설정했습니다. 이렇게 하면 Lambda 실행이 비활성화되어 CloudFront에서 5xx 에러가 발생합니다.

웹사이트에서 5xx 에러가 발생할 때 트리거되는 CloudFront5xx 알람을 생성했습니다.

아래 스크린샷을 보면, 알람이 트리거될 때 해당 Lambda가 DevOps Agent로 페이로드 (payload)를 전송하는 것을 볼 수 있습니다.

AWS DevOps Agent Space에서 추가로 확인해 보면, Agent가 조사를 시작한 것을 볼 수 있습니다. DevOps Agent 웹앱을 열고 인시던트 (Incident) 항목 아래에서 조사가 시작되었음을 확인할 수 있습니다.

또한 타임라인 (timeline)을 통해 DevOps Agent가 어떻게 조사에 접근했는지 확인할 수 있습니다. 예: