핵심 요약
- 자동 발행된 첫 devlog 글이 자기 자신을 '초안'이라고 지칭했다. 실제로는 검토 없이 즉시 공개되는데도 그렇게 썼다.
- 원인은 워크플로우의 step 이름이 'Create devlog draft'로 남아 있었기 때문이다. AI가 diff에서 이 단어를 읽고 그대로 믿었다.
- step 이름을 'Publish devlog'로 바꾸고, 메모에도 즉시 발행된다는 사실을 명시해 같은 오독을 구조적으로 막았다.
- 나머지 감점인 깊이 부족은 프롬프트 규칙 보강과 재료 확대로 다뤘다. diff 발췌를 120줄에서 200줄로, 본문 분량 목표를 1,800~2,800자로 늘렸다.
거짓말은 프롬프트가 아니라 파일 이름에서 나왔다
hyeonwoo.co.kr에는 푸쉬가 감지되면 커밋 기록을 재료로 삼아 개발 일지를 자동으로 써서 즉시 공개하는 파이프라인이 있다. 검토 단계는 없다. 그래서 이 글도 지금 그렇게 발행되고 있다.
첫 자동 발행 글을 채점했더니 82점이었다. 가장 큰 감점 사유는 정확성이었다. 글이 스스로를 '초안'이라고 불렀는데, 실제로는 그 순간 이미 공개된 상태였다. 처음에는 프롬프트에 명시적 지시가 부족했다고 생각했다. 그런데 원인을 추적해보니 다른 곳에 있었다. 워크플로우 파일의 step 이름이 여전히 'Create devlog draft'였던 것이다.
AI는 커밋 diff를 재료로 글을 쓰는데, 그 diff 안에 'draft'라는 단어가 곳곳에 박혀 있었다. AI 입장에서는 자연스러운 추론이었다. 파일 이름이 그렇다고 말하니 그렇게 믿은 것뿐이다. 프롬프트를 아무리 정교하게 다듬어도 입력 재료 자체가 틀린 사실을 말하고 있으면 결과는 그 재료를 따라간다. 이번 경험에서 얻은 가장 분명한 교훈은, AI 출력의 오류를 프롬프트 규칙으로 억지로 막기 전에 먼저 입력 데이터가 사실과 일치하는지부터 점검해야 한다는 것이다.
- - name: Create devlog draft
+ - name: Publish devlog
run: node scripts/create-devlog-from-push.mjs이름을 고치는 것만으로는 부족해서 명시적으로 못 박았다
step 이름을 바꾼 것만으로 안심할 수는 없었다. 이름은 언젠가 또 어긋날 수 있고, 코드 변수명이나 파일 경로 어딘가에 비슷한 오해의 소지가 남아 있을 수 있다. 그래서 메모 자체에 사실을 명문화했다.
이름을 바로잡는 것과 사실을 명시하는 것, 두 가지를 같이 했다. 하나만 했다면 다음에 또 비슷한 단어가 diff에 섞여 들어올 때 같은 문제가 재발할 수 있었다.
- "이 커밋들이 어떤 문제를 풀려고 한 것인지 커밋 메시지에서 추론해 글의 중심에 놓아라.",
+ "참고로 이 글은 초안이 아니다. 푸쉬가 감지되면 검토 없이 즉시 공개 발행되는 파이프라인이다. 시스템 동작을 언급할 때 이 사실과 다르게 쓰지 마라.",
+ "이 커밋들이 어떤 문제를 풀려고 한 것인지 커밋 메시지에서 추론해 글의 중심에 놓아라. 커밋 메시지가 간결하면 diff에서 의도를 읽어내라.",깊이 부족은 규칙과 재료 두 방향에서 동시에 메웠다
정확성 문제를 잡았다고 감점이 다 사라지는 건 아니었다. 남은 감점은 글의 깊이였다. 그래서 프롬프트에 마무리 방식과 서술 태도에 관한 규칙을 추가했다. 마지막 본문 섹션은 다짐이나 예고가 아니라 이번 경험에서 뽑은 일반 원칙 한 문장으로 닫으라고 했고, 메모에 없는 시스템 동작은 단정하지 말라고 했고, 소제목만 순서대로 읽어도 주장이 이어지게 쓰라고 했다.
동시에 재료도 늘렸다. diff 발췌는 120줄에서 200줄로, 본문 분량 목표는 1,800~2,800자로 넓혔다. 규칙을 정교하게 다듬는 것과 재료를 넉넉하게 주는 것, 둘 중 하나만으로는 부족하다고 봤다. 규칙이 아무리 좋아도 diff가 120줄에서 끊기면 뒷부분의 맥락을 놓치고, 재료가 아무리 많아도 마무리 규칙이 없으면 글이 흐지부지 끝난다.