2026년 Amazon Bedrock AgentCore 추적 데이터가 보이지 않으면 어떻게 해야 할까요?

CloudWatch에서 AgentCore 호출 로그나 추적 정보를 찾을 수 없습니다. 먼저 계정·리전·Runtime·조회 시간을 맞춘 뒤 Transaction Search와 리소스별 관측성 설정, 로그 목적지, 권한을 확인하세요. AgentCore Runtime 밖에서 실행되는 에이전트라면 OpenTelemetry 계측 여부도 점검해야 합니다.

이 안내는 AgentCore Runtime 호출에 실패했지만 진단 자료가 없는 개발자, CloudWatch 로그와 추적을 설정하는 플랫폼 엔지니어, 운영 환경의 재현 절차를 마련하는 기술 책임자를 위한 내용입니다.

먼저 구분할 문제: 호출 실패, 로그 누락, 추적 누락

세 증상은 원인과 확인 위치가 다릅니다. 호출 자체가 실패했는지, 호출은 됐지만 로그가 없는지, 로그나 지표는 보이는데 spans가 없는지부터 구분하세요. 모두를 막연히 “CloudWatch 오류”로 처리하면 다른 계층의 문제를 놓칠 수 있습니다.

다음 항목을 같은 기준으로 맞춰 비교합니다.

• AWS 계정과 리전이 Runtime을 만든 위치와 일치하는지 확인합니다.
• 조회 대상 Runtime과 실제 호출한 리소스가 같은지 확인합니다.
• 호출 시각을 기준으로 CloudWatch 검색 시간 범위를 다시 지정합니다.
• Runtime 호출 결과와 애플리케이션 로그를 대조해 요청이 실제로 도달했는지 확인합니다.

AgentCore Runtime의 추적 spans가 어디에 표시되는지는 AgentCore 관측성 보기 안내를 기준으로 확인하세요. 로그 화면만 살펴보고 spans가 없다고 결론 내리면 조회 위치가 다른 경우를 지나칠 수 있습니다.

호출이 실패했다면 추적 데이터 설정만 반복해서 바꾸지 마세요. Runtime 오류와 권한 문제를 함께 확인하고, 실패 시각과 응답 정보를 먼저 기록해야 원인을 좁힐 수 있습니다.

Transaction Search와 조회 조건

CloudWatch Transaction Search가 활성화되지 않았거나 설정이 아직 적용되지 않았다면 추적 정보가 검색되지 않을 수 있습니다. Transaction Search 활성화 문서에서 계정 수준 설정과 활성화 요건을 확인하세요. 계정 설정이 켜져 있는지, 현재 확인하려는 데이터가 해당 설정의 적용 대상인지 각각 살펴봐야 합니다.

계정 설정, AgentCore 리소스의 텔레메트리 설정, CloudWatch 검색 조건은 서로 다른 확인 지점입니다. 한 곳이 활성화됐다고 나머지도 자동으로 준비됐다고 가정하지 마세요. 활성화 직후 데이터가 바로 검색되지 않는다면 문서의 처리 안내를 따르되, 예시로 제시된 소요 시간을 모든 계정과 리전의 보장 시간으로 해석해서는 안 됩니다.

AgentCore Runtime 로그·추적 설정 점검

AgentCore 관측성은 지표, 로그, 추적 데이터를 구분해 다룹니다. 따라서 지표가 보인다는 사실만으로 로그와 spans까지 수집 중이라고 판단할 수 없습니다. AgentCore 관측성 문서와 텔레메트리 설정 안내를 함께 열어 리소스 종류별 설정을 대조하세요.

확인 순서는 다음과 같습니다.

• Runtime: 현재 Runtime의 지표·로그·spans 설정을 각각 확인합니다. Runtime 텔레메트리에서 제공하는 데이터 범위는 Runtime 지표 안내와 대조합니다.
• Memory와 Gateway: Runtime과 같은 설정이나 기본값이 적용된다고 가정하지 말고, 해당 리소스의 관측성 설정을 별도로 확인합니다.
• 로그 목적지: 리소스 설정에 기록된 목적지가 현재 검색 중인 CloudWatch 위치와 일치하는지 확인합니다. 목적지 동작이나 설정 관련 변경은 AgentCore 릴리스 노트에서 다시 확인합니다.

어떤 데이터가 기본 제공되고 무엇을 추가로 켜야 하는지는 리소스와 구성에 따라 확인해야 합니다. 한 리소스의 기본값을 다른 리소스에 그대로 적용하거나, 문서 예제를 모든 배포 방식의 보장으로 받아들이지 마세요.

Runtime 밖에서 실행하는 에이전트의 계측

에이전트가 AgentCore Runtime에 의해 호스팅되지 않는다면, 서비스 설정만으로 애플리케이션 내부의 호출 경로가 자동으로 추적된다고 볼 수 없습니다. OpenTelemetry SDK와 프레임워크 계측, 텔레메트리 환경 변수가 애플리케이션 실행 환경에 맞게 설정됐는지 확인하세요. 관측성 시작 안내는 설정 흐름을 확인하는 공식 자료입니다.

같은 요청을 로컬과 클라우드에서 실행해 결과를 비교하면 계측 문제와 목적지 문제를 나누는 데 도움이 됩니다. 로컬에서 spans가 생성되지 않으면 SDK나 프레임워크 계측부터 확인합니다. 로컬에서는 보이지만 클라우드에서만 사라진다면 배포 환경 변수, 서비스 권한, 네트워크 경로와 내보내기 대상이 달라졌는지 살펴보세요. 이 비교는 진단 방법이며, 로컬 성공이 클라우드 권한이나 CloudWatch 수집까지 정상임을 증명하지는 않습니다.

증상별 다음 확인 항목

AgentCore CloudWatch 화면에서 무엇이 보이는지에 따라 다음 점검을 선택하세요. 권한과 목적지 중 어느 쪽을 먼저 볼지는 데이터가 어디까지 도달했는지에 따라 달라집니다.

Runtime 역할이 필요한 권한을 갖췄는지는 Runtime 권한 문서와 대조하세요. 호출 오류가 함께 발생한다면 Runtime 문제 해결 문서도 확인합니다. 권한을 넓게 부여해 증상을 가리는 대신, 실제 역할과 필요한 접근 범위를 먼저 비교하세요.

요청 본문이나 프롬프트를 로그에 남기면 개인정보와 비밀 정보가 노출될 수 있습니다. 재현을 위해 페이로드 기록이 필요하더라도 민감 값을 제거하거나 마스킹하고, 운영 로그 접근 권한과 보존 설정을 함께 검토하세요.

조건에 맞춰 다음 점검을 선택하세요

• 계정·리전·시간 범위가 맞지 않으면: CloudWatch 필터를 먼저 수정하고 같은 요청 시각으로 다시 조회합니다.
• Transaction Search가 꺼져 있으면: 공식 활성화 안내를 따라 계정 수준 설정을 확인한 뒤 새 요청으로 검색 가능 여부를 검증합니다.
• 지표만 있고 spans가 없으면: Runtime의 spans 설정을 확인합니다. Runtime 밖의 에이전트라면 OpenTelemetry 계측을 점검합니다.
• 설정은 맞는데 로그가 비어 있으면: 로그 목적지와 역할 권한을 대조합니다. 호출 실패가 동반되면 Runtime 오류부터 좁힙니다.
• 여러 계정에 걸쳐 조회한다면: 교차 계정 권한과 실제 데이터가 생성된 계정을 먼저 확인합니다.

재현 기록에는 실행 계정과 리전, Runtime 식별 정보, 요청 시각, 호출 결과, 확인한 데이터 종류, Transaction Search 상태, 로그 목적지, 권한 점검 결과를 남기세요. 페이로드를 포함해야 한다면 민감 정보를 제거한 뒤 기록합니다. 이렇게 정리하면 다음 담당자가 같은 기준으로 확인할 수 있습니다.

다음 실행 환경을 고르는 기준

이 문제의 진단 기준은 AgentCore와 CloudWatch 설정입니다. 맥 환경이 AWS 권한이나 CloudWatch 목적지 문제를 대신 해결하지는 않습니다. 다만 에이전트 코드와 OpenTelemetry 계측을 별도로 재현할 테스트 환경이 필요하다면 실행 환경 선택을 검토할 수 있습니다.

AWS 환경은 실제 Runtime 권한과 로그 목적지를 검증하기에 적합하지만, 계정 설정과 권한 경계, 검색 위치를 함께 관리해야 합니다. 로컬 개발 환경은 반복 실험에 유리할 수 있지만 운영 환경과 설정 차이가 남습니다. 맥을 직접 구매하면 물리 장비를 계속 유지해야 하고, 단기 테스트만을 위해서는 초기 구매와 관리가 부담일 수 있습니다. 반대로 물리 인터페이스가 필요하거나 장기간 일정한 부하를 돌려야 한다면 임대보다 직접 보유가 맞을 수 있습니다.

AWS 문제와 별개로 일시적인 macOS 재현 환경이 필요하다면 한국 리전 맥 환경 선택을 살펴볼 수 있습니다. 단기 테스트에서는 장비를 구매·관리하는 부담 없이 환경을 마련할 수 있다는 장점이 있지만, AWS Runtime의 실제 권한과 CloudWatch 수집 여부는 AWS에서 계속 검증해야 합니다. 환경 선택이나 이용 방법을 확인할 때는 kvmboot 도움말 센터를 참고하세요.