Amazon Bedrock AgentCore의 스팬(spans)과 트레이스(traces)가 검색 가능해지려면 CloudWatch Transaction Search가 먼저 활성화되어야 하며, 처음 사용하는 사용자는 해당 스팬이 나타날 때까지 약 10분 정도 기다려야 할 수도 있습니다.

이러한 요구 사항은 관찰성(observability) 배포 전략을 세울 때 고려되어야 합니다. 즉, 조사가 필요한 상황에서 관찰성에 의존하기 전에 텔레메트리(telemetry) 경로를 먼저 검증해야 합니다.

확인된 동작과 제안된 기본값 분리하기

플랫폼의 기본값을 확인하기 전까지는 그것을 기준으로 설계하지 마십시오.

현재 AWS 문서에서는 모든 새로운 AgentCore 에이전트에 대해 에이전트별 전용 로그 그룹(log groups)을 보장하지 않습니다. AgentCore 릴리스 노트에서 명시적인 릴리스 수준의 확인 사항을 체크한 다음, 이를 대상 환경에서 보이는 구성과 비교하십시오.

전용 격리(Dedicated isolation)는 디버깅 범위를 좁히고 텔레메트리 소유권을 명확하게 할 수 있습니다. 팀이 단순히 격리가 생성되었다고 가정하기만 한다면, 이 두 가지 이점 중 어느 것도 신뢰할 수 없습니다.

별도의 그룹이 운영 모델의 일부라면, 이를 명시적으로 확인하거나 구성하십시오. 언급되지 않은 동작을 계약(contract)처럼 취급하는 대신, 배포 결과로 무엇이 생성되었는지 기록하십시오.

두 가지 텔레메트리 목적지 모두 확인하기

AWS 문서는 에이전트 런타임 로그(agent runtime logs)와 트레이스 스팬(trace spans)의 목적지를 별도로 구분합니다. 따라서 런타임 메시지가 보인다고 해서 워크플로의 트레이스가 검색 가능한 상태임을 증명하는 것은 아닙니다.

운영자가 나중에 필요로 할 증거를 기록하는 배포 검증 아티팩트(artifact)를 생성하십시오:

1. 에이전트 런타임 로그에 사용된 실제 목적지를 캡처합니다.
2. 트레이스 스팬에 대해 구성된 목적지를 캡처합니다.
3. 처음 사용하는 경우 CloudWatch Transaction Search가 활성화되었는지 확인합니다.
4. 스팬 검색 가능 여부를 판단하기 전에 문서에 명시된 약 10분의 지연 시간을 고려합니다.
5. 알려진 워크플로를 실행하고 그 결과로 생성된 트레이스를 찾을 수 있는지 확인합니다.
6. 프로덕션 사용 전 발생할 수 있는 격차를 해결할 책임자를 기록합니다.

다음 AWS CLI 명령어를 사용하여 배포 구성에 표시된 접두사(prefix)와 CloudWatch 로그 그룹 이름 및 ARN을 대조하여 확인하십시오:

aws logs describe-log-groups --log-group-name-prefix '<prefix-from-deployment-configuration>' --query 'logGroups[].{LogGroup:logGroupName,ARN:arn}' --output table

반환된 로그 그룹 이름과 ARN을 배포 검증 아티팩트(artifact)에 기록하십시오. 이를 통해 환경에 대한 가정을 배포 기록과 함께 전달될 수 있는 증거로 전환하여, 다음 조사자에게 명확한 시작점을 제공할 수 있습니다.

정답뿐만 아니라 워크플로(workflow)를 디버깅하십시오

자율적인 워크플로(workflow)는 계획을 세우고, 도구(tool)를 선택하고, 작업을 재시도하거나, 다른 서비스를 호출하거나, 사람의 검토를 위해 일시 중지할 수 있습니다. 최종 응답만으로는 어떤 단계에서 잘못된 결과가 발생했는지 보여줄 수 없습니다.

워크플로(workflow) 상태, 도구(tool) 권한, 검토 게이트(review gates), 그리고 복구 경로를 매핑하는 것부터 시작하십시오. 해당 매핑을 위의 AWS CLI 확인 절차와 결합하면, 배포 기록에 단순히 제안된 아키텍처만 포함되는 것이 아니라 구체적인 런타임(runtime) 로그 목적지가 포함되도록 할 수 있습니다.

조사의 유용한 단위는 에이전트가 거친 경로입니다. 해당 경로를 재구성할 때 트레이스 스팬(trace spans)과 함께 런타임(runtime) 로그를 검토하십시오. AWS는 이러한 시그널(signals)에 대해 서로 다른 목적지를 지정하므로, 두 경로 모두 명시적인 확인이 필요합니다.

플릿(fleet) 가시성을 잃지 않으면서 에이전트별 경계를 사용하십시오

에이전트별 격리는 팀이 조사할 범위를 좁히고 어떤 담당자가 응답해야 하는지를 명확히 할 수 있습니다. 하지만 동일한 조직이 여러 에이전트에 걸쳐 추론해야 할 때는 트레이드오프(tradeoff)가 발생합니다.

플릿(fleet) 전체에 대한 쿼리(query)와 정책은 격리된 텔레메트리(telemetry)로부터 자동으로 생성되지 않습니다. 팀은 여전히 에이전트 간 조사, 보존(retention), 샘플링(sampling), 장애 알림 및 에스컬레이션(escalation) 규칙을 위한 의도적인 설계를 필요로 합니다.

공유된 운영 계층이 존재하지 않는다면, 한 담당자에게 도움이 되는 경계가 플릿(fleet)의 거버넌스를 더 어렵게 만들 수 있습니다. 로컬 소유권과 플릿(fleet) 감독을 서로 경쟁하는 선택지로 취급하지 말고 함께 설계하십시오.

트레이스 기반 SLO를 운영 가능하게 만드십시오

AgentCore 텔레메트리(telemetry)는 증거를 제공할 수 있지만, 트레이스 기반 SLO(Service Level Objectives)는 여전히 운영자의 책임입니다. 이는 장애 알림, 보존(retention), 샘플링(sampling) 및 에스컬레이션(escalation)에도 동일하게 적용됩니다.

중요한 워크플로 상태(workflow states)를 중심으로 SLO 프레임워크를 구축하십시오. 어떤 트레이스 증거(trace evidence)가 성공적인 진행을 나타내는지, 어떤 실패가 소유자에게 알림을 보내야 하는지, 어떤 텔레메트리(telemetry)를 보존해야 하는지, 샘플링(sampling)을 어떻게 관리할지, 그리고 언제 조사를 에스컬레이션(escalation)할지를 결정해야 합니다.

에이전트별 분리(Per-agent separation)는 단일 워크플로를 더 쉽게 검사할 수 있게 해주지만, 많은 워크플로의 일관성을 유지하는 데 필요한 정책은 추가적인 설계가 필요합니다. AgentCore는 관찰성(observability) 메커니즘을 제공할 뿐, 팀의 운영 결정(operating decisions)을 제공하지는 않습니다.

배포와 함께 증거를 전달하십시오

프로덕션 준비가 된 관찰성 패키지에는 아키텍처, 배포 검증 아티팩트(deployment verification artifact), 조사 패턴, SLO 프레임워크 및 프로덕션 체크리스트가 포함되어야 합니다. 이러한 출력물들은 함께 구성(configuration)과 사람들이 워크플로를 조사하고 관리하는 방식을 연결합니다.

릴리스 게이트(release gate)를 구체적으로 유지하십시오. 실제 로그 및 스팬(span) 목적지를 확인하십시오. 트랜잭션 검색(Transaction Search)을 활성화하십시오. 알려진 스팬이 검색 가능해질 때까지 기다리십시오. 에이전트별 전용 그룹이 필요한 경우, 구성 및 권위 있는 릴리스 문서와 대조하여 확인하십시오.

AgentCore 워크플로를 승격(promoting)하기 전에 어떤 증거가 필요합니까? 확인된 목적지입니까, 검색 가능한 알려진 트레이스(trace)입니까, 아니면 둘 다입니까?

📖 가이드 전문 읽기 → Amazon Bedrock AgentCore Observability: Per-Agent Logs and Traces