AI 개발일지의 거짓 정보, git 사실 시트로 막은 방법

개발일지를 손으로 쓰는 시간이 아까워서, 초안 작성을 AI에게 맡겨 봤어요. 혼자 운영하면서 제품 개발과 글쓰기를 같이 하려니, 반복을 줄여줄 작은 도구가 필요했거든요.

그런데 AI가 쓴 초안을 읽다 보면 묘하게 불편한 순간이 있어요. 하지 않은 작업이 완료된 것처럼 적혀 있거나, 잰 적도 없는 개선폭이 수치로 등장하는 식이에요. 혹시 비슷한 경험 없나요?

금지어 목록만으로는 못 막아요

처음엔 "과장 표현 금지" 같은 규칙을 프롬프트에 쌓았어요. 적용해 봤더니 표현은 얌전해지는데 내용의 거짓말은 그대로였어요. LLM은 빈칸을 그럴듯하게 채우는 데 능하니까요.

그래서 접근을 바꿨어요. 완성된 문장을 검사하는 대신, 글의 근거 자체를 고정하기로요.

git 이력에서 사실 시트를 뽑았어요

초안을 만들기 전에 최근 7일치 커밋을 훑어 날짜·제목·변경 파일만 담은 사실 시트를 뽑고, 이 시트 밖의 주장은 쓰지 못하게 못 박았어요. 시트에는 일주일치 커밋 11건이 담겼어요.

시트 맨 위에는 두 줄을 분명히 적었어요. 커밋이 증명하는 건 "이 시각에 이 파일을 바꿨다"는 사실뿐이고, 성과나 소요 시간, 개선폭은 증명하지 않는다는 것. 직접 만들어 보니 생성 스크립트와 테스트를 합쳐 3개 파일 수정으로 끝나는 작은 작업이었어요.

git 커밋→사실 시트→AI 초안→결정론 게이트→발행 표면 확인

검증을 LLM에게만 맡기지 않아요

사실 시트만으로는 부족해서, 거짓정보 게이트에 결정론 검사를 붙였어요. LLM이 LLM의 초안을 검사하는 구조는 자기 환각을 자기가 검증하는 셈이라 위험하거든요. 스크립트가 초안 속 수치와 코드 링크를 시트와 기계적으로 대조하게 했고, 이 작업은 검사기와 테스트까지 5개 파일을 고쳤어요.

발행 확인도 같이 바꿨어요. 자동화 로그의 성공 표시만 믿지 않고, 글별 URL이 200 응답을 주는지, 본문이 실제로 렌더되는지까지 확인해요. 돌려 보니 "성공했다고 말하는 것"과 "실제로 게시된 것"은 다른 문제더라고요.

기록은 정확하면 충분해요

플랜비(plan-b) 같은 제품을 만들며 쌓이는 커밋이 그대로 글감이 되는 구조라, 이제는 글 쓰는 부담보다 커밋 메시지를 정성껏 쓰는 부담이 커졌어요. 그게 맞는 방향 같아요.

AI에게 글을 맡기고 있다면 문체 교정보다 근거 고정을 먼저 해보세요. 기록은 화려할 필요 없고, 정확하면 돼요.