[Hands-On] AWS DevOps Agent를 활용한 CI/CD 파이프라인 자율 운영하기

안녕하세요,
클라우드 기술팀 이샘입니다.

오늘은 2026년 3월 31일 GA(정식 출시) 된 AWS DevOps Agent를 활용하여 CI/CD 파이프라인을 자율적으로 운영하고, 배포 실패가 발생했을 때 근본 원인을 자동으로 찾아내는 방법을 소개해드리겠습니다.

기존의 CI/CD 파이프라인은 “배포가 성공했는가/실패했는가”는 알려주지만, 왜 실패했는지, 어떤 커밋이 원인이었는지, 어떻게 복구해야 하는지는 사람이 직접 로그를 뒤져가며 판단해야 했습니다. AWS DevOps Agent는 이 영역을 자동화하기 위해 AWS가 새로 발표한 Frontier Agents 카테고리(DevOps Agent와 Security Agent로 시작)에 속하는 자율 에이전트로, Amazon Bedrock AgentCore 위에서 동작하며 단순한 LLM 래퍼가 아닌 운영 전담 에이전트로 설계되었습니다.

본 글에서는 특히 GitHub 기반 CI/CD 환경과의 연동에 초점을 맞추어, 코드 작성보다는 AWS 콘솔과 GitHub UI를 통해 어떻게 구성하는지 단계별로 소개해드리겠습니다.

아키텍처

DevOps Agent Space가 중심에서 GitHub/CodePipeline의 배포 이벤트와 CloudWatch/CloudTrail의 운영 데이터를 모두 흡수한 뒤, 인시던트 발생 시 애플리케이션 워크로드(CloudFront → API Gateway → Lambda → DynamoDB)를 자율 조사하고, 그 결과를 Slack/PagerDuty로 회신하는 구조입니다.

0. AWS DevOps Agent 소개

AWS DevOps Agent는 항상 대기 중인 운영 팀원(always-on operations teammate) 으로, 인시던트가 발생하면 사람이 호출하지 않아도 즉시 조사를 시작합니다. 핵심 특징은 다음과 같습니다.

영역	설명
Context	교차 계정 리소스를 자동 탐색하여 애플리케이션 토폴로지 그래프를 생성합니다.
Control	IAM 기반 세분화된 권한 제어 및 조사 과정을 추적하는 investigation journal(조사 일지)을 제공합니다.
Continuous Learning	Built-in skills와 사용자가 자연어로 추가하는 Custom skills 두 갈래로 구성되며, 운영자 피드백을 받아 추천이 지속적으로 정교화됩니다.
Cost Effective	에이전트가 실제 작업을 수행한 시간만 초 단위로 과금됩니다 (`$0.0083/agent-second`, 약 `$29.88/시간`). 신규 고객은 2개월 무료 트라이얼이 제공됩니다.

💡 프리뷰 기간 동안 고객 사례 기준 MTTR 75% 감소, 조사 시간 80% 단축, 근본 원인 정확도 94% 를 기록했다고 합니다.

기존 CodePipeline + CloudWatch Alarm + Lambda Auto-Rollback 조합과 가장 큰 차이는 “인과 관계의 자동 추론” 입니다. 단순히 “어떤 메트릭이 임계치를 넘었는가”가 아니라, “어떤 커밋이 / 어떤 배포 단계에서 / 어떤 리소스에 / 어떤 영향을 미쳤는가”를 추론합니다.

1. 사전 준비

본 핸즈온을 진행하기 위해서는 아래 환경이 필요합니다.

AWS 계정. 신규 고객 대상 2개월 무료 트라이얼(월 20시간 investigations · 15시간 evaluations · 20시간 chat)이 제공되며, 유료 Support 플랜이 있으면 매월 일정 비율의 크레딧이 자동 적용됩니다. (Unified Operations 100% / Enterprise 75% / Business+ 30%)
지원 리전(2026년 5월 기준 6개) : us-east-1(N. Virginia), us-west-2(Oregon), eu-west-1(Ireland), eu-central-1(Frankfurt), ap-northeast-1(Tokyo), ap-southeast-2(Sydney). Seoul 리전은 아직 미지원이므로 국내 워크로드는 일반적으로 Tokyo 리전을 권장드립니다.
GitHub 계정 및 organization owner 권한 (앱 설치용)
샘플 애플리케이션 (본 글에서는 간단한 Node.js + Lambda + DynamoDB URL 단축기 사용)
관리자 권한 IAM 사용자 (Agent Space 생성용)

2. Agent Space 생성

Agent Space는 DevOps Agent가 접근할 수 있는 AWS 계정, 통합, 권한의 논리적 컨테이너입니다. 하나의 Agent Space는 일반적으로 하나의 비즈니스 도메인(예: 결제 서비스, 검색 서비스)에 대응합니다.

2-1. 콘솔에서 Agent Space 만들기

AWS Management Console 상단 검색창에서 “DevOps Agent” 를 검색하여 서비스로 이동합니다.
좌측 메뉴에서 Agent spaces → Create agent space 버튼을 클릭합니다.
General settings 섹션에서 다음을 입력합니다.

Name : payments-platform
Description : 결제 플랫폼 운영용 Agent Space
Service role : Create and use a new service role 선택 (콘솔이 자동 생성)

Linked AWS accounts 섹션에서 조사 대상 계정 ID들을 추가합니다. 단일 계정인 경우 그대로 두면 됩니다.
Topology discovery 토글을 활성화합니다. 이 옵션을 켜면 Agent가 자동으로 VPC, ECS, Lambda, DynamoDB, RDS 등 리소스 간의 관계를 매핑한 그래프를 생성합니다.
Create 를 클릭하면 약 5~10분 내에 Agent Space가 준비되고, 동일 시간 동안 백그라운드에서 초기 토폴로지 스캔이 진행됩니다.

2-2. Operator 권한 부여

운영 엔지니어가 DevOps Agent Web App에 접속할 수 있도록 권한을 부여합니다. 콘솔의 Agent Space 상세 페이지 → Access 탭 → Add operator 에서 IAM 사용자 또는 IAM Identity Center 그룹을 추가합니다.

권한 레벨은 두 가지입니다.

VIEWER : 토폴로지/인시던트 조회만 가능
OPERATOR : 조사 시작·중지, 완화 액션 승인 가능

3. GitHub 저장소 연동 (UI 가이드)

DevOps Agent의 진가는 CI/CD 파이프라인 이벤트와 인시던트를 자동으로 상관관계 분석 하는 데 있습니다. 이를 위한 가장 강력한 통합 대상이 GitHub입니다. 아래 다이어그램이 전체 연동 구조를 보여줍니다.

연동은 크게 두 갈래로 진행됩니다.

GitHub App 설치 : Agent가 저장소의 커밋, PR, Actions 실행 결과를 읽어옵니다.
OIDC + EventBridge : GitHub Actions가 AWS로 안전하게 인증하고, 배포 이벤트를 Agent에 전달합니다.

3-1. GitHub App 설치

AWS 콘솔의 Agent Space 상세 페이지 → Integrations 탭으로 이동합니다.
Add integration 버튼을 클릭한 뒤 통합 카탈로그에서 GitHub를 선택합니다.
Connect to GitHub 버튼을 클릭하면 GitHub OAuth 인증 페이지로 리디렉션됩니다.
대상 organization을 선택하고, “AWS DevOps Agent” GitHub App에 다음 read-only 권한을 허용합니다. GitHub App은 일반 OAuth 앱과 달리 별도 웹훅을 등록하지 않으며, App 자체가 이벤트 채널 역할을 합니다.

권한 범위	사용 목적
Contents (Read)	커밋 diff, 변경 파일 분석
Pull requests (Read)	최근 머지된 PR과 인시던트 시점 상관 분석
Actions (Read)	워크플로우 실행 결과(성공/실패) 추적
Metadata (Read)	저장소 토폴로지(기본)

인증 완료 후 AWS 콘솔로 자동 복귀합니다. Repositories 화면에서 모니터링할 저장소를 선택합니다 (예: gintlab/url-shortener).

3-2. 저장소-애플리케이션 매핑

Agent가 “어떤 저장소가 어떤 워크로드를 빌드하는지”를 알도록 매핑을 추가합니다.

Agent Space → Applications 탭 → Create application 클릭
다음을 입력합니다.

Application name : url-shortener
Linked repository : gintlab/url-shortener
Production branch : main
Resource selectors : tag:Application=url-shortener (AWS 리소스 태그 기반 자동 매칭)

저장 후, Agent가 백그라운드에서 저장소의 최근 6개월 배포 이력을 분석합니다.

💡 태그 전략이 핵심입니다. 모든 Lambda, DynamoDB Table 등 워크로드 리소스에 Application=url-shortener 태그를 일관되게 부여해두면, Agent가 별도 설정 없이 자동으로 리소스를 묶어 분석합니다.

4. GitHub Actions 워크플로우와 OIDC 연동

GitHub Actions가 AWS 리소스를 배포하면서 동시에 DevOps Agent에 “배포 이벤트”를 전달하는 구조를 만들어봅니다. 전체 흐름은 아래와 같습니다.

4-1. OIDC 자격 증명 공급자 설정

장기 액세스 키 대신 OIDC를 사용하여 GitHub Actions가 IAM Role을 직접 Assume 하도록 설정합니다.

AWS 콘솔 → IAM → Identity providers → Add provider
Provider type : OpenID Connect 선택
Provider URL : https://token.actions.githubusercontent.com
Audience : sts.amazonaws.com
Add provider 클릭

4-2. 배포용 IAM Role 생성 (최소 권한 원칙)

IAM → Roles → Create role
Trusted entity type : Web identity 선택
Identity provider : 위에서 만든 GitHub OIDC 공급자
Audience : sts.amazonaws.com
GitHub organization : gintlab, Repository : url-shortener, Branch : main
권한은 *FullAccess 관리형 정책이 아닌, 배포에 필요한 액션과 리소스만 허용하는 인라인 정책을 사용합니다. SAM 기반 URL 단축기 배포 예시는 다음과 같습니다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "CloudFormationDeploy",
      "Effect": "Allow",
      "Action": [
        "cloudformation:CreateChangeSet",
        "cloudformation:ExecuteChangeSet",
        "cloudformation:DescribeStacks",
        "cloudformation:DescribeStackEvents",
        "cloudformation:GetTemplate"
      ],
      "Resource": "arn:aws:cloudformation:ap-northeast-1:*:stack/url-shortener-*/*"
    },
    {
      "Sid": "LambdaDeploy",
      "Effect": "Allow",
      "Action": [
        "lambda:UpdateFunctionCode",
        "lambda:UpdateFunctionConfiguration",
        "lambda:GetFunction",
        "lambda:PublishVersion",
        "lambda:UpdateAlias"
      ],
      "Resource": "arn:aws:lambda:ap-northeast-1:*:function:url-shortener-*"
    },
    {
      "Sid": "DynamoDBTable",
      "Effect": "Allow",
      "Action": [
        "dynamodb:DescribeTable",
        "dynamodb:UpdateTable"
      ],
      "Resource": "arn:aws:dynamodb:ap-northeast-1:*:table/url-shortener-*"
    },
    {
      "Sid": "S3ArtifactBucket",
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:PutObject"],
      "Resource": "arn:aws:s3:::sam-artifacts-*/url-shortener/*"
    },
    {
      "Sid": "IAMPassRoleForLambda",
      "Effect": "Allow",
      "Action": "iam:PassRole",
      "Resource": "arn:aws:iam::*:role/url-shortener-lambda-role",
      "Condition": {
        "StringEquals": { "iam:PassedToService": "lambda.amazonaws.com" }
      }
    }
  ]
}

Role 이름은 GitHubActionsDeployRole로 저장합니다.

4-3. GitHub Actions 워크플로우 작성

DevOps Agent는 GitHub App을 통해 저장소에 연결된 직후부터 commits, PRs, Actions 워크플로우 실행 결과를 자동으로 수신합니다. 따라서 배포 이벤트를 Agent에 알리기 위해 별도의 CLI 호출이나 API 단계를 워크플로우에 추가할 필요가 없습니다.

워크플로우는 일반적인 SAM 배포 구조 그대로 두면 됩니다.

- name: Configure AWS credentials (OIDC)
  uses: aws-actions/configure-aws-credentials@v4
  with:
    role-to-assume: arn:aws:iam::123456789012:role/GitHubActionsDeployRole
    aws-region: ap-northeast-1

- name: Deploy with SAM
  run: |
    sam build
    sam deploy --no-confirm-changeset

배포가 완료되면 Agent의 GitHub App이 워크플로우의 completed 이벤트와 main 브랜치의 새 커밋을 자동으로 수신하고, 이후 발생하는 인시던트의 시점·범위와 자동 상관 분석합니다.

4-4. Agent가 PR/커밋 데이터를 활용하는 방식

DevOps Agent의 GitHub App은 read-only로 동작합니다. 즉, PR에 직접 코멘트를 작성하거나 워크플로우를 트리거하지 않습니다. 대신 다음 데이터를 인시던트 조사 시 컨텍스트로 사용합니다.

최근 머지된 PR의 변경 파일 / diff
워크플로우 실행 성공·실패 이력
배포된 커밋 SHA와 타임스탬프

조사 결과는 DevOps Agent Web App과 Slack/ServiceNow 등 연결된 협업 채널에서 확인합니다. PR 본문에 자동 코멘트를 다는 동작은 별도의 AWS Security Agent가 제공하는 기능이며, 보안 발견(security findings)에 한해 동작합니다. 두 서비스는 보완재로 함께 사용할 수 있지만, 본 글의 범위는 DevOps Agent에 한정합니다.

5. CodePipeline 연동

GitHub Actions 외에 AWS CodePipeline을 함께 사용하는 환경이라면 추가 연동이 가능합니다.

Agent Space → Integrations → AWS CodePipeline 추가
모니터링할 파이프라인을 체크박스로 선택
Save 클릭

선택과 동시에 EventBridge 규칙이 자동 생성되며, CodePipeline의 모든 단계 전이(STARTED, SUCCEEDED, FAILED)가 Agent에 실시간 전달됩니다. 별도 코드 변경 없이 활성화됩니다.

6. 관찰 가능성 도구 연동

CI/CD 통합만으로는 충분하지 않습니다. Agent가 “어떤 영향을 받았는지” 알기 위해서는 메트릭/로그/트레이스 소스가 함께 연결되어야 합니다.

CloudWatch : Agent Space 생성 시 같은 리전의 메트릭/로그/알람은 자동 연결됩니다.
CloudTrail : 마찬가지로 자동 연결되며, 누가/언제/무엇을 변경했는지를 추적합니다.
Datadog, New Relic, Dynatrace, Splunk, Grafana : Integrations 탭에서 카탈로그를 통해 추가합니다. API 키/Application 키만 Secrets Manager에 저장해두면 콘솔이 안내해줍니다.

7. 실전 시나리오 : 배포 후 5xx 오류 발생 시 자동 조사

이제 실제로 장애 상황을 재현하고 Agent가 어떻게 동작하는지 확인해보겠습니다.

7-1. 의도된 회귀(regression) 배포

URL 단축기의 Lambda 함수에 의도적으로 비효율 코드를 삽입한 PR을 머지합니다. 한 요청을 처리할 때마다 단일 PutItem 대신 BatchWriteItem을 100회 루프로 호출하도록 변경한 것이라, 트래픽이 누적되면 write capacity 소모가 폭증합니다.

GitHub Actions가 자동으로 배포하고, DevOps Agent의 GitHub App이 새 커밋과 배포 완료 이벤트를 자동으로 수신합니다.

7-2. 인시던트 발생

배포 약 30~40분 후 트래픽이 증가하면서 DynamoDB의 ProvisionedThroughputExceededException이 발생하고, API Gateway에서 5xx 오류율이 임계치를 초과합니다.

CloudWatch Alarm이 발화하는 즉시, DevOps Agent는 사람의 호출 없이 다음 단계를 자율적으로 수행합니다.

시간	Agent 동작
0:00	CloudWatch Alarm 수신 ( `api-5xx-rate-high` )
0:01	토폴로지 기반 가설 생성 : API Gateway → Lambda → DynamoDB
0:02	각 계층 메트릭 병렬 쿼리 (Lambda Throttles, DDB ThrottledRequests)
0:03	DynamoDB Write Throttle 급증 확인, 시간대 역추적
0:03	GitHub commit history 확인 → `feat: bulk write` 커밋 식별
0:04	Slack 채널에 RCA 및 완화 방안 게시

7-3. Agent의 출력 예시

Slack에 게시되는 내용은 다음과 같은 구조를 가집니다.

🔴 Investigation #INV-2026-0142  payments-platform
─────────────────────────────────────────────────
Application : url-shortener
Trigger     : CloudWatch Alarm api-5xx-rate-high
Duration    : 3m 47s

▌Root Cause (Confidence: 96%)
Deployment 2026-05-22 13:42 UTC (commit a7f3c91 "feat: bulk write")
introduced a BatchWriteItem loop in handler.js:47, increasing
write capacity consumption by ~98x. DynamoDB throttling started
at 14:19 UTC, cascading to API Gateway 5xx.

▌Mitigation Options
  [1] Rollback to previous deployment (commit 2e1d5b8) - Recommended
  [2] Switch table to on-demand capacity mode

▌Validation Steps
  - Monitor api-5xx-rate-high for 10 min
  - Verify DDB ThrottledRequests returns to baseline

💡 위 시나리오에서 사람이 직접 조사했다면 통상 1~2시간이 소요됩니다. Agent는 약 4분 만에 동일한 결론에 도달합니다.

7-4. 인시던트 ↔ 커밋 연결 정보 확인

DevOps Agent Web App의 인시던트 상세 화면을 열면, RCA와 함께 원인이 된 커밋의 메타데이터가 한 화면에 노출됩니다.

인시던트 ID, 시작·종료 시각, 영향 받은 리소스
직전 배포의 commit SHA / 변경 파일 / PR 번호 (GitHub 링크)
향후 예방을 위한 추천 액션 (Prevention 권장사항)

여기서 PR 링크를 클릭하면 GitHub의 해당 PR로 이동하므로, 운영팀과 작성자가 같은 화면을 공유하면서 회고할 수 있습니다.

💡 PR 본문에 인시던트 링크를 자동 코멘트로 다는 기능은 AWS Security Agent가 보안 발견(security findings)에 한해 제공합니다.
DevOps Agent의 GitHub App은 read-only이므로 PR 코멘트를 작성하지 않습니다.

7-5. 자동 완화 액션

Agent가 제시한 완화 방안을 자동 실행하려면 Mitigation Action을 사전 등록할 수 있습니다. Agent Space → Mitigation actions → Register 에서 다음을 등록합니다.

Action type : Lambda
Target function : 롤백을 실행할 Lambda 함수
Approval required : Yes (운영 초기에는 반드시 활성화 권장)

승인이 필요한 액션은 Slack에 승인 버튼으로 게시되며, 권한이 있는 운영자가 클릭해야 실행됩니다.

8. 예방 권장사항(Prevention) 활용

DevOps Agent의 또 다른 강력한 기능은 과거 인시던트의 패턴을 학습하여 사전 예방 권장사항을 제시한다는 점입니다.

DevOps Agent Web App의 Prevention 탭에 접속하면 4가지 영역의 권장사항을 확인할 수 있습니다.

Observability : 누락된 알람, 부족한 로그 보존
Infrastructure : Auto Scaling 설정, 용량 튜닝
Deployment Pipeline : 테스트 단계 보강, 카나리 배포 적용
Code Quality : 반복적으로 회귀를 유발한 모듈 식별

권장사항 예시는 다음과 같습니다.

⚠️ Deployment Pipeline Recommendation
Severity : Medium
Application : url-shortener

Observation
  In the last 90 days, 3 of 4 production incidents were caused
  by changes to handler.js that bypassed integration tests.

Recommendation
  Add a required integration test step to the GitHub Actions
  workflow that runs against DynamoDB Local before deployment.

Estimated Impact
  Would have prevented INV-2026-0142, INV-2026-0098, INV-2026-0073

권장사항은 Web App에서 그대로 복사하거나, Export as remediation spec 으로 마크다운/JSON 사양 파일로 내려받을 수 있습니다. 이 사양 파일을 팀의 코드 리뷰/리팩터링 도구(예: Kiro, GitHub Copilot Workspace)에 입력하여 워크플로우 YAML 변경 PR을 사람이 생성하는 방식이 일반적인 권장 흐름입니다.

💡 DevOps Agent 자체가 GitHub에 PR을 직접 생성하지는 않습니다. 자동 PR 생성이 필요하다면 별도의 자동화(GitHub Actions workflow_dispatch 또는 Security Agent의 fix submission) 와 조합해야 합니다.

9. 마치며

지금까지 AWS DevOps Agent를 활용하여 CI/CD 파이프라인을 자율적으로 운영하는 방법을 살펴보았습니다. 핵심을 다시 정리하면 다음과 같습니다.

Agent Space 는 DevOps Agent의 작업 단위이며, IAM 기반 거버넌스를 제공합니다.
GitHub 연동 은 read-only GitHub App 한 번의 설치만으로 commits·PRs·Actions 이벤트를 자동 수신합니다. 별도의 CLI 호출이 워크플로우에 들어갈 필요가 없습니다.
자동 조사 는 약 4분 내에 근본 원인을 식별합니다 (AWS Cloud Operations Blog의 고객 사례 기준 MTTR 1~2시간 → 20~30분).
Prevention 권장사항 을 통해 사후 대응에서 사전 예방 으로 운영 패러다임을 전환할 수 있습니다.
PR 자동 코멘트·자동 PR 생성 이 필요한 보안 시나리오에는 별도 서비스인 AWS Security Agent를 함께 사용하세요.

다만, DevOps Agent는 GA 이후 사용량 기반 과금($0.0083/agent-second, 약 $29.88/시간 × Investigations·Evaluations·Chat 3개 모드 동일 단가)이 적용됩니다. 초기에는 2개월 무료 트라이얼 한도(월 20시간 investigations 등) 안에서 개발/스테이징 환경부터 도입하여 ROI를 검증한 뒤 프로덕션으로 확장하시기 바랍니다. 자동 완화 액션은 처음에는 반드시 approval-required 옵션을 켜고 운영하시기 바랍니다.

본 핸즈온에서 생성한 리소스(Agent Space, IAM Role, GitHub App, EventBridge 규칙)는 비용 누적을 막기 위해 반드시 정리해주세요.

다음 글에서는 DevOps Agent의 멀티 클라우드 / 하이브리드 환경 적용 사례 와 온프레미스 Kubernetes 클러스터 연동 을 다뤄보겠습니다. 감사합니다.

참고 자료

AWS DevOps Agent 공식 문서
Supported Regions — AWS DevOps Agent
AWS DevOps Agent Pricing
Announcing General Availability of AWS DevOps Agent (AWS Cloud Operations Blog)
AWS DevOps Agent is now generally available (AWS What’s New)
Leverage Agentic AI for Autonomous Incident Response with AWS DevOps Agent (DevOps & Developer Productivity Blog)
AWS Security Agent (보완재)

[Hands-On] AWS DevOps Agent를 활용한 CI/CD 파이프라인 자율 운영하기

아키텍처

목차

0. AWS DevOps Agent 소개

1. 사전 준비

2. Agent Space 생성

3. GitHub 저장소 연동 (UI 가이드)

4. GitHub Actions 워크플로우와 OIDC 연동

5. CodePipeline 연동

6. 관찰 가능성 도구 연동

7. 실전 시나리오 : 배포 후 5xx 오류 발생 시 자동 조사

8. 예방 권장사항(Prevention) 활용

9. 마치며

0. AWS DevOps Agent 소개

1. 사전 준비

2. Agent Space 생성

2-1. 콘솔에서 Agent Space 만들기

2-2. Operator 권한 부여

3. GitHub 저장소 연동 (UI 가이드)

3-1. GitHub App 설치

3-2. 저장소-애플리케이션 매핑

4. GitHub Actions 워크플로우와 OIDC 연동

4-1. OIDC 자격 증명 공급자 설정

4-2. 배포용 IAM Role 생성 (최소 권한 원칙)

4-3. GitHub Actions 워크플로우 작성

4-4. Agent가 PR/커밋 데이터를 활용하는 방식

5. CodePipeline 연동

6. 관찰 가능성 도구 연동

7. 실전 시나리오 : 배포 후 5xx 오류 발생 시 자동 조사

7-1. 의도된 회귀(regression) 배포

7-2. 인시던트 발생

7-3. Agent의 출력 예시

7-4. 인시던트 ↔ 커밋 연결 정보 확인

7-5. 자동 완화 액션

8. 예방 권장사항(Prevention) 활용

9. 마치며

참고 자료

댓글 달기 댓글 취소