Microsoft와 Google의 공식 글쓰기 지침은 매우 유용하다. 핵심을 앞에 두고, 문장을 명확하게 쓰고, 용어를 통일하고, 접근성과 번역 가능성을 높이는 데 큰 도움이 된다.
문제는 이 지침을 모든 글에 똑같이 적용할 때 시작된다.
여행기에도, 게임 글에도, 음식 리뷰에도 기술 문서 규칙을 100% 적용하면 어느 순간 모든 글이 고객센터 문서처럼 보인다. 어제까지 농담하던 문장이 오늘은 “다음 단계를 수행하세요”만 말한다. 문장은 살아 있는데 성격은 퇴사했다.
독자가 헤매지 않게 해 주는 원칙은 적극적으로 빌리되, 다른 목적의 문서에 맞춘 문체까지 기계적으로 복사하지 않는다.
Google 개발자 문서 스타일 가이드도 프로젝트 고유 스타일을 먼저 적용하고, 독자에게 더 좋은 결과가 된다면 가이드에서 벗어날 수 있다고 설명한다.[4]
5초 결론: 스타일 가이드는 헌법이 아니라 안전 난간이다
| 층 | 역할 | 예 |
|---|---|---|
| 필수 | 반드시 정확해야 하는 조건 | 공식 명칭, 인용, 실제 접근성 요구사항 |
| 강한 권장 | 대부분의 글에서 이해도를 높이는 원칙 | 결론 우선, 명확한 제목, 짧은 단락 |
| 편집 목소리 | 매체와 독자에 따라 정하는 부분 | 유머, 비유, 말맛, 속도, 농담 |
세 층을 모두 절대 규칙으로 만들면 문제가 생긴다. Google의 세계 독자 대상 개발 문서 지침은 문화 의존적 관용구와 유머를 피하라고 권하지만,[5] 이것은 번역되는 기술 문서의 맥락이다. 모든 에세이와 리뷰에서 웃음을 금지한다는 뜻은 아니다.
기계적으로 지키면 왜 글이 밋밋해지는가
Microsoft는 중요한 내용을 먼저 배치하고, 짧고 명확한 제목·문장·단락을 사용하며, 긴 문서에는 이동 수단을 제공하라고 권한다.[1] 접근성 지침도 짧고 의미 있고 집중된 문장을 강조한다.[2]
문제는 자동 점수화다. “짧을수록 좋음”, “비유는 노이즈”, “구어체 삭제”로 바꾸면 글은 예측 가능한 공장 제품이 된다.
읽기 쉬운 글은 개성이 없는 글이 아니다.
읽기 쉬움은 독자가 의미를 이해하기 위해 낭비하는 노력을 줄이는 것이다.
Microsoft와 Google이 실제로 강조하는 것
Microsoft의 공통 방향은 독자를 길 잃게 하지 않는 것이다. 중요한 정보를 먼저 제시하고, 스캔하기 쉬운 구조를 만들고, 긴 글에는 내비게이션을 제공하며, 다양한 능력을 가진 독자도 이해하기 쉽게 작성한다.[1][2][3]
Google 개발자 문서 지침도 명확하고 간결하며 모호하지 않은 문장과 일관된 용어를 권장한다.[5] 동시에 프로젝트별 규칙을 우선하고, 독자에게 더 낫다면 가이드에서 벗어나도 된다고 한다.[4]
Google 검색 지침은 독창적인 정보·조사·분석, 충분한 설명, 실제 경험, 독자가 목표를 달성할 수 있는지를 본다.[6] 2026년 생성형 AI 검색 안내도 독특한 관점과 비범용 콘텐츠를 강조한다.[7]
명확하게 써라. 정확하게 써라. 독자를 도와라. 복사기가 되지는 마라.
Google이 말하지 않은 숫자를 “Google 기준”으로 만들지 않는다
자동화는 숫자를 좋아한다. 그래서 “한 문장은 무조건 몇 자 이하”, “몇 천 자 이상이어야 SEO에 좋음”, “제목은 반드시 몇 개” 같은 가짜 공식이 생긴다.
내부 경고값으로 쓰는 것은 가능하지만, 공식 문서에 없다면 공식 요구사항이라고 부르면 안 된다. Google 검색은 Google이 선호하는 고정 단어 수는 없다고 설명한다.[6]
- 공식 필수 조건
- 공식 권장 사항
- 내부 경험칙
집안 규칙에 Google 유니폼을 입히지 말자.
글을 세 층으로 나눈다
1. 사실의 뼈대
사실, 결론, 숫자, 날짜, 조건, 인용, 출처, 불확실성. 여기는 농담으로 바꾸지 않는다.
2. 이해의 길
제목, 요약, 순서, 단락, 표, 예시, 용어 설명, 내부 링크. 공식 가이드의 장점을 가장 많이 쓰는 곳이다.
3. 글의 목소리
유머, 비유, 관찰, 템포, 표현, 이상한 예시. 이 층을 전부 없애면 정확하지만 어디서나 볼 수 있는 글이 된다.
좋은 농담은 설명을 운반한다. 나쁜 농담은 설명을 숨긴다.
12개 언어에서는 농담의 문장이 아니라 역할을 번역한다
일본어 말장난이나 인터넷 밈을 그대로 번역하면 다른 언어에서는 아무 일도 일어나지 않을 수 있다. 그래서 세계 대상 기술 문서는 문화 의존 표현을 줄인다.[5]
일반 기사에서는 유머를 전부 지우기보다 기능을 로컬라이즈한다. 사실, 숫자, 논리, 출처, 불확실성은 고정하고, 어순, 훅, 비유, 예시, 농담, 리듬은 각 언어에 맞게 다시 쓴다.
12개 언어 출판은 일본어를 11번 변환하는 일이 아니라 같은 글을 12번 제대로 쓰는 일에 가깝다.
규칙은 메모리·정본·실행 지시로 나눈다
| 위치 | 역할 |
|---|---|
| 메모리 | 장기적인 편집 의도 |
| GitHub 같은 정본 | 세부 규칙, 예시, 적용 범위, 변경 이력 |
| 스케줄러·작업 지시 | 매 실행마다 최신 정본을 읽고 적용하도록 강제 |
세 곳에 같은 장문 규칙을 복붙해 각각 정본으로 만들면 안 된다. 하나의 상세 정본을 두고, 메모리는 철학을, 실행 지시는 최신 정본을 읽는 계약을 담당하게 한다.
자동 품질 검사는 “읽을 이유가 사라졌는가”도 확인해야 한다
결론을 바로 찾을 수 있는지, 제목만 읽어도 흐름이 보이는지, 전문 용어를 몰라도 이해 가능한지, 숫자와 출처가 보존됐는지, 독자적인 분석·관찰·경험이 남아 있는지, 의미 있는 유머를 이유 없이 지우지 않았는지, 수정 후 흔한 AI 요약처럼 변하지 않았는지를 본다.
Google 스팸 정책은 AI 생성, 번역, 재작성 등으로 대량 콘텐츠를 만들면서 사용자에게 거의 추가 가치를 주지 않는 경우를 문제로 본다.[8]
고친 뒤 읽을 이유가 사라졌다면 최적화는 실패다.
글쓰기 자동화의 흔한 실패 5가지
실패 1: 전부 짧게 만든다
문장을 자르다가 의미 관계까지 자른다. 해결: 길이보다 한 번 읽고 관계가 보이는지를 본다.
실패 2: 모든 단락을 같은 틀로 만든다
구조는 편하지만 리듬까지 같으면 금방 지친다. 해결: 정보 순서는 정리하되 문장 호흡까지 고정하지 않는다.
실패 3: 유머를 잡음으로 처리한다
설명을 기억하게 해 주는 비유까지 없앤다. 해결: 의미를 운반하는 농담은 남기고 탈선만 줄인다.
실패 4: 개발자 문서 스타일을 검색 순위 규칙으로 착각한다
문체와 검색 품질은 다른 문제다. 해결: 문체, 검색, 접근성, 현지화를 별도 층으로 본다.
실패 5: 숫자를 만든다
출처에 없는 기준을 Google 기준이라 부른다. 해결: 내부 경험값은 내부 경험값이라고 명시한다.
마지막 점검
- 몇 초 안에 주제와 결론이 보인다.
- 30초 안에 전체 구조를 훑을 수 있다.
- 제목만으로 흐름을 이해할 수 있다.
- 쉬운 말이 정확성을 해치지 않는다.
- 숫자·출처·불확실성이 정확하다.
- 긴 글에서도 길을 잃지 않는다.
- 독자적인 가치가 있다.
- 농담이 설명을 돕는다.
- 12개 언어에서 농담의 기능을 현지화했다.
- 공식 필수·공식 권장·내부 규칙을 구분했다.
- 최종 글에 “굳이 이 글을 읽을 이유”가 남아 있다.
스타일 가이드는 강력하다. 그래서 통째로 삼키면 안 된다.
안전 난간은 필요하다. 도로 전체를 난간으로 만들면 아무도 달릴 수 없다.
