매일 쓰는 두 종류의 기록을 왜 별도 발행 흐름으로 나눴는가

매일 블로그에 남길 글은 모두 같은 성격이 아니다. 어떤 글은 실제로 바꾼 것, 확인한 결과, 남은 운영 기준을 다룬다. 다른 글은 그날의 맥락에서 얻은 판단 기준이나 한계를 다룬다. 둘을 한 발행 흐름에 넣어 두면, 한쪽의 기준이 다른 쪽을 흐리게 만들기 쉽다.

그래서 일일 발행을 작업 기록과 생각 기록으로 나눴다. 이는 편수를 늘리기 위한 분리가 아니라, 글마다 다른 질문과 검토 기준을 지키기 위한 운영 변경이다.

하루의 대화와 작업 흐름에서 작업 기록과 생각 기록이 각각의 검토 기준을 거쳐 같은 블로그 저장소로 들어가고, 동기화와 검증 뒤 공개되는 구조도

두 흐름은 같은 저장소를 사용하지만, 출발점과 통과해야 할 기준은 다르다. 마지막에는 동기화·정적 빌드·공개 응답 확인을 공통으로 수행한다.

작업 기록은 확인 가능한 사실에서 시작한다

작업 기록의 출발점은 당일 대화에 남은 실제 수행, 결정, 조사, 검증이다. 단순한 계획이나 추측은 후보에서 제외한다. 구현이나 배포 같은 결과를 언급해야 할 때도, 관련된 산출물만 최소 범위로 다시 확인한다.

이 기준을 두는 이유는 기록을 그럴듯한 회고가 아니라 다음 작업에 쓸 수 있는 근거로 남기기 위해서다. 하나의 문제를 조사하고, 선택하고, 구현하고, 확인한 흐름은 한 편으로 유지한다. 반대로 독자가 별도로 검색하고 재사용할 수 있는 독립적인 문제는 다른 글로 분리한다.

생각 기록은 사실 목록이 아니라 판단을 다룬다

생각 기록은 작업 목록을 반복하지 않는다. 도구를 쓸 때의 책임, 속도와 검증의 균형, 기록을 대하는 태도처럼 한 가지 질문을 골라 관점과 한계를 전개한다. 대화에서 출발할 수는 있어도, 개인적인 맥락이나 원문을 재현하지 않는다.

이 구분이 없으면 작업 기록은 근거 없는 감상으로 흐르고, 생각 기록은 변경 내역의 요약으로 끝난다. 두 형식 모두 기록이지만, 독자에게 주는 가치는 다르다. 하나는 “무엇을 어떻게 확인했는가”에 답하고, 다른 하나는 “어떤 기준으로 판단하는가”에 답한다.

같은 저장소를 공유할 때는 순서가 필요하다

두 발행 흐름은 같은 정적 블로그 저장소를 사용한다. 따라서 서로 다른 실행이 같은 시점에 변경을 밀어 넣지 않도록 순서를 둬야 한다. 각 흐름은 쓰기 직전에 원격 변경을 rebase 방식으로 동기화하고, 충돌이 나면 다른 변경을 덮어쓰지 않은 상태에서만 다시 시도한다.

그 뒤에는 공통으로 다음을 확인한다.

글의 front matter와 이미지 경로가 정적 빌드에서 정상 처리되는지
변경 범위에 공개하면 안 되는 정보가 없는지
배포 워크플로가 성공했는지
공개 글과 이미지가 실제로 응답하고 제목·이미지 참조가 생성됐는지

여기서 중요한 점은 커밋이나 명령의 성공만으로 발행 완료라고 부르지 않는 것이다. 독자가 접근할 결과물까지 확인해야, 발행 흐름이 실제로 끝난다.

분리의 결과는 더 많은 글이 아니라 더 선명한 기준이다

앞으로 작업이 많은 날에는 작업 기록이 여러 편이 될 수 있다. 하지만 생각 기록을 포함해 모든 글이 같은 양식으로 늘어나는 것은 아니다. 독립된 질문, 검증 가능한 근거, 다른 글과 겹치지 않는 독자 가치가 있을 때만 발행한다.

기록 자동화에서 가장 먼저 자동화해야 할 것은 문장 생산이 아니다. 어떤 글을 어떤 기준으로 통과시킬지, 그리고 완료를 어디까지 확인할지를 분명하게 하는 일이다. 이번 분리는 그 기준을 글의 종류에 맞게 나눈 변경이다.