블로그를 만들 때, 글이 먼저 필요했다.
단순한 이유였다. 블로그를 개발하려면 실제 마크다운 예시가 있어야 했다. 시리즈가 어떻게 묶이는지, 메타데이터가 어떤 형태로 들어가는지, 글끼리 연결되는 구조가 어떻게 보이는지 — 이걸 테스트하려면 실제 글 파일이 필요했다.
“블로그 사이트 만들거야, 내 대화 이력 뽑아서 블로그 작성해줘. 관련 있는 건 시리즈로 묶고, 마크다운으로 관리할 거니까 메타데이터도 글 안에 넣어야 해.”
개발용 샘플을 만들기 위한 일괄 생성이었다. 진짜 발행하려고 한 게 아니라, 일단 마크다운 파일을 채워서 사이트가 어떻게 돌아가는지를 보려고.
마커도 일부러 없앴다
AI가 초안을 뽑으면 확인이 필요한 부분마다 마커(⚠️)가 달린다. “이 부분은 raw에 근거가 없어요, 확인해주세요” 표시.
나는 그 마커들을 없애달라고 했다.
이것도 의도적인 결정이었다. 어차피 개발 예시용이고, 일단 개발부터 진행해야 했다. 마커가 달린 채로 사이트를 테스트할 수는 없으니까. 나중에 내용을 제대로 채우면 된다고 생각했다.
AI는 마커를 없앴다. 그리고 마커가 표시하던 공백을 스스로 채웠다.
그래서 환각이 생겼다
나중에 글을 제대로 읽어보니 문제가 보였다.
이야기의 전개가 내 기억이랑 달랐다. 틀렸다기보다 그럴듯했다. AI가 공백을 채울 때 내 대화 이력의 맥락을 기반으로 “아마 이랬을 것”을 만들어 넣었다. 인과관계를 만들고, 내가 한 적 없는 생각을 내 생각인 것처럼 썼다.
마커는 “여기 근거 없음”이라는 표시였는데, 그걸 없애라고 하면 AI 입장에서는 “그러면 내가 채우겠습니다”가 되는 거다. 내가 원한 건 빈칸으로 두는 거였지만, 빈칸을 두라고 말하지 않았다.
지시의 해석 문제이기도 하고, 설계의 문제이기도 했다.
문제의 구조
지어냄이 생기는 건 두 가지 이유가 있다.
첫 번째: 이야기의 흐름을 AI가 결정한다. 내가 겪은 일들을 어떤 순서로 어떻게 연결할지를 AI가 판단한다. 그게 내 기억과 다를 수밖에 없다. 내가 왜 그 결정을 했는지, 어느 순간이 전환점이었는지는 나만 안다.
두 번째: 공백은 채워진다. “여기 모른다”를 AI가 표현하는 방식은 빈칸이 아니라 추론이다. 근거가 없는 부분일수록 더 자연스럽게 이어붙인다.
두 가지를 바꿨다
이야기 흐름은 내가 설계한다
/blog-series 스킬을 만들었다.
4막 구조(intro / build / use / wrap)로 시리즈 전체 흐름을 먼저 잡는다. 각 편이 어느 자리에서 어떤 이야기를 해야 하는지를 내가 직접 정한다. “이 편은 왜 시작했는지, 다음 편은 어디서 막혔는지” — 구조를 내가 잡으면 AI는 그 안을 채운다.
이야기의 주인이 달라졌다.
raw 없으면 빈칸으로 둔다
/blog-draft 스킬에 규칙 하나를 추가했다.
초안 작성 전에 관련 raw 파일을 반드시 읽는다. raw에서 직접 근거를 가져올 수 없는 부분은 채우지 않고 ⚠️[확인 필요]로 표시한다. 마커를 없애달라고 해도 빈칸으로 두는 게 아니라, 애초에 마커를 붙여야 할 부분을 쓰지 않는다.
지금 이 글도 그 규칙대로 쓰여졌다.
개발 예시용으로 일괄 생성한 건 나쁜 선택이 아니었다. 덕분에 사이트 구조를 빠르게 테스트할 수 있었고, 어떤 글들이 소재가 되는지도 한눈에 볼 수 있었다.
환각이 생긴 건 그 다음 단계에서 내가 지름길을 탄 탓이다. 마커를 없애면 공백이 채워진다는 걸 몰랐다.
알고 나면 설계할 수 있다.