함께 맞물리는 두 기반
REZICS는 “콘텐츠가 무엇인가”와 “콘텐츠가 어디에 나타나는가”를 분리해 모델링합니다.
- Block Schema는 렌더링 가능한 문서가 어떤 타입이 지정된 블록으로 이루어지는지, 각 블록이 안정적인 정체성, 버전, 검증 규칙을 어떻게 보존하는지 정의합니다.
- 콘텐츠 구조는 콘텐츠 단위의 출현 위치, 부모-자식 관계, 순서, 목적지, 발행된 수정본을 정의합니다.
이 분리 덕분에 같은 장／게시물을 본문을 복사하지 않고 여러 위치에서 재사용할 수 있으며, 각 출현은 고유한 노드 ID, 순서, 탐색 의미를 가집니다.
Block Schema: 원시 JSON이 아님
저장 가능한 JSON 문서 대부분은 임의의 Portable Text 배열을 필드에 그대로 넣는 대신 먼저 식별 가능한 기본 객체를 가져야 합니다. 가장 기본적인 Portable Text 문서는 다음 의미를 가집니다.
{
_type: "portable-text",
_key: "6바이트／12자리 16진수 키",
content: PortableText,
}_type은 파싱과 렌더링 프로토콜을 결정합니다. _key는 수정본, 문단 댓글, 구조 작업을 거쳐도 블록 정체성을 유지하게 합니다. 문서 버전은 구조 사양이 진화할 때마다 명시적인 마이그레이션 경계를 제공합니다. 형식 검증 뒤에도 참조, 권한, 공개 범위를 검증해야 합니다. 식별자 형식만으로 대상이 읽을 수 있다는 증명이 되지는 않습니다.
구현된 블록 계열
현재 공통 Block Schema는 Portable Text, 단위 참조, 전체 게시물 표시, 단위 목록, 검색 기반 콘텐츠 피드, 메뉴, 기타 통제된 콘텐츠 화면을 표현할 수 있습니다. 각 변형은 닫힌 유니온의 일부이므로 알 수 없는 블록이 렌더러를 조용히 통과할 수 없습니다.
구역, 배치 영역, 위키 탐색, 앞으로 재사용할 수 있는 문서는 모두 이 공통 기반 위에 있습니다. 블록 문서를 독립 단위로 승격할지는 소유자를 넘는 재사용, 독립 저자, 발행 이력, 공개 범위 같은 실제 필요로 증명되어야 합니다.
콘텐츠 구조로 지금 할 수 있는 일
- 도서, 미디어, 게시물, 영역 분류 구조, 탐색용 타입이 지정된 구조를 만듭니다.
- 안정적인 노드 ID, 부모 노드, 분수 인덱스 위치로 대규모 순서 트리를 보존합니다.
- 노드가 재사용 가능한 콘텐츠 단위를 참조하고 콘텐츠, 단위 목적지, 외부 URL을 구분하게 합니다.
- 완전한 초안으로 도서／미디어 구조를 편집하고, 상한이 있는 변경을 원자적 요청으로 컴파일합니다.
- 수정본을 저장하고 차이를 비교하며 새 수정본으로 이전 상태를 복원합니다.
- 리더가 구조를 목차, 이전 장／다음 장, 읽기 진행도 위치로 투영하게 합니다.
대규모 연재와 가져오기
한 번의 구조 변경은 논리 명령을 최대 10,000개로 컴파일합니다. 이 제한은 하나의 원자적 변경에 대한 것이지 도서 전체 노드 수에 대한 것이 아닙니다. 대규모 웹소설은 전체 트리를 여러 차례의 복구 가능한 쓰기로 나눌 수 있습니다. 매번 커밋된 노드와 상한이 있는 새 노드 묶음을 가져오고, 성공한 뒤 다음번에 필요한 수정 토큰을 받습니다.
따라서 10,000장보다 큰 작품도 무제한 트랜잭션을 로드할 필요가 없고 충돌 감지를 포기할 필요도 없습니다. 가져오기는 중단 후 재개할 수 있으며 마지막에 전체 스냅샷을 검증합니다.
개발 중 및 계획 중
더 많은 블록 변형, 소유자를 넘는 블록 단위, 강한 참조 색인, 문단 수준 댓글, 완전한 대규모 가져오기 흐름, GameContentStructure는 각각 개발 중이거나 계획 중입니다. 새 블록 종류마다 저장, 발행, 읽기, 삭제, 캐시, 실패 상태를 정의해야 합니다.
관계와 경계
Block Schema는 편집기가 아니고 콘텐츠 구조도 본문이 아닙니다. 편집기는 검증된 문서를 만들며, 게시물／장이 콘텐츠를 소유하고, 콘텐츠 구조가 출현 위치를 배치하며, 이력은 발행된 수정본을 보존합니다.