프롬프트에 남긴 말투 규칙 자체가 틀렸다 — 실물 354줄 실측으로 갈아끼운 것

실물 계정의 게시물을 우리 것과 나란히 놓고 어미를 세기 시작했는데, 처음 무너진 것은 상대편이 아니라 우리 규칙이었습니다. 세금·부동산 정보 계정 56곳에서 게시물을 계정당 한 편씩 모아 354줄로 나눠 어미를 세웠습니다. 프롬프트에 "중간 서술은 음슴체"라고 적어 둔 그 어미(~임 ~함 ~됨)는 354줄 가운데 7줄이었습니다. 그리고 그 7줄 중 6줄은 번호나 이모지 불릿 뒤에 붙은 목록 항목이었습니다.

이 규칙은 2026년 8월 19일에 writer 프롬프트와 editor 프롬프트에 들어갔고 CLAUDE.md 에는 "실물 게시물 30여 건 조사(2026-08-19)"라는 출처 표기까지 붙어 같은 규칙이 있었습니다. 9월 8일 0시 49분 커밋(de04e66)에서 뒤집혔습니다. 그 사이 이 규칙을 따라 나간 money 스레드가 있습니다. 규칙을 쓰는 에이전트도, 그 규칙을 기준으로 검사하는 에이전트도 같은 문서를 읽고 있었으니 어디에서도 잡힐 수가 없었습니다. 결국 잡은 것은 실물을 직접 세어 보는 것뿐이었습니다.

note에서 AI 발행 파이프라인을 다룬 시리즈의 세 번째 글입니다. 앞선 두 편은 프롬프트 지시가 실행에서 빠진 네 사례를 코드 가드로 막은 기록과 스레드 발행 구조에서 샌 규칙을 이력과 에러로 막은 기록이었습니다. 두 편 모두 "규칙이 샌다"가 주제였습니다. 이번에는 규칙이 지켜졌습니다. 규칙의 내용이 실물과 정반대였습니다. 그래서 앞선 글의 결론인 "말투의 생성과 판정을 어디에 두나"로는 이 사고를 설명할 수 없고 질문 자체가 "프롬프트에 둔 내용을 누가 검증하나"로 바뀝니다.

규칙은 세 곳에 있었고 전부 같은 말을 했다

말투 규칙은 에이전트 프롬프트 두 개와 저장소 루트 문서 한 곳에 있었습니다. 정정 커밋 바로 이전 버전(de04e66^)을 열면 셋이 같은 말을 하고 있었습니다.

글을 쓰는 에이전트의 프롬프트(.claude/agents/post-writer.md)에는 자리별 말투를 정한 표가 있었고 그 가운데 행이 이렇습니다(509행).

중간 서술 | 음슴체 또는 짧은 단언 | ~임 ~함 ~됨 ~있음 / ~다 ~한다 / 개조식

바로 아래 조립 예시에는 문장 중간에서 줄을 바꾼 뒤 이렇게 달아 두기까지 했습니다(524행).

안 하면 공제 3억 날아감 ← 음슴체 서술

검수하는 에이전트의 프롬프트(.claude/agents/post-editor.md)에는 이것이 검사 항목으로 들어 있었습니다(96행).

중간 서술이 음슴체나 개조식인가. ~임 ~함 ~됨 이 자연스럽다.

저장소 루트의 CLAUDE.md 도 같은 규칙을 적고 있었습니다(268~269행).

첫 글·마지막 CTA 는 말 거는 반말(~야 ~해 ~거든 ~해봐), 중간 서술은 음슴체(~임 ~함 ~됨)나 짧은 ~다 나 개조식

writer는 이 규칙을 따랐습니다. editor는 이 규칙을 기준으로 검사했습니다. 검사하는 쪽의 기준이 검사받는 쪽의 기준과 같으면 검수는 확인 절차가 됩니다. 틀린 규칙이라도 "그 규칙대로 쓰였는가"만 물어보니 통과할 수밖에 없었습니다. 같은 문장이 세 곳에 있었다는 것은 규칙이 세 번 확인된 게 아니라 한 출처가 세 번 복사된 것이었습니다. 같은 말이 세 곳에 있으면 확인된 것이 아니라 증폭된 것이다.

잡는 손이 어디에도 없었다

코드 쪽 검사기(pipeline/check-content.ts)는 스레드 문구에서 다섯 가지만 봅니다. 문구 자체가 없는 것은 아닌지, 조각이 500자를 넘기는지, 첫 조각에 링크가 들어 가는지, 해시태그를 직접 달았는지, 조각 수가 23개 범위를 벗어나는지입니다. 말투를 보는 검사는 없습니다. 그 분업은 코드에 주석으로 박혀 있습니다(328330행).

말투는 프롬프트가 쓰고, 여기서는 샜는지만 본다.

editor 쪽 프롬프트에도 같은 분업이 적혀 있습니다(80~81행).

post:check 는 말투를 아예 안 본다. 길이·링크·해시태그·조각 수처럼 셀 수 있는 것만 센다. 말투는 전부 네 몫이다.

이 분업 자체가 잘못이었다고 보지는 않습니다. 8월 18일에 존댓말 어미를 코드로 갈아 끼웠다가 늘어난다 같은 문어체가 나와 되돌린 일이 있었고 바로 위 주석이 그 되돌림의 결론입니다(앞선 글에서 다룹니다). 문제는 다른 곳에 있었습니다. editor가 "네 몫"이라고 넘겨받은 말투 판정의 기준도 같은 저장소의 프롬프트에서 나왔다는 점입니다. 기준이 틀렸으면 검수를 돌려도 잡히지 않습니다. editor는 "음슴체가 자연스러운가"를 물었고 들어온 문구는 규칙대로 음슴체였으니 답은 늘 한쪽이었습니다. 셀 수 있는 것만 재는 검사기와 말투를 맡은 검수 사이에 규칙 내용을 확인하는 자리가 비어 있었다.

실제로 나간 문구를 뒤져 보았다

규칙을 고치기 전에, 그 규칙으로 실제로 무엇이 나갔는지부터 확인했습니다. 8월 20일부터 9월 4일 사이에 쓰여 발행된 money 스레드는 여덟 편입니다. 발행 여부와 발행 시각은 각 글 frontmatter 의 기록(threadsPosts·threadsPublishedAt)으로 확인했고 여덟 편 모두 정정(9월 8일) 이전에 나갔습니다. 여덟 편 전부에서 서술 자리 음슴체가 나왔습니다. 참고로 스레드 문구는 만들어졌지만 발행 기록이 없는 글 한 편(9월 1일자 퇴직소득세 계산 글)은 실례에서 뺐습니다.

8월 28일자 청약저축 전환 글의 첫 조각에는 이 문장이 있었습니다.

공공분양 실적을 합산해 준다고 적힌 통장은 딱 하나임

같은 글 설명 조각에는 이 줄이 있었습니다.

청약예금·청약부금은 그 조문에 안 적혀 있음

9월 4일자 양도소득세 기한후신고 글에서는 첫 조각 두 번째 줄과 설명 조각에 각각 이렇게 들어 있었습니다.

아직 절반은 깎을 수 있음. 대신 날짜가 정해져 있다

대신 깎아주는 건 무신고가산세뿐임

네 문장 모두 불릿 목록의 항목이 아니라 문장 가운데 놓인 서술이었습니다. 8월 27일자 전세보증금 글처럼 첫 조각의 후킹 문장에 붙은 경우("알고 있으면 위험함", "먼저 받는 돈은 5,000만원뿐임")도 있었습니다. 이 여덟 편은 구조 검사와 검수를 통과해 나간 문구입니다. 실측이 나오기 전까지 이것들은 규칙을 잘 따른 글이었습니다. 규칙을 잘 따른 결과가 실물과 정반대인 문구였다.

354줄을 세어 보았다

방법은 단순합니다. 검색어 10개(증여세·양도소득세·종부세·연말정산·취득세·전세보증금·청약·연금저축·재테크·절세)로 스레드를 검색해 정보 계정의 게시물을 모았습니다. 한 계정에서 한 편씩 가져왔으므로 계정 56곳 × 1편 = 56편이고 게시물을 줄로 나눠 354줄의 어미를 하나씩 분류했습니다. 계정당 한 편이라는 표집 조건은 중요합니다. "56계정이 56편을 올렸다"가 아니라 56곳에서 한 편씩 뽑은 표본입니다.

결과는 이렇게 갈렸습니다.

음슴체는 354줄 중 7줄이었습니다(354 × 2% ≒ 7). 그 7줄 가운데 6줄은 번호나 이모지 불릿 뒤에 붙어 있었습니다. 실물에서는 번호 불릿 다음 줄에 세대원의 주택수를 고려하지 않음, 이모지 불릿 다음 줄에 임대등록한 주택 주택수 들어가서 취득세 중과됨 같은 형태로 붙어 있었다는 뜻입니다.

그래서 이번 계측의 요지는 순위가 아니었습니다. 음슴체가 사는 자리가 목록 항목이었다는 것이 핵심이었습니다. 옛 규칙은 음슴체를 "중간 서술"의 말투로 지정했는데, 실물에서 음슴체는 서술의 말투가 아니라 개조식 항목의 말투였습니다. 줄글에 놓으면 개조식 보고서로 읽히는 어미였습니다.

원시 집계 파일이나 계측 스크립트는 저장소에 커밋돼 있지 않습니다. 다시 뽑는 절차만 남아 있습니다. callcheck 의 스레드 검색기(searchOnce)로 한 단어씩 검색해 줄 단위로 어미를 세는 것이고 정정 당시 post-writer 프롬프트에 적어 뒀습니다(546~547행). 다시 돌리면 수치가 소폭 달라질 수 있는 규모의 표본입니다.

더 큰 발견은 어미가 아니라 줄바꿈이었다

어미와 함께 재니까 더 큰 차이가 나온 것은 줄이었습니다. 한 줄의 평균 길이는 20.9자, 중앙값은 17자였습니다. 게시물 하나는 평균 6.3줄이었습니다(354 ÷ 56 ≒ 6.3). 그리고 줄바꿈을 기준으로 따로 잰 값에서는 전체의 64%가 문장부호 없이 줄만 바꾼 것이었습니다. 어미 분류에서 가장 큰 묶음이 "문장 중간에서 줄만 바꿈"(59%)이었던 것과 같은 결을 가리킵니다.

실물 한 줄을 그대로 옮기면 이런 모양입니다.

현금 재산이 300~400억인 부자들은

150억 증여

두 줄 다 문장이 끝나지 않은 상태에서 줄을 바꿨습니다. 한 문장을 호흡 단위로 끊어 내리는 것이 실물 스레드의 기본 결이었고 어미를 무엇으로 끝내느냐는 그다음 문제였습니다. 긴 문장 하나를 통으로 놓으면 어미를 아무리 반말로 바꿔도 블로그 문단으로 읽힙니다.

이 항목은 옛 규칙 어디에도 없었습니다. 옛 post-writer의 표는 자리별 어미만 정했고 줄을 어떻게 끊는지는 다루지 않았습니다. 그래서 이번 정리는 어미 규칙을 교체하는 일과 줄 길이에 대한 지시를 새로 넣는 일이 동시에 됐습니다. 순위를 뒤집은 것은 음슴체 2퍼센트였고 결을 바꾼 것은 줄 길이였다.

갈아끼운 것

정정 커밋은 de04e66이고 9월 8일 0시 49분에 찍혔습니다. 세 파일이 같이 바뀌었습니다. post-writer에 46줄이 더해지고 13줄이 지워졌습니다. post-editor에 11줄이 더해지고 4줄이 지워졌고 CLAUDE.md 에 20줄이 더해지고 6줄이 지워졌습니다. 세 파일을 합쳐 77줄이 더해지고 23줄이 지워졌습니다. 바뀐 내용의 골격은 이렇습니다.

post-writer에는 자리별 표가 네 행으로 다시 그려졌습니다. 첫 글(후킹)은 말 거는 반말(~야 ~해 ~거든 ~잖아 ~더라 ~네 ~까?), 중간 서술은 그 반말을 이어 가는 것, 목록 항목은 개조식이나 음슴체이되 불릿 뒤에서만, 마지막 CTA 는 명령형 반말(~해봐 ~알려줘)입니다. 여기에 두 항목이 새로 붙었습니다. 진행형 대화체(~하고 있어 ~적는 중이야)는 소개·근황 자리의 말투로 따로 떼어 놓은 것(실물 예: 상속 증여 전문 세무사님 찾고있어), 그리고 계정 소개(bio)는 이 규칙 밖이라는 것입니다. 실물 bio 14건은 개조식 명사구이거나 ~합니다 존댓말이었습니다(세대를 잇는 부를 연구합니다).

빈도 수치 네 개(느낌표 0.4 · 물결 0.1 · 이모지 0.5 · ㅋㅎㅠ 0.4회)는 드물지만 있고 대부분 마지막 CTA 한 줄에 몰린다는 관측과 함께 들어갔습니다. 본문에 흩뿌리지 말고 닫는 줄에만 쓰라는 지시가 그 수치의 용도입니다.

editor는 판정 방향을 통째로 뒤집었습니다. "중간 서술이 음슴체나 개조식인가"였던 항목이 "음슴체가 줄글에 쓰이지 않았는가"로 바뀌었고(~임 ~함 ~됨 은 실물에서 2%라는 근거가 붙었습니다), "한 줄이 40자를 넘어가면 어미가 뭐든 블로그 문단으로 읽힌다 — 끊으라고 지시한다"는 검사가 새로 생겼습니다. CLAUDE.md 도 같은 정리를 따라갔습니다. 규칙이 있던 세 곳이 모두 움직였기 때문에, 다음 writer와 다음 editor는 서로 다른 기준을 읽는 상태가 되지 않습니다.

앞선 두 번과 뭐가 다른가

이 저장소에서 프롬프트 규칙을 실측으로 갈아끼운 것은 이번이 세 번째입니다.

첫 번째는 8월 26일이었습니다. writer 프롬프트의 후킹 예시가 ~면 잠깐 문형이었는데, 실물 42건을 뽑아 보니 그 문형이 0건이었습니다(FLOW.md 의 "실물 계정 후킹 실측" 절에 기록이 있습니다). 갈아끼운 대상은 예시였습니다. 예시는 곧 규칙이 된다는 것을 그때 확인했습니다. 두 번째는 8월 19일에 말투 검사를 코드로 만들었다가 뺀 건인데, 이것은 앞선 글에서 다뤘듯 갈아끼운 대상이 검사 방식(코드 → editor)이었습니다. 이번 세 번째는 갈아끼운 대상이 규칙의 명제 자체였다는 점에서 앞의 두 번과 다릅니다.

한 가지는 정확히 해 두고 싶습니다. 옛 음슴체 규칙이 근거 없는 느낌은 아니었습니다. CLAUDE.md 는 "실물 게시물 30여 건 조사(2026-08-19)"라고 출처를 달고 있었고 그날의 커밋 메시지도 "스레드 말투를 실물 30여 건에서 다시 뽑았다 — 규칙이 얕았다"였습니다. 30여 건을 훑어 낸 관찰이었습니다. 문제는 그 관찰이 셈이 아니었다는 것입니다. 훑어서 뽑은 인상은 눈에 띈 사례 쪽으로 기울기 쉽고 그 인상을 규칙으로 적어 놓으면 writer가 그대로 재현합니다. 354줄을 줄 단위로 세자 같은 실물에서 정반대의 답이 나왔습니다.

프롬프트에 둔 규칙은 코드가 셀 수 있는 것만 재고 editor는 프롬프트의 기준을 읽습니다. 그 사이에 규칙의 내용을 확인하는 손은 따로 없습니다. 이번에는 실물을 셀 수 있는 형태로 만들었을 때 비로소 잡혔습니다. 검증은 규칙을 셀 수 있게 만들 때 시작됩니다.

근거와 참고

• 저장소 커밋 de04e66 "threads: 말투 규칙을 실측으로 교체 — 음슴체는 기본이 아니다" (2026-09-08 00:49) — .claude/agents/post-writer.md(+46/-13), .claude/agents/post-editor.md(+11/-4), CLAUDE.md(+20/-6)
• 정정 이전 규칙 원문 — de04e66^ 기준 .claude/agents/post-writer.md 509행·524행, .claude/agents/post-editor.md 96행, CLAUDE.md 268~269행. 음슴체 문구의 진입 커밋은 writer 9b58e89(08-19 10:05), editor 559ee51(08-19 10:15)
• pipeline/check-content.ts — 분업 주석 328330행, threadChecks 354행부터. 검사 항목은 문구 부재·500자·첫 조각 링크·해시태그·조각 수 다섯 가지. .claude/agents/post-editor.md 8081행의 "말투는 전부 네 몫이다"
• 발행 실례 여덟 편 — content/money/posts/ 아래 2026-08-20(부동산 증여 취득세)·2026-08-25(외국인 토지거래허가구역)·2026-08-26(부담부증여)·2026-08-27(전세보증금 우선변제)·2026-08-28(청약저축 전환)·2026-09-01(주택수별 취득세)·2026-09-01(전세계약신고)·2026-09-04(양도소득세 기한후신고), 발행 기록은 각 글 frontmatter 의 threadsPosts
• 8월 26일 후킹 실측(실물 42건에서 ~면 잠깐 0건) — FLOW.md "실물 계정 후킹 실측 — '잠깐'은 아무도 안 쓴다 (2026-08-26)" 절
• 재수집 방법 — .claude/agents/post-writer.md 546~547행. callcheck 의 searchOnce 로 한 단어씩 검색해 줄 단위 어미 계측. 원시 집계 파일·스크립트는 저장소에 커밋돼 있지 않다
• 앞선 글 — AI 에이전트 프롬프트 지시 누락, 코드 가드로 막은 네 번의 사례
• 앞선 글 — AI 에이전트 스레드 발행에서 또 샌 규칙, 이력과 에러로 막은 것