How Cornerstone OnDemand cut database diagnosis by 78% with Amazon Bedrock

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Cornerstone OnDemand는 Amazon Bedrock과 Strands Agents 기반의 다중 에이전트 시스템 Orion AI를 구축해 데이터베이스 진단 시간을 45분에서 10분으로 줄이고, 운영 조정과 팀 간 인계를 자동화했다.

📌 핵심 요약

• 186개국에서 1억 4,000만 사용자에게 인력 준비도 솔루션을 제공하는 Cornerstone OnDemand는 3명으로 구성된 팀이 6개월 동안 Orion AI를 구축했으며, 데이터베이스 진단 시간을 45분에서 10분으로 단축해 78% 감소를 달성했다.
• Orion AI는 Amazon Bedrock과 Strands Agents를 사용하며, 중앙 메타 오케스트레이터가 13개 도메인별 에이전트에 작업을 위임한다. 엔지니어는 웹 애플리케이션에서 질문하고 작업을 승인하며, 시스템은 원인 분석과 해결책 추천부터 담당 온콜 엔지니어에게 할당된 Jira 티켓 생성까지 지원한다.
• 데이터베이스 수명주기 작업은 10개 이상의 수동 단계에서 자연어 상호작용 1회로 바뀌었으며, 원문의 결과 표는 이를 70% 감소로 제시한다. SRE 팀과 데이터 팀 사이의 15분 보고 지연은 실시간 전달로 대체됐고, 중복 경보는 중앙값 기준 65% 감소했다.
• 에이전트를 도메인별로 분리하고 키워드 우선 라우팅에 의미 검색을 결합했다. 질의의 약 80%는 메모리 내 키워드 경로에서 1밀리초 미만으로 처리되며, 모호한 요청은 Amazon Titan Text Embeddings V2로 라우팅하고 운영 문서 검색에는 Amazon Bedrock Knowledge Bases를 사용한다.
• Orion AI는 Amazon ECS에서 실행되며 공유 도구에는 MCP, 다른 데이터 소스에는 직접 SDK 또는 REST API 연결을 사용한다. 대화 맥락은 세션 내·세션 간·에이전트 간 메모리로 관리하고, 메모리 조회에는 500밀리초 제한과 4,000토큰 예산을 적용하지만 실시간 지표 요청은 메모리를 우회해 현재 시스템 데이터를 읽는다.

🧩 주요 포인트

1. 진단·해결책 추천·Jira 할당을 하나의 흐름으로 연결 → 개별 분석 시간뿐 아니라 수동 조정과 팀 간 인계 부담도 축소.
2. 개 도메인별 에이전트와 키워드·의미 검색의 결합 → 도구 선택 범위를 좁히면서 빈번한 요청의 속도와 모호한 요청의 정확성을 함께 추구.
3. 대화 메모리와 실시간 시스템 조회의 역할 분리 → 대화의 연속성을 유지하면서 과거 맥락이 현재 진단에 섞이는 위험을 완화.

🧠 상세 정리

1. 수동 조사와 팀 간 조정에 묶여 있던 데이터 운영

Cornerstone OnDemand는 186개국에서 1억 4,000만 사용자에게 인력 준비도 솔루션을 제공하며, Enterprise DataOps 팀은 Orion AI 도입 전까지 주로 문제가 발생한 뒤 대응하는 방식으로 운영됐다. 데이터베이스 성능 조사에는 사건당 약 45분이 걸렸고, 엔지니어는 여러 도구와 시스템 뷰를 오가며 로그를 대조한 뒤 다른 팀으로 작업을 넘겨야 했다. 데이터베이스 수명주기 작업도 연결 설정부터 상태 전달까지 10개 이상의 수동 단계를 요구했다. SRE 팀과 데이터 팀 사이에는 15분의 보고 지연이 있었으며, 중복되거나 서로 겹치는 경보가 중요한 신호를 가렸다. 이 문제들이 함께 작용하면서 엔지니어의 시간이 실제 문제 해결보다 수동 조사와 업무 조정에 소모됐다는 것이 원문의 출발점이다.

2. Orion AI의 구성과 측정된 도입 성과

Cornerstone은 중앙 조정 에이전트인 메타 오케스트레이터가 전문 자식 에이전트에 작업을 위임하는 허브 앤드 스포크 구조로 Orion AI를 설계했다. 엔지니어는 기존 운영 업무를 조정하는 웹 애플리케이션에서 질문하고 작업을 승인하며, 에이전트는 인프라 모니터링, 데이터베이스 진단과 수명주기 운영, 고객 분석, 지식 기반 지원을 담당한다. 구축 원칙은 AWS 공동 책임 모델 아래의 데이터 프라이버시와 기존 운영 도구와의 깊은 통합이었고, Amazon Bedrock은 기반 모델에 대한 관리형 접근을, Strands Agents는 오케스트레이션 계층을 제공했다. 3명으로 구성된 팀이 6개월 동안 시스템을 구축했으며, 진단 시간은 45분에서 10분으로 줄어 원문 기준 78% 감소했다. 결과 표는 수명주기 작업이 10개 이상의 수동 단계에서 상호작용 1회로 바뀐 성과를 70% 감소로 제시하고, 보고 지연의 실시간 전환과 중복 경보의 중앙값 기준 65% 감소도 함께 보고한다. 원문은 진단 정확도 역시 개선됐다고 설명하지만 별도의 정확도 수치는 제시하지 않는다.

3. 성능 진단에서 해결과 수명주기 운영까지 이어지는 흐름

기존 성능 조사에서는 엔지니어가 문제가 발생한 SQL Server 인스턴스에 직접 연결한 뒤, 시스템 뷰에서 차단 체인과 대기 유형을 조회하고 로그를 대조해 장시간 실행 쿼리를 찾아야 했다. 이렇게 모은 증거를 연결해 근본 원인 가설을 세우는 과정에 사건당 평균 약 45분이 소요됐다. Orion AI에서는 서로 다른 조사 단계를 맡은 세 전문 에이전트가 분석을 분담하며, 진단 이후에도 근본 원인을 식별하고 해결책을 추천한 다음 필요한 내용이 채워진 Jira 티켓을 담당 온콜 엔지니어에게 할당한다. 원문은 이 과정에서 네 단계의 수동 인계가 하나의 상호작용으로 합쳐졌다고 설명한다. 데이터베이스 수명주기 작업에서도 Orion AI가 적절한 도구와 데이터 소스를 선택하고 여러 시스템에 질의를 실행한 뒤 결과를 검증해 통합된 응답을 반환한다. 따라서 엔지니어의 역할은 Orion AI에 자연어로 요청하고 돌아온 분석 결과를 확인하는 형태로 바뀐다.

4. 실시간 가시성과 경보 피로 감소

Orion AI는 주기적인 수동 확인을 여러 시스템에 걸친 지속적인 가시성으로 대체해 SRE 팀과 데이터 팀 사이에 있던 15분의 보고 지연을 없앴다. 이는 진단 시간을 줄이는 것과 별개로, 관련 팀이 운영 상태를 전달받는 시점을 실시간으로 바꾼 성과다. 경보 처리에서는 중복 제거, 임계값 필터링, 여러 신호 사이의 상관관계 분석을 사용해 중복 경보를 중앙값 기준 65% 줄였다. 원문은 이전에 경보가 10개 발생했다면 이제는 그중 3~4개만 엔지니어에게 전달된다고 설명하며, 이 수치는 모든 상황에 동일하게 적용되는 고정 비율로 제시되지는 않는다. 걸러진 경보는 중간 경보 계층을 거치지 않고 책임 있는 팀으로 직접 전달되므로, 신호 선별과 담당 팀 연결이 같은 운영 흐름 안에서 이뤄진다.

5. 도메인 분리·혼합 라우팅·최신 데이터 우선의 설계 원칙

첫 번째 설계 원칙은 작업 난이도가 아니라 운영 도메인을 기준으로 에이전트를 나누는 것으로, 각 에이전트가 한 영역에 필요한 좁은 범위의 도구 통합만 갖도록 한다. 원문은 이렇게 모델의 맥락을 집중시키면 하나의 범용 에이전트에 모든 일을 맡기는 방식보다 도구 선택의 정확성을 높일 수 있다고 설명한다. 두 번째 원칙은 예측 가능한 요청을 키워드로 빠르게 분류하고, 의도가 모호한 요청에만 의미 검색을 적용하는 것이다. 이 선택은 빠른 처리와 어려운 질의의 정확성 사이에서 균형을 추구한다. 세 번째 원칙은 대화 맥락의 범위를 관리하되 현재 운영 상태를 묻는 요청에서는 메모리를 우회하고 실시간 데이터를 읽는 것이다. 지속적인 기억은 여러 차례 이어지는 대화를 지원하지만, 실시간 진단에서는 오래된 데이터가 현재 상태에 섞이지 않도록 별도의 조회 경로를 사용한다.

6. Amazon ECS와 Strands Agents로 구현한 허브 앤드 스포크

Orion AI는 Amazon Elastic Container Service인 Amazon ECS에서 컨테이너 서비스로 실행되며, 웹 애플리케이션이 사용자 요청을 적절한 에이전트로 보내고 필요한 도구를 호출해 응답을 조립한다. Strands Agents의 Agent 클래스는 중앙 메타 오케스트레이터와 전문 에이전트 모두의 구성 요소이며, 도구는 @tool 데코레이터를 붙인 일반 Python 함수로 정의된다. 함수의 타입 힌트와 문서 문자열에서 도구 명세를 도출하므로 별도의 스키마를 유지할 필요가 없고, BedrockModel은 각 에이전트가 사용하는 Amazon Bedrock 모델을 감싸며 MCPClient는 외부 도구 서버 연결을 맡는다. 중앙의 TaskExecutor는 도메인 도구 없이 find_relevant_agents와 call_agent 같은 라우팅 도구, emit_plan_step과 emit_confirmation_gate 같은 흐름 제어 도구만 보유한다. 전문 에이전트는 데코레이터 기반 등록 체계에서 필요할 때 지연 로딩되며, 각자 모델·도메인 도구·전용 시스템 프롬프트를 갖는다. 중앙 에이전트가 call_agent로 전문가를 호출하면 해당 에이전트가 독립적으로 도구 호출을 수행하고 종합한 텍스트를 반환하며, 중앙에서 이를 최종 응답으로 묶는다.

7. 키워드 우선 라우팅과 운영 문서 기반 응답

Orion AI의 라우팅은 키워드를 우선 적용하고 필요한 경우 의미 검색으로 전환하는 혼합 방식이다. 질의의 약 80%는 메모리 내 키워드 처리 경로에서 1밀리초 미만으로 분류되며, 이 수치는 전체 응답 생성 시간이 아니라 해당 라우팅 경로의 처리에 관한 설명이다. 키워드만으로 의도를 결정할 수 없을 때는 Amazon Titan Text Embeddings V2를 이용한 의미 검색으로 적절한 에이전트를 선택한다. 원문은 모델의 AWS 리전별 가용성에 대해서는 Amazon Bedrock의 지원 모델 정보를 참조하도록 안내한다. 직접 도구를 호출하는 방식이 적절하지 않을 때는 대체 처리 흐름에서 완전관리형 검색 증강 생성 기능인 Amazon Bedrock Knowledge Bases가 운영 문서를 검색한다. 이를 통해 응답이 맥락 없이 생성되는 대신 승인된 운영 절차에 근거하도록 구성했다.

8. 13개 전문 에이전트와 SQL Server 조사 단계의 경계

Orion AI는 13개 도메인별 에이전트를 사용하며, 원문은 SQL Server를 담당하는 세 에이전트로 역할 분리 방식을 구체적으로 보여준다. 데이터베이스 진단 에이전트는 차단 체인, 대기 유형, 장시간 실행 쿼리를 드러내고 기술적 발견을 업무 영향과 해결 권고로 바꿔 현재 무슨 일이 일어나며 무엇을 의미하는지 설명한다. 세션 차단 분석 에이전트는 추론 모델로 여러 단계의 조사를 수행해 차단 체인을 근본 차단 주체까지 추적하고, 즉각적인 세션 종료부터 장기적인 아키텍처 수정까지 우선순위를 정한 권고를 제공한다. 실시간 SQL 진단 에이전트는 Cornerstone의 DATAOPS API를 통해 SQL Server 인스턴스를 직접 조회해 현재의 차단 데이터와 CPU 사용량이 높은 세션을 분석한다. 나머지 에이전트도 인프라 모니터링, 운영 분석, 데이터베이스 수명주기 관리, 고객 분석, 운영 절차 문서 검색, 알림 라우팅, 복합 질의 분해, Availability Group 리스너 확인, 모델 연결 사전 준비처럼 좁은 책임 범위를 따른다. 이 구성은 현상과 영향, 근본 원인, 현재 상태를 각각 맡겨 조사 단계의 경계를 명확하게 만든다.

9. 공유 도구의 MCP 연결과 직접 API 접근

Orion AI는 여러 에이전트가 공유하는 도구에는 Model Context Protocol인 MCP를 사용하고, 공유 인터페이스가 필요하지 않은 데이터 소스에는 SDK 또는 REST API를 직접 호출한다. 실시간 SQL 진단 같은 공유 기능에서는 Strands의 @tool 함수가 MCPClient를 통해 스트리밍 가능한 HTTP로 Portal-Tools MCP 서버를 호출하며, 이 서버가 SQL Server와 DATAOPS API에 접근한다. Jira 통합도 외부 Atlassian MCP 도구를 사용하는 동일한 접근 방식을 따른다. 반면 지표와 대시보드, 온콜 일정에는 직접 연결을 사용하고, Amazon Bedrock Knowledge Bases에는 AWS SDK for Python인 Boto3로 접근한다. 이 분리는 각 데이터 소스에 맞는 가벼운 연결 방식을 선택하면서 여러 에이전트가 쓰는 도구를 MCP 서버에 모으기 위한 것이다. 연결에는 TLS를 적용하고 MCP 토큰과 REST API 인증 정보 같은 자격 증명은 에이전트 코드에 내장하지 않고 요청마다 제공한다.

10. 세 계층의 대화 메모리와 실시간 요청의 우회 처리

Orion AI의 중앙 메모리 관리자는 세 계층에서 맥락을 병렬로 읽으며, 각 계층에 별도의 시간 제한과 토큰 할당을 적용한다. 단기 메모리는 동일 세션의 맥락을 기본적으로 저장 시 암호화되는 Amazon DynamoDB에 보관하고, Amazon Nova 2 Lite가 비동기로 생성하는 누적 대화 요약과 함께 사용한다. 장기 메모리는 Amazon Bedrock AgentCore의 메모리 기능을 통해 세션 간 회상을 지원하며 사용자 ID별 네임스페이스로 구분되고, 작업이 끝나면 create_event를 호출해 자동 추출·요약·통합을 시작한다. 세 번째 계층인 에이전트 간 메모리는 한 작업 안에서 하위 에이전트의 발견을 전달하는 일시적인 메모리 내 작업 공간이다. 메모리 관리자는 최근에 가장 적게 사용된 항목을 제거하는 캐시를 활용하면서 전체 조회에 500밀리초의 엄격한 제한과 4,000토큰 예산을 적용한다. 다만 현재 시스템 상태를 묻는 요청에서는 에이전트가 메모리를 완전히 우회하고 실시간 데이터를 읽도록 해 과거 대화 맥락이 현재 진단에 섞이는 것을 방지한다.

🧾 핵심 주장 / 시사점

• Orion AI의 성과는 진단 시간 단축과 팀 간 인계 자동화가 결합된 결과다. 원인 분석 이후의 해결책 추천과 Jira 할당까지 연결한 점이 운영 조정 부담 감소를 설명한다.
• 도메인별 전문화와 혼합 라우팅은 서로 보완한다. 에이전트의 도구 선택 범위를 제한하면서 흔한 요청은 빠르게 처리하고 모호한 요청에는 의미 검색을 적용하는 구조다.
• 대화의 연속성과 진단 데이터의 최신성은 서로 다른 경로로 관리된다. 세 계층의 메모리가 맥락을 제공하더라도 실시간 요청은 직접 조회를 우선하므로, 기억의 재사용이 곧 운영 사실의 재사용으로 이어지지 않는다.

✅ 액션 아이템

• 데이터베이스 진단 45분→10분과 Jira 할당까지 이어지는 Orion AI 흐름의 적용 가능성 검토.
• 수명주기 작업의 10개 이상 단계→상호작용 1회 전환과 결과 표의 70% 감소 사이의 산정 기준 확인.
• 실시간 지표의 메모리 우회 원칙과 500밀리초·4,000토큰 제한의 적용 조건 검토.

❓ 열린 질문

• 수명주기 작업이 10개 이상의 단계에서 상호작용 1회로 바뀐 성과를 70% 감소로 제시한 산정 기준은 무엇인가?
• 질의의 약 80%를 1밀리초 미만으로 처리하는 키워드 라우팅은 어떤 요청 범위에서 유지되는가?
• 실시간 지표 요청을 메모리 우회 대상으로 판단하는 기준과 500밀리초 제한을 넘긴 메모리 조회의 처리 방식은 무엇인가?