[블로그를 파이프라인으로 만들기] 0. 초안까지만 자동화한 이유
기술 블로그를 오래 못 쓰는 이유는 글재주가 아니라 매번 백지에서 시작해야 한다는 것이다. 쓸 이야기는 이미 쌓여 있는데, 그걸 글의 형태로 옮기는 첫 30분이 매번 새로 든다.
그래서 이 블로그는 그 30분을 파이프라인에 넘겼다. 다만 발행까지 넘기지는 않았다.
자동화한 것과 하지 않은 것
| 단계 | 누가 |
|---|---|
| 글감 발굴·우선순위 | 파이프라인 |
| 민감정보 탈맥락화 검사 | 파이프라인 |
| 초안 작성 | 파이프라인 |
| 사실 검증·문장 다듬기 | 사람 |
| 발행 | 사람 |
경계를 여기 그은 이유는 두 가지다.
첫째, 초안 자동 발행형 블로그는 오래 못 간다. 내용에 책임을 지는 주체가 없으면 글이 점점 검색 결과의 재조합으로 수렴한다. 그건 읽을 이유가 없는 글이다.
둘째, 내 글감의 대부분이 회사 프로덕션 이야기다. 근본 원인, 실제 수치, 티켓 번호가 붙어 있다. 이건 그대로 나가면 안 된다. 그래서 탈맥락화를 사람의 기억에 의존하는 체크리스트가 아니라 파이프라인의 한 단계로 박아뒀다.
draft 플래그가 이중 안전장치다
자동화가 만든 초안은 항상 draft: true로 떨어진다. 그리고 프로덕션 빌드는 draft를 렌더하지 않는다.
function isVisible(post: Post): boolean {
return !post.draft || process.env.NODE_ENV !== "production";
}즉 머지는 발행이 아니다. 실수로 초안 PR이 머지돼도 사이트에는 나오지 않는다.
발행은 draft: false로 바꾸는 별도의 명시적 행동이다.
이런 구조를 좋아하는 이유는, 사고가 나려면 두 번 실수해야 하기 때문이다. 한 번의 부주의로는 아무 일도 일어나지 않는다.
조용한 실패보다 터지는 게 낫다
frontmatter에 title이나 date가 없으면 빌드가 실패한다. 빈 값으로 렌더하지 않는다.
자동화가 파일을 잘못 만들었을 때, 조용히 제목 없는 글이 배포되는 것보다 빌드가 멈추는 게 낫다. 발견되지 않는 실패가 가장 비싸다.
이건 일하면서 배운 것이다. 운영에서 가장 오래 살아남는 버그는 예외를 던지는 버그가 아니라, 아무 에러 없이 화면에서 조용히 사라지는 버그였다.