AI 증거 플랫폼(AI evidence platform)은 대부분의 조직이 관측성(observability) 도구를 승인했을 때 구매했다고 생각하는 바로 그 물건이 아닙니다. 예산은 승인되었고, 벤더(vendor)가 선정되었으며, 대시보드(dashboard)가 구축되었습니다. 하지만 그 자리에 있던 누구도 "우리가 모델이 무엇을 했는지 볼 수 있는가"와 "우리가 모델이 무엇을 했는지 증명할 수 있는가"가 동일한 구매인지 묻지 않았습니다. 이 둘은 다르며, 그 사이의 간극이 바로 이 포스트의 실제 주제입니다.

AI evidence platform — observability dashboard vs unprovable authorization gap

조직들이 가시성(Visibility)을 증거(Proof)로 착각한 이유

이러한 실수는 이해할 만하며, 바로 그렇기 때문에 매우 흔하게 발생합니다. 장애 검토(incident review) 중이거나, 모델의 출력에 대한 이사회의 질문이 있거나, 고객의 에스컬레이션(escalation)이 발생했을 때, 관측성(observability) 대시보드는 그 자리에서 유일하게 정답처럼 보이는 산출물입니다. 거기에는 타임스탬프(timestamps)가 있습니다. 트레이스(trace)가 있습니다. 나쁜 일이 발생하기 전에 상승하는 그래프가 있습니다. 회의에 참석한 모든 사람이 고개를 끄덕입니다. 가시성(visibility)이 증거(proof)처럼 느껴지기 때문입니다. 그것은 구체적이고, 쿼리(queryable)가 가능하며, 충분히 비싼 비용을 지불했기에 분명히 단순히 무언가를 보여주는 것 이상의 역할을 할 것이라고 믿기 때문입니다.

그러한 느낌이 바로 전체적인 실패 모드(failure mode)입니다. "무슨 일이 일어났는가"에 답하는 관측성(observability)은 장애 발생 시 엔지니어들로 가득 찬 방에서 던지는 질문을 충족시킵니다. 하지만 그것은 규제 기관, 감사인(auditor), 또는 상대측 변호사가 6개월 후에 던지는 질문을 충족시키지는 못합니다. 그 질문은 "이것을 승인한 사람이 당시 시행 중이던 정책에 따라 권한을 부여받았음을 증명하라"에 더 가깝습니다. 이것들은 서로 다른 증거 요구 사항을 가진 서로 다른 질문이며, 첫 번째 질문에 답하는 플랫폼은 두 번째 질문에 답하도록 설계되지 않았습니다. 바로 그 지점에서 AI 증거 플랫폼(AI evidence platform)은 아주 훌륭한 대시보드(dashboard)로 조용히 대체되며, 아무도 그 교체가 일어났다는 사실을 알아차리지 못합니다.

이것은 관측성(observability)에 국한된 새로운 관찰 결과가 아닙니다. 이는 rack2cloud가 이미 정의한, 거버넌스 레이어로서의 관측성(The AI Observability Layer Is Becoming a Governance System)과 수동적 텔레메트리(passive telemetry)로서의 관측성 사이의 차이점과 동일합니다. '관측성 권한 경계(Observability Authority Boundary)'는 관측성이 대시보드(dashboard) 역할을 멈추고 무언가를 강제(enforce)하도록 요구받는 시점을 명명합니다. 대부분의 조직은 여전히 그 경계의 대시보드 쪽에 머물러 있으며, 그 사실조차 인지하지 못하고 있습니다. 왜냐하면 아직 아무도 그들에게 대시보드가 할 수 없는 무언가를 만들어내라고 요구하지 않았기 때문입니다.

관측성이 설계된 목적

이 모든 내용이 도구(tooling) 자체를 비판하는 것은 아닙니다. 관측성 플랫폼은 모델 동작, 지연 시간(latency), 오류율(error rates), 드리프트 신호(drift signals), 리소스 소비에 대한 실시간 가시성(visibility) 등 본래 설계된 목적에 충실합니다. 이는 진정으로 가치 있는 일이며, 이를 갖추지 못한 조직은 실제 운영 사고(production incidents)를 유발하는 방식으로 눈을 가린 채 비행하는 것과 같습니다. 도구가 문제는 아닙니다.

문제는 그 위에 무엇이 당연하게 가정되었는가입니다. 관측성은 운영 도구(operations tool)로서, 즉 팀이 시스템이 현재 무엇을 하고 있는지 보고 대응하는 것을 돕는 용도로 범위가 설정되고, 구축되고, 판매되었습니다. 증거(Evidence)는 완전히 다른 요구사항입니다. 생성된 순간을 지나 생존해야 하며, 현장에 없었던 당사자에게 전달될 수 있어야 하고, 설명 대상인 시스템을 더 이상 호출하여 물어볼 수 없는 상태에서도 유효해야 하는 것입니다.

실수는 관측성을 구매한 것이 아닙니다. 실수는 관측성이 설계된 적도 없는 결과물(artifacts)을 만들어낼 것이라고 기대한 것입니다.

AI 증거 플랫폼(AI Evidence Platform)에 실제로 필요한 것

기계적인 관점에서 실제 격차가 발생하는 지점은 바로 여기입니다. 관측성 (Observability)은 요청이 발생했는지, 무엇을 반환했는지, 그리고 대략 얼마나 걸렸는지를 알려줍니다. 하지만 기본적으로 관측성은 해당 요청을 생성한 동작을 누가 승인했는지, 어떤 정책 (policy)에 따라 그 승인이 부여되었는지, 혹은 실행 시점에 해당 정책이 실제로 유효했는지까지는 알려주지 않습니다. 관측성은 시스템이 실행되었다는 사실을 알려줄 뿐입니다. 시스템이 제3자가 독립적으로 확인할 수 있는 형태로 정당하게 (legitimately) 실행되었는지는 알려주지 않습니다.

이것은 더 나은 대시보드로 해결할 수 있는 도구적 격차가 아닙니다. 이는 카테고리의 차이입니다. 관측성 데이터는 그것을 생성한 플랫폼 내부에 존재합니다. 즉, 쿼리하고, 그래프로 그리고, 알람을 설정할 수는 있지만, 해당 플랫폼이 사라지거나, 은퇴하거나, 혹은 요청하는 당사자로부터 신뢰를 얻지 못하는 순간 데이터도 함께 사라집니다. 증거 (Evidence)는 정의상 바로 그러한 상황에서도 살아남아야 합니다. 증거는 생성된 시스템 외부에서도 의미를 가질 수 있을 만큼 충분히 이식 가능 (portable)해야 하며, 충분히 귀속 가능 (attributable)해야 합니다.

이것이 바로 rack2cloud의 AI 증거 아티팩트 레이어 (AI Evidence Artifact Layer) 프레임워크 (AI Systems Need Evidence, Not Just Observability)가 직접 명명한 조건입니다. 즉, 생성된 런타임 (runtime) 외부에서도 살아남을 수 있는, 이식 가능하고 귀속 가능하며 검증 가능한 실행 증거를 생성할 책임이 있는 아키텍처 레이어입니다. 더 쉬운 말로 표현하자면, 그것이 바로 AI 증거 플랫폼의 실체입니다. 대시보드가 아니라, 자신을 만든 시스템보다 더 오래 지속되는 아티팩트 (artifacts)를 생성하기 위한 메커니즘입니다. 이 프레임워크의 실패 상태에도 이름이 있는데, 바로 '증거 없는 가시성 (Visibility Without Proof)'입니다. 이는 위에서 설명한 상황을 정확히 묘사합니다. 운영자는 AI 시스템이 무엇을 했는지 볼 수는 있지만, 런타임이 사라졌고 증거가 런타임보다 오래 지속되도록 설계된 형태로 생성된 적이 없기 때문에, 제3자는 사후에 승인 (authorization), 출처 (provenance), 또는 정책 상태 (policy state)를 재구성할 수 없습니다.

나란히 놓고 비교해 보면, 이 차이는 기능 비교의 문제가 아니라 거버넌스 (governance)의 문제입니다:

해당 표에 등장하는 모든 "아니오"와 "제한적"이라는 답변은, 조직이 답을 가지고 있다고 믿었으나 정밀 조사 (scrutiny) 과정에서 그렇지 않다는 것을 깨닫게 되는 지점입니다.

이 격차가 테스트되기 전까지 보이지 않는 이유

이 격차가 오랫동안 눈에 띄지 않는 이유는 우연이 아니라 구조적인 문제입니다. 관측성 (observability)은 운영 (operations) 중에 성공적으로 작동합니다. 반면 증거 (evidence)는 정밀 조사 (scrutiny) 중에 테스트됩니다. 이들은 서로 다른 허용 범위 (tolerances)를 가진 서로 다른 대상이며, 일반적인 비즈니스 상황에서는 오직 한 부류만이 나타납니다.

observability succeeds in operations, evidence tested only under scrutiny

운영 팀은 관측성 (observability)을 좋아하며, 이는 타당합니다. 관측성은 그들이 새벽 2시에 문제를 찾아내고 해결할 수 있게 해주는 도구이기 때문입니다. AI 증거 플랫폼은 운영이 평온한 시기에는 구축되지 않습니다. 왜냐하면 일반적인 운영 중에는 그 어떤 것도 플랫폼에 무언가를 증명하라고 요구하지 않기 때문입니다. 감사인 (Auditors), 규제 기관 (regulators), 법무 팀 (legal teams), 그리고 조사관 (investigators)은 증거를 요구하며, 이들은 일반적인 운영 중에 나타나지 않습니다. 이들은 무언가 잘못된 이후, 혹은 규제 기관이 이미 요청을 보낸 이후에 나타납니다. 이는 대부분의 조직이 이 격차를 발견하는 첫 번째 순간이, 바로 그 격차가 실제로 중요해지는 첫 번째 순간임을 의미합니다. Who Approved the Model's Output?는 권한 부여 (authorization) 레이어에서의 정확히 이러한 실패 모드 (failure mode)를 다룹니다. 즉, 플랫폼은 모델을 실행했지만, 사후에 누가 그 실행을 승인했는지 아무도 제시할 수 없는 상황입니다. [The Model Answered.

Nobody Asked Who Authorized That.는 검토(Review) 시점이 아닌 실행(Execution) 시점이라는, 한 단계 앞선 지점에서도 동일한 격차가 발생함을 보여줍니다.

기술적 실패 이면에 숨겨진 조달(Procurement)의 실패

이 부분은 아키텍처 다이어그램(Architecture diagrams)에는 나타나지 않으며, 이러한 격차가 이토록 광범위하게 퍼져 있는 실제 이유입니다. 조달(Procurement) 과정에서 인프라 팀은 가시성(Visibility)을 평가했고, 보안 팀은 액세스 제어(Access controls)를 평가했으며, 법무 팀은 계약 문구를 검토했습니다. 6개월 후에 승인 이력(Authorization history)을 증명해야 할 명시적인 책임자는 아무도 없었습니다. 회의실에 있던 모든 기능(Function)은 자신들에게 주어진 범위(Scope) 내에서 각자의 업무를 올바르게 수행했습니다. 하지만 그 어떤 범위에도 증거 생존성(Evidence survivability)은 포함되지 않았는데, 이는 누구도 이를 범위에 명시하지 않았기 때문입니다. 회의실의 모든 범위는 올바르게 평가되었습니다. 다만 그중 어느 것도 "AI 증거 플랫폼(AI evidence platform)"이라고 명명되지 않았기에, 이를 구축할 책임도 누구에게도 없었습니다.

이 질문은 직접적으로 던질 가치가 있습니다. 왜냐하면 그 답이 단순한 관찰보다 더 유용하기 때문입니다.

구매의 소유권은 누구에게 있었는가? 거버넌스(Governance)의 소유권은 누구에게 있었는가? 증거 요구사항(Evidence requirements)의 소유권은 누구에게 있었는가? 누가 다른 누군가가 처리했을 것이라고 가정했는가?

대부분의 조직에서 이 네 가지 질문에 대한 솔직한 답변은 모두 동일한 단어, 즉 "아무도 없다"입니다. 이는 누군가 태만했기 때문이 아닙니다. 구매가 운영(Operations) 결정으로 범위가 지정되었고, 운영 기준에 의해 평가되었으며, 증거 요구사항이 이를 지적할 수 있는 기능(Function)에 할당된 적이 없었기 때문입니다. Your AI Vendor Became Critical Infrastructure Before The Contract Did는 다른 각도에서 바라본 동일한 조달 실패 패턴을 보여줍니다. 즉, 핵심 의존성(Critical dependencies)이 이를 뒷받침하기 위해 마련된 계약 및 거버넌스 구조(Scaffolding)보다 더 빠르게 구축된다는 점입니다.

만약 귀사의 조직이 이러한 격차에 직면해 있고, 증거(Evidence) 요구사항에 대한 명확한 책임자(Owner)가 아직 없다면, AI Governance Assessment는 바로 이 점을 드러내기 위해 설계되었습니다. 이는 기술 감사(Technology audit)가 아니라, 귀사가 AI 증거 플랫폼(AI evidence platform)을 보유하고 있는지, 아니면 단지 관측성(Observability) 레이어에 그 이름을 붙여 사용하고 있는지, 그리고 그 차이를 메우기 위해 누가 책임을 지는지에 대한 범위 감사(Scope audit)입니다.

설계자의 판결 (Architect's Verdict)

구매 자체가 틀린 것은 아니었습니다. 범위(Scope)가 틀렸던 것입니다. 관측성 플랫폼을 구매한 모든 조직은 실제로 유용하고 실질적인 것을 구매했습니다. 실패의 원인은 제품에 있었던 것이 아니라, 가시성(Visibility)과 증명(Proof)이 동일한 요구사항이며, 동일한 기준으로 평가되고, 동일한 구매를 통해 충족될 것이라는 명시되지 않은 가정에 있었습니다. AI 증거 플랫폼은 거버넌스 요구사항(Governance requirement)이지, 단순한 항목(Line item)이 아닙니다. 이를 후자처럼 취급하는 것이 이 글 전체가 설명하고 있는 실수입니다.

이 격차가 놓여 있는 규제 압박은 가설적이거나 먼 미래의 이야기가 아닙니다. EU AI Act 시행 일정은 "이것을 증명할 수 있는가"라는 질문을 가설적인 감사 질문에서 날짜가 지정된 준수 마감일(Compliance deadline)로 바꿉니다. 증거를 나중에 추가할 기능(Feature)으로 취급하는 조직은 거버넌스 요구사항을 제품 로드맵 항목(Product roadmap item)으로 취급하는 것이며, 이 두 가지는 동일한 일정으로 움직이지 않습니다.

가장 어려운 증거 문제는 증거를 수집하는 것이 아닙니다. 증거를 생성한 플랫폼을 신뢰할 수 없게 되었을 때, 그 증거가 여전히 존재하는지 판단하는 것입니다. 많은 조직은 플랫폼이 정보를 표시할 수 있기 때문에 증거가 존재한다고 가정합니다. 해당 플랫폼을 사용할 수 없게 되거나, 논란의 여지가 생기거나, 신뢰할 수 없게 되는 순간이 바로 증거가 실제로 존재하는지 발견하게 되는 순간입니다.

원문은 rack2cloud.com에 게시되었습니다.