Datadog과 AWS가 같은 날 발표한 'Ops 에이전트'는 무엇을 두고 경쟁하고 있는가

미국 현지 시간 2026년 6월 9일, 두 개의 큰 발표가 같은 날 겹쳤습니다.

뉴욕에서 개최된 Datadog의 연례 이벤트 DASH 2026의 키노트(Keynote)에서, Bits AI 패밀리가 대폭 확장되었습니다. Detection, Investigation, Remediation, Infrastructure, Code, Release, Testing, Data Analysis, Chat, Memories, Evals. 에이전트 단위로 세면 10종류가 넘으며, 총 100개 이상의 신기능이 한꺼번에 발표되었습니다. 발표의 전체 모습은 키노트 요약 기사에 정리되어 있습니다.

같은 날, AWS는 FinOps Agent를 프리뷰(Preview)로 발표했습니다. Cost Explorer, Cost Anomaly Detection, Cost Optimization Hub, Compute Optimizer의 네 가지 데이터 소스(Data Source)를 하나로 묶어, 비용 이상에 대한 자동 조사, 자연어를 통한 비용 질문, 정기 비용 보고서, 최적화 기회 집약까지를 Slack과 Jira로 직접 전달하는 구성입니다. 자세한 내용은 AWS 블로그에 정리되어 있습니다.

AWS DevOps Agent는 이미 3월에 GA(General Availability)되었으며, 이는 인시던트(Incident) 대응을 담당합니다. 비용 관리를 담당하는 FinOps Agent가 추가됨으로써, 운영의 주요 도메인(Domain)에 'AWS 제작 표준 에이전트'가 나란히 등장하게 되었습니다. 다만, DevOps Agent는 AWS뿐만 아니라 멀티 클라우드(Multi-cloud)나 온프레미스(On-premises) 환경도 대상으로 한다는 점에서, AWS의 비용 데이터를 대상으로 하는 FinOps Agent와는 수비 범위가 다릅니다. GA 당시의 상세 내용은 다음 블로그에 정리되어 있습니다.

표면적으로는 모니터링 플랫폼인 Datadog과 클라우드 인프라인 AWS가 서로 다른 영역의 이야기를 하는 것처럼 보입니다. 하지만 양사의 발표를 나란히 읽어보면, Ops라는 동일한 진지를 서로 다른 입구를 통해 점령하러 오고 있다는 것을 알 수 있습니다. 기능을 나열하면 대부분 겹치고 있어, 표면적인 스펙 비교로는 차이가 보이지 않습니다. 본 기사에서는 이 동시 출시를 양사의 포지셔닝 차이에서 정리하고, 매우 유사한 에이전트 군이 실제로는 무엇을 두고 경쟁하고 있는지, 그 판별 기준과 그로부터 읽어낼 수 있는 예측까지 깊이 있게 다룹니다.

대상 독자는 SRE, FinOps, Platform Engineering에 관련된 분들을 상정하고 있습니다.

왜 'Ops 에이전트'라는 카테고리가 지금 등장하는가

FinOps, DevOps, SRE는 서로 다른 이름을 가지고 있지만, 동일한 구조적 과제를 안고 있었습니다. 이상을 감지한 운영자와 실제로 수정하는 개발자. 이 두 사람 사이의 왕복 비용(Context Switching Cost)입니다.

구체적으로는 다음과 같은 흐름이 일상적으로 발생할 것입니다. 예를 들어 비용 관리의 경우. Cost Anomaly Detection이 비용 이상을 알리는 알람(Alert)을 울립니다. 누군가가 대시보드(Dashboard)를 열어 서비스별 내역을 확인합니다. 스파이크(Spike)의 원인이 EC2인지 RDS인지 구분하고, CloudTrail을 열어 누가 무엇을 배포했는지 대조합니다. Slack으로 관계자에게 확인을 받고, 리포지토리(Repository)를 열어 해당 IaC 코드를 찾습니다. 여기까지 오기 위해 수많은 화면과 도구를 오가게 됩니다. 수정안을 작성하여 PR(Pull Request)을 올리는 것은 그 이후입니다.

인시던트 대응도 같은 흐름입니다. 알람이 울리고, 대시보드를 열고, 로그를 보고, APM의 트레이스(Trace)를 추적하고, 관계자를 Slack으로 호출하여 수정을 가합니다. 컨텍스트 스위칭(Context Switching)의 연속으로, 대응이 심야까지 이어지면 더욱 소모적입니다.

LLM의 정밀도가 이러한 해석과 왕복 작업을 맡을 수 있는 수준에 도달한 것이 최근 1년 정도의 변화라고 할 수 있습니다. 모니터링 데이터를 읽고, 원인을 해석하며, 수정을 제안하는 일련의 작업을 인간 대신 수행할 수 있게 된 것입니다. 모니터링과 조작을 일원화하고 싶다는 욕구는 이전부터 있었지만, 마침내 그것을 자율 에이전트(Autonomous Agent)라는 형태로 세상에 내놓을 수 있게 된 타이밍의 문제입니다. 실제로 AWS가 운영용 일련의 에이전트를 갖추기 시작한 것도, 지난 연말 re:Invent 2025에서 DevOps Agent와 Security Agent를 프리뷰 공개한 시점부터입니다.

DASH 2026과 AWS FinOps Agent가 같은 날 겹친 것은 아마 우연이 아닐 것입니다. 서로 다른 영역에 있던 양사가 같은 방향으로 동시에 진화하고 있음을 보여주는 하루였다고 할 수 있습니다.

Datadog과 AWS의 전략 차이

양사의 전략을 데이터 소스, 수비 범위, 에이전트의 포지셔닝이라는 세 가지 축으로 비교해 보겠습니다.

데이터 소스

AWS는 비용 데이터와 CloudTrail을 1차 데이터 (Primary Data)로 보유하고 있습니다. 이는 AWS만이 온전히 소유하고 있는 데이터입니다.

AWS FinOps Agent의 이상 징후 조사 (Anomaly Investigation)는 이러한 특성을 직접 활용하도록 설계되어 있습니다. Cost Anomaly Detection의 탐지 이벤트를 기점으로, 그 전후의 CloudTrail 이벤트를 상관 분석합니다. CloudTrail은 '누가', '언제', '어떤 API를' 호출했는지를 기록하기 때문에, 비용 변동을 일으킨 조작과 이를 실행한 IAM 사용자 또는 역할(Role), 즉 책임을 지는 소유자(Owner)를 특정하는 단계까지 자동화됩니다. 출력 결과는 사업적 요인까지 깊게 파고드는 해석이 아니라, 책임을 지는 엔지니어에게 직접 전달되는 Jira 티켓이나 Slack 알림입니다.

이는 비용이 발생하는 지점과 리소스가 조작되는 지점을 동시에 보유하고 있어야만 만들 수 있는 워크플로우라고 할 수 있습니다. 서드파티 (Third-party) FinOps SaaS는 CUR (Cost and Usage Report)를 가져올 수 있지만, CloudTrail과의 대조를 동일한 정밀도로 수행하는 것은 데이터 지연이나 권한 측면에서 AWS만큼 용이하지 않을 것입니다. AWS는 자사 내부의 API 호출을 거의 실시간으로 파악할 수 있는 위치에 있으며, 여기에 구조적인 우위가 있습니다.

Datadog은 APM, 로그 (Log), 트레이스 (Trace), RUM, 프로파일러 (Profiler)의 텔레메트리 (Telemetry)를 1차 데이터로 보유하고 있습니다. Bits Detection은 실시간 메트릭 (Metric)이나 로그에 더해, 과거의 베이스라인 (Baseline), 서비스 토폴로지 (Service Topology), 소유권 정보, 소스 코드의 컨텍스트 (Context)까지 참조하며 현재 상태가 건전한지를 지속적으로 판단합니다. 근본 원인 조사는 Bits Investigation이 수행하고, 그 수정은 Bits Code가 맡아 GitHub 상에 프로덕션용 PR (Pull Request)까지 생성합니다.

근원이 되는 데이터의 종류가 다르기 때문에, 특화된 이상 징후의 유형도 다릅니다. AWS는 '비용의 이상'에, Datadog은 '성능과 동작의 이상'에 강점이 있습니다. 양사 모두 범용 Ops 에이전트라고 자처하고 있지만, 내부 데이터 소스가 다른 이상 전문 영역의 무게 중심은 자연스럽게 달라집니다.

수비 범위

AWS는 자사 클라우드 내에서 완결됩니다. 멀티 클라우드 (Multi-cloud)나 SaaS는 커버하지 않습니다.

이는 단점인 동시에 강점이기도 합니다. AWS로만 구성된 조직이라면 비용부터 실행 로그까지 모두 동일한 클라우드 내에서 갖춰집니다. 반대로 Snowflake, Databricks, Google Cloud, Vercel 등 여러 서비스가 혼재된 조직에서는 AWS FinOps Agent만으로는 조직 전체의 클라우드 비용 이상을 파악할 수 없습니다.

Datadog은 멀티 클라우드와 SaaS를 아우를 뿐만 아니라, 자사 인프라에 둔 로그 기반까지 통합합니다. 로그를 자신의 클라우드 환경에 둔 채로 검색할 수 있는 BYOC Logs에 더해, DASH 2026에서는 Databricks나 ClickHouse 같은 외부 데이터 스토어를 Log Explorer에서 동일한 구문으로 횡단 검색할 수 있는 Federated Logs도 선보였습니다. 로그가 어디에 흩어져 있든 Datadog에서 검색할 수 있는 방향으로 확장하고 있습니다.

조직의 운영 범위가 어디까지 확장되어 있느냐에 따라 선택이 달라집니다. AWS 100% 조직이라면 전자로 충분하지만, 여러 클라우드나 SaaS가 섞여 있는 조직에서는 후자의 범위가 필요하다는 차이가 있습니다. 양쪽을 모두 사용하는 조직이라도 비용 최적화는 AWS FinOps Agent, 성능과 가용성은 Datadog Bits로 나누는 분업 구조는 가능한 구성이라고 할 수 있습니다.

에이전트의 위치づけ (Positioning)

이 차이야말로 본 기사에서 가장 전달하고 싶은 부분입니다.

AWS는 AI 에이전트를 자사 플랫폼 위에서 구동하기 위한 구성 요소로서 갖추려 하고 있습니다. Bedrock AgentCore가 그 기반이며, Memory (기억), Identity (권한 관리), Observability (동작 가시화), Gateway (외부 도구 연동), Runtime (실행 환경), 그리고 Browser Tool이나 Code Interpreter 같은 내장 도구들이 갖춰져 왔습니다. DevOps Agent나 FinOps Agent는 이 레이어 위에 올라가는 AWS 제작 표준 에이전트로 위치づけ (Positioning) 됩니다.

즉, AWS는 에이전트의 실행 환경 자체를 자사가 장악하고, 그 위에서 동작하는 구체적인 에이전트들을 순차적으로 출시하는 전략입니다. AgentCore는 LangGraph나 CrewAI 등 타사의 프레임워크에도 대응하고 있어, 서드파티 에이전트들도 동일한 기반 위에서 동작할 수 있을 것으로 기대됩니다.

Datadog은 AI 에이전트를 모니터링 대상으로 삼아 외부에서 관찰하려 하고 있습니다. 같은 날 발표된 Datadog Agent Console은 조직에서 사용되는 코딩 에이전트(Claude Code, Cursor, GitHub Copilot 등)와 Datadog 자체의 Bits AI를 가로질러 가시화하는 장치입니다. 누가 어떤 에이전트를 얼마나 사용하고 있는지, 그것이 AI를 사용하지 않을 때와 비교하여 효과적인지, 비용이 어디에서 낭비되고 있으며 무엇을 개선할 수 있는지. 이러한 질문들에 대해 하나의 UI로 답할 수 있도록 합니다.

여기서 중요한 점은 모니터링 대상에 Datadog 자신의 Bits AI도 포함되어 있다는 점입니다. 자사의 에이전트도, 경쟁사의 에이전트도 동일한 UI에서 나란히 비교할 수 있습니다. "우리 에이전트를 사용해 달라"고 호소하는 것이 아니라, "당신 조직의 에이전트 운영 그 자체를 우리가 가시화해 주겠다"는 입장입니다.

AI Guard도 같은 사상의 연장선에 있습니다. 이는 AI 에이전트를 프롬프트 인젝션 (Prompt Injection), 도구 오용, 데이터 유출과 같은 공격으로부터 보호하는 장치이지만, 보호 대상이 Datadog 제작 에이전트에 국한되지는 않습니다. 환경 내의 보호되지 않은 에이전트를 식별하며, 외부에서 직접 만든 에이전트도 대상으로 포함합니다. Datadog은 에이전트를 모니터링하고, 보호하며, 거버넌스 (Governance)를 수행하는 입장을 취하려 하고 있습니다.

에이전트를 소유하려는 AWS와 에이전트를 모니터링하려는 Datadog. 이 차이가 양측 전략의 핵심이라고 할 수 있습니다.

에이전트가 담당하는 영역 대응표

운영부터 개발까지, AI 에이전트가 담당하는 영역을 양측이 각각 무엇으로 실현하고 있는지 나열해 보겠습니다. 클라우드 서비스 전체를 비교하는 것은 아닙니다. 상단 절반은 운영과 개발 실무(탐지·조사·복구부터 코드 변경·릴리스·테스트까지), 하단 절반은 이를 뒷받침하는 기반(기억·평가·모니터링·보호·실행 환경)입니다. 이 표에서 슬래시(/)는 여러 제품이 후보가 될 수 있음을, 플러스(+)는 여러 개를 조합하여 실현함을 나타냅니다.

역할	Datadog	AWS
이상 탐지	Bits Detection	Cost Anomaly Detection / DevOps Agent
...

역할로서는 대부분이 겹칩니다. 겹치지 않는 영역이나 명확하게 강점이 다른 영역에서 각자의 강점이 드러납니다.

Datadog은 "자사 외부의 에이전트까지 모니터링 대상으로 포함하는" 확장성과, Bits Code나 Bits Release와 같이 "탐지부터 수정, 검증까지의 루프를 Datadog 내부에서 완결하는" 설계를 가지고 있습니다.

AWS는 CloudTrail이라는 소유 데이터를 원천으로 한 "비용 이상의 근본 원인 특정"과, AgentCore Runtime이라는 "타사 에이전트를 자사 플랫폼으로 끌어들이는 토대"를 가지고 있습니다. 후자는 서드파티 (Third-party) 개발자들에게 "AWS 위에서 에이전트를 구동해 달라"고 유도하기 위한 장치입니다.

주도권의 분기점은 "누가 코드를 바꾸는가"

기능 대응표를 살펴보면 한 가지 쟁점이 떠오릅니다. 탐지부터 조사, 코드 변경, 릴리스 검증까지의 흐름을 어디까지 자사의 UI로 완결할 것인가. 이 지점이 양사의 영토 전쟁이 되고 있습니다.

Datadog의 Bits Code는 이러한 관점에서 상징적인 프로덕트입니다. 공식 설명에 따르면, Bits Code는 Error Tracking, APM Recommendations, Continuous Profiler, Test Optimization, Code Security, 그리고 Bits Investigation으로부터 시그널을 받아 엔지니어가 평소 수동으로 수행하던 일련의 작업을 대신합니다. 문제의 트리아지 (Triage), 해당 코드 특정, 수정 사항 작성, 테스트 실행, 그리고 PR (Pull Request) 생성까지. 이 모든 과정을 일괄적으로 처리합니다.

즉, 지금까지 "모니터링 도구는 알람을 주는 데까지, 수정은 IDE와 GitHub의 역할"이었던 분업 구조를 Datadog 측으로 흡수하려 하고 있습니다. 리포지토리 (Repository) 자체는 GitHub나 GitLab 측에 있지만, PR을 생성하는 주체는 Datadog입니다.

AWS DevOps Agent 또한 근본 원인 특정부터 수정 제안까지 수행합니다. 다만, 수정 대상이 애플리케이션 코드까지 깊숙이 들어가는 경우, 코드의 주 무대가 AWS 자사 서비스 위에 있다고 단정할 수 없기 때문에 이 부분의 완결성은 다소 약합니다. AWS 코딩의 핵심은 사양 주도(Specification-driven)에 특화된 Kiro나 Bedrock을 통한 서드파티 에이전트가 될 가능성이 높으며, DevOps Agent는 이들과 연계하는 역할을 맡게 됩니다. AWS의 전략은 에이전트 실행 환경으로서의 AgentCore를 장악하고, 그 위에서 동작하는 서드파티를 포함하여 자사 플랫폼에 올리는 것이라는 서로 다른 경로를 택하고 있습니다.

여기서 Datadog Agent Console이 힘을 발휘합니다. 조직이 사용하는 Claude Code나 Cursor, GitHub Copilot을 모니터링 대상으로 포함함으로써, Datadog 외부에서 동작하는 코딩 에이전트의 활동까지 가시화 범위에 넣을 수 있습니다. Bits Code 자체도 모니터링 대상이 되기 때문에, 자사 제품과 타사 제품을 동일한 UI에서 나란히 비교할 수 있습니다.

즉, Datadog은 코딩 에이전트 자체를 소유하지 않더라도, 그것을 모니터링하는 입장을 취함으로써 주도권을 잡으려는 포지션을 취하고 있습니다. 반면 AWS는 AgentCore 위에서 모든 것을 완결시키면 모니터링까지 자사 내에서 해결할 수 있다는 입장입니다.

어느 전략이 성립할지는 엔지니어가 평소 어디에 머무느냐에 따라 좌우됩니다. AWS 콘솔에 오래 체류하는 팀이라면 AWS 측, Datadog의 UI와 Slack을 주 무대로 삼는 팀이라면 Datadog 측이 될 것이라는 점이 현시점에서의 자연스러운 분기점일 것입니다. IAM이나 VPC, Cost Management처럼 AWS 콘솔을 통해서만 직접 다룰 수 있는 리소스가 많은 조직에서는 AWS 측의 우위가 작용하기 쉽습니다. Slack 알림과 PR 리뷰를 중심으로 운영이 돌아가는 조직에서는 Datadog 측이 커버할 수 있는 범위가 넓게 확장될 것입니다.

사실로부터 보이는 예측

지금까지 정리한 사실로부터 몇 가지 예측을 도출해 보겠습니다.

예측 1: AgentCore는 Bedrock의 전략을 에이전트로 반복한다

AWS의 전략은 과거 Bedrock 전략의 재현으로 보입니다. Bedrock은 Anthropic, OpenAI, Meta와 같은 각사의 모델을 AWS에서 호스팅하고, 자사의 Nova 모델과 동일한 선상에 놓아 모든 것을 AWS 청구서에 포함시키는 기반으로서 확장되었습니다. 어떤 모델이 승리할지에 베팅하는 것이 아니라, 모델이 동작하는 실행 환경과 과금을 장악함으로써 AI 시장의 점유율을 확보하는 전략입니다.

AgentCore Runtime은 이와 동일한 구조를 에이전트 시장에서 재현하려 하고 있습니다. 에이전트 자체를 대량으로 직접 만드는 것이 아니라, 서드파티 에이전트 개발자들에게 "AWS 위에서 동작시켜 달라"고 유도하는 장치입니다. DevOps Agent나 FinOps Agent는 그 기반 위에서 동작하는 표준 구현의 본보기라는 위치를 갖게 됩니다. AgentCore Memory, Identity, Observability, Gateway와 같은 컴포넌트는 에이전트 개발자가 직접 만들려면 번거로운 공통 부품들을 AWS가 대신 처리해 주는 장치로 보입니다.

이 전략이 성립할지는 에이전트 개발자가 AgentCore의 제약을 허용하느냐에 달려 있습니다. Bedrock이 모델 제공자들을 흡수하는 데 성공했듯이, AgentCore가 에이전트 제공자들을 흡수하는 데 성공한다면 AWS는 모니터링, 실행, 과금의 모든 것을 자사 내에 품을 수 있습니다.

예측 2: Bits Code와 Bits Release의 양립이 보여주는 Datadog의 완결성 전략

DASH 2026에서 Datadog은 코드 변경을 담당하는 Bits Code와 릴리스 검증을 담당하는 Bits Release를 동일한 패밀리로 정렬했습니다. Bits Release는 코드 변경의 의도된 영향을 분석하고, 검증 계획을 세우며, 스테이징에서 체크를 실행하고, 롤아웃(Rollout)을 지켜보는 에이전트입니다. 이 두 가지가 나란히 배치된 것 자체가 전략적인 의도의 표현이라고 읽을 수 있습니다.

탐지부터 조사, 코드 변경, 릴리스 검증까지의 루프를 자사 내에서 완결시키려면, 우선 코드 변경(수정 PR)을 장악하는 것이 기점이 됩니다. 코드 변경을 장악하면 그 이후의 릴리스 검증은 "Datadog이 생성한 PR을 Datadog이 릴리스 시점에 확인한다"는 자연스러운 연장선이 됩니다. 반대로 코드 변경을 타사의 IDE 측 에이전트나 GitHub Copilot에 빼앗기게 되면, 릴리스 검증만 자사에서 보유하더라도 폐쇄된 루프(Closed loop)를 형성할 수 없습니다.

Bits Code로 루프의 기점을 확보하고, Bits Release로 그 출구까지 자사로 끌어들입니다. 이 두 가지가 갖춰짐으로써, 모니터링부터 수정, 릴리스까지를 Datadog의 UI 내에서 완결시키는 경로가 보이기 시작했습니다. 아직 프리뷰(Preview) 단계인 기능도 포함되어 있지만, 이를 엔드 투 엔드(End-to-end)로 완성해 나갈 가능성은 높아 보입니다.

예측 3: 채팅과 티켓으로의 통합은 「푸시형 UX」로의 거대한 전환의 일부

양사 모두 에이전트(Agent)의 출력처로서 채팅과 티켓 관리 도구를 중시하고 있습니다. AWS FinOps Agent는 출력처를 Slack이나 Jira로 지정할 수 있으며, Datadog Bits 역시 조사 결과나 알림을 동일한 종류의 도구로 전달합니다.

이는 「대시보드를 보러 가는 UX」에서 「엔지니어가 이미 있는 곳으로 전달되는 UX」로의 거대한 전환을 나타냅니다. 지금까지 모니터링 도구도 FinOps 도구도, 사용자가 대시보드를 보러 간다는 전제하에 만들어져 왔습니다. 알림은 메일로 받고, 상세 내용은 대시보드에서 확인하는 흐름입니다.

에이전트의 시대가 되면 이것이 반전됩니다. 문제가 발생하면 해석과 권장 조치(Recommended action)가 채팅으로 직접 전달됩니다. 대시보드를 여는 것은 심층 분석을 하고 싶을 때와 에이전트의 판단에 납득할 수 없을 때뿐입니다. 대시보드는 에이전트의 판단을 뒤에서 뒷받침하는 참조 자료라는 위치로 내려가게 됩니다.

이러한 변화는 과금 모델에도 영향을 미치기 시작했습니다. 기존의 조회수나 시트(Seat) 단위의 과금에 더해, Datadog은 이미 에이전트의 작업량에 따른 AI 크레딧이나 조사 건당 종량제 과금을 도입하고 있습니다. 대시보드를 얼마나 보느냐가 아니라, 에이전트를 얼마나 일하게 하느냐. 모니터링 과금의 축은 그쪽으로 움직이기 시작했습니다.

예측 4: 코딩 에이전트 운용은 「개인 도구」에서 「조직 도구」로

Datadog Agent Console이 등장했다는 사실 자체가 코딩 에이전트 운용이 하나의 장르로서 성립되고 있음을 보여줍니다. Claude Code나 Cursor, GitHub Copilot을 개별적으로 도입하여 누가 얼마나 사용하고 있는지 보이지 않는 상황도 빈번하게 발생하곤 합니다.

각 도구 또한 GitHub Copilot의 엔터프라이즈(Enterprise)용 관리 기능이나 Cursor의 팀 기능처럼, 조직에서의 이용을 통합하는 방향으로 움직이고 있습니다. 다만 개별 도구의 관리 화면은 기본적으로 해당 제품 안에서 폐쇄되어 있습니다. Datadog Agent Console은 그 위에 가로지르는 관리 레이어(Management layer)를 얹으려 하고 있습니다. GitHub Copilot이 타사의 코딩 에이전트를 자신의 플랫폼으로 흡수하기 시작한 것과는 방향이 다르지만, 목표는 유사한 움직임이라고 할 수 있습니다.

「조직의 코딩 에이전트 운용 대시보드」라는 카테고리는 이미 형성되고 있습니다. 아직 보이지 않는 것은 그 다음 단계로, 비용 배분을 위한 업계 표준 태그 규약이나 에이전트 단위의 생산성 지표(PR 채택률, 에러율, 채택된 PR당 비용 등)의 정비가 다음에 올 과제일 것입니다.

예측 5: 주도권 싸움은 삼파전으로 발전한다

지금까지는 Datadog과 AWS 두 회사를 중심으로 작성했지만, 실제 주도권 싸움은 삼파전이 될 것으로 보입니다. 소스 코드를 보관하는 GitHub나 GitLab, 실행 플랫폼을 가진 AWS나 Google Cloud, Azure, 모니터링 플랫폼을 가진 Datadog이나 Grafana Labs, New Relic. 각자가 에이전트 시대의 주도권을 노리고 있습니다.

GitHub는 Copilot과 Actions의 조합을 통해 코드 변경부터 릴리스, 모니터링까지의 루프를 GitHub 내에서 완결시키는 방향으로 움직이고 있습니다. GitHub Advanced Security에는 Copilot Autofix가 포함되어 있으며, CodeQL이 탐지한 취약점에 대해 수정 제안 PR을 생성하는 단계까지 이미 구축되어 있습니다.

리포지토리(Repository) 측, 실행 기반 측, 모니터링 측의 세 주체가 각각 자신의 소유 영역에서 탐지·수정·릴리스의 루프를 가져오려 하고 있습니다. 세 주체 중 어느 하나가 완전히 승리한다기보다, 이용하는 조직이 자신들의 규모나 업종, 기존 스택에 맞춰 주인공을 선택하게 될 것입니다. 승자는 조직별로 나뉘게 된다는 결말로 이어질 것으로 보입니다.

예측 6: FinOps의 조직론적 전환

AWS FinOps Agent가 가장 크게 바꾸는 것은 기술이 아니라 조직의 형태일지도 모릅니다.

지금까지 FinOps는 중앙 FinOps 팀이 주도하는 형태가 주류였습니다. 전문가 집단이 비용 보고서(Cost Report)를 작성하고, 월간 리뷰를 통해 개발 팀과 소통하는 방식입니다. 최근에는 중앙 팀이 표준과 가드레일(Guardrail)을 정비하면서 각 팀에 책임을 위임하는 방향으로 이동하고 있었습니다. 다만, 그 역할을 수행하는 주체는 여전히 사람이었습니다. AWS FinOps Agent는 개별 엔지니어가 자연어(Natural Language)로 비용을 질문할 수 있고, 이상 징후가 발생하면 엔지니어에게 직접 Jira 티켓이 전달되도록 설계되어 있습니다.

이는 셀프 서비스(Self-service) 측면을 강화하고 싶은 조직에게 그 전환을 한 단계 더 진전시키는 장치라고 할 수 있습니다. 지금까지 사람이 담당하던 분산화를 에이전트(Agent)가 맡을 수 있기 때문입니다. 이 길을 선택할 경우, FinOps 팀의 업무는 모두를 가르치는 것에서 계정(Account)과 소유자(Owner)의 매핑, 태그 규약(Tagging Convention)을 정비하고 에이전트에게 전달할 컨텍스트(Context)를 설계하는 것으로 옮겨가게 됩니다. FinOps 전문가가 사라지는 것이 아니라, 활동의 내용이 기반을 다지는 작업으로 변해가는 것입니다. 그러한 선택지가 현실적이 되었다는 관점입니다.

비슷한 구도는 다른 영역에서도 볼 수 있습니다. SRE에서는 모니터링을 직접 담당하는 것과 모니터링 체계를 구축하는 것. Platform Engineering에서는 각 팀이 스스로 인프라를 다룰 수 있도록 가드레일이 마련된 표준 경로를 준비하는 것. 보안(Security)에서는 전문 팀이 건별로 리뷰하는 것과 정책(Policy)을 플랫폼 템플릿에 내장하는 것. 전문 팀이 현장을 직접 처리할 것인지, 현장이 스스로 움직일 수 있는 체계를 만드는 쪽으로 돌아설 것인지에 대한 선택이 각각 존재합니다.

어느 쪽이 정답이라고 할 수는 없습니다. 완전한 중앙집권형이 적합한 조직이 있는가 하면, 현장에 크게 위임하는 조직도 있습니다. 대부분은 중앙이 표준과 가드레일을 준비하고, 그 범위 내에서 현장이 스스로 움직이는 중간 형태에 안착할 것입니다. AI 에이전트는 이 '현장이 스스로 움직이는' 측면을 인력보다 낮은 비용으로 실현할 수 있는 선택지로서 등장했습니다. FinOps의 셀프 서비스화도 그 일례입니다. AI 에이전트의 도입은 모니터링이나 조작 방식뿐만 아니라, 조직이 역할의 무게중심을 어디에 둘 것인가라는 선택지 자체를 넓히고 있습니다.

예상되는 반론

지금까지의 정리와 관련하여 몇 가지 반론이 있을 수 있습니다. 먼저 제시된 질문들에 대해 각각 답변하겠습니다.

반론 1: Datadog의 멀티 클라우드 우위

멀티 클라우드(Multi-cloud)와 SaaS 모두를 아우르는 Datadog이 결국 커버리지 면에서 승리하지 않을까?

확실히 멀티 클라우드라는 넓은 커버리지는 Datadog의 강점입니다. 하지만 AWS에는 비용 데이터와 CloudTrail처럼 AWS 자신만이 1차 데이터(Primary Data)를 가질 수 있는 영역이 있습니다. 비용 변동의 근거를 가장 높은 정밀도로 추적할 수 있는 것은 AWS 자신이라는 우위는 남습니다. 멀티 클라우드 조직이라 하더라도 AWS의 비용 거버넌스(Cost Governance)만큼은 AWS FinOps Agent에 맡기는 식의 분업은 가능할 것입니다. 모니터링의 일원화와 데이터 소스의 정밀도. 양립하기 어려운 이 두 축이 여기서 시험대에 오릅니다.

반론 2: 자사 서비스에 국한되는 불리함

AWS는 자사 클라우드 안에 갇히게 된다. 커버리지가 좁은 만큼 불리하지 않을까?

커버리지가 좁다는 점은 확실히 불리한 요소입니다. 하지만 AWS를 주력으로 사용하는 개발자들은 이미 AWS 콘솔(Console)에 오랫동안 머물고 있습니다. 엔지니어가 평소 사용하는 화면에 그대로 녹아들 수 있다는 점은 행동 변화의 비용을 낮추는 강력한 무기입니다. 새로운 UI로 이동할 필요가 없다는 것은 툴(Tool) 채택 현장에서 매우 큰 효과를 발휘합니다.

반론 3: 양쪽을 병용하는 선택

하나로 좁히지 말고 둘 다 도입하면 되는 것 아닌가?

실제로 이는 현실적인 선택지입니다. 코딩 현장에서는 이미 Claude Code로 설계를 다듬으면서 구현은 Codex에 맡기고, 그 출력을 다른 에이전트가 리뷰하게 하는 등 여러 에이전트를 병용하는 사례가 확산되고 있습니다. 특기가 다른 에이전트를 구분하여 사용하고, 한쪽의 결과를 다른 쪽에서 검증하게 하는 방식입니다. Ops 에이전트에서도 동일한 세계관이 충분히 성립합니다.

다만, 이것이 성립하려면 인간이 "어떤 것을 어떤 목적으로 사용하고, 어떤 출력을 신뢰할 것인가"에 대한 판단 기준을 가지고 있어야 합니다. Ops 에이전트는 기능의 중첩이 커서 이상 조사, 자동 복구, 자연어 질문 모두 양쪽에서 가능합니다. 판단 기준 없이 두 가지를 모두 도입하면, 동일한 경험을 두 곳에서 겪어야 하는 비용만 남게 되고, 엔지니어는 어디에 물어봐야 할지 혼란을 겪게 됩니다. 과거 모니터링 툴이 난립하던 시절과 같은 구도입니다. 병용을 활용할지 망칠지는 사용 방식의 설계에 달려 있다고 할 수 있습니다.

반론 4: 결국 Datadog에서 모든 것을 볼 수 있을 가능성

AgentCore에 탑재된 에이전트도 Datadog에서 볼 수 있다면, 결국 Datadog이 시장을 장악하는 것 아닌가?

이는 충분히 가능한 미래입니다. AgentCore Observability는 OpenTelemetry 호환이며, 이미 Datadog을 포함한 외부 모니터링 도구로 텔레메트리 (Telemetry)를 보낼 수 있습니다. AWS가 실행 기반과 과금 권한을 쥐더라도, 모니터링의 주 무대는 Datadog 측에 남는다는 역할 분담이 이루어질 수 있습니다. 실행은 장악하되, 모니터링은 외부에 개방한다. 이러한 농도의 차이가 장기적인 주도권의 분기점이 될 것으로 보입니다.

반론 5: GitHub의 참입

리포지토리 (Repository)를 보유한 GitHub이 동일한 루프를 먼저 만들어버리는 것 아닌가?

이는 오히려 '예측 5'에서 언급한 삼파전 이야기와 직결됩니다. GitHub은 실제로 이 방향으로 움직이고 있으며, Copilot Autofix와 Actions의 조합을 통해 코드 기점의 루프를 만들어가고 있습니다. Datadog의 Bits Code는 모니터링 기점, GitHub Copilot Autofix는 코드 기점, AWS DevOps Agent는 실행 기반 기점입니다. 동일한 루프를 각기 다른 입구를 통해 장악하러 오는 구도로 정리할 수 있습니다.

어디서부터 시작할 것인가

지금까지 판단의 축은 정리되었습니다. 데이터 소스, 방어 범위, 에이전트의 위치 선정. 이 세 가지를 통해 각 에이전트의 정체를 파악할 수 있게 되었으니, 이제 실제로 무엇부터 움직일 것인가에 대한 이야기로 넘어가겠습니다. AWS를 실행 기반으로, Datadog을 모니터링으로, GitHub을 코드 관리로 사용하고 있다는 구성을 전제로 정리해 보겠습니다.

단계 1: 조직의 운영이 '무엇 기점'으로 움직이고 있는지 언어화하기

가장 먼저 해야 할 일은 도구 선정이나 도입 검증이 아니라, 현상황을 언어화하는 것입니다. 인시던트 (Incident)나 비용 이상이 발생했을 때, 가장 먼저 어디를 보고, 어디에서 원인을 특정하며, 어디에서 수정하는가. 이 왕복 경로를 한 번 적어보면, 조직이 어떤 벤더와 가장 궁합이 잘 맞는지 보이기 시작합니다.

판단 축은 다음과 같이 정리할 수 있습니다.