devops

AWS DevOps Agent: 최대 활용을 위한 10가지 베스트 프랙티스

발행: (2025년 12월 30일 오전 02:27 GMT+9)
20 min read
원문: Dev.to

Source: Dev.to

AWS re:Invent 2025에서 주요 발표 중 하나는 새로운 최전선 자율 에이전트들의 출시였습니다:

  • AWS DevOps Agent
  • AWS Security Agent
  • Kiro Autonomous Agent

이 중 AWS DevOps Agent는 DevOps 및 SRE 팀의 작업 방식을 혁신할 예정입니다. 아래는 AWS DevOps Agent를 최대한 활용하기 위한 필수 베스트 프랙티스입니다.

1. AWS DevOps Agent는 역량이며, 도구가 아닙니다

“맞게 읽으셨습니다. DevOps Agent는 차 한 잔을 마시며 모든 문제를 해결해 주는 마법의 총알이 아닙니다.”

이는 역량이며—그 결과는 어떻게 활용하느냐에 달려 있습니다.

예시

AIOps 에이전트를 설치하고 MTTR(Mean Time to Repair)이 자동으로 감소할 것이라고 기대할 수 없습니다.

  • 알림은 여전히 같은 방식으로 발생합니다.
  • 런북은 실행할 수 없습니다.
  • 서비스 소유권이나 정의된 SLO(Service Level Objectives)가 없습니다.

해야 할 일

  1. 각 서비스에 대한 SLO를 정의합니다.
  2. 런북을 실행 가능한 프로세스로 전환합니다.
  3. 가시성을 제공합니다.
  4. 변경 가시성을 보장합니다.
  5. 에이전트가 다음을 수행할 수 있도록 다른 역량을 활성화합니다:
    • 배포를 연관 짓기.
    • 해결책 제시.
    • 사람을 포함한 루프에서 실행하기.

기억하세요: 역량은 사람, 프로세스, 도구를 포함하며, 단순히 소프트웨어만을 의미하지 않습니다.

2. 가시성은 핵심 – 에이전트는 컨텍스트가 필요합니다

가시성은 그 어느 때보다 중요합니다. 가시성 논의를 미룰 수 있다고 생각했다면 큰 실망을 맛볼 것입니다. 에이전트가 행동하려면 컨텍스트가 필요하고, 그 컨텍스트는 여러분의 텔레메트리 데이터(메트릭, 로그, 트레이스)에서 나옵니다.

그 컨텍스트를 제공하는 방법

  • 모든 텔레메트리 소스를 집계합니다.
  • CloudWatch가 마음에 들지 않으면 Datadog, Dynatrace, New Relic, Splunk 등 주요 가시성 도구와의 통합을 사용합니다.

목표는 에이전트가 텔레메트리를 통해 사건의 블라스트 반경을 파악하게 하여 시스템 내부 상태를 이해하고 올바른 의도로 행동하도록 하는 것입니다.

예시

상황가시성이 부족한 경우가시성이 충분한 경우
로드 밸런서가 5xx 오류를 감지에이전트는 5xx 카운트만 보고 → 로드 밸런서 또는 서비스 확장을 제안텔레메트리는 느린 SQL 쿼리와 고 CPU 사용으로 인한 RDS 연결 풀 고갈을 보여줍니다. 에이전트는 근본 원인이 RDS 문제이며 ALB가 아니라는 결론을 내립니다.

에이전트가 증상만이 아니라 블라스트 반경을 이해하도록 하세요. 가시성은 그 컨텍스트의 기반입니다.

3. Define golden signals (latency, error rate, saturation, traffic)

Agents reason better on symptoms (effects) rather than raw alerts, which often generate noise. The more symptom data the agent has, the better it can act.

  • Instead of alerts like CPU > 80% or Memory > 75%, define thresholds such as:

    • checkout latency P95 > 2 s
    • error rate > 1 %

  • Alerts are then triggered by increased latency or rising error rates.

Result
The agent can reason about user experience even when infrastructure metrics appear normal, leading to better detection of end‑user‑impacting issues and more effective root‑cause analysis.

3. 골든 시그널 정의 (latency, error rate, saturation, traffic)

에이전트는 원시 알림보다 증상(효과)에 대해 더 잘 추론합니다. 원시 알림은 종종 잡음을 발생시킵니다. 증상 데이터가 많을수록 에이전트는 더 잘 행동할 수 있습니다.

권장 접근 방식

  • CPU > 80% 또는 Memory > 75%와 같은 알림 대신 다음과 같은 임계값을 정의합니다:

    • checkout latency P95 > 2 s
    • error rate > 1 %

  • 그런 다음 알림은 지연 시간 증가 또는 오류율 상승에 의해 트리거됩니다.

결과
인프라 메트릭이 정상으로 보여도 에이전트는 사용자 경험에 대해 추론할 수 있어 최종 사용자에게 영향을 미치는 문제를 더 잘 감지하고 보다 효과적인 근본 원인 분석을 수행합니다.

4. 실행 가능한 가이드 제공 – 위키만이 아니라

조사 안내만 제공하는 런북은 본질적으로 문서에 불과합니다. 에이전트를 진정으로 유용하게 만들려면 실행 가능한 기능을 제공하세요.

구현 방법

  1. Lambda 함수를 사용하여:

    • 텔레메트리 데이터를 가져오기.
    • 복구 작업을 실행하기.

  2. Step Functions(또는 기타 워크플로 엔진)를 사용해 이러한 Lambda 함수를 오케스트레이션하기.

  3. 전제 조건, 안전 작업, 롤백 단계를 명확히 정의하기.

예시 워크플로

단계설명
Lambda 1근본 원인 파악(예: SQS 백로그 과다).
Lambda 2올바른 복구 작업 결정(예: 컨슈머 팟 재시작).
Lambda 3복구 작업 실행(팟 재시작).
Step Functions세 개의 Lambda를 오케스트레이션하고 승인 게이트와 롤백 로직 포함.

사고 발생 시 에이전트는 다음을 수행할 수 있습니다.

  • 큐 깊이와 컨슈머 지연을 가져오기 위해 Lambda 호출.
  • 실패 패턴 분석.
  • (승인 후) Step Functions 워크플로를 추천하거나 실행.

이렇게 하면 에이전트가 수동적인 관찰자가 아니라 능동적인 운영자가 됩니다.

5. 에이전트를 인간처럼 다루기 – 가드레일에 집중하고 전면 권한 부여는 피하십시오

Giving the agent full administrative access is as bad as denying it the permissions it actually needs. The agent requires a reasonable level of access to do its job.

에이전트에게 전체 관리 권한을 부여하는 것은 실제로 필요한 권한을 차단하는 것만큼이나 나쁩니다. 에이전트가 작업을 수행하려면 합리적인 수준의 접근 권한이 필요합니다.

권장 권한 전략

  • 최소 권한 IAM 역할은 여전히 중요합니다.
  • 가드레일: 에이전트가 할 수 있는 일과 할 수 없는 일을 명확히 정의합니다.
    • 진단을 위한 광범위한 접근(읽기 전용).
    • 복구 작업을 위한 엄격한 제어(쓰기/실행).

에이전트를 사용할 때는 모든 가능한 행동을 차단하려 하기보다, 명확히 정의된 레일 안에서 작동하는 자율성에 익숙해져야 합니다.

TL;DR 체크리스트

  • ☐ DevOps 에이전트를 역량(사람 + 프로세스 + 도구)으로 다룹니다.
  • ☐ 모든 소스에서 전체 가시성(메트릭, 로그, 트레이스)을 제공합니다.
  • ☐ 골든 시그널을 정의하고 증상 기반 알림을 사용합니다.
  • ☐ 정적 런북을 실행 가능한 Lambda/Step Functions 워크플로우로 교체합니다.
  • ☐ 가드레일 적용: 진단은 최소 권한, 복구는 제어된 권한.

이러한 실천을 따르면 AWS DevOps Agent의 전체 잠재력을 활용할 수 있습니다—추천 엔진에서 클라우드 환경을 자율적으로, 상황을 인식하는 운영자로 전환하게 됩니다.

6. 에이전트를 위한 KT 계획 수립 – 팀원이 약간의 보살핌이 필요합니다

DevOps 에이전트를 새로운 팀원으로 대하십시오. AWS에 관해서는 슈퍼히어로일 수 있지만, 귀하의 특정 클라우드 구현에 대해서는 아직 초보자입니다.

  • 에이전트를 교육시켜 상세 정보를 제공함으로써 아키텍처, 구현 및 비즈니스 컨텍스트를 완전히 이해하도록 합니다.
  • 방금 팀에 합류한 전문가 수준의 솔루션 아키텍트라고 생각하고, 사전 지식을 가정하지 마세요.
  • 모든 자료를 공유하고 적절히 온보딩하십시오. 바로 화재 진압에 뛰어들게 하지 마세요.

제공할 내용:

  • 아키텍처 다이어그램
  • 문서
  • 서비스 매핑
  • 비즈니스 컨텍스트
  • 알려진 실패 패턴

이를 통해 에이전트는 알림을 관리할 때 보고 작업보다 결제 API를 우선시하고, 알려진 잘못된 복구 작업을 반복하지 않도록 할 수 있습니다.

핵심 요점: 컨텍스트는 잘못된 자동화 작업을 줄여줍니다.

7. 에이전트에게 개발자들이 무엇을 하고 있는지 알려 주세요

예, 이것은 DevOps 에이전트이지만 여전히 개발자들이 작업하고 있는 내용에 대한 가시성이 필요합니다. CI/CD 파이프라인을 연결하고 이 가시성을 에이전트에 제공하세요.

  • 에이전트는 운영 문제를 최근 코드 변경 및 배포와 연관시킬 수 있습니다.
  • 특정 커밋이나 파이프라인 실행을 식별하고 이를 격리하여 근본 원인을 더 잘 이해할 수 있습니다.

Reality check: 오늘날 대부분의 사고는 코드와 배포와 관련되어 있습니다. 옛말이 여전히 맞습니다—만지지 않으면 스스로 고장 나지 않는다.

이것이 도움이 되는 이유

  • 에이전트가 근본 원인을 빠르게 격리할 수 있도록 가속화합니다.
  • 평균 복구 시간(MTTR)을 감소시킵니다.

예시

  1. 특정 시점에 지연 시간이 급증합니다.
  2. DevOps 에이전트가 CI/CD 파이프라인을 확인하고 급증 직전에 발생한 배포를 식별합니다.
  3. 해당 커밋에는 결제 관련 파일에 대한 변경이 포함되어 있습니다.
  4. 에이전트가 추가 메트릭을 가져와 높은 신뢰도로 연관성을 확인하고, 최근 배포가 알림의 원인임을 결론짓고 롤백을 권장합니다.

CI/CD 컨텍스트가 없었다면 에이전트는 인프라 문제를 조사하는 데 시간을 낭비했을 것이며, 이는 MTTR을 증가시켰을 것입니다.

8. 에이전트가 성장할 때까지 손을 잡아 주세요 – 인간‑인‑루프(Human‑in‑the‑Loop)부터 시작하기

초기에는 여러분이 많이 관여해야 합니다—첫날부터 완전 자율적인 에이전트를 현실적으로 기대할 수 없습니다.

  • 에이전트의 행동을 관찰하고, 상황을 설명하며, 에이전트가 실행할 수 있는 상세한 권고안을 제공합니다.
  • 모든 복구 작업은 초기 단계에서 승인 절차를 거치도록 해야 합니다.

신뢰 구축

  • 적절한 가드레일을 마련하면서 점진적으로 자율성을 높여갑니다.
  • 채팅 기능을 활용해 세부 정보를 제공하고, 실패 시나리오를 논의하며, 실시간으로 대응 방안을 계획합니다.
  • 잘못된 알림이나 부정확한 근본 원인 분석을 발견하면 에이전트를 바로잡고 왜 동의하지 않는지 설명하여 효과적으로 학습하도록 합니다.

목표: 에이전트가 실패하기를 기다리기보다, 에이전트가 성공하도록 사전에 적극적으로 조치를 취합니다.

예시:

  • 에이전트가 RDS 인스턴스 재시작을 권고합니다.
  • 인간 운영자가 해당 작업을 거부하고, 피크 시간대에 RDS 재시작이 데이터 손실이나 고객 영향을 초래할 수 있음을 설명합니다.
  • 에이전트는 시간 창, 비즈니스 제약 조건, 보다 안전한 대안에 대해 학습합니다.

후기 단계에서는 에이전트가 **무상태 서비스(stateless services)**를 자동으로 재시작할 수 있게 되지만, **데이터 계층 변경(data‑layer changes)**에 대해서는 여전히 승인이 필요합니다. 신뢰는 안내된 자율성을 통해 구축됩니다.

9. 비즈니스 지표를 사용한 에이전트 성과 측정

에이전트는 배포하고 잊어버리는 반짝이는 객체가 아닙니다. 결과를 긍정적으로 개선하지 못한다면 무용지물입니다.

추적해야 할 핵심 지표

  • Mean Time to Resolve (MTTR)
  • Noise reduction (예: 사고당 알림 수)
  • Percentage of root causes identified automatically
  • Percentage of remediations executed by the agent

이러한 지표는 에이전트가 실제 가치를 제공하고 있는지 파악하는 데 도움이 됩니다.

측정이 없으면 의미 있는 개선도 없습니다.

예시

MetricBefore AgentAfter Agent
MTTR45 minutes18 minutes
Alerts per incident12035
Auto‑diagnosed incidents0 %40 %
Auto‑remediated incidents0 %20 %

이것이 여러분이 달성해야 할 실제 비즈니스 혜택입니다. 측정 가능한 영향을 보여줄 수 없다면, 에이전트는 단지 반짝이는 데모에 불과합니다.

10. 에이전트 조사 격차를 적극적으로 파악하고 해결하기

DevOps 에이전트는 특히 초기 단계에서는 첫 시도에서 바로 올바르게 동작하지 않을 수 있습니다.

  • 조사 격차를 지속적으로 검토 (예: 놓친 근본 원인, 오탐).
  • 에이전트의 지식 베이스, 가드레일, 자동화 스크립트를 반복적으로 개선.

격차를 체계적으로 해결함으로써 에이전트가 시간이 지날수록 더 신뢰할 수 있고 가치 있게 됩니다.

조사 격차

에이전트가 계속 진행하지 못하는 조사 상황은 다음과 같습니다.

  • 구현 격차
  • 누락된 컨텍스트
  • 텔레메트리 데이터 부족
  • 누락된 기능
  • 권한 문제

이러한 조사 격차를 정기적으로 검토하고 에이전트에 필요한 입력을 제공해야 합니다. 시간이 지나면서 에이전트는 더 효과적이고 똑똑해질 것입니다.

Scenario:
에이전트가 조사를 중단하고 데이터베이스 쿼리 메트릭이 누락되어 근본 원인을 파악할 수 없다고 보고합니다.

Your response:

  1. RDS Performance Insights를 활성화합니다.
  2. 슬로우 쿼리 로그를 추가합니다.
  3. 쿼리 통계를 가져오는 Lambda 함수를 생성합니다.
# Example Lambda function to fetch RDS query stats
import boto3

def handler(event, context):
    client = boto3.client('rds')
    response = client.describe_db_instances()
    # Add logic to retrieve and process Performance Insights data
    return response

Result:
이 추가 컨텍스트를 통해 에이전트는 장시간 실행되는 쿼리를 식별하고 다음과 같은 조치를 제안할 수 있습니다:

  • 인덱스 생성
  • 쿼리 스로틀링

주요 내용

  • 모든 실패는 에이전트의 학습 데이터 포인트이며, 이를 포기하거나 비난할 이유가 아닙니다.
  • AWS DevOps 에이전트와 지속적으로 진화하여 더 큰 자동화와 인사이트를 향한 여정을 함께하세요.
Back to Blog

관련 글

더 보기 »