AI 코딩 도구의 확산으로 Pull Request가 만들어지는 속도는 폭발적으로 빨라졌지만, 이를 검토하고 테스트하는 속도는 여전히 사람의 손에 머물러 있습니다. 이 글에서는 AWS Frontier Agents의 개념과 구성을 소개하고, AWS DevOps Agent에 새로 추가된 Release Management(Preview) 기능으로 코드 변경이 프로덕션에 도달하기 전에 릴리스 리스크를 자율적으로 검증하는 방법을 단계별로 살펴봅니다.

들어가며: Frontier Agents란 무엇인가

생성형 AI 어시스턴트는 이제 익숙한 도구가 되었습니다. 질문을 하면 답을 주고, 코드를 요청하면 코드를 생성합니다. 하지만 어시스턴트에게는 근본적인 한계가 있는데, 이는 사람이 매 단계를 지시하고, 결과를 확인하고, 다음 지시를 내려야 한다는 점입니다.

Frontier Agent는 이와 다른 부류의 AI Agent입니다. 목표를 위임받으면 사람의 개입 없이 수 시간에서 수일에 걸쳐 자율적으로 작업을 수행하고, 수많은 동시 작업으로 확장되며, 중간 결과물이 아닌 완결된 결과를 전달합니다. 질문에 답하는 도구가 아니라, 팀의 일원처럼 자율적으로 업무를 수행합니다.

AWS는 re:Invent 2025에서 Frontier Agents 제품군을 발표했고, 2026년 상반기를 거치며 빠르게 기능을 확장해 왔습니다. 현재 제품군은 다음 네 가지로 구성됩니다.

네 가지 Agent를 애플리케이션 라이프사이클 위에 놓고 보면 각자의 위치가 분명해집니다. Kiro가 코드를 만들고, DevOps Agent가 배포와 운영을 지키고, Security Agent가 보안을 검증하고, FinOps Agent가 비용을 감시합니다.

이 시리즈는 가상의 이커머스 기업 AnyCompany의 주문 서비스를 예시 삼아, 하나의 애플리케이션을 세 개의 Agent가 라이프사이클 단계별로 어떻게 담당하는지 따라갑니다. 이번 1편은 배포 전(pre-production) 단계를 다룹니다.

우선 한가지 짚고 넘어갈 점이 있습니다. AWS DevOps Agent를 활용한 인시던트 대응 방법은 AWS 한국 기술 블로그에서 이미 잘 다루고 있습니다. 성능 테스트 결과 분석, HYBE의 Custom MCP 서버 기반 인시던트 자동 조사, K8s Operator와 결합한 EKS 운영 최적화를 참고하시기 바랍니다. 이 글은 그와 반대로, 장애 발생 이전에 배포를 사전 검증하는 영역에 초점을 맞춥니다.

왜 Release Management인가: 인시던트 ‘대응’에서 ‘예방’으로

지금까지 AWS DevOps Agent의 목표 대상은 배포 이후였습니다. 인시던트가 발생하면 CloudWatch, Datadog 같은 관측 도구의 텔레메트리를 자율적으로 조사해 근본 원인을 찾고 완화 방안을 제시했습니다. 하지만 SRE 관점에서 가장 이상적인 것은 인시던트 자체가 발생하지 않는 것입니다. 하지만 실제로 프로덕션 인시던트의 상당수는 배포된 변경에서 비롯되게 됩니다.

여기서 문제는 변경의 양입니다. AI 코딩 도구가 보편화되면서 개발팀이 하루에 만들어내는 Pull Request 수는 크게 늘었지만, 이를 리뷰하고 테스트하는 과정은 여전히 사람의 속도에 묶여 있습니다. 그 결과 두 가지 나쁜 패턴이 나타납니다. 검토가 형식적으로 이루어져 위험한 변경이 통과되거나, 반대로 리뷰 대기열이 길어져 배포가 정체됩니다.

2026년 6월 Preview로 공개된 Release Management는 이 병목을 겨냥합니다. Release Management는 아래의 두 가지 기능으로 구성됩니다.

핵심 차이는 세 번째 행에 있습니다. 기존 CI 파이프라인의 테스트는 사람이 미리 작성해 둔 시나리오만 반복합니다. Autonomous Release Testing은 이번 변경이 무엇을 하는지 추론한 뒤, 그 변경에 맞는 테스트 계획을 스스로 생성합니다. 테스트 커버리지가 코드 변경을 따라 움직이는 것입니다.

아키텍처 및 동작 원리

그림 1. AWS DevOps Agent Release Management 동작 아키텍처 — GitHub/GitLab PR이 Agent Space로 전달되고, 코드 인덱싱으로 구축된 knowledge graph를 바탕으로 격리 환경 검증을 거쳐 콘솔 리포트와 PR 코멘트로 결과가 전달되는 흐름

전체 흐름을 이해하기 위해 세 가지 핵심 개념을 먼저 정리합니다.

Release Readiness Review는 연결된 리포지토리에 PR이 제출되면(또는 온디맨드 요청 시) 실행됩니다. Agent는 변경을 분석해 프로덕션 요구사항과 의존성 안전성, 다른 서비스에 영향을 주는 cross-repo 의존성 리스크, 접근 제어 변경의 AWS Well-Architected Framework 모범 사례 부합 여부, 그리고 사용자가 자연어로 정의한 조직 표준 준수 여부를 검토합니다. 여기서 그치지 않고 AWS 관리형 격리 환경에서 실제로 소프트웨어를 빌드하고 실행하여 경량 사용자 여정 테스트(lightweight user journey test)까지 수행합니다. 정적 분석만으로는 잡을 수 없는 “빌드는 되는데 실행이 안 되는” 유형의 문제를 걸러내는 단계입니다.

Autonomous Release Testing은 웹 및 API 기반 애플리케이션을 대상으로 한 단계 더 나아갑니다. 변경 내용을 추론해 기능 정확성, 동작 회귀, 통합 시나리오를 포괄하는 테스트 계획을 생성하고, 고객이 프로비저닝한 프로덕션과 유사한 환경에서 병합 전에 실행합니다. 실행이 끝나면 메트릭, 로그, 트레이스, 실행 요약이 구조화된 아티팩트로 남습니다.

두 기능의 실행 환경 차이에 주목할 필요가 있습니다. Readiness Review는 AWS가 관리하는 격리 환경을 사용하므로 별도 인프라 준비 없이 바로 시작할 수 있고, Release Testing은 실제와 유사한 환경이 필요하므로 고객 환경을 사용합니다. 도입 순서로는 Readiness Review를 먼저 활성화하고, 검증 깊이가 더 필요한 핵심 서비스에 Release Testing을 확대하는 접근이 자연스럽습니다.

핸즈온: AnyCompany 주문 서비스에 적용하기

이제 AnyCompany의 주문 서비스에 Release Management를 적용해 보겠습니다. 주문 서비스는 결제 서비스와 API로 연동되는 전형적인 마이크로서비스 구성이며, 두 서비스는 각각 별도의 GitHub 리포지토리로 관리됩니다. 실습에 사용한 전체 코드는 anycompany-order-service와 anycompany-payment-service 리포지토리에서 확인할 수 있습니다. 직접 따라 하려면 두 리포지토리를 본인 계정으로 fork하거나, 소스 코드를 내려받아 본인 리포지토리를 만들어 Agent Space에 연결하면 됩니다.

단, 퍼블릭 리포지토리의 fork는 퍼블릭으로만 유지되어 PR 자동 리뷰가 트리거되지 않으므로, 리뷰 결과를 PR 코멘트로 받아보려면 소스를 내려받아 프라이빗 리포지토리로 구성하세요.

참고: Release Management는 Preview 기간 동안 미국 동부(버지니아 북부, us-east-1) 리전에서만 제공됩니다. 실습을 시작하기 전에 콘솔 우측 상단에서 리전을 미국 동부(버지니아 북부)로 변경했는지 확인하세요.

1단계: Agent Space 구성과 리포지토리 연결

먼저 DevOps Agent 콘솔에서 Agent Space를 생성하고 주문 서비스와 결제 서비스의 GitHub 리포지토리를 모두 연결합니다. 리포지토리 연결 절차는 공식 문서의 가이드를 따릅니다.

그림 2. Agent Space 생성 화면 — 스페이스 이름과 에이전트 응답 언어(선택 사항)를 지정하는 화면

그림 3. GitHub 계정/조직 등록 화면 — 리뷰 결과를 PR 코멘트로 게시할 수 있도록 읽기 및 쓰기(Read and write) 권한을 선택한 화면

Tip: 콘솔의 리포지토리 선택 목록에는 GitHub에 설치된 DevOps Agent GitHub App이 접근 권한을 가진 리포지토리만 표시됩니다. 원하는 리포지토리가 목록에 보이지 않는다면 GitHub의 Settings → Applications → Installed GitHub Apps에서 AWS DevOps Agent App의 Repository access 범위에 해당 리포지토리를 추가한 뒤 콘솔 화면을 새로고침하세요.

연결이 완료되면 Agent가 코드 인덱싱을 시작하고, 주문 서비스와 결제 서비스 간 API 호출 관계를 포함한 knowledge graph를 구축합니다. 최초 인덱싱에는 약 1~2시간이 소요됩니다.

콘솔에서 Agent Space를 선택한 뒤 웹 앱 실행(영문 콘솔: Operator access) 버튼을 눌러 IAM을 통해 시작을 선택하면 웹 애플리케이션에 접근할 수 있습니다. 웹 애플리케이션 UI는 영어로 제공되지만, Agent Space 생성 시 에이전트 응답 언어를 설정해 두면 리뷰 리포트를 한국어로 받을 수 있습니다.

2단계: 조직의 릴리스 표준을 자연어로 정의하기

웹 애플리케이션 좌측 메뉴에서 Knowledge를 선택하고 Instructions 탭으로 이동합니다. 지침은 용도별 카테고리로 나뉘어 있습니다 — 인시던트 분류·RCA·완화 같은 인시던트 대응 계열과 함께 Release readiness review(“Production-readiness change review for code and infrastructure changes”) 카테고리가 제공됩니다. 이 항목의 View를 눌러 편집 모드에 진입해 릴리스 표준을 작성하면 릴리스 준비 상태 검토에 적용됩니다. 별도의 정책 언어를 배울 필요 없이 평문으로 작성합니다. 아래는 AnyCompany의 예시입니다.

그림 4. 웹 애플리케이션의 Knowledge → Instructions 화면 — 인시던트 대응 계열 카테고리와 함께 Release readiness review 카테고리가 제공되는 화면

# AnyCompany 릴리스 표준

## 암호화
- 저장 데이터를 다루는 모든 신규 리소스는 저장 시 암호화(encryption at rest)가
활성화되어야 합니다. 비활성화된 경우 릴리스를 차단합니다.

## 네트워크 접근
- 보안 그룹 인바운드 규칙에 0.0.0.0/0 을 추가하는 변경은 릴리스를 차단합니다.
- 새로운 퍼블릭 엔드포인트 노출은 반드시 이슈로 보고합니다.

## IAM
- 와일드카드(*) 액션 또는 리소스를 포함하는 IAM 정책 변경은 릴리스를 차단합니다.
- 기존 역할의 권한 범위를 확대하는 변경은 '주의' 수준으로 보고합니다.

## 관측성 (경고만, 차단하지 않음)
- 신규 API 엔드포인트에 구조화된 로깅이 없으면 경고합니다.

## 민감 정보
- 주문 데이터의 고객 개인정보(이름, 주소, 연락처)는 민감 데이터로 분류합니다.
- 민감 데이터를 로그로 출력하는 코드는 릴리스를 차단합니다.

지침이 차단(block) 기준과 경고(warn) 기준을 구분하고 있다는 점에 주목하시기 바랍니다. 모든 것을 차단하면 릴리스 관문이 아니라 릴리스 장벽이 됩니다. 조직에서 타협 불가능한 기준만 차단으로 두고, 나머지는 경고로 시작해 팀의 수용도를 보며 조정하는 것을 권장합니다. 릴리스 표준을 더 정교하게 관리하려면 코드 리뷰 방법론을 담은 DevOps Agent Skills로 분리해 필요할 때만 로드되도록 구성할 수도 있습니다.

3단계: 위험한 PR 제출하기

검증을 위해 의도적으로 문제를 포함한 PR을 준비합니다. 먼저 두 리포지토리의 기준 코드(main 브랜치)를 살펴봅니다.

• 주문 서비스 — anycompany-order-service:

# template.yaml
AWSTemplateFormatVersion: "2010-09-09"
Transform: AWS::Serverless-2016-10-31
Description: AnyCompany Order Service

Resources:
  OrderTable:
    Type: AWS::DynamoDB::Table
    Properties:
      TableName: anycompany-orders
      AttributeDefinitions:
        - AttributeName: orderId
          AttributeType: S
      KeySchema:
        - AttributeName: orderId
          KeyType: HASH
      BillingMode: PAY_PER_REQUEST
      SSESpecification:
        SSEEnabled: true

  GetOrderFunction:
    Type: AWS::Serverless::Function
    Properties:
      Handler: src/get_order.handler
      Runtime: python3.12
      Policies:
        - DynamoDBReadPolicy:
            TableName: !Ref OrderTable
      Events:
        GetOrderApi:
          Type: Api
          Properties:
            Path: /orders/{orderId}
            Method: get

# src/get_order.py
import json
import boto3

dynamodb = boto3.resource("dynamodb")
table = dynamodb.Table("anycompany-orders")


def handler(event, context):
    order_id = event["pathParameters"]["orderId"]
    response = table.get_item(Key={"orderId": order_id})
    item = response.get("Item")
    if not item:
        return {"statusCode": 404, "body": json.dumps({"message": "Order not found"})}
    return {
        "statusCode": 200,
        "body": json.dumps({
            "orderId": item["orderId"],
            "orderStatus": item["status"],
            "amount": item["amount"],
        }),
    }

• 결제 서비스 — anycompany-payment-service:

# src/verify_order.py
import requests

ORDER_API_BASE = "https://api.anycompany.example.com"

def verify_order_before_refund(order_id: str) -> bool:
"""환불 처리 전 주문이 배송 완료 상태인지 주문 서비스에 확인한다."""
resp = requests.get(f"{ORDER_API_BASE}/orders/{order_id}")
resp.raise_for_status()
data = resp.json()
return data["orderStatus"] == "DELIVERED"

결제 서비스는 주문 서비스 API의 orderStatus 필드를 읽어 환불 가능 여부를 판단합니다. 이 의존성이 cross-repo 계약의 핵심입니다.

이제 주문 서비스 리포지토리에서 feature/order-status-v2 브랜치를 만들고 두 가지 변경을 커밋해 PR을 제출합니다. 겉보기에는 평범한 리팩터링이지만 각각 리스크를 담고 있습니다.

• 변경 1 — IAM 권한 확대: 주문 조회 Lambda의 실행 역할을 읽기 전용 정책에서 dynamodb:* 와일드카드 액션으로 교체합니다. 2단계에서 정의한 조직 표준의 차단 기준에 해당합니다.

# template.yaml — GetOrderFunction의 Policies
Policies:
- Version: "2012-10-17"
Statement:
- Effect: Allow
Action: "dynamodb:*" # 기존: DynamoDBReadPolicy (읽기 전용)
Resource: !GetAtt OrderTable.Arn

• 변경 2 — Cross-repo API 계약 변경: 주문 조회 API의 응답 필드명을 orderStatus에서 status로 변경합니다. 주문 서비스 코드만 보면 문제가 없지만, 위의 결제 서비스 호출 코드는 data[“orderStatus”]를 읽고 있으므로 배포 시 환불 검증이 실패하게 됩니다.

  # src/get_order.py — 응답 본문
          "body": json.dumps({
              "orderId": item["orderId"],
              "status": item["status"],     # 기존: "orderStatus"
              "amount": item["amount"],
          }),

  첫 번째는 리포지토리 하나만 봐도 알 수 있는 문제지만, 두 번째는 결제 서비스 리포지토리의 호출 코드까지 함께 봐야만 발견할 수 있는 문제입니다. 사람 리뷰어가 가장 자주 놓치는 유형이기도 합니다. 이 때문에 1단계에서 주문 서비스뿐 아니라 결제 서비스 리포지토리도 함께 연결해 인덱싱을 마쳐두는 것이 전제 조건입니다.

그림 5. 제출된 PR의 Files changed 화면 — 응답 필드명 변경(get_order.py)과 IAM 와일드카드 정책 교체(template.yaml) 두 가지 변경이 담긴 화면

프라이빗 리포지토리의 경우 PR이 제출되면 리뷰가 자동으로 트리거되어, 결과가 PR에 인라인 코멘트와 종합 판정 코멘트로 게시됩니다. 퍼블릭 리포지토리는 자동 트리거가 지원되지 않으므로, 이 실습에서는 웹 애플리케이션 채팅에서 온디맨드로 리뷰를 요청합니다. 대상은 브랜치 이름, PR 번호, 커밋 SHA 중 어느 것으로든 지정할 수 있습니다.

4단계: 리뷰 결과 분석하기

리뷰가 완료되면 웹 애플리케이션 채팅에 구조화된 리포트가 표시됩니다. 리포트 위의 도구 사용 내역 토글(예: “4개의 도구 사용됨”)을 펼치면 Agent가 판정에 이르기까지 어떤 도구를 호출해 무엇을 조회했는지 단계별로 확인할 수 있습니다. 결과만 던지는 블랙박스가 아니라 판단의 근거를 추적할 수 있다는 점이 실무 도입에서 중요한 요소입니다.

그림 6. 도구 사용 내역 토글을 펼친 화면 — Agent가 브랜치 변경분 조회(Git Diff·Git Log)에 사용한 도구 호출 단계가 기록되고, 이어서 변경 사항 요약이 표시된 모습

리포트 본문은 변경 사항 요약 → 이슈별 상세 → 결론 순으로 구성됩니다. 이번 PR에서는 두 변경 모두 차단으로 판정되었습니다.

• IAM 와일드카드 정책: dynamodb:*가 읽기뿐 아니라 DeleteTable, DeleteItem 등 모든 작업을 허용한다는 점을 짚고, 2단계에서 정의한 릴리스 표준의 차단 기준 문구를 그대로 인용하며 차단했습니다. 변경 전 읽기 전용 정책으로 되돌리거나 필요한 액션만 명시하는 수정안이 코드로 함께 제시됩니다.
• API 응답 필드명 변경: 하위 호환성이 깨지는 Breaking Change로 차단하고, 버전 관리된 엔드포인트 도입 또는 기존 필드를 유지한 채 새 필드를 병행 제공하는 과도기 방안을 제시했습니다.

리포트 말미에는 릴리스 가능 여부가 차단으로 명시되고 필수 수정 사항 수가 요약됩니다.

그림 7. 차단 판정 리포트 — API Breaking Change의 문제점·권장 조치에 이어, 결론 표에 릴리스 가능 여부 “차단”과 필수 수정 사항 2건이 명시된 화면

여기까지가 이슈를 찾아 차단한 결과라면, 이 제품의 진짜 차별점은 후속 질문에서 드러납니다. 필드명 변경이 어디를 깨뜨리는지 영향 범위를 물어봅니다.

프롬프트 어디에도 결제 서비스를 언급하지 않았지만, Agent는 knowledge graph에서 anycompany-payment-service의 src/verify_order.py를 스스로 찾아냅니다. data[“orderStatus”]를 읽는 정확한 라인에서 KeyError가 발생한다는 장애 지점, 환불 처리가 전면 실패한다는 비즈니스 영향, 두 리포지토리 README에 문서화된 의존성 근거, 그리고 하위 호환 필드 병행 제공 또는 두 서비스 동시 배포라는 해결 방안까지 구조화해 답합니다. 사람 리뷰어가 가장 자주 놓치는 cross-repo 계약 파괴가 파일·라인 단위로 특정되는 순간입니다.

그림 8. Cross-repo 영향 분석 — 결제 서비스 verify_order.py Line 11이 장애 발생 지점으로 특정되고, data[“orderStatus”] 접근 시 KeyError → 환불 전면 실패라는 장애 시나리오가 구조화된 화면

그림 9. 프라이빗 리포지토리에서 자동 트리거된 리뷰가 PR에 남긴 Blocking 코멘트 — 결제 서비스의 verify_order.py를 소비자로 특정하고, 목킹 환경에서 실행해 KeyError 발생을 확인한 뒤 하위 호환 수정안까지 제시한 화면

그림 10. PR 상태 검사에 기록된 리뷰 결과 — aws-devops-agent/release-readiness-review 검사가 “change blocked”로 실패 처리되어, 머지 차단 조건으로 설정하면 병합을 막을 수 있음을 보여주는 화면

5단계: 자율 릴리스 테스트 실행하기

Readiness Review를 통과하도록 PR을 수정했다면, 병합 전 마지막 관문으로 자율 릴리스 테스트를 실행할 수 있습니다. 먼저 웹 애플리케이션의 Release Manager → 테스트 프로파일(Test profiles)에서 대상 애플리케이션을 정의합니다. 프로파일에는 스테이징 배포의 URL(퍼블릭 인터넷 접근 가능해야 함)과 테스트 유형 — 브라우저 기반 UI 테스트 또는 REST API 대상 API 테스트 — 을 지정합니다. 이후 프로파일에서 직접 실행하거나, 채팅으로 요청하거나, GitHub Actions로 CI/CD 파이프라인에 통합할 수 있습니다.

Agent는 이번 변경이 주문 상태 조회 흐름을 수정했다는 것을 이해하고, 정적 회귀 스위트가 아니라 Readiness Review에서 드러난 리스크 영역을 겨냥한 변경-특화 테스트 계획을 생성해 실행합니다. 결과는 구체적 실패 지점, 재현 절차, 권장 수정과 함께 리포트되며 UI 테스트는 스크린샷도 남습니다.

다만, 한 가지 주의할 점이 있습니다. 릴리스 테스트는 대상 애플리케이션에 POST·PUT·DELETE를 포함한 실제 요청을 보냅니다. 탐색 과정에서 데이터가 생성·수정·삭제될 수 있으므로, 고객 알림 발송이나 결제 처리 같은 부작용이 없는 스테이징 환경을 대상으로 실행해야 합니다.

IDE에서 커밋 전에 검증하기

PR을 만들기 전 단계로 당길 수도 있습니다. Kiro power 또는 Claude Code 플러그인을 설치하면 IDE와 CLI에서 직접 릴리스 준비 상태 리뷰를 호출할 수 있습니다. 문제를 커밋 전에 발견할수록 수정 비용은 낮아지므로, 팀에 코딩 에이전트가 이미 정착되어 있다면 함께 구성할 가치가 있습니다.

무엇을 잘 잡고, 무엇은 여전히 사람의 몫인가

핸즈온에서 확인했듯 Release Management가 특히 강한 영역은 다음과 같습니다.

• Cross-repo 영향 분석: knowledge graph 기반으로 리포지토리 경계를 넘는 계약 파괴를 찾아냅니다. 사람 리뷰어는 대개 자기 리포지토리만 봅니다.
• 조직 표준의 일관된 집행: 자연어 지침이 모든 PR에 동일하게 적용됩니다. 리뷰어 개인의 컨디션이나 경험에 따라 기준이 흔들리지 않습니다.
• 실행 검증: 격리 환경에서 실제로 빌드하고 실행하므로 정적 분석의 사각지대를 보완합니다.

반면, 다음 영역은 여전히 사람의 판단이 필요합니다. 비즈니스 요구사항 자체가 올바른지(요구사항이 잘못된 채로 완벽하게 구현된 변경은 통과합니다), 도메인 특유의 암묵적 규칙(지침으로 명문화되지 않은 것은 검증되지 않습니다), 그리고 조직 간 이해관계 조율이 그렇습니다. Release Management는 리뷰어를 대체하는 것이 아니라, 리뷰어가 기계적 검증에 쓰던 시간을 이런 판단에 쓸 수 있게 만드는 도구로 이해하는 것이 정확합니다.

한 가지 실무 팁을 덧붙이면, Instructions는 작게 시작해서 키우는 것이 좋습니다. 처음부터 수십 개 규칙을 넣기보다, 실제 인시던트의 원인이 되었던 변경 유형 서너 가지를 차단 기준으로 정의하고, 리뷰 결과를 지켜보며 규칙을 추가하는 방식이 오탐으로 인한 팀의 피로를 줄입니다.

비용 및 고려사항

• Release Management는 Preview 기간 동안 추가 비용 없이 사용할 수 있으며, 미국 동부(버지니아 북부) 리전(us-east-1)에서 제공됩니다.
• DevOps Agent의 기존 기능(인시던트 조사 등)은 agent-second당 $0.0083(시간당 약 $30)로 과금되며, Agent가 실제로 작업하는 시간에만 부과됩니다. 2개월 무료 평가판이 제공됩니다.
• AWS Support 플랜에 따라 월간 크레딧이 제공됩니다. Unified Operations는 전월 Support 요금의 100%, Enterprise는 75%, Business(및 Enterprise On-Ramp)는 30%에 해당하는 크레딧을 받습니다. 자세한 내용은 요금 페이지를 참고하세요.
• Agent가 조사 과정에서 호출하는 연동 서비스 사용량(예: CloudWatch Logs Insights 쿼리)은 해당 서비스의 표준 요금으로 별도 과금됩니다.
• DevOps Agent 자체는 11개 리전에서 제공되지만, Release Management Preview는 현재 us-east-1에서만 사용할 수 있습니다. 다른 리전의 워크로드도 Agent Space에서 교차 리전으로 모니터링할 수 있습니다.

마무리

이 글에서는 AWS Frontier Agents 제품군의 전체 구성을 살펴보고, AWS DevOps Agent의 Release Management(Preview)로 배포 전 릴리스 리스크를 자율 검증하는 과정을 AnyCompany 주문 서비스 시나리오로 따라가 보았습니다. 자연어로 정의한 조직 표준이 모든 PR에 일관되게 집행되고, cross-repo 의존성 분석과 격리 환경 실행 검증, 변경-특화 테스트 생성이 결합되어 사람 리뷰의 속도 한계를 보완하는 구조를 확인했습니다.

AnyCompany의 주문 서비스는 이제 릴리스 관문을 갖췄습니다. 그런데 릴리스 리스크가 없는 코드라고 해서 안전한 코드는 아닙니다. 이 애플리케이션에 공격자가 악용할 수 있는 취약점은 없을까요? 2편에서는 AWS Security Agent로 침투 테스트를 온디맨드로 수행하고, 발견된 취약점의 수정 PR까지 자동으로 받아보는 과정을 다룹니다.

지금 바로 시작해 보려면:

• AWS DevOps Agent 시작하기 — 2개월 무료 평가판
• Release Management 발표 블로그
• AWS DevOps Agent 사용자 가이드
• AWS Frontier Agents 소개