하나의 게시물을 읽고 글 하나를 쓰는 동안에는 출처 주소만 있으면 충분해 보인다. K-POP PULSE에서는 영상과 공지, 일정이 같은 사건으로 모이고 한 자료에서 여러 글감이 나왔다. 원고 파일 하나에 모든 것을 넣으면 어떤 문장의 근거인지 다시 찾기가 어려웠다.
초기 설계 문서는 수집한 항목, 이슈의 묶음, 발행 글과 그 글이 사용한 출처를 구별했다. 나는 이 관계를 지금 DB의 복사본으로 소개하지 않는다. 당시 설계와 후속 편집 기록을 읽고, 자료와 판단과 문장의 수명을 나누는 이유를 다른 홈페이지에서도 사용할 수 있게 풀어 보려 한다.
새 자료가 들어왔다고 바로 새 글이 되는 것은 아니다
수집 항목은 무엇이 게시됐는지 담는다. 이슈는 여러 자료가 같은 사건을 설명하는지 편집자가 묶어 보는 단위다. 글은 그중 어떤 질문을 독자에게 설명할지 선택한 결과다. 이 셋은 연결되어 있지만 같은 상태를 가지고 움직이지 않는다.
한 사건에 영상과 날짜 공지가 들어오면 자료는 둘이고 이슈는 하나일 수 있다. 글도 짧은 소식과 날짜 표기를 설명하는 해설로 나뉠 수 있다. 이런 관계를 새 파일 이름 몇 개로만 해결하려 하면 중복인지 후속 설명인지 판단한 이유가 사라지기 쉽다.
자료의 보관과 글의 개정을 다른 일로 둔다
초기 문서에는 원본 수집 항목을 근거 단위로 보존하고, 글의 출처 연결에는 발행 시점에 사용한 자료를 남긴다는 방향이 있다. 이는 자료가 변하지 않는 저장 장치를 현재 검증했다는 뜻이 아니라 당시의 설계 의도다. 실제 보존 방식은 적용할 프로그램에서 따로 확인해야 한다.
내가 가져갈 기준은 문장을 고친다고 이미 읽었던 자료를 덮어쓰지 않는 것이다. 나중에 원문이 바뀌면 새로 읽은 자료의 시점과 이전 읽기를 구별한다. 그 뒤 문장을 고치면 어느 읽기를 기준으로 판단했는지도 함께 남긴다. 최신 주소만 열어서는 과거 문장의 이유가 보이지 않을 수 있다.
이슈에 연결한 자료를 전부 본문에 쓸 필요는 없다
글감을 판단할 때 읽은 자료와 실제 문장을 뒷받침한 자료는 범위가 다를 수 있다. 제목을 보고 보류한 후보, 같은 소식의 반복 게시물, 맥락을 살피기 위해 읽은 이전 공지를 모두 같은 출처로 달면 어느 문장을 검토해야 하는지 모호해진다.
나는 글의 개정마다 사용한 자료와 필요한 사실을 연결하는 방식을 검토한다. 여러 자료를 사용한 글이라면 날짜가 어느 공지에서 왔고 제목이 어느 게시물에서 왔는지 찾을 수 있어야 한다. 외부 출처가 진짜라는 확인과 그 자료가 특정 주장을 뒷받침한다는 확인도 따로 남긴다.
검증이 실패했을 때 관계가 원인을 좁힌다
10월 1일 작업에서는 설명란에 있는 연도가 사실표의 앞부분에 들어오지 않아 초안이 막혔다. 원고만 보았다면 연도를 지우는 수정으로 끝날 수 있었다. 원문과 저장한 근거, 그 근거를 만든 코드를 함께 읽어야 누락된 위치를 찾을 수 있었다.
원본·사실표·초안을 나누는 것은 저장 공간을 늘리기 위한 분류가 아니다. 틀린 문장인지, 잘린 근거인지, 새로 읽은 시점이 다른지 물어볼 경로를 남기는 것이다. 나는 실패한 결과도 해당 입력과 연결해 두려 한다. 통과 기록만 남기면 다음 작업에서 왜 이 관계가 필요한지 이해하기 어렵다.
작게 적용할 때도 연결의 의미를 먼저 적는다
아래 예제는 현재 새로 만든 관계 스케치다. 과거 DB 스키마를 그대로 복원한 코드나 운영 저장소는 아니다. 두 자료로 판단한 이슈에서 실제 첫 자료를 사용한 원고를 구별한다. 수집 단위와 글의 버전을 어떤 값으로 연결할지 팀의 작업 방식에 맞춰 정할 수 있다.
공유 편집 보드도 이 관계에서 발전시킨 새 예제다. 자료를 선택하고 필요한 사실과 충돌을 확인하는 작은 화면과 코드를 제공한다. 핵심 함수 검사는 했으며 실제 브라우저 조작 검수는 대기 중이다. 보드의 확인 표시가 자료의 진실성이나 공개 권한까지 판정하는 것은 아니다.
코드와 구현 살펴보기
새 설명용 연결 모델. 현재 운영 DB나 원본 스키마 복원본이 아니다.
{
"capture": {"id": "capture-a", "observed_at": "actual time", "source_revision": "retained version"},
"issue": {"id": "issue-a", "capture_ids": ["capture-a", "capture-b"]},
"draft": {"id": "draft-a", "used_capture_ids": ["capture-a"], "revision": 1}
}
// New relational sketch. No copied database or immutable-storage implementation.다음 작업자가 판단을 다시 이어 갈 수 있도록 남긴다
다른 AI나 컴퓨터에서 글을 이어 쓰려면 완성 본문만 전달해서는 부족하다. 어떤 자료를 어느 시점에 읽었고, 무엇을 아직 확인하지 못했으며, 수정할 때 어느 글이 영향을 받는지 찾아갈 수 있어야 한다. 그 정보가 있어야 새 문장을 만들면서도 이전 사실을 바꾸지 않는다.
나는 모든 프로젝트에 같은 표 개수나 기술을 요구하지 않는다. 자료가 적다면 작은 장부로도 시작할 수 있다. 대신 연결의 의미와 바뀐 시점을 남긴다. 홈페이지가 계속 자랄 때 필요한 것은 글을 많이 저장한 상태만이 아니라 그 글을 다시 검토할 수 있는 길이었다.