AI 글이 애매할 때 가장 먼저 떠오르는 해법은 더 좋은 모델로 바꾸는 것이다.
하지만 모델 옆에 엄청 깐깐하고 절대 잠들지 않는 편집장을 붙이는 방법도 있다.
제목을 확인하고, 본문이 제목의 약속에 답하는지 보고, 설명 없는 전문용어를 찾고, 같은 단서를 반복하는지 세고, 12개 언어가 모두 있는지 검사하고, 실패한 부분만 다시 쓰게 하는 편집장이다.
TypeScript가 문장을 쓰는 것은 아니다. 대신 좋은 원고가 될 때까지 출고하지 않는 편집 공정을 만들 수 있다.
1. 5초 결론: 문재를 코드화하는 것이 아니라 편집 공정을 코드화한다
공통 규칙을 넣으면 AI 글은 좋아질 수 있다. 더 큰 효과는 규칙을 프롬프트에 쌓는 것보다 생성 → 검사 → 의미 평가 → 부분 수정 → 재검사를 반복 가능한 공정으로 만드는 데서 나온다.
OpenAI는 평가를 ‘좋음의 기준을 정하기 → 측정하기 → 개선하기’의 순환으로 설명하며, 실제 출력에서 발견한 새로운 실패를 평가 기준에 계속 반영하라고 제안한다.[1]
글쓰기 공장으로 바꾸면 간단하다. 불량을 발견하고, 원인을 찾고, 다음부터 잡아내는 검사 항목을 만든다.
2. TypeScript는 작가가 아니라 생산라인이다
코드는 확정적으로 판정할 수 있는 일을 잘한다.
- H1이 여러 개인가
title과og:title이 충돌하는가- 12개 언어가 모두 있는가
- 중복 제목이나 잘못된 날짜 형식이 있는가
- 기준 이하 평가를 받으면 재수정 단계로 보낼 것인가
반면 다음은 의미를 읽어야 한다.
- 도입이 재미있는가
- 비유를 살릴 가치가 있는가
- 제목이 독자의 진짜 질문을 담았는가
- 연구 설명이 원래의 재미있는 관찰을 덮어버렸는가
그래서 기계 검사는 TypeScript, 의미 판단은 AI 편집자로 나누는 편이 강하다.
3. ‘프로 편집자’를 역할로 쪼개면 구현하기 쉬워진다
구성 편집
독자의 질문, 결론 위치, 장 순서와 흐름을 본다.
카피 편집
제목, 도입, 반복, 표현, 리듬을 다듬는다.
사실 편집
숫자, 날짜, 인용, 단정의 강도와 출처 일치를 본다.
검색 입구 편집
제목 앞부분만 읽어도 무슨 글인지 알 수 있는지 본다.
Google Search Central은 검색결과 제목이 페이지 내용과 검색어의 관련성을 빠르게 이해하는 핵심 정보라고 설명하며, 구체적이고 간결하며 각 페이지를 구분할 수 있는 제목과 키워드 남용 방지를 권한다.[2]
NN/g 연구도 웹 사용자는 자주 정독보다 스캔을 하며, 링크와 제목의 앞부분에 정보량 높은 단어를 두는 것이 중요하다고 보여준다.[4][5]
4. Before / After: 농담을 삭제하지 말고 입구에서 옮긴다
변경 전
성은 잘못이 없다, 사전이 사고를 쳤다 — Manko·Wang·Chin으로 보는 ‘다른 언어에서 위험해지는 이름’
재미는 있지만 실제 주제가 뒤에 있다.
변경 후
다른 언어에서 민망하게 들리는 이름 — Manko·Wang·Chin으로 보는 이름의 다국어 충돌
그리고 첫 문장을 이렇게 쓴다.
성은 잘못이 없다. 사전이 사고를 쳤다.
농담은 살아 있고, 독자는 이미 무엇에 대한 농담인지 안다.
Google의 사람 우선 콘텐츠 가이드도 제목이 내용을 유용하고 정확하게 요약하는지, 검색 유입만 노린 과장인지 점검하도록 권한다.[3]
5. 좋은 공통 규칙은 모든 글을 똑같게 만들지 않고 같은 사고를 막는다
모든 글에 ‘항상 3문장’, ‘항상 질문형 소제목’, ‘항상 예시 2개’를 강제하면 글이 공장제 플라스틱처럼 변한다.
더 좋은 규칙은 실패를 정의한다.
- 핵심 질문을 캐치프레이즈 뒤에 묻지 않는다
- 본문이 답하지 않는 약속을 제목에 넣지 않는다
- 같은 유보를 반복하지 않는다
- 전문용어를 설명 없이 던지지 않는다
- 소제목만 봐도 뜻이 통한다
- 연구는 원래 관찰을 보강하지, 주인공을 빼앗지 않는다
- 12개 언어를 일본어 어순 그대로 번역하지 않는다
6. P0 / P1 / P2로 나누면 규칙 감옥을 피할 수 있다
P0: 반드시 지킬 것
사실, 숫자, 날짜, 인용, 제목-본문 일치, 개인정보 보호, 12개 언어 완성, 근거 없는 단정 금지.
P1: 매우 중요
빠른 결론, 한 단락 한 주제, 쉬운 설명을 먼저, 독립적으로 이해되는 소제목, 중복 축소.
P2: 글의 맛
농담, 비유, 대화감, 리듬, 강한 훅.
P0를 지키려고 P2까지 죽일 필요는 없다. 그러면 모든 글이 사용설명서 경고문이 된다.
7. 강한 시스템은 규칙 목록이 아니라 실패에서 자라는 평가 루프다
- 초안을 만든다
- 기계 검사를 한다
- AI 편집자가 의미를 읽는다
- 실패 이유를 구조화한다
- 실패한 부분만 고친다
- 다시 검사한다
- 새로운 유형의 실패면 영구 평가 기준 후보로 보낸다
OpenAI의 eval 접근도 실제 실패를 다음 평가와 개선에 연결하는 순환을 강조한다.[1]
제목만 나쁘다면 2,000자의 본문까지 다시 만들 필요가 없다. 이미 좋은 부분을 다시 생성하면 새 불량이 생길 수 있다.
8. TypeScript 구현은 이 정도면 충분하다
const draft = await writeArticle(input);
const hardCheck = runDeterministicChecks(draft);
const editorial = await semanticEditor.review(draft, rubric);
if (!hardCheck.ok || editorial.hasCriticalIssue) {
const revised = await reviseOnlyFailures(draft, { hardCheck, editorial });
return verifyAgain(revised);
}
return draft;
중요한 것은 멋진 코드가 아니다. 확실히 검사할 수 있는 것은 코드에, 의미 판단은 AI 편집자에게, 실패 이유는 부분 수정 지시로 보낸다.
9. 자동화의 약점: AI 편집자도 틀린다
좋은 농담을 장황하다고 지우거나, 소수 문체를 이상하다고 판단하거나, 문화적 유머를 번역 과정에서 평평하게 만들 수 있다. 자기 글을 자기 평가로 과대평가할 수도 있다.
그래서 의미 평가 점수는 진실이 아니라 검사 신호다. 사실은 공식·1차 자료로 돌아가고, 위험도가 높은 공개물은 사람 검토로 올린다.
10. 100편, 1000편에서 강해지는 것은 ‘개선의 복리’다
한 글에서 ‘캐치프레이즈가 핵심 질문을 밀어냈다’는 실패를 찾으면 다음부터 전 글에서 검사할 수 있다.
다른 글에서 ‘하지만’이 반복돼 결론이 흐려졌다면 그것도 기준이 된다.
독일어 버전에서 직역 냄새가 났다면 독일어 전용 검사 기준이 된다.
실패가 한 편의 수정으로 끝나지 않고 편집 자산이 된다.
11. 결론: 규칙 산이 아니라 잠들지 않는 편집부를 만들어라
TypeScript에 문재를 이식하는 것이 목적이 아니다.
“이 제목만 보면 무슨 글인지 모르겠다”, “이 약속을 본문이 안 갚는다”, “그 농담은 지우지 말고 위치를 바꿔라”, “이 사실은 출처가 필요하다” 같은 프로 편집자의 판단을 반복 가능한 공정으로 만드는 것이다.
그렇게 하면 같은 모델이라도 최종 원고는 달라진다. 모델 주변의 편집 시스템이 학습했기 때문이다.
