같은 사료 파일 하나로 맥락 없는 서브에이전트에게 블로그 글을 다섯 번 쓰게 했다.
사료만 준 안은 산발적이었고
템플릿에 문체 규범 문서 둘을 더 준 안이 가장 잘 읽혔다.
윤문은 그 뒤에 한 번 적용했을 뿐이다.
그렇게 고른 최종본도 기계 게이트를 통과한 채 결함 넷을 남겼고
그 넷과 줄 폭을 블로그 집필 스킬의 단계로 고정했다.
문제
AI 느낌은 장치를 더해도 블로그에서 빠지지 않았다.
gn-voice를 찾은 이유를 그날 이렇게 적었다.
"아무리 장치를해도 AI느낌을 내 블로그에서 지울수가없어서 찾는중에 발견한거야."
gn-voice는 남의 GitHub 리포에 있는 스킬이고
AI가 쓴 한국어 초안을 개인 문체로 재작성한다.
첫 비교는 윤문끼리였다.
A안은 게이트를 거친 개발일지 초안이고
B안은 그 A안을 gn-voice의 rewrite 모드에 맡긴 결과다.
rewrite 실행과 심사, 재작업 한 번에 서브에이전트를 세 번 호출했다.
B안을 읽고 "확실히 공냥것 넣으니 더 자연스럽다."라고 했지만
B안은 A안을 만든 뒤에 윤문을 한 번 더 거친 글이었다.
정작 보고 싶던 것은 윤문 전의 글이었다.
"기본 사료를 두고 A게이트 안거친 생짜 공냥스킬 결과물을 보고싶은거야."
gn-voice의 기본 모드는 compose다.
재료를 받아 글을 새로 쓰는 모드이고
rewrite는 명제를 전부 보존한 채 문체만 고친다.
윤문 도구를 끈 경위와 2단 윤문 게이트가 원문을 보지 않는 문제는
다른 글에 적었다.
사료에 무엇을 더했나
C안부터 G안까지 사료는 바이트가 같은 파일 하나였다.
요청 문장도 같았고 바뀐 것은 사료와 함께 준 첨부뿐이다.
| 안 | 사료에 더한 첨부 | 결과 | 내 평 |
|---|---|---|---|
| C | 없음 | H2 0개, 문장 끝 64개 중 존댓말 0개 | "확실히 자연스러운투인데, 글이 산발적이네." |
| D | 템플릿 | 문체가 지켜지지 않음 | "D에선 왜 안지켜졌을까?" |
| F | 템플릿, 목소리 규범과 표기 규범 전문 | H2 6개와 H3 4개, 문장 끝 86개 중 존댓말 0개 | "현재중엔 F가 가장 좋다." |
| G | 템플릿, 발행 전 게이트 발췌 | H2 6개, 문장 끝 89개 중 존댓말 0개 | - |
C안은 문체가 자연스러웠지만 헤딩이 하나도 없었다.
템플릿만 더한 D안에서는 C안이 지키던 문체가 지켜지지 않았다.
규범 전문(18436바이트와 38228바이트)을 더한 F안이 구조와 문체를 함께 확보했고
발췌 6849바이트만 준 G안도 헤딩은 갖췄다.
이 네 안 중 어디에도 윤문 도구는 개입하지 않았다.
윤문은 맨 뒤에 한 번만 얹었다
F안으로 정한 뒤 F 결과물에 /korean을 돌렸다(H안).
diff를 보면 F의 49줄이 바뀌었다.
"지휘 쪽은 9월 26일이다."가 "지휘 쪽은 9월 26일에 시작됐다."가 된 식이다.
문장은 더 매끄럽게 읽혔고 원문에 없던 동사 하나가 추가됐다.
H'안은 F안과 입력이 같고 템플릿 두 곳만 달랐다.
도입 안내는 첫 문단의 두세 문장에 관통 논지를 두라는 지시로 바꿨고
말미에 구성 규칙 3줄을 더했다. 윤문은 H안과 같은 /korean을 거쳤다.
블라인드 피드백은 "H'가 훨씬 잘읽힌대. H보다."였다.
윤문은 동일하게 두고 compose 앞에 넣는 템플릿만 바꾼 비교였다.
블라인드 세트에는 H'에서 어미와 1인칭만 공손체로 바꾼 H''도 넣었다.
줄 끝이 존댓말인 줄이 H'는 0줄, H''는 71줄이다.
문체는 "그리고 너말대로 단정체로하는걸로 해야겠어."로 정했다.
최종본이 통과시킨 것
H'안 윤문본에 줄바꿈을 더한 글을 읽고 "음 좋다 이대로 fix."라고 했다.
그 글을 최종본이라고 불렀다.
다시 살펴보니 최종본에는 네 가지가 남아 있었다.
| 남은 것 | 최종본에서 보인 모습 |
|---|---|
| 생성 메타 주석 | compose가 남긴 요약 주석 블록이 본문 끝에 그대로 있다. F안과 H'안에도 있었다 |
| 인용 띄어쓰기 | 9월 세션의 내 발화를 띄어 쓴 형태로 실었다. compose에 넣은 사료가 이미 띄어 쓴 형태였다 |
| 낡은 상태 서술 | 사료 상태 칸을 옮겨 마지막 스킬 커밋과 런 기록을 10월 15일로 적었다. 최종본을 쓰기 전 10월 18일까지 스킬 커밋이 9건 더 있었다 |
| 기발행 글 재서술 | 이미 발행한 판정문 한 편이 쓴 측정을 두 줄에 걸쳐 다시 서술했다 |
띄어쓰기가 바뀐 원래 발화는 이랬다.
"스킬이 산발적으로 돌아가는데, 스킬체이닝을 하나의스킬로 묶을수있나?"
최종본은 '하나의 스킬로'와 '묶을 수 있나'로 고쳐 실었다.
재서술된 측정은 그 판정문이 이미 적고 있다.
이 최종본을 기발행 글 62편과 같은 폴더에 넣고 스타일 게이트를 돌려도 PASS였다.
편 사이 10어절 겹침도 0쌍이었다.
게이트 규칙은 한 낱말 굵게, 공간 비유 명사, 반전 구문, 격언 결말,
편 사이 10어절 공유, 줄 폭이다.
주석, 인용 원문, 상태 서술의 날짜를 보는 규칙은 목록에 없었다.
게이트가 틀렸다기보다는 처음부터 확인하지 않는 항목들이었다.
줄 폭
블라인드 피드백을 전하며 "내눈에 걸리는건 이제 줄바꿈이 미숙해."라고 덧붙였다.
렌더러는 문단 안의 원고 줄마다 <br>로 이어 한 문단으로 낸다.
본문 폭은 720px라서, 원고 한 줄이 그보다 길면
브라우저가 한 번 더 접고 다음 줄에 짧은 꼬리를 남긴다.
대상은 "모바일은 무시하고 PC에만 맞추자그럼."으로 좁혔다.
스타일 게이트에 줄 폭 규칙을 더했다.
글자 종류별 폭은 Noto Serif KR 17px로 브라우저에서 잰
원고 371줄에 최소제곱으로 맞췄고
같은 371줄에서 접힘 여부를 2줄만 잘못 판정했다(둘 다 경계 ±2px).
경계 여유 6px를 빼서 본문 줄은 714px를 넘으면 넘침으로 센다.
측정해 보니 H'안 윤문본은 76줄 중 23줄이, 기발행 아티클은 116줄 중 30줄이 접히고 있었다.
줄바꿈을 마친 최종본은 0줄이다.
880px 이하에서 문단 안 줄바꿈을 푸는 CSS와 text-wrap: pretty는 기각했다.
넘친 줄 자동 분할기도 기각했다.
쉼표 없는 긴 줄은 문장을 다시 짜야 해서 기계 분할이 리듬을 깨기 때문이다.
그래서 줄바꿈 스크립트는 쉼표와 연결어미 경계에서만 줄을 바꾸고
낱말은 바꾸지 않는다.
놓친 것을 스킬 단계로 옮겼다
최종본 감사 결과를 받고 처음엔 이렇게 물었다.
"한마디로 final을 만들었던 방식만 남기고 나머진 전부 없애면 되는거아니야?"
바로 "아니. 스킬로 만들생각하자. 이게 옳지?"로 방향을 틀었다.
다음 세션에서는 개발일지 전용으로 설계만 해 둔 스킬을 블로그 전체로 넓혔다.
"gn voice 써야지. 그리고 final이 작성했던 방식 그대로 재현해야해. 모든 kinds에."
골든 샘플은 compose 첨부에서 뺐다.
걱정은 "기계적으로 찍어낸것처럼 느껴질까봐."였다.
blog 스킬의 compose 첨부는 템플릿, 목소리 규범, 표기 규범 셋뿐이다.
골든 샘플을 넣으면 구성과 표현이 끌려가 찍어낸 글이 되고
기발행 글과 10어절 겹침이 생긴다는 것이 스킬 문서에 적힌 이유다.
최종본이 통과시킨 넷과 줄 폭은 이렇게 스킬 단계와 확인 표의 칸이 됐다.
| 놓친 것 | 스킬 단계 | 확인 표 |
|---|---|---|
| 인용 띄어쓰기 | 사료 확인: 세션 발화 인용을 원문과 대조해 되돌리고, 못 찾으면 간접 서술로 바꾼다 | 원고 인용이 원문 메시지의 바이트 부분 문자열인지 |
| 낡은 상태 서술 | 사료 확인: 기준일 다음 날 이후 커밋과 열린 이슈를 사료 끝에 붙이고, 현재형 상태 문장에 기준일을 단다 | 보고를 보고 내가 판단 |
| 기발행 글 재서술 | 사료 확인: 키워드가 든 기발행 글을 "이미 발행한 글" 절로 붙이고 재서술을 금한다 | 숫자 겹침은 보고, 10어절 겹침은 필수 |
| 생성 메타 주석 | 후처리: 원고 끝 주석을 별도 파일로 옮기고 원고에서 지운다 | 주석 개수 0 |
| 줄 폭 | 줄바꿈: 쉼표와 연결어미 경계에서만 끊는다 | 스타일 게이트 넘침 0 |
H안에서 49줄을 바꾼 윤문은 확인 표의 다른 칸에서 점검한다.
compose 결과와 윤문본의 숫자, 큰따옴표, 코드스팬, URL, 헤딩이 같은지 본다.
이 스킬은 2026-10-18 저녁에 머지됐고
결과 검수 스킬이 확정한 결함 10건을 고친 뒤였다.
줄 폭 단계에는 그 뒤 조사 경계 2차 분할이 더해졌다.
쉼표도 연결어미도 없는 줄을 자동 수정 불가로 두면
윤문 출력에 따라 넘침 칸이 확률적으로 통과하지 못했기 때문이다.
결론
윤문 도구를 바꾸는 것보다 compose 앞에 무엇을 넣느냐가
이번 비교의 결과를 더 크게 갈랐다.
같은 윤문을 거친 H와 H'의 차이도 템플릿 두 곳에서 났다.
다만 compose를 잘 갖춰도 최종본은 게이트가 확인하지 않는 항목을 그대로 통과시킨다.
윤문 도구를 고르기 전에,
맥락 없는 서브에이전트에 사료, 템플릿, 규범 문서를 넣어 한 편을 뽑아 보고
그 결과에서 메타 주석, 인용 원문, 상태 날짜, 기발행 글과의 겹침을 따로 세어 볼 일이다.
한계·재검토 트리거
비교한 다섯 안의 사료 파일은 바이트가 같은 하나였고
비교는 그 한 편을 대상으로 한 번 진행했다.
스킬로 옮긴 뒤 재현 실행은 개발일지 한 종류였고
kind별 실집필 검증 과제는 2026-10-20 확인 기준으로 열려 있다.
2026-10 기준 / 재검토 트리거: article 실집필이 같은 첨부로 단정체를 놓칠 때
참고
- gn-voice - GitHub - 비교에 쓴 남의 윤문·집필 스킬
- humanizer를 끈 글 - 윤문 도구를 끈 경위
- 보지도 않은 리뷰 판정문 - 최종본이 재서술한 측정의 원래 편
- 검수·지휘 스킬 - 비교에 쓴 사료의 주제