AWS Machine Learning

Cornerstone OnDemand가 Amazon Bedrock으로 데이터베이스 진단 시간을 78% 단축한 방법

Cornerstone OnDemand는 Amazon Bedrock과 Strands Agents 기반의 멀티 에이전트 시스템인 Orion AI를 구축하여 데이터베이스 운영을 대응형 소방식 작업에서 선제적 자동화로 전환했습니다. 3인 팀이 6개월 만에 데이터베이스 진단 시간을 45분에서 10분으로, 즉 78% 단축했습니다. 다른 팀들이 재사용할 수 있는 설계 결정을 확인해 보세요.

Architecture diagram of Orion AI within AWS Cloud. Web Application Users and external integrations (chat, issue tracking, incident management, and metrics dashboards) connect to a TaskExecutor agent running on Amazon ECS inside a virtual private cloud (VPC). The TaskExecutor acts as the meta-orchestrator hub, routing to specialist spoke agents including a Database Diagnostics agent, a Session Blocking Analysis agent, and other agents. A Portal-Tools MCP server inside the VPC connects the agents
이미지 출처 · AWS Machine Learning

Cornerstone OnDemand, Inc. (Cornerstone)는 186개국에서 140 million 명의 사용자에게 서비스를 제공하는 인력 역량 준비 솔루션 분야의 글로벌 리더입니다. 이 회사는 데이터베이스 운영을 대응형 소방식 작업에서 선제적이고 자율적으로 조율되는 워크플로우로 전환하는 멀티 에이전트 AI 시스템을 구축했습니다. Orion AI라 불리는 이 시스템은 Amazon Bedrock 및 Strands Agents(AWS의 오픈 소스 에이전트 오케스트레이션 프레임워크)를 사용하여 전문화된 에이전트들을 조율합니다.

Orion AI 이전에는 Cornerstone의 Enterprise DataOps 팀이 데이터베이스 장애 발생 시 팀 간 인계를 하기 전에 시스템 뷰를 수동으로 조회하고 로그를 교차 참조하는 데 장애당 최대 45분을 소요했습니다. Orion AI 도입 후 데이터베이스 진단 시간은 45분에서 10분으로, 78% 감소했습니다. 3인 팀이 6개월 만에 이 시스템을 구축했습니다.

이 게시물에서는 Cornerstone이 직면한 운영 문제, Orion AI 설계 방식, 측정된 성과, 그리고 다른 팀들이 재사용할 수 있는 설계 결정을 살펴봅니다.

운영상의 과제

Orion AI 이전에는 Cornerstone의 Enterprise DataOps 팀이 대응 방식으로 운영되었으며, 네 가지 반복적인 문제점이 있었습니다:

  • 데이터베이스 성능 조사는 장애당 약 45분이 소요되었으며 여러 도구와 시스템 뷰에 걸쳐 이루어졌습니다.
  • 데이터베이스 수명 주기 워크플로우는 연결 설정부터 상태 업데이트 전달까지 10단계 이상의 수동 작업을 필요로 했습니다.
  • 사이트 신뢰성 엔지니어링(SRE) 팀과 데이터 팀 간의 보고는 15분의 지연을 겪었습니다.
  • 중복되고 겹치는 알림이 불필요한 소음을 만들어 중요한 신호를 묻어버렸습니다.

이로 인해 엔지니어들은 문제 해결 대신 수동 조율에 시간을 소모하게 되었습니다.

해결책: Orion AI

Orion AI는 조율 에이전트(메타 오케스트레이터)가 허브 앤 스포크 토폴로지로 배치된 전문화된 자식 에이전트들에게 작업을 위임하는 멀티 에이전트 시스템입니다. 엔지니어들은 웹 애플리케이션을 통해 이 시스템과 상호작용하며, 이미 운영 업무를 조율하던 동일한 환경에서 질문을 하고 작업을 승인합니다. 에이전트들은 인프라 모니터링, 데이터베이스 진단, 데이터베이스 수명 주기 운영, 고객 분석, 지식 기반 지원을 담당합니다.

구축은 두 가지 원칙에 따라 진행되었습니다. 공유 책임 모델하의 AWS 제어를 통한 데이터 프라이버시, 그리고 기존 운영 도구와의 깊은 통합입니다. Amazon Bedrock은 파운데이션 모델에 대한 관리형 액세스를 제공했고, Strands Agents는 오케스트레이션 계층을 제공했습니다.

결과

Orion AI는 진단 속도와 정확성 모두에서 측정 가능한 개선을 제공했으며, 팀을 수동 조율에서 해방시켰습니다. 수동 병목 지점을 자동화하고 팀 간 워크플로우를 간소화함으로써 Cornerstone은 다음과 같은 성과를 달성했습니다.

지표 이전 이후 개선
데이터베이스 진단 시간 45분 10분 78% 더 빠름
수동 라이프사이클 단계 10단계 이상 1회 상호작용 70% 감소
SRE-to-data-team 보고 지연 15분 실시간(Instantaneous) 실시간(Real-time)
중복 알림 높은 기준 알림 볼륨 필터링됨 65% 감소(중앙값)

더 빠른 성능 문제 해결

데이터베이스 진단 시간을 단축한 것이 지금까지 Orion AI가 달성한 가장 큰 단일 효율성 향상이었습니다. 이전에는 엔지니어들이 영향을 받은 SQL Server 인스턴스에 수동으로 접속하여, 시스템 뷰를 조회해 블로킹 체인과 대기 유형을 확인하고, 로그를 교차 참조하여 장시간 실행되는 쿼리를 분리한 뒤, 증거들을 연관 지어 근본 원인 가설을 세웠습니다. 이 과정은 사건당 평균 약 45분이 걸렸습니다.

Orion AI를 사용하면 세 개의 전문 에이전트가 조사를 나누어 담당하며, 각 에이전트는 서로 다른 단계를 담당합니다. 진단을 넘어, Orion AI는 문제 해결까지 수행합니다: 근본 원인을 식별하고, 수정 방안을 권고하며, 적절한 당직 엔지니어에게 할당된 내용이 채워진 Jira 티켓을 생성합니다. 4단계의 수동 인계 과정이 단일 상호작용으로 축소됩니다.

자동화된 데이터베이스 수명 주기 관리

이전에는 데이터베이스 연결 설정부터 시스템 간 쿼리 실행, 상태 업데이트 전달까지 10단계 이상의 수동 작업이 필요했던 태스크들이 이제는 단일 자연어 상호작용으로 실행됩니다. Orion AI는 적절한 도구와 데이터 소스를 식별하고, 여러 시스템에 걸쳐 쿼리를 실행하며, 결과를 검증하고, 통합된 응답을 반환합니다. 엔지니어의 관점에서 이 작업은 Orion AI에 프롬프트를 입력하고 그것이 보고하는 결과를 검증하는 것으로 축소됩니다.

실시간 모니터링 및 알림 피로 감소

Orion AI는 15분의 SRE-to-data-team 보고 지연을 제거하고, 주기적인 수동 확인을 지속적인 시스템 간 가시성으로 대체했습니다.

Orion AI는 중복 제거, 임계값 필터링, 교차 신호 상관 분석을 통해 중복 알림을 중앙값 기준 65퍼센트 줄였습니다. 이전에 생성된 10개의 알림 중 이제는 3–4개만 엔지니어에게 전달됩니다. 알림은 중간 알림 계층 없이 담당 팀으로 직접 라우팅됩니다.

핵심 설계 원칙

세 가지 결정이 Orion AI를 만들었으며, 여러분도 자신의 멀티 에이전트 프로젝트에 적용할 수 있습니다:

  1. 도메인별로 에이전트 분할, 태스크 복잡도 기준 분할 아님: 각 에이전트는 하나의 운영 도메인을 위한 좁은 범위의 도구 통합을 담당합니다. 이렇게 하면 모델의 컨텍스트가 집중되고 도구 선택의 정확도가 향상되며, 하나의 범용 에이전트에게 모든 것을 요구하지 않게 됩니다.
  2. 키워드 라우팅을 기본으로 사용하고 시맨틱 검색으로 폴백: 예측 가능한 요청은 속도를 위해 키워드로 매칭됩니다. 모호한 요청은 정확도를 위해 시맨틱 검색으로 폴백됩니다. 이를 통해 더 어려운 쿼리에서의 정확성을 희생하지 않고도 지연 시간을 낮게 유지합니다.
  3. 대화 메모리는 세션 범위로 한정하고 실시간 지표에는 메모리를 우회: 영구 메모리는 멀티 턴 대화를 지원하지만, 운영 관련 질문은 항상 현재 시스템 상태를 읽습니다. 실시간 지표에 메모리를 우회하면 오래된 데이터가 실시간 진단을 오염시키는 것을 방지하는 데 도움이 됩니다.

아키텍처 개요

Orion AI는 다음에 컨테이너화된 서비스로 배포됩니다: Amazon Elastic Container Service (Amazon ECS). 사용자는 웹 애플리케이션을 통해 상호작용하며, 이 애플리케이션은 각 요청을 적절한 에이전트로 라우팅하고, 필요한 도구를 호출하며, 응답을 조립합니다. 다음 다이어그램은 이러한 구성 요소들이 AWS Cloud 내에서 어떻게 연결되는지 보여줍니다.

Architecture diagram of Orion AI within AWS Cloud. Web Application Users and external integrations (chat, issue tracking, incident management, and metrics dashboards) connect to a TaskExecutor agent running on Amazon ECS inside a virtual private cloud (VPC). The TaskExecutor acts as the meta-orchestrator hub, routing to specialist spoke agents including a Database Diagnostics agent, a Session Blocking Analysis agent, and other agents. A Portal-Tools MCP server inside the VPC connects the agents

그림 1: Orion AI 아키텍처: Amazon ECS의 메타 오케스트레이터가 요청을 전문 에이전트로 라우팅하며, 에이전트는 Portal-Tools MCP 서버를 통해 데이터 소스에 접근하고 모델, 장기 메모리, 검색 증강 생성을 위해 Amazon Bedrock을 사용합니다

아키텍처 상세 분석

앞서 설명한 설계 원칙은 아키텍처에서 구체적으로 나타납니다. 이 섹션의 나머지 부분에서는 Orion AI의 핵심 구성 요소를 살펴봅니다.

Strands Agents로 허브 앤 스포크 패턴 구축

Orion AI는 소수의 Strands Agents 프리미티브로 토폴로지를 표현합니다. 이 Agent 클래스는 전문 에이전트와 메타 오케스트레이터 모두의 구성 요소입니다. 각 에이전트의 도구는 다음으로 표시된 일반적인 Python 함수입니다. @tool 데코레이터입니다. 이는 도구의 사양(specification)을 함수의 타입 힌트와 독스트링(docstring)에서 도출하므로, 별도로 유지 관리할 스키마가 없습니다. BedrockModel 각 에이전트가 실행되는 Amazon Bedrock 모델을 감싸며, MCPClient 에이전트를 외부 도구 서버에 연결합니다.

토폴로지:

  • 허브는 메타 오케스트레이터(TaskExecutor) 역할을 하는 단일 Strands Agent입니다. 여기에는 도메인 도구가 없으며 라우팅 도구만 있습니다(find_relevant_agents, call_agent) 및 제어 흐름 도구(emit_plan_step, emit_confirmation_gate)요청을 단계별로 추론할 수 있습니다.
  • 스포크는 서로 독립적입니다. Agent 데코레이터 기반 레지스트리를 통해 지연 로딩되는 인스턴스들입니다. 각 인스턴스는 자체 모델, 도메인 도구, 그리고 현지화된 시스템 프롬프트를 가지고 있습니다.

런타임에 허브는 등록된 항목을 통해 스페셜리스트를 이름으로 호출합니다. call_agent 도구입니다. 각 전문 에이전트는 자체 도구 호출 루프를 실행하고 합성된 텍스트를 허브로 반환하며, 허브는 이를 바탕으로 최종 응답을 조립합니다.

하이브리드 라우팅

Orion AI는 키워드 우선 라우팅을 사용하며 시맨틱 검색을 폴백으로 활용합니다. 약 80퍼센트의 쿼리는 인메모리 키워드 패스트 패스를 통해 1밀리초 미만에 처리됩니다. 키워드만으로 의도를 판단하기에 불충분할 경우, 시스템은 다음으로 구동되는 시맨틱 검색으로 폴백합니다. Amazon Titan Text Embeddings V2 의미 기반으로 라우팅합니다. AWS 리전별 모델 가용성에 대한 자세한 내용은 다음을 참조하세요. Amazon Bedrock의 AWS 리전별 지원 모델.

직접 도구 호출이 적절하지 않을 때는 폴백 체인이 활성화됩니다: Amazon Bedrock Knowledge Bases, 완전 관리형 검색 증강 생성(Retrieval Augmented Generation, RAG) 기능은 운영 문서를 검색하여 응답이 맥락 없이 생성되는 것이 아니라 승인된 절차에 근거하도록 합니다.

도메인 특화 에이전트와 그 경계

Orion AI는 13개의 도메인별 에이전트를 사용합니다. 세 개의 SQL Server 에이전트는 도메인 분할이 실제 조사의 단계와 어떻게 대응되는지 보여줍니다.

  • 데이터베이스 진단 에이전트 블로킹 체인, 대기 유형, 장기 실행 쿼리를 파악한 다음, 기술적 결과를 비즈니스 영향으로 변환하여 remediation 권고 사항을 제시합니다. 즉, "무슨 일이 일어나고 있으며 그것이 무엇을 의미하는지"에 답합니다.
  • 세션 차단 분석 에이전트 추론 모델을 활용해 다단계 조사를 수행하여 차단 원인(root blocker)까지의 차단 연쇄를 파악합니다. “이 문제가 왜 발생했는지, 그리고 근본 원인이 무엇인지”에 대한 답을 제공하며, 즉각적인 세션 종료부터 장기적인 아키텍처 수정에 이르기까지 우선순위가 매겨진 권고 사항을 전달합니다.
  • 실시간 SQL 진단 에이전트 Cornerstone의 DATAOPS API를 통해 SQL Server 인스턴스에 직접 질의하여 실시간 차단(blocking) 데이터와 고-CPU 세션 분석을 수행합니다. 즉, "지금 이 순간의 실제 상태"를 알려줍니다.

나머지 에이전트들도 좁은 소유권(narrow ownership)이라는 동일한 원칙을 따릅니다: 인프라 모니터링, 운영 분석, 데이터베이스 라이프사이클 관리, 고객 분석, 런북(runbook) 기반 지식 검색, 알림 라우팅, 복합 쿼리 분해, Availability Group 리스너 확인, 그리고 모델 연결 웜업(warm-up)이 그 대상입니다.

도구 통합 및 서비스 연결

Orion AI는 두 가지 패턴을 통해 데이터 소스에 접근합니다:

  • Model Context Protocol (MCP) 여러 에이전트가 공유하는 도구(예: 실시간 SQL 진단)를 위한 것입니다. Strands @tool 함수가 ...을 호출합니다 MCPClient 스트리밍 가능한 HTTP를 통해 Portal-Tools MCP 서버로 전달되며, 이 서버가 SQL Server와 DATAOPS API에 연결합니다. Jira 통합도 외부 Atlassian MCP 도구를 통해 동일한 방식으로 수행됩니다.
  • 직접 SDK 또는 REST API 호출 공유 MCP 인터페이스가 필요 없는 소스를 위한 것입니다. 여기에는 메트릭과 대시보드, 온콜 일정, 그리고 Amazon Bedrock Knowledge Bases가 포함되며, 이는 다음을 통해 제공됩니다. Python용 AWS SDK (Boto3).

이러한 분리 구조는 각 에이전트가 자신의 소스에 맞는 가장 가벼운 메커니즘을 사용하면서도, 여러 에이전트가 공유하는 도구들은 MCP 서버가 중앙에서 관리하도록 합니다. 이러한 연결은 TLS를 통해 실행되며, MCP 토큰 및 REST API 인증과 같은 자격 증명은 에이전트 코드에 내장되지 않고 요청별로 제공됩니다.

대화형 메모리

Amazon Bedrock AgentCore는 어떤 프레임워크나 모델로도 대규모 에이전트를 구축, 연결, 최적화할 수 있는 플랫폼으로, 교차 세션 메모리 계층을 제공합니다. Orion AI는 중앙 메모리 관리자를 통해 컨텍스트를 조율하며, 이 관리자는 세 개의 계층에서 병렬로 읽어 들이고 각 계층은 자체 타임아웃과 토큰 할당을 갖습니다.

Orion AI는 세 가지 계층에 걸쳐 컨텍스트를 조정합니다. 단기 기억은 동일 세션의 컨텍스트를 Amazon DynamoDB, 기본적으로 저장 시 암호화되며, 다음 요소와 결합됩니다. rolling conversation summary는 Amazon Nova 2 Lite가 비동기적으로 생성합니다. 장기 기억은 Amazon Bedrock AgentCore의 기능인 AgentCore memory를 통해 사용자 ID별로 네임스페이스화된 cross-session recall을 제공합니다. 작업 완료 시 Orion AI는 다음을 호출합니다 create_event 자동 추출, 요약 및 통합을 트리거합니다. 세 번째 계층인 inter-agent memory는 단일 작업 내에서 하위 에이전트 단계 간에 결과를 전달하는 휘발성 인메모리 스크래치패드입니다.

메모리 관리자는 최근 사용 빈도 기반(least-recently-used) 캐시를 활용하여 4,000토큰 예산 내에서 500밀리초의 엄격한 타임아웃 안에 여러 계층에 걸쳐 검색을 수행합니다. 요청이 현재 시스템 상태와 관련된 경우, 에이전트는 메모리를 완전히 우회하여 실시간 데이터를 읽으므로, 오래된 컨텍스트가 실시간 진단을 오염시키지 않습니다.

책임 있는 AI와 가드레일

DataOps 안전성은 어떤 데이터베이스 작업이 서비스 중단을 유발하는지와 같은 도메인 특화 규칙에 의존하기 때문에, 팀은 일반적인 콘텐츠 필터에 의존하는 대신 사용자 지정 가드레일 로직을 구축했습니다. Orion AI는 네 가지 계층에 걸쳐 제어를 적용합니다:

  • 프롬프트 수준의 안전 제약 조건 은 모든 에이전트의 시스템 프롬프트에 삽입되어 위험한 권고(예: 중요한 데이터베이스 프로세스 종료)를 차단하고 서비스 중단을 일으키지 않는 방식을 강제합니다.
  • 사람 개입 확인 게이트 는 파괴적 작업을 일시 중지하고 사용자가 5분 이내에 확인하도록 하며, 타임아웃 시 기본적으로 거부합니다.
  • 입력 검증을 위한 사용자 지정 가드레일 모듈 은 (길이 제한, 프롬프트 및 SQL 인젝션 차단), 출력 정화(비밀 정보 및 개인 식별 정보의 마스킹), 속도 제한, 역할 기반 접근 제어, 요청별 비용 추적을 수행합니다.
  • 라우팅 수준의 보호 는 메모리에서 운영 관련 질의에 답변하는 것을 차단하여, 현재 상태에 관한 질문에는 실시간 도구 실행을 강제합니다.

관찰 가능성

Orion AI는 모니터링과 디버깅을 위해 표준 AWS 관찰 가능성 서비스를 사용합니다. Amazon CloudWatch 는 라우팅 신뢰도, 지연 시간, 에이전트 호출 활동에 대한 지표와 구조화된 로깅을 제공합니다. AWS X-Ray 는 에이전트 실행 전반의 분산 호출을 추적하여 엔드투엔드 요청 경로 가시성을 제공합니다.

교훈

Orion AI를 가능하게 한 설계 결정들은 여러분이 재사용할 수 있는 것들입니다. 도메인별로 에이전트를 분리함으로써 각 에이전트가 단일 모델의 컨텍스트를 비대하게 만들지 않으면서 좁은 범위의 도구 통합을 담당할 수 있었습니다. 기본으로 키워드 라우팅을 사용하고 모호한 요청에 대해서는 의미론적 검색을 폴백으로 사용함으로써 정확도를 희생하지 않고 낮은 지연 시간을 유지했습니다. 대화형 메모리를 세션 범위로 한정하고 실시간 지표에는 이를 우회 적용함으로써 실시간 진단의 신뢰성을 유지했습니다.

팀은 실용적인 인프라 선택도 했습니다. 프로젝트 시작 시점에 Amazon Bedrock AgentCore 런타임(Amazon Bedrock AgentCore의 기능)을 사용할 수 없었기 때문에 컴퓨팅을 Amazon ECS에 배포했으며, 현재는 이를 향후 마이그레이션 옵션으로 평가하고 있습니다. 오늘날 구축하신다면 자신의 스택에 대해 동일한 트레이드오프를 저울질하세요. 지금 안정적이고 사용 가능한 것으로 시작하고, 관리형 기능이 성숙해지면 다시 검토하세요.

결론

Orion AI는 데이터베이스 진단 시간을 45분에서 10분으로 단축했고, 수명 주기 단계의 70 퍼센트를 수동으로 처리해야 하는 부담을 없앴으며, 알림 노이즈를 65 퍼센트 줄였습니다. 3인 팀이 Amazon Bedrock에서 6개월 만에 이를 구현했습니다. 이러한 결과 뒤에 있는 패턴, 즉 도메인 범위 에이전트, 하이브리드 라우팅, 실시간 지표 우회가 적용된 세션 범위 메모리는 다른 운영 팀들도 채택할 수 있는 것입니다.

AWS에서 멀티 에이전트 오케스트레이션을 시작하려면 AWS 솔루션 라이브러리 가이드.


저자 소개

원문 출처

AWS Machine Learning

내용 안내

원문 발행 및 권리는 출처에 있습니다.

기계 번역 · 원문을 참고하세요