How nOps shipped FinOps agents 75% faster with Amazon Bedrock AgentCore

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

nOps는 FinOps 에이전트 Clara를 Amazon Bedrock AgentCore와 Databricks 중심의 단일 관리형 아키텍처로 전환해 출시 기간을 75% 단축하고 응답 품질과 도구 안정성을 높였다.

📌 핵심 요약

• nOps는 AWS, Google Cloud Platform, Microsoft Azure의 약정 최적화를 지원하며, 현재 40억 달러가 넘는 클라우드 지출을 관리하는 고객들에게 지속적인 비용 절감과 위험 완화 기능을 제공한다.
• 기존 Clara는 Kubernetes, Amazon Bedrock 모델 호출, LangChain/LangGraph 오케스트레이션, 웹 API 도구 래퍼로 구성됐으나 긴 컨텍스트로 인한 지연, 여러 운영 계층의 복잡성, 분석 의미 계층 부재라는 한계가 있었다.
• 새 구조는 Amazon Bedrock AgentCore의 단일 Strands 에이전트, Databricks Lakehouse Metric Views의 관리형 분석 의미 계층, Databricks Lakebase의 영속 상태 저장, Vercel 기반 웹 애플리케이션을 결합했다.
• Clara는 캔버스 단위 메모리, 사전 Guardrails 검사, 테넌트 정책, 스트리밍 응답과 비동기 분석 경로를 통해 세션 지속성, 다중 테넌트 격리, 장시간 작업의 실시간 사용자 경험을 지원한다.
• nOps는 출시 소요 시간이 10~12개월에서 4개월로 줄어 75% 단축됐고, 정확성은 81.7%, 유용성은 79.4%를 기록했으며, 도구 실패율은 7.49%에서 0.92%로 감소했다고 밝혔다.

🧩 주요 포인트

1. API 중심 데이터 접근을 Databricks Lakehouse Metric Views의 단일 지표 정의로 대체해 대화형 답변과 대시보드가 같은 재무 논리를 사용하도록 만들었으며, 이는 분석 결과의 일관성과 질의 단순화로 이어졌다.
2. 여러 자체 관리 계층 대신 Amazon Bedrock AgentCore의 단일 Strands 에이전트와 공유 런타임을 채택해 에이전트 간 전달 지연과 운영 부담을 줄였으며, 그 결과 출시 기간이 75% 단축되고 4~6개의 운영용 에이전트를 제공할 수 있게 됐다.
3. 캔버스 단위 메모리와 Databricks Lakebase의 영속 상태, 비동기 워크플로를 결합해 대화에서 생성된 분석을 지속적이고 공유 가능한 결과로 보존하면서 장시간 분석도 사용자 인터페이스를 차단하지 않도록 구성했다.

🧠 상세 정리

1. nOps의 FinOps 사업과 전환 목표

nOps는 인공지능 기반 클라우드 최적화 솔루션으로, AWS, Google Cloud Platform, Microsoft Azure 전반의 약정 최적화를 관리하는 고객을 지원한다. Reserved Instances와 AWS Savings Plans 같은 약정을 지속적으로 최적화해 절감 효과를 높이고 위험을 줄이며, 수작업 FinOps 운영 부담을 자동화하는 것이 제품의 핵심 역할이다. 현재 nOps가 지원하는 고객의 관리 대상 클라우드 지출은 40억 달러를 넘는다. 이번 전환의 목표는 복잡해지는 분석 요구를 수용하면서 제품 출시 속도와 응답 품질을 높이고, 인프라 운영 복잡성을 낮추는 것이었다. 이를 위해 nOps는 Clara의 분석 및 에이전트 경험을 Amazon Bedrock AgentCore, Databricks Lakehouse Metric Views, Databricks Lakebase, Amazon DynamoDB, Vercel을 중심으로 다시 구성했다.

2. 기존 API 중심 구조의 한계

초기 Clara는 Kubernetes 위에서 Amazon Bedrock 모델을 호출하고, LangChain과 LangGraph로 오케스트레이션하며, 웹 API를 도구 래퍼로 제공하는 구조였다. 이 방식은 제품을 빠르게 처음 선보이는 데에는 유효했지만, 고객과 제품 범위가 확대되면서 복잡한 분석 워크플로, 높은 신뢰성, 다중 테넌트 격리를 함께 유지하기 어려워졌다. API 기반 데이터 접근은 긴 컨텍스트 메시지를 만들었고, 그 결과 각 대화 차례의 지연이 늘고 응답 일관성이 낮아졌다. 여러 오케스트레이션 및 관측 계층은 반복 개발과 디버깅을 어렵게 했으며, 엔지니어링 시간이 제품 혁신보다 인프라 유지에 더 많이 투입되는 문제도 발생했다. 특히 에이전트 답변이 전용 분석 의미 계층이 아니라 개별 API 응답에 종속돼 분석 중심 에이전트에 적합하지 않은 데이터 경로가 형성됐다.

3. 새로운 전체 아키텍처

nOps는 Amazon Bedrock AgentCore를 런타임과 오케스트레이션의 중심으로 삼고, Databricks Lakehouse Metric Views와 Databricks Lakebase를 결합한 목적 지향적 구조로 전환했다. 사용자 접점은 Vercel에 호스팅된 Next.js 애플리케이션이며, Backend for Frontend가 요청을 AgentCore로 전달하고 Server-Sent Events를 통해 응답을 스트리밍한다. AgentCore에서는 하나의 Strands 기반 에이전트가 캔버스 작업, 질의 실행, 데이터 소스 탐색, 워크플로 오케스트레이션 도구에 직접 접근한다. 분석 의미는 Metric Views가 관리하고, 세션·캔버스·위젯·질의 및 차트 사양 같은 영속 객체는 서버리스 PostgreSQL인 Lakebase가 저장한다. 장시간 분석은 Amazon DynamoDB, Amazon SNS, Amazon SQS, Amazon API Gateway WebSocket을 이용하는 별도의 비동기 경로에서 처리된다.

4. 단일 에이전트 런타임과 스트리밍

Clara의 런타임은 Docker 컨테이너로 Amazon Bedrock AgentCore에 배포되며, 런타임·메모리·가드레일·큐·작업자 함수는 하나의 AWS CDK 스택으로 정의된다. nOps는 다중 에이전트 라우터 대신 하나의 Strands Agent가 필요한 도구를 직접 호출하도록 설계해 에이전트 간 전달에서 발생하는 지연과 오류 전파를 피하고 도구 배치를 결정적으로 유지했다. 사용자는 Clara가 Strands 도구로 수행하는 것과 동일한 워크플로를 제품 화면에서 수동으로 실행할 수 있어, 에이전트와 사람이 같은 제품 절차를 따르게 된다. 스트리밍 병합 계층은 긴 도구 실행 중 연결을 유지하는 하트비트, 단어 경계를 고려해 작은 모델 출력을 읽기 좋은 단위로 합치는 텍스트 버퍼, 실시간 캔버스 갱신 이벤트를 같은 스트림에 삽입하는 위젯 폴링 작업자를 함께 처리한다. 이 구조는 긴 작업 중 연결 단절과 화면 깜박임을 줄이면서 분석 결과가 생성되는 과정을 사용자 인터페이스에 지속적으로 전달하기 위한 것이다.

5. 메모리 지속성과 테넌트 격리

Clara는 AgentCore 메모리를 의미적 사실, 사용자 선호, 캔버스 요약이라는 세 가지 전략으로 사용한다. 사용자 선호는 레이아웃, 기본 집계, 차트 유형 선택에 반영되고, 의미적 사실은 계정 구조와 비용 배분 규칙 같은 조직별 맥락을 보존한다. 캔버스 요약은 세션 사이의 분석 흐름을 유지해 사용자가 브라우저를 새로 고치거나 다시 연결한 뒤에도 이전 맥락을 반복 설명하지 않고 작업을 이어가게 한다. 세션 범위는 일시적인 HTTP 세션이 아니라 캔버스를 기준으로 설정돼 대화 상태가 사용자 분석 객체와 함께 지속된다. 다중 테넌트 격리를 위해 Amazon Bedrock Guardrails가 에이전트 호출 전에 원시 사용자 프롬프트를 검사하고, 별도의 테넌트 정책 계층이 전송되는 스트림 조각과 위젯 이벤트에서 내부 식별자를 삭제한다.

6. Metric Views를 통한 분석 의미 통합

새로운 데이터 계층에서 Clara는 분석 맥락을 일반 제품 API에 의존하지 않고, 선별된 도구를 통해 Databricks SQL Warehouse와 Databricks Lakehouse Metric Views를 질의한다. Metric Views는 측정값과 차원의 정의를 관리하는 의미 계층을 제공해 대화형 답변과 대시보드 출력이 같은 재무 논리를 사용하게 한다. 원문이 제시한 ‘최근 30일의 계정별 True Customer Cost’ 사례에서 원시 SQL 방식은 기본 상각 비용, EDP 할인, PPA 크레딧, RI 및 Savings Plan의 유효 상각 비용을 매번 결합하고 정규화해야 했다. Metric View 방식은 이 재무 논리를 true_customer_cost라는 사전 정의 측정값에 담아 account_name 차원 및 기간 조건과 함께 간단히 조회한다. 결과적으로 True Customer Cost의 정의가 한곳에서 관리되고 도구의 질의 논리가 단순해지며, 채팅과 대시보드가 일관된 결과를 생성할 수 있게 됐다.

7. 영속 상태와 비동기 분석 워크플로

Databricks Lakebase는 제품 객체, 세션, 캔버스, 위젯, 질의 및 차트 사양을 영속적으로 저장하는 상태 계층을 담당한다. 이 구조를 통해 채팅에서 생성된 분석 결과를 일시적인 답변으로 끝내지 않고 지속적이며 공유 가능한 분석 결과물로 전환할 수 있다. 오래 걸리는 분석 작업은 워크플로 작업자가 백그라운드에서 실행하고, Amazon DynamoDB가 작업 상태를 추적하며 Amazon SNS와 Amazon SQS가 알림 및 작업 전달을 처리한다. 완료 또는 진행 이벤트는 Amazon API Gateway WebSocket을 통해 사용자 인터페이스로 전송돼 화면이 실시간으로 갱신된다. 따라서 Clara는 무거운 처리가 끝날 때까지 전체 상호작용을 정지시키지 않고 즉각적인 대화 응답과 백그라운드 분석을 병행할 수 있다.

8. 출시 속도와 품질 개선 결과

nOps는 자체 관리 Amazon EKS 스택을 단일 관리형 서비스로 교체한 뒤 제품 출시까지 걸리는 시간이 10~12개월에서 4개월로 줄었으며, 이를 75% 감소로 제시했다. 하나의 공유 런타임에서는 현재 4~6개의 운영 준비가 완료된 에이전트가 분석 기능을 제공한다. 응답 품질 지표에서 정확성은 이전 기간보다 145% 상승한 81.7%를 기록했고, v1의 약 65%와 비교됐으며, 유용성은 이전 기간보다 138% 상승한 79.4%로 보고됐다. 새로운 도구 호출 방식과 Amazon Bedrock AgentCore 도입 이후 도구 실패율은 7.49%에서 0.92%로 감소했다. Customer Success Managers의 수동 분석 시간도 추정 2시간에서 30분으로 줄어 75% 감소했다고 제시됐지만, 제공된 본문은 이 결과를 설명하는 문장 도중에 끝나므로 이후 내용은 확인할 수 없다.

🧾 핵심 주장 / 시사점

• Clara의 개선은 모델 호출 자체보다 런타임, 도구 호출, 분석 의미 계층, 상태 저장 경로를 함께 재구성한 결과로 제시되며, 정확성 81.7%와 도구 실패율 0.92%가 그 변화를 수치로 보여준다.
• Databricks Lakehouse Metric Views는 복잡한 FinOps 계산을 매번 생성하는 대신 true_customer_cost 같은 관리형 측정값으로 고정해 대화형 분석과 대시보드 사이의 정의 불일치를 줄인다.
• 캔버스 단위 메모리와 Databricks Lakebase의 영속 상태를 결합한 구조는 대화를 일회성 질의가 아니라 세션을 넘어 이어지고 공유 가능한 분석 작업으로 확장한다.

✅ 액션 아이템

• Amazon Bedrock AgentCore 전환 전후의 출시 기간 10~12개월에서 4개월, 도구 실패율 7.49%에서 0.92%라는 결과를 도입 판단 기준으로 검토.
• Databricks Lakehouse Metric Views를 통해 대화형 답변과 대시보드에 같은 FinOps 지표 정의를 적용할 수 있는 범위를 확인.
• Clara의 캔버스 단위 메모리, Databricks Lakebase 영속 상태, 비동기 분석 경로가 필요한 사용자 작업 범위를 구분.

❓ 열린 질문

• Amazon Bedrock AgentCore 전환에서 보고된 75% 출시 기간 단축은 10~12개월에서 4개월로의 변화와 어떤 산정 기준으로 연결되는가?
• Databricks Lakehouse Metric Views의 단일 FinOps 지표 정의는 대화형 답변과 대시보드 간 일관성을 어느 범위까지 보장했는가?
• Clara의 도구 실패율이 7.49%에서 0.92%로 감소한 결과에서 새로운 도구 호출 방식과 단일 Strands 에이전트는 각각 얼마나 기여했는가?