작업 기록
왜 블로그의 첫 화면을 글 목록으로 바꿨는가
소개보다 기록을 먼저 보여주고, 나중에 다시 찾을 수 있는 구조를 택한 이유.
블로그를 손보는 일은 처음에는 색과 간격을 고르는 일처럼 보였다. 실제로는 그보다 앞선 질문이 있었다. 이곳에 들어온 사람이 무엇을 가장 먼저 보아야 하는가.
처음 화면에는 사이트의 성격을 설명하는 문장, 대표 글, 탐색 안내, 최근 글을 함께 두었다. 각각은 틀린 요소가 아니었다. 하지만 글을 읽으러 온 사람에게는 첫 화면에서 해야 할 판단이 너무 많았다. 이 블로그가 어떤 곳인지 이해하기 전에, 정작 기록 목록까지 내려가야 했다.

소개는 필요한데, 첫 화면의 주인은 아니다
이 블로그의 목적은 자신을 소개하는 일이 아니라 작업 중에 남긴 판단을 다시 읽고 찾는 일이다. 그래서 선언적인 문장은 소개 페이지로 보내고, 홈에서는 최근 기록을 바로 보여주기로 했다.
이 결정으로 홈의 역할은 단순해졌다. 최신 글을 읽고, 시간순이면 아카이브로, 관심사 기준이면 태그로 이동한다. 각 페이지가 서로 다른 질문에 답하게 한 것이다. 홈은 “무엇을 읽을까”, 아카이브는 “언제 했지”, 태그는 “어떤 주제였지”를 맡는다.
매일 기록이 쌓이면 검색이 탐색의 중심이 된다
앞으로 작업 기록이 매일 쌓인다면 시간순 목록과 태그만으로는 부족해진다. “지난번에 자동 발행의 중복을 어떻게 막기로 했지?”, “favicon을 왜 다시 만들었지?” 같은 질문은 정확한 날짜나 태그를 기억하지 못해도 생긴다.
그래서 별도 서버나 외부 검색 서비스를 붙이지 않고, Jekyll이 글의 제목·설명·태그·본문을 담은 정적 인덱스를 만들도록 했다. 검색은 /, ⌘K, Ctrl+K 또는 헤더의 검색 버튼으로 열리고, 결과는 곧바로 글로 연결된다. 정적 사이트의 가벼움은 유지하면서도 기록을 다시 찾는 경로를 만들었다.
남은 기준
글이 많아진다고 모두 같은 무게를 가질 필요는 없다. 홈은 글을 보여주되 과장하지 않고, 검색은 필요한 맥락을 되찾게 해야 한다. 그리고 자동 발행 역시 날짜가 아니라 독립적인 작업 단위를 기준으로 판단해야 한다.
디자인을 덜어낸 이유도 같다. 기록을 보기 위한 화면에서 화면 자체가 너무 많은 설명을 시작하면, 정작 남겨 둔 판단은 뒤로 밀린다. 다음 작업을 위한 여백은 장식이 아니라, 다시 읽기 쉬운 순서에서 만들어진다.
CONTINUE READING
기록맥락은 공짜가 아니다: 에이전트가 무엇을 남기고 무엇을 버려야 하는가→기록증거는 읽히기 위해, 계승을 도와야 한다→