describug
← 기록
사이트 만들기

비유를 어디서 멈출까

사이트를 명세서처럼 생기게 만들다가, 구조 전체를 명세서 목차에 맞추는 안은 접었습니다.

설계브랜딩

Summary

과제
이름이 명세서에서 나왔으니 화면도 그렇게 갈까 싶었는데, 어디까지 씌울지가 문제였다.
수단
먼저 씌우지 않고 글을 쓰다 필요해진 자리에만 붙였다. 구조 전체를 맞추는 일은 하지 않았다.

DETAILED DESCRIPTION

이 사이트 이름의 describ는 명세서의 「발명의 설명」, Description에서 따왔습니다. 이름이 거기서 왔으니 화면도 명세서처럼 만들어 볼까 싶었습니다.

하고 싶었지만 안 한 것

처음 떠오른 건 항목 이름을 아예 바꾸는 것이었습니다. 「만든 것」을 Application으로, 「기록」을 Description으로요.

그런데 과해 보였습니다. 들어온 사람이 무슨 페이지인지 바로 알아야 하는데, 영문 명세서 용어가 앞에 서 있으면 그게 안 됩니다.

그래서 이름은 그대로 두고 부제로만 달았습니다. 「만든 것」 아래 작게 Application, 「기록」 아래 작게 Description. 아는 사람은 알아보고, 모르는 사람은 그냥 부제로 읽고 넘어갑니다.

이 선이 이후로도 기준이 됐습니다 — 비유가 콘텐츠를 가리면 안 된다.

필요해져서 붙은 것

나머지는 씌운 게 아니라 붙었습니다.

기록 초안을 써놓고 다시 읽는데, 글 맨 위에 무엇이 문제였고 어떻게 풀었는지 두 줄이 있으면 좋겠다 싶었습니다. 그게 필요해서 만든 자리인데, 명세서에 마침 같은 자리가 있었습니다 — SUMMARY의 과제와 해결 수단입니다. 이름을 따로 지을 이유가 없어서 그대로 가져왔습니다. 그 아래 본문을 가르는 표제도 자연스레 DETAILED DESCRIPTION이 됐습니다.

목록 번호도 그렇게 붙었습니다. 어느 것을 말하는지 가리킬 방법이 필요했고, 출원번호처럼 연도와 번호로 구성했습니다(26-01). 기록에는 단락번호꼴로 [0001]을 달았습니다.

순서가 이랬습니다. 자리를 먼저 만들어 놓고 채운 게 아니라, 필요해서 만든 자리에 마침 맞는 이름이 명세서에 있었습니다.

주소까지는 내려갔다

부제로만 쓰던 Application·Description을 나중에 주소와 폴더 이름까지 맞췄습니다 — /works는 /application으로, /log는 /description으로. 밖에 나가 있는 옛 주소가 죽지 않도록 영구 이동으로 받아 넘깁니다.

「읽은 것」은 /background로 뒀습니다. 이건 억지가 아니라 「발명의 배경이 되는 기술」과 실제로 맞아떨어지는 자리라서, 비유를 씌우기 전부터 이름이 그랬습니다.

구조 전체를 맞추지는 않았다

명세서에는 항목이 정해져 있습니다. 발명의 명칭, 기술분야, 배경기술, 해결하려는 과제, 과제의 해결 수단, 발명의 효과, 도면의 간단한 설명, 발명을 실시하기 위한 구체적인 내용, 요약서.

사이트 페이지를 여기에 하나씩 맞추는 안도 생각해 봤습니다. 소개는 「기술분야」, 이런 식으로요.

안 했습니다. 그렇게 하면 순서가 뒤집힙니다. 쓸 게 있어서 자리를 만드는 게 아니라, 자리가 있어서 쓸 걸 찾게 됩니다. 그렇게 만든 자리는 안 채워지거나, 채우려고 쓴 글이 들어갑니다.

여기까지가 끝입니다. 남은 항목에 페이지를 맞추는 일은 하지 않습니다.

멈춘 자리가 마침 맞았다

멈추고 보니, 붙어 있던 것들이 한 벌로 맞아떨어져 있었습니다.

기록 한 편을 열면 위에서부터 SUMMARY(과제·수단) → DETAILED DESCRIPTION(본문) 순으로 내려갑니다. 명세서를 읽는 순서 그대로입니다. 맞추려고 만든 게 아니라 글에 원래 필요했던 자리라 억지가 없습니다.

DETAILED DESCRIPTION은 덤이 하나 더 있습니다. 설명충의 영어 정의이기도 합니다. 이 사이트 이름이 거기서 나왔습니다.