디자인이 아름답게 끝났는데 구현 단계에서 “이건 CMS 로는 어렵습니다” 라는 말이 나옵니다. 여기서 대화는 대개 둘 중 하나로 갑니다 — 디자인을 깎거나, 편집자가 손댈 수 없는 화면을 만들거나. 둘 다 나중에 비용을 냅니다.
이 대화는 순서를 바꾸면 아예 일어나지 않습니다. 어느 영역을 편집자가 바꿀 수 있는지를 디자인 전에 정하면, 디자인은 처음부터 그 제약 안에서 만들어집니다. 제약은 창의성을 깎는 것이 아니라 협상을 끝내 두는 장치입니다.
편집 가능한 영역이 늘어나면 무엇이 따라오는가
“전부 편집 가능하게” 는 관대해 보이지만 실제로는 디자인의 통제권을 넘기는 결정입니다. 편집자가 색을 고를 수 있으면 브랜드 팔레트 밖의 색이 언젠가 들어오고, 간격을 조절할 수 있으면 척도 밖의 값이 들어옵니다. 그리고 그 값은 디자이너가 보지 못하는 화면에 들어갑니다.
어디까지 넘길 것인가
실용적인 경계선은 사이트 크롬과 본문 사이입니다. 크롬 — 헤더 · 푸터 · 랜딩 섹션 · 목록 화면의 구조 — 은 코드가 소유하고, 본문은 편집자가 소유합니다.
이 사이트도 같은 규칙으로 운영합니다. 랜딩 섹션과 헤더 · 푸터는 코드에 있고, 편집 화면에서 바꿀 수 있는 것은 아티클 본문입니다. 이유는 관리자를 못 믿어서가 아니라 레이아웃이 데이터베이스에 들어가면 되돌릴 수 없기 때문입니다 — 버전 관리에 흔적이 남지 않고, 스테이징에서 프로덕션으로 옮길 때 수작업 복사가 되며, 자동화로 재현할 수 없습니다.
반대로 본문은 반드시 편집자에게 줍니다. 글 한 줄 고치려고 개발자를 불러야 하는 구조는 콘텐츠를 쌓지 못하게 만들고, 결국 사이트가 낡습니다.
제약을 디자인 문서에 적는 법
결정을 말로만 하면 사라집니다. 시안 옆에 한 줄씩 적어 두는 것으로 충분합니다 — “이 영역은 편집자가 문단과 목록만 넣을 수 있음”, “이미지 비율 고정, 자르기는 자동”, “이 섹션은 고정, 순서 변경 없음”.
이 한 줄들이 있으면 개발자는 편집 화면을 어떻게 구성할지 바로 알 수 있고, 디자이너는 편집자가 만들 수 있는 최악의 화면을 미리 상상할 수 있습니다. 그 최악의 화면이 견딜 만하면 그 설계는 안전합니다.
테마와 편집 환경의 관계는 테마 · 플러그인 아카이브에서 더 다루고, 이미 편집 권한이 넓게 열려 버린 사이트를 정리하는 작업은 최적화 지원 사업의 범위에 있습니다.
다음 회차
영역이 정해졌으면 그 안을 채우는 값의 이야기가 남습니다. 다음 회차는 간격 명세 — 픽셀 숫자를 던지는 대신 척도를 넘기는 방법입니다.