정확한 지식은 어떻게 쌓이는가

주차별로 쌓이는 데이터

이 그래프는 한 번에 완성되지 않습니다. 정기 수집과 검토를 통해 작품과 관계 정보가 쌓입니다. 아래는 주차별 데이터 증가량을 집계한 것입니다.

막대는 그 주까지 누적된 사실(claim) 수, 아래 초록 숫자는 그 주에 새로 늘어난 양입니다. 엔티티는 현재 누적 193,960개입니다. 숫자는 현재 데이터베이스를 기준으로 집계합니다.

문서가 아니라 구조로 쌓는다

위키피디아는 사람이 읽는 문서입니다. 한 배우를 알려면 그 문서를 열어 문단을 읽어야 하고, "이 웹툰을 원작으로 한 드라마·영화를 전부" 같은 질문에는 수십 개 문서를 사람이 오가며 짜맞춰야 합니다. Atlas는 같은 정보를 기계가 곧바로 질의하는 구조로 쌓습니다.

모든 것이 엔티티(노드)와 관계(엣지)입니다. 작품·인물·캐릭터·조직·프랜차이즈·릴리스 여섯 종류의 엔티티를, 41종의 관계로 잇습니다. 서술 문장이 아니라 작품 —[감독]→ 인물, 드라마 —[원작]→ 웹툰 같은 연결이 데이터의 기본 단위입니다.

지금 노드 193,960개가 관계 568,534개로 이어져 있습니다. 스키마 전체는 온톨로지 화면에서 그림으로 볼 수 있습니다 — 그 그림도 손으로 그린 게 아니라 predicate_def 테이블에서 자동으로 만들어, 설명과 데이터가 어긋날 수 없습니다.

위키피디아와 무엇이 다른가

위키피디아를 대체하려는 게 아닙니다. 목적이 다릅니다 — 하나는 사람이 읽는 백과사전, 하나는 AI가 질의하는 데이터 인프라입니다. 그 차이가 설계 곳곳에 드러납니다.

그래서 Atlas는 위키피디아의 자매 프로젝트인 위키데이터(구조화 데이터, CC0)를 씨앗으로 쓰되, 위키백과 본문은 가져오지 않고 링크만 겁니다 — 문서를 베끼는 게 아니라 사실을 재구성하기 때문입니다.

구조가 주는 유익

• AI가 바로 쓴다. 문서를 파싱하고 환각을 걸러낼 필요 없이, 근거가 붙은 사실을 그대로 질의합니다. 이 데이터 인프라가 존재하는 이유입니다.
• 관계를 탐색한다. 원작–각색을 잇는 IP 군집(OSMU) 113개처럼, 문서에는 흩어져 있는 연결을 한 번의 질의로 따라갑니다.
• 어떤 사실이든 되짚는다. 화면의 값 하나에서 "어디서 왔는지" 근거 594,922건까지 내려갈 수 있습니다.
• 시간을 다룬다. 소속사 이적·사명 변경·편성 변경을 덮어쓰기가 아니라 기간을 나눈 사실로 보존합니다.
• 상업적으로 쓸 수 있다. 사실은 저작물이 아니고, 라이선스를 사실 단위로 관리하므로 배포 가능한 부분만 골라낼 수 있습니다.

여섯 단계

1. 1

   씨앗을 심는다

   모든 콘텐츠를 처음부터 만들지 않습니다. 최근 공개된 드라마·영화부터 시작해, Wikidata·MusicBrainz의 구조화 데이터를 씨앗으로 가져옵니다. 여기서 "작품 A는 감독 B가 만들었다" 같은 뼈대가 생깁니다.

   예: node ingest/load_pg.mjs · ingest/osmu.mjs

2. 2

   사실 하나하나에 출처를 붙인다

   모든 사실은 3요소가 아니라 6요소로 저장됩니다 — (주어, 관계, 목적어, 출처, 신뢰도, 관측 시각). "누가 언제 주장했는가"가 없으면 검증도 충돌 해소도 할 수 없기 때문입니다. 같은 사실이라도 출처가 다르면 근거가 따로 쌓입니다.

   지금 근거 594,922건이 사실 568,534건을 뒷받침합니다.

3. 3

   출처를 등급으로 나눈다

   모든 출처를 똑같이 믿지 않습니다. 세 등급으로 나누고, 등급이 등급을 넘어 자동 승격하지 못하게 막습니다.

   A 권위 있는 출처 6곳

   KMDb·공식 발표·사람이 직접 확인. 단독으로도 신뢰한다.

   bcwwhumankmdbkocca_entkomaconofficial

   B 구조화된 공개 데이터 4곳

   Wikidata·MusicBrainz·TMDB·Commons. 서로 다른 곳 2군데가 일치하면 자동 승격.

   commonsmusicbrainztmdbwikidata

   C 힌트 전용 4곳

   나무위키·뉴스. 검토를 시작할 단서로만 쓰고, 절대 자동 승격하지 않는다.

   enwikigeneratednamunaver_news

   나무위키·뉴스(C등급)는 사실의 근거가 아니라 검토를 시작할 단서일 뿐입니다. 특히 뉴스는 저장·가공하지 않고 링크로만 인용합니다.

4. 4

   서로 다른 출처가 일치하면 한 단계 올린다

   서로 독립적인 A·B 출처 두 곳 이상이 같은 사실을 말하면, 그 사실은 candidate에서 corroborated로 자동 승격됩니다. 여기서 "독립적"이 핵심입니다 — Wikidata와 TMDB는 서로 봇으로 데이터를 주고받아, 둘이 같다고 해서 두 번 확인된 게 아닙니다. 그래서 출처를 독립성 그룹으로 묶고, 같은 그룹은 한 번으로 셉니다.

   현재 교차검증 상태의 사실은 5,124건입니다. 각 사실에 연결된 출처와 독립성 조건을 기준으로 검증 상태를 관리합니다.

5. 5

   충돌은 사람에게 넘긴다

   한 값만 가질 수 있는 사실(생년월일·최초 공개일 등)에 서로 다른 값이 주장되면 conflicted로 표시되어 검토 큐에서 최우선으로 처리됩니다. 기계가 다수결로 정하지 않고, 등급 높은 쪽이 자동으로 이기지도 않습니다 — 사람이 판단합니다. 사람이 확정한 값은 이후 재수집이 돌아도 절대 기계가 덮어쓰지 못합니다.

   지금 충돌 2,014건이 검토를 기다립니다. 예를 들어 한 배우의 생년월일이 출처마다 다르면, 그건 노이즈가 아니라 사람이 봐야 할 진짜 질문입니다.

6. 6

   사람이 확정하고, 그 흔적을 남긴다

   관리자가 검토 화면에서 사실을 확인하거나 고치면 verified가 되고, 누가 언제 무엇을 바꿨는지 감사 로그에 남습니다. 각 문서에는 검증·수정 표시가 붙어, 어디까지 사람 손을 거쳤는지 한눈에 보입니다. 아직 문서로 만들지 않은 참조 대상은 붉은 링크로 드러나 — 그래프의 빈 곳이 눈에 보여야 채울 수 있기 때문입니다.

   현재 stub(참조되었으나 미구축) 1,305건. 빈 곳을 감추지 않습니다.

사실 하나가 거치는 상태

기계는 candidate만 만듭니다. corroborated로 가려면 독립 출처의 합의가, verified로 가려면 사람의 확인이 필요합니다. 값이 다투면 옆으로 새 conflicted로 빠져 검토 큐로 가고, 틀린 사실은 rejected로 물러나되 삭제하지 않습니다 — 왜 뺐는지도 기록이기 때문입니다.

지키는 원칙

• 지어내지 않는다. 모르는 값은 비워 둡니다. 빈칸은 "정보 없음"이지만 틀린 값은 실존 인물·작품을 잘못 기술합니다.
• 출처 ≠ 식별자. Wikidata를 통해 얻은 TMDB·IMDb ID는 "다른 데서 뭐라 불리는가"이지 우리가 접속한 출처가 아닙니다. 둘을 섞지 않습니다.
• 라이선스를 존중한다. Wikidata 구조화 데이터(CC0)는 가져오되, 위키백과 본문(CC BY-SA)은 링크만 겁니다. 뉴스는 사실 확인용으로 인용만 합니다.
• 사람의 판단을 덮어쓰지 않는다. 한 번 확정된 값은 재수집이 몇 번을 돌아도 그대로 남습니다.
• 결정적으로 만든다. 같은 입력은 언제 돌려도 같은 결과를 냅니다 — 그래야 재수집이 없던 충돌을 만들어내지 않습니다.