ML Observability

Contexta는 ML Observability를 구조화된 증거를 다루는 하나의 원칙으로 바라봅니다.

이는 Observability가 실행 중인 시스템에서 트레이스(traces), 메트릭(metrics), 로그(logs)를 수집하는 것에 국한되지 않음을 의미합니다. 이러한 시그널들은 여전히 중요하며, 다른 프로덕션 시스템과 마찬가지로 ML 시스템에서도 반드시 필요합니다. 하지만 이것들만으로는 ML 결과가 어떻게 도출되었는지, 그 결과를 신뢰할 수 있는지, 또는 나중에 다른 결과와 어떻게 비교해야 하는지를 설명하기에는 충분하지 않습니다.

ML 실행(run)은 런타임 동작 그 이상의 것들을 남깁니다. 중간 상태, 평가 결과, 아티팩트(artifacts), 환경 조건, 설정 선택, 샘플 수준의 실패, 리포트 및 배포 결정 등을 생성합니다. 이러한 객체 중 일부는 실행 중에 발생합니다. 어떤 것들은 실행 과정 주변에서 생성됩니다. 또 어떤 것들은 누군가가 나중에 결과를 검토, 재현, 비교 또는 배포하려고 시도할 때에야 비로소 의미를 갖게 됩니다.

Contexta의 핵심 주장은 이러한 모든 요소들이 Observability 스토리의 일부로 다루어져야 한다는 것입니다. ML Observability는 사후에도 해당 실행을 이해할 수 있도록, ML 실행 및 결과에 대한 충분한 구조화된 증거를 보존하는 프랙티스입니다.

이 문서는 그러한 관점을 설명합니다. 이 문서는 API 레퍼런스가 아니며, 가능한 모든 Observability 도구에 대한 중립적인 조사 자료도 아닙니다. 이 문서는 Contexta가 ML Observability를 어떻게 생각하는지, 왜 그 관점이 기존의 애플리케이션 Observability보다 더 넓은지, 그리고 왜 이 프로젝트가 실행(runs), 단계(stages), 레코드(records), 아티팩트(artifacts), 리니지(lineage), 환경(environment) 및 리포트(reports)를 중심으로 개념을 구성하는지 설명합니다.

이 문서의 대상 독자

이 문서는 개별 API나 구현 세부 사항을 살펴보기 전에 Contexta 이면의 세계관을 이해하고자 하는 독자를 대상으로 합니다.

기존의 Observability에 익숙하며 ML 시스템에서 무엇이 달라지는지 이해하고 싶은 엔지니어에게 유용할 것입니다. 또한, 이미 실험을 추적하고 있지만 실행, 아티팩트, 평가 증거 및 운영 결과를 연결하는 더 명확한 모델을 원하는 ML 실무자에게도 유용할 것입니다. 오프라인 증거와 프로덕션 동작이 왜 같은 스토리 내에 속해야 하는지를 설명하므로, 운영자 및 플랫폼 팀에게도 유용할 수 있습니다.

이 문서는 의도적으로 개념에 집중합니다. 이 문서의 목적은 모든 기능적 표면을 나열하는 것이 아니라, 프로젝트의 멘탈 모델을 명확하게 읽을 수 있도록 만드는 데 있습니다. 독자들은 Contexta가 ML Observability를 증거에 기반하고, 수명 주기를 반영하고, 재현성을 고려하고, 검토 지향적이라고 말할 때 그것이 실질적으로 무엇을 의미하는지 실무적인 감각으로 이해할 수 있어야 합니다.

핵심 주장

Contexta의 핵심 주장을 가장 짧게 요약하면 아주 단순합니다. 기존의 Observability가 실행 중인 시스템을 그 '시그널'로부터 이해할 수 있는지 묻는다면, ML Observability는 ML의 수명 주기를 그 '증거'로부터 이해할 수 있는지 묻습니다.

시그널은 그 증거의 일부이지만, 전체 모델은 아닙니다. 트레이스는 어디에 시간이 소요되었는지 보여줄 수 있습니다. 메트릭은 점수가 어떻게 변했는지 보여줄 수 있습니다. 로그 라인은 폴백 경로가 사용되었음을 보여줄 수 있습니다. 그러나 ML 조사에는 보통 그보다 더 많은 컨텍스트가 필요합니다. 결과를 생성한 실행이 무엇인지, 메트릭을 생성한 단계가 무엇인지, 어떤 아티팩트가 생성되었는지, 어떤 환경이 출력을 형성했는지, 어떤 샘플이 실패했는지, 그리고 이 증거가 결정을 뒷받침할 만큼 충분히 완전한지 알아야 합니다.

이것이 바로 Contexta가 취하는 개념적 전환입니다. Contexta는 Observability 데이터를 단순히 운영상의 텔레메트리(telemetry)로만 취급하지 않고 미래의 조사, 비교, 재현성, 검토 및 운영상의 의사 결정을 위한 영구적인(durable) 증거로 다룹니다.

텔레메트리 시스템은 우리에게 무언가 일어났음을 알려줄 수 있습니다. 반면 증거 시스템은 무엇이 일어났는지, 어디서 일어났는지, 무엇을 생성했는지, 다른 객체들과 어떻게 연결되는지, 그리고 우리가 그 기록을 얼마나 신뢰해야 하는지를 이해하도록 도와야 합니다.

기존의 Observability가 ML에 충분하지 않은 이유

기존의 Observability는 운영상의 질문에 답하는 데 탁월합니다. 팀이 요청에 시간이 어디서 소요되었는지, 어떤 의존성이 실패했는지, 오류 양이 증가했는지, 혹은 지연 시간과 처리량이 어떻게 변하고 있는지 이해하도록 돕습니다. ML 시스템 역시 여전히 이러한 답변을 필요로 합니다. 학습 작업, 평가 파이프라인, 피처 빌더(feature builders), 배치 스코어링 작업 및 추론 서비스 모두 트레이스, 메트릭 및 로그의 이점을 누릴 수 있습니다.

문제는 기존의 세 가지 기둥인 트레이스, 메트릭, 로그가 틀렸다는 것이 아닙니다. 문제는 이것들이 ML 결과의 수명 주기를 설명하기에는 너무 협소하다는 점입니다.

이전 후보 모델보다 더 나은 집계 점수를 생성하는 모델 평가를 예로 들어보겠습니다. 기존의 Observability 시스템은 평가 작업이 완료되었다는 사실, 시간이 얼마나 걸렸는지, 로그에 오류가 나타났는지 여부를 알려줄 수 있습니다. 이 정보도 유용하지만, 가장 중요한 ML 관련 질문에는 답하지 못합니다. 어떤 데이터셋 스냅샷이 사용되었는지, 정확히 어떤 실행이 해당 후보를 생성했는지, 어떤 샘플이 개선되거나 퇴행했는지, 환경이 변경되었는지, 어떤 리포트가 그 증거를 요약했는지, 또는 결과 아티팩트가 실제로 프로모션 되었는지는 알려주지 않습니다.

동일한 패턴이 학습 과정에서도 나타납니다. 트레이스는 학습 과정에서 데이터 로딩, 포워드 패스(forward passes), 체크포인트 저장 또는 평가에 얼마나 시간을 썼는지 보여줄 수 있습니다. 메트릭은 시간에 따른 training loss와 validation loss를 보여줄 수 있습니다. 로그는 경고를 기록할 수 있습니다. 하지만 시스템이 이러한 시그널들을 명명된 실행(named run), 단계, 환경 스냅샷, 생성된 체크포인트, 데이터셋 버전 및 향후 리포트와 연결하지 못한다면, 증거는 단편적인 상태로 남게 됩니다. 즉각적인 디버깅에는 도움이 될 수 있지만, 나중에 이를 설명하기에는 그 근거가 빈약합니다.

또한 ML 워크플로우는 본질적으로 '요청 중심'이 아닌 질문들을 만들어냅니다. 팀은 논의 중인 모델을 어느 실행에서 만들었는지, 어떤 단계에서 regression이 발생했는지, 집계 점수가 양호함에도 실패한 샘플은 무엇인지, 어떤 아티팩트가 프로모션 되었는지, 어떤 패키지 세트가 해당 출력을 생성했는지, 또는 기록에서 누락된 증거는 무엇인지 질문할 수 있습니다. 이러한 것들은 부차적인 질문이 아닙니다. 사람들이 ML 시스템을 구축, 평가, 검토 및 운영할 때 던지는 핵심 질문들입니다.

이것이 바로 Contexta가 텔레메트리에서 멈추지 않는 이유입니다. Contexta는 ML Observability를 구조화된 증거 시스템으로 취급합니다. 그 목표는 실행 중에 무슨 일이 일어났는지 아는 것뿐만 아니라, 나중에 그 실행을 완벽히 이해할 수 있도록 충분한 컨텍스트를 보존하는 것입니다.

시그널에서 증거로

"증거"라는 단어는 수집에서 설명으로 초점을 전환하기 때문에 매우 중요합니다.

시그널은 시스템이 내보내는 것입니다. 반면 증거는 미래의 독자가 결론을 이해하거나, 정당화하거나, 혹은 이의를 제기하는 데 사용할 수 있는 것입니다. 동일한 데이터 포인트가 이 두 가지 역할을 모두 수행할 수 있습니다. Validation Accuracy 메트릭은 평가 중에 발생할 때는 하나의 시그널입니다. 하지만 나중에 누군가가 모델을 프로모션해야 하는지, 왜 한 실행이 다른 실행보다 성능이 좋은지, 또는 리포트를 신뢰할 수 있는지 물을 때 그것은 증거가 됩니다.

메트릭 값 자체만으로는 이러한 질문을 뒷받침하기에 내용이 너무 빈약한 경우가 많습니다. 예를 들어, validation_accuracy = 0.91이라는 값은 주변 컨텍스트가 보존될 때만 의미가 있습니다. 이 값이 어떤 실행에 속하는지, 어떤 단계에서 생성되었는지, 어떤 데이터셋이나 슬라이스를 설명하는지, 어떤 환경에서 생성되었는지, 어떤 아티팩트 번들이 이를 문서화하는지, 캡처의 일부가 저하(degrade)되지는 않았는지 알아야 합니다. 이러한 구조가 없다면 해당 메트릭은 여전히 하나의 숫자일 뿐, 증거로서는 설득력이 떨어집니다.

이러한 차이는 왜 Contexta가 스키마 우선의 증거 지향적 모델을 선호하는지 설명해 줍니다. 로그, 메트릭, 스팬은 여전히 중요하지만, 이들은 더 큰 증거 그래프의 일부로 저장됩니다. 프로젝트, 실행, 단계, 샘플, 아티팩트, 환경 및 하위 결정에 연결될 때 이들의 가치는 더욱 커집니다.

증거는 시간적 특성 또한 가지고 있습니다. 시그널은 주로 그것이 나타난 순간 근처에서 소비됩니다. 하지만 증거는 그 순간이 지난 후에도 유용하게 남아 있어야 합니다. 배포가 실패하거나, 감사 질문이 나오거나, 모델이 퇴행하거나, 리포트를 재현해야 할 때 팀은 며칠 혹은 몇 달 후에 특정 실행을 다시 살펴봐야 할 수도 있습니다. 그 시점에서, 형태 없는 기억이나 파편화된 대시보드는 구조화된 컨텍스트를 대신하기엔 턱없이 부족합니다.

이러한 관점에서, Observability는 실행 중인 시스템을 관찰하는 것만을 의미하지 않습니다. 사후에 결과를 검사, 비교 및 설명할 수 있도록 일어난 일의 의미를 보존하는 것이기도 합니다.

핵심 증거 모델

Contexta의 핵심 질문은 단순히 "런타임에 무슨 일이 일어났는가?"가 아니라 "나중에 누군가가 이 결과를 이해하려면 무엇이 필요할 것인가?"입니다.

그 미래의 독자는 퇴행을 디버깅하는 엔지니어일 수도 있고, 후보 실행들을 비교하는 ML 실무자, 배포 상태를 조사하는 운영자, 증거가 충분한지 확인하는 검토자, 혹은 변경 사항을 평가하려는 자동화된 에이전트일 수도 있습니다. 이 모든 경우에 독자에게는 단순한 데이터 발생의 흐름 그 이상이 필요합니다. 구조화된 실행 설명이 필요합니다.

따라서 유용한 ML Observability 모델은 무엇이 실행되었는지, 실행이 어떻게 구조화되었는지, 어떤 증거가 생성되었는지, 어떤 아티팩트가 생성되거나 소비되었는지, 어떤 환경이 결과를 형성했는지, 결과 객체들이 어떻게 연결되어 있는지, 무엇이 리포트나 배포로 이어졌는지, 그리고 이 증거가 얼마나 완전한지를 보존해야 합니다.

이는 기존의 텔레메트리 중심 Observability와는 다른 멘탈 모델로 이어집니다. 로그와 메트릭에서 출발하여 나중에 소비자가 나머지를 추론할 수 있기를 바라는 대신, Contexta는 프로젝트, 실행, 단계, 레코드, 아티팩트, 리니지, 리포트와 같은 표준 객체에서 시작합니다. 텔레메트리는 여전히 이 모델의 일부로 남지만, 그것 자체로 모든 의미를 짊어질 것을 요구받지는 않습니다.

이러한 차이는 미묘하지만 중요합니다. 텔레메트리 우선 시스템에서는 추후 조사를 할 때 흩어진 사실들로부터 의미를 재구성하는 경우가 많습니다. 증거 우선 시스템에서는 의미 모델이 기록의 일부로서 보존됩니다. 메트릭은 이미 자신의 범위를 알고 있습니다. 아티팩트는 자신을 생성한 실행이 무엇인지 알고 있습니다. 리포트는 자신이 어떤 증거를 요약하는지 알고 있습니다. 기능 저하 마커는 기록의 일부를 주의해서 다루어야 한다는 점을 독자에게 미리 알려줍니다.

목표는 단지 데이터 자체를 더 많이 수집하는 데 있지 않습니다. 매번 의미 구조를 다시 구축하지 않고도 미래의 질문에 답할 수 있도록 만드는 것이 핵심 목표입니다.

ML Observability의 8가지 계층

Contexta가 바라보는 ML Observability는 8가지 계층을 통해 이해할 수 있습니다. 이 계층들은 독립적으로 단절된 사일로(silo)가 아닙니다. 이들은 서로 연결될 때 더 유용해지는 다양한 종류의 증거를 설명합니다.

계층	캡처 대상	답변하는 질문
실행 컨텍스트 (Execution context)	프로젝트, 실행, 단계, 작업	이 증거는 어디에 속하는가?
레코드 패밀리 (Record families)	이벤트, 메트릭, 스팬, 기능 저하 마커	실행 중에 무슨 일이 일어났는가?
단위 세분화 (Granularity units)	배치, 샘플	어떤 특정 단위가 실패하거나 변경되었는가?
아티팩트 증거 (Artifact evidence)	체크포인트, 리포트, 번들, 스냅샷	이 실행은 무엇을 생성하거나 소비했는가?
재현성 컨텍스트 (Reproducibility context)	플랫폼, 패키지, 환경, 설정	이것은 어떤 조건에서 발생했는가?
관계 추적 (Relationship tracing)	리니지, 출처(provenance)	실행, 아티팩트, 리포트, 배포는 어떻게 연결되어 있는가?
운영 결과 (Operational outcome)	프로모션, 배포, 하위 상태	실행 결과로 무엇이 다음 단계로 넘어갔는가?
조사 및 해석 (Investigation and interpretation)	쿼리, 비교, 진단, 트렌드, 리포트	사용자는 증거를 어떻게 이해하고 소통할 수 있는가?

초기 계층은 무엇이 어디서 일어났는지 정의합니다. 중간 계층은 증거, 컨텍스트, 생성된 객체를 연결합니다. 후반부 계층은 이러한 요소들이 결정, 프로덕션 결과 및 사람의 해석과 어떻게 연결되는지 설명합니다.

특정 계층이 누락되면, 전체적인 스토리가 특정 측면에서 약해집니다. 실행 컨텍스트가 없으면 증거의 의미론적 위치를 잃게 됩니다. 세분화가 없으면 집계된 메트릭이 국소적인 실패를 숨길 수 있습니다. 아티팩트가 없으면 출력의 기준을 잡기 어렵습니다. 재현성 컨텍스트가 없으면 비교가 취약해집니다. 리니지가 없으면 관련된 객체들이 하나의 설명으로 구성되지 않습니다. 조사 표면이 없으면 증거가 존재하더라도 사용하기 어렵습니다.

이 계층들은 완벽을 위한 체크리스트가 아닙니다. 실제 시스템은 흔히 특정 계층을 다른 계층보다 더 깊이 있게 캡처합니다. 중요한 점은 각 계층이 ML 팀이 결국 묻게 될 질문의 종류를 설명한다는 것입니다. 시스템이 더 많은 계층을 연결할 수 있을수록, 일어난 일을 재구성하기 위해 사용자가 나중에 해야 할 작업은 줄어듭니다.

1. 실행 컨텍스트 (Execution Context)

실행 컨텍스트는 관찰 대상의 형태를 정의합니다.

기존 서비스에서 가장 자연스러운 Observability 단위는 보통 요청, 프로세스, 또는 서비스 경계입니다. ML 시스템에서 가장 자연스러운 단위는 주로 실행(run)입니다. 실행은 학습 실행, 평가 패스, 프롬프트 평가 세션, 내보내기(export) 워크플로우 또는 배치 추론 작업을 나타낼 수 있습니다. 사용자가 무슨 일이 일어났는지, 결과가 좋았는지, 다른 시도와 어떻게 비교되는지 물을 때 다시 찾게 되는 객체입니다.

Contexta는 실행 컨텍스트를 프로젝트(Project), 실행(Run), 단계(Stage), 작업(Operation)을 중심으로 구성합니다.

프로젝트(Project)는 관련된 작업들에 안정적인 보금자리를 제공합니다. 모델 제품군, 제품 워크플로우, 실험 도메인, 또는 논리적인 애플리케이션 경계에 해당할 수 있습니다. ML 증거는 시간이 지남에 따라 축적되기 때문에 이는 중요합니다. 단일 실행도 그 자체로 의미가 있지만, 트렌드, 비교, 리포트, 배포 이력을 함께 해석할 수 있는 프로젝트에 속할 때 더욱 유용해집니다.

실행(Run)은 조사의 기본 단위입니다. 사용자가 나중에 검사하고 싶어 하는 핵심 대상입니다. 누군가가 후보 모델의 성능이 어떠했는지, 어떤 아티팩트를 생성했는지, 증거가 완전한지, 혹은 프로모션할 만큼 양호한지 물을 때, 대개 실행 중심의 질문을 하는 것입니다. 실행을 중심에 두면 메트릭, 이벤트, 아티팩트, 환경 스냅샷, 리포트 모두를 하나의 공유 객체에 연결할 수 있으므로, 나머지 Observability 모델을 추론하기가 더 쉬워집니다.

단계(Stage)는 실행에 의미론적인 내부 구조를 부여합니다. train 단계의 메트릭은 둘 다 숫자일지라도 evaluate 단계의 메트릭과 같은 의미를 갖지 않습니다. prepare 중의 경고는 export 중의 경고와 같은 의미가 아닙니다. prepare, train, evaluate, retrieve, generate, package, export와 같은 단계를 보존함으로써, 시스템은 나중에 독자가 증거가 수명 주기의 어느 부분에 속하는지 이해할 수 있게 합니다.

작업(Operation)은 단계 내부에 더 세밀한 구조를 제공합니다. 이는 단계 수준의 가시성이 너무 거칠 때 유용합니다. 토큰화, 피처 정규화, 검색(retrieval), 리랭킹, 체크포인트 직렬화, 메트릭 집계 등은 모두 국소적인 실패, 성능 저하 또는 예상치 못한 아티팩트를 설명할 수 있기 때문에 관찰할 가치가 있는 작업들입니다.

이 계층은 단순한 명명(naming) 작업처럼 보일 수 있어 과소평가하기 쉽습니다. 하지만 실제로는 그 이상입니다. 실행 컨텍스트는 향후 증거가 의미 있는 주소를 가질지 여부를 결정합니다. 메트릭이 타임스탬프에만 연결되어 있다면, 독자는 그것이 어디에 속하는지 추론해야 합니다. 프로젝트, 실행, 단계, 작업에 연결되어 있다면 해석은 훨씬 직접적입니다.

실행 컨텍스트가 약할 때, 팀은 명명 규칙, 폴더 구조 또는 비공식적인 기억으로 이를 보완하려 합니다. 파일 이름에 실행 식별자를 포함하거나, 로그 메시지에 단계를 언급하거나, 대시보드에서 규칙에 따라 값을 그룹화합니다. 이러한 접근 방식은 소규모 팀에서는 효과적일 수 있지만, 원래의 컨텍스트가 잊혀진 후 증거를 비교, 감사, 내보내기, 재검토해야 할 때 취약해집니다.

이 계층의 핵심은 단순한 정리가 아닙니다. 실행 컨텍스트는 해석의 중추입니다. 이것이 없다면 메트릭은 분리된 숫자일 뿐이고, 로그는 고립된 기록이며, 아티팩트는 출처를 설명하기 위해 명명 규칙이나 사람의 기억에 의존하게 됩니다. 이를 통해 증거는 의미 있는 범위에 연결될 수 있습니다.

예시: 실행 컨텍스트 증거

최소한의 실행 컨텍스트 기록은 다음과 같을 수 있습니다 :

{
  "project": "rag-support-bot",
  "run_id": "run_2026_05_03_eval_014",
  "run_type": "evaluation",
  "started_at": "2026-05-03T09:12:44Z",
  "stages": [
    {
      "name": "prepare",
      "status": "completed",
      "started_at": "2026-05-03T09:12:44Z",
      "ended_at": "2026-05-03T09:13:10Z"
    },
    {
      "name": "retrieve",
      "status": "completed",
      "started_at": "2026-05-03T09:13:10Z",
      "ended_at": "2026-05-03T09:18:21Z"
    },
    {
      "name": "evaluate",
      "status": "completed",
      "started_at": "2026-05-03T09:18:21Z",
      "ended_at": "2026-05-03T09:24:03Z"
    }
  ]
}

이는 아직 품질, 아티팩트 또는 리니지를 설명하지 않습니다. 그 목적은 더 단순하고 기초적입니다. 나중에 사용할 증거에 주소를 제공하는 것입니다. 메트릭에서 충실도가 떨어졌다고 나오면, 독자는 해당 메트릭이 evaluate에서 왔는지, 검색(retrieval)이 먼저 완료되었는지, 실행이 예상 수명 주기를 따랐는지 확인할 수 있습니다.

실제로 이러한 종류의 증거는 사용자가 실행 간의 단계 소요 시간을 비교하고, 누락된 단계를 감지하며, 워크플로우의 올바른 부분에 경고를 연결하고, 실행 형태를 재구성하기 위해 파일 이름이나 대시보드 필터에 의존하지 않도록 돕습니다.

2. 레코드 패밀리 (Record Families)

레코드 패밀리는 실행 중에 수집되는 추가(append) 방식의 사실들입니다. 이는 기존의 Observability와 가장 유사한 계층이지만, Contexta는 이러한 레코드들을 의미론적 실행 컨텍스트에 연결된 증거로 취급함으로써 프레임워크를 확장합니다.

이벤트(Event)는 실행의 흐름에서 발생하는 개별적인 사실들을 설명합니다. 데이터셋이 로드되었다, 검증이 시작되었다, 체크포인트가 저장되었다, 폴백 경로가 사용되었다, 스키마 검증이 실패했다 등입니다. 덜 구조화된 시스템에서 이러한 사실들은 단순한 로그 라인으로만 나타날 수 있습니다. Contexta에서는 실행, 단계, 작업, 배치 또는 샘플에 연결되고 나중에 쿼리될 수 있기 때문에 훨씬 유용합니다.

이벤트는 수명 주기 전환이나 비정상적인 경로를 표시할 때 특히 유용합니다. 성공적으로 완료되었지만 폴백 로더를 사용한 실행은 예상 경로를 따른 실행과 동일하지 않을 수 있습니다. 시작은 되었으나 완료 이벤트를 내보내지 않은 검증 단계는 진단이 필요할 수 있습니다. 경고 발생 후에 저장된 체크포인트는 정상적인 실행 중에 저장된 것과 다르게 해석되어야 할 수 있습니다. 이들은 작은 내러티브적 사실이지만 검토 과정에서 종종 중요하게 작용합니다.

메트릭(Metric)은 측정된 값을 설명합니다. 여기에는 학습 손실, 검증 손실, 정확도, F1, 관련성, 충실도, 지연 시간, 처리량, 아티팩트 크기 등 익숙한 ML 값들이 포함됩니다. 중요한 점은 ML 메트릭에 범위(scope)가 필요하다는 것입니다. 실행 수준의 평균, 단계 수준의 집계, 스텝별 학습 곡선, 슬라이스 특정 점수, 샘플 수준의 평가 값은 같은 개념의 버킷에 뭉뚱그려져서는 안 됩니다. 이들은 서로 다른 질문에 답합니다.

이 범위 지정(scoping) 문제는 ML 메트릭이 많은 서비스 메트릭보다 더 복잡한 이유 중 하나입니다. 서비스 대시보드에서는 평균 지연 시간이나 오류율만으로도 팀에 문제가 있음을 알리기에 충분할 수 있습니다. 하지만 ML에서는 평균 품질 메트릭이 정작 중요한 패턴을 숨길 수 있습니다. 모델이 전체적으로는 개선되었지만 중요한 슬라이스에서는 퇴행할 수 있습니다. 검색 시스템이 평균 관련성은 유지하면서도 특정 구조의 프롬프트에서는 실패할 수 있습니다. 학습 곡선이 요약 수준에서는 안정적으로 보이지만 후반부 에포크에서 불안정성을 유발할 수 있습니다.

스팬(Span)은 시간이 지정된 실행 구간을 설명합니다. 시간이 어디에 쓰였는지, 어떤 작업이 느려졌는지, 단계가 퇴행했는지, 시간 초과나 실패가 어디서 발생했는지 설명하는 데 도움이 됩니다. 검색, 특징 추출, 추론 호출, 평가 루프 또는 내보내기 작업과 같이 비용이 많이 드는 하위 단계가 ML 파이프라인에 포함되어 있을 때 특히 유용합니다.

Contexta에서 스팬은 중요하지만 지배적이지는 않습니다. 여러 레코드 패밀리 중 하나일 뿐입니다. 트레이스가 기간과 순서를 설명할 수는 있지만, 아티팩트의 의미, 샘플 수준의 품질, 환경 조건 또는 다운스트림 배포 결정 자체를 설명하지는 못하기 때문입니다.

기능 저하 마커(Degraded marker)는 불완전성을 명시적으로 나타냅니다. 이는 기본적인 텔레메트리 모델과 Contexta 증거 모델 사이의 가장 뚜렷한 차이점 중 하나입니다. Observability 데이터가 항상 완전한 것은 아닙니다. 캡처가 부분적일 수 있고, 가져오기(imports) 중 세부 정보가 손실될 수 있으며, 재생(replay)에 간격이 있을 수 있고, 검증 중 경고가 발생할 수 있습니다. 시스템이 이러한 저하된 상태를 표현할 수 없다면, 미래의 독자는 침묵을 건전성이나 완전성으로 오해할 수 있습니다.

기능 저하 마커는 단순한 오류가 아닙니다. 그것은 증거 품질에 대한 증거입니다. 레코드, 단계, 아티팩트, 가져오기 또는 재생을 주의해서 해석해야 함을 독자에게 알려줍니다. ML 시스템에서는 저장된 기록을 바탕으로 나중에 결정을 내리는 경우가 많기 때문에 이러한 구분이 중요합니다. 샘플 캡처가 누락된 실행도 여전히 유용할 수 있지만, 증거가 완전한 실행과 동일하게 취급되어서는 안 됩니다.

이 계층은 실행에 생생한 디테일을 부여하기 때문에 중요합니다. 실행 컨텍스트가 train 단계의 존재를 알려준다면, 레코드 패밀리는 그 안에서 무슨 일이 일어났는지, 값이 어떻게 변했는지, 어떤 마일스톤이 발생했는지, 어떤 경고가 나타났는지, 실행이 어디서 느려지거나 저하되었는지 알려줍니다.

레코드 캡처가 약하면, 실행은 충분한 히스토리가 없는 뼈대에 불과하게 됩니다. 사용자는 단계가 존재했고 아티팩트가 생성되었다는 것은 알 수 있지만, 실행이 어떤 경로를 취했는지, 경고가 언제 발생했는지, 메트릭이 어떻게 진화했는지, 또는 증거가 완전한지 여부는 모를 수 있습니다. 더 넓은 모델은 레코드를 대체하는 것이 아니라, 레코드에 더 강력한 컨텍스트를 부여합니다.

예시: 레코드 증거

실행은 동일한 평가 단계 동안 여러 레코드 패밀리를 내보낼 수 있습니다 :

{
  "records": [
    {
      "type": "event",
      "run_id": "run_2026_05_03_eval_014",
      "stage": "evaluate",
      "name": "evaluation_started",
      "timestamp": "2026-05-03T09:18:21Z"
    },
    {
      "type": "metric",
      "run_id": "run_2026_05_03_eval_014",
      "stage": "evaluate",
      "name": "faithfulness",
      "scope": "slice",
      "slice": "refund_questions",
      "value": 0.72
    },
    {
      "type": "span",
      "run_id": "run_2026_05_03_eval_014",
      "stage": "retrieve",
      "operation": "rerank_documents",
      "duration_ms": 1842
    },
    {
      "type": "degraded_marker",
      "run_id": "run_2026_05_03_eval_014",
      "stage": "evaluate",
      "reason": "sample_outputs_partially_redacted",
      "severity": "warning"
    }
  ]
}

이 예시는 구조화된 레코드가 왜 더 유용한지 보여줍니다. 충실도 메트릭은 단순한 숫자가 아니라 실행, 단계, 특정 슬라이스에 속합니다. 스팬은 단순히 경과 시간을 보고하는 것이 아니라 그것을 소비한 작업을 식별합니다. 기능 저하 마커는 일부 평가 증거를 주의해서 해석해야 함을 독자에게 알려줍니다.

사용자는 이 레코드 세트를 사용하여 품질 저하가 특정 슬라이스에 국한된 것인지, 검색 지연 시간이 변경되었는지, 실행 중 비정상적인 경로가 발생했는지, 그리고 프로모션 결정을 뒷받침할 만큼 증거가 완전한지 물을 수 있습니다.

3. 단위 세분화 (Granularity Units)

ML 시스템은 종종 불균일하게 실패합니다.

모델이 전체 실행 수준에서는 건전해 보이지만 특정 데이터 슬라이스에서는 심각하게 실패할 수 있습니다. 검색 시스템이 평균적으로는 성능이 좋지만 특정 프롬프트 유형에서는 지속적으로 실패할 수 있습니다. 평가 파이프라인이 안정적인 집계 점수를 보여주지만 소수의 샘플에서 심각한 퇴행을 보일 수 있습니다.

이것이 Contexta가 단위 세분화를 Observability의 일부로 취급하는 이유입니다. 배치 및 샘플 수준의 증거를 통해 집계된 메트릭이 숨기고 있는 실패를 볼 수 있습니다.

배치(Batch)는 단계 내의 개별적인 데이터 처리 단위입니다. 워크플로우에 따라 에포크, 미니배치 그룹, 교차 검증 폴드, 일괄 가져오기의 파일, 또는 스트림 청크를 나타낼 수 있습니다. 배치 수준의 증거는 단계 내부 어디에서 불안정성이 나타났는지 답하는 데 도움을 줍니다. 하나의 폴드가 비정상적인 메트릭을 생성했거나, 하나의 가져오기 청크가 실패했거나, 하나의 에포크가 성능 저하를 유발했음을 보여줄 수 있습니다.

배치 가시성은 단계를 하나의 단위로 해석하기에 너무 클 때 특히 유용합니다. 학습 단계는 많은 에포크 동안 실행될 수 있습니다. 배치 스코어링 단계는 많은 파일을 처리할 수 있습니다. 데이터 가져오기는 많은 청크를 소비할 수 있습니다. 시스템이 단계 수준의 결과만 기록한다면, 단계 내의 국소적인 문제들은 요약 속에 묻혀버립니다. 배치 수준의 증거는 전체 단계와 개별 샘플 사이의 중간 해상도를 제공합니다.

샘플(Sample)은 실행 중 마주치는 개별 단위입니다. 학습 예제, 검증 행, 이미지, 프롬프트, 생성된 답변, 검색된 문서 또는 모델 동작의 다른 단위일 수 있습니다. 샘플 수준의 증거는 '품질이 변했다는 것을 아는 것'과 '왜 변했는지 이해하는 것' 사이의 차이를 만들어내는 경우가 많습니다.

이 계층은 집계 점수가 오해를 불러일으킬 수 있는 최신 ML 및 LLM 시스템에서 특히 중요합니다. 모델이 전체 벤치마크는 통과하더라도 법적으로 민감한 사례, 소수(minority) 슬라이스, 롱테일 프롬프트, 또는 운영상 중요한 엣지 케이스에서는 실패할 수 있습니다. RAG 파이프라인이 평균적으로는 건전해 보이지만 특정 범주의 질문에 대해 지속적으로 무관한 컨텍스트를 검색할 수 있습니다. LLM 심사자가 허용 가능한 집계 점수를 내면서도 몇 가지 예시에서 심각한 환각이나 정책 위반을 노출할 수 있습니다.

샘플 수준의 증거가 모든 시스템이 모든 입력을 영구히 저장해야 함을 의미하지는 않습니다. 개인정보 보호, 스토리지 비용 및 운영 제약으로 인해 보존할 수 있는 범위가 제한될 수 있습니다. 하지만 개념적인 요점은 동일합니다. ML Observability에는 집계 수준 아래의 증거를 위한 공간이 있어야 합니다. 샘플 캡처가 부분적이라면 그 부분성이 숨겨지지 않고 명시되어야 합니다.

단위 세분화는 Observability를 단순한 평균 대시보드에서 모델 동작을 위한 조사 표면으로 바꿔줍니다. 사용자가 성과가 변했는지 여부뿐만 아니라 어디서 변했는지, 누구에게 변했는지, 어떤 구체적인 예시가 그 변화를 설명하는지 물을 수 있게 합니다.

이 계층이 누락되면 집계된 값은 기만적인 위안을 줄 수 있습니다. 팀은 평균 결과는 알지만 어떤 프롬프트가 심하게 실패했는지, 특정 슬라이스가 퇴행했는지, 실패가 소수의 하위 집합에 집중되었는지, 경고가 후반 배치에서만 나타났는지 알지 못할 수 있습니다. 많은 ML 문제들은 전체의 문제가 되기 전에 국소적으로 발생합니다. 단위 세분화는 이를 더 일찍 발견하고 나중에 더 잘 설명하도록 돕습니다.

예시: 샘플 수준의 증거

샘플 수준의 기록은 사용자가 전체 실행을 수동으로 검사하지 않고도 실패를 설명할 수 있을 만큼 충분한 디테일을 보존할 수 있습니다:

{
  "run_id": "run_2026_05_03_eval_014",
  "stage": "evaluate",
  "batch_id": "fold_03",
  "sample_id": "prompt_042",
  "slice": "refund_questions",
  "input_summary": "User asks whether a partially used annual plan can be refunded.",
  "retrieval": {
    "top_document_ids": ["doc_policy_general", "doc_pricing_faq"],
    "expected_document_id": "doc_refund_policy_2026"
  },
  "scores": {
    "relevance": 0.41,
    "faithfulness": 0.33
  },
  "failure_tags": ["missing_required_policy_context", "unsupported_claim"]
}

실행 수준에서 이 예시는 평균 충실도의 미세한 감소로만 나타날 수 있습니다. 하지만 샘플 수준에서는 그 이유가 구체적으로 드러납니다. 검색 단계에서 환불 정책 문서를 놓쳤고, 생성된 답변이 근거 없는 주장을 한 것입니다.

이러한 종류의 증거는 사용자가 국소적인 실패를 디버깅하고, 취약한 슬라이스를 식별하며, 회귀 테스트 세트를 구축하고, 프롬프트 클래스를 검사하며, 집계 메트릭이 심각한 운영 문제를 숨기고 있는지 여부를 결정하는 데 도움을 줍니다.

4. 아티팩트 증거 (Artifact Evidence)

ML 워크플로우는 결과를 이해하는 데 중심이 되는 영구적인 객체들을 생성합니다.

한 실행은 체크포인트, 모델 번들, 데이터셋 스냅샷, 피처 세트, 설정 스냅샷, 리포트 번들, 내보내기 패키지, 증거 번들 또는 디버그 아카이브를 생성할 수 있습니다. 이러한 객체들은 단순한 부수 효과가 아닙니다. 종종 나중에 검토, 비교, 프로모션, 배포, 보관 또는 감사 대상이 되는 핵심적인 요소들입니다.

이러한 이유로 Contexta는 아티팩트를 1급 Observability 증거로 취급합니다.

중요한 질문은 단순히 파일이 어디에 저장되었는가가 아닙니다. 무엇이 그것을 생성했는지, 그것이 무엇을 나타내는지, 어느 실행과 단계에 속하는지, 어떤 메트릭이나 리포트가 그것을 참조하는지, 그리고 다운스트림 결정의 일부가 되었는지 여부입니다.

모델의 체크포인트(Checkpoint)를 생각해 봅시다. 시스템이 파일 경로만 저장한다면 의미의 대부분은 외부 정보로 남게 됩니다. 누군가는 여전히 어떤 실행이 그것을 생성했는지, 어떤 설정이 그 형태를 잡았는지, 어떤 평가 리포트가 그것을 판단했는지, 나중에 프로모션되었는지 알아내야 합니다. 아티팩트가 증거 모델의 일부일 때 이러한 관계를 직접 보존할 수 있습니다.

데이터셋의 스냅샷(Snapshot)도 마찬가지입니다. 그 이면의 데이터를 알면 메트릭을 해석하기 더 쉽습니다. 두 평가 실행이 일치하지 않을 때, 데이터셋 스냅샷은 그 차이가 모델 변경, 데이터 변경, 설정 변경 중 무엇 때문인지 판단하는 데 도움을 줄 수 있습니다. 이러한 아티팩트 증거가 없다면, 팀은 기억이나 외부 스토리지 규칙에 의존하여 데이터 컨텍스트를 재구성해야 할 수도 있습니다.

리포트 번들(Report Bundle)도 아티팩트입니다. ML 결정은 종종 사람이 읽을 수 있는 형태로 검토되기 때문에 중요합니다. 리포트는 평가 결과를 요약하거나, 후보 실행을 비교하거나, 저하된 증거를 설명하거나, 배포 결정을 뒷받침할 수 있습니다. 표준 증거로부터 리포트를 생성할 수 있다면, Observability 모델은 단순히 데이터를 저장하는 것에 그치지 않고 설명을 지원하는 것입니다.

디버그 번들(Debug Bundle)과 증거 번들(Evidence Bundle)도 비슷한 역할을 합니다. 단일 메트릭이나 이벤트에는 깔끔하게 맞지 않지만 조사 중에 결정적일 수 있는 자료를 보존합니다. 예를 들어, 디버그 번들에는 샘플링된 실패 사례, 중간 출력, 설정 스냅샷, 진단 노트가 포함될 수 있습니다. 이러한 번들을 아티팩트로 취급하면 그것들을 분리된 파일로 남겨두지 않고 실행에 연결된 상태로 유지할 수 있습니다.

아티팩트 증거가 없으면 팀은 흔히 비공식적인 답변에 의존하게 됩니다. "체크포인트는 오브젝트 스토리지에 있을 거야", "리포트는 아마 그때쯤 생성되었을 거야", "모델 번들은 아마 그 특정 실행에서 나왔을 거야". 이러한 답변은 가벼운 협업에는 통할 수 있지만 비교, 감사, 복구, 배포 검토를 위한 기반으로는 취약합니다.

Contexta에서 아티팩트는 단순한 출력이 아닙니다. 실행의 의미를 기준 짓는 데 도움을 주는 영구적인 증거 객체입니다.

예시: 아티팩트 증거

아티팩트 매니페스트(manifest)는 생성된 파일을 그것을 만든 실행 및 단계에 연결할 수 있습니다 :

{
  "run_id": "run_2026_05_03_train_021",
  "artifacts": [
    {
      "artifact_id": "artifact_model_bundle_v17",
      "kind": "model_bundle",
      "produced_by_stage": "package",
      "path": "artifacts/model_bundle_v17.tar.gz",
      "sha256": "9b91c7e4...",
      "size_bytes": 184221903
    },
    {
      "artifact_id": "artifact_eval_report_v17",
      "kind": "report_bundle",
      "produced_by_stage": "evaluate",
      "path": "reports/evaluation_v17.md",
      "summarizes_run": "run_2026_05_03_eval_014"
    },
    {
      "artifact_id": "artifact_config_snapshot_v17",
      "kind": "config_snapshot",
      "produced_by_stage": "prepare",
      "path": "snapshots/config_v17.json"
    }
  ]
}

이 매니페스트는 독자가 아티팩트를 단순한 개별 파일이 아닌 증거 모델의 일부로 다룰 수 있게 해줍니다. 모델 번들은 패키징 단계에 연결될 수 있습니다. 리포트는 자신이 요약하는 평가 실행에 연결될 수 있습니다. 두 실행이 다른 결과를 낳을 때 설정 스냅샷을 검사할 수 있습니다.

실제로 이는 감사, 재현성, 배포 검토 및 복구를 지원합니다. 또한 ML 프로젝트에서 흔히 발생하는 실패 패턴, 즉 "중요한 파일이 어딘가에 있다는 것은 알지만, 어떤 실행이 그것을 생성했는지, 어떤 결정을 뒷받침했는지 확신하지 못하는 문제"를 예방하는 데 도움이 됩니다.

5. 재현성 컨텍스트 (Reproducibility Context)

결과를 생성한 조건이 알려져 있지 않다면 그 결과를 신뢰하기 어렵습니다.

ML 시스템에서 재현성 컨텍스트는 선택적인 메타데이터가 아닙니다. 그것은 설명의 일부입니다. 코드가 바뀌거나, 데이터가 바뀌거나, 설정이 바뀌거나, 패키지가 업그레이드되거나, 토크나이저가 다르게 동작하거나, CUDA 버전이 변경되거나, 환경 변수가 실행을 변경했기 때문에 두 실행이 달라질 수 있습니다. 이러한 조건들이 캡처되지 않으면 나중에 하는 비교는 추측에 불과하게 됩니다.

따라서 Contexta는 환경 및 설정 증거를 Observability의 일부로 취급합니다. 여기에는 Python 버전, 플랫폼, 패키지 버전, 관련 환경 변수, 설정 값 및 캡처 시간이 포함될 수 있습니다.

이러한 실질적 가치는 조사 과정에서 명확해집니다. 두 개의 평가 실행이 다른 결과를 냈다고 가정해 봅시다. 재현성 컨텍스트가 없다면 팀은 그 차이가 데이터, 모델 코드, 의존성 버전, 혹은 런타임 플랫폼의 변경에서 비롯된 것인지 토론하는 데 시간을 낭비할 수 있습니다. 환경 및 설정 증거가 실행에 첨부되어 있다면 그러한 가능성들을 훨씬 빨리 좁힐 수 있습니다.

워크플로우를 직접 실행하지 않은 사람이 결과를 신뢰해야 할 때도 재현성 컨텍스트가 중요합니다. 검토자는 환경이 안정적이었는지 알고 싶어 할 수 있습니다. 운영자는 배포되는 아티팩트가 예상된 조건 하에 생성되었는지 확인해야 할 수 있습니다. 미래의 엔지니어는 의존성이 변경된 후에 실행을 다시 생성해야 할 수도 있습니다. 환경 스냅샷이 완벽한 재현성을 보장하지는 않지만, 정직한 분석을 위한 출발점을 제공합니다.

ML에서는 사소한 환경 차이가 큰 해석상 결과를 초래할 수 있기 때문에 이 계층이 특히 중요합니다. 패키지 업그레이드가 전처리 과정을 변경할 수 있습니다. 토크나이저 리비전이 프롬프트 동작을 바꿀 수 있습니다. 하드웨어나 플랫폼의 차이가 성능이나 결정론에 영향을 미칠 수 있습니다. 설정 값이 평가를 조용히 변경할 수 있습니다. 이러한 조건들이 캡처되지 않으면 증거는 실제보다 더 안정적으로 보일 수 있습니다.

기존 서비스의 Observability는 종종 환경을 외부에서 관리되는 배포 메타데이터로 취급합니다. ML 워크플로우에서 환경은 곧 결과 자체가 갖는 과학적, 운영적 의미의 일부인 경우가 많습니다. 메트릭은 이를 생성한 조건이 알려져 있을 때 더 신뢰할 수 있습니다.

이 계층이 누락되면 실행 간의 차이를 설명하기가 더 어려워집니다. 팀은 출력이 다르다는 것은 알지만 그 원인이 코드, 데이터, 설정, 패키지 버전, 플랫폼 중 무엇인지 알지 못할 수 있습니다. 이러한 불확실성은 원래 캡처에 들었을 비용보다 훨씬 더 많은 시간을 소비하게 만들 수 있습니다.

예시: 재현성 컨텍스트 증거

실행은 레코드와 함께 환경 및 설정 컨텍스트를 캡처할 수 있습니다 :

{
  "run_id": "run_2026_05_03_eval_014",
  "environment": {
    "python": "3.11.8",
    "platform": "linux-x86_64",
    "cuda": "12.4",
    "packages": {
      "torch": "2.4.1",
      "transformers": "4.45.2",
      "tokenizers": "0.20.1"
    }
  },
  "configuration": {
    "retriever": "hybrid_bm25_dense",
    "top_k": 8,
    "reranker": "cross_encoder_v3",
    "temperature": 0.0,
    "evaluation_set": "support_eval_2026_04"
  },
  "captured_at": "2026-05-03T09:12:44Z"
}

이 증거는 실행이 완벽하게 재현될 수 있음을 보장하지는 않지만, 추후 조사를 더 정직하게 만듭니다. 다른 실행과 차이가 날 경우, 팀은 패키지 세트가 변경되었는지, 평가 세트가 변경되었는지, top_k가 변경되었는지, 또는 다른 리랭커가 사용되었는지 확인할 수 있습니다.

실질적인 용도는 분명합니다. 재현성 컨텍스트는 탐색 공간을 좁혀줍니다. 메트릭 차이의 모든 가능한 원인을 두고 토론하는 대신, 사용자는 캡처된 조건을 비교하고 그 차이가 데이터, 설정, 의존성, 플랫폼 또는 모델 동작에서 비롯되었을 가능성을 판단할 수 있습니다.

6. 관계 추적 (Relationship Tracing)

ML 시스템은 연결된 증거 네트워크를 생성합니다.

실행은 데이터셋을 소비합니다. 단계는 메트릭을 생성합니다. 아티팩트는 실행에서 나옵니다. 리포트는 평가를 요약합니다. 배포는 아티팩트를 프로모션합니다. 프로덕션 동작은 이전의 학습 및 평가 결정을 반영합니다. 그 결과로 생기는 구조는 단순한 타임라인이 아니라 하나의 그래프입니다.

이것이 Contexta가 관계 추적을 ML Observability의 핵심 계층으로 다루는 이유입니다.

리니지(Lineage)는 객체들이 어떻게 연결되어 있는지 설명합니다. 아티팩트가 어디서 왔는지, 어떤 실행이 모델 번들을 생성했는지, 리포트가 무엇을 요약하는지, 어떤 하위 객체가 특정 결과에 의존하는지, 배포의 상위에 무엇이 있는지와 같은 질문에 답합니다. ML에서는 워크플로우 전반에 걸쳐 출력이 변환되고, 패키징되고, 프로모션되고, 재사용되기 때문에 이러한 질문이 흔하게 발생합니다.

리니지는 무언가 잘못되었을 때만 유용한 것이 아닙니다. 일상적인 검토도 지원합니다. 두 후보 실행을 비교할 때 사용자는 이들이 동일한 데이터셋 스냅샷을 사용했는지, 이들의 리포트가 동등한 증거를 요약하는지, 아티팩트가 동일한 파이프라인 단계를 통해 생성되었는지, 하나의 후보가 저하된 입력을 상속받았는지 알고 싶어 할 수 있습니다. 이들은 모두 '관계'에 대한 질문입니다.

출처(Provenance)는 이러한 관계에 신뢰성 컨텍스트를 더합니다. 우리가 연결이 유효하다고 믿는 이유, 그 링크가 직접 캡처되었는지 나중에 추론되었는지, 연결 주장을 뒷받침하는 증거가 무엇인지, 어떤 조건에서 관계가 형성되었는지 묻습니다. 리니지가 사물들이 연결되어 있음을 알려준다면, 출처는 우리가 그 연결을 얼마나 확신할 수 있는지 설명하는 데 도움을 줍니다.

모든 관계가 동일한 증거적 강도를 가지는 것은 아니기 때문에 이 구분은 중요합니다. 어떤 링크는 실행 중에 명시적으로 캡처됩니다. 어떤 것은 가져오기 중에 재구성되거나, 파일 이름에서 추론되거나, 메타데이터에서 파생될 수 있습니다. 성숙한 Observability 시스템은 이러한 모든 관계를 똑같이 확실한 것으로 제시해서는 안 됩니다.

메트릭 대시보드는 모델 성능이 저하되었음을 보여줄 수 있습니다. 관계 추적은 어떤 업스트림 데이터셋, 실행, 아티팩트, 리포트 또는 배포가 관련되어 있는지 설명하는 데 도움을 줍니다. 이러한 링크가 없으면 시스템에 유용한 증거 조각이 많이 있어도 일관된 스토리로 구성되지 못할 수 있습니다.

관계 추적이 누락되면 팀은 파편만 갖고 있을 뿐 설명은 갖지 못하는 경우가 많습니다. 실행, 체크포인트, 리포트, 배포 기록은 있지만 한 요소가 다음 요소로 어떻게 이어지는지 보여주는 모델링된 경로는 부족할 수 있습니다. 이러한 간극은 감사, 인시던트 대응, 장기적인 유지보수 시에 큰 비용으로 작용합니다.

예시: 리니지 및 출처 증거

관계 증거는 배포된 모델이 업스트림 객체와 어떻게 연결되어 있는지 설명할 수 있습니다 :

{
  "relationships": [
    {
      "type": "produced",
      "from": "run_2026_05_03_train_021",
      "to": "artifact_model_bundle_v17",
      "captured_by": "package_stage",
      "confidence": "direct"
    },
    {
      "type": "summarized_by",
      "from": "run_2026_05_03_eval_014",
      "to": "artifact_eval_report_v17",
      "captured_by": "report_generator",
      "confidence": "direct"
    },
    {
      "type": "approved_for",
      "from": "artifact_eval_report_v17",
      "to": "deployment_2026_05_04_prod",
      "captured_by": "promotion_record",
      "confidence": "direct"
    },
    {
      "type": "derived_from",
      "from": "artifact_model_bundle_v17",
      "to": "deployment_2026_05_04_prod",
      "captured_by": "deployment_import",
      "confidence": "inferred"
    }
  ]
}

여기서 유용한 디테일은 객체들이 연결되어 있다는 사실만이 아닙니다. 이 레코드는 또한 각 연결이 어떻게 확립되었고 시스템이 그 관계를 얼마나 확신하는지 알려줍니다. 직접 캡처된 리포트 관계는 추론된 배포 가져오기 관계보다 더 강력합니다.

이를 통해 사용자는 프로덕션 문제를 배포에서 아티팩트, 리포트, 평가 실행, 학습 실행으로 역추적할 수 있습니다. 또한 검토자는 워크플로우 중에 캡처된 증거와 나중에 재구성된 증거를 구별할 수 있습니다.

7. 운영 결과 (Operational Outcome)

ML Observability는 실험에서 멈춰서는 안 됩니다.

한 실행이 아티팩트를 생성할 수 있습니다. 그 아티팩트는 검토될 수 있습니다. 리포트가 프로모션을 정당화할 수 있습니다. 배포를 통해 아티팩트가 프로덕션 환경으로 이동할 수 있습니다. 나중에 프로덕션 동작은 원래의 증거에 대해 새로운 질문을 제기할 수 있습니다. 이러한 단계들은 분리된 세계로 취급되어서는 안 됩니다.

Contexta의 관점에서 배포(Deployment)와 프로모션(Promotion)은 ML 작업의 출력물에 일어난 일을 설명하기 때문에 증거 스토리의 일부입니다.

배포는 단순한 릴리스 이벤트가 아닙니다. 이전의 실행, 아티팩트, 평가 및 결정이 관찰 가능한 결과로 이어진 것입니다. 유용한 시스템이라면 어떤 실행이 배포되었는지, 어떤 아티팩트가 프로모션되었는지, 어떤 증거가 그 결정을 뒷받침했는지, 배포가 성공했는지 실패했는지, 그리고 현재 활성화된 배포 결과가 무엇인지 답할 수 있어야 합니다.

오프라인 평가와 온라인 사용은 연결되어 있지만 동일하지는 않기 때문에 이 계층은 중요합니다. 입력 분포가 변하거나, 서빙 환경이 다르거나, 운영 컨텍스트가 새로운 제약을 도입하기 때문에, 평가를 통과한 모델이라도 프로덕션 환경에서는 실패할 수 있습니다. 반대로, 프로덕션 문제를 조사하기 위해 배포된 모델을 생성한 실행, 아티팩트, 리포트 및 환경으로 역추적해야 할 수도 있습니다.

운영 결과는 또한 실험과 결과(consequence) 사이의 루프를 닫는 데 도움을 줍니다. 많은 ML 시스템이 수많은 실험을 축적하지만, 실제로 다음 단계로 진행되는 아티팩트는 소수입니다. 어떤 결과가 단순한 탐색용이었고 어떤 결과가 프로덕션에 영향을 미쳤는지 아는 것은 해석에 필수적입니다. 배포된 아티팩트를 생성한 실행은 폐기된 실행과는 운영상 다른 의미를 갖습니다.

Observability 모델이 배포 전에서 멈춘다면, 실험과 실제 결과 사이의 다리는 약해집니다. 운영 결과를 포함하면 팀이 프로덕션 동작을 그로 이어진 증거의 관점에서 조사할 수 있습니다.

핵심은 학습이나 평가 중에 무엇이 일어났는가 하는 것뿐만이 아닙니다. 그 작업으로 인해 다음 단계로 '무엇이 이동했는가' 하는 점도 똑같이 중요합니다.

예시: 운영 결과 증거

배포 레코드는 운영 상태를 이를 정당화한 증거에 연결할 수 있습니다 :

{
  "deployment_id": "deployment_2026_05_04_prod",
  "environment": "production",
  "status": "succeeded",
  "started_at": "2026-05-04T08:30:00Z",
  "completed_at": "2026-05-04T08:37:12Z",
  "promoted_artifact": "artifact_model_bundle_v17",
  "source_run": "run_2026_05_03_train_021",
  "supporting_report": "artifact_eval_report_v17",
  "checks": {
    "schema_check": "passed",
    "smoke_test": "passed",
    "rollback_plan": "available"
  }
}

이 레코드는 배포를 분리된 릴리스 노트가 아니라 증거 수명 주기의 일부로 만듭니다. 프로덕션 문제는 프로모션된 아티팩트, 소스 실행, 뒷받침하는 리포트로 역추적할 수 있습니다. 리뷰를 통해 아티팩트가 이동하기 전에 예상된 검증 단계를 통과했는지 확인할 수 있습니다.

운영 결과 증거는 실험과 결과를 분리하기 때문에 유용합니다. 많은 실행이 아티팩트를 생성할 수 있지만, 일부 아티팩트만이 프로모션됩니다. 무엇이 진행되었는지 알면 팀은 실제로 사용자나 다운스트림 시스템에 영향을 미친 결과에 집중하여 조사할 수 있습니다.

8. 조사 및 해석 (Investigation and Interpretation)

이전 계층들은 어떤 증거가 존재하는지 설명합니다. 이 계층은 사용자가 그 증거로 무엇을 할 수 있는지 설명합니다.

Contexta는 데이터를 내보내고 저장하기만 한다면 Observability가 불완전하다는 입장을 취합니다. 증거는 읽을 수 있어야 합니다. 사용자는 쿼리하고, 비교하고, 진단하고, 트렌드를 파악하고, 이를 리포트로 변환할 수 있는 방법이 필요합니다.

쿼리(Query)는 기본적인 읽기 표면입니다. 사용자가 실행 목록을 조회하고, 실행 스냅샷을 검사하고, 연결된 아티팩트를 추적하고, 주제에 대한 증거를 수집할 수 있게 해줍니다. 데이터가 존재하지만 이해할 수 있는 하나의 실행 뷰로 조립될 수 없다면 조사 경험은 여전히 빈약할 수밖에 없습니다. 사용자는 단일 실행을 이해하기 위해 로그, 메트릭, 파일 경로, 환경 노트를 수동으로 이어 붙일 필요가 없어야 합니다.

비교(Comparison)는 ML 작업의 중심입니다. 팀은 하나의 실행이 다른 실행과 어떻게 다른지, 어떤 단계가 변경되었는지, 어떤 메트릭이 퇴행했는지, 어떤 아티팩트가 다른지, 어떤 후보를 선택해야 하는지 자주 파악해야 합니다. 이는 어쩌다 한 번 발생하는 디버깅 요구가 아닙니다. 정상적인 개발 및 검토 루프의 일부입니다. 유용한 Observability 시스템은 비교를 질문할 때마다 맞춤형 노트북을 다시 만드는 방식이 아니라 일급 활동으로 만들어야 합니다.

진단(Diagnostics)은 의심스럽거나, 불완전하거나, 저하된 상태를 찾는 데 도움을 줍니다. 불완전한 단계, 예상되는 종료 단계 누락, 메트릭 증거 없이 완료된 단계, 기능 저하 레코드, 실패한 배치 또는 실패한 배포 등을 표면화할 수 있습니다. 진단이 사람의 판단을 대체하지는 않지만, 사용자가 먼저 어디를 살펴봐야 할지 결정하는 데 도움을 줍니다.

트렌드(Trends)는 시간의 흐름이나 실행에 따른 변화를 보여줍니다. 메트릭이 이동하고 있는지, 단계 소요 시간이 길어지고 있는지, 아티팩트 크기가 변하고 있는지, 단계 수준의 동작이 불안정해지고 있는지 파악할 수 있도록 돕습니다. 많은 ML 문제들은 단일한 명백한 실패가 아니라 점진적으로 나타납니다. 트렌드 표면은 그러한 점진적 변화를 눈치채고 조사하기 쉽게 만들어 줍니다.

리포트(Reports)는 증거를 사람이 읽을 수 있는 설명으로 변환합니다. 검토, 공유, 아카이빙, 거버넌스 및 의사 결정을 지원합니다. 표준 증거에서 생성된 리포트는 단순한 프레젠테이션 계층 그 이상입니다. 증거 모델이 해석을 뒷받침할 수 있다는 증명입니다.

많은 ML 결정들이 자동화된 하나의 컴포넌트에 의해 실시간으로 내려지는 것이 아니기 때문에 이러한 리포트 지향적 관점은 중요합니다. 의사 결정은 검토를 통해 이루어집니다. 사람들은 후보 실행을 비교하고, 증거가 충분한지 결정하고, 성능 저하가 허용 가능한지 판단하고, 발견한 내용을 협업자에게 전달합니다. Observability는 기계적인 수집뿐만 아니라 이러한 인간의 프로세스도 지원해야 합니다.

이러한 조사 표면이 없으면 팀은 질문이 생길 때마다 미가공 데이터를 노트북, 스크립트 또는 일회용 대시보드로 내보내곤 합니다. 이는 임시방편은 될 수 있지만 재구성의 부담을 사용자에게 남깁니다. 성숙한 Observability 시스템이라면 조사를 일급 워크플로우로 만들어야 합니다.

예시: 조사 출력

조사 표면은 레코드, 아티팩트, 진단을 실행 비교 결과로 조립할 수 있습니다 :

{
  "comparison": {
    "baseline_run": "run_2026_04_27_eval_009",
    "candidate_run": "run_2026_05_03_eval_014",
    "summary": {
      "accuracy_delta": 0.018,
      "faithfulness_delta": -0.042,
      "latency_p95_delta_ms": 231
    },
    "notable_findings": [
      {
        "type": "slice_regression",
        "slice": "refund_questions",
        "metric": "faithfulness",
        "delta": -0.11
      },
      {
        "type": "artifact_growth",
        "artifact": "artifact_model_bundle_v17",
        "size_delta_percent": 18.4
      },
      {
        "type": "degraded_evidence",
        "stage": "evaluate",
        "reason": "sample_outputs_partially_redacted"
      }
    ],
    "recommended_next_steps": [
      "Inspect failed refund_questions samples.",
      "Compare retrieval outputs for prompts with faithfulness regression.",
      "Review whether partial redaction limits promotion confidence."
    ]
  }
}

이것은 새로운 형태의 미가공 증거가 아닙니다. 증거로부터 구축된 '해석'입니다. 이 출력의 가치는 메트릭, 슬라이스, 아티팩트, 기능 저하 마커를 사람이 조치를 취할 수 있는 형태로 연결하는 데서 옵니다.

사용자는 이 출력을 활용하여 어디를 먼저 조사할지, 후보 실행을 여전히 프로모션할 가치가 있는지, 어떤 샘플을 회귀 테스트로 삼아야 할지, 누락된 증거가 결정의 신뢰성을 떨어뜨리는지 여부를 판단할 수 있습니다. 이것이 해석이 Observability 스토리의 외곽이 아닌 내부에 속해야 하는 이유입니다.

프로덕션 모니터링의 위치

이 문서는 구조화된 증거를 강조하지만, 프로덕션 모니터링은 여전히 ML Observability의 중요한 일부입니다.

모델이나 ML 워크플로우가 배포되고 나면 새로운 질문들이 등장합니다. 입력 데이터가 드리프트 될 수 있습니다. feature의 분포가 변할 수 있습니다. 예측 분포가 달라질 수 있습니다. 온라인 결과가 오프라인 평가와 어긋날 수 있습니다. 특정 슬라이스의 사용자나 예시에서 성능이 저하될 수 있습니다. 피드백 데이터가 불완전하거나 지연되거나 편향될 수 있습니다.

Contexta 모델에서 이러한 프로덕션 시그널들은 증거와 분리되어 있지 않습니다. 이들은 증거 그래프를 앞쪽으로 확장합니다. 프로덕션 메트릭과 드리프트 지표는 활성화된 동작을 생성한 실행, 아티팩트, 설정, 평가 리포트 및 배포 기록에 연결되는 추가적인 레코드가 됩니다.

이러한 연결이 중요한 이유는, 리니지가 없는 프로덕션 모니터링은 근본 원인을 설명하지 못한 채 증상만을 식별하기 때문입니다. 드리프트 경고가 입력 분포의 변화를 알려줄 수는 있지만, 팀은 여전히 어떤 모델이 활성화되어 있는지, 어떤 데이터셋에 대해 평가되었는지, 프로모션 시점에 어떤 가정들이 있었는지, 배포를 뒷받침한 증거가 무엇인지 알아야 합니다. 반대로, 프로덕션과 연결되지 않은 오프라인 증거는 모델이 어떻게 구축되었는지는 설명할 수 있지만, 정작 중요한 시점인 프로덕션에서 어떻게 동작했는지는 설명하지 못합니다.

또한 프로덕션 모니터링은 이전 증거의 의미를 변화시킵니다. 평가 리포트 작성 당시에는 결과가 강력해 보였을지라도, 나중에 프로덕션 데이터를 통해 평가 세트가 중요한 슬라이스를 놓쳤음이 드러날 수 있습니다. 초기 배포는 성공적이었으나, 피드백 품질이 예상보다 낮게 판명될 수도 있습니다. 프로덕션 결과를 오프라인 증거로 다시 연결함으로써, 시스템은 배포를 스토리의 끝으로 취급하는 대신 학습의 전체 수명 주기를 지원할 수 있습니다.

더 강력한 ML Observability 모델은 이 양방향을 모두 연결합니다. 팀이 프로덕션 증상에서 시작하여 배포된 동작을 생성한 증거로 거슬러 올라가고, 오프라인 증거에서 시작하여 실제 세계의 결과로 나아갈 수 있게 합니다.

불완전성의 명시가 중요한 이유

8가지 계층 전체를 관통하는 하나의 테마가 있습니다. 바로 시스템이 증거 품질에 대해 정직해야 한다는 것입니다.

일반적인 엔지니어링 시스템에서 Observability 데이터의 누락은 불편함 정도일 수 있습니다. 하지만 ML 시스템에서는 오해를 불러일으킬 수 있습니다. 모델을 프로모션할지, 퇴행이 진짜인지, 비교가 공정한지, 리포트가 리뷰를 뒷받침하는지, 혹은 배포된 아티팩트가 평가된 것과 일치하는지 등의 결정이 종종 증거를 바탕으로 이루어집니다.

누락된 증거가 표시되지 않으면, 사용자는 데이터의 부재를 정상 상태로 취급할 수 있습니다. 경고가 없는 리포트는 비록 샘플 캡처가 불완전했더라도 신뢰할 만한 것으로 보일 수 있습니다. 한쪽 실행에 환경 증거가 없더라도 비교가 공정해 보일 수 있습니다. 아티팩트 리니지가 부분적으로만 추론되었더라도 배포가 잘 뒷받침된 것처럼 보일 수 있습니다.

따라서 Contexta는 저하되고(degraded) 부분적인(partial) 상태를 데이터로 취급합니다. 캡처 누락, 입력 누락, 재생 한계, 가져오기 손실, 검증 경고 및 추론된 관계는 미래의 독자에게 가시적이어야 합니다. 부분적인 답변은 묵묵히 완전한 레코드인 양 포장되는 대신, 명확하게 부분적인 것으로 남아 있어야 합니다.

이 원칙은 모델 전체에 적용됩니다. 단계 자체는 완료되었더라도 샘플 증거는 부분적일 수 있습니다. 아티팩트가 존재하더라도 그 리니지는 추론된 것일 수 있습니다. 증거가 불완전하다는 진단 경고가 있으면서도 리포트는 생성될 수 있습니다. 뒷받침하는 리포트와의 연결 고리가 누락되었더라도 배포는 성공할 수 있습니다. 이러한 구분이 중요한 이유는, 독자가 자신이 보는 것에 얼마나 확신을 가져야 할지 결정하는 데 도움을 주기 때문입니다.

명시적인 불완전성은 복구에도 유용합니다. 시스템이 무엇이 누락되었는지 안다면 사용자에게 복구, 재가져오기, 재실행, 또는 주의 깊은 해석을 유도할 수 있습니다. 누락이 눈에 보이지 않는다면 시스템은 거짓된 완전성의 착각만을 줄 뿐입니다.

이것은 비관주의가 아닙니다. 신뢰를 위한 조건입니다. 시스템이 완전한 증거와 부분적인 증거, 직접 캡처와 추론된 캡처, 정상 상태와 저하된 상태, 강한 확신과 약한 확신을 구분할 때 사용자는 더 나은 결정을 내릴 수 있습니다.

모델의 실제 적용

이 8가지 계층은 구체적인 워크플로우를 통해 가장 쉽게 이해할 수 있습니다.

학습 워크플로우(training workflow)에서, 실행 컨텍스트는 프로젝트, 실행, 그리고 prepare, train, evaluate와 같은 단계를 정의합니다. 레코드 패밀리는 손실, 정확도, 경고, 기능 저하 마커, 스팬 소요 시간을 캡처합니다. 세분화 단위는 에포크, 배치 또는 샘플 수준의 변동을 보존합니다. 아티팩트는 체크포인트, 모델 번들, 설정 스냅샷의 기준이 됩니다. 재현성 컨텍스트는 환경을 기록합니다. 관계 추적은 출력물을 실행과 다시 연결합니다. 운영 결과는 나중에 선택된 아티팩트를 배포와 연결할 수 있습니다. 조사 표면을 통해 실행을 비교, 진단, 트렌드 분석 및 리포팅할 수 있습니다.

텔레메트리 전용 관점은 단지 학습이 실행되었다는 사실만 보여줄 수 있습니다. 반면 구조화된 증거 관점은 학습이 어떻게 실행되었는지, 무엇을 생성했는지, 왜 그 결과가 다른 실행과 다른지, 증거가 프로모션을 뒷받침할 만큼 강력한지 설명할 수 있습니다.

예를 들어, 새로운 학습 실행이 검증 정확도를 향상시켰지만 아티팩트 크기가 더 커지고 내보내기 시간이 길어졌다고 가정해 보겠습니다. 기본적인 메트릭 대시보드는 정확도와 시간 변화만 보여줄 수 있습니다. 더 강력한 증거 모델은 그 향상이 특정 평가 슬라이스에서 비롯되었고, 내보내기 단계에서 더 큰 번들을 생성했으며, 패키지 세트가 변경되었고, 불완전한 샘플 캡처로 인해 리포트에 기능 저하 마커가 포함되어 있음을 보여줄 수 있습니다. 이처럼 더 풍부한 뷰는 집계된 점수 하나만 볼 때보다 더 나은 의사 결정을 지원합니다.

평가 워크플로우(evaluation workflow)에서 구조화된 증거의 필요성은 훨씬 더 분명해집니다. 실행에는 로딩, 채점(scoring), 집계, 리포팅이 포함될 수 있습니다. 집계 메트릭은 전반적인 품질을 설명할 수 있지만, 샘플 수준의 증거는 어떤 케이스가 실패했는지 드러냅니다. 아티팩트는 생성된 리포트나 내보내기 결과를 보존합니다. 출처는 결론이 어떻게 형성되었는지 설명합니다. 모델 품질은 평균 동작뿐만 아니라 소수의 심각한 실패에 좌우되는 경우가 많기 때문에 이는 매우 중요합니다.

평가는 또한 리포트가 왜 중요한지 보여줍니다. 리뷰어는 보통 미가공 레코드를 일일이 검사하고 싶어 하지 않습니다. 그들은 설명을 원합니다. 무엇이, 어떤 조건에서 평가되었는지, 어떤 메트릭이 변했는지, 어떤 예시가 실패했는지, 어떤 아티팩트가 생성되었는지, 불완전한 증거는 없는지 알고 싶어 합니다. 리포트가 표준 증거에서 생성된다면 미가공 캡처 데이터와 인간의 리뷰 사이의 신뢰할 수 있는 다리 역할을 할 수 있습니다.

LLM 또는 RAG 워크플로우에서는 증거 모델이 한층 더 넓어집니다. 유용한 증거에는 프롬프트 수준의 샘플, 검색 단계 메트릭, 생성 단계 메트릭, 충실도 및 관련성 점수, 폴백 마커, 검색된 컨텍스트, 그리고 프롬프트, 검색된 증거, 생성된 출력, 리포트를 연결하는 리니지가 포함될 수 있습니다. 여기서 가장 흥미로운 질문은 종종 단순한 지연 시간이나 오류 횟수가 아니라 '프롬프트별 동작'과 '증거 경로'에 관한 것입니다.

예를 들어, RAG의 실패는 하나의 메트릭으로 설명되지 않을 수 있습니다. 검색이 관련 문서를 놓쳤거나, 리랭킹이 잘못된 단락을 선택했거나, 생성기가 검색된 증거를 무시했거나, 평가자가 출력을 일관성 없게 채점했기 때문에 답변이 틀렸을 수 있습니다. 이러한 체인을 조사하려면 Observability 모델에 단계 구조, 샘플 수준 레코드, 증거 번들이 포함된 아티팩트, 그리고 프롬프트, 검색 결과, 생성된 답변, 평가 결과를 연결하는 리니지가 필요합니다.

배포 워크플로우(deployment workflow)에서 초점은 실행이 무엇을 했는가에서, 그 실행으로 인해 무엇이 진행되었는가로 옮겨갑니다. 시스템은 아티팩트, 리포트, 환경, 출처, 프로모션, 배포 상태를 연결해야 합니다. Observability는 단순한 실행의 기록이 아니라 '결과(consequence)의 스토리'가 됩니다.

실패한 배포는 배포된 아티팩트, 그것을 생성한 실행, 그것을 뒷받침한 리포트, 그것이 생성된 환경으로 역추적할 수 있어야 합니다. 성공한 배포라 하더라도 이후의 프로덕션 모니터링과 연결된 상태로 유지되어야 실제 동작을 원래의 증거에 비추어 해석할 수 있습니다.

함의: AI 에이전트를 위한 Observability

구조화된 증거는 사람에게도 유용하지만, AI 에이전트에게도 유용합니다.

AI 코딩 에이전트가 점점 더 소프트웨어를 생성하고 평가하고 디버깅하고 유지보수함에 따라, 이들에게는 이전 작업에 대한 기계 판독 가능한 컨텍스트가 필요해집니다. 이들은 사람의 비공식적인 기억이나 파편화된 대시보드에 의존할 수 없습니다. 프로그램적으로 검사할 수 있는 레코드, 메트릭, 아티팩트, 리니지 경로, 진단 및 리포트가 필요합니다.

이것은 ML Observability와 에이전트 지향 워크플로우 사이에 자연스러운 연결 고리를 만듭니다. 생성 에이전트는 변경 사항을 만들 수 있습니다. 평가 에이전트는 테스트를 실행하고, 증거를 검사하고, 결과를 비교하고, 구체적인 피드백을 반환할 수 있습니다. 이후의 세션은 취약한 채팅 기록이 아니라 아티팩트와 구조화된 컨텍스트에서 다시 시작할 수 있습니다.

이는 장기적으로 실행되거나 여러 단계로 이루어진 작업에서 특히 중요합니다. 인간 팀은 이전 상황을 이해하기 위해 종종 공유된 기억, 논의 또는 대시보드에 의존합니다. 에이전트는 더 명시적인 인수인계가 필요합니다. 그들은 전체 대화 기록에 접근하지 않고도 작업 상태를 설명하는 구조화된 실행 기록, 결정론적 메트릭, 증거 번들 및 진단의 이점을 누릴 수 있습니다.

이것이 ML Observability의 핵심 정의를 바꾸지는 않습니다. 오히려 그것을 강화합니다. 인간의 리뷰에 충분할 만큼 구조화된 증거는, 여러 실행에 걸쳐 추론하고 결과를 비교하며 시간이 지남에 따라 품질을 강화해야 하는 에이전트에게도 더 유용합니다.

취약한 ML Observability 스토리는 어떤 모습인가

취약한 ML Observability 스토리는 데이터가 완전히 없는 상태를 의미하는 것이 아닙니다. 대부분의 팀은 약간의 메트릭, 로그, 아티팩트, 대시보드, 스크립트 또는 리포트를 가지고 있습니다. 취약함은 이러한 조각들이 서로 연결되지 않을 때 나타납니다.

메트릭은 존재하지만 그 범위나 단계가 모호할 수 있습니다. 로그에 중요한 수명 주기 이벤트가 포함되어 있지만 단계 간의 경계가 암시적일 수 있습니다. 스토리지에 아티팩트가 존재하지만 그 출처는 관례나 사람의 기억으로 추적될 수 있습니다. 환경의 차이는 사후에 재구성되어야 할 수 있습니다. 샘플 수준의 실패는 평균치 뒤에 숨겨질 수 있습니다. 비교를 할 때마다 사용자 정의 스크립트가 필요할 수 있습니다. 누락된 증거가 표시되지 않아 침묵이 마치 완전함인 것처럼 보일 수 있습니다. 배포 기록이 그 배포를 정당화한 증거와 분리되어 있을 수 있습니다.

이러한 종류의 파편화는 흔합니다. 이는 팀에 Observability가 없다는 뜻이 아닙니다. 일관된 ML 증거 모델 없이 Observability 시그널만 가지고 있다는 뜻입니다.

이러한 파편화의 비용은 종종 나중에 청구됩니다. 관련된 사람들이 컨텍스트를 기억하고 있는 직후라면 팀은 실행을 즉시 디버깅할 수 있을 것입니다. 하지만 몇 주 뒤 누군가가 왜 모델이 프로모션되었는지, 혹은 프로덕션 동작이 왜 변했는지 물을 때, 누락된 연결 고리들은 고통으로 다가옵니다. 데이터는 존재하지만 설명은 새로 재구성해야 합니다.

따라서 취약한 스토리는 보통 실행 중에는 적절해 보이지만 리뷰 시점에는 부적절하게 느껴집니다. Contexta는 기억이 희미해진 후에도 증거를 계속 해석할 수 있어야 하는 그 이후의 시점을 염두에 두고 설계되었습니다.

강력한 ML Observability 스토리는 어떤 모습인가

강력한 ML Observability 스토리는 그 조각들을 하나로 연결합니다.

실행 구조가 명시적입니다. 레코드는 의미 있는 범위에 연결됩니다. 샘플 및 배치 수준의 변동을 검사할 수 있습니다. 아티팩트는 증거 객체로 보존됩니다. 환경 및 설정 컨텍스트가 결과와 함께 캡처됩니다. 리니지와 출처가 객체 간의 관계를 설명합니다. 저하되거나 부분적인 상태가 눈에 보입니다. 프로덕션 결과를 오프라인 증거로 다시 연결할 수 있습니다. 쿼리, 비교, 진단, 트렌드, 리포팅은 긴급 상황의 재구성 도구가 아니라 일상적인 워크플로우가 됩니다.

이것이 완벽한 캡처를 요구하는 것은 아닙니다. 완벽한 증거는 현실적으로 거의 불가능합니다. 중요한 것은 의미 모델을 바닥부터 다시 구축하지 않고도 나중에 묻게 될 질문에 답할 수 있을 만큼 시스템이 충분한 구조를 보존한다는 점입니다.

또한 강력한 스토리는 모든 사용자가 항상 모든 계층을 검사해야 함을 의미하지도 않습니다. 많은 사용자가 리포트, 비교, 또는 진단 요약에서 시작할 것입니다. 이 모델의 가치는 그러한 표면들이 구조화된 증거에 의해 뒷받침될 수 있다는 점에 있습니다. 질문이 더 깊어질 때 시스템은 독자가 요약에서 레코드로, 레코드에서 아티팩트로, 아티팩트에서 리니지로, 리니지에서 운영 결과로 원활하게 이동할 수 있도록 해줍니다.

그런 의미에서 강력한 ML Observability 스토리는 단지 완전성에 관한 것만이 아닙니다. 그것은 탐색 가능성(Navigability)에 관한 것입니다. 증거는 사용자가 그 의미를 잃지 않고 데이터를 자유롭게 넘나들 수 있을 만큼 충분히 구조화되어야 합니다.

Contexta 이면의 핵심 설계 직관

Contexta 이면의 핵심 설계 직관은 다음과 같이 요약할 수 있습니다.

텔레메트리는 무엇인가 일어났음을 알려줍니다. 구조는 그것이 어디서 일어났는지 알려줍니다. 단위 세분화는 어떤 단위가 영향을 받았는지 알려줍니다. 아티팩트는 무엇이 생성되었는지 알려줍니다. 환경은 어떤 조건에서 그것이 일어났는지 알려줍니다. 리니지는 그것이 어떻게 연결되는지 알려줍니다. 저하 정도는 그 기록을 얼마나 신뢰해야 할지 알려줍니다. 리포트와 진단은 그것을 어떻게 해석해야 할지 알려줍니다.

이러한 직관은 프로젝트 내의 퍼블릭 개념들을 하나로 연결합니다. 구현 표면이 진화하더라도 기저에 깔린 관점은 일관되게 유지됩니다. 'ML Observability는 시간이 지나도 ML 작업을 이해하는 데 필요한 증거를 보존해야 한다'는 것입니다.

이것은 또한 왜 Contexta가 ML Observability를 '몇 개의 ML 전용 태그가 추가된 애플리케이션 Observability'로 정의하지 않는지 설명해 줍니다. 태그는 컨텍스트를 추가할 수 있지만, 그것만으로는 일관된 증거 모델이 만들어지지 않습니다. 대신 이 프로젝트는 ML 팀이 추론할 때 필요로 하는 핵심 객체들, 즉 실행, 단계, 레코드, 샘플, 아티팩트, 환경, 관계, 운영 결과 및 리포트에서 출발합니다.

이것이 Contexta에 의미하는 바

이 문서는 Contexta에 인코딩된 방향성을 설명합니다. 가능한 모든 ML Observability 워크플로우가 완성되었다거나 프로젝트의 모든 표면이 똑같이 성숙하다고 주장하는 것은 아닙니다.

방향성은 명확합니다. 로컬 우선의 표준 증거 저장, 구조화된 실행 중심 조사, 레코드 및 아티팩트의 명시적 모델링, 1급 컨텍스트로서의 환경 및 리니지, 비교 및 리포팅 지원, 불완전하거나 저하된 상태의 정직한 처리가 그것입니다. 또한, 실험과 배포를 별개의 역사로 취급하는 대신 오프라인 증거를 운영 결과와 연결하는 것을 의미합니다.

로컬 우선 저장이 중요한 이유는 증거를 원격 백엔드 뒤에 숨겨둘 뿐만 아니라 사용자가 직접 검사하고 소유할 수 있어야 하기 때문입니다. 표준 증거가 중요한 이유는 리포트, 내보내기 결과, 진단 및 비교가 각기 다르게 임시로 재구성되는 대신 동일한 기본 레코드에서 파생되어야 하기 때문입니다. 실행 중심 조사가 중요한 이유는 대부분의 ML 관련 질문들이 결국 특정 실행이 무엇을 했고, 무엇을 생성했으며, 무엇을 정당화했는가로 돌아가기 때문입니다.

더 넓은 관점에서 볼 때, Contexta는 ML Observability를 단순히 'ML에 적용된 로그, 메트릭, 트레이스'로 보지 않습니다. 오히려 시간이 지나도 이해할 수 있고, 검토할 수 있으며, 재현할 수 있고, 신뢰할 수 있도록 ML 실행과 결과에 대한 구조화된 증거를 보존하는 하나의 원칙으로 봅니다.

요약

Contexta의 관점에서 ML Observability는 ML 실행이 일어난 후에도 그 의미를 명확히 읽을 수 있게(legible) 만드는 프랙티스입니다.

여기에는 텔레메트리가 포함되지만, 의미론적 실행 구조, 의미 있는 범위에 연결된 레코드, 샘플 및 배치 수준의 세분화, 아티팩트 증거, 재현성 컨텍스트, 리니지와 출처, 운영 결과, 명시적인 저하 상태 모델링, 그리고 쿼리, 비교, 진단, 트렌드, 리포팅을 위한 해석 표면도 포함됩니다.

그렇기 때문에 Contexta는 텔레메트리 하나만을 중심으로 퍼블릭 개념을 조직하는 대신 실행, 단계, 레코드, 아티팩트, 리니지 및 리포트를 중심으로 구성됩니다.

이를 실무적으로 정의하자면 다음과 같습니다:

ML Observability는 미래의 조사, 비교, 재현성, 검토 및 운영상의 의사 결정을 지원하기 위해 실행, 단계, 레코드, 샘플, 아티팩트, 환경, 관계 및 증거 품질에 대한 충분히 구조화된 증거를 보존하는 원칙이다.