살아있는 온톨로지 (The Living Ontology)

실시간으로 AI가 생성하고 인간이 검증하는 프로젝트 인텔리전스를 위한 패턴

Kiprono Ngetich

_온톨로지 (Ontology)_는 데이터와 인텔리전스(Intelligence) 사이의 차이입니다. 정적인 스키마 (Schema)는 감옥과 같습니다. 진화하고, 인간의 개입 (Human override)을 존중하며, 출처 (Provenance)를 추적하는 '살아있는 온톨로지'만이 운영 환경에서 AI를 유용하게 만드는 유일한 방법입니다.

이 문서는 프로젝트 상태 인텔리전스를 위해 구축된 온톨로지 패턴을 설명합니다. 하지만 이 패턴은 일반화될 수 있습니다.

다음과 같은 모든 도메인에서 이 패턴을 사용할 수 있습니다:

• 비정형적인 인간의 커뮤니케이션에 구조화된 의도 (Intent)가 포함되어 있는 경우
• AI가 제안할 수 있지만, 인간이 반드시 검증해야 하는 경우
• 실시간 협업이 필수적인 경우
• 감사 가능성 (Auditability)이 컴플라이언스 (Compliance) 요구사항인 경우

...

핵심적인 긴장 관계

모든 운영 온톨로지는 근본적인 긴장 관계에 직면합니다:

AI는 혼돈 속에서 구조를 추출할 수 있지만, AI는 종종 틀립니다. 인간은 진실을 알고 있지만, 인간은 온톨로지를 유지 관리하려 하지 않습니다.

전통적인 해결책은 다음 두 가지 방향 중 하나에서 실패합니다:

AI 우선 (AI-first): 온톨로지가 자동으로 생성됩니다. 인간은 관찰자일 뿐입니다. 시스템은 표류하고, 신뢰는 무너집니다.

인간 우선 (Human-first): 온톨로지가 수동으로 유지 관리됩니다. AI는 무시됩니다. 시스템은 정확하지만 오래된 정보(Stale)를 담고 있습니다. 인간은 번아웃을 겪습니다.

세 번째 길이 존재합니다.

패턴: 주요 축으로서의 출처 (Provenance)
대부분의 온톨로지는 사물이 '무엇인지'를 중심으로 구성됩니다. 이 패턴은 우리가 '무엇을 어떻게 아는지'를 중심으로 구성됩니다.

모든 엔티티 (Entity)는 출처 플래그를 가집니다: isManuallyEdited.

이 단 하나의 불리언 (Boolean) 값이 온톨로지를 정적인 분류에서 동적인 신뢰 계층 (Trust layer)으로 변모시킵니다.

최소 형태의 온톨로지:

text
WeekData
  - contains → Task (AI-extracted)
...

핵심적인 통찰: AI가 생성한 것과 인간이 검증한 것은 별개의 엔티티 유형이 아닙니다. 이들은 서로 다른 출처 상태를 가진 동일한 엔티티 유형입니다.

이는 다음을 의미합니다:

• 쿼리 계층 (Query layer)에서 출처에 따라 필터링할 수 있습니다 (인간이 검증한 행만 보여주기).
• AI 계층이 출처로부터 학습할 수 있습니다 (isManuallyEdited=true인 행은 학습 데이터가 됩니다).

준수 계층(compliance layer)은 출처(provenance)를 감사할 수 있습니다 (모든 필드는 AI 또는 인간이라는 추적 가능한 출처를 가집니다).

세 가지 온톨로지 불변량 (The three ontological invariants)

불변량 1: POST-once 제약 (The POST-once constraint)
AI 생성은 고유한 도메인 엔티티당(이 경우에는 주당 1회) 최대 한 번만 발생합니다.

온톨로지에서 이것이 중요한 이유: 대부분의 시스템은 AI를 온디맨드(on-demand) 서비스로 취급합니다. 모든 뷰(view)가 생성을 트리거합니다. 이는 출처(provenance)를 무의미하게 만듭니다. 비교할 수 있는 "원본" AI 상태가 존재하지 않기 때문입니다.

이 불변량은 고정점(fixed point)을 생성합니다. 첫 번째 AI 출력물은 기준점(baseline)으로 동결됩니다. 이후의 모든 인간 편집은 해당 기준점에 대한 델타(delta, 차이)가 됩니다.

이것이 스트리밍 지능(streaming intelligence, 일시적이고 반복 불가능함)과 정착된 지능(settled intelligence, 감사 가능하고 비교 가능하며 학습 가능함)의 차이입니다.

불변량 2: 덮어쓰기 불가 원칙 (The override-is-sacred rule)
isManuallyEdited가 false에서 true로 전환되면, 시스템은 원래의 AI 값을 기록하지만 이를 다시는 노출하지 않습니다.

이것이 중요한 이유: 대부분의 AI 시스템에서 인간의 피드백은 훈련 신호(training signal), 즉 결국 모델을 개선하게 될 무언가로 취급됩니다. 운영 환경(operational environments)에서 그러한 지연 시간(latency)은 용납될 수 없습니다. 인간의 수정은 즉각적으로 권위(authoritative)를 가져야 합니다.

온톨로지는 이를 애플리케이션 계층뿐만 아니라 저장 계층(storage layer)에서 강제합니다. AI가 다시 실행되더라도 isManuallyEdited가 true인 필드를 덮어쓸 수 없습니다.

불변량 3: 일시적 존재 경계 (The ephemeral presence boundary)
사용자 존재(user presence) — 즉, 지금 누가 무엇을 보고 있는지 — 는 영속성(persistence)에서 명시적으로 제외됩니다.

이것이 중요한 이유: 온톨로지는 일시적인 상태(ephemeral state)를 포함하여 모든 것을 캡처하려는 경향이 있습니다. 이는 두 가지 문제를 일으킵니다:

1. 저장 공간이 도메인 복잡성이 아닌 활동량에 따라 증가함
2. 쿼리가 무관한 "현재 상태(current state)"로 인해 지저분해짐

존재(presence)를 온톨로지 외부(out-of-ontology)로 선언함으로써, 이는 별도의 채널(WebSocket presence messages)로 강제됩니다. 온톨로지는 정착된 진실(settled truth)에 집중된 상태를 유지합니다.

이를 통해 가능한 것
AI 운영 측면에서
출처 플래그(provenance flag)는 자연스러운 학습 루프를 생성합니다:

AI가 초기 상태를 생성합니다

사람이 특정 필드를 수정합니다

시스템이 원본과 수정본을 비교합니다

수정 사항이 라벨링된 학습 데이터 (labeled training data)가 됩니다

온톨로지는 입력값 (raw message)과 수정된 출력값 (edited row) 사이의 정렬 (alignment)을 보존합니다. 이는 일반적인 인간 피드백 (human feedback)보다 훨씬 더 가치 있습니다. 모델은 수정을 바탕으로 원본 메시지를 재검토함으로써 자신이 왜 틀렸는지 학습할 수 있습니다.

인간의 운영 측면에서
사용자는 AI의 실수를 결코 보지 않습니다. 그들은 수정된 진실을 봅니다. 하지만 사용자가 원한다면 AI의 원래 출력값을 볼 수도 있습니다. 감사 추적 (audit trail)이 토글 스위치 바로 뒤에 존재하기 때문입니다.

이는 심리적 안정감 (psychological safety)을 형성합니다. AI는 틀릴 수 있도록 허용됩니다. 잘못된 추출 (extraction)에 대해 누구도 비난받지 않습니다. 시스템은 그저 학습하고 개선될 뿐입니다.

컴플라이언스 (compliance) 측면에서
모든 필드는 출처 체인 (provenance chain)을 가집니다:

• 만약 isManuallyEdited = false라면, 해당 값은 AI로부터 왔으며, AI는 (저장되고, 변경 불가능하며, 타임스탬프가 찍힌) rawMessage를 바탕으로 작동했습니다.

• 만약 isManuallyEdited = true라면, 해당 값은 특정 시점에 특정 에이전트 (username)로부터 왔으며, 원래의 AI 값은 그대로 유지됩니다.

이는 문서화가 증거 표준 (evidentiary standards)을 충족해야 하는 규제 환경 (regulated environments)에서 충분한 요건이 됩니다.

기존 방식과의 비교

항목	기존 온톨로지	이 패턴
AI 출력	일시적이며, 조회할 때마다 재생성됨	고정된 지점이며, 감사가 가능한 기준점 (auditable baseline)
인간의 수정	AI 출력을 덮어쓰며, 흔적이 남지 않음	원본을 보존하며, 오버라이드 (override) 플래그를 표시함
학습 데이터	별도의 수집 파이프라인 필요	사용의 자연스러운 부산물
...

일반화
이 패턴은 다음과 같은 조건이 충족되는 모든 도메인에 적용됩니다:

• 비정형 입력값 (이메일, 전사 데이터, 로그, 메시지)에 잠재적 구조 (latent structure)가 포함되어 있음
• AI가 수용 가능한 정확도 (70-90%)로 해당 구조를 제안할 수 있음
• 인간이 높은 신뢰도로 수정을 검증해야 함
• 여러 행위자(actors) 간에 실시간 가시성이 필요함
• 감사 가능성 (auditability)이 컴플라이언스 요구 사항임

예시 도메인:

정보 분석 (Intelligence analysis): AI가 가공되지 않은 정보 (raw intelligence)에서 개체 (entities)와 관계 (relationships)를 추출하면, 분석가가 이를 수정 및 보완하며, 온톨로지 (ontology)는 출처 (provenance)를 추적합니다.

사고 대응 (Incident response): AI가 경보 스트림 (alert streams)으로부터 타임라인과 영향을 제안하면, 대응 인력이 실시간으로 수정하며, 지휘부 (command)는 실시간 상태를 확인합니다.

공급망 가시성 (Supply chain visibility): AI가 운송업체의 메시지에서 배송 상태를 추출하면, 물류 팀이 예외 사항을 수정하고, 이해관계자들은 권위 있는 진실 (authoritative truth)을 확인합니다.

임상 시험 (Clinical trials): AI가 사이트 보고서에서 환자 상태를 추출하면, 모니터링 요원이 이를 검증하고, 규제 기관이 출처 체인 (provenance chain)을 감사 (audit)합니다.

모든 사례에서 핵심 패턴은 동일합니다:

AI가 제안하고, 인간이 결정합니다. 온톨로지는 그 차이를 기억합니다.

남겨진 질문
이 온톨로지는 단방향입니다: AI → 인간 → (동결). 인간의 수정 사항이 단순한 학습 데이터 (training data)를 넘어, 향후 추출을 위한 AI의 세계 모델 (world model)로 다시 흘러 들어가는 폐쇄 루프 (closed loop)가 존재하지 않습니다.

직관적으로는 그 해결책이 온톨로지 자체에 있다고 생각됩니다. 즉, isManuallyEdited를 모델의 잠재 공간 (latent space) 내에서 원래의 추출 결과에 대한 가중치를 재조정해야 한다는 신호로 취급하는 것입니다. 하지만 이는 아직 구현되지 않은 상태입니다.

맺음말
작은 문제(프로젝트 상태 보고)를 위한 작은 온톨로지입니다. 하지만 출처 (provenance)를 주요 축으로 삼고, 단 한 번의 POST를 통한 생성, 신성한 인간의 우선권 (human override), 일시적 존재의 분리라는 이 패턴은 일반적인 것으로 느껴집니다.

이는 운영 환경에서 AI가 겪는 핵심적인 긴장 상태를 해결합니다. 기계는 제안하고 인간은 결정하며, 시스템은 이 둘을 절대 혼동하지 않습니다.

이것은 단순한 데이터 모델이 아닙니다. 이것은 신뢰 모델 (trust model)입니다.

Kiprono Ngetich

부록: 온톨로지 명세 (요약)
개체 (Entities):

Entity  Key fields  Provenance
WeekData    weekNumber, year, rawMessage    생성 후 변경 불가능 (Immutable)
StatusRow   9개 콘텐츠 필드, isManuallyEdited, sourceTask  플래그는 한 번만 전환됨 (false→true)
...