Claude OpenTelemetry 관측성, Databricks MLflow 지원으로 에이전트 실패를 가시화

Claude OpenTelemetry 관측성이 이제 Databricks MLflow와 네이티브로 연결되어, 그럴듯한 최종 답변 뒤에 가려질 수 있는 실행 세부 정보를 드러낸다. OpenTelemetry는 애플리케이션 활동을 기록하고 교환하기 위한 공개 표준이다. 이 통합은 근거를 놓치거나, 작업을 반복하거나, 불완전한 응답으로 끝나는 에이전트를 개발자가 조사할 또 하나의 방법을 제공한다.

Databricks는 2026년 11월 3일 이 지원 대상지를 발표했다. Anthropic은 10월 14일 더 폭넓은 네이티브 트레이싱 기능을 퍼블릭 베타로 도입했다. 이 구분은 중요하다. 이는 독점적인 모니터링 협력이 아니라, 더 광범위한 내보내기 시스템 안의 Databricks 통합이기 때문이다.

핵심 쟁점은 팀이 에이전트 성능을 어떻게 판단하는가에 있다. 잘 다듬어진 답변은 에이전트가 무엇을 제공했는지 보여 준다. 실행 기록은 그 결과에 어떻게 도달했는지 설명하는 데 도움이 된다. Langfuse, Grafana 및 다른 관측성 플랫폼은 이미 이 영역에서 활동하고 있다. Databricks는 개발 및 평가 플랫폼인 MLflow를 이러한 근거를 조사와 후속 테스트에 연결하는 공간으로 자리매김하고 있다.

Claude OpenTelemetry 관측성, 네이티브 Databricks 대상지 추가

Databricks에 따르면 개발자는 Anthropic 개발 라이브러리, Messages API 및 Claude Managed Agents에서 Claude의 네이티브 실행 기록을 MLflow로 전송할 수 있다. API는 애플리케이션이 서비스를 요청하는 데 사용하는 인터페이스다. Managed Agents는 작업을 수행하는 Anthropic 호스팅 에이전트다.

native tracing integration은 Databricks의 수집 서비스인 Zerobus Ingest를 사용해 기록을 받는다. 데이터 거버넌스 시스템인 Unity Catalog는 이를 MLflow 실험과 연결된 테이블에 저장한다.

이 변화로 Claude 활동은 기존 엔터프라이즈 조사 환경으로 직접 이어지는 경로를 갖게 된다.

트레이스는 하나의 실행을 기록하고, 스팬은 그 기록 안의 개별 작업을 나타낸다. 모델 요청과 도구 활동은 별도의 스팬으로 표시될 수 있다. 이들의 관계를 통해 조사자는 응답 뒤에 있었던 순서를 따라갈 수 있다.

개발팀에는 이 순서가 디버깅 대화의 출발점을 바꾼다. 누군가에게 실패한 상호작용을 기억에 의존해 재구성해 달라고 요청하는 대신, 팀은 기록된 활동을 살펴볼 수 있다. 그렇다고 정확한 진단이 자동으로 확정되는 것은 아니다. 다만 진단이 다룰 수 있는 구체적인 대상을 제공한다.

이 차이는 답변이 그럴듯해 보일 때 특히 유용하다. 명백한 오류는 즉시 조사를 촉발한다. 하지만 에이전트가 결정적인 출처를 놓쳤거나 정보를 수집하는 데 불필요한 노력을 들였더라도, 그럴듯한 응답은 주의를 피할 수 있다.

가상의 사내 리서치 어시스턴트가 제품 업데이트를 준비하는 상황을 생각해 보자. 최종 요약에는 정확한 배경 정보가 포함되어 있지만 최근 릴리스 노트는 빠져 있다. 요약만 읽어서는 여러 가능성이 열려 있다. 어시스턴트가 문서를 아예 찾지 못했을 수도 있고, 내용을 잘못 이해했을 수도 있으며, 답변을 작성하는 과정에서 해당 발견을 누락했을 수도 있다.

실행 기록은 이러한 가능성을 구분하는 데 도움이 된다. 각 설명은 서로 다른 개입을 가리킨다. 검색 단계에서 관련 문서를 한 번도 노출하지 못했다면, 작성 지침을 바꿔도 큰 효과가 없을 것이다.

이것이 발표의 운영상 의미다. 네이티브 내보내기는 에이전트 상호작용과 이를 조사하는 데 쓰이는 도구 사이의 거리를 줄인다. 여전히 어떤 행동을 실패로 볼지 결정하는 일은 팀의 몫이다.

이 통합은 이번 소식의 경계도 분명히 한다. 새로운 Claude 모델, 더 높은 벤치마크 점수 또는 독립적으로 측정된 신뢰성 향상을 발표한 것은 아니다. 즉각적인 기여는 근거 수집과 접근성에 있다.

이는 지능 향상보다 좁은 주장이다. 그러나 배포된 에이전트의 실질적인 약점을 다룬다. 팀은 살펴보기 어려운 행동을 일관되게 개선할 수 없다.

에이전트 책임자에게는 수용 가능한 답변을 설명해야 하는 압박이 커진다

즉각적인 압박은 실제 워크플로에 에이전트를 승인하는 개발자와 제품 책임자에게 가해진다. 이들의 책임은 답변이 유용하게 들리는지 여부를 넘어선다. 놓친 정보, 낭비된 작업, 배포 후에야 드러나는 실패를 설명해야 한다.

네이티브 트레이싱은 이러한 결정에 활용할 수 있는 근거의 기준을 높인다.

데모는 보통 선택된 하나의 상호작용을 제시한다. 실제 운영에서는 다양한 질문, 불완전한 문서, 변화하는 도구, 모호한 요청이 등장한다. 익숙한 예시는 잘 처리하는 에이전트라도 주변 조건이 달라지면 어려움을 겪을 수 있다.

이는 엔지니어링 문제인 동시에 관리 문제를 만든다. 제품 책임자는 감수할 수 있는 한계와 반복되는 결함을 구분해야 한다. 개발자는 결함을 재현할 만큼 충분한 근거가 필요하다. 도메인 전문가는 답변에 무엇이 포함됐어야 하는지 식별해야 한다.

공유된 기록이 없으면 이 그룹들은 서로 엇갈린 대화를 할 수 있다. 검토자는 답변이 불완전하다고 보고한다. 엔지니어는 성공한 요청을 본다. 제품 관리자는 워크플로를 완료한 사용자를 본다. 각 관찰은 정확할 수 있지만 근본적인 문제는 해결되지 않은 채 남을 수 있다.

Claude 에이전트 트레이싱은 그 대화를 위한 공통의 대상을 제공한다. 팀은 특정 실행을 검토하고 피드백을 실제로 일어난 일과 연결할 수 있다. 이점은 의견 차이를 조사할 수 있을 만큼 구체적으로 만든다는 데 있다.

Anthropic의 agent observability launch에는 서로 다른 모니터링 플랫폼을 사용하는 조직의 고객 사례가 포함되어 있다. Foxglove는 PostHog에서 제품 활동과 함께 에이전트 상호작용을 분석한다고 설명한다. FloQast는 Grafana Cloud에서 모델 활동을 회계 워크플로와 연결한다고 설명한다.

이 사례들은 서로 다른 우선순위를 보여 준다. 로보틱스 제품팀은 지원이 부족한 지점을 이해하려 한다. 금융 워크플로 팀은 에이전트가 수행한 일을 방어 가능한 방식으로 설명하기를 원한다. 두 요구 모두 최종 텍스트를 확인하는 일을 넘어선다.

다만 이는 Databricks 통합에 대한 독립 평가가 아니라 Anthropic이 제시한 고객 발언이다. 보편적인 비즈니스 성과를 입증하지는 않지만, 관련 사용 사례를 보여 준다.

지식 근로자에게도 요약이 다른 의사결정의 근거가 될 때 같은 문제가 나타난다. 누락된 단서는 계획 문서, 고객 응답 또는 엔지니어링 논의로 이어질 수 있다. 유창한 언어는 이러한 누락을 알아차리기 어렵게 만들 수 있다.

검색 가능한 지식 베이스를 구축하는 팀도 관련된 질문에 직면한다. 어떤 문서가 답변을 뒷받침하는가? 에이전트 운영자는 시스템이 그 문서에 적절히 접근하고 활용했는지도 조사해야 한다.

따라서 압박은 구체적이다. 에이전트의 책임 범위를 넓히는 사람은 실패를 검토하고 수정 우선순위를 정할 신뢰할 수 있는 방법이 필요하다. 네이티브 내보내기는 그 검토를 시작하기 쉽게 만든다. 그렇다고 에이전트에 더 많은 책임을 맡길 자격이 있는지 판단하는 데 필요한 판단까지 없애지는 않는다.

이 메커니즘은 실행 근거를 평가와 연결한다

중요한 메커니즘은 기록된 행동과 반복 가능한 개발 의사결정의 연결이다. 근거가 팀의 에이전트 조사나 테스트 방식을 바꾸지 못한다면 활동을 수집하는 가치는 제한적이다.

MLflow 트레이스 분석은 발견 사항이 검증 가능한 설명으로 이어질 때 유용해진다.

가상의 리서치 에이전트가 불완전한 요약을 만들기 전에 문서를 반복해서 연다고 상상해 보자. 반복된 접근은 관찰 가능한 행동이다. 그 원인은 여전히 의문이다. 에이전트에 중단 규칙이 없을 수도 있고, 일관되지 않은 도구 결과를 받을 수도 있으며, 변하는 정보를 합리적으로 다시 확인하고 있을 수도 있다.

반복 읽기 모두를 낭비로 취급하면 이러한 설명을 오해를 부르는 지름길로 축소하게 된다. 조사자는 반복 작업이 유용한 근거를 제공했는지 이해해야 한다. 바람직한 수정 방향은 그 구분에 달려 있다.

따라서 유용한 조사는 관찰된 행동을 기대되는 결과와 연결한다. 팀은 무엇이 잘못됐는지, 제안된 변경이 왜 이를 해결하는지, 어떤 근거가 그 설명을 반박할지를 설명할 수 있어야 한다.

Databricks는 코딩 어시스턴트인 Genie Code로 구동되는 베타 기능 MLflow Issues를 통해 반복 문제 감지를 지원한다고 문서화했다. 이 시스템은 기록된 활동을 분석하고 조사할 이슈로 근거를 그룹화한다.

문서에서는 최근 트레이스로 기준선을 설정하고, 유입되는 활동의 표본을 평가하는 모니터도 설명한다. 스코어러는 지정된 행동이나 결과를 평가하는 함수다.

이 기능들은 개발 루프를 지원하지만 자동 보장으로 오해해서는 안 된다. 이슈 감지기는 관찰을 그룹화하는 유용한 방식을 제안한다. 스코어러는 정의를 운영화한다. 어느 쪽도 그 정의가 실제 작업과 일치하는지 확인할 필요를 없애지 않는다.

예를 들어 도구 호출 횟수가 적을수록 보상하는 평가는 성급한 답변을 부추길 수 있다. 더 나은 평가는 완전성과 함께 불필요한 작업을 고려해야 한다. 그렇지 않으면 겉보기 효율성 향상은 단순히 조사가 줄어든 결과일 수 있다.

응답 속도에도 같은 논리가 적용된다. 답변이 여전히 요청을 충족할 때 더 빠른 완료는 가치가 있다. 에이전트가 중요한 출처를 건너뛴다면, 짧아진 실행 시간은 품질 저하를 감출 수 있다.

작업과 평가 기준을 일정하게 유지하면 비교를 해석할 수 있다. 팀은 수정된 지침이 관련 없는 요구 사항을 약화시키지 않으면서 문제 행동을 개선하는지 물을 수 있다. 이는 서로 다른 버전의 무관한 예시를 비교하는 것보다 더 유익하다.

정확성이 맥락에 달려 있는 경우에는 사람의 전문성이 여전히 필요하다. 주제 전문가는 누락된 예외를 식별하거나, 겉보기에는 중복된 작업이 왜 정당했는지 설명할 수 있다. 이러한 판단은 자동화된 평가가 잘못된 행동을 보상하지 않도록 돕는다.

제품 측면에서의 함의는 관측성과 평가가 같은 개발 대화에 속한다는 점이다. 실행 근거는 결과를 설명한다. 평가는 제안된 수정이 대표적인 작업 전반에서 유지되는지 검증한다.

따라서 구매자에게 중요한 질문은 플랫폼이 보기 좋은 트레이스를 표시하는지보다 더 넓다. 팀이 실패한 상호작용에서 정당화된 변경으로 나아가고, 이후 그 결과를 검토할 수 있는가가 핵심이다.

공개 표준은 비교의 초점을 워크플로와 거버넌스로 옮긴다

Anthropic의 내보내기 설계는 이번 발표에 경쟁적 맥락을 부여한다. Claude 활동은 여러 관측성 대상지에 도달할 수 있다. 따라서 Databricks는 기록이 도착한 뒤에 무엇이 일어나는지로 경쟁해야 한다.

공유된 내보내기 표준은 조사 워크플로를 더 의미 있는 비교 지점으로 만든다.

MLflow의 OpenTelemetry 통합 문서는 이 표준을 활용한 수집과 내보내기를 모두 다룹니다. 또한 생성형 AI 활동을 설명하기 위한 공통 규약도 지원합니다. 이러한 규약은 호환되는 시스템에 관련 정보의 공통 명칭과 구조를 제공합니다.

이로써 모든 모델 통합을 각각 독립된 모니터링 프로젝트로 다루는 방식에 대한 대안이 생깁니다. 팀은 모델 활동이 애플리케이션의 다른 증거 자료와 함께 어떻게 자리해야 하는지 검토할 수 있습니다.

하지만 프로토콜 호환성이 경쟁 제품들을 서로 대체 가능하게 만들지는 않습니다. 실행 기록에는 유용한 인터페이스, 적절한 접근 제어, 이해하기 쉬운 평가 방식, 그리고 팀의 일상 업무 안에서 활용될 자리가 여전히 필요합니다. 이러한 요구 사항은 초기 내보내기의 편의성을 능가할 수 있습니다.

Langfuse, Grafana Cloud, PostHog는 고객 사례를 통해 Anthropic의 출시 자료에 등장합니다. 이들의 존재는 팀마다 서로 다른 출발점에서 에이전트 관측 가능성에 접근한다는 점을 보여 줍니다. 어떤 팀은 AI 평가에서 시작하고, 다른 팀은 인프라 모니터링이나 제품 분석에서 출발합니다.

Databricks의 핵심 주장은 엔터프라이즈 데이터 및 거버넌스와의 근접성에 관한 것입니다. 이미 그곳에서 운영 정보를 조사하는 조직이라면, 에이전트 기록은 익숙한 프로세스 안의 또 다른 데이터세트가 될 수 있습니다.

Unity Catalog 저장소 문서에 따르면 트레이스 접근 권한은 스키마 및 테이블 권한을 따릅니다. 해당 테이블에 접근 가능한 사용자는 연결된 실험 전반의 트레이스를 볼 수 있습니다. 이 세부 사항은 접근 권한 검토 시 주의 깊게 살펴볼 필요가 있습니다.

문서는 SQL을 통해 저장된 기록을 쿼리하는 것도 지원합니다. SQL은 구조화된 데이터를 조회하고 분석하는 데 쓰이는 언어입니다. 이를 통해 데이터 팀은 이미 관리하고 있는 정보와 함께 에이전트 활동을 검토할 또 하나의 경로를 얻습니다.

분석 측면의 매력은 분명합니다. 제품 팀은 특정 실패 패턴을 특정 워크플로 또는 애플리케이션 릴리스와 연결하고 싶을 수 있습니다. 더 까다로운 조직적 질문은 관련 메타데이터가 일관되게 기록되고 이해되고 있는지 여부입니다.

개방형 형식만으로는 그 규율을 제공할 수 없습니다. 팀에는 의미 있는 식별자, 명확한 소유권, 그리고 어떤 비교가 타당한지에 관한 합의가 여전히 필요합니다. 그렇지 않으면 더 큰 기록 집합도 흩어진 로그의 혼란을 되풀이할 수 있습니다.

전송 유연성과 조직적 이식성 사이에도 차이가 있습니다. 호환 가능한 시스템 간에 스팬을 옮기는 일은 하나의 문제입니다. 검토 습관, 평가 기준, 거버넌스 체계를 재현하는 일은 또 다른 문제입니다.

이는 특정 공급업체에 대한 의존에서 벗어난다는 광범위한 주장에 한계를 둡니다. 개방형 프로토콜은 특정 통합 장벽을 낮춥니다. 하지만 구매자는 조사 프로세스의 어느 정도가 플랫폼별 기능에 의존하는지도 계속 살펴봐야 합니다.

경쟁 측면의 시사점은 극적이라기보다 실용적입니다. Claude의 네이티브 내보내기는 독점적 수집 기능만의 중요성을 낮춥니다. 더 중요한 비교 기준은 각 대상 시스템이 사용자가 개발 결정을 내리고 검증하도록 얼마나 효과적으로 돕는가입니다.

베타 상태와 불완전한 기록이 트레이스로 확인할 수 있는 범위를 제한한다

가장 중요한 주의점은 증거를 수집하는 것과 개선을 입증하는 것 사이의 거리입니다. 이 발표는 기능과 사례를 문서화합니다. Databricks 통합이 에이전트 신뢰성을 어떻게 바꾸는지 보여 주는 독립 연구를 제공하지는 않습니다.

트레이스는 조사를 뒷받침하지만, 조사가 완료되었음을 인증하지는 않습니다.

Databricks 게시물에는 특히 유용한 공개 사항이 담겨 있습니다. 반복 이슈 시연은 수동으로 작성되었으며, 해당 사례에서는 자동화된 Issue Detection이 실행되지 않았습니다. 따라서 이 예시는 워크플로 시연으로 읽어야 합니다.

이 공개가 기본 기능 자체를 무효화하지는 않습니다. 다만 이 사례가 입증하는 범위를 제한합니다. 독자는 관련 실패가 의도한 방식으로 제시되는 모습을 볼 수 있지만, 이 이미지를 자동 탐지 정확성의 증거로 받아들여서는 안 됩니다.

기계 생성 진단에도 비슷한 구분이 적용됩니다. 실패한 실행에 대한 설득력 있는 설명은 여전히 평가해야 할 설명입니다. 조사자는 기록된 증거가 이를 뒷받침하는지, 그리고 경쟁하는 설명이 여전히 그럴듯한지를 확인해야 합니다.

범위 역시 또 다른 한계입니다. Anthropic은 자사 서비스에서 기록된 활동과 개발자 애플리케이션 내부에서 기록된 활동을 구분합니다. 하나의 에이전트는 두 환경을 모두 포함할 수 있으므로, 실행의 서로 다른 부분은 서로 다른 계측을 통해 보이게 됩니다.

구매자에게 중요한 질문은 기록이 작업에 중요한 연산을 포괄하는지 여부입니다. 모델 활동을 상세히 설명하더라도 로컬 도구나 상류 정보 소스에 대해서는 불확실성이 남을 수 있습니다.

Anthropic의 API 트레이싱 문서 역시 메타데이터 전용 내보내기와 전체 콘텐츠 내보내기를 구분합니다. 메타데이터는 더 깊은 진단에 필요한 프롬프트, 응답 또는 도구 콘텐츠를 반드시 포함하지 않은 채 활동을 설명합니다.

전체 콘텐츠 수집에는 그에 상응하는 데이터 관리 결정이 따릅니다. 문서는 전달된 정보가 선택한 대상 시스템에 해당 서비스의 보존 및 접근 제어 체계 아래 저장된다고 설명합니다. 따라서 내보내기는 민감한 애플리케이션 정보를 전송하는 다른 작업과 마찬가지로 주의 깊게 다뤄야 합니다.

전달 자체도 오류 없는 과거 기록은 아닙니다. Anthropic은 최선 노력 방식의 전달과 스팬 중복 가능성을 문서화합니다. 또한 손실된 스팬은 재전송할 수 없다고 설명합니다.

이는 부정적 발견에 중요한 함의를 가집니다. 누락된 작업이 에이전트가 그 작업을 수행하지 않았음을 자동으로 입증하지는 않습니다. 조사자는 그러한 결론을 내리기 전에 범위와 전달 상태를 고려해야 합니다.

이러한 한계는 디버깅 증거와 더 강한 보증 주장 사이의 유용한 구분을 시사합니다. 트레이스는 특정 상호작용을 설명하는 데 도움이 될 수 있습니다. 완전한 감사 가능성, 일관된 탐지, 또는 개선된 비즈니스 성과에 관한 주장은 추가 증거가 필요합니다.

구매자는 네이티브 제공 여부와 운영 준비 상태도 구분해야 합니다. 지원되는 대상 시스템이 있다고 해서 모든 팀이 보존 기간, 검토자 접근 권한, 조사 소유권 또는 에스컬레이션에 합의했다는 뜻은 아닙니다. 이러한 결정이 해당 기능이 일상적 관행이 될지를 좌우합니다.

적절한 회의론은 구체적입니다. 무엇이 기록되었고, 무엇이 누락되었으며, 이슈를 어떻게 식별했고, 제안된 수정 사항을 어떻게 검증했는지 물어야 합니다. 이러한 질문은 실용적 가치를 무시하지 않으면서 약속을 평가합니다.

시연을 넘어 범위, 검증된 수정, 도입 현황을 지켜봐야 한다

향후 몇 달 동안 가장 유용한 신호는 범위, 검증된 개선, 지속적인 사용에 관한 것입니다. 각각은 네이티브 내보내기가 에이전트 운영을 더 쉽게 만든다는 주장 중 다른 부분을 다룹니다.

가장 강력한 증거는 눈에 보이는 실패와 대표적인 워크로드에서도 유지되는 수정 사항을 연결할 것입니다.

첫째, 팀이 서비스 호스팅 모델 활동과 자체 애플리케이션 도구 전반에서 일관된 기록을 보여 주는지 지켜봐야 합니다. 조사는 분리된 조각이 아니라 답변을 만든 작업을 따라갈 때 더 유용해집니다.

이러한 연속성의 증거는 Claude OpenTelemetry 관측 가능성의 실용적 근거를 강화할 것입니다. 기록이 단절되었거나 설명되지 않은 누락이 있다는 보고는 팀이 이를 신뢰할 수 있는 범위를 좁힐 것입니다.

이 신호는 실제 워크플로 사례를 통해 평가해야 합니다. 성공적인 내보내기는 정보가 대상 시스템에 도달했음을 확인합니다. 유용한 조사는 그 정보가 팀이 이전에 해결하기 어려워했던 운영 질문에 답했음을 보여 줍니다.

둘째, 안정적인 평가 기준을 갖춘 문서화된 수정 사항을 살펴봐야 합니다. 신뢰할 수 있는 설명은 원래의 실패, 개입 조치, 이후 관찰된 동작을 설명해야 합니다. 또한 목표로 삼은 증상 외의 결과도 다뤄야 합니다.

반복적인 읽기를 멈췄지만 중요한 발견을 놓치기 시작한 리서치 에이전트는 한 결함을 다른 결함과 맞바꾼 것입니다. 유용한 보고서는 두 결과를 모두 살필 것입니다. 그러한 증거는 Databricks가 설명한 개발 루프를 뒷받침할 것입니다.

독립적인 재현은 이 주장을 더욱 강화할 것입니다. 공급업체 시연은 의도된 동작을 보여 줄 수 있는 반면, 외부 사례는 덜 정제된 조건에서 워크플로가 어떻게 작동하는지 드러낼 수 있습니다. 범위가 명확하게 유지된다면 두 형태의 증거 모두 가치가 있습니다.

셋째, 조직이 조사와 검토를 일상 운영의 일부로 만드는지 지켜봐야 합니다. 지속적인 사용은 내보내기를 활성화하기로 한 초기 결정보다 더 중요합니다. 팀에는 발견 사항을 검토하고 변경 사항을 언제 릴리스할지 결정할 책임자가 필요합니다.

구체적인 도입 증거는 이슈가 그 프로세스를 통해 어떻게 이동했는지 설명할 것입니다. 관련 검토자를 식별하고, 개발 대응을 설명하며, 팀이 이후 동작을 어떻게 확인했는지 보여 줄 것입니다.

이는 MLflow 트레이스 분석이 지속적인 에이전트 유지 관리에 기여한다는 주장을 강화할 것입니다. 후속 조치 없는 인상적인 스크린샷 모음만으로는 운영상 이점이 충분히 입증되지 않습니다.

개발자에게 이 발표는 성공적인 에이전트 실행의 기준을 다시 생각해 볼 유용한 계기를 제공합니다. 겉보기에 올바른 답변은 하나의 관찰입니다. 에이전트가 어떻게 작동했는지에 대한 정당한 설명은 다른 수준의 확신을 뒷받침합니다.

엔터프라이즈 구매자에게 이에 상응하는 결정은 워크플로 적합성에 관한 것입니다. 기존 거버넌스, 검토자 전문성, 조사 관행은 네이티브 연결성과 함께 대상 시스템 선택에 영향을 미쳐야 합니다. 가장 좋은 증거는 팀이 실제로 인식하는 해결된 문제입니다.

실패가 중요하고 도메인 전문가가 기대 결과를 설명할 수 있는 에이전트 작업부터 시작하십시오. Claude OpenTelemetry 관측 가능성이 검색 문제와 추론 또는 도구 문제를 구분할 만큼 충분한 실행 정보를 드러내는지 살펴보십시오. 그런 다음 제안된 수정 사항이 필요한 작업을 버리지 않으면서 대표 사례를 개선하는지 물으십시오. 사후에 준비된 더 깔끔한 시연이 아니라 원래 작업에 증거를 연결해 두십시오. 이 접근 방식은 네이티브 트레이싱에 구체적인 목적을 부여하고 플랫폼 비교를 더 유용하게 만듭니다. 에이전트가 그럴듯한 답변을 내놓았을 때, 팀은 어떤 증거를 고려했는지, 프로세스가 어디에서 실패했는지, 다음 버전이 왜 더 큰 신뢰를 받을 만한지 설명할 수 있습니까?