미리보기에서 잘 정리한 글을 운영 사이트에 붙일 때는 기존 메뉴도 함께 읽어야 했다. 분류표 두 개를 나란히 보니 같은 번호가 서로 다른 내용을 가리키고 있었다. 이번에는 새 글을 더하는 일보다 두 분류의 경계를 연결한 판단을 풀어 본다.
공개 작업으로 넘어가며 달라진 질문
최근 작업 대화에는 작성과 검증에 이어 공개 배포까지 진행해 달라는 요청이 남아 있다. 그 뒤의 최종 기록은 실제 배포와 공개 본문 확인을 보고한다. 이번 글에서는 그 작업을 다시 실행하지 않고, 배포기가 편집실 자료와 운영 중인 홈페이지를 연결한 코드를 읽었다. 다른 채팅에서의 배포 위임을 이 콘텐츠 작업의 새 배포 권한으로 옮기지 않았다.
편집실 안에서 글을 잘 찾게 만드는 일과 이미 운영하는 홈페이지에 그 글을 넣는 일은 조건이 다르다. 전자는 새 분류표를 기준으로 생각할 수 있지만 후자는 기존 메뉴·주소·글 목록을 함께 받아들여야 한다. 같은 ID가 보인다는 이유로 같은 뜻이라고 보면 한쪽의 구조를 다른 쪽에 덮어씌울 수 있다.
실제 두 분류표에서는 한 번호가 한쪽에서는 상담 안내를, 다른 쪽에서는 현장 관찰 기록을 가리켰다. 이름만 다른 같은 분류가 아니었다. 독자가 기대하는 내용부터 달랐으므로, 이 차이를 표시하지 않은 채 새 글을 붙이는 방식을 피해야 했다.
원본을 고치기보다 공개 쪽의 연결을 정했다
원본 분류 번호를 바꾸면 폴더와 편집 목록, 진행 기록을 함께 점검해야 한다. 반대로 기존 운영 분류를 새 뜻으로 바꾸면 이미 공개한 글의 위치와 메뉴 해석이 달라질 수 있다. 배포 코드는 원본 자료의 분류를 그대로 읽고 공개용 글 객체에서만 다른 분류 번호로 연결했다.
공개 기록에는 originalCategoryId를 남겨 원래 분류가 무엇이었는지 보존한다. 공개 글 목록에 넣을 categoryId는 그와 별도로 정한다. 어떤 원고가 어디에서 왔고 운영 화면에서는 어디에 묶이는지 함께 설명할 수 있는 구조다. 나는 이 작은 연결 층이 원본 정리와 공개 메뉴 정리를 독립적으로 유지하는 데 도움이 된다고 봤다.
이 선택은 모든 필드의 이름을 그대로 공개해야 한다는 규칙이 아니다. 내부 폴더 번호와 방문자 메뉴는 목적이 다르기 때문에 다르게 연결할 수 있다는 뜻이다. 다만 연결 관계를 버리면 나중에 어떤 원고를 수정해야 하는지 찾기 어려워진다. 원본 값과 공개 값을 동시에 읽을 수 있는 기록이 필요했다.
코드와 구현 살펴보기
이번 합성 예제의 연결 형태
{
"source_category_id": "section-a",
"public_category_id": "section-b",
"route": "/journal/new/",
"note": "Source identity and article route remain; public category is projected separately."
}분류를 옮겨도 글 주소를 다시 만들지 않았다
확인한 배포 코드에서는 공개용 categoryId를 바꿀 때 글의 route를 다시 계산하지 않는다. 글 객체에 있던 경로를 유지한 채 공개 분류와 연결한다. 분류 번호와 글의 주소가 언제나 같은 값에서 다시 만들어져야 한다고 묶지 않은 것이다. 이미 준비된 글을 어느 메뉴에서 보여 줄지 바꾸는 일과 그 글의 주소를 바꾸는 일을 나눴다.
이후 새 글과 기존 글을 합친 목록에서 경로가 중복되는지도 검사한다. 분류 연결이 맞더라도 같은 주소에 서로 다른 글을 만들면 둘을 함께 제공할 수 없기 때문이다. 새 분류를 넣는 검사와 글 주소의 충돌 검사를 각각 통과해야 한다. 이번 글이 설명하는 것은 이 코드의 계약이며 원래 사이트의 모든 옛 주소를 새로 검사했다는 뜻은 아니다.
앞선 주소 유지 제작기는 공개된 옛 링크와 이동 응답을 살펴봤다. 이번에는 그보다 앞단에서 편집 분류와 공개 분류를 다르게 연결해도 글 주소를 함부로 재생성하지 않는 판단에 집중한다. 실제 주소 이전이 필요한 경우에는 이동 규칙과 공개 응답을 별도 작업으로 설계해야 한다.
분류 번호만 검사하면 이름 경로의 충돌을 놓친다
새 공개 분류를 추가하는 부분은 ID뿐 아니라 slug도 기존 목록과 비교한다. 번호가 달라도 같은 슬러그를 쓰면 분류 페이지가 겹칠 수 있으므로 두 값 중 하나가 이미 쓰이고 있으면 멈춘다. 원래 코드는 정해진 새 분류를 추가하는 방식이고, 같은 분류로 합류해도 되는지 의미를 추론하는 기능은 없다.
이번 공유 모듈은 이 판단을 독립적인 입력 계약으로 넓혔다. 원래 코드처럼 특정 번호를 고정하지 않고 출처 분류와 공개 대상 분류를 규칙으로 받는다. 기존 공개 분류를 재사용하려면 ID·슬러그·선언한 의미가 모두 같아야 하고, 충돌한 번호를 알아서 다른 값으로 고치지는 않는다.
여기서 의미가 같다는 확인은 결국 사람이나 상위 편집 절차의 책임이다. 모듈의 meaning 필드는 그 결정을 담는 문자열일 뿐 글을 읽고 주제를 보증하는 장치가 아니다. 어떤 값을 같다고 비교했는지 공개하면 코드의 자동 처리와 편집자의 판단을 섞지 않을 수 있다.
목록 연결의 성공과 실제 공개 완료는 따로 남겼다
원래 배포기는 편집 큐의 검증 상태와 원고 해시를 확인해 공개 후보를 고른다. 또 기존에 공개한 원고가 이번 선택에서 빠지면 진행하지 않도록 검사한다. 분류를 연결한 후보를 만들었다고 곧바로 published로 기록하지 않고, 후보 자료에는 공개 전 상태를 남긴다. 원본을 읽고 목록을 만들었다는 단계와 실제 공개 결과를 구별하는 것이다.
대화의 최종 기록에 공개 배포와 주소 확인이 남아 있지만 그것은 그 실행의 보고다. 나는 이번에 원래 배포기나 원래 시험을 다시 돌리지 않았다. 고객 원고와 제공 자료 묶음도 이 글의 공개 재료로 옮기지 않았다. 이번에 확인한 범위는 선택한 코드·지침·시험 소스와 제작 판단이다.
공유 모듈의 performs_write_or_publish도 항상 false다. 분류 연결이 정상이라는 결과를 원고 검토·공개 권한·배포·접속 성공으로 읽지 않도록 경계를 남겼다. 이 작은 함수는 기존 운영 사이트를 바꾸기 전에 만들어 볼 수 있는 공개 목록의 한 부분이다.
다음 홈페이지에서도 다시 쓸 수 있도록 남긴 것
새 합성 구현의 24개 시험은 원본 분류 보존, 기존 공개 분류 보존, 같은 대상 재사용과 여러 출처의 합류, ID·슬러그·경로 충돌, 연결 누락과 입력 보존을 확인했다. 다섯 실행 기록은 정상 연결과 네 가지 거절 상황을 남긴다. ZIP을 추출한 재시험도 같은 24개 시험이며 별개의 새 시험 수로 합산하지 않는다.
모듈에 들어 있는 결과 선택기는 저장된 기록을 보여 준다. DOM 대역에서 한영 초기 표시와 각 기록 선택을 확인하지만 실제 브라우저의 레이아웃과 키보드 검수는 아니다. 경로 생성과 파일·검색 목록 대조는 이미 공개한 경로 모듈을 함께 검토할 수 있다. 새 모듈로 그 기능을 다시 만들지 않았다.
다른 홈페이지에 붙일 때는 먼저 현재 운영 분류표와 글 주소 목록을 확보하고, 편집실 분류가 각각 어느 공개 메뉴로 가야 하는지 정하면 된다. 그 연결을 시험한 뒤 기존 발행 절차에 넘긴다. 내 자료를 관리하기 쉬운 구조와 방문자가 찾기 쉬운 구조가 달라도, 둘 사이의 관계를 명확히 남기면 계속 확장할 수 있다.