Michael JohnsonAWS는 2026년 9월 22일 CloudWatch Omni를 발표했고, 9월 23일 정식 출시 제품으로 등록했습니다. 두 날짜는 서로 다른 일, 즉 발표와 정식 출시 시작을 가리킵니다. Omni는 독립형 웹 인터페이스와 IDE 확장 기능은 물론 CloudWatch 통합 기능을 통해 애플리케이션과 AI 에이전트의 관측 기능을 하나의 경험으로 제공합니다. aws.amazon.com
이 조합은 프로덕션 환경의 사각지대를 해소합니다. 에이전트 요청이 일반적인 서비스 오류 없이 완료되더라도 답변 품질이 낮거나 잘못된 도구를 선택할 수 있기 때문입니다. AWS는 팀이 에이전트 트레이스와 평가 결과를 애플리케이션 텔레메트리와 함께 살펴볼 수 있다고 설명합니다. 실질적인 관건은 이러한 신호가 공유 작업 공간에서 유용하게 쓰일지, 그리고 그곳으로 데이터를 보낼 때 어떤 데이터와 액세스 권한, 비용이 수반되는지입니다.
에이전트 트레이스 그 이상을 아우르는 제품
Omni는 CloudWatch를 대체하는 제품이 아니라 CloudWatch의 확장판입니다. AWS에 따르면 기존 CloudWatch 알람과 대시보드, API, 콘솔 워크플로는 계속 사용할 수 있습니다. 이미 CloudWatch로 전송된 텔레메트리는 재구성 없이 Omni에 표시할 수 있고, 그 밖의 계측된 워크로드는 OpenTelemetry Protocol(OTLP)을 통해 데이터를 보낼 수 있습니다. AWS는 서비스 검색과 종속성 매핑도 제공하며, 해당 목적에 맞게 구성하면 계정과 리전에 걸친 텔레메트리를 스페이스에 모을 수 있다고 설명합니다. docs.aws.amazon.com 문서
Omni는 AWS Management Console에서만 사용할 수 있는 것이 아닙니다. AWS는 싱글 사인온을 지원하는 독립형 웹 인터페이스와 VS Code, Cursor, Kiro용 IDE 확장을 제공합니다. 9월 23일 출시 안내에 따르면 미국 동부(버지니아 북부), 미국 서부(오리건), 유럽(아일랜드)에서 정식 출시되었습니다. 프로덕션 설계에 Omni를 포함하기 전에 팀은 리전 지원 여부를 확인해야 합니다.
에이전트 기능과 관련해 AWS는 OpenAI Agents SDK, LangGraph, CrewAI, Vercel AI SDK, Strands 등의 프레임워크에서 트레이스 탐색과 평가, 실험을 지원한다고 설명합니다. 애플리케이션 조사에서는 자연어로 질문하거나 텔레메트리를 직접 탐색할 수 있으며, AWS에 따르면 AI 지원 조사 기능은 DevOps Agent를 기반으로 합니다. AWS의 애플리케이션 출시 게시물은 각 Omni 조사 세션에서 DevOps Agent가 기본적으로 활성화된다고도 밝힙니다. 관리자는 워크플로를 평가할 때 이 동작을 이해해야 합니다.
신호 통합이 중요한 이유
기존 모니터링으로는 서비스의 응답 여부와 응답 시간, 오류 반환 여부를 확인할 수 있습니다. 하지만 에이전트가 요청을 잘못 이해하거나 부적절한 도구를 선택하거나 틀린 답변을 내놓았다는 점은 드러나지 않을 수 있습니다. 평가 결과를 트레이스 및 애플리케이션 신호와 함께 살펴보면 팀이 품질 문제의 원인을 에이전트 실행 과정에서 추적하는 데 도움이 될 수 있습니다.
이는 현실적으로 기대할 수 있는 운영상 이점이지, 입증된 성능 결과는 아닙니다. AWS의 출시 자료는 통합 워크플로를 소개하지만, 기존 도구보다 사고를 더 빠르게 해결한다고 입증하지는 않습니다. Omni의 평가 및 조사 기능이 자사 워크로드에서 도움이 되는지 팀이 직접 테스트해야 합니다.
OpenTelemetry를 이용하면 기존 계측에서 텔레메트리를 더 쉽게 보낼 수 있지만, 공통 프로토콜을 사용한다고 관측 플랫폼을 서로 바꿔 쓸 수 있는 것은 아닙니다. OTLP 사양은 텔레메트리 전송 방식을 정의합니다. 팀은 여전히 워크플로가 어떤 신호와 쿼리, 플랫폼별 기능에 의존하는지 확인해야 합니다.
중앙 집중화에는 구성이 필요하다
Omni로 계정과 리전 전반의 데이터를 모을 수 있지만, 인터페이스를 활성화하기만 하면 모든 계정의 텔레메트리가 자동으로 통합된다고 가정해서는 안 됩니다. AWS의 설정 문서에는 도메인과 스페이스를 만든 다음 여러 계정의 텔레메트리를 스페이스에 모으는 방식을 구성하는 절차가 설명되어 있습니다. 기존 CloudWatch 데이터는 계측을 다시 하지 않아도 볼 수 있지만, 조직은 원하는 액세스 권한과 데이터 흐름을 직접 설정해야 합니다. docs.aws.amazon.com 설정 문서
이 차이는 배포와 비용 모두에 중요합니다. AWS의 요금 안내 페이지는 텔레메트리 수집과 저장, 분석 요금을 구분합니다. 추가 중앙 집중식 복사본의 요금도 안내하며, 게시된 요금에 따르면 첫 번째 중앙 집중식 복사본은 무료입니다. 쿼리 비용은 스캔한 데이터와 사용 한도에 따라 달라집니다. 에이전트 평가에는 Amazon Bedrock AgentCore Evaluations 요금이 적용됩니다. 따라서 유용한 비용 추산에는 에이전트 수뿐 아니라 데이터 양과 보존 기간, 쿼리 패턴, 복사본 수, 평가 빈도도 반영해야 합니다.
트레이스 내용과 액세스 권한을 검토해야 한다
에이전트 트레이스에는 프롬프트와 응답, 검색된 문서, 개인 정보가 포함될 수 있습니다. AWS에 따르면 Omni는 개인 식별 정보를 자동으로 감지하거나 삭제하지 않습니다. AWS의 민감한 데이터 처리 지침은 필터링 위치를 선택하도록 권고합니다. 수집 시점에 데이터를 마스킹하는 방식은 민감한 내용이 애플리케이션 밖으로 나가는 것을 막는 방법입니다.
AWS는 고객 콘텐츠를 파운데이션 모델 학습이나 Omni 자체의 개선에 사용하지 않는다고도 밝혔습니다. 그렇다고 다른 곳에서 콘텐츠가 전혀 처리되지 않는다는 뜻은 아닙니다. 일부 기능은 데이터를 Bedrock이나 AgentCore 같은 서비스로 보내며, AWS는 AI 기능을 위한 리전 간 추론을 문서화하고 있습니다. 데이터는 해당 스페이스의 리전에 저장되지만, AI 요청은 같은 지리적 영역 내 다른 곳에서 처리될 수 있습니다. 특히 추적 콘텐츠의 처리 위치를 제한하는 정책이 있다면 AWS의 데이터 사용 정책과 리전 간 추론 세부 정보를 검토해야 합니다.
액세스 제어도 텔레메트리 파이프라인만큼 면밀히 살펴야 합니다. AWS에 따르면 스페이스 구성원은 기본적으로 해당 스페이스의 모든 텔레메트리를 읽을 수 있습니다. 데이터 범위를 설정하면 구성원이 볼 수 있는 로그 및 트레이스 행을 제한할 수 있습니다. 하지만 이 범위 설정은 행 내부의 필드를 숨기지 않으므로 사용자가 절대 보아서는 안 되는 콘텐츠를 마스킹하는 대신 사용할 수는 없습니다. docs.aws.amazon.com 액세스 제어 문서
Omni를 신중하게 평가하는 방법
이미 CloudWatch를 사용하는 팀이라면 범위를 제한해 테스트함으로써 Omni의 애플리케이션 및 에이전트 통합 화면이 실제 워크플로에 도움이 되는지 확인할 수 있습니다. 프로덕션 트레이스를 보내기 전에 필요한 신호를 파악하고 필터링을 구성하며, 계정 및 리전 액세스를 설정하고 수집과 저장, 분석, 평가 비용을 추산해야 합니다. 그런 다음 생성된 조사 결과와 평가 결과를 현재 사고 대응 절차와 비교합니다.
다른 관측 플랫폼을 사용하는 조직이라면 이번 출시는 워크플로를 평가할 계기이지, 그 자체로 마이그레이션을 결정할 이유는 아닙니다. Omni는 에이전트 품질 신호를 애플리케이션 운영에 더 가깝게 가져오지만, 그 가치는 조사 기능의 유용성과 제어 기능의 적합성, 데이터 흐름의 경제성에 달려 있습니다.
