Harness 기반 AIOps Agent 구축 2

AWS 환경에서 Backend Private 망을 격리하고 생성형 AI로 장애를 분석·복구하는 2편 구현 체계를 정리합니다.

대규모 클라우드 서비스를 운영할 때 가장 까다로운 과제는 애플리케이션 배포 환경의 보안 격리와 장애 발생 시 평균 복구 시간을 줄이는 일입니다.
애플리케이션 자체 로직보다 중요한 것은 신뢰할 수 있는 인프라 경계와 생성형 AI가 결합된 자율 운영 파이프라인을 구축하는 설계입니다.

 

이번 2편에서는 소제목 구분을 최소화하고, 서비스 애플리케이션 영역과 AIOps 운영 영역의 격리부터 Amazon Bedrock 기반 이상 진단과 복구 루프까지 5대 핵심 영역을 심도 있게 분석합니다.

대표 아키텍처. 개발 서버, 서비스 애플리케이션 영역, AIOps 운영 영역 간 통신 및 격리 토폴로지

1. 프로젝트 3대 영역 아키텍처와 엔터프라이즈 망 분리

안정적인 프로덕션 운영을 달성하기 위한 첫 번째 설계 원칙은 개발 환경과 실서비스 환경, 그리고 운영 모니터링 환경의 3대 영역 분리 원칙을 엄격히 적용하는 것입니다.

 

개발 영역은 퍼블릭 서브넷의 EC2 Ubuntu 인스턴스로 독립 배치합니다. 로컬 개인 PC에 무거운 런타임을 설치하는 대신 클라우드 개발 서버에서 Kiro를 통한 원격 SSH 바이브코딩 환경을 구성합니다. 이곳에서 Git 저장소 관리, Python FastAPI 백엔드 개발, Docker Compose를 통한 로컬 단위 테스트, AWS CLI를 통한 클라우드 배포 제어가 일원화되어 실행됩니다.

 

개발 서버의 네트워크 보안은 지정 IP 기반 SSH 접근 규칙으로 철저히 통제합니다. 0.0.0.0/0 전체 개방을 원천 차단하고 사내 공인 IP나 승인된 개발자 IP에 대해서만 22번 포트 인바운드를 허용합니다. 개발 서버는 소스 코드를 빌드하여 도커 컨테이너 이미지를 Amazon ECR에 푸시하고, 정적 프런트엔드 산출물과 런북 문서를 Amazon S3에 업로드하는 게이트웨이 역할을 전담합니다.

 

서비스 애플리케이션 영역과 AIOps 운영 영역은 서로 다른 가상 네트워크(VPC) 또는 격리된 프라이빗 서브넷으로 분리합니다. 운영자가 대시보드를 열어 시스템 로그를 조회하고 AI 진단을 요청하는 트래픽이 실제 고객의 비즈니스 요청과 같은 네트워크 대역을 공유하면 안 됩니다.

 

운영 모니터링 트래픽으로 인한 내부 ALB 대역폭 잠식이나 서비스 컨테이너의 성능 저하를 방지하기 위해 두 영역의 진입점과 백엔드 클러스터를 완전히 물리적·논리적으로 분할합니다. 서비스 컨테이너와 AIOps 컨테이너는 직접 내부 통신을 하지 않고, CloudWatch 텔레메트리 파이프라인과 API Gateway 엔드포인트를 통해서만 상호작용하도록 설계됩니다.

2. Backend Private 인프라 구축과 트래픽 제어

엔터프라이즈 클라우드 아키텍처의 필수 보안 요건은 백엔드 컨테이너와 데이터베이스가 공용 인터넷에 노출되지 않도록 막는 것입니다. 본 프로젝트에서는 유일한 진입점 API Gateway를 통해서만 백엔드 애플리케이션에 도달하도록 트래픽 경로를 단일화합니다.

 

인터넷에서 들어오는 모든 클라이언트 요청은 먼저 Amazon API Gateway REST API 엔드포인트에 도달합니다. API Gateway는 비인가 요청 차단, 요청 속도 제한(Throttling), 웹 애플리케이션 방화벽(WAF) 연동을 1차 방어선으로 수행합니다. 유효한 요청만이 VPC Link를 타고 AWS 백본망 내부로 전달됩니다.

그림 1. ECS Fargate 프라이빗 서브넷 배포 및 네트워크 격리 구조 (출처: AWS Containers Blog)

VPC Link의 종단점은 프라이빗 서브넷에 위치한 Internal ALB 전용 라우팅 계층으로 연결됩니다. 로드 밸런서는 인터넷 연결형(Internet-facing)이 아닌 내부 전용(Internal)으로 생성되므로 외부 공인 IP를 일절 보유하지 않습니다. ALB는 VPC 내부 트래픽만 수신하여 가용영역 A(AZ-A)와 가용영역 C(AZ-C)에 분산된 ECS Fargate 태스크로 부하를 고르게 분배합니다.

 

컨테이너 오케스트레이션을 담당하는 ECS Fargate 태스크 정의에는 Public IP 할당 완전 차단 옵션이 적용됩니다. 태스크가 기동될 때 오직 프라이빗 IP만 탄력적 네트워크 인터페이스(ENI)에 할당됩니다. 외부 사용자가 ALB나 ECS 컨테이너의 IP를 알아내어 직접 접속하려 시도하더라도 네트워크 레벨에서 패킷이 즉시 드롭됩니다.

 

데이터 계층인 Amazon RDS MySQL 역시 프라이빗 서브넷에 격리 배치됩니다. 데이터베이스 보안 그룹은 오직 서비스 ECS 태스크의 보안 그룹에서 인입되는 3306 포트 트래픽만 허용하도록 체이닝 규칙을 정의합니다. 인터넷은 물론이고 개발 서버에서도 프로덕션 RDS에 직접 쿼리를 날릴 수 없으므로 자격 증명 유출 시 발생할 수 있는 대규모 침해 사고를 원천 방어합니다.

3. 서비스 애플리케이션 배포와 5대 결함 주입 테스트

정적 사용자 인터페이스인 프런트엔드는 S3 버킷에 HTML, JS, CSS 산출물을 업로드하고 CloudFront 배포를 연결하여 전 세계 엣지 로케이션에 캐싱합니다. 이때 S3 버킷의 퍼블릭 읽기 권한을 모두 비활성화하고 Origin Access Control(OAC) 정책을 필수 적용합니다. CloudFront를 거치지 않고 S3 직접 객체 URL로 접근하는 시도는 403 Forbidden으로 차단됩니다.

 

// S3 프런트엔드 버킷의 CloudFront OAC 전용 인가 정책
{
  "Version": "2012-10-17",
  "Statement": {
    "Sid": "AllowCloudFrontServicePrincipalReadOnly",
    "Effect": "Allow",
    "Principal": { "Service": "cloudfront.amazonaws.com" },
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::my-service-frontend-bucket/*",
    "Condition": {
      "StringEquals": {
        "AWS:SourceArn": "arn:aws:cloudfront::123456789012:distribution/EDFDVBD6EXAMPLE"
      }
    }
  }
}

AIOps 시스템을 검증할 때 가장 큰 난관은 프로덕션에서 실제 장애가 발생하기 전까지 AI 엔진의 진단 정확도를 시험하기 어렵다는 점입니다. 이를 해결하기 위해 백엔드 코드 내부에 의도적 장애 주입 API 세트를 사전에 빌드하여 배포합니다. 운영자가 통제된 환경에서 결함을 발생시키고 모니터링 알람과 AI 에이전트의 연쇄 반응을 체계적으로 관측합니다.

엔드포인트 경로	HTTP 메서드	주입 결함 시나리오 및 AIOps 관측 목적
/health	GET	ALB 및 ECS 타깃 그룹의 헬스체크 정상 상태 주기적 검증
/ops/delay	POST	비동기 sleep 지연을 발생시켜 API Gateway 29초 타임아웃 및 레이턴시 스파이크 유발
/ops/error	POST	HTTP 500 내부 에러 예외를 강제 발생시켜 ALB 5xx 에러 카운트 알람 발동
/ops/cpu-load	POST	멀티스레드 무한 연산으로 vCPU 사용률 95% 도달 및 ECS 오토스케일링 관측
/ops/db-error	POST	RDS DB 커넥션 풀 고갈 및 락 쿼리를 유도하여 DB 병목 현상 격리

예를 들어 POST /ops/error를 호출하면 애플리케이션 코드가 명시적 런타임 예외를 발생시키며 즉시 스택 트레이스를 표준 에러 출력으로 쏟아냅니다. 타깃 그룹은 이를 5xx 에러로 집계하고, POST /ops/cpu-load는 컨테이너의 연산 스레드를 점유하여 헬스체크 응답 지연을 유발합니다. 이러한 시뮬레이터가 갖춰져 있어야 AI 에이전트가 단편적 증상 뒤에 숨은 최초 결함을 구분할 수 있는지 객관적으로 평가할 수 있습니다.

4. Observability 텔레메트리 수집과 CloudWatch 경보 연동

AIOps 에이전트의 추론 품질은 입력되는 텔레메트리 데이터의 해상도에 의해 결정됩니다. ECS Fargate 환경에서는 클러스터 설정에서 Container Insights 메트릭 수집 옵션을 활성화하여 컨테이너 단위 CPU, 메모리 사용량, 네트워크 I/O 지표를 1분 단위 시계열 데이터로 수집합니다.

 

애플리케이션이 뿜어내는 로그 스트림은 awslogs 로그 드라이버를 통해 Amazon CloudWatch Logs의 지정된 로그 그룹으로 스트리밍됩니다. 로그 그룹에는 단순 저장을 넘어 특정 에러 패턴을 계측하는 CloudWatch 지표 필터를 구성합니다. [ERROR]나 Traceback, ConnectionRefusedError 같은 핵심 장애 키워드가 탐지될 때마다 사용자 지정 메트릭 카운트를 증가시킵니다.

 

로드 밸런서 계층에서는 AWS/ApplicationELB 네임스페이스의 HTTPCode_Target_5XX_Count 지표를 지속 모니터링합니다. 정상적인 서비스라면 5xx 에러가 발생하지 않아야 하므로, 1분 평가 주기 내에 5xx 에러 카운트가 5건 이상 발생하는 즉시 CloudWatch Alarm 임계치 설정이 작동하여 경보 상태(ALARM)로 전환됩니다.

 

경보 이벤트는 Amazon EventBridge 또는 SNS를 통해 AIOps 백엔드의 웹훅 수신기로 비동기 전달됩니다. 이때 경보 메타데이터에는 장애가 발생한 리소스 ARN, 메트릭 통계치, 최초 경보 발동 시각이 포함됩니다. AIOps 백엔드는 이 트리거를 신호탄으로 삼아 즉각적인 로그 번들링과 Bedrock 진단 워크플로우를 개시합니다.

5. Amazon Bedrock 기반 AIOps 자율 진단과 런북 복구 체계

경보를 수신한 AIOps Backend는 단편적인 재기동 스크립트를 바로 돌리지 않습니다. 파운데이션 모델 추론을 전담하는 Claude 3.5 Sonnet 추론 파이프라인을 호출하여 다각적인 인과관계 분석에 돌입합니다.

그림 2. Amazon Bedrock Agent Runtime 추론 오케스트레이션 플로우 (출처: AWS Documentation)

AIOps Backend는 장애 직전 5분간의 CloudWatch 로그 스트림과 RDS 세션 수, ALB 응답시간 지표를 번들링하여 Bedrock Agent 프롬프트에 주입합니다. Claude 3.5 Sonnet은 단순한 결과 증상(예: 502 타임아웃)과 발단 원인(예: DB 커넥션 고갈)을 분리하며 장애의 근본 원인(RCA) Evidence 도출을 수행합니다. 모델은 분석 결과에 실제 에러 로그 라인과 타임스탬프를 명확한 증거로 박아 넣어 답변의 환각을 방어합니다.

 

// Bedrock Agent 진단 요청 및 구조화 Evidence 출력 규격
{
  "incidentId": "INC-20260930-01",
  "status": "ANALYZED",
  "rootCauseAnalysis": {
    "category": "DATABASE_CONNECTION_EXHAUSTION",
    "primaryFailure": "PostgreSQL connection pool maxed out at 100 connections",
    "evidenceSnippet": "2026-09-30T12:45:02Z [ERROR] pool.go:128: connection timeout after 30000ms",
    "confidenceScore": 0.96
  },
  "recommendedAction": {
    "actionId": "ACT-RESTART-POOL",
    "description": "DB 커넥션 풀 강제 반환 및 ECS 태스크 롤링 재기동",
    "requiresHumanApproval": true
  }
}

원인이 식별되면 에이전트는 Amazon Bedrock Knowledge Base를 쿼리합니다. 사내 S3에 적재된 표준 장애 대응 런북 문서를 하이브리드 벡터 검색 RAG 기법으로 조회하여 정확한 복구 절차를 매칭합니다. 과거 유사 인시던트의 포스트모텀과 사내 운영 지침이 프롬프트에 실시간 주입되므로 독자적인 임의 조치가 아닌 사내 규정에 부합하는 대응안이 도출됩니다.

그림 3. Bedrock Knowledge Base RAG 전처리 및 벡터 검색 파이프라인 (출처: AWS Documentation)

복구 조치는 최소 권한 기반 Action Group을 통해 실행 가능한 AWS Lambda 도구로 변환됩니다. 컨테이너 롤링 재배포, ECS 태스크 사양 증설, 악성 클라이언트 IP 차단 명령이 준비됩니다. 그러나 데이터베이스 테이블 삭제나 서비스 중단과 같은 파괴적 작업은 모델이 단독으로 실행하지 못하도록 안전장치를 둡니다.

 

최종 진단 결과와 추천 복구 버튼은 Route 53과 CloudFront, S3로 호스팅되는 운영자 판단 지원 Dashboard에 실시간 표시됩니다. 운영자는 근거 로그(Evidence)와 런북 가이드를 한 화면에서 확인한 뒤 원클릭으로 조치를 승인합니다.

그림 4. AgentCore Action Group 도구 호출 및 엔드포인트 실행 흐름 (출처: AWS Tech Blog)

아키텍처 계층	주요 리소스	AIOps 2편 구현 및 제어 역할
진입점 보안	Route 53 / CloudFront / OAC	정적 자산 캐싱, TLS 종단 및 S3 오리진 무단 접근 차단
망 분리 게이트웨이	API Gateway / VPC Link / Internal ALB	퍼블릭 인터넷과 프라이빗 Fargate 간 안전한 터널링
서버리스 컴퓨팅	Amazon ECS Fargate (AZ-A, AZ-C)	Public IP 배제, 최소 권한 IAM Role 기반 컨테이너 실행
관측성 파이프라인	CloudWatch Logs & Metrics / Container Insights	5대 테스트 API 결함 지표 실시간 수집 및 알람 발송
지능형 진단 엔진	Amazon Bedrock (Claude 3.5 Sonnet)	장애 증거(Evidence) 추출 및 RCA 인과관계 자동 분석
사내 지식 RAG	Bedrock Knowledge Base / OpenSearch	표준 런북 매뉴얼 하이브리드 벡터 검색 및 환각 방지
자율 제어 액션	Bedrock Action Group & Lambda Tool	운영자 승인 기반 컨테이너 조치 및 복구 자동화

이러한 2편의 구현 체계가 완성되면 운영팀은 알람 폭풍 속에서 대시보드를 찾아 헤매던 관행에서 벗어나 인시던트 대응 시간(MTTR) 획기적 단축을 체감하게 됩니다. 1편의 기반 개념과 2편의 실전 구현 설계를 엮어 엔터프라이즈 환경에 바로 투입 가능한 자율 AIOps를 구현할 수 있습니다.