한 절씩 맞추는 일에서, 맞출 수 없는 것까지 보존하는 시스템으로-박윤선주석 2,111개 원문을 정렬·분류·분할·검증한 전체 작업 기록

📝 한줄 요약

이 사례는 로마서 한 파일을 고친 이야기도, 마지막 NULL 큐의 숫자 두 개를 맞춘 이야기도 아니다. 박윤선주석 로컬 corpus의 2,111개 Markdown 원문을 대상으로, 주석 문장을 성경 절·절 범위와 연결하고, 장별 강해·혼합 도서·다중 앵커·손상·출처 불명 자료를 구분하며, 안전하게 확정할 수 없는 부분은 NULL과 HOLD로 보존한 전체 정렬 작업의 기록이다.

바쁘시면 이것만 읽어도 됩니다.

• 시작점은 “주석 문장을 해당 성경 절에 연결하자”였지만, 실제 문제는 문장보다 원문 구조가 복잡하다는 데 있었다.

• 한 파일 안에 여러 장이 섞이거나, 장 제목은 있지만 절 범위가 없거나, 다른 도서 본문이 끼어들거나, 번역문·숙제·부록이 이어지는 경우가 많았다.

• 그래서 파일명을 보고 절을 추정하지 않고, 물리적 heading·명시 범위·본문 경계·LEB 본문·원문 byte를 함께 대조했다.

• 안전한 경우에는 whole-chapter coverage, bounded alignment, exact segmentation, whole-row reclassification을 적용했다.

• 안전하지 않은 경우에는 억지로 절을 부여하지 않고 residual·typed residual·HOLD·restored-unclassified로 남겼다.

• 각 적용은 시험 shadow에서 먼저 검증하고, pinned 입력에서 전체본을 다시 만들고, exact reassembly·audit·FTS·무결성·보호 파일 해시를 다시 확인하는 방식으로 진행했다.

• 실패는 숨기지 않았다. 잘못된 장 귀속, 외국 도서 본문 혼입, provenance ledger 누락, 경로 오판, roundtrip 방식 오류, stale 보고서 숫자를 각각 FAIL로 보존하고 원인에 맞게 수리했다.

• commentary_v50.db 이후 수많은 shadow를 거쳐 최종 commentary_v119.db에 도달했고, 최신 기준은 13,442 chunks/FTS, 1,398 alignment, 954 segmentation, 86 coverage, 62 reclassification이다.

• 최종 NULL은 197 chunks / 156 files이며, 이것은 작업 실패의 숫자가 아니라 현 정책과 증거로 더 이상 안전하게 자동 승격하지 않기로 한 보존 결과다.

• 마지막 독립 검토는 회귀 테스트 추가 후 현행 기준 372/372 PASS로 완료됐다.

🎯 이 글이 다루는 범위

이전 사례게시글은 v119 NULL 정책 큐의 nested 36/76 stale 집계를 37/78로 교정한 마지막 사건에 집중했다. 그 글만 읽으면 마치 이번 작업이 보고서 안의 숫자 두 개를 고치는 짧은 QA 작업이었던 것처럼 보일 수 있다.

실제로는 다음 작업들이 하나의 연속된 운영이었다.

원문 corpus 확인
→ 단일 절·절 범위 정렬 종료
→ 오분류 재분류
→ 장 전체 coverage
→ 다중 앵커·혼합 파일 segmentation
→ residual·HOLD 정책화
→ 수동 bounded repair
→ provenance ledger 보강
→ shadow DB 재생성
→ 독립 적대 검토
→ 최종 NULL 정책 큐 확정

이 글은 마지막 오류만이 아니라, 이 전체 흐름을 하나의 사례로 다시 엮는다.

문제는 “절을 찾는 것”보다 “절을 찾지 말아야 할 때를 아는 것”이었다

주석 corpus를 검색 가능한 지식 기반으로 만들려면 각 조각이 어느 성경 본문을 설명하는지 알아야 한다. 가장 단순한 형태는 다음과 같다.

원문 주석
→ 성경 책
→ 장
→ 절 또는 절 범위
→ 검색 가능한 passage

하지만 실제 자료는 교과서처럼 정돈되어 있지 않았다.

• 한 파일에 여러 장의 설교가 붙어 있었다.

• 장 제목은 있지만 절 제목이 없었다.

• 잠4절-5절과 잠21-22절처럼 표기가 일정하지 않았다.

• 1:8,9처럼 연속 절이 아닌 표기가 섞였다.

• 장별 강해와 선택 연구가 같은 파일에 함께 있었다.

• 다음 장 과제나 편집자의 질문이 본문 뒤에 붙어 있었다.

• 다른 성경 책의 heading과 본문이 한 청크 안에서 충돌했다.

• OCR·변환·번역 잔재가 원문에 이미 존재했다.

• 파일명과 실제 본문 책이 서로 달랐다.

• 한 줄로 이어진 자료에서는 줄바꿈 자체가 경계 정보가 되지 못했다.

따라서 파일명, 주제, 인접 파일, 익숙한 성경 순서만으로 절을 추정하면 검색 결과는 그럴듯해도 근거가 없는 귀속이 된다. 이 작업의 첫 원칙은 다음과 같았다.

원문이 말하지 않은 절은, AI가 알고 있더라도 넣지 않는다.

시작 조건과 목표

작업은 이미 구축된 local corpus와 누적 shadow DB를 기반으로 진행됐다. 정본과 원문은 직접 덮어쓰지 않고, 각 단계의 입력 shadow에서 새 shadow를 생성했다.

목표는 모든 조각에 억지로 좌표를 부여하는 것이 아니었다. 목표는 세 가지였다.

1. 안전하게 확정할 수 있는 조각은 검색 가능한 passage로 만든다.

2. 확정할 수 없는 조각은 이유와 provenance를 가진 보류 상태로 남긴다.

3. 다음 사람이 같은 입력과 같은 규칙으로 결과를 재현할 수 있게 한다.

전체 작업의 구조

전체 작업은 크게 네 층으로 나뉘었다.

[1] Alignment
    이미 있는 주석과 성경 절의 관계를 확인

[2] Coverage
    절 단위가 아닌 장 전체·비완전 강해의 reviewed 범위를 기록

[3] Segmentation / Reclassification
    한 청크를 안전한 passage와 residual로 분리하거나
    잘못된 책·좌표를 감사 가능한 방식으로 교정

[4] Policy Queue
    아직 자동으로 처리하지 않은 잔여를 상호배타 버킷과 provenance로 관리

이 네 층을 섞지 않는 것이 중요했다. 예를 들어 장 전체를 설명하는 강의를 절별 주해라고 주장하지 않았고, 책명이 틀린 원문을 조용히 다른 책으로 이동하지 않았으며, segmentation을 했다고 해서 모든 residual을 accepted로 바꾸지 않았다.

1단계: 단일 절 정렬의 종료와 기준선 만들기

초기 단계의 질문은 “어느 도서에 명시적인 단일 절 또는 동일 장 절 범위가 남아 있는가”였다. 이 축을 먼저 닫아야 이후의 다중 장·혼합·손상 자료를 별도 문제로 분리할 수 있었다.

유다서 정렬 종료 검증에서는 실제 LEB 본문을 회수해 절 범위와 원문 주제를 대조했고, SQLite 무결성·FTS 수·audit 증가·원문 byte round-trip을 확인했다. 그 결과 단일 범위 자동 정렬의 종료 조건을 만들 수 있었다.

이 단계에서 얻은 중요한 결론은 “검색 결과가 0이면 자료가 없다”가 아니었다.

• 전용 단일 범위 정렬 후보가 0이라는 뜻일 수 있다.

• 장 전체 연구나 다중 앵커 자료는 별도 coverage·segmentation 축으로 넘어가야 한다.

• 손상·혼합·출처 불명 자료는 자동 축의 실패가 아니라 다른 작업 유형이다.

즉, 완료는 전체 원문이 완성됐다는 뜻이 아니라 현재 작업 축에 더 이상 안전한 후보가 없다는 뜻으로 정의됐다.

2단계: 오분류를 조용히 고치지 않고 재분류 audit으로 남기기

초기 보류 큐에는 나훔 라벨 아래에 실제로는 민수기 본문인 자료 36개가 있었다. 이 문제를 파일 이동이나 DB 직접 수정으로 처리하지 않았다.

대표 4건을 먼저 시험 shadow에 적용했다. 무결성·FTS·provenance·대상 외 불변성을 확인한 뒤 전체 36건을 새 shadow에 적용했다.

나훔 라벨 아래 미분류 36개 → 0개
민수기 구조화 대상       → 36개
전체 미분류 파일         315 → 279
review 큐                256 → 220

각 행에는 다음 정보를 남겼다.

• 이전 책과 이후 책

• 이전·이후 좌표

• chunk ID

• 원본 SHA

• 입력 shadow SHA

• 재분류 근거

이것이 reclassification_audit이다. 결과만 “민수기로 고쳤다”고 쓰는 것과, “어떤 근거로 어느 행을 어디에서 어디로 옮겼는지 다시 확인할 수 있다”고 쓰는 것은 다르다.

3단계: 장 전체 coverage는 절별 주해와 구분하기

장별 설교나 연구 자료를 절별 주해처럼 쪼개는 것은 오히려 의미를 왜곡할 수 있다. 그래서 절 단위로 안전하게 나눌 수 없는 자료에는 whole_chapter_summary_coverage 또는 non_exhaustive_reviewed 같은 별도 method를 사용했다.

열왕기하

열왕기하 21–25장 요약 5건은 Logos LEB 본문과 실제 장 정체성을 대조한 뒤 reviewed whole-chapter coverage로 기록했다. 기존 alignment audit prefix는 그대로 보존했고 coverage audit을 별도로 추가했다.

레위기

레위기 13장과 15장은 장 제목과 하위 범위가 명시되어 있었지만, 원문 청크를 임의로 쪼개지 않고 장 전체 coverage로 기록했다. 불연속 범위를 연속 절 주해로 둔갑시키지 않는 것이 우선이었다.

느헤미야·요나·아모스·빌립보서·고린도서·데살로니가서·디도서·빌레몬서·요한복음

이 자료들에서는 장 전체를 다루는 설교·연구·워크북을 장 scope로 검토했다. 다만 다음 조건을 구분했다.

• exhaustive verse commentary인지

• 장을 중심으로 한 non-exhaustive study인지

• 파일명과 실제 본문 장이 충돌하는지

• 다음 장 과제나 편집 종결문이 포함되는지

• 장 내부의 교차 인용이 새 boundary인지

예를 들어 느헤미야 자료 중 하나는 파일명 suffix와 실제 본문 흐름이 달랐다. 이를 파일명대로 처리하지 않고 filename_mismatch_reviewed method로 8장에 귀속했다.

4단계: 다중 앵커와 혼합 파일을 분할하되 residual을 남기기

장 전체 coverage만으로도 검색성이 개선되지 않는 자료는 segmentation 대상으로 넘겼다. 이때 적용 원칙은 다음과 같다.

물리적 heading 또는 명시 범위
→ candidate boundary
→ 실제 성경 본문 상한 대조
→ trial segmentation
→ raw/DB exact reassembly
→ accepted와 residual 분리

잠언 24–31장

잠언 자료는 한 줄 > > 블록, 계층형 표제, 개요 질문, 상위 section, 부록이 복잡하게 섞여 있었다. 그래서 다음을 구분했다.

• 명시적인 질문·절 범위는 accepted passage

• 서론과 전권 개요는 residual

• 상위 제목은 하위 질문과 중복 승인하지 않음

• 원문에 표제가 없는 절은 추정하지 않음

• 잠2절3절 같은 비정규 표기는 본문 근거가 있을 때만 승인

잠언 27·28장은 한 파일 안에서 두 장이 공백 없이 결합된 혼합 파일이었다. 원본 byte offset과 DB character offset을 장 경계로 고정하고, 두 장의 accepted segment와 residual을 분리했다. applicator가 전역 장 번호를 기록하는 결함도 이 과정에서 실패 테스트로 재현해 segment별 장 번호를 기록하도록 수정했다.

시편 67–88편

시편에서는 편:절, 편;절, 하이픈 범위, 쉼표 나열, terminal scripture quote와 commentary heading을 구분해야 했다. 누락 절을 보간하지 않았고, quote와 다음 commentary를 자동 병합하지 않았다.

대체 번역문, 칼빈 사역 번역, 무표제 tail, duplicate와 unique tail은 각각 residual 종류로 보존했다. 이것은 “분할을 많이 했다”보다 중요한 결과다. 분할 가능한 것과 분할하면 안 되는 것을 함께 분리했기 때문이다.

호세아·요한계시록·고린도서·갈라디아서·골로새서·야고보서

이후에는 도서별 parser와 일반화된 applicator를 추가했다. line-start 약칭과 명시 범위만 경계로 사용했고, 다장 범위·물리행 중간 강해 전환·외국 도서 본문 혼입은 typed residual로 남겼다.

특히 요한계시록 합본과 21:22–22:5 자료는 top-level chapter/session 경계를 기준으로 분할했다. 장 안의 제N장 문구를 새로운 경계로 중복 사용하지 않았고, 계 8·9·11·12처럼 non-exhaustive 범위는 그 사실을 method에 남겼다.

5단계: 안전한 적용은 trial과 full regeneration을 분리하기

모든 적용은 한 번에 정본에 쓰지 않았다. 공통 절차는 다음과 같았다.

pinned input shadow
        │
        ├─ disposable trial
        │    대표 사례·경계·실패 조건 확인
        │
        ├─ 실패 시 폐기·수정
        │
        └─ input shadow에서 full regeneration
             전체 DB·audit·FTS·reassembly 검증

반복해서 확인한 검증 항목

• SQLite integrity_check

• chunks/FTS parity

• alignment audit prefix

• segmentation audit exact content

• coverage/reclassification audit exact content

• segment별 offset과 source membership

• raw byte 또는 DB text exact reassembly

• LEB 본문 최대 절 범위

• 대상 외 chunk 불변성

• input/canonical DB SHA·size·mtime

• MD_교정/ 원문 tree fingerprint

• 회귀 테스트와 전체 discovery

이 구조의 장점은 실패가 생겼을 때 전체를 되돌리지 않아도 된다는 점이다. 실패한 책임 단위만 폐기하고 pinned 입력에서 다시 만들 수 있다.

6단계: 실제로 있었던 FAIL과 수리

이 프로젝트의 중요한 부분은 PASS 목록이 아니라 FAIL을 어떻게 다뤘는가에 있다.

JN10·JN15 whole-chapter coverage와 BS10-9

첫 후보 v97은 디도서 BS10-9의 전권 개요 residual을 다른 장에 흡수해 독립 검토 FAIL을 받았다. 실패본은 승격하지 않고 rejected-* 증거로 격리했다.

수정된 v97에서는 BS10-9를 완전히 NULL로 복원했다. 그 다음 JN10·JN15만 다시 생성했고, audit exact content와 FTS 전수 parity를 독립 검토했다.

요한복음 JN04

다음 v98은 JN04에 요한복음 4:54를 포함할 근거가 부족해 FAIL했다. 이 역시 실패본을 승격하지 않고 JN04를 fully-NULL hold로 되돌렸다.

그 뒤 명시된 경계만 사용해 JN01, BS10-9, JN04를 bounded segmentation으로 다시 만들었다. JN04는 4:1–53으로 제한했고, 4:54를 추정하지 않았다.

에베소서 EBS의 디모데전서 혼입

v104에서는 EBS 한 구간에 디모데전서 본문이 inline으로 섞여 있었는데도 에베소서 4:1–12로 승인하는 오류가 발생했다. 독립 검토가 이를 FAIL으로 판정했고, 해당 구간 전체를 residual_truncated_scope_with_inline_foreign_book으로 격리했다.

수정 v104는 foreign-book 혼입을 accepted로 숨기지 않고 residual로 보존했다. 이 사건은 “문장이 에베소서처럼 보인다”가 “해당 장으로 승인할 수 있다”와 다르다는 것을 보여 준다.

Romans overview provenance

Romans overview chunk 12592에 non-ratifying provenance ledger를 추가했지만, 최초 recomputer가 새 ledger를 읽지 않아 독립 검토 FAIL이 발생했다. ledger를 생성하는 것만으로는 충분하지 않았다. 실제 queue builder가 그 ledger를 소비하는지까지 검증해야 했다.

recomputer에 exact lookup을 추가한 뒤 source-only가 0으로 내려갔고, non-ratifying 1건은 좌표 승인이 아니라 historical replay로 남았다.

v116 basis provenance

v116의 첫 독립 검토는 partition·provenance·재현성·불변성을 통과했지만, basis 목록에서 v114/v115 merge report SHA 두 개가 빠져 FAIL했다. 데이터 결과가 맞아도 검증 입력 목록이 불완전하면 승격하지 않았다.

두 SHA를 basis에 추가하고 14/14 입력 해시를 다시 대조한 뒤에야 PASS했다.

v117 경로 검토

v117의 첫 검토는 무관한 LLM-Wiki 경로를 조회해 path-invalid FAIL이 되었다. 절대 경로로 재검토해 실제 대상과 입력을 맞춘 뒤 PASS했다.

이 사건은 독립 검토의 “독립성”만큼이나 정확한 대상 경로가 중요하다는 것을 보여 준다.

v119 roundtrip과 nested stale count

Romans DATA를 세 조각으로 나누는 과정에서는 pre-copy roundtrip 방식이 틀려 먼저 FAIL했다. CRLF→LF와 terminal LF 제거 규칙을 명시한 뒤 exact reassembly를 통과시켰다.

그 다음 NULL 큐를 재산출하면서 top-level summary와 상세는 37/78인데 nested audit_residual만 36/76인 stale 표시값이 발견됐다. nested 숫자를 summary에서 파생하도록 고치고, 같은 문제를 고정하는 회귀 테스트를 추가했다.

회귀 테스트가 1건 늘어 전체 테스트 수가 371→372가 됐다. 중간 독립 검토는 오래된 371 기대값 때문에 절차적 FAIL을 반환했지만, 새 안전장치를 삭제하지 않고 기준을 372로 갱신한 뒤 재검토해 최종 PASS했다.

7단계: 자동 축을 닫고 NULL 정책 큐로 넘어가기

v107 시점에는 segmentation·bounded alignment·whole-row reclassification의 자동 안전 후보가 0개가 됐다. 이때 작업을 끝내는 대신, 남은 NULL을 정책 큐로 재구성했다.

큐의 목적은 다음과 같다.

• 남은 보류를 정확히 세기

• 서로 다른 이유의 보류를 섞지 않기

• 이미 처리한 항목이 다시 후보로 나타나지 않게 하기

• 원문과 DB를 건드리지 않고 다음 정책 결정을 준비하기

• 승인 권한이 없는 작업을 자동으로 실행하지 않기

v108–v119 주요 변화

이 표에서 중요한 것은 NULL이 항상 줄어들지 않는다는 점이다. 안전한 하나의 accepted segment를 만들면서 나머지 경계를 residual로 분리하면 NULL chunk 수가 늘 수 있다. 그것은 실패가 아니라, 한 덩어리의 불확실성을 더 정직한 단위로 분해한 결과다.

8단계: 최종 v119에서 실제로 무엇이 바뀌었나

Romans DATA parent chunk는 다음 세 조각으로 lossless 분할됐다.

1. whole-book introduction residual [0,3257)
2. Romans 1:1–17 accepted        [3257,5278)
3. cross-chapter tail residual    [5278,41730)

raw mapping은 [0,7514), [7514,12226), [12226,96554)이며 CRLF→LF 후 terminal LF 하나를 제거하는 규칙으로 exact reassembly됐다.

이 적용은 다음을 바꾸지 않았다.

• Genesis와 KCM066 HOLD

• non-target chunks

• 기존 다른 audit

• canonical/protected fingerprints

• 원문 Markdown

• 정본 DB

최종 shadow의 구조 지표는 다음과 같다.

9단계: 최종 NULL 큐는 무엇을 의미하나

최종 큐는 다음처럼 상호배타적으로 분할된다.

이 중 audit_residual은 “감사 기록이 전혀 없는 실패 데이터”가 아니다. 77개는 exact segmentation provenance가 있고, 1개는 non-ratifying historical replay provenance가 있다. 좌표 승인이 없는 1건을 exact accepted와 섞지 않았다는 점이 중요하다.

남은 91개 valid-commentary HOLD도 “주석이 아니다”라는 뜻이 아니다. 주석일 가능성이 있어도 지금 가지고 있는 근거만으로 안전한 장·절 경계를 만들 수 없다는 뜻이다.

따라서 최종 결론은 다음과 같다.

모든 주석을 절에 억지로 배치한 것이 아니라, 배치할 수 있는 것은 배치하고 배치할 수 없는 것은 이유 있는 보류 상태로 남겼다.

10단계: 전체 작업에서 지켜진 불변성

이 작업의 성과를 accepted 개수만으로 평가하면 핵심을 놓치게 된다. 같은 중요도로 지켜진 것은 무엇을 바꾸지 않았는가이다.

• 원문 Markdown 2,111개를 직접 수정하지 않았다.

• 정본 commentary.db를 덮어쓰지 않았다.

• 각 shadow는 pinned 입력에서 새로 생성했다.

• 실패한 shadow는 승격하지 않고 격리했다.

• source·input·canonical DB의 SHA·size·mtime을 대조했다.

• audit는 append-only 성격으로 보존했다.

• raw/DB text를 exact reassembly로 확인했다.

• FTS parity와 SQLite integrity를 매 단계 확인했다.

• 원문에 없는 절·장·책을 추정하지 않았다.

• 외부 공개 본문과 연구용 원문을 분리했다.

이 작업이 신학 연구에 주는 의미

이 사례는 새로운 교리 해석을 제시하는 글이 아니다. 박윤선주석의 문장을 어느 성경 본문과 연결할지에 대한 자료 정렬·불확실성 관리·검증 운영의 사례다.

하지만 이 전처리는 해석의 질과 무관하지 않다. 주석 조각이 잘못된 장이나 절에 붙으면, 검색자는 그 주석을 실제로 해당 본문을 설명하는 것처럼 읽게 된다. 반대로 경계가 불확실한 조각을 HOLD로 남기면, 당장 검색 결과가 줄어들더라도 다음 연구자는 확정된 것과 보류된 것을 구분할 수 있다.

이 작업은 다음과 같은 연구 습관을 제안한다.

1. 원문과 해석을 먼저 분리한다.

2. 출처가 말한 경계를 우선한다.

3. 본문에 없는 절을 인접 맥락으로 보간하지 않는다.

4. 장 전체 연구와 절별 주해를 같은 metadata로 부르지 않는다.

5. residual도 검색·검토 가능한 지식으로 보존한다.

6. PASS가 나오기 전까지 실패본을 정본처럼 사용하지 않는다.

7. 검토 기준이 오래되면 안전장치를 삭제하지 말고 기준을 갱신한다.

재사용 가능한 전체 운영 패턴

다른 주석·설교·강의 corpus에도 적용할 수 있는 순서는 다음과 같다.

1. 원문 파일과 정본·입력 DB의 역할을 고정한다.
2. 단일 절·절 범위 자동 축을 먼저 종료한다.
3. 오분류는 reclassification audit으로 교정한다.
4. 장 전체 자료는 coverage로, 분할 가능한 자료는 segmentation으로 분리한다.
5. 물리적 heading과 명시 범위만 경계 후보로 삼는다.
6. 누락 절과 혼합 범위는 추정하지 않고 residual로 남긴다.
7. trial shadow에서 경계·예외·실패를 검증한다.
8. pinned 입력에서 full shadow를 독립 재생성한다.
9. raw reassembly·audit·FTS·integrity·hash·mtime을 대조한다.
10. 실패본을 폐기·격리하고 수정 책임 단위만 다시 실행한다.
11. 남은 NULL을 상호배타 정책 큐로 만들고 authorized action을 분리한다.
12. 작성자와 다른 검토자가 read-only로 재검토한다.
13. 다음 후보가 없으면 0개를 정답으로 기록한다.

최종 검증과 한계

최종 v119 NULL 정책 큐는 다음 기준을 통과했다.

• 전체 NULL 197 chunks / 156 files의 exhaustive partition

• summary·nested·detail audit residual 37/78 일치

• provenance 77 exact + 1 non-ratifying + 0 source-only

• valid-commentary HOLD 91/91

• basis 입력 17개 SHA 일치

• DB integrity·quick check ok

• chunks/FTS 13,442/13,442

• 보호 대상 26개 snapshot 불변

• JSON·Markdown 두 번 byte-identical 재산출

• 회귀 테스트를 포함한 전체 372/372 PASS

• warnings fail-closed PASS

• 자동 allow-list []

• 현 정책상 다음 실행 가능 변경 후보 0

기준 해시

• commentary_v119.db: c044c90477eeeece03a6d852106750556e7194c80709e4b1295b0392ca5c0385

• NULL 큐 JSON: ab76914b667f9e96a47f1e8ccdf1306d8101ce0895dd0e916a78e5be61080d66

• NULL 큐 Markdown: 924a41139975ace5ef92928053872cb0262006bb539228d35326c5315b9ce667

이 글은 전체 작업을 설명하지만, 다음을 주장하지 않는다.

• 모든 주석의 신학적 의미가 확정됐다는 뜻이 아니다.

• 모든 원문이 절 단위로 검색 가능해졌다는 뜻이 아니다.

• HOLD 91개가 오류라는 뜻이 아니다.

• 좌표가 없는 residual을 미래에 영구적으로 처리할 수 없다는 뜻이 아니다.

• 외부 웹이나 공개 커뮤니티에 게시했다는 뜻이 아니다.

이 글이 말하는 것은 더 제한적이고 더 검증 가능하다.

현재 입력·현재 정책·현재 감사 기록으로 확정할 수 있는 것과 확정할 수 없는 것을 분리했고, 그 판단을 다시 실행할 수 있는 shadow와 audit을 남겼다.

마무리

처음 질문은 “주석을 성경 절에 연결할 수 있는가”였다. 작업이 끝날 무렵 질문은 달라졌다.

이 조각은 어느 절인가?
→ 이 조각을 그 절이라고 말할 근거가 있는가?
→ 그 근거가 원문·본문·audit에 남아 있는가?
→ 다른 검토자가 같은 입력으로 다시 확인할 수 있는가?
→ 확인할 수 없다면, 왜 보류됐는가?

좋은 정렬은 모든 빈칸을 채우는 일이 아니다. 빈칸을 빈칸으로 남길 때조차 그 이유와 출처와 다음 검토 조건을 잃지 않는 일이다.

박윤선주석 정렬 작업의 최종 성과는 13,442라는 chunk 수나 372/372라는 테스트 수만이 아니다. 가장 중요한 성과는, 자료가 말하지 않은 것을 말한 것처럼 만들지 않고도 검색 가능한 지식 기반을 확장했다는 데 있다.