5초 결론: 글을 쓸 때 8개 층을 본다
AI 편집자가 살펴보는 곳은 크게 이렇게 8개 층입니다.
- 이번 의뢰 — 무엇을 만들고, 무엇을 만들지 않을지
- 과거 메모리와 지난 세션 — 문체, 품질 규칙, 이전에 정해 둔 예외
- GitHub의 최신 main — 지금 유효한 계약, 품질 epoch(기준 시대), 편집 규칙, QA
- 원본 기사와 원자료 — 숫자, 날짜, 인용, 고유명사, 불확실성처럼 "절대 깨면 안 되는 땅"
- 웹의 1차·공식·연구 자료 — 현재성, 제도, 사양, 연구, 반증
- 기사 그 자체 — 독자의 필요, 접근 각도, 구조, 주장과 근거, 유머, 자연스러움
- 12개 언어 버전 — 단어가 아니라 개념을 현지화하고, 정확한 이름은 그대로 보존
- 실제 사이트·실제 데이터·QA 증거 — 스마트폰, 확대, 긴 글, 링크, 표, 오류 상황까지 확인
그러니까 "구글 가이드를 읽고 글을 쓴다"가 아닙니다.
구글만 보면 구글 직원의 영혼이 빙의하고, 마이크로소프트만 보면 설명서가 설명서를 낳기 시작합니다. 기사 공장에 필요한 건 여러 강력한 자료와 그 기사의 목적을 이어 주는 편집 판단입니다.
1. 가장 먼저 보는 것은 '이번 주문'
최우선은 이번 사용자의 지시입니다.
"빠짐없이", "짧게", "개그 많이", "연구 기반으로", "이미지 없이", "12개 언어로", "개인정보는 빼고" 같은, 이번에만 해당하는 조건이 있습니다. 옛 템플릿이 아무리 훌륭해도 주문이 라멘인데 카레를 내놓으면 그냥 사고입니다.
여기서 정하는 것은 주로 다음 5가지입니다.
- 누구를 위한 글인가
- 독자의 궁금증은 무엇인가
- 다 읽고 나면 무엇을 알게 되고, 무엇을 할 수 있어야 하는가
- 어디까지 조사해야 하는가
- 이번에만 적용되는 금지 사항·형식·어조는 무엇인가
이 단계에서 기사의 "Reader Need(독자의 필요)"와 "Reader Outcome(읽은 뒤의 성과)"를 정해 둡니다.
2. 다음으로 보는 것은 과거 메모리와 지난 세션
기사에는 그 자리의 지시만으로는 부족합니다. 쌓여 온 편집 규칙이 필요합니다.
예를 들어 현재 기준에는 이런 규칙이 있습니다.
- 평범한 성인에게 자연스럽게 읽히면서도, 중학생이 읽어도 뜻을 따라갈 수 있다
- 5초면 결론, 30초면 개요
- 제목만 봐도 무슨 글인지 안다
- H2(큰 소제목)만 읽어도 흐름이 보인다
- 원칙적으로 한 문단에 한 주제
- 결론 → 이유 → 구체적인 예
- 전문 용어는 이름보다 먼저 정체를 설명한다
- 개그는 논점을 이해하기 쉽게 하려고 쓴다
- 개인을 특정할 수 있는 정보는 일반화한다
- 12개 언어는 직역하지 않는다
여기서 중요한 점은 과거 메모리를 사실의 출처로 삼지 않는다는 것입니다.
"예전에 이렇게 정했다"는 제작 방침에는 쓸 수 있습니다. 하지만 가격, 법률, 사양, 연구 결과, 현재의 제도까지 "전에 그렇게 말했으니까"로 밀어붙이면 기사가 타임캡슐이 됩니다.
메모리는 편집 방침의 연속성에 쓰고, 사실은 현재의 증거로 돌아가서 확인합니다.
3. GitHub의 최신 main은 '지금의 사용 설명서'
장기 운영에서는 GitHub의 최신 main이 기사 공장의 정본(원본 기준)입니다.
현재의 품질 시스템은 29번째 품질 축을 새로 늘리지 않습니다. 대신 기존 28개 상위 축 아래에 전문 편집 노하우를 서브 게이트로 통합했습니다.
AI가 보는 대표적인 정본은 다음과 같습니다.
- 현재의 품질 epoch
- 28개 품질 축
- 독자 경험·인지 접근성
- 콘텐츠 품질
- Microsoft / Google 확장 기준
- 전문 편집 워크플로
- 일본어 편집 규칙
- 자연스러운 문장 스타일
- 다국어·현지화 기준
- 정보 패스포트·신선도
- PASS / SAMPLE_PASS / COMPLETE_100의 정의
- 정식 채택·공개·검증 계약
여기서 중요한 건 옛 성공 기록보다 최신 규칙이 위라는 점입니다.
어제 100점이던 기사도 품질 규칙이 바뀌면 "어제의 100점"이라는 역사가 됩니다. 구 규정으로 전승을 거둬도, 새 규정의 대회에 "어제 이겼으니 오늘도 우승입니다"라며 들어갈 수는 없죠.
4. 원본 기사와 원자료는 '절대 깨면 안 되는 땅'
편집할 수 있는 것은 글의 보여 주는 방식이지, 사실을 입맛대로 바꾸는 일이 아닙니다.
특히 지키는 것은 다음과 같습니다.
- 숫자
- 날짜
- 금액
- 단위
- 인원수
- 제도 이름
- 제품 사양
- URL
- 인용
- 출처
- 고유명사
- 연구 설계
- 불확실성
- "모른다"는 상태
읽기 쉽게 하려고 "약 30%"를 "절반쯤"으로 바꾸면, 읽기 쉬운 걸 넘어 다른 세계선이 됩니다.
AI 편집자의 기본은 의미를 바꾸지 않고 순서·설명·예시·제목·표현을 고치는 것입니다.
5. 웹에서는 '강한 근거'부터 본다
현재성이나 외부 사실이 필요한 기사는 웹을 조사합니다. 다만 검색 결과 맨 위부터 차례로 넙죽 엎드리지는 않습니다.
정보원은 대략 다음 순서의 강도로 봅니다.
- 규격·법령·1차 자료
- 공식 제공자의 가이드·사양
- 1차 연구·동료 심사를 거친 연구
- 전문적인 편집·보도 기준
- 신뢰할 수 있는 2차 자료
- 커뮤니티·SNS·체험담
물론 기사 유형에 따라 달라집니다.
"이용자가 실제로 어떻게 느꼈는가"라면 Reddit이나 SNS가 의미를 가질 수도 있습니다. 반대로 "WCAG(웹 접근성 표준)의 필수 조건이 뭔가"를 게시판의 "아마 24px일걸요ㅋ"로 정해 버리면 규격이 웁니다.
또한 분석·비교·연구·추천·영향이 큰 기사에서는 자신의 결론을 무너뜨릴 수 있는 자료도 찾아봅니다.
"이 가설을 지지하는 자료를 5개 모았습니다!"만으로는 연구가 아니라 팬클럽입니다.
6. 28개 품질 축은 '28명의 신'이 아니다
현행 시스템은 28개 상위 축을 유지합니다. 크게 보면 독자 경험 17축과 내용 품질 11축입니다.
독자 경험의 17축
- 주의
- 기억
- 판단
- 처리 속도
- 이해
- 정보의 냄새(원하는 정보가 어디 있는지 알려 주는 단서)
- 시각적 혼잡
- 위계
- 레이아웃
- 글자
- 색·시각
- 조작
- 다국어
- 보조 기술
- 움직임
- 상태 변화
- 실제 데이터에 대한 내성
내용 품질의 11축
- 독자·목적·읽은 뒤의 성과
- 독자적 가치
- 신뢰·저자·제작 방법
- 위험·숫자·의사결정
- 표·그림·이미지의 의미
- 절차·행동·기억 부담
- 포용성·문화
- 독자의 과제 성립 여부
- 지역별 완성도
- 성능·집중해서 읽기
- 소리로 읽었을 때의 글
28개를 체크리스트처럼 매번 본문에서 전부 읊을 필요는 없습니다.
목적은 "축을 채우는 것"이 아니라, 독자가 어디에서 걸려 넘어질지를 먼저 생각하고 그 장벽과 관련된 축을 쓰는 것입니다.
기사 공장에서 "오늘의 28신께 올릴 공물이 아직 3축 부족합니다"라고 말하기 시작하면, 그건 품질 관리가 아니라 종교 법인입니다.
7. 전문 편집의 14개 서브 게이트를 본다
28개 상위 축 아래에는 전문 편집 공정으로서 14개의 서브 게이트가 있습니다.
- 독자의 필요와 읽은 뒤의 성과
- 기사의 접근 각도
- 도입부의 훅
- 이 글은 무슨 이야기이고 왜 중요한가
- 중요한 정보를 앞에 내기
- 각 문단의 역할
- 주장과 근거의 대응
- 반증 체크
- 정보원의 강도
- 구조 → 사실 → 문장 순서로 편집
- 제목의 약속을 본문에서 지키기
- 다음에 무엇이 나올지 예측할 수 있는 동선
- 표기·용어의 일관성
- 공개 후의 신선도와 콘텐츠 부채
다만 이걸 모든 기사에 기계적으로 적용하지는 않습니다.
맛집 체험 기사에 로이터식 뉴스 구조를 통째로 입힐 필요는 없고, API 사양서를 "갑자기 면이 웃었다."로 시작할 필요도 없습니다.
기사 유형에 맞는 기법만 쓴다. 이게 중요합니다.
8. 편집 순서는 '구조 → 사실 → 문장'
전문 편집에서 은근히 효과가 큰 것이 순서입니다.
1회차: 구조
- 독자의 의문에 답하고 있는가
- 접근 각도가 있는가
- 결론이 너무 늦지 않은가
- H2만으로 흐름이 통하는가
- 중복된 장은 없는가
- 불필요한 장은 없는가
2회차: 사실과 근거
- 주장에 근거가 있는가
- 그 근거가 정말로 주장을 뒷받침하는가
- 숫자의 모집단이나 비교 대상이 필요하지는 않은가
- 반대 증거는 없는가
- 오래된 정보는 아닌가
3회차: 문장
- 한 문장에 너무 많이 욱여넣지 않았는가
- 전문 용어를 설명했는가
- 지시어("이것", "그것")가 길을 잃지 않았는가
- 개그가 먹히고 있는가
- AI 티 나는 장식용 굵은 글씨나 "※ 참고" 연발이 되지 않았는가
이 순서를 거꾸로 하면 다음 주에 헐 집의 벽지만 반짝반짝하게 새로 바르는 편집이 됩니다.
9. 수치 규칙은 3종류로 나눈다
숫자가 나오면 AI는 갑자기 "기준값"을 만들고 싶어질 때가 있습니다. 거기서 제동을 겁니다.
수치는 반드시 3종류로 나눕니다.
공식·규격이 정한 수치
예: WCAG의 320 CSS px 상당 리플로(화면 폭에 맞춰 내용이 다시 배치되는 것), 200% 글자 확대, 대상 크기 등.
이것은 그 규격이 정한 범위와 예외 안에서 hard gate(반드시 통과해야 하는 관문)로 삼을 수 있습니다.
연구에서 얻은 수치
연구 대상, 언어, 조건, 표본이 다르면 그대로 만능 기준이 될 수 없습니다.
"영어로 ○단어"라는 연구 결과가 있다고 해서 "일본어로는 ○글자"라고 계산기로 연금술을 부려서는 안 됩니다.
사이트 내부의 휴리스틱
예: "H2가 4개 이상이면 목차를 확인한다."
리뷰 후보를 찾아내는 기준으로는 편리하지만, 기준이 경찰관으로 승진해서는 안 됩니다.
구글 스스로도 "구글이 좋아하는 글자 수" 같은 만능 수치를 제시한 적이 없습니다. 길이보다, 목적에 필요한 내용을 채웠는지를 봐야 합니다.
10. 12개 언어는 번역이 아니라 현지화한다
지원 언어는 다음과 같습니다.
- 일본어
- 영어
- 한국어
- 중국어(간체)
- 중국어(번체)
- 스페인어
- 포르투갈어(브라질)
- 인도네시아어
- 태국어
- 베트남어
- 프랑스어
- 독일어
다국어화에서는 단어를 3종류로 나눕니다.
LOCALIZE_CONCEPT
일반적인 개념은 그 언어에서 보통 이해되는 말로 바꿉니다.
KEEP_EXACT_NAME
제품명, 규격명, API, URL, 코드, 파일명, 논문 식별자처럼 정확한 이름이 중요한 것은 그대로 보존합니다.
KEEP_EXACT_NAME_WITH_LOCAL_DESCRIPTOR
이름은 보존하되 그것만으로는 무엇인지 알 수 없을 때는, 그 언어로 짧은 설명을 덧붙입니다.
일본어의 어순·줄바꿈·말장난을 12개 언어에 복사하는 건 번역이 아닙니다.
그건 해외여행 가서 일본 콘센트를 기합으로 꽂고 있는 상태입니다.
농담도 의미를 현지화합니다. 통하지 않는 개그는 다른 자연스러운 웃음으로 바꿉니다.
11. PASS는 평균 점수가 아니라 게이트 방식
현행의 기본은 gate-first-score-second(먼저 관문, 점수는 그다음)입니다.
즉,
"사실은 틀렸지만 디자인 95점, 문장 96점, 평균 90점 넘었으니 합격!"
같은 건 없습니다.
중대한 FAIL은 평균 점수로 지워지지 않습니다.
SAMPLE_PASS
확인한 표본에서는 중대한 문제가 없었다.
PASS
현재 대상 범위가 정확히 정의되어 있고, 필요한 증거가 현재의 콘텐츠 identity·품질 epoch·규칙 버전에 묶여 있으며, 필요한 항목에 해결되지 않은 중대한 UNKNOWN이 없다.
COMPLETE_100
적용되는 hard gate, 의미 검토, 필요한 외부/runtime 증거까지 성립하고, 현재의 모든 대상에서 닫혀 있다.
사람이 채점하지 않았다고 해서 FAIL로 치지는 않습니다. 현재는 source-grounded AI semantic editor(출처에 근거한 AI 의미 편집자)가 정식 의미 검토의 주체입니다.
다만 AI가 자기가 써 놓고,
"AI 선생님의 엄정한 심사 결과, AI 선생님의 글은 완전히 올바르다고 판정되었습니다"
라고 해 봐야 증거가 되지 않습니다.
재판관은 AI여도 좋다. 하지만 증거물까지 재판관이 찰흙으로 빚어서는 안 된다.
12. 본문 다음은 실제 화면을 본다
기사 본문이 맞아도 화면에서 깨지면 읽을 수 없습니다.
실제 사이트에서는 적어도 다음 같은 상태를 확인합니다.
- 320px급 스마트폰
- 390px급 스마트폰
- 가로로 눕힌 스마트폰
- 태블릿
- 1280px / 1440px급 PC
- 200% 글자 확대
- WCAG Text Spacing(글자·줄 간격을 넓혀도 깨지지 않는지 보는 기준)
- 의사 현지화(번역 때 글자가 늘어나는 상황을 흉내 내는 시험)로 글자가 불어난 상태
- forced-colors(고대비 표시 모드)
- reduced-motion(애니메이션을 줄이는 설정)
또한 실제 데이터의 '지뢰'를 씁니다.
- 가장 긴 제목
- 가장 긴, 줄바꿈할 수 없는 문자열
- 가장 긴 본문
- 가장 짧은 본문
- 소제목이 가장 많은 글
- 링크가 가장 많은 글
- 표가 가장 많은 글
- 정의 목록처럼 생긴 요소가 가장 많은 글
- code / pre가 가장 많은 글
- 여러 문자 체계가 섞인 글
평범한 기사로만 "괜찮았습니다!" 하고 확인하면, 도서관에서 스쿼트를 하고 건강검진을 마친 기분이 되는 정도로 검사 범위가 다릅니다.
오류, 0건, 로딩 실패, 번역 누락 같은 상태도 기사 경험의 일부입니다.
13. 연구 규칙도 스스로 돌아간다
품질 규칙 자체도 낡습니다.
그래서 기존의 중앙 감사에 연구 업데이트를 넣어 두었습니다.
- 일반 refresh: 원칙적으로 7일마다
- deep sweep: 원칙적으로 30일마다
- 중대한 공식 변경: 필요하면 앞당김
살펴보는 대상에는 W3C/WCAG, ISO 24495, Microsoft, Google, Reuters, AP, GOV.UK, 인지과학, HCI(인간과 컴퓨터의 상호작용), 읽기 연구, 정보 탐색, 접근성, 다국어·편집 연구 등이 있습니다.
새로운 발견은
기존 규칙과 겹치지 않는가 → 정보원은 강한가 → 어느 기사에 적용하는가 → 수치의 범위는 어디까지인가 → 반대 증거는 없는가
를 확인한 뒤,
- ADOPT
- CONDITIONAL
- TEST
- DEFER
- REJECT
- SUPERSEDED
중 하나로 분류합니다.
2026년 8월 28일 v5의 첫 deep sweep에서는 현행 PASS 기준을 뒤집을 만한 변경이 발견되지 않았고, v5를 유지하기로 판단했습니다.
14. 공식 가이드는 신탁이 아니다
Microsoft, Google, Reuters, AP, W3C, ISO. 모두 강력한 자료이지만 적용 범위가 다릅니다.
예를 들어 기술 문서에서는 관용구나 유머를 줄이는 것이 번역 용이성과 정확성에 도움이 될 때가 있습니다.
하지만 그 규칙을 맛집 체험기나 오락 기사에 전부 적용하면,
햄버그스테이크를 섭취했다. 육즙이 발생했다. 만족도가 향상되었다.
같은, 감정을 준법감시실에 두고 온 문장이 완성됩니다.
공식 가이드는 "어떤 맥락에서 옳은가"를 봅니다.
공식이니까 모든 기사에 ADOPT가 아니라, 필요하면 CONDITIONAL입니다.
15. GitHub가 죽어도 기사의 두뇌까지 죽게 하지 않는다
GitHub를 가져올 수 없을 때도 기사 작성과 의미 검토를 전부 멈출 필요는 없습니다.
복구 baseline(기준선)으로 다음을 별도 계통에도 남겨 둡니다.
- 28개 상위 축
- AI 편집자 방침
- 전문 편집 워크플로
- 정보원의 강도
- 수치 기준
- 연구 업데이트 방법
- PASS 판정
- 공장을 멈추지 않는다는 원칙
다만 GitHub가 보이지 않을 때, 다음을 상상으로 채워서는 안 됩니다.
- current SHA(현재 커밋 ID)
- 최신 receipt(처리 확인 기록)
- repo에 적용되었는지 여부
- 현재의 정식 진행 상황
그건 UNKNOWN입니다.
GitHub가 복구되면 latest main + 복구 baseline + 최신 1차·공식 정보를 대조해서 평소 운영으로 돌아갑니다.
"마지막에 쓴 쪽이 이긴다"는 blind last-write-wins는 편집 방침이 아니라 가위바위보입니다.
16. 하지 않는 것
이 기사 공장에서는 적어도 다음을 피합니다.
- AI의 답변만을 사실의 근거로 삼는 것
- 사람의 검토를 하지 않았는데 "전문가 확인 완료"라고 쓰는 것
- 공식이 말하지 않은 숫자를 "구글 기준" 같은 이름으로 부르는 것
- 검색 순위만을 위해 저가치 기사를 대량 생성하는 것
- 제목만 자극적이고 본문에서는 답하지 않는 것
- 읽기 쉽게 하려고 원본 기사의 숫자나 불확실성을 바꾸는 것
- 모든 기사를 똑같은 뉴스형·기술 문서형에 밀어 넣는 것
- 일본어 제목·어순·개그를 다른 언어로 기계적으로 복사하는 것
- 본문 전체를 굵은 글씨로 두들겨 패는 것
- "※ 참고"를 잡초처럼 자라게 하는 것
- 기사 1건의 실패로 관계없는 공장까지 멈추는 것
- 표본 검사만으로 "전체 사이트 100점"을 자처하는 것
정리: AI 편집자는 '글을 쓰기 전'과 '쓴 뒤'가 더 바쁘다
글 쓰는 작업만 보면 AI 편집자는 문장 생성기처럼 보입니다.
하지만 실제 일은
의뢰를 읽는다 → 과거 규칙을 읽는다 → GitHub 정본을 읽는다 → 원자료를 지킨다 → 1차·공식·연구 자료를 조사한다 → 반증해 본다 → 구조를 만든다 → 사실을 검증한다 → 문장을 다듬는다 → 12개 언어로 현지화한다 → 실제 화면에서 부숴 본다 → QA로 마무리한다 → 규칙 자체도 정기적으로 연구한다
까지입니다.
"기사 써 줘"는 시작 버튼일 뿐, 일의 설명이 아닙니다.
기사 공장의 AI 편집자는 작가·교열자·리서처·번역 편집자·QA·설비 보전을 혼자서 순찰합니다.
그리고 가장 중요한 건 규칙을 지킨 문장을 만드는 것이 아니라, 독자가 뜻을 바로 짚고, 근거를 따라가고, 필요한 판단을 내릴 수 있는 기사를 만드는 것입니다.
규칙은 그걸 위한 공구입니다. 공구 상자를 숭배하려고 만든 기사 공장이 아닙니다.
