같은 설명을 썼어도 시공 전후 사진의 위치가 바뀌면 독자는 반대로 이해할 수 있다. 글자 수와 본문 문자열만 비교해서는 이런 차이를 놓친다. 북극성에서는 문단과 매체를 순서 있는 계획으로 받고, 입력이 끝난 편집기 구성도 그 순서와 대조하도록 만들었다.
글자만 꺼낸 값은 매체의 위치를 말하지 못한다
articleText는 text 블록만 모아 두 줄바꿈으로 연결한다. 일반 본문 확인에 필요한 값이지만 사진과 영상이 어디에 들어갔는지는 사라진다. 나는 이 값을 전체 원고의 유일한 정체성으로 쓰지 않았다. ArticlePlan에는 text·image·video가 하나의 blocks 배열 안에 순서대로 남는다.
매체 블록에는 이름과 바이트 hash가 있고 영상 제목도 있다. 처음과 끝 문단, 연속 문단 결합 같은 조건도 이 rich 계약에서 검사한다. 순서를 먼저 자료로 만들면 입력기와 검증기가 같은 계획을 읽을 수 있다. 화면을 보고 순서를 다시 추측하는 작업을 줄이기 위한 선택이었다.
전체 계획의 변경을 본문 hash와 따로 잡는다
validateArticleInput은 파싱한 plan 전체를 JSON으로 만들어 contentHash를 계산한다. 텍스트뿐 아니라 매체 hash와 위치, 영상 제목이 달라도 다른 원고로 읽을 수 있다. 저장한 ArticleProgress의 contentHash와 다르면 ARTICLE_PLAN_CHANGED로 멈춘다. 같은 제목과 날짜라는 이유로 수정된 매체 구성을 이어 붙이지 않는다.
hash가 맞는다고 원고 내용이 사실이라는 뜻은 아니다. 이 값은 계획의 동일성 확인이지 저작권·사실성·완성도 판정이 아니다. 같은 입력을 재개하는 일과 새 원고를 만드는 일을 구별하는 데 쓴다. 본문의 의미를 검토하는 사람의 판단을 지문 계산으로 대체하지 않았다.
완료한 앞부분과 다음 한 항목을 구분한다
ArticleProgress는 확인한 blocks와 선택·삽입 중인 pending을 따로 가진다. pending의 index는 확인한 blocks 길이와 맞아야 한다. 확인된 앞부분의 텍스트가 바뀌거나 유형이 달라지면 원장과 계획의 불일치다. 어디까지 완료했는지와 다음 것을 보내려 했는지를 같은 목록으로 섞지 않은 것이다.
이 구조가 있어야 늦게 나타난 사진 하나를 기존 요청의 결과로 받아들일 조건도 정할 수 있다. 새 구성 요소가 보였다는 이유만으로 전부 채택하지 않는다. 기존 앞부분이 같은지와 다음 유형이 맞는지 함께 비교해야 다른 사람이 수정한 글을 자동 실행의 결과처럼 덧붙이지 않는다.
관찰한 요소 ID와 선택 파일 hash는 다른 증거다
편집기 관찰에는 순서·유형·요소 ID·준비 상태가 들어간다. matches는 신뢰한 문서 root에 articleExpectation을 전달해 checked와 matches를 읽는다. 텍스트는 내용, 매체는 연결한 요소 ID를 포함한 구성을 대조한다. 마지막에는 pending이 없고 전체 블록 수가 계획과 같아야 한다.
이때 요소 ID를 로컬 원본 바이트의 hash라고 부르면 안 된다. 파일 hash는 선택 자료를 연결하는 증거이고 요소 ID는 편집기에 삽입된 구성의 식별이다. 실제 서비스가 원본과 바이트 단위로 같은 파일을 보관한다고 이 관찰만으로 증명하지 않는다. 자료의 출처와 화면 구성을 잇는 각 단계의 의미를 나눴다.
시험은 추가된 매체보다 바뀐 앞부분을 먼저 거절한다
기존 시험은 선택한 사진이 나중에 보이더라도 앞 문단이 바뀌면 채택하지 않는지 확인한다. 또 매체 hash를 바꾸면 contentHash가 달라지고 지원하지 않는 operation은 거절되는지 본다. 이번에는 해당 함수와 시험을 읽었으며 실제 고객 원고를 바꾸거나 새 외부 업로드를 실행하지 않았다.
공유 모듈은 순서·문단·매체 바이트·ready의 합성 관찰 차이를 실제30개 시험으로 확인한다. 그 관찰은 호출자가 주는 자료라 원래 편집기 component 연결을 재현하지 않는다. 구조 검토 예제와 실제 서비스 검증을 같은 수준으로 발표하지 않으려는 구분이다.
레이아웃을 내용의 바깥으로 밀어내지 않는다
사진은 장식일 수도 있지만 절차와 결과를 설명하는 핵심 자료일 수도 있다. 어느 문단 뒤에 있는지, 다른 사진과 어떤 순서인지가 독자의 이해를 바꾼다면 그 위치도 원고에 포함해야 한다. 텍스트가 맞았다는 확인만으로 완성됐다고 부르기 어려운 이유다.
다른 편집기에 적용할 때는 요소 ID와 준비 상태를 어디서 읽을지 먼저 정해야 한다. 같은 블록 이름을 쓰는 것만으로 신뢰할 관찰이 생기지는 않는다. 나는 원고 계획과 입력 기록, 다시 관찰한 구성을 연결해 내용과 배치를 함께 확인할 수 있는 제작 방법을 남기고 싶었다.