문체를 다듬는 단계가 41일 동안 한 번도 돌지 않았다. 지시문을 세게 고쳐도 소용없었다

매일 아침 루틴은 기사 10건의 요약과 시사점을 쓴 다음 번역투와 AI 말투를 걸러내는 humanizer 단계를 한 번 더 거치게 돼 있다. 8월 23일에 넣은 단계다.

9월 30일에 그날 본문을 직접 읽다가 이 단계를 거쳤다고 보기 어려운 문장이 여럿 눈에 띄었다. 며칠 사이에 생긴 일인 줄 알았는데 거슬러 올라가 보니 처음부터였다.

커밋 43건 중 언급은 한 번

8월 23일 이후 루틴이 남긴 브리핑 커밋 43건 가운데 이 단계를 입에 올린 건 9월 7일 하나였다. "스킬이 로드되지 않아 건너뛰었다." 나머지 42건에는 건너뛰었다는 말도 거쳤다는 말도 없었다. 실패가 아니라 생략이라 아무 소리도 나지 않았다.

원인은 네 겹이었다

• 스킬 파일이 내 PC에만 있었다. 클라우드 루틴은 저장소만 받아서 도는데 그 안에 없었다. 절차서에는 "불러오지 못하면 건너뛴다"는 예외가 있었고 그 예외가 매일 성립했다.
• 루틴에 스킬을 부르는 도구가 없었다. "스킬에 통과시킨다"는 문장이 실제로 할 수 있는 행동으로 이어지지 않았다.
• 거쳤는지 남는 흔적이 없었다. 그러니 "쓰면서 반영했다"는 한마디로 끝낼 수 있었다.
• 본문 10건을 스크립트 하나로 한꺼번에 쓰는 구조였다. 따로 다듬으려면 다 쓴 덩어리를 다시 열어야 한다. 9월 29일에 바꾼 빠른 모델은 30턴 안팎에서 일을 끝내며 이런 단계부터 뺐다.

지시문을 세게 고친 건 소용없었다

첫 대응은 절차서 문장이었다(9월 30일). 절차서에 "시간이 부족하면 건너뛰어도 발송은 진행한다"는 문장이 있었다. 발송을 막지 말라고 쓴 말이 안 해도 된다는 허락으로 읽혔다고 보고, 시간은 이유가 못 된다고 못박았다.

다음 날 루틴은 또 건너뛰었다. 이번엔 "스킬이 이 환경에 없다"고 했고 그 말은 사실이었다. 첫째 원인을 못 본 채 문장만 세게 만든 셈이다.

스킬을 저장소에 넣은 다음 날(10월 2일) 아침 루틴은 파일을 읽긴 했다. 그러고는 따로 다듬지 않고 "작성하면서 반영했다"고 보고했다. 같은 날 사이트를 만들 때 문체 경고를 세어 찍게 하고 리허설을 돌렸다. 루틴은 경고 5건을 0건으로 줄이고 "다 쓴 뒤 처음부터 다시 읽으며 고쳤다"고 보고했다. 실행 기록을 보니 본문을 쓰고 3초 뒤에 사이트를 만들었고, 손댄 곳은 경고가 짚은 다섯 군데뿐이었다.

다른 눈에 맡겼다

10월 2일부터 이 단계를 루틴에서 떼어 냈다. 루틴은 다듬을 문장만 뽑아 파일로 남기고, 한국어와 영어 편집을 맡은 서브에이전트 둘을 새 맥락으로 띄운다. 처음 보는 글이라 "이미 반영했다"고 말할 거리가 없다. 서브에이전트는 문장마다 고치기 전과 후를 돌려주고, 스크립트가 숫자와 고유명사가 바뀌지 않았는지 확인한 다음 넣는다. 몇 문장을 고쳤는지는 그날 아카이브에 남는다.

지침도 바꿨다. 리허설에서 범용 문체 규칙을 다 읽은 서브에이전트는 39문장 중 3개만 고쳤다. 규칙 목록에 걸리는 것만 손댔다. 같은 날 지난 본문을 다시 읽어 보니 가장 나쁜 문제는 문체 쪽이 아니었다. 월요일에 다음 날 행사를 "다음 주"라고 쓴 헤드라인이 있었고, 원문보다 세게 이어 붙인 인과도 있었다. 그래서 지침을 이 브리핑에서 실제로 나온 문장의 전후 사례로 다시 쓰고 사실과 앞뒤부터 보게 했다. 판단이 드는 일이라 더 큰 모델로 띄운다.

발행일	한국어	영어
10월 3일	10 / 41	9 / 28
10월 4일	15 / 36	10 / 28
10월 5일	15 / 36	13 / 27
10월 6일	10 / 36	7 / 27
10월 7일	10 / 37	9 / 24

남는 것

무인으로 도는 일에 "이 단계를 거쳐라"라고 적어 둔다고 그 단계가 생기지는 않는다. 거쳤는지 기계가 셀 수 있는 흔적이 있어야 하고, 다음 날 누군가 그 숫자를 봐야 한다.

이번에 처음 던진 질문은 "왜 안 하나"였고, 그 질문은 지시문을 고치는 쪽으로만 이어졌다. 먼저 물었어야 할 건 "했다는 걸 무엇으로 아나"였다.