Blog system notes 4. 두 가지 글쓰기 기준을 세웠습니다

Blog system notes를 공개 순서로 다시 잡아 보니, 글쓰기 기준은 첫 글보다 마지막 글에 가까웠습니다.

원본 구조, 검색 제출, 발행 queue를 정리해도 마지막에 남는 질문이 있습니다. 그럼 실제 글은 어떤 기준으로 고칠 것인가.

그래서 마지막에는 글을 분류하는 기준을 다시 세웠습니다. AI 시대 감각을 해석하는 글과, 제품 개발 과정이나 학습 내용을 설명하는 글은 같은 블로그에 있어도 독자에게 하는 약속이 다르기 때문입니다.

그래서 AI Survival Log의 글쓰기 기준을 두 갈래로 정리했습니다. 하나는 성찰형 에세이입니다. 다른 하나는 정보전달형 기록입니다. 이번 글은 그 분리 기준과, 제목과 소제목의 기호 규칙까지 하네스로 고정한 과정을 정리한 기록입니다.

기존 에세이 문체는 버릴 대상이 아니었습니다

처음에는 문제를 문체의 문제로만 볼 수도 있었습니다.

어떤 글은 감각과 해석이 앞에 있어야 하고, 어떤 글은 상태와 근거가 먼저 나와야 했습니다. 그런데 제품 개발기나 학습 기록까지 모두 같은 성찰형 문장으로 쓰면, 독자가 필요한 정보를 찾기 어렵습니다.

그렇다고 기존의 에세이 문체를 버릴 이유는 없었습니다. AI를 쓰며 달라진 감각, 개인적인 해석, 어떤 비유를 통해 겨우 붙잡은 시대감은 이 블로그의 중요한 축입니다. 그 글들은 계속 성찰형 에세이로 남기는 것이 맞다고 판단했습니다.

그래서 문제는 어느 방식이 더 좋은가가 아니었습니다.

문제는 글마다 어떤 독자 약속을 먼저 세우느냐였습니다.

문제는 문장 길이가 아니라 독자 약속이었습니다

새로 나눈 두 가지 글쓰기 기준은 편의상 P1과 P2로 부르기로 했습니다.

P1은 성찰형 에세이입니다. 이 기준은 AI 시대를 지나며 생긴 감각, 불안, 해석, 비유를 다룹니다. 독자가 이 글에서 기대하는 것은 빠른 상태표보다, 어떤 관점을 발견했는지에 가깝습니다.

P2는 정보전달형 기록입니다. 이 기준은 프로젝트 상태, 선택지, 근거, 검증, 남은 한계를 설명합니다. LazyPad 개발기, CodeTree 학습 기록, LLM 공부 시리즈, 시스템 설계 스터디 같은 글은 대부분 여기에 들어갑니다.

이 구분은 문장을 짧게 쓰기 위한 규칙이 아닙니다. 글을 읽는 사람이 첫 화면에서 무엇을 기대해야 하는지 맞추기 위한 규칙입니다.

구분	독자 약속	기본 사용처
P1 성찰형 에세이	AI 시대 감각과 개인적인 해석을 보여줍니다	AI 시대 에세이, 개념과 성찰이 섞인 글
P2 정보전달형 기록	상태, 선택, 근거, 검증, 한계를 분리해 설명합니다	개발기, 학습 기록, 운영 구조, 도구 검토

이 표를 만든 뒤부터 글을 고칠 때 질문이 단순해졌습니다.

이 글은 무엇을 느꼈는지 보여주는 글인가. 아니면 무엇을 판단했고 어떻게 확인했는지 설명하는 글인가.

제목과 소제목에도 같은 기준이 필요했습니다

기준을 나눈 뒤에는 제목과 소제목도 다시 보였습니다.

이전에는 제목 안에서 :, -, | 같은 기호를 자연스럽게 썼습니다. 짧은 제목을 만들기에는 편했습니다. 하지만 글이 많아질수록 문제가 생겼습니다. 어떤 제목은 카드처럼 보이고, 어떤 제목은 내부 작업명처럼 보였고, 어떤 제목은 시리즈 안에서 규칙이 달라 보였습니다.

특히 정보전달형 글에서는 제목과 소제목이 독자의 스캔 경로가 됩니다. 독자는 모든 문장을 처음부터 끝까지 읽기 전에, 제목과 소제목만 보고 이 글이 필요한지 판단합니다.

그래서 P2 글에서는 보이는 제목과 소제목에서 장식적인 구분 기호를 줄이기로 했습니다.

허용해야 하는 예외도 있습니다. Wi-Fi, source-of-truth, dry-run, 파일 경로, URL, 코드 값처럼 기술적으로 필요한 기호는 보존합니다. 하지만 제목을 멋있게 나누기 위한 기호는 줄입니다.

규칙의 목표는 글을 단조롭게 만드는 것이 아닙니다. 독자가 글의 구조를 덜 힘들게 읽도록 만드는 것입니다.

48개 발행 글을 같은 기준으로 다시 봤습니다

규칙을 세운 뒤에는 실제 발행 글을 다시 봐야 했습니다.

현재 공개된 글은 48개였습니다. 그중 위키가 source-of-truth인 글은 42개였고, 오래전에 사이트 쪽에만 남아 있는 legacy 글은 6개였습니다.

이 글들을 모두 같은 기준으로 분류했습니다.

Track	Count	판단
AI-era essay	8	P1 성찰형 에세이로 유지합니다
Study and learning	22	P2 학습 기록으로 유지합니다
Product development log	4	P2 LazyPad 개발기로 유지합니다
Agent harness and automation	13	P2 운영과 자동화 기록으로 유지합니다
Blog system notes	1	블로그 시스템 자체를 다루는 제한 트랙으로 둡니다

이 분류에서 중요한 결론은 하나였습니다. 블로그에서 작성됐다고 해서 모든 글이 Blog system notes가 되는 것은 아닙니다. 위키를 거쳐 발행됐다고 해서 모든 글이 위키 운영기가 되는 것도 아닙니다.

LazyPad 글은 제품 개발기입니다. CodeTree 글은 학습 기록입니다. Agent Harness 글은 운영과 자동화 기록입니다. 블로그와 위키는 그 글들이 만들어지고 발행되는 경로이지, 모든 글의 주제가 아닙니다.

기존 글의 날짜와 주소는 바꾸지 않았습니다

발행된 글을 다시 볼 때 가장 조심한 것은 날짜와 주소였습니다.

문체를 다듬거나 제목 기호를 정리한다고 해서 이미 공개된 글의 created, updated, slug, 날짜가 들어간 output path, downstream post path를 바꾸면 안 됩니다. 독자에게 공개된 글의 주소는 글쓰기 규칙보다 더 강한 계약이기 때문입니다.

그래서 이번 정리는 글의 기준을 세우는 작업으로 제한했습니다. 기존 글의 발행일과 주소를 새 규칙에 맞춰 조용히 바꾸지 않았습니다.

이 점은 앞으로도 같은 기준으로 가져가려고 합니다. 새 글에는 새 규칙을 적용합니다. 기존 발행 글을 고칠 때는 내용과 주소 계약을 분리해서 판단합니다.

이 글은 블로그 운영기가 아니라 블로그 시스템 노트입니다

이 글을 쓰면서 일부러 넓은 이름을 피했습니다.

블로그와 위키 운영기라고 부르면 편합니다. 하지만 그 이름은 너무 넓습니다. 앞으로 쓰는 모든 글이 블로그와 위키를 거쳐 만들어진다는 이유만으로 그 시리즈에 들어갈 위험이 있습니다.

그래서 이 트랙은 Blog system notes로 제한했습니다.

이 트랙에 들어오는 글은 블로그, 위키, 사이트, 발행 파이프라인 자체가 주제인 경우입니다. 예를 들면 글쓰기 페르소나, source-of-truth 구조, SEO 제출 기록, content와 build와 deploy queue 같은 내용입니다.

반대로 제품 개발기, 학습 기록, 하네스 운영 기록은 자기 트랙에 남깁니다.

앞으로 글을 쓸 때는 "무슨 시리즈인가"보다 먼저 "독자에게 어떤 약속을 하는 글인가"를 고릅니다. 그 다음에 페르소나를 고르고, 마지막으로 시리즈를 고릅니다.

이번에 세운 규칙은 그 순서를 잊지 않기 위한 장치입니다.