본문으로 건너뛰기

Amazon Bedrock 기반 자동 근본 원인 분석 파이프라인

CloudWatch 오류를 Strands 에이전트와 Amazon Bedrock으로 자동 조사해 수 초 내 구조화된 수정 제안을 제공합니다.

이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.

TL;DR

TReNDS는 Amazon Bedrock과 Strands Agents SDK를 결합해 CloudWatch에서 오류를 감지하면 Lambda가 Strands 에이전트를 실행하고, 에이전트가 추가 로그와 GitHub 소스 코드를 읽어 근본 원인을 추적한 뒤 SNS로 구조화된 분석을 전달하는 파이프라인을 운영합니다. 핵심은 모델이 fetch_source_code·fetch_log_context 같은 도구를 자율적으로 호출해 멀티파일 호출 체인과 미묘한 코드 결함까지 추적하는 agentic 조사 루프입니다. 배포 이후 평균 조사 시간은 15~30분에서 1분 이하로 감소했고, 모델 호출 비용은 엔지니어 시간에 비해 매우 낮아 실무 적용 가치가 확인되었습니다.

섹션별 상세

TReNDS 팀은 Amazon EKS에서 운영하는 애플리케이션의 오류 조사 시간을 줄이기 위해 Amazon Bedrock 기반의 에이전트형 자동 원인 분석 파이프라인을 구성했습니다. 로그는 FluentBit로 CloudWatch에 집계되고, CloudWatch의 구독 필터가 오류 패턴을 감지하면 Lambda가 호출되어 Strands Agent를 실행합니다. 에이전트는 추가 로그 맥락과 GitHub 소스 코드를 불러와 모델로 추론하고, SNS로 구조화된 분석 결과를 전파합니다.
아키텍처의 핵심은 모델이 도구 사용을 스스로 결정하는 agentic 접근 방식입니다. Strands Agents SDK로 @tool 데코레이터 방식의 도구를 정의하고, 시스템 프롬프트로 출력 형식을 규정하면 모델이 로그·코드·검색 도구를 조합해 조사 루프를 자율적으로 수행합니다. 이로 인해 모든 조사 경로를 하드코딩할 필요 없이 스택 트레이스에 따라 파일을 읽고 관련 코드를 따라가며 원인을 추적할 수 있습니다.
로그와 소스 코드 접근권한을 에이전트에게 부여하는 것이 핵심 도전 과제이자 가치 원천입니다. 스택 트레이스의 파일 경로와 라인 번호만으로는 원인 규명이 제한적이며, fetch_source_code 도구를 통해 실제 구현을 읽을 수 있어야 구체적 수정 제안이 가능합니다. 동일 컨테이너의 전후 로그를 fetch_log_context로 확보하면 요청 흐름과 예외 발생 직전 상태를 재구성할 수 있습니다.
EKS에서 FluentBit로 CloudWatch에 로그를 전송하고 구독 필터가 Lambda(Strands Agent)를 기동해 Bedrock으로 추론하고 SNS로 결과를 전달하는 전체 아키텍처 다이어그램입니다.
Diagram다이어그램은 로그의 흐름과 에이전트의 도구 호출 관계를 시각적으로 정리해 파이프라인의 입력→처리→출력 단계를 명확히 보여줍니다. 특히 구독 필터가 오류 패턴을 캡처해 Lambda를 호출하고, Lambda 내부에서 Strands Agent가 fetch_source_code와 fetch_log_context 같은 도구를 호출해 Bedrock 모델과 상호작용한 뒤 SNS로 분석을 배포하는 연속성이 잘 드러납니다. 이 구조는 운영 팀이 로그 기반 자동 조사 도입 시 필요한 권한·데이터 레지던시·통합 포인트를 빠르게 파악하는 데 유용합니다.
파이프라인은 네 단계로 동작합니다: CloudWatch 구독 필터가 오류를 감지해 Lambda를 호출하고, Lambda는 이벤트 디코딩 후 Strands Agent를 기동합니다. 에이전트는 필요한 도구를 호출해 추가 로그와 소스 코드를 취합하고 근본 원인을 추론한 뒤 SNS에 구조화된 분석을 게시합니다. 이러한 처리 흐름 덕분에 사람의 수동 조사 없이도 수 초 내에 가설과 수정 방향을 도출할 수 있습니다.
모델 평가와 선택은 도구 사용 신뢰성, 추론 품질, 지연, 비용을 기준으로 이루어졌습니다. Anthropic Claude Sonnet은 다중 파일 추적과 미묘한 코드 결함 탐지에서 가장 우수한 성능을 보였고, Haiku와 Nova 계열 모델들은 비용·지연 요구가 다른 시나리오에서 적절한 선택지로 제시되었습니다. Strands를 통해 모델 교체는 한 줄의 설정 변경으로 가능해 평가와 운영 전환이 단순합니다.
운영 성과로 조사 소요 시간을 15~30분에서 1분 이하로 단축했고, 분석당 Bedrock 추론 비용은 상대적으로 낮아 인적 비용 대비 경제성이 높았습니다. 반복 발생 오류는 DynamoDB 기반의 중복 필터링으로 첫 건만 분석을 트리거하도록 하여 비용과 알림 피로도를 제어합니다. 향후 RAG 기반 내부 런북 연결, 티어별 모델 라우팅, 자동 이슈 및 PR 생성 같은 확장 계획을 통해 진단에서 해결까지의 자동화를 더 진행하려고 합니다.

용어 해설

CloudWatch 구독 필터(CloudWatch subscription filter)
CloudWatch 로그 스트림에서 ERROR/Exception/FATAL 등 패턴을 감지해 Lambda로 매칭된 로그 이벤트를 전달하는 기능으로, 로그 기반 실시간 트리거를 구현할 때 사용하는 표준 방식입니다.
Strands 에이전트(Strands Agent)
Strands Agents SDK를 통해 정의한 도구(tool)를 호출하며 자율적으로 도구 사용과 탐색을 결정하는 에이전트 실행 로직으로, 모델이 로그·코드·외부 도구를 조합해 조사 루프를 수행합니다.
Amazon Bedrock
다수의 foundation model에 대해 통합 API로 접근하게 해주는 AWS 서비스로, TReNDS 사례에서는 모델 호출과 도구 오케스트레이션의 추론 엔진 역할을 맡습니다.
FluentBit
컨테이너 로그를 수집하여 CloudWatch Logs로 전송하는 경량 로그 수집기이며, EKS 환경에서 stdout/stderr 파이프라인을 구성할 때 사용됩니다.
Amazon SNS
에이전트가 생성한 구조화된 분석 결과를 이메일·Slack 등으로 팬아웃 전달하는 퍼블리셔로 사용되는 메시징 서비스입니다.

코드 예제

python
import base64
import boto3
import requests
from strands import Agent, tool

# Retrieve the GitHub token from AWS Secrets Manager
secrets_client = boto3.client("secretsmanager")
github_token = secrets_client.get_secret_value(
    SecretId="trends/github-token"
)["SecretString"]

@tool
def fetch_source_code(file_path: str, repo: str) -> str:
    """Fetch a source file from a GitHub repository.
    Args: file_path: Path to the file in the repository repo: Repository in 'owner/repo' format
    """
    response = requests.get(
        f"https://api.github.com/repos/{repo}/contents/{file_path}",
        headers={"Authorization": f"token {github_token}"}
    )
    if response.status_code != 200:
        return f"Could not fetch {file_path} from {repo}: HTTP {response.status_code}"
    content = base64.b64decode(response.json()["content"])
    return content.decode("utf-8")

에이전트가 스택 트레이스에서 파일 경로와 라인 번호를 발견했을 때 해당 소스 파일을 GitHub에서 읽어 오는 도구입니다. 함수의 docstring과 타입 힌트는 Strands가 모델에게 도구의 입력과 출력을 전달하는 데 사용되며, 모델이 언제 이 도구를 호출할지 스스로 결정합니다. 이 도구 덕분에 에이전트는 단순한 로그 패턴 매칭을 넘어서 코드 흐름을 추적할 수 있습니다.

python
@tool
def fetch_log_context(log_group: str, log_stream: str, timestamp: int, window_seconds: int = 30) -> str:
    """Fetch log lines from the same log stream surrounding an error.
    Args: log_group: CloudWatch Log Group name
          log_stream: Log stream that produced the error
          timestamp: Error event timestamp in milliseconds
          window_seconds: Time window before and after the error
    """
    response = logs_client.filter_log_events(
        logGroupName=log_group,
        logStreamNames=[log_stream],
        startTime=timestamp - (window_seconds * 1000),
        endTime=timestamp + (window_seconds * 1000),
    )
    events = response.get("events", [])
    if not events:
        return f"No log events found in {log_stream} within {window_seconds}s of the error."
    return "
".join(e["message"] for e in events)

CloudWatch에서 전달된 단일 매칭 라인만으로는 원인 규명에 충분하지 않을 때 같은 로그 스트림에서 전후 맥락을 가져와 전체 스택 트레이스와 요청 흐름을 확보하는 도구입니다. log_stream으로 범위를 한정하면 동시성으로 인한 노이즈를 줄이고 동일 컨테이너의 연속된 이벤트를 시간순으로 얻을 수 있습니다. 에이전트는 이 로그 맥락을 바탕으로 추가 도구 호출과 코드 검색 우선순위를 결정합니다.

기술

  • Amazon Bedrock
  • Strands Agents SDK
  • Anthropic Claude Sonnet
  • Amazon CloudWatch
  • AWS Lambda
  • Amazon SNS
  • Amazon EKS
  • FluentBit
  • GitHub
  • Amazon DynamoDB

활용 사례

  • 운영 중인 마이크로서비스에서 발생한 예외를 자동으로 조사해 근본 원인과 관련 소스 코드 컨텍스트·수정 제안을 즉시 제공하는 경우입니다. 에이전트는 스택 트레이스의 경로를 따라 관련 파일을 열람하고 전후 로그를 취합해 실행 흐름을 재구성하므로 엔지니어의 진단 시간을 크게 단축합니다. 이 케이스는 특히 여러 서비스가 얽힌 복합 오류에서 효과가 큽니다.
  • 대규모 오류 발생 시 저비용·고속 우선 처리 루트를 만들어 간단한 패턴은 경량 모델로, 복잡한 사례는 고성능 모델로 자동 라우팅해 비용과 응답성을 최적화하는 티어드 triage 워크플로우입니다. Strands와 Bedrock의 모델 교체 용이성 덕분에 모델 기반 정책을 운영적으로 적용하기가 용이합니다. 결과적으로 비용 제약이 있는 팀도 필수적인 자동화를 도입할 수 있습니다.
  • 에이전트가 수정 제안을 바탕으로 자동으로 GitHub 이슈를 생성하고 PR까지 열어둬 문제 발견에서 수정 배포까지 인간 개입을 줄이는 워크플로우입니다. 논리적 수정 제안이 신뢰할 수준에 도달하면 수작업을 생략해 릴리스 사이클을 단축할 수 있습니다. TReNDS는 이 단계의 자동화를 향후 로드맵으로 계획하고 있습니다.
AI 분석 전체 내용 보기

AI 요약 · 북마크 · 개인 피드 설정 — 무료

출처 · 인용 안내

원문 발행 2026. 08. 08.수집 2026. 08. 08.출처 타입 RSS

인용 시 "요약 출처: AI Trends (aitrends.kr)"를 표기하고, 사실 확인은 원문 보기 기준으로 진행해 주세요. 자세한 기준은 운영 정책을 참고해 주세요.