데이터 장애를 위한 인용: EvidenceCapsule 소개

AI 에이전트가 "오늘 아침 왜 orders 데이터가 최신 상태가 아니죠?"라고 답변할 때, 여러분은 두 가지 상황 중 하나를 마주하게 됩니다. 에이전트가 접촉한 모든 행(row)을 응답에 쏟아붓거나(토큰 낭비, 가독성 저하, 감사 추적 불가), 어떤 테이블의 어떤 행에서 가져온 정보인지 알려주지 않은 채 이벤트 이름만 언급하며 자신감 있게 산문 형태로 답변하는 것입니다. 두 번째 방식은 읽기는 빠르지만 구조적으로 신뢰할 수 없습니다. 단 하나의 주장이라도 검증하기 위해 클릭하여 확인할 수 없기 때문입니다.

EvidenceCapsule은 이 문제를 해결하기 위해 우리가 출시한 타입 지정된(typed) 조사 출력물입니다. 에이전트가 조사 과정에서 제시하는 모든 증거는 인용(citation)입니다. 즉, AnomalyArmor 인스턴스 내의 실제 레코드(알림(alert), 스키마 변경(schema change), 메트릭(metric), 리니지 엣지(lineage edge), 인텔리전스 노트(intelligence note))를 가리키는 타입 지정된 행이며, UI에는 클릭 가능한 딥 링크(deep link)가 제공되고 SDK 및 Claude Code 스킬을 위한 안정적인 JSON 형태를 갖추고 있습니다.

이 기능이 해결하는 문제

데이터 웨어하우스(data warehouse)에서의 조사는 한 번에 6개 정도의 소스에서 데이터를 가져옵니다. 진정한 "왜 데이터가 최신 상태가 아닌가"에 대한 답변은 다음 사항들을 고려해야 합니다:

발생한 신선도 체크(freshness check)와 그 시점
지난 며칠 동안 상위 테이블(upstream table) 또는 그 종속성에서 발생한 스키마 변경(schema change)
실제 근본 원인일 수 있는 관련 자산에 대한 알림(alerts)
동일한 시간대를 가리키는 최근의 메트릭 이상 징후(metric anomalies)
어떤 하위 소비자(downstream consumers)가 이 자산에 의존하는지 보여주는 리니지 엣지(lineage edges)

이 작업을 잘 수행하는 에이전트는 이 모든 행을 컨텍스트(context) 내에 유지해야 합니다. 이 작업을 신뢰할 수 있게 수행하는 에이전트는 어떤 행이 어떤 결론을 뒷받침했는지 주장 하나하나마다 사용자에게 알려주어야 합니다. 이것이 없다면, 응답이 기술적으로는 정확할지라도 구조적으로는 환각(hallucination)과 구별할 수 없게 됩니다.

이는 인용이 없는 연구 논문과 같은 문제입니다. 논거는 맞을지 모르지만, 근거가 되는 소스를 찾을 수 없기 때문에 그 논거를 확인할 수 없습니다.

EvidenceCapsule의 모습

모든 조사는 질문된 내용과 함께 5개의 필드를 가진 캡슐(capsule)을 반환합니다:

필드 (Field)	포함 내용	예시
`question`	조사를 트리거한 자연어 질문	"Why is the orders table 14 hours stale?"
...

triggers와 consequences의 각 증거(evidence) 행은 요약(summary), 소스(source; 알람(alert), 스키마 변경(schema change), 메트릭(metric), 리니지 엣지(lineage edge), 인텔리전스 노트(intelligence note)), 실제 레코드를 가리키는 UUID, 관찰된 시간, 그리고 상관분석기(correlator)가 추출한 구조화된 필드(structured fields)를 포함하는 타입화된 객체(typed object)입니다. UI에서는 요약이 클릭 가능한 링크로 변환되어 알람 상세 페이지, 스키마 차이(schema diff), 메트릭 차트 또는 자산(asset) 페이지로 직접 연결됩니다.

SDK에 의해 반환되거나 에이전트 UI에 렌더링되는 실제 캡슐(capsule)은 다음과 같습니다:

question: "Why is the orders table 14 hours stale?"
root_cause: >
  Upstream Fivetran sync for raw.orders failed at 19:04 yesterday
...

모든 source_id는 AnomalyArmor 인스턴스의 실제 레코드로 해석됩니다. UI는 각 증거 행을 해당 상세 페이지로 연결되는 인용 칩(citation chip)으로 렌더링합니다. SDK는 직접 반복(iterate)할 수 있는 타입화된 Pydantic 모델 형태로 동일한 구조를 제공합니다.

사용자는 서술형 답변을 읽습니다. 만약 어떤 주장이 의심스러워 보인다면, 그 옆의 링크를 클릭합니다. 해당 레코드가 주장을 뒷받침하거나, 그렇지 않거나 둘 중 하나입니다. 제3의 선택지는 없으며, 이것이 바로 핵심입니다.

이것이 AI 조사에서의 신뢰 작동 방식을 바꾸는 이유

운영 데이터 시스템(production data systems)에서 LLM 기반 분석에 대해 제기되는 표준적인 반론은 "언제 틀렸는지 알 수 없다"는 것입니다. 그 반론은 일반적인 관점에서 옳으며, 통상적인 대응(더 나은 프롬프트, 더 많은 가드레일(guardrails), 신중한 평가(evals))은 실제적인 해결책이긴 하지만 불완전합니다. 구조적인 해결책은 모델이 환각(hallucination)을 일으키지 않도록 더 잘 만드는 것이 아니라, 환각이 숨을 수 있는 경로 자체를 제거하는 것입니다.

인용(citations)이 포함된 캡슐은 환각된 주장(hallucinated claim)을 숨길 수 없습니다. 왜냐하면 해당 주장은 실제로 존재하는 행(row)에 의해 뒷받침되거나, 그렇지 않거나 둘 중 하나이기 때문입니다. 링크는 실제 레코드로 연결되거나, 아니면 404 오류를 발생시킵니다. 검토자(데이터 엔지니어, 온콜(on-call) 담당자, 사후 분석(postmortem) 보고서를 읽는 매니저 등)는 30초 안에 세 개의 인용을 점검하여 전체 캡슐이 신뢰할 수 있는지에 대해 조정된 신뢰(calibrated trust)를 형성할 수 있습니다.

이는 "답변을 읽어보니 맞는 것 같다"라는 식의 신뢰와는 다른 형태의 신뢰입니다. 이는 엔지니어들이 이미 SQL을 신뢰하는 방식에 더 가깝습니다. 데이터베이스가 항상 정답을 반환하기 때문이 아니라, 쿼리와 테이블을 읽고 검증할 수 있기 때문입니다.

실제 사용하는 인터페이스 전반에서 작동하는 방식

EvidenceCapsule은 웹 UI를 사용하든, 노트북에서 SDK를 호출하든, 터미널에서 Claude Code 스킬을 실행하든 동일한 형태를 유지합니다. 컨텍스트(context)가 바뀌어도 멘탈 모델(mental model)은 변하지 않습니다.

웹 에이전트(web agent)에서. 채팅창에 "왜 주문 데이터가 최신 상태가 아닌가요(why is orders stale)"라고 물어보세요. 응답은 에이전트의 서술형 답변과 그 아래에 렌더링된 캡슐로 구성됩니다. 각 증거 행(evidence row)은 인용 칩(citation chip)으로 표시됩니다: 스키마 변경 아이콘, "raw.orders의 customer_id 컬럼 타입이 변경됨 (2026-05-23 14:31)", 클릭 가능. 에이전트의 서술은 사례를 설명하고, 캡슐은 증거(receipts)를 제공합니다.

SDK에서. 새로운 client.investigations 리소스에는 두 가지 메서드가 있습니다. get(id)는 기존 조사(investigation)에 대한 캡슐을 반환합니다. explain(asset_id, question)은 단일 자산(asset)에 대해 즉석 조사(ad-hoc investigation)를 실행하고 캡슐을 직접 반환합니다. 두 메서드 모두 반복(iterate), 로깅, 또는 자체적인 다운스트림 프로세싱(downstream processing)에 입력할 수 있는 타입화된 EvidenceCapsule 및 Evidence 모델을 반환합니다.

from anomalyarmor import AnomalyArmor

client = AnomalyArmor(api_key=...)
...

Claude Code 스킬 내에서. 기존의 armor-investigate 스킬은 5단계의 레시피로 구성되어 있었습니다: 조사 목록 나열, 하나 선택, 경고(alerts) 가져오기, 스키마 변경 사항 가져오기, 그리고 산문 형태의 답변을 엮어내는 과정이었습니다. 각 단계는 모델이 올바른 순서로 호출해야 하는 SDK 호출이었습니다. EvidenceCapsule을 사용하면 이 스킬은 단 한 번의 타입 지정된 호출(typed call)로 변합니다. 모델이 SDK에 설명을 요청하면, SDK는 캡슐(capsule)을 반환하고, 모델은 이를 렌더링합니다. 5개의 연결된 호출이 하나로 압축된 것은 이 전체 기능에서 가장 레버리지가 높은(highest-leverage) 변화입니다.

왜 LLM에 더 많은 컨텍스트를 제공하고 결과가 좋아지길 기대하지 않는가?

"프롬프트에 더 많은 행(rows)을 밀어 넣는 것"이 기본 반사 작용이기 때문에 합리적인 질문입니다. 여기에는 세 가지 구체적인 이유가 있습니다.

비용 (Cost). 경고(alerts), 스키마 이벤트, 메트릭(metrics), 그리고 계보(lineage)를 포함하면 조사 컨텍스트는 쉽게 수백 개의 행이 될 수 있습니다. 매번 이 모든 것을 프롬프트에 넣는 것은 호출할 때마다 토큰 비용을 지불하는 것을 의미합니다. LLM 호출 전에 백엔드에서 캡슐을 구축하면 모델에 필요한 최소한의 투영(projection)을 제공하며 토큰 사용량을 예측 가능하게 유지할 수 있습니다.

결정론 (Determinism). 캡슐의 형태는 매번 동일합니다. 산문 형태의 답변 구조는 모델의 상태(mood), 온도(temperature) 설정, 그리고 질문의 정확한 문구에 따라 달라집니다. 다운스트림 소비자(로깅, 평가 하네스(eval harnesses), 인시던트 티켓 내보내기, 프론트엔드 렌더러)는 자유 형식의 산문을 안정적으로 파싱할 수 없습니다. 하지만 타입 지정된 스키마(typed schema)는 안정적으로 파싱할 수 있습니다.

검증 가능성 (Verifiability). 이것이 가장 중요한 부분입니다. 프롬프트에 포함된 평면적인 행 덩어리(flat blob of rows)는 모델의 출력을 해당 행들로 제한하지 못합니다. 모델은 주어진 데이터를 바탕으로 여전히 환각(confabulate)을 일으킬 수 있습니다. source_id 필드가 포함된 타입 지정된 캡슐은 출력이 실제로 존재하거나 존재하지 않는 특정 레코드에 근거하도록 강제합니다. 검증 가능성은 행동(behavioral)이 아닌 구조적(structural)인 차원에서 이루어집니다.

이것이 다음에 열어줄 가능성

Capsule-as-output(출력으로서의 Capsule)는 이전에는 구축할 수 없었던 여러 기능의 기질(substrate)이 됩니다. 실행 간의 Capsule 비교(Capsule diffing, 예: 동일한 조사가 지난주와 이번 주에 서로 다른 답변을 생성했는가?), 장애 사후 분석(incident postmortems)을 위한 영구적인 Capsule(에이전트가 단순히 말한 내용뿐만 아니라, 무엇을 보고 무엇을 결론지었는지에 대한 안정적인 기록), 동일한 데이터에 대해 에이전트의 Capsule을 정답(ground-truth) 세트와 비교하는 평가 하네스(Eval harnesses), 그리고 조사를 모든 증거가 미리 첨부된 실행 가능한 티켓으로 전환하는 Export-to-Jira 또는 Export-to-Linear 워크플로우 등이 이에 해당합니다.

이 중 어느 것도 오늘 당장 출시되는 것은 아닙니다. 하지만 이러한 형태(shape)가 존재하기 때문에 구축이 가능해집니다.

사용 방법

EvidenceCapsule이 프로덕션에 출시되었습니다. 기존 AnomalyArmor 인스턴스를 사용 중인 경우:

Web agent: 채팅에서 어떤 조사 질문이든 물어보세요. Capsule이 산문 형태의 답변 아래에 렌더링됩니다.
SDK: 최신 Python SDK로 업그레이드하고 client.investigations.explain(asset_id, question)을 호출하세요.
Claude Code skill: armor-investigate를 최신 버전으로 업데이트하고 기존과 동일한 방식으로 사용하세요. 출력 형태는 이제 구조화된 JSON입니다.

별도의 대시보드가 아닌 AI 어시스턴트 내부에 상주하는 관측성(observability) 도구를 구축하는 이유에 대한 배경 정보는 AI 어시스턴트 내부에서 작동하는 데이터 관측성 도구를 참조하세요. AI 네이티브 워크플로우가 실제 장애 대응을 어떻게 변화시키는지에 대해서는 AI 네이티브 데이터 관측성이 장애 대응을 변화시키는 방법을 참조하세요.

EvidenceCapsule FAQ

이것은 단순한 RAG인가요?

아니요. RAG (retrieval-augmented generation, 검색 증강 생성)는 관련 컨텍스트를 검색하여 프롬프트에 채워 넣는 패턴입니다. EvidenceCapsule은 검색된 레코드에 대한 인용(citation)을 포함하는 타입화된 출력 스키마 (typed output schema)입니다. 이 둘은 상호 보완적입니다. 에이전트는 기존 방식과 동일하게 관련 행(row)을 검색한 다음, 사용자가 각 주장(claim)을 해당 행과 대조하여 검증할 수 있게 해주는 캡슐(capsule)을 생성합니다. RAG는 검색 측면이며, EvidenceCapsule은 감사 가능성 (auditability) 측면입니다.

LLM이 여전히 산문 형태의 답변을 작성하나요?

네. 캡슐은 구조화된 투영 (structured projection)입니다. 상단의 산문 서술은 여전히 모델에 의해 생성되며, 캡슐에 근거(grounded)합니다. 차이점은 산문에 포함된 모든 주장이 캡슐 내의 인용을 통해 확인 가능하다는 점입니다.

v1에서 지원되는 소스는 무엇인가요?

경고(Alerts), 스키마 변경(schema changes), 메트릭(metrics), 리니지 엣지(lineage edges), 그리고 인텔리전스 노트(intelligence notes)입니다. 이는 조사가 이미 다루고 있는 구조화된 행 (structured-row) 소스들입니다. 원시 로그 클러스터링 (raw log clustering) 및 비구조화된 텍스트 수집 (unstructured text ingestion)은 명시적으로 범위 외(out of scope)입니다. 증거가 구조화된 테이블에 있다면 지원됩니다.

이것이 제 데이터와도 작동하나요?

EvidenceCapsule은 AnomalyArmor가 이미 귀하의 데이터 웨어하우스 및 통합 환경에서 수집하고 있는 메타데이터를 기반으로 작동합니다. 기존 AnomalyArmor 연결 외에 귀하 측에서 추가적인 계측 (instrumentation)을 수행할 필요는 없습니다.

캡슐 형식이 안정적인가요?

네, 스키마는 버전 관리되며 추가적인 방식 (additive)으로 운영됩니다. 기존의 get_investigation 도구는 기존의 JSON 형태에 새로운 evidence_capsule 필드를 추가하여 반환하므로, 이를 선택하지 않은 클라이언트들은 변경 없이 그대로 작동합니다.

캡슐을 인시던트 티켓(incident ticket)으로 내보낼 수 있나요?

아직 내장된 흐름(built-in flow)으로는 지원되지 않습니다. 캡슐의 타입화된 구조 덕분에 이를 구축하는 것은 간단하며, 후속 기능으로 출시될 예정인 짧은 목록에 포함되어 있습니다. 오늘 당장 수동으로 수행하고 싶다면, SDK가 모든 필드를 제공합니다.

신뢰도(confidence)는 어떻게 계산되나요?

신뢰도(confidence)는 하위 상관관계 분석기(correlators)로부터 집계됩니다(각 증거 행은 자체적인 신뢰도를 가지며, 캡슐의 전체 신뢰도는 이들의 집계된 결과입니다). 이는 첫 번째 호출을 두 번째 LLM 호출이 채점하는 방식이 아닙니다. 규칙 기반(Rule-based) 집계는 더 예측 가능하며, "모델이 스스로를 채점하는" 실패 모드를 방지합니다.

왜 "캡슐(capsule)"이라고 부르나요?

이 명칭은 관측성(observability) 도구에서 구조화된 조사 출력(structured investigation outputs)을 제공하려는 광범위한 트렌드에서 유래되었습니다. 핵심은 단어 자체가 아니라, 그 형태(근본 원인(root cause) + 트리거(triggers) + 결과(consequences) + 신뢰도(confidence) + 미결 질문(open questions)이 각각 유형화된 증거(typed evidence)에 의해 뒷받침되는 구조)에 있습니다.

자신의 웨어하우스(warehouse)에서 EvidenceCapsule이 작동하는 모습을 직접 보고 싶다면, AnomalyArmor가 프라이빗 베타(private beta)로 제공되고 있습니다. 문의해 주시면 액세스 권한을 드리겠습니다.