개발 중 남긴 개인 TIL에는 실패한 테스트와 선택의 이유가 흩어져 있습니다. 여기서 공개할 근거를 골라 원고를 쓰더라도, 글을 언제 공개할지는 블로그마다 다른 규칙을 따릅니다. 초기 coco-blog는 공개 전환을 Hugo의 draft: false로 고정했습니다. 1.2.0을 준비하면서 원본 노트를 글로 편집하는 과정과 프로젝트마다 달라지는 게시 절차를 분리했습니다. 1.2.0 검증 기록

글감의 근거 고르기

글감은 작성자가 직접 했거나 확인한 작업에서 고릅니다. 예를 들어 한 노트에 재시도 중복을 확인한 테스트가 있고 다른 노트에 수정 후 재현 결과가 있다면, 둘을 엮어 문제를 어떻게 발견하고 검증했는지 설명할 수 있습니다. 초안에는 독자가 재현과 판단을 이해하는 데 필요한 부분을 옮기고, 원본 노트는 그대로 둡니다. 이미 작성자가 고쳐 둔 원고는 그 내용을 읽고 이어 씁니다. 원본을 다시 가져온다는 이유로 기존 문장을 덮어쓰지 않습니다.

Team Edo 블로그에서는 공개 원고를 별도로 작성하고 draft: true로 검토합니다. 애플리케이션 작업 브랜치에서 시작했더라도 글은 블로그 기준 브랜치에서 따로 다룰 수 있습니다. 이렇게 하면 개발 작업과 글의 변경 이력이 섞일 일이 줄고, 로컬 TIL에서 공개할 대목을 작성자가 직접 고를 수 있습니다.

초안과 게시 검증

공개 여부를 기록하는 방식은 블로그마다 다릅니다. Hugo는 draft를 쓰고, 다른 블로그는 status나 published를 쓸 수 있습니다. coco-blog는 실제 프로젝트 안내를 먼저 읽고 그 저장소의 상태 전환을 따릅니다. 원고 검토, 커밋·푸시, 게시 요청 생성, 실제 공개는 각 단계의 권한과 확인 방법이 다릅니다. 예를 들어 원고 방향에 동의해도 글은 계속 초안 상태로 남을 수 있습니다.

출시 전에는 실제 Codex에서 네 가지 시나리오를 한 번씩 실행했습니다. 글감 선택, status: draft로 초안 저장, 승인을 받은 published: true 전환, 기존 Hugo 게시 절차 보존을 각각 확인했습니다. Codex와 Claude Code용 설치기는 임시 경로에서 업데이트와 재설치, 개인 파일 보존, 이전 버전 복구를 확인했습니다. Claude Code에서 글쓰기 대화를 실행하는 검증과 실서비스 공개는 이 시나리오의 범위 밖이었습니다. COCO 1.2.0 릴리스 및 검증 기록