사내 안내서 리디자인 — Juyoung You

전 구성원이 매일 여는 사내 안내서 페이지를 다시 설계하면서, 그대로 적용했다면 하위 페이지 46개가 사라졌을 파괴적 변경을 사전에 발견하고 원본을 한 번도 건드리지 않는 리허설로 검증한 프로젝트.

1. 한눈에


역할	요구사항 정의 · 정보구조 설계 · 시안 제작 · 이관 전략 수립 (1인)
기간	2026-08
상태	Phase 0~1 완료 (리허설 통과) · Phase 2 적용 승인 대기
대상	사내 안내서 — 8개 섹션 · 하위 페이지 46개 · 데이터베이스 1개 · 인라인 링크 2개
방법	구조화 인터뷰 5라운드 → 시안 4종 → 개선 반영 → 확정
원본 상태	무손상 확인 완료 — 전 과정에서 원본을 한 번도 수정하지 않음

2. 배경 — 무엇이 문제였나

사내 안내서는 신규 입사자가 처음 여는 문서이자, 기존 구성원이 규정·시스템·사무실 이용을 찾을 때 들어오는 관문이다. 즉 읽히는 빈도가 가장 높은 사내 문서다.

내용은 쌓여 있었지만 구조가 따라오지 못했다. 8개 섹션 아래 46개 페이지가 평평하게 나열되어 있어서, 필요한 것을 찾으려면 전부를 훑어야 했다.

문제는 “다시 만들면 된다”가 아니었다. 이 페이지는 이미 돌아가고 있는 것이었다.

하위 페이지 46개는 각자 URL을 가지고 있고, 사내 여기저기서 링크되어 있다. URL이 바뀌면 그 링크들이 전부 깨진다.
사이드바 계층이 바뀌면 사람들이 익숙해진 경로가 사라진다.
그리고 결정적으로 — 이 도구에서 페이지 참조와 페이지 실체는 다른 것이었다.

3. 발견한 함정 — 참조인 줄 알았던 것이 실체였다

원본 페이지 본문에 들어 있는 46개 항목은 다른 곳에 있는 페이지를 가리키는 링크가 아니었다. 그 페이지들이 존재하는 위치 자체였다.

즉 본문에서 그 항목을 빼면, 링크가 끊기는 게 아니라 페이지가 삭제된다.

그런데 새로 만든 시안은 전부 참조(mention) 방식으로 되어 있었다. 시안을 만들 때는 그게 자연스럽다 — 원본을 건드리지 않고 구조만 보여주려면 참조를 쓸 수밖에 없다.

시안을 그대로 원본에 이식했다면, 46개 페이지가 한 번에 증발했을 것이다.

이걸 적용 직전이 아니라 전략 수립 단계에서 발견했다. 원본과 시안을 섹션별로 1:1 대조하는 과정에서, 항목 수는 47개로 정확히 맞는데 한 항목의 타입이 다르다는 것이 눈에 띄었기 때문이다(원본은 데이터베이스 실체, 시안은 참조). 개수만 세고 넘어갔으면 놓쳤을 차이였다.

4. 해법 — 껍데기만 가져오고 알맹이는 원본 것을 쓴다

  시안 C (새 레이아웃)              원본 (실체 블록 46개)
   ├ 3단 컬럼 구조                   ├ 페이지 실체 × 46
   ├ 토글 아코디언 8개               ├ 데이터베이스 실체 × 1
   └ 위젯 · 카드                     └ 인라인 링크 × 2
        │                                    │
        │  레이아웃만 추출                     │  실체 그대로 유지
        └──────────────┬─────────────────────┘
                       ▼
              원본 페이지를 제자리에서 교체
              ├ 원본 URL 유지
              ├ 하위 46개 URL 유지
              └ 사이드바 계층 변화 없음

시안의 레이아웃(3단 구조, 토글, 위젯 배치)만 가져오고, 토글 안에 들어갈 항목은 원본의 실체 블록을 그대로 되돌려 넣는 방식을 택했다.

대안은 하위 페이지 46개를 먼저 다른 곳으로 옮긴 뒤 본문을 참조 방식으로 새로 쓰는 것이었는데, 사이드바 계층이 한 단계 깊어지고 이동 실패 시 복구 비용이 크다는 이유로 차선으로 뒀다.

5. 안전장치 — 되돌릴 수 없는 작업을 다루는 법

① 삭제를 금지하는 옵션을 검증기로 썼다

편집 연산에 “콘텐츠 삭제 불허” 옵션이 있다. 이걸 켜면 하위 페이지나 데이터베이스가 하나라도 지워지는 연산은 에러로 거부된다.

이것을 안전장치가 아니라 자동 검증기로 해석했다.

연산이 성공했다 = 47개가 하나도 지워지지 않았다.

사후에 “몇 개 남았나”를 세는 대신, 잘못된 연산은 애초에 성공할 수 없게 만든 것이다.

② 롤백을 3중으로 준비했다

층	수단	복원 범위
1	플랫폼 페이지 히스토리	콘텐츠 + URL 전부 (1순위)
2	실행 직전 복제 백업본	콘텐츠 (하위 URL은 새로 생성됨)
3	로컬 마크다운 스냅샷	텍스트

1층만으로 충분해 보이지만, 플랜에 따라 히스토리 보존 기간이 다르다는 점을 확인 항목으로 남겼다. 가장 믿는 롤백 수단의 전제를 검사하지 않으면 롤백 계획이 아니라 희망이 된다.

③ 리허설 자체가 원본을 파괴할 뻔했다

원본을 통째로 복제해 리허설하려던 계획을 폐기했다.

이유: 복제본에 원본 페이지를 참조하는 실체 태그를 넣으면, 원본의 하위 페이지가 복제본으로 이동해 버린다. 리허설이 원본을 망가뜨린다.

대신 더미 페이지 몇 개로 구성한 미니 리허설을 만들어, “실체 블록이 다단 컬럼과 토글 안에서 살아남는가”라는 구조 명제 하나만 판정했다. 통과했다.

검증하려던 행위 자체가 위험원인 경우가 있다. 무엇을 확인해야 하는지를 명제로 좁히면, 훨씬 작고 안전한 실험으로 답할 수 있다.

④ 도구의 조용한 손실을 순서로 회피했다

특정 편집 방식이 이미지 블록을 조용히 삭제한다 → 이미지는 전체 교체 연산 한 번에 넣고, 이후 부분 수정을 금지.
페이지에 붙지 않은 첨부 업로드는 만료되어 사라진다 → 첨부 생성을 준비 단계가 아니라 적용 직전으로 옮김.
첨부 원본 URL은 5분 만에 만료된다 → 가져오기와 업로드 사이에 다른 작업을 넣지 않도록 절차에 명시.

셋 다 “실패하면 에러가 나는” 종류가 아니라 성공한 것처럼 보이는데 결과물이 비어 있는 종류였다.

6. 검증을 두 종류로 나눴다

자동 검증 (전수 대조)	육안 검증 (자동 불가)
실체 페이지 46개 — 섹션별 개수까지	3단 레이아웃 렌더링
데이터베이스 1개 존재	위젯 2종 로딩
인라인 링크 2개 (뷰 파라미터 포함)	토글 8개 개폐
페이지 아이콘 유지	모바일 표시 · 다크모드 대비

그리고 육안 항목 중 모바일 표시와 다크모드 대비를 “미검증”으로 명시했다. 확인하지 않은 것을 확인한 것처럼 두지 않기 위해서다.

7. 프로세스 — 요구사항을 먼저 좁혔다

구조를 만들기 전에 구조화 인터뷰 5라운드로 요구사항을 정리했다(잔여 모호도 17%까지 축소). 그 다음 성격이 다른 시안 4종을 만들었다.

시안	구조
A	좌측 사이드바 + 본문 2단
B	상단 위젯 바 + 균등 3단
C (확정)	3단 — 좌: 시각 요소·규정 카드 / 중: 토글 아코디언 8개 / 우: 위젯
D	퀵액세스 우선 — 히어로 + 4단

하나를 만들어 고치는 대신 네 개를 나란히 놓고 고른 이유는, 정보 구조는 설명으로 비교하기 어렵고 실물을 봐야 판단이 되기 때문이다. 확정 후 개선 사항(위젯 교체·규정 최신성 표시·신규 입사자 경로)은 4개 시안 전부에 반영해 비교 조건을 맞췄다.