퇴사하고 AI로 회사를 만드는 중이다. 그 과정을 적는 블로그가 이번엔 스스로 일감이 됐다. 9시 55분부터 이미 사이트에 올라가 있는 글을 전부 다시 쓰기 시작했고, 그 작업을 서브에이전트(별도 세션에서 도는 보조 에이전트)에게 넘기면서 호출 프롬프트를 글마다 다르게 썼다.
형식을 세러 갔다가 사실에서 걸렸다
글마다 takeaway(검색 결과에 나갈 한 줄)와 asset(독자가 가져갈 것의 종류) 두 칸이 있어야 한다는 규칙을 세운 참이었다. 옛 글에 그 칸이 있는지 세는 건 grep 한 줄이면 끝나는 일이라 거기서부터 시작했다.
형식은 예상한 대로였다. 예상 못 한 쪽은 문장 검사기를 같이 돌렸을 때 나왔다. 한 편은 원자료에 없는 숫자를 쓰고 있어서 이미 발행 불가 판정을 받은 상태였고, 다른 한 편은 원자료에서 중간에 잘려 있는 명령 하나를 실패로 단정하고 있었다. 그 명령에 실패의 근거로 붙어 있던 줄은 🔓 Token Permissions: 하나였는데, 그건 그 명령이 정상으로 뱉은 출력이다.
형식이 비어 있는 건 칸을 다시 채우면 되지만, 원자료에 없는 숫자를 쓴 글과 정상 출력을 실패로 읽은 글은 문장을 손보는 정도로 안 되고 그 사건을 처음부터 다시 정리해서 써야 한다 — 어느 문장이 원자료의 어느 줄에서 나왔는지를 전부 다시 대봐야 하기 때문이다.
다시 쓰기는 덮어쓰기다
글 하나에 에이전트 하나를 붙였다. 원자료와 문체 규칙을 읽히고 같은 경로에 덮어쓰게 했다. 그날 에이전트를 27번 불렀다.
여기 걸리는 게 하나 있다. 글 맨 위 frontmatter(파일 머리에 붙는 설정 블록)에는 사이트 발행 스위치가 한 줄 들어 있다. 그 줄이 사라지면 글이 목록에서 내려간다. 다시 쓰는 쪽은 자기가 글을 고치는 중이라고 여긴다. 글을 내린다고는 여기지 않는다.
처음 네 편에 보낸 프롬프트에는 이 문장만 있었다.
frontmatter의 date, publish, series, title은 그대로 둔다.
다섯 번째부터 이렇게 바꿨다.
frontmatter의 date, publish, series, title 네 줄은 글자 그대로 옮긴다.
특히 `publish: true`를 빠뜨리지 마라 — 지우면 글이 사이트에서 내려간다.
“그대로 둔다”와 “글자 그대로 옮긴다”는 읽는 사람에게는 같은 말이다. 파일을 처음부터 새로 쓰는 쪽에게는 다르다. 앞은 건드리지 말라는 금지고, 뒤는 네 줄을 복사해 넣으라는 작업 지시다. 지우면 무슨 일이 생기는지도 한 절 붙였다.
프롬프트를 한 벌로 돌리지 않았다
요청들은 경로 세 줄만 다르고 나머지가 똑같은 복사본이 될 뻔했다. 그러면 그 글에서 찾아낸 결함도 같이 복사된다. 검사에서 걸린 것을 그 글의 호출 프롬프트에만 한 줄로 박았다.
고객사 일을 쓴 글에는 이 줄이 붙었다.
이 글은 남의 사업(고객사)에 들어간 일이다. 고객 쪽 매출·팔로워 같은 숫자는
원자료에 있어도 글에 옮기지 마라. 내가 무엇을 만들기로 했고 무엇을 줄였는지만 쓴다.
원자료에는 그 사업의 숫자가 그대로 남아 있다. 어느 줄을 옮기면 안 되는지는 읽는 쪽이 판단해야 한다. 그 판단을 맡기지 않고 호출 프롬프트 맨 아래에 붙였다.
문서 여러 편을 AI에게 한꺼번에 고치게 한다면, 공통 지시는 스킬 파일에 두고 그 글에만 해당하는 결함 한 줄은 호출 프롬프트에 직접 쓰세요. 검사기가 이미 찍어준 것을 다시 찾아내게 만들 이유가 없습니다.
검사기가 찍은 단어 둘
두 편을 검사기에 넣었더니 WARN 원자료에 없는 영문 토큰 2개: error, failed가 났다. 한 편은 error·failed 문자열로 실패를 세는 로그 추출기 얘기라서, 글에 그 단어가 나오는 게 맞다. 경고를 0으로 만들려면 저 단어를 지워야 하고, 지우면 글이 무슨 말인지 알 수 없게 된다. 검사기 경고는 지우라는 명령이 아니라 설명하라는 요구다.
숫자 때문에 발행 불가였던 한 편에는 “다시 쓸 때 원자료에 있는 숫자만 쓴다”를 프롬프트 마지막 줄로 넣었다.