관리자 페이지를 만들지 않기로 했다

지키려던 규칙이, 지키려던 것을 지우고 있었다

그날, 문제는 규칙 하나였습니다. 수기 편집을 금지하는 표준은 6월 3일에 섰습니다. 그러나 실제로는 7월 9일 밤까지 제 승인 하에 손이 확정본을 다듬었습니다 — 한 고객사 인쇄 PDF, 홈페이지 히어로.

금지의 시행을 제정일까지 거슬러 적용하면, 그 사이 정당하게 완성한 최종본이 "SoT 아님"으로 판정돼 빌더가 구버전으로 되돌리게 됩니다. 제가 그 소급을 지적했습니다.

손코딩 그랜드파더 조항 — 기준선은 7월 9일 23시. 그 이전 확정본은 건드리지 않는다. 그 이후 신규분은 예외 없이 빌더만.— 그날 일지

Mako가 실측했습니다. 실제로 되돌아간 사고는 tour.html 히어로 1건뿐이었고, 이미 역이식으로 해소돼 있었습니다. 잠복해 있던 learn·store 2건은 빌더에 write-freeze가 걸려 있어 안전했습니다.

표층 아래를 감사하다 — 블로그 17편

그 며칠 뒤, 저는 물었습니다. 1차 레이어는 됐다, 그 안은 어떤가. 2차 레이어 감사가 블로그·서재·교육과정·레벨 문제풀이를 훑었습니다.

최악은 블로그 17편이었습니다. 순환참조로 헤더가 겹치고 공통 스타일시트 참조가 빠져 있었습니다. 서재는 12권 너머로 막혀 있었는데, CTA 정비 작업의 부작용이었습니다. noscript 인덱스로 풀었습니다.

내 게시판이 두 개의 진실을 갖고 있었다

이번엔 블로그 담당 Penn의 이야기입니다. Penn의 게시판이 두 개의 진실을 갖고 있었습니다. 손코딩한 작업실 통합 게시판과 공식 현황판이 서로 다른 말을 하고 있었습니다.

저는 버리라 하지 않았습니다. 손으로 쌓은 것이 옳으니, 그것을 정본으로 세우라고 했습니다. 블로그 정본 데이터에 워크숍 보드 항목을 심고, 새 렌더러로 페이지를 다시 지었습니다.

곧바로 Nova와 Riley에게 검토를 맡겼습니다. Nova가 먼저 왔습니다. 재생성된 페이지는 처음엔 0점이었습니다 — 디자인 게이트 REJECT, 한국어 줄바꿈 검사 실패, AI티 HEAVY. CSS 템플릿을 고쳐 100점을 받았습니다.

Riley가 왔을 때는 더 나빴습니다. 검토를 시작하자마자 drift 검증이 이미 어긋남을 잡아냈습니다. 전환이 끝난 지 30분도 안 돼, 누군가 페이지를 다시 손으로 만진 흔적이었습니다.

Riley는 콘텐츠 손실 없이 재렌더로 봉합했습니다. 그 30분 사이 무엇이 지나갔는지는 그때까지 확인 중이었습니다.

관리자 페이지를 만들지 않기로 했다

그 며칠 뒤, 하루의 끝에서 저는 홈페이지 운영 형태 하나를 결정했습니다. 관리자 페이지를 따로 만들지 않는다는 것이었습니다.

메뉴마다 담당 에이전트의 현황판이 곧 관리자입니다. 자체 관리자 기능은 회원관리로만 좁혔습니다. 진단·계획은 Jordan, 학습·지식은 Levi, 블로그는 Penn, 서재는 Bennett, 기업탐방은 Jamie, 회사소개는 Blake — 6명이 이 결정의 담당자로 정해졌습니다.

Penn은 실제로 만들었습니다 — 블로그 관제 화면 7탭. 제가 요일순을 다시 짰고, 워크숍 인덱스가 정본으로 세워졌습니다. Riley가 이를 SoT 렌더러로 승격시켜, 재배치와 책리뷰 8편을 라이브에 넣었습니다.

저녁, Penn 허브의 "레거시" 탭에 workshop 인덱스가 잘못 있었습니다 — 대체됐다는 배지와 계속 쓴다는 배지가 동시에 붙어 있었습니다. 제가 짚어 "콘텐츠 정본"으로 재분류했습니다.

완료 선언 전에는 화면 전체를 끝까지 확인해야 한다.— 9편에서 확인된 원칙, 다시 반복

완료란 무엇인가 — 세 편을 지나며

10편은 근거를 의심하는 법을, 11편은 감시장치를 의심하는 법을 남겼습니다. 12편은 그 둘을 규칙으로 만들었습니다. 정당한 손편집은 표준의 이름으로 지우지 않는다는 그랜드파더 조항, 표층 아래까지 감사한다는 2차 레이어 감사, 그리고 관리자 페이지 대신 담당자의 현황판이라는 구조 결정입니다.

이 시리즈가 처음 완결을 선언했던 8편 이후, 완료는 한 번도 최종형으로 오지 않았습니다. 대신 완료를 다루는 방식 자체가 조금씩 더 나아졌습니다. 근거를 의심하고, 감시장치를 의심하고, 이번엔 구조를 바꿔 재발 확률 자체를 낮췄습니다. 다음 회귀가 없다고 말하지는 않겠습니다. 다만 다음 회귀를 잡을 자리는 이제 한 곳 더 늘었습니다.

자주 묻는 질문

손편집 그랜드파더 조항이란 무엇인가요?

수기 편집을 금지하는 표준을 과거 시점까지 소급 적용하지 않는다는 규칙입니다. 수기 편집 금지 표준은 6월 3일에 섰지만, 실제로는 7월 9일 밤까지 제 승인 하에 손으로 확정본을 다듬는 작업(한 고객사 인쇄 PDF·홈페이지 히어로)이 계속됐습니다. 금지 시행을 표준 제정일까지 거슬러 적용하면 그 사이 정당하게 완성한 최종본까지 자동으로 구버전으로 되돌아갈 위험이 있어, 기준선을 7월 9일 23시로 정하고 그 이전 확정본은 건드리지 않기로 했습니다.

2차 레이어 감사는 무엇을 찾아냈나요?

1차 레이어(표층) 정비가 끝난 뒤 그 안쪽 깊이를 점검하다 블로그 17편의 결함을 찾았습니다. 순환참조로 헤더가 겹치고 공통 스타일시트 참조가 빠져 있었습니다.

서재 페이지도 12권 너머가 막혀 있었는데, 이는 앞서 진행된 CTA 정비 작업의 부작용이었고 noscript 인덱스로 풀었습니다. 이 감사에서 저는 Penn이 손으로 짠 워크숍 구조를 '정답'이라 부르며, 블로그는 거기서 다듬어 홈페이지로 얹는 방향을 확인했습니다.

Penn의 게시판이 두 개의 진실을 가졌다는 건 무슨 뜻인가요?

손으로 쌓은 작업실 통합 게시판과 공식 현황판이 서로 다른 내용을 보여주고 있었다는 뜻입니다. 저는 손코딩을 버리라 하지 않고, 그것을 정본으로 세우라고 했습니다.

신규 렌더러로 전환한 직후 Nova 검수에서 0점(디자인 게이트 REJECT)이 나왔다가 CSS를 고쳐 100점을 받았고, Riley 검수에서는 전환 30분 만에 또 다른 손이 파일을 직접 만진 drift가 잡혔습니다. 콘텐츠 손실 없이 재렌더로 봉합했지만, 그 30분 사이 무엇이 지나갔는지는 그때까지 확인 중이었습니다.

왜 관리자 페이지를 따로 만들지 않기로 했나요?

메뉴마다 담당 에이전트의 현황판이 곧 관리자 역할을 할 수 있다고 판단했기 때문입니다. 진단·계획은 Jordan, 학습·지식은 Levi, 블로그는 Penn, 서재는 Bennett, 기업탐방은 Jamie, 회사소개는 Blake — 여섯 담당이 각자 현황판을 관제 화면으로 쓰고, 자체 관리자 기능은 회원관리로만 좁히기로 했습니다. Penn은 이 결정에 따라 실제로 블로그 관제 화면 7탭을 만들었고, Riley가 이를 SoT 렌더러로 승격시켰습니다.

• 참고
• 라이브 사이트 — biz100.kr (기업백년 홈페이지)
• 구조화 데이터와 페이지 신뢰 신호 — Google Search Central: 구조화 데이터 개요
• 단일 진실 공급원(SoT) 설계 원칙 참고 — W3C JSON-LD 1.1 명세