매뉴얼 구조화

많은 글쓰기 지침들이 차례의 중요성을 강조한다. 차례 짜기가 문서 기획에서 상당 부분을 차지해야 한다고 말한다. 많은 사람들이 아래와 같이 여러 수준을 사용하여 문서를 구조화한다.

---

장 (Chapter) 1
절 (Section) 1.1
절 (Section) 1.1.1
절 (Section) 1.1.1.1

---

하나의 문서는 여러 주제들로 이루어진다. 어떤 주제에서 그 내용이, 그 내용의 길이와 관계 없이, 주제를 완결적으로 다루었을 때 그 주제가 독립적인 것으로 간주된다. 현미로 맛있는 밥을 짓는 방법으로 이야기가 시작해서 현미가 백미보다 건강에 좋은 이유로 이야기가 끝난다면 그것은 아직 사람들에게 보여줄 수 있는 글이 아니다. 다층 구조로 이루어진 글에서 우리는 몇 가지 의문을 갖게 된다. 위의 예를 사용하자면, “절 1.1.1.1″에 실제 주제와 내용이 들어있다면 상위 구획들은 무엇을 위한 것들일까? 그것을 아래와 같이 바꾸어 보아도 될 것 같다.

---

대주제
소주제
소주제
소주제
내용

---

장 단위를 대주제라기보다 같은 성격의 주제들을 담은, 그래서 다른 주제들과 쉽게 구분할 수 있게 하는 바구니 정도로 보아도 괜찮을 것이다. 그렇다면 “절 1.1″과 “절 1.1.1.”도 바구니일까, 아니면 큰 소주제와 작은 소주제일까? 바구니로 본다면 중간에 아무 내용 없이 큰 절의 제목에 이어 작은 절의 제목이 곧바로 올 수 있을 것이다. 바구니가 아니라면 큰 절 제목 아래 작은 절을 소개하거나 암시하는 문단이 있을 것이다. 이 두 가지 방식이 무분별하게 함께 사용된다면 독자들에게 큐브처럼 보이는 문서가 만들어질지도 모른다.

문서의 많은 부분을 읽고 난 뒤에 독자들은 그 내용의 총체적 이해로서 어떤 체계적 형상을 머리 속에 그릴 수 있을지도 모른다. 그 형상이 그 문서가 의도하는 것과는 다소 다르다고 하더라도 그렇게 할 수 있을 정도로 독자가 내용을 이해했다면 문서는 제 역할을 한 셈이다. 독자가 어차피 머리 속에 큐브와 같은 것을 갖게 된다면 문서가 아예 큐브를 보여주는 것이 더 좋을지 모른다. 그러나 그런 기대는 달성되지 않는다. 독자는 문서를 통해 여러 주제들을 하나씩 이해하게 되고 그 모듈들을 짜맞추어 큐브를 완성한다. 큐브의 여러 면을, 또는 한 면의 여러 속성을 동시에 보여주는 것은 독자의 이해를 돕기는커녕 문서 자체를 풀기 어려운 퍼즐로 만들어 버린다.

벼락치기 공부를 하면서 만든 쪽지는 그것을 만든 사람에게만 도움이 된다. 공부하는 동안 많은 양의 정보가 이해되고 기억되었고 쪽지는 단지 그 기억을 끄집어내는 데에 도움이 될 뿐이다. TED 강연들을 보라. 보통의 이야기 방식으로 전달되는 정보가 쉽게 이해되고 오래 기억된다.

문서의 구조는 단순해야 한다. 빨랫줄에 걸린 옷들이나 암실에서 줄에 걸린 채 인화를 기다리는 사진들 같아야 한다.

“절(section)만 사용하되 불가피한 경우에 부절(subsection)을 사용하겠다”거나 그에 준하는 원칙을 세우고 지켜라. 복잡하지 않는 구조는 독자가 이해하기 쉬울 뿐만 아니라 저자가 주제를 정하는 데에도 도움이 된다. 복잡한 구조를 사용하면 이것과 저것을 나누고 무엇부터 무엇까지 담을지 계속 고민하고 갈등하게 된다. 독립적이고 완결적인 것들이 될 때까지 주제들을 나누고 쪼개라. 그렇게 하여 얻은 것들을 논리적인 순서로 연결하라. 아래 전자책 앱의 차례가 단순 구조의 좋은 예를 보여준다.

---

Purchasing books

1. Canceling purchases
2. Free books

Reading books

1. Navigating through pages
2. Page appearance
3. Annotating books
4. Searching for words
5. Referencing
6. Bookmarks
7. Syncing reading progress

Managing books

1. Sorting books
2. Changing display modes
3. Deleting books
4. Searching for books
5. Syncing books

---

제품의 구성이나 기능이 복잡하다는 것이 문서마저 복잡해야 한다는 이유가 될 수 없다.