CloudWatch Omni가 정상 응답 속의 오답까지 추적한다…콘솔 밖에서 본다

AWS는 2026년 9월 22일 CloudWatch Omni의 정식 제공을 발표하며 정상 처리된 AI 에이전트 응답의 품질까지 살피는 평가·추적 기능을 소개했다. 내장 평가기 17종으로 답변의 정확성과 일관성, 검색 품질, 도구 선택 등을 점검하고, 실행 기록에서 답이 만들어진 과정을 따라갈 수 있다. 개발자는 IDE에서, 운영팀은 AWS 관리 콘솔과 분리된 웹 화면에서 이를 이용한다.

기존 CloudWatch와의 차이는 수집한 데이터를 버리고 새로 시작하는 데 있지 않다. 이미 들어오는 로그·지표·추적을 활용하면서 에이전트의 응답 품질을 실행 단계와 연결해 보는 작업 흐름이 추가된다. 따라서 기존 애플리케이션 데이터에 필요한 설정과 아직 추적을 보내지 않는 에이전트에 필요한 계측은 구분해야 한다. 조직 전체의 데이터를 한 화면에서 보려면 스페이스가 접근하는 계정·리전의 범위도 정해야 한다.

오류 없이 끝난 요청에서 무엇을 찾아내나

일반적인 오류율은 요청이 실패했는지 알려주지만, 성공 응답에 담긴 내용이 질문에 맞는지는 알려주지 않는다. 에이전트가 정상적인 형식으로 답을 반환했어도 검색한 근거를 잘못 사용하거나 부적절한 도구를 선택할 수 있다. Omni는 응답에 대한 평가 점수를 지연 시간, 오류, 토큰 사용량과 같은 추적에서 보여줘 운영 신호와 품질 신호를 함께 살피게 한다. 오답의 발견은 추적 자체보다 어떤 답을 좋은 답으로 볼지 정한 평가 기준에 달려 있다.

추적 탐색기에서는 한 요청에 속한 모델 호출과 도구 호출이 계층화된 시간 순서로 이어진다. 각 단계의 입력과 출력, 지연 시간, 토큰 사용량을 보면 최종 응답에 이르기 전 어느 단계에서 동작이 달라졌는지 조사할 수 있다. 서로 다른 프롬프트나 구성을 사용한 추적을 나란히 놓는 비교 기능도 있다. 이는 응답이 틀렸다는 평가 결과를 실행 경로와 연결하는 수단이지, 추적 기록만으로 답의 진위를 자동 판정한다는 뜻은 아니다.

평가기는 일관성·유용성·근거 충실도·라우팅의 적절성처럼 서로 다른 품질 기준을 다룬다. 운영 중인 응답을 평가할 수도 있고, 추적에서 만든 데이터셋으로 프롬프트나 에이전트 구성을 실험할 수도 있다. 실험 화면은 같은 데이터셋에 대한 평가 점수와 지연 시간, 토큰 사용량을 함께 비교한다. 품질을 높인 구성이 응답 속도와 사용량에 어떤 변화를 가져오는지 한 자리에서 살필 수 있지만, 점수의 의미는 데이터셋과 평가 기준을 어떻게 정했는지에 따라 달라진다.

로컬 개발과 운영 화면은 어떻게 이어지나

IDE 확장 기능은 에이전트를 개발하며 실행 기록과 평가 결과를 확인하는 경로다. 로컬 개발은 AWS 계정 없이 시작할 수 있고 데이터도 기본적으로 로컬에 저장된다. 다만 에이전트가 사용하는 모델에 따라 해당 제공업체의 인증 정보는 필요할 수 있다. 개발 단계에서 생긴 기록을 클라우드에 계속 보관하거나 팀과 공유하려면 Cloud Login으로 AWS 계정에 연결해 원격 측정 데이터를 CloudWatch로 보내야 한다.

운영팀에는 조직 전용 URL로 접속하는 독립 웹 화면이 제공된다. 조직이 관리하는 자격 증명으로 로그인하며, AWS 관리 콘솔을 열지 않고도 애플리케이션 상태와 에이전트 추적, 평가 결과를 살필 수 있다. 이 화면은 개발 중의 추적과 운영 중의 추적을 같은 맥락에서 조사할 수 있는 경로지만, 로컬에만 저장한 실행 기록까지 자동으로 공유되지는 않는다. 어느 기록을 CloudWatch에 전송했는지가 팀이 함께 볼 수 있는 범위를 가른다.

새 에이전트의 실행 과정을 보려면 호출 단계에서 추적 신호가 생성되어야 한다. Omni는 OpenTelemetry 기반 데이터를 받아들이며, 계측된 워크로드는 OpenTelemetry Protocol 엔드포인트로 데이터를 보낼 수 있다. 지원되는 에이전트 프레임워크에는 LangGraph, CrewAI, Strands 등이 포함되고, 기존 에이전트를 위한 자동 계측 경로와 Python·TypeScript 수동 설정 경로도 제공된다. 이미 CloudWatch에 들어오는 애플리케이션 지표가 그대로 보인다는 설명은 아직 생성되지 않은 에이전트 추적까지 만들어 준다는 의미가 아니다.

기존 CloudWatch와 스페이스의 경계

CloudWatch Omni 제품 문서는 이를 기존 CloudWatch 데이터 위에서 작동하는 화면과 작업 흐름으로 설명한다. 기존 콘솔 화면과 지표, 경보, 대시보드, API는 계속 작동하며 현재의 계측도 바꿀 필요가 없다. 로그 그룹과 보존 기간, 수집 엔드포인트 등 데이터의 수집·저장 설정은 여전히 CloudWatch에서 관리한다. Omni를 켜는 일과 기존 원격 측정 체계를 교체하는 일은 별개의 결정이다.

Omni의 도메인은 조직의 로그인 입구이고, 스페이스는 실제로 데이터를 조회하는 작업 범위다. 스페이스는 호스팅된 AWS 계정과 리전 하나에 대응하며, 활성화할 때 생성되는 CloudWatch Dataset이 그 범위의 로그와 추적을 연결한다. 한 도메인 아래 여러 스페이스를 둘 수 있어도 스페이스 사이의 데이터를 자동으로 한 번에 조회할 수 있는 것은 아니다. 팀마다 같은 도메인 URL을 쓰더라도 각자가 보는 데이터는 접근 권한과 스페이스가 속한 위치에 따라 달라진다.

여러 계정이나 리전의 데이터를 한 스페이스에서 조사하려면 CloudWatch 중앙화 규칙으로 해당 데이터를 스페이스가 있는 계정과 리전에 모아야 한다. 스페이스를 추가하는 행위 자체가 다른 위치의 로그와 추적을 복제하지는 않는다. 여러 환경에 에이전트를 배치한 조직이라면 평가 결과가 비어 있는 원인이 실제 품질 문제인지, 추적이 생성되지 않았는지, 또는 조사 중인 스페이스로 데이터가 들어오지 않았는지를 구별해야 한다. 이 경계는 한국과 해외 리전을 함께 쓰는 운영팀에도 그대로 적용된다.

국내 운영팀에 남는 도입 조건

출시 시점의 제공 범위는 미국 동부 버지니아, 미국 서부 오리건, 유럽 아일랜드 리전이다. CIO의 2026년 9월 22일 보도는 이 리전 범위와 기존 고객의 스페이스·접근 권한 설정 필요성을 전하며, Moor Insights and Strategy의 마이클 리오네가 “agent evaluations are only as good as an enterprise’s definition of a good answer”라고 지적한 내용을 실었다. 한국 리전에서 스페이스를 바로 개설하는 것과 한국 리전의 원격 측정 데이터를 지원 리전으로 중앙화해 보는 것은 다른 문제다.

도입 판단에는 네 가지 경계가 있다. 기존 CloudWatch 데이터는 재계측 대상인지보다 현재 어느 계정과 리전에서 수집되는지가 중요하다. 새 에이전트는 모델·도구 호출을 남기는 계측과 답의 품질을 판정할 기준이 필요하다. 로컬 개발 기록은 클라우드 전송 여부에 따라 팀 공유 범위가 달라진다. 여러 계정과 리전을 운영한다면 중앙화 규칙과 스페이스 권한을 함께 정해야 한다.

비용도 평가 점수만 보고 가늠하기 어렵다. 에이전트 실행은 프롬프트와 모델 호출, 도구 사용마다 추적 데이터를 만들며, 수집·저장·분석량과 평가에 쓰는 모델 사용량이 운영 규모에 따라 달라질 수 있다. 특히 성공 응답 속 오답을 꾸준히 찾아내려면 평가할 응답과 데이터셋의 범위를 정해야 한다. 그 범위가 넓어질수록 품질 변화에 관한 정보는 늘지만, 함께 처리하고 보관할 데이터의 양도 커진다.

함께 읽기:

• AI 코딩 에이전트 7종이 업데이트 훅에 뚫렸다…모델은 공격을 못 본다
• Roman 우주망원경 발사, 하루 1.4TB가 암흑우주를 추적한다
• Gemini가 필요한 장면만 다시 본다…영상 토큰을 최대 88% 줄인 방식