AWS에서 에이전트 기반 AI 워크플로우 구축: 프로덕션 자동화용 생성형 AI

AI가 AWS 환경에 무제한 접근 권한을 부여하지 않고도 프로덕션 장애 조사를 도울 수 있을까요?

프로덕션 API에서 HTTP 503 오류가 발생한다고 상상해 보세요. 지연 시간이 증가하고, CPU 사용률이 급증하며, 로그에는 데이터베이스 연결 풀 타임아웃이 표시됩니다.

개발자는 보통 CloudWatch를 열어 로그를 검사하고, 메트릭을 비교하고, 종속성을 조사하고, 다음에 무엇을 할지 결정해야 합니다.

만약 AI 지원 워크플로우가 증거를 수집하고, 장애 상황을 요약하며, 문제 해결 단계를 추천하고, 인간의 승인을 위한 복구 계획을 준비할 수 있다면 어떨까요?

이 튜토리얼에서는 AWS 생성형 AI 서비스와 작은 Python 프로젝트를 사용하여 해당 워크플로우를 구축하는 방법을 탐구합니다.

다룰 내용은 다음과 같습니다:

• 생성형 AI 및 에이전트 기반 워크플로우를 위한 핵심 AWS 서비스.
• 프로덕션 장애 분류(triage)를 위한 참조 아키텍처.
• 실행 가능한 Python 데모.
• Amazon Bedrock 통합.
• 승인 게이트 및 보안 제어 추가.
• 프로덕션 운영에 미치는 실제 영향 측정.

예를 들어, 운영 에이전트는 승인된 메트릭을 수집하고, 실행 매뉴얼(runbook)을 검색하며, 인시던트를 분석하고, 다음 단계를 추천할 수 있습니다.

에이전트가 운영 문제를 추론할 수 있다는 이유만으로 무제한의 AWS 권한을 부여받아서는 안 됩니다.

Amazon Bedrock Knowledge Bases: 조직 컨텍스트

Knowledge Bases는 검색 증강 생성(RAG)을 지원합니다.

내부 실행 매뉴얼, 아키텍처 문서, 인시던트 보고서 및 배포 절차 등 관련 컨텍스트를 제공할 수 있습니다.

이는 모델이 추천을 생성할 때 조직의 문서를 활용하도록 돕지만, 여전히 응답은 검증이 필요합니다.

Amazon Bedrock Guardrails: 안전 제어

Bedrock Guardrails는 콘텐츠 필터링 및 민감 정보 보호를 포함하여 지원되는 사용 사례에 대한 구성 가능한 제어를 제공합니다.

Guardrails는 애플리케이션 검증 및 IAM(Identity and Access Management) 제어와 보완적이며, 이를 대체하지 않습니다.

AWS Lambda: 통제된 도구

AWS Lambda는 메트릭 수집, 승인된 로그 검색, 보고서 생성 또는 승인된 작업을 실행하기 위한 특정 함수를 제공할 수 있습니다.

AI의 추천과 실제로 동작을 수행하는 코드를 분리하여 유지해야 합니다.

AWS Step Functions: 워크플로우 오케스트레이션

AWS Step Functions는 프로세스를 조정하고, 실행 상태를 처리하며, 사람의 승인을 기다리는 워크플로우를 지원할 수 있습니다.

Amazon CloudWatch: 운영 증거

Amazon CloudWatch는 메트릭, 로그, 대시보드 및 알람을 제공합니다.

이는 AI 지원 워크플로우가 분석할 수 있는 운영 증거를 공급합니다.

2. 아키텍처: 인시던트 감지부터 승인된 복구까지

AI 지원 인시던트 트리아지 시스템을 위한 가능한 아키텍처는 다음과 같습니다:

Production Application
         |
         v
...

이것은 참조 아키텍처이며, 자동으로 구성되는 통합이 아닙니다. 관련 API 호출, IAM 역할, 유효성 검사 로직 및 워크플로우 상태를 직접 구현해야 합니다.

중요한 설계 결정 사항은 모델이 조치를 권장하지만, 애플리케이션이 해당 조치가 허용되는지 여부를 결정한다는 것입니다.

3. Python 인시던트 트리아지 데모 구축

시뮬레이션된 프로덕션 원격 측정(telemetry)에서 증상을 식별하는 작은 프로젝트를 만들어 보겠습니다.

샘플 checkout-api의 상태는 다음과 같습니다:

• CPU 활용률: 92%
• 메모리 활용률: 78%
• HTTP 5xx 오류: 45
• P95 지연 시간(latency): 2,400ms
• 데이터베이스 연결 풀 타임아웃

첫 번째 버전에서는 결정론적 Python 규칙을 사용할 것입니다. 이렇게 하면 AWS 자격 증명이나 모델 접근 없이 프로젝트를 실행할 수 있습니다.

단계 1: 프로젝트 생성

aws-ai-incident-triage/
└── incident_triage.py

단계 2: 코드 추가

incident_triage.py를 생성합니다:

import json

incident = {
...

단계 3: 실행

python incident_triage.py

이 첫 번째 버전에는 외부 Python 패키지가 필요하지 않습니다.

단계 4: 출력 검토

출력은 다음과 유사하게 보일 것입니다:

{
  "service": "checkout-api",
  "environment": "production",
...

이 출력은 라이브 AI 모델에 의해 생성된 것이 아니라 결정론적 규칙에 의해 생성됩니다.

이 데모는 증상을 식별하고 다음 단계를 권장합니다. 서비스를 재시작하거나, 인프라를 수정하거나, 프로덕션 변경을 수행하지는 않습니다.

4. 워크플로우를 Amazon Bedrock에 연결하기

다음으로, 규칙 기반 분석을 파운데이션 모델(foundation model)로 대체합니다.

먼저 AWS 자격 증명을 구성하고 선택한 리전에서 계정에 사용 가능한 모델을 선택합니다. 해당 신원이 필요한 Bedrock 권한을 가지고 있는지 확인하십시오.

필요한 경우 AWS SDK for Python을 설치합니다:

python -m pip install boto3

다음 예제는 이전 섹션에서 사용된 incident 딕셔너리가 사용 가능하다고 가정합니다:

import json
import boto3

...

YOUR_SUPPORTED_MODEL_ID를 실제 지원되는 모델 ID로 교체하십시오.

이 코드는 샘플 인시던트를 Amazon Bedrock으로 전송하고 모델의 응답을 출력합니다. 이 코드는 CloudWatch 원격 측정 데이터를 자동으로 검색하거나 복구 조치를 실행하지는 않습니다.

실제 구현을 위해서는, 메트릭과 로그를 수집하고, 정의된 스키마와 모델 출력을 검증하며, 승인된 작업을 제어된 워크플로우로 전달하는 권한이 부여된 Lambda 통합을 추가해야 합니다.

5. 승인 게이트(Approval Gate) 추가하기

모델은 대상 환경에 부적절할 수 있는 유효해 보이는 조치를 제안할 수 있습니다.

애플리케이션 수준의 허용 목록(allowlist)으로 시작하십시오:

APPROVED_ACTIONS = {
    "inspect_logs",
    "collect_metrics",
...

첫 번째 작업은 이 예제 정책에 의해 허용되며, 두 번째 작업은 거부됩니다.

이것은 기본적인 시연일 뿐이며 완전한 권한 부여 시스템은 아닙니다. 프로덕션 코드는 대상 리소스, 매개변수, 호출자 신원(caller identity), 그리고 IAM 권한을 검증해야 합니다.

프로덕션 가용성이나 데이터에 영향을 미칠 수 있는 작업의 경우, 실행 전에 명시적인 인간 승인이 필요한 워크플로우를 사용하십시오.

절대로 프롬프트만으로 보안 경계를 강제하는 것에 의존하지 마십시오.

6. 프로덕션 영향도는 어떻게 측정할 수 있나요?

AI 도입은 기준선(baseline)과 비교하여 평가되어야 합니다.

이것들은 평가 목표이며, 데모에서 측정된 결과는 아닙니다.

7. 해결해야 할 프로덕션 위험 요소 (Production Risks to Address)

에이전트 기반 워크플로우를 배포하기 전에 다음 사항을 계획하십시오:

• 환각 (Hallucinations): 증거 기반의 발견을 요구하고 권장 사항을 검증해야 합니다.
• 프롬프트 주입 (Prompt injection): 로그와 검색된 문서를 신뢰할 수 없는 입력으로 취급해야 합니다.
• IAM 보안 (IAM security): 최소 권한(least-privilege) 역할을 사용하고 범위가 좁은 도구를 활용해야 합니다.
• 신뢰성 (Reliability): 타임아웃, 제한된 재시도(bounded retries), 폴백 동작을 추가해야 합니다.
• 비용 및 지연 시간 (Cost and latency): 불필요한 모델 호출을 제한하고 종단 간 성능을 측정해야 합니다.
• 관측 가능성 (Observability): 도구 호출, 오류, 승인 결정 및 결과를 기록해야 합니다.
• 인간 감독 (Human oversight): 위험하거나 되돌릴 수 없는 변경에 대해서는 승인을 요구해야 합니다.

Bedrock Guardrails가 유용한 추가 제어 기능을 제공할 수 있지만, 이는 보안 설계의 한 계층일 뿐입니다.

8. 구현 로드맵 (Implementation Roadmap)

실용적인 배포는 다음 단계를 따를 수 있습니다:

1. CloudWatch를 통해 승인된 원격 측정 데이터(telemetry)를 수집합니다.
2. 필요한 증거를 검색하기 위한 Lambda 함수를 구축합니다.
3. Amazon Bedrock을 사용하여 증상을 요약하고 다음 단계를 권장합니다.
4. 예상 스키마 및 애플리케이션 정책에 따라 응답을 검증합니다.
5. Step Functions로 워크플로우를 오케스트레이션(orchestrate)합니다.
6. 프로덕션 변경 작업을 수행하기 전에 승인을 요구합니다.
7. 추천 품질, 지연 시간 및 비용을 측정합니다.
8. 내부 런북(runbooks)이 유용한 컨텍스트를 제공할 때 Knowledge Base를 추가합니다.

모델 기반 도구 선택과 다단계 작업 실행이 가치 있는 경우 Bedrock Agents를 사용하십시오. 모델 호출을 포함하는 결정론적 워크플로우는 더 간단한 사용 사례의 경우 보안 및 운영 측면에서 더 쉬울 수 있습니다.

결론 (Conclusion)

에이전트형 AI(Agentic AI)는 단순히 언어 모델을 도구에 연결하는 것에 관한 것이 아닙니다. 유용한 추론을 신뢰할 수 있는 증거, 통제된 실행, 그리고 명확한 권한 경계와 결합하는 것입니다.

Amazon Bedrock은 모델 액세스를 제공하고, Lambda는 제어된 도구를 공급하며, CloudWatch는 운영 증거를 제공하고, Step Functions가 워크플로우를 조정합니다.

저희의 Python 데모는 첫 번째 단계, 즉 프로덕션 변경을 실행하지 않으면서 원격 측정 데이터를 구조화된 발견 및 권장 사항으로 변환하는 것을 보여줍니다.

다음 단계는 워크플로우를 실제 원격 측정(telemetry)에 연결하고, 알려진 사고 사례와 비교하여 테스트하며, 이것이 조사 프로세스를 개선하는지 측정하는 것입니다.

프로덕션 AI의 저의 원칙: 모델이 추천하게 하고, 애플리케이션이 검증하게 하며, 승인된 사람이 중요한 변경 사항을 승인하게 하라.

참고 자료 (References)

• Amazon Bedrock 문서
• Amazon Bedrock Agents
• Amazon Bedrock Guardrails
• AWS Step Functions 수동 승인 워크플로우
• Amazon CloudWatch