핵심 요약
- 개인 사이트 hyeonwoo.co.kr 저장소에 main 브랜치 푸시를 감지해 devlog 초안을 자동으로 만드는 워크플로(devlog-from-push.yml)를 새로 추가했다.
- 기존에 수동으로 카테고리를 선택해 글 초안을 만들던 두 워크플로(create-blog-draft.yml, create-draft.yml)에 project 카테고리를 추가해, 개발 기록도 정식 카테고리로 다룰 수 있게 했다.
- 커밋 메시지에 [skip blog]가 있으면 자동 생성을 건너뛰도록 조건을 걸어, 모든 푸시가 글이 되지는 않게 최소한의 안전장치를 뒀다.
- 결국 이 글도 그 워크플로가 만든 초안에서 출발했다.
커밋은 쌓이는데 글은 안 쓰였다
코드를 고치고 커밋을 남기는 일과, 그걸 글로 정리하는 일 사이에는 항상 시차가 있었다. 커밋할 때는 왜 이렇게 바꿨는지 머릿속에 다 있는데, 며칠 지나면 그 맥락은 흐려지고 결국 안 쓰고 넘어가는 경우가 많았다. 블로그에 project 카테고리를 만들어놓고도 실제로 개발 기록이 잘 안 쌓이는 이유가 여기 있었다. 글을 쓰려면 별도로 시간을 내서 "오늘 뭐 했지"를 되짚어야 하는데, 그 진입장벽 자체가 컸다.
그래서 이번에는 글을 쓰는 행위 자체를 커밋 이후로 미루지 않고, 커밋이 일어나는 순간에 끼워 넣기로 했다. main에 푸시가 발생하면 자동으로 devlog 초안이 하나 만들어지게 하는 것이다. 사람이 나중에 기억을 더듬어 글감을 찾는 게 아니라, 커밋 직후 아직 맥락이 생생할 때 초안이라도 만들어두면 나중에 다듬기만 하면 된다는 계산이었다.
자동화는 만들었지만 전부 자동으로 남기지는 않기로 했다
devlog-from-push.yml의 핵심은 push 이벤트를 트리거로 잡고, before/after 커밋 SHA를 환경변수로 넘겨서 이번 푸시에 어떤 변경이 있었는지 스크립트가 판단하게 한 부분이다.
여기서 두 가지를 의도적으로 넣었다. 하나는 `if` 조건으로, 커밋 메시지에 `[skip blog]`가 들어 있으면 아예 실행 자체를 건너뛰게 했다. 오타 수정이나 워크플로 파일 자체를 손보는 것처럼 글로 남길 가치가 없는 푸시까지 전부 초안으로 만들면, 오히려 devlog 목록이 노이즈로 뒤덮인다. 자동화를 걸되 예외를 남겨두는 쪽이, 무조건 다 기록하는 것보다 실용적이라고 판단했다.
다른 하나는 `IDEMPOTENCY_KEY`다. 같은 푸시로 워크플로가 여러 번 실행되거나 재시도되는 경우에도 초안이 중복 생성되지 않도록 커밋 SHA 기반의 키를 넘겼다. 자동화를 만들 때 가장 신경 쓰이는 부분은 결과물 자체보다 "실수로 여러 번 실행됐을 때 뭐가 깨지는가"였는데, 최소한 중복 생성 문제는 이 키로 막아둔 셈이다.
on:
push:
branches:
- main
jobs:
create-devlog:
if: "!contains(github.event.head_commit.message, '[skip blog]')"
runs-on: ubuntu-latest
env:
BEFORE_SHA: ${{ github.event.before }}
AFTER_SHA: ${{ github.event.after }}
IDEMPOTENCY_KEY: push-${{ github.event.after }}
MODE: now
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 0
- name: Create devlog draft
run: node scripts/create-devlog-from-push.mjs카테고리에 project를 넣은 것도 같은 맥락이다
create-blog-draft.yml과 create-draft.yml은 원래 수동으로 글 초안을 만들 때 카테고리를 고르는 워크플로였는데, 여기 project 옵션이 빠져 있었다. business, investment, reading은 있는데 정작 지금 하고 있는 개발 작업을 담을 자리가 없었던 것이다. 이번에 devlog 자동화를 만들면서 자연스럽게 이 빈칸도 채웠다. 자동으로 만들어지는 devlog든 수동으로 쓰는 글이든, 개발 기록이 갈 자리를 카테고리 단계에서부터 명확히 해두고 싶었다.
돌이켜보면 이번 작업은 새로운 기능을 만든 게 아니라, 내가 이미 하고 있던 일(커밋)과 하고 싶었지만 자꾸 미루던 일(기록) 사이의 간격을 좁힌 것에 가깝다. 자동화로 완성도 높은 글이 나오는 건 아니고, 나중에 다듬는 과정은 여전히 필요하다. 다만 "쓸까 말까"를 고민하는 단계 자체를 없앤 게 이번 변경의 핵심이다.