열둘 중 열은 추측이었다: 결정론적 레지스트리의 씨앗을 감사하다
한 가지 질문이 계기가 됐습니다.
“이 레지스트리 항목들, 어디서 나온 거야?”
소스 신뢰도 분류 시스템에 대해서는 다른 편에서 자세히 다루겠지만, 간단히 말하면 이렇습니다. 소스를 인제스트할 때마다 “이 미디어가 얼마나 신뢰할 수 있는가”를 S1~S4 등급으로 분류합니다. 그리고 한 번 확인한 미디어는 레지스트리에 저장해서, 다음 번에는 처음부터 다시 추측하지 않고 기록을 찾아보도록 했습니다.
설계 의도는 좋았습니다. 문제는 레지스트리를 처음 만들 때 이미 12개의 도메인을 초기 데이터로 넣어뒀다는 점이었습니다.
그 데이터의 출처를 물어봤습니다.
“제가 알고 있던 것들입니다”
AI 에이전트의 답변은 정직했습니다.
“레지스트리를 만들 당시 일반적인 지식으로 판단한 것들입니다. Daniel이 직접 확인하신 항목은 없습니다.”
12개 중 2개만 제가 실제로 확인한 근거가 있었습니다. 나머지 10개는 AI가 “이 사이트는 보통 이런 수준이겠지”라고 추측한 내용이 마치 확인된 사실처럼 저장되어 있었습니다.
이것은 단순한 데이터 품질 문제가 아니었습니다. 레지스트리를 만든 이유 자체가 “매 세션마다 다시 추측하지 말고 한 번 확인한 것을 기록으로 남기자”였는데, 그 레지스트리의 씨앗 데이터가 추측으로 채워져 있었습니다. 이 시스템이 막으려 했던 문제를 이 시스템이 그대로 안고 있었습니다.
증거를 역추적할 수 있을까
수동으로 10개를 다시 확인하는 것은 현실적이지 않았습니다. 그래서 다른 방법을 생각했습니다.
위키에는 이미 300개가 넘는 소스의 인제스트 기록이 있었습니다. 각 소스마다 도메인 정보가 있고, 그 소스의 V-tier(검증 가능성) 기록이 있습니다. Tier = V × S 매트릭스로 계산되므로, 같은 도메인의 소스가 여러 개 있으면 거꾸로 S-tier를 추론할 수 있습니다.
이것을 자동화한 것이 backfill_registry.py였습니다. 과거 인제스트 기록을 뒤져서 “이 도메인의 역사적 패턴이 특정 S-tier 추정과 유일하게 일치하는 경우”를 찾아내는 도구입니다.
결과적으로 6개 도메인에서 기존 추측을 수정하거나 새로 추가할 수 있는 실제 증거를 찾았습니다. 그리고 나머지 6개는 여전히 “증거 부족”으로 표시됐습니다. 확인되지 않은 것을 확인되지 않았다고 표시하는 것이, 잘못된 자신감보다 낫습니다.
시스템이 스스로를 감사해야 한다
이 경험이 가르쳐준 것이 있습니다.
AI 에이전트와 함께 시스템을 만들 때, 에이전트가 생성한 데이터와 사람이 확인한 데이터를 명확히 구분하지 않으면 둘이 섞여버립니다. 에이전트는 틀릴 수 있고, 에이전트가 틀렸을 때 그것이 어디에 있는지 찾을 수 있어야 합니다.
’확인됨’과 ’확인되지 않음’의 구분이 없다면, 시스템 전체의 신뢰도는 그 구분이 없는 항목의 수준으로 내려갑니다.
레지스트리는 지금도 계속 업데이트됩니다. 새로운 소스를 인제스트할 때마다 새로운 증거가 쌓이고, 일부는 기존 추정을 뒤집기도 합니다. 시스템이 스스로를 감사하는 구조가 처음부터 있었다면 더 좋았겠지만, 늦게라도 만든 것이 없는 것보다 낫다는 사실을 이때 배웠습니다.
다음 편 예고
인박스에 소스가 쌓이기 시작했습니다. 하나씩 처리할 때는 신중했는데, 다섯 개가 쌓이니 어느 순간 “그냥 다 승인하면 되겠지”라는 생각이 들기 시작했습니다. 다음 편에서는 그 패턴이 얼마나 빠르게 나타났는지 이야기하겠습니다.