카테고리를 아무리 나눠도 읽는 순서는 안 고쳐졌다

파이썬으로 보안 도구를 만들어 본 기록이 여덟 편 쌓였다. 뒤 편이 앞 편의 산출물을 조립하는 구조라 순서대로 읽어야 뜻이 사는데, 목록은 게시일 역순이라 항상 마지막 편이 맨 위에 있다. 처음 온 사람은 완성된 파이프라인을 먼저 보고 그다음에 그 부품을 보게 된다.

처음에는 카테고리 문제라고 생각했다. 카테고리를 더 잘게 나누면 같은 묶음끼리 모일 테니 순서도 따라올 것 같았다. 나눠 보니 모이기는 하는데 순서는 그대로였다. 카테고리 안에서도 정렬은 게시일 역순이기 때문이다.

순서는 분류가 아니다. 카테고리를 어떻게 나눠도 고쳐지지 않는 이유가 이거였다. 「무엇에 대한 글인가」와 「이 여덟 편을 어떤 순서로 읽나」는 다른 질문이고, 다른 질문에는 다른 축이 필요하다.

카테고리를 대체하지 않고 겹쳐서 쓴다

그래서 시리즈를 카테고리와 별개의 축으로 뒀다. 글 하나가 카테고리도 갖고 시리즈도 갖는다. 시리즈에 넣었다고 카테고리를 떼지 않는다 — 「이 사람이 클라우드를 다뤄 봤나」에 답하는 것은 여전히 카테고리이기 때문이다.

시리즈 목록만 오름차순으로 보여 준다. 편 번호는 게시일과 별개로 두었다. 나중에 쓴 글을 2편으로 끼워 넣는 경우가 실제로 생기는데, 게시일에 순서를 묶어 두면 그때 날짜를 거짓으로 적게 된다.

대신 편 번호에는 검증을 걸었다. 같은 시리즈 안에서 중복될 수 없고, 1부터 빈칸 없이 이어져야 한다. 검증 스크립트가 그것을 본다. 순서를 나타내려고 만든 값이 어긋난 채로 있으면 아무 정보도 아니게 된다.

시리즈 자체는 파일 하나에 정의하고 id 가 곧 주소가 된다. 글의 frontmatter 에 적은 id 가 그 목록에 없으면 빌드가 멈춘다. 이 저장소에서 반복해서 쓰는 방식이다 — 값의 목록을 한 곳에 두고, 없는 값을 쓰면 실패하게 만든다.

출처를 분류로 만들지 않았다

시리즈를 만들면서 같이 정한 것이 있다. 「어디서 배웠나」는 카테고리나 시리즈로 만들지 않는다.

수업이나 행사 같은 출처는 분류로 삼기 좋아 보인다. 실제로 그 시점에는 글이 대부분 한 출처에서 나오니까 깔끔하게 묶인다. 문제는 글이 쌓일수록 그 라벨이 전체 글과 같아진다는 것이다. 전부에 붙는 라벨은 아무것도 나누지 못한다. 그리고 그 수업이 끝나면 라벨만 남는다.

그래서 출처는 태그로 둔다. 태그는 자유롭게 붙이고 없어져도 구조가 흔들리지 않는 자리다. 축을 세 개로 정리하면 이렇게 된다 — 카테고리는 주제로 하나, 시리즈는 순서가 있을 때만 선택, 태그는 주제가 아닌 사실.

시리즈와 개발일지는 같은 자리를 노린다

시리즈를 넣고 나서 알게 된 제약이 하나 있다. 개발일지는 시리즈에 넣을 수 없다. 시리즈 목차를 만드는 쪽이 개발일지를 제외하기 때문에, 넣으면 목차가 빈 채로 나간다.

처음에는 버그로 보였는데 따져 보니 그렇지 않았다. 두 장치가 같은 일을 한다 — 흩어진 글을 순서대로 모아서 보여 주는 것. 개발일지는 프로젝트 상세에 모이고 시리즈는 시리즈 페이지에 모이는데, 한 글이 양쪽에 걸리면 「이 글의 목록은 어디인가」가 갈린다.

그래서 지금 쓰는 이 개발일지들에는 편 번호를 붙이지 않는다. 프로젝트 상세의 목록이 게시일 오름차순으로 정렬되므로 순서는 이미 있고, 여기에 번호까지 적으면 프로젝트가 둘이 됐을 때 어느 목록과도 맞지 않는 번호가 본문에 남는다.

지금 시리즈는 두 개다. 이 축이 실제로 도움이 되는지는 아직 모른다 — 순서대로 읽으라고 만들어 둔 것을 순서대로 읽는 사람이 있는지 확인할 방법이 없기 때문이다. 확인할 수 있는 것은 목록을 열었을 때 1편이 맨 위에 있다는 것까지다.