제10장. 검증 - 세 단계로 합격을 담보하는 과정

4차 서술 집필이 끝나면 LLM 블록 1,500개에 서술이 모두 채워집니다. 그러나 서술이 채워졌다는 것만으로 Vault가 완성되었다고 말하기는 어렵습니다.

이 시점의 Vault는 방대하지만 아직 검증을 거치지 않은 상태여서, 끊어진 링크가 남아 있거나 같은 인물이 두 표제어로 중복 등록되었거나 세계관축이 잘못 분류된 표제어가 섞여 있을 수 있습니다. 이런 문제들을 발견하지 못한 채 출구 작업으로 Vault를 넘기면, 그 작업은 잘못된 정보를 그대로 물려받게 됩니다.

10장은 이런 잠재적 문제들을 발견하고 처리하는 검증 단계를 다룹니다.

검증이 창작을 느리게 만든다는 오해

검증을 처음 접하면 이런 반응이 나오기도 합니다. "검증 항목이 너무 많아 부담스럽다. 이 모든 것을 다 통과해야 한다면 창작이 오히려 느려지는 것 아닌가." 검증을 창작에 걸림돌이 되는 절차로 여기는 시각인데, 소프트웨어 개발의 역사는 이 시각이 틀렸음을 오랜 경험으로 증명해 왔습니다.

1960년대 초기 소프트웨어 개발 현장에서는 코드를 일단 빠르게 작성하고 문제가 생기면 그때 고쳤습니다. 검증 없이 배포한 뒤 사용자가 오류를 발견하면 수정하는 방식이었는데, 결과는 좋지 않았습니다. 오류가 점점 쌓이는 데다 하나를 고치면 다른 부분에서 새 오류가 생겼고, 코드가 커질수록 수정 비용이 기하급수적으로 늘었습니다. 이 경험에서 소프트웨어 업계가 배운 것은 오류를 발생 시점에 가깝게 잡을수록 수정 비용이 낮다는 사실입니다. 1차 추출에서 생긴 오류를 1차에서 잡으면 비용이 1이지만, 그 오류가 2차를 거쳐 3차까지 내려가 Vault의 파일 1,500개로 퍼진 다음 잡으면 비용은 수십 배로 불어납니다. 검증은 창작을 느리게 만들지 않습니다. 오히려 검증이 없으면 창작이 더 느려집니다.

제조업에도 같은 교훈이 있어서, 도요타 생산 방식의 핵심 원칙 가운데 하나가 "이상이 발견되면 즉시 라인을 멈춘다"입니다. 불량품을 계속 만들어 내는 라인을 멈추지 않는 편이 더 빨라 보이지만, 그 불량품을 나중에 수거해 폐기하거나 수리하는 비용이 훨씬 크다는 것을 알았기 때문입니다. 라이브러링의 검증 3단계는 이 원칙을 창작 과정에 옮겨 온 것으로, 각 단계가 서로 다른 층위의 문제를 서로 다른 비용으로 잡아냅니다.

검증이 창작을 지키는 두 사례

검증을 가장 큰 규모로 운영하는 공개 창작물이 위키피디아입니다. 위키피디아에는 핵심 콘텐츠 정책 세 가지가 있고 그중 하나가 검증가능성으로, 의심받을 만한 서술과 인용에는 신뢰할 수 있는 출처가 붙어야 한다는 원칙입니다. 이 원칙을 어긴 편집은 되돌리기(revert)로 이전 상태로 복원되고, 같은 문서를 두고 편집이 충돌하면 편집 분쟁으로 보아 분쟁 해결 게시판이나 의견 요청(RfC) 같은 절차로 합의를 찾습니다. 저는 이런 장치들을 창작을 막는 규제가 아니라 창작을 지키는 장치로 읽습니다. 출처 없는 서술이 그대로 쌓이면 무엇이 사실인지 아무도 분간하지 못하게 되고 결국 백과사전 전체를 믿을 수 없게 되는데, 검증가능성과 되돌리기가 바로 그 붕괴를 막습니다. 라이브러링의 자동 단이 끊어진 링크와 중복 표제어를 잡아내는 일은, 위키피디아가 출처 없는 편집을 되돌리는 일과 같은 역할을 합니다.

게임 분야에도 비슷한 사례가 있습니다. 규모가 큰 게임은 출시 전에 QA(품질 보증)가 회귀 테스트를 돌리는데, 새 기능을 넣는 과정에서 이미 작동하던 부분이 망가지지 않았는지를 다시 확인하는 작업입니다. 출시 뒤에는 패치 노트로 무엇이 어떻게 바뀌었는지를 공개하고, 이 두 가지가 게임이라는 거대한 세계의 정합성을 지킵니다. 라이브러링도 다르지 않습니다. 3차 골격 빌드나 4차 집필을 다시 돌린 뒤 자동 단을 재실행해 새 문제가 생기지 않았는지를 확인하는 일이 회귀 테스트에 해당하고, 검증 상태를 Vault 인덱스에 한 줄로 기록하는 일이 패치 노트에 해당합니다.

이슈 우선순위, P0·P1·P2

검증에서 발견된 이슈는 세 등급으로 분류하는데, 이렇게 등급을 나누면 모든 문제를 똑같은 비중으로 처리하느라 낭비하는 일을 막을 수 있습니다.

P0는 Vault의 사용 가능성에 직접 영향을 주거나 표제어 동일성을 훼손하는 이슈로, 발견 즉시 수정합니다. 같은 인물이 두 표제어로 중복 등록된 경우, hub 표제어에서 끊어진 링크가 발생한 경우, frontmatter YAML 파싱이 실패하는 파일, 세계관축 허용값에 없는 값이 들어간 경우가 여기에 해당하며, 모두 Vault 자체가 오작동하는 수준입니다. 가령 frontmatter YAML 파싱이 실패하는 파일이 하나 있다면 그 파일을 읽으려는 출구 작업이 오류를 내는데, 그 오류가 어디서 비롯되었는지 추적하는 데에는 시간이 걸립니다. 처음 발견했을 때라면 3분이면 고칠 것을, 나중에 추적하면 30분이 걸릴 수 있습니다.

추적성이나 참조 무결성이 손상된 이슈는 P1로 분류해 핸드오프 전에 수정합니다. related 필드의 링크가 실재하지 않는 파일을 가리키는 경우, manifest의 표제어 수와 실제 파일 수가 일치하지 않는 경우가 여기에 해당하는데, Vault 자체는 작동하지만 추적성을 해치는 문제들입니다.

P2는 구조적 개선이나 후속 보강에 해당하며 다음 사이클로 이월할 수 있습니다. leaf 표제어의 서술이 기준 분량에 조금 미달하는 경우, %% LLM %% 블록이 채워지지 않은 표제어가 전체의 5% 이하인 경우가 여기에 해당하고, Vault 사용에는 지장이 없는 이슈들입니다.

무엇을 지금 고쳐야 하고 무엇을 나중으로 미룰 수 있는지를 의식적으로 결정하는 것, 이것이 이슈 등급 분류의 핵심입니다.

1단계: 자동 단, 기계가 잡을 수 있는 것을 기계가 잡는다

자동 단은 스크립트나 자동화 도구로 점검할 수 있는 무결성 항목을 확인하는 단계로, 사람의 판단 없이 통과와 실패가 결정됩니다.

소프트웨어 개발의 단위 테스트(unit test)와 비슷합니다. 함수 하나가 예상대로 작동하는지를 자동으로 확인하고 테스트가 실패하면 바로 그 지점이 문제이므로, 사람이 눈으로 코드를 전부 읽는 것보다 훨씬 빠르고 정확합니다.

라이브러링의 자동 단은 파이프라인 단계마다 점검 항목을 둡니다. 1차 완료 점검은 작업계획서 체크박스가 100% 완료되었는지, 입력 문서가 고르게 커버되었는지, 9분류가 모두 1건 이상 포함되었는지를 봅니다. 사물 분류가 비정상적으로 비어 있다면 국자나 솥 같은 소품을 통째로 놓쳤다는 신호일 수 있습니다. 2차 완료 점검은 대표키워드 중복 0건, 영문명 누락 0건, 끊어진 wikilink 0건, 버전상태 "미정"이 전체의 5% 이하, 세계관축 "미정"이 전체의 10% 이하, 세계관축 허용값을 벗어난 값 0건을 봅니다. 3차 완료 점검은 .md 파일 수와 2차 CSV 행 수의 일치, frontmatter YAML 파싱 실패 0건, 파일명 충돌 0건, worldbuilding_axis 누락 0건을 봅니다. 4차 완료 점검은 LLM 서술 완성률 95% 이상, 내용 비율(서식 대비 본문) 60% 이상, hub 표제어 4문단 이상, leaf 표제어 1문단 이상, category별 구조화 섹션 존재, 자기 자신을 가리키는 링크 0건, manifest의 진행률과 실제 파일 상태의 일치를 봅니다.

이 항목들은 자동화로 거의 즉시 확인되며, 실패가 나오면 P0 또는 P1 이슈로 등록해 곧바로 처리합니다. 자동 단의 가치는 두 가지입니다. 첫째, 사람이 읽어야 비로소 발견되는 것이 아니라 기계가 즉시 찾아냅니다. 둘째, 3차 골격 빌드나 4차 집필을 다시 실행한 뒤에도 같은 항목들을 다시 확인할 수 있어서, 재빌드 후 자동 단을 실행하면 새 문제가 생겼는지를 즉시 알 수 있습니다.

2단계: 수동 샘플 단, 의미와 판단이 필요한 검수

자동 단은 구조적 무결성을 잡아냅니다. 그러나 "이 동의어 묶음이 정말 같은 인물인가"처럼 의미와 판단이 필요한 항목은 자동화로 처리할 수 없습니다. 수동 샘플 단이 바로 이런 항목들을 점검합니다.

표본 추출의 원리가 여기에 들어맞습니다. 공장 제품 1,000개를 전부 검사하지 않고 일부를 무작위로 골라 검사하면, 전체 상태를 가늠하는 실무적 신호를 낮은 비용으로 얻을 수 있습니다. 수동 샘플 단은 이 원리를 적용해서, 1,500개의 표제어를 사람이 모두 읽는 대신 무작위로 추출한 표본을 꼼꼼히 검수하고 전체 품질의 위험 신호를 찾습니다.

그래서 수동 샘플 단의 원칙은 전수 검수가 아니라, 분류마다 1~2개를 무작위로 추출해 직접 읽는 것입니다. 확인하는 항목은 네 가지입니다.

통합 판단의 적절성은 무작위로 고른 표제어 5개의 이칭과 별칭이 정말 같은 대상을 가리키는지, 서로 다른 인물이 같은 표제어로 묶인 경우는 없는지를 봅니다. 2차 통합에서 AI가 잘못 판단한 내용이 Vault까지 내려온 경우로, 자동화로는 잡히지 않고 사람이 직접 읽어야 발견할 수 있습니다.

4차 서술의 톤 일관성은 hub 표제어 1개와 같은 분류의 중간 표제어 5개를 비교해, hub에서 확립된 핵심 프레이밍이 다른 표제어에서도 같은 방식으로 작동하는지를 봅니다. 배치마다 AI 인스턴스가 달랐던 탓에 배치 경계에서 톤이 갑자기 바뀌는 경우가 있습니다.

세계관축 분류의 적절성은 각 세계관축에서 표제어 5개를 무작위로 골라 정말 그 축에 속하는지를 봅니다. "천명" 축으로 분류된 표제어 가운데 실제로는 "사건" 분류에 더 가까운 것이 섞여 있을 수 있습니다.

구조화 섹션의 정확성은 장치 표제어의 "제약 조건" 섹션이 실제 출처를 가리키는지를 봅니다. AI가 출처 없는 추측을 제약 조건으로 적었다면 P1 이슈입니다.

이 수동 단은 30분에서 1시간이 걸리는 작업이고, 발견된 이슈는 P1 또는 P2로 등록합니다. 표본에서 심각한 이슈가 발견되면 그 이슈가 속한 분류 전체를 더 폭넓게 검수합니다. 표본이 경고 신호를 보내면 전체를 더 살펴보는 것입니다.

3단계: 통합 빌드 단, 실제로 사용될 때 제대로 작동하는가

세 번째 단계는 가장 높은 층위의 검증입니다. 자동 단이 파일 하나하나의 무결성을 살피고 수동 샘플 단이 의미의 정확성을 살폈다면, 통합 빌드 단은 이 Vault가 실제로 사용될 때 어떤 경험을 주는지를 살핍니다. 소프트웨어에 비유하면 사용자 수용 테스트(User Acceptance Test, UAT)에 해당하는데, 단위 테스트와 통합 테스트를 모두 통과한 소프트웨어라도 실제 사용자가 써 보면 예상치 못한 문제가 드러날 수 있기 때문입니다.

통합 빌드 단에서 하는 일은 세 가지입니다.

hub 표제어 한 개를 처음부터 끝까지 따라갑니다. hub 표제어 하나를 펼쳐 frontmatter, 정의, 상세설명, LLM 서술, related, backlinks(이 표제어를 가리키는 다른 표제어들)를 순서대로 짚어 갑니다. 이 순서로 따라가면서 정보가 충분한지, 링크가 제대로 연결되는지, 서술이 IP의 질문에 답하는지를 봅니다. 「우사부」의 "기우제" 표제어를 따라가다가 "이 의례를 지낸 인물이 나중에 어떻게 되는지"를 알고 싶은데 그 정보로 이어지는 링크가 없다면 P2 이슈입니다. 지금 당장 Vault가 멈추는 것은 아니지만, 이 표제어에서 연결되어야 할 링크가 빠진 것입니다.

가상 단편 한 편을 시뮬레이션합니다. Vault만 보고 짧은 단편을 쓰려 할 때 어디서 막히는지를 봅니다. 막히는 부분이 바로 자료 보강이 필요한 곳입니다. "기우제"를 처음 올리는 인물의 장면을 쓰려는데 이 의례를 어디서 지내는지에 대한 정보가 Vault에 없다면, 장소 관련 표제어나 기우제 서술에 그 정보를 보강해야 합니다. 이런 이슈는 P2로 등록합니다.

신규 사용자 시뮬레이션을 합니다. Vault를 처음 보는 사람이 인덱스에서 핵심 표제어로, 다시 그 표제어에서 관련 표제어로 이동하면서 30분 안에 IP의 세계관을 파악할 수 있는지를 봅니다. 이 시뮬레이션이 중요한 이유는, IP를 오래 만들어 온 제작자는 Vault의 내용을 이미 알고 있어 빠진 정보가 있어도 자신의 기억으로 채우지만 신규 사용자는 그렇게 할 수 없기 때문입니다. 신규 편집자나 번역자가 합류했을 때 Vault만 보고도 IP를 파악할 수 있어야 합니다. 통합 빌드 단의 신규 사용자 시뮬레이션이 바로 이 준비 상태를 확인합니다.

이 통합 빌드 단은 1~2시간이 걸리는 작업입니다. 발견된 이슈는 P2로 등록하고, 인덱스와 hub 표제어, 보조 문서의 보강 계획으로 이어집니다.

핸드오프 합격 체크박스

세 단계 검증이 끝나면 핸드오프 합격 체크박스를 확인합니다. 다음 항목들이 모두 통과되어야 Vault를 출구 작업으로 넘길 수 있습니다.

필수 항목은 하나라도 통과하지 못하면 핸드오프를 보류합니다. 자동 단 전 항목 통과, 4차 위임 후 검수 5단계 모두 통과, manifest의 "핸드오프 준비 완료" 표시, 모든 P0 이슈 즉시 수정 완료, 모든 P1 이슈 수정 완료 또는 명시적 이월 결정, 프로파일과 세계관축 카탈로그와 보조 문서 카탈로그의 첨부가 필수 항목입니다. 권장 항목은 1건까지는 미통과를 허용합니다. 수동 샘플 단 통과, 통합 빌드 단에서 자료만으로 정보가 충분함, 보조 문서가 카탈로그대로 산출됨, hub 표제어가 직접 작성됨이 권장 항목입니다.

이 체크박스가 완성되면 검증 상태를 Vault의 인덱스 파일에 한 줄로 기록합니다. 누가 Vault를 처음 보더라도 이 Vault가 어떤 상태인지를 즉시 확인할 수 있게 하기 위해서입니다.

합격선 체계, 단계별 기준이 다른 이유

파이프라인 단계마다 합격선이 다릅니다. 1차는 "가능한 한 많이 모으기"가 목표이므로 60%만 모아도 다음 단계로 넘어갈 수 있습니다. 2차는 통합과 정제의 단계여서 대부분의 표제어가 13컬럼을 채워 95%에 이르러야 하고, 나머지 5%는 "미정" 상태로 남겨 두어도 됩니다. 3차는 결정적 자동화 단계이므로 파일 하나도 오류 없이 생성되어야 하는 100%입니다. 4차는 hub와 leaf의 분량 기준이 다르지만, 운영용 Vault 전체로는 LLM 서술 완성률 95% 이상을 요구합니다. leaf 표제어가 짧아도 되는 것이지, 대량으로 비어 있어도 된다는 뜻은 아닙니다. 남은 미작성분은 전체 5% 이하의 P2 이슈로 명시하고 다음 사이클 보강 계획에 올려야 합니다.

이 합격선 체계가 있으면 어디에서 완벽을 추구하고 어디에서 적당히 넘어가도 되는지가 명확해집니다. 1차에서 100%를 추구하면 시간 낭비이고 3차에서 99%만 달성하면 문제인 것처럼, 단계마다 기준이 다른 데에는 그만한 이유가 있습니다.

검증을 마치고 핸드오프로

이 세 단계를 통과한 Vault는 출구 작업으로 핸드오프될 준비를 갖춘 것입니다. 그런데 핸드오프를 마치고 나면 Vault는 거기서 멈추는가 하는 질문이 남습니다. 그렇지 않습니다. Vault는 IP와 함께 계속 살아 움직입니다.

새로운 IP 콘텐츠가 발표될 때 Vault가 어떻게 업데이트되는지, 새로운 표제어가 어떻게 역류하는지, IP가 살아 있는 한 Vault도 함께 살아 움직이는 운영 사이클을 11장에서 살펴봅니다.