Orion AI: Amazon Bedrock 기반 3개 에이전트 시스템으로 데이터베이스 진단 시간 78% 단축

Cornerstone OnDemand는 데이터베이스 운영을 사후 대응적인 문제 해결(reactive firefighting)에서 사전 예방적 자동화로 전환하기 위해 Orion AI를 구축했습니다. 한 팀의 세 명의 엔지니어들은 Amazon Bedrock과 Strands Agents 프레임워크를 사용하여 6개월 만에 데이터베이스 진단 시간을 45분에서 10분으로 단축했습니다. 이 시스템은 순환 종속성(circular dependencies)이나 상태 충돌 없이 세 가지 전문화된 에이전트(진단, 쿼리 생성, 복구/개선)를 조정합니다.

이는 데모가 아닙니다. 실제 데이터베이스 사고를 처리하는 주요 SaaS 제공업체에서 운영 환경(production)으로 실행되고 있습니다.

문제점: 대규모 수동 데이터베이스 진단

Cornerstone의 데이터베이스 운영팀은 익숙한 패턴에 직면했습니다:

• 경고 발생 (Alert fires)
• 엔지니어가 로그와 메트릭을 수동으로 쿼리함
• 엔지니어가 진단용 SQL 작성
• 엔지니어가 결과 해석
• 엔지니어가 복구 방안 결정
• 엔지니어가 수정 사항 실행
• 엔지니어가 사고 기록 (document incident)

각 사이클은 평균 45분이 걸렸습니다. 이를 멀티테넌트 SaaS 플랫폼에서 매일 발생하는 수십 건의 경고에 곱하면, 엔지니어들이 아키텍처 작업 대신 반복적인 진단에 대부분의 시간을 소비하게 됩니다.

팀은 단순히 경고 알림이나 모니터링을 넘어 전체 루프를 처리할 수 있는 자동화가 필요했습니다.

아키텍처: 명확한 경계를 가진 세 가지 에이전트

Orion AI는 데이터베이스 운영을 세 가지 전문화된 에이전트로 분리했으며, 각 에이전트는 좁은 범위의 역할을 수행합니다:

진단 에이전트 (Diagnosis Agent)

• 경고 및 메트릭 수집(Ingests alerts and metrics)
• 문제 패턴 식별
• 검사가 필요한 데이터베이스 구성 요소 결정
• 쿼리 에이전트에 컨텍스트 전달(Hands off context to query agent)

쿼리 생성 에이전트 (Query Generation Agent)

• 진단 컨텍스트 수신
• 안전하고 읽기 전용인 SQL 쿼리 생성
• 실행 전에 쿼리 구문 유효성 검사(Validates query syntax before execution)
• 구조화된 결과를 진단 에이전트에 반환

복구/개선 에이전트 (Remediation Agent)

• 승인된 진단 및 쿼리 결과 수신
• 복구 조치 제안
• 파괴적인 작업(destructive operations)에 대해서는 인간의 승인 필요
• 승인된 수정 사항 실행
• 감사를 위해 모든 작업 기록 (Logs all actions for audit)

에이전트들은 Strands Agents가 관리하는 상태 기계(state machine)를 통해 통신하며, 이는 핸드오프(handoff)를 처리하고 워크플로우 전반의 컨텍스트를 유지합니다.

오케스트레이션 흐름 (Orchestration Flow)

# 간소화된 오케스트레이션 패턴 (개념적)
class OrionWorkflow:
    def __init__(self, bedrock_client, strands_orchestrator):
...

핵심 설계 결정은 다음과 같습니다. 각 에이전트는 구조화된 입력(structured input)을 받고 구조화된 출력(structured output)을 반환합니다. 어떤 에이전트도 다른 에이전트를 직접 호출하지 않습니다. 오케스트레이터가 모든 핸드오프를 처리하고 감사 추적(audit trail)을 유지합니다.

상태 관리 및 컨텍스트 보존 (State Management and Context Preservation)

Orion AI는 Strands Agents를 사용하여 3개 에이전트 워크플로우 전반의 상태를 관리합니다. 각 단계는 다음 단계로 전달되는 아티팩트(artifacts)를 생성합니다:

오케스트레이터는 모든 아티팩트를 연결하는 워크플로우 ID를 유지합니다. 만약 에이전트가 실패하거나 시간 초과(time out)되면, 시스템은 비용이 많이 드는 진단 또는 쿼리 작업을 재실행하지 않고도 마지막 성공 단계부터 재개할 수 있습니다.

보안 경계 및 실패 모드 (Security Boundaries and Failure Modes)

팀은 연쇄 오류(cascading errors)에 대비하여 세 가지 보호 계층을 구축했습니다:

쿼리 안전성 (Query Safety)

• 생성된 모든 SQL은 DML/DDL을 거부하는 파서(parser)를 통과합니다.
• 쿼리 시간 초과 제한(Query timeout limits)이 무분별한 작업을 방지합니다.
• 결과는 설정 가능한 행 제한(configurable row limits)으로 제한됩니다.
• 커넥션 풀링(Connection pooling)은 데이터베이스 과부하를 방지합니다.

복구 게이트 (Remediation Gates)

• 파괴적인 작업(Destructive operations)에는 명시적인 인간의 승인(human approval)이 필요합니다.
• 승인 요청에는 전체 컨텍스트와 예측된 영향이 포함됩니다.
• 승인된 조치는 트랜잭션 경계(transaction boundaries)를 가지고 실행됩니다.
• 롤백 절차는 복구 계획과 함께 생성됩니다.

관측 가능성 (Observability)

• 모든 에이전트 호출은 입력, 출력 및 지연 시간(latency)을 기록합니다.
• 실패한 에이전트 호출은 운영팀에 경고를 발생시킵니다.
• 쿼리 실행 계획은 실행 전에 기록됩니다.
• 복구 조치는 별도의 감사 데이터베이스(audit database)에 기록됩니다.

가장 흔한 실패 모드: 진단 에이전트가 문제를 오분류하여 관련 없는 쿼리를 생성하는 경우입니다. 시스템은 이 문제를 해결하기 위해 쿼리 에이전트가 '데이터 부족(insufficient data)' 결과를 반환하도록 허용하며, 이는 수동 진단을 위한 폴백(fallback)을 트리거합니다.

배포 구조 (Deployment Shape)

Cornerstone은 AWS 인프라에서 Orion AI를 실행합니다:

• LLM 추론용 Amazon Bedrock (Claude 모델)
• 오케스트레이션 및 상태 관리를 위한 Strands Agents
• 감사 로그 및 워크플로우 상태용 Amazon RDS
• 에이전트 실행을 위한 AWS Lambda
• 알림 수집을 위한 Amazon EventBridge

팀은 데이터베이스 사고가 간헐적으로 발생하는(bursty) 특성 때문에 에이전트 실행에 Lambda를 선택했습니다. 대부분의 시간 동안 시스템은 유휴 상태입니다. 알림이 발생하면, Lambda는 사전 프로비저닝된 용량 없이도 여러 동시 워크플로우를 처리하도록 확장됩니다.

각 에이전트는 자체 Lambda 함수와 별도의 IAM 역할을 사용하여 실행됩니다. 진단 에이전트는 메트릭에 대한 읽기 전용(read-only) 액세스를 가집니다. 쿼리 에이전트는 읽기 전용 데이터베이스 자격 증명을 가집니다. 복구(remediation) 에이전트는 쓰기 액세스 권한을 가지지만, 승인 후에만 실행됩니다.

결과 및 트레이드오프 (Results and Trade-offs)

운영 환경에서 6개월 후:

• 진단 시간이 45분에서 10분으로 단축 (78% 감소)
• 사고의 60%가 이제 인간의 개입 없이 해결됩니다.
• 엔지니어들은 반복적인 진단에 쓰는 시간을 줄였습니다.
• 시스템은 하루 평균 40개 이상의 알림을 자동으로 처리합니다.

팀이 수용한 트레이드오프:

안전을 위한 지연 시간 (Latency for Safety)
시스템은 검증 단계, 승인 게이트(approval gates), 구조화된 핸드오프를 포함하기 때문에 2분 대신 10분이 소요됩니다. 팀은 속도보다 정확성을 선택했습니다.

제한적인 복구 범위 (Limited Remediation Scope)
복구 에이전트는 미리 정의된 일련의 작업(서비스 재시작, 캐시 지우기, 연결 풀 조정)만 처리합니다. 복잡한 수정은 여전히 인간 엔지니어를 필요로 합니다.

모델 의존성 (Model Dependency)
시스템은 Amazon Bedrock의 가용성에 의존합니다. 만약 Bedrock에 장애가 발생하면, Orion AI는 수동 진단으로 폴백합니다. 팀은 Bedrock 상태를 모니터링하며 수동 폴백을 위한 운영 절차서(runbooks)를 갖추고 있습니다.

기술적 평가 (Technical Verdict)

다음과 같은 경우에 이 패턴을 사용하세요:

• 반복적이고 예측 가능한 패턴을 따르는 운영 워크플로우가 있을 때
• 진단(diagnosis), 분석(analysis), 복구(remediation) 사이에 명확한 경계를 정의할 수 있을 때
• 규정 준수를 위해 감사 추적(audit trails) 및 승인 게이트(approval gates)가 필요할 때
• 운영 역량을 확장해야 하는 소규모 팀이 있을 때

다음과 같은 경우에는 이 패턴을 피하세요:

• 장애 상황이 매우 가변적이어서 창의적인 문제 해결 능력이 필요할 때
• 10분간의 진단 지연 시간(diagnosis latency)을 감수할 수 없을 때
• 데이터베이스 작업에 복잡한 다단계 트랜잭션(multi-step transactions)이 필요할 때
• 오케스트레이션 에이전트 워크플로우를 실행할 인프라가 부족할 때

Cornerstone의 사례 연구는 실패 모드(failure modes)를 염두에 두고 설계하고, 명확한 에이전트 경계를 유지하며, 속도와 안전성 사이의 트레이드오프(trade-offs)를 수용한다면 다중 에이전트 시스템이 프로덕션 환경에서 작동한다는 것을 보여줍니다. 3인 팀은 좁은 문제 영역에 집중하고 기존 프레임워크(Bedrock, Strands Agents)를 재사용했기 때문에 오케스트레이션을 처음부터 구축하는 대신 6개월 만에 이를 구현할 수 있었습니다.

출처 링크

• AWS Blog: Cornerstone OnDemand가 Amazon Bedrock을 사용하여 데이터베이스 진단 시간을 78% 단축한 방법