educational-content-writing

name	educational-content-writing
description	AI 보조 시리즈형 교육 글(컬렉션)의 본문 구성·깊이·slug·00 챕터·내용 완결성(석학/SME 기준: 오개념·개념 연결·1차 출처·과목별 필수 요소)·품질 체크리스트를 표준화한다. design-patterns, cleanarchitecture, optimization 시리즈, C++ 성능 트랙, 장문 기술 튜토리얼, 커리큘럼형 블로그 포스트를 작성·보강할 때 사용한다. blog-post-writing 스킬 및 rules-that-must-be-followed와 함께 적용한다.

AI 활용 교육 자료 품질 가이드

이 스킬은 AI로 생성·보완하는 교육 콘텐츠(블로그/시리즈형 글)의 품질을 일관되게 유지하기 위해 적용된다.

적용 대상: content/collection/**/index.md 중 교육/시리즈형(본문 구성, 분량, slug, 00 챕터, 체크리스트가 필요한) 글을 작성·보강할 때.

함께 적용

• rules-that-must-be-followed: frontmatter, Mermaid, 알고리즘 주석, 링크 검증 등 전역 규칙
• blog-post-writing 및 reference.md: 제목 형식·카테고리 접두어·날짜, 내부 링크(/post/...) 상세

---

0. 핵심 원칙 (항상 우선 적용)

본문을 작성·수정하기 전, 아래 3원칙을 먼저 점검한다 (상세는 §2.5/§4.4/§5.2).

1. 안티패딩: 분량은 목표가 아니라 결과다. 닫는 절(요약·FAQ·체크리스트·네비)은 종류별 1개만 두고, 중복 요약·답 없는 번호 리스트(질문 24/메모 20류)·작성자용 자기인증("게시 전 자가 점검" 등)·존재하지 않는 파일 참조를 본문에 넣지 않는다.
2. 컴파일 가능한 코드: 핵심 예제는 #include·타입 정의를 갖춰 컴파일 가능해야 한다. 주석뿐인 블록·미정의 타입으로 핵심을 대체하지 않는다.
3. 수치·사실 근거: "정량적"·"측정"을 표방하면 실제 수치(플랫폼·플래그 명시) 또는 실행 가능한 벤치를 포함하고, 크기·새니타이저·디스패치 같은 사실 주장은 검증하거나 "구현 정의"로 표기한다.

---

1. 목적

• AI 보조로 작성하는 교육 자료의 본문 구성·길이·깊이·시각 요소를 표준화한다.
• 역사·배경·인용이 있는 주제는 출처와 맥락을 명확히 한다.
• 전문가 양성에 맞게, 학습 성과 목표·판단 기준·실무 적용·비판적 시각을 요구한다.
• 게시 전 품질 체크리스트로 누락·환각을 줄인다.

---

2. 본문 구성

2.0 본문 서술 원칙 (문단 중심)

• 문단이 설명의 중심: 본문에서 개념·원칙·판단 기준·학습 결과는 **문단(연속된 문장)**으로 서술하여, 리스트·표·코드 블록 없이도 독자가 핵심을 이해할 수 있도록 구성한다.
• 리스트·표·코드는 부가: 목록(불릿/번호 리스트), 표, 코드 블록, Mermaid 다이어그램은 문단으로 서술한 내용을 요약·구체화·시각화하는 보조 수단으로 둔다. 즉, "문단으로 말한 뒤 리스트/표/코드로 정리·예시" 순서를 지향한다.
• 평가 기준·학습 목표: "이 글을 읽은 후 달성해야 할 목표"처럼 리스트로만 제시하는 경우, 그 앞에 같은 내용을 문단으로 요약하여, 리스트를 읽지 않아도 문단만으로 무엇을 할 수 있게 되는지 전달되게 한다.

2.1 필수 섹션 순서

다음 순서를 지키되, 주제 성격에 따라 일부 절은 생략 가능하다.

1. 도입: 동기/배경 — "왜 이 주제인가", 인용문·훅 또는 정의 한 줄 + 동기. 시리즈 전체의 도입인 00 챕터에는 컬렉션 전체 동기와 챕터별 필요성·학습 결과까지 포함하는 것이 좋다.
2. 정의·원칙: 핵심 용어 정의(첫 등장 시 굵게), 원칙·구조(목록 또는 표).
3. 예시 또는 코드: 실제 동작을 보여주는 코드 블록 또는 다이어그램.
4. 비교·트레이드오프 또는 요약: 전통 vs 개선, 장단점, 한눈에 보기 표 등.
5. 마무리: 다음 중 하나 이상 — "핵심 요약" 테이블, "평가 기준/체크리스트", "핵심 메시지", "다음 장에서는" 링크.
6. 전문가 양성 요소(아래 §2.4): 학습 성과 목표, 언제 쓸지/피할지 판단 기준, 실무 적용·비판적 시각을 적절히 포함한다.

2.2 시리즈 글

• 커리큘럼/파트 테이블 또는 "다음 장에서는" 문단으로 선후 관계를 명시한다.
• 개요/인트로 글에는 학습 목표·커리큘럼 구성을 포함한다.
• 00 챕터(또는 개요) 필수 요소: 시리즈/컬렉션의 **00 챕터(또는 개요)**에는 다음 세 가지를 반드시 포함한다. (1) 동기(왜 배우는가): 이 주제/컬렉션을 배우는 이유, 해결하는 문제, 학습을 통해 얻는 것(역량·결과). (2) 챕터/Phase별 필요성: 각 Phase 또는 주요 챕터가 전체 목표에 어떻게 기여하는지, 왜 그 순서인지, 건너뛰면 어떤 한계가 있는지 중 하나 이상을 서술 또는 표로 제시. (3) 학습 결과(무엇에 도움이 되는지): 완주 시 갖추게 되는 역량·할 수 있는 일·실무/취업 관점의 이점을 요약하고, 가능하면 Phase/챕터와 역량의 연결을 명시한다.
• 컬렉션 소개·커리큘럼: 시리즈/컬렉션의 소개·커리큘럼·학습 방법·참고 자료는 아래 §2.2.1을 따른다.

2.2.1 컬렉션 순서 및 00 챕터

• 컬렉션 내 순서: frontmatter collection_order(정수)로 컬렉션 내 페이지 순서를 지정한다. 숫자가 작을수록 앞에 오며, 첫 챕터·개요는 0을 쓴다.
• series_order는 사용하지 않는다. 사이트는 정렬 시 collection_order만 사용한다.
• 목록 페이지: 컬렉션 목록 페이지(list.html)는 section의 본문(_index.md의 .Content)을 렌더하지 않고, 제목·설명·이미지만 사용한다. 따라서 시리즈/컬렉션 소개·커리큘럼·학습 방법·참고 자료는 _index.md가 아니라 00 챕터(예: 00-introduction, 00-curriculum-overview)에 두어야 독자가 실제로 볼 수 있다.
• 00 챕터에는 **collection_order: 0**을 두어 목록에서 맨 앞에 오게 한다.
• _index.md는 section 메타데이터(title, description, weight, featured_image 등)용으로 두고, 본문은 비우거나 "전체 소개는 00. xxx 참고."처럼 한 줄만 둔다.
• 다른 컬렉션(optimization, python 시리즈 등)도 소개/커리큘럼이 길면 00 챕터에 두고 _index 본문은 최소화한다.

2.2.2 Slug

• 필수: 컬렉션·시리즈 글은 URL 안정성과 가독성을 위해 frontmatter에 **slug**를 명시한다. (Hugo 기본 경로에만 의존하지 않음)
• 형식: 소문자, 단어 구분은 하이픈(-), 공백·특수문자 없음, 영문만 사용.
• Section (_index.md): 컬렉션을 대표하는 짧은 slug (예: cpp-optimization, design-patterns).
• 00 챕터 (인트로/커리큘럼): getting-started- + 컨텍스트(트랙/도메인) + 필요 시 -performance-tuning, -fundamentals 등 (예: getting-started-cpp-language-performance-tuning).
• 일반 챕터 (01~): 폴더명에서 숫자 접두사 NN-를 제거한 kebab-case를 기본으로 하고, 주제를 구체화할 필요가 있으면 보조 키워드를 하이픈으로 이어 붙인다 (예: abstraction-cost, optimization-flags-o2-o3-ofast).

2.3 제목 계층

• H2 → H3 → (필요 시) H4까지 사용 가능하다. H4 초과 깊이는 지양한다.
• 각 섹션은 한 가지 큰 아이디어만 다루고, 긴 절은 3~5개 하위 절로 나눈다.

2.4 전문가 양성에 필요한 요소

독자가 단순 암기가 아니라 판단·적용·비판을 할 수 있도록 다음을 반영한다.

• 학습 성과 목표: 글 말미에 "평가 기준" 또는 "이 글을 읽은 후 달성해야 할 목표" 절을 둔다. 독자가 설명·구분·비교·리팩토링 등을 할 수 있는지 구체적으로 나열한다 (예: "X와 Y의 차이를 설명할 수 있다", "상황 A에서는 X를, B에서는 Y를 선택할 수 있다").
• 판단 기준: 해당 기술/패턴을 언제 사용하고 언제 피할지를 표·체크리스트 또는 문단으로 제시한다. "적용 체크리스트", "사용해도 되는 경우 / 피해야 하는 경우" 형태를 권장한다.
• 실무 적용: 가능하면 실무자를 위한 권장사항, 리팩토링 가이드, 대안 패턴/기술을 다룬다. 레거시 이해·현대적 대안과의 연결을 포함하면 좋다.
• 비판적 시각: 한계, 논란, Anti-pattern 관점, 트레이드오프를 다루어 무조건 따르는 규칙이 아니라 상황에 따른 선택임을 드러낸다.

2.5 안티패딩 (반복·필러 금지)

분량을 채우려고 같은 내용을 반복하거나 가치 없는 블록을 덧붙이면 품질이 떨어진다. 아래는 금지한다.

• 닫는 절은 종류별로 1개만: "핵심 요약", "FAQ", "체크리스트", "이전·다음 장 네비게이션"은 각각 하나씩만 둔다. "최종 정리", "마무리(최종)", "요약 표(최종)", "이 장을 마치며", "학습 목표 재확인", "이 장에서 다룬 내용", "용어 정리(추가)"처럼 같은 내용을 다른 제목으로 반복하지 않는다.
• 답·해설 없는 번호 리스트 덤프 금지: "체크 질문 24", "한 줄 메모 20", "오해하기 쉬운 문장 30", "미니 레슨 20"처럼 항목만 길게 나열하고 설명이 없는 목록은 두지 않는다. 체크리스트는 6개 내외 핵심 항목으로 좁히고, 각 항목에 한 줄 근거를 붙인다.
• 독자용이 아닌 메타 블록 금지: "게시 전 자가 점검", "평가 기준 재확인: 충족" 같은 작성자용 자기인증을 본문에 남기지 않는다(QA는 별도로 하고 본문에서는 지운다).
• 존재하지 않는 파일·자료 참조 금지: 저장소에 실제로 없는 파일(예: 길이 목표 점검 파일)이나 확인되지 않은 자료를 본문에서 인용하지 않는다. 본문 링크는 항상 실재·접근 가능 여부를 확인한다.

판단 기준: **"이 절을 지워도 독자가 잃는 학습 가치가 없다면 패딩"**이다. 패딩은 추가하지 말고, 그 자리에 실제 코드·측정·사례를 넣는다.

2.6 레벨별 학습 경로 (다단계 독자 대상 글)

초보자부터 전문가까지 같은 글에서 다루는 기술 심화 챕터(예: 동시성·성능·아키텍처 패턴 시리즈)는 다음 두 절을 도입부 직후에 둔다. (multithreading-design-patterns 컬렉션의 각 챕터가 이 형식의 실제 예시다.)

• "이 장을 읽기 전에": (1) 완전한 초보자 안내 — 이 장이 전제하는 선행 챕터를 [NN장: 제목](/post/.../slug/) 링크로 명시하고, 어떤 개념을 이미 안다고 가정하는지 한두 문장으로 적는다. (2) 이 장의 깊이 — 난이도 범위(예: "초급전문가", "중급전문가")와 전문가 구간에서 추가로 다루는 내용을 명시한다. (3) 다루지 않는 것 — 범위 밖 주제와, 그 주제를 다루는 다른 챕터/컬렉션으로의 링크를 적어 독자가 헤매지 않게 한다.
• "당신의 수준에 맞는 경로" 표: 수준 | 읽을 부분 | 핵심 목표 3열 표로, 최소 2단계(예: 초보자/전문가) 이상의 독자가 각자 어디를 읽고 무엇을 얻을지 한눈에 보게 한다. 섹션 제목이 바뀌면 이 표도 함께 갱신한다(표가 가리키는 섹션명과 실제 본문 제목이 어긋나지 않도록).

이 두 절은 시리즈의 모든 챕터에 일관되게 적용한다 — 일부 챕터에만 있으면 독자가 "이 챕터는 더 쉬운가/어려운가"를 글의 다른 신호 없이 추측해야 한다.

챕터를 추가·재배치하거나 슬러그를 바꾸면 위 "선행 챕터" 링크와 "다음 장에서는" 서술이 다른 챕터에서 stale해지기 쉽다 — 상세 감사 절차는 collection-writing-standards §6.1을 따른다.

2.7 검증 가능한 코드 진행 (Broken → Fixed → Verification)

정확성이 핵심인 주제(동시성, 메모리 안전성, 동기화, 자료구조 불변식 등)는 코드를 다음 순서로 배치한다.

1. 깨진 코드: 흔히 작성하는 자연스럽지만 잘못된 버전을 먼저 보여준다.
2. 원인 설명: 왜 깨졌는지를 표준/사양 또는 메모리 모델 같은 근거 있는 언어로 설명한다("우연히 동작함"과 "보장됨"을 구분).
3. 올바른 구현: 표준 라이브러리 기능 또는 정립된 패턴으로 고친 버전을 제시한다.
4. 안전성 검증: 두 버전을 실제로 검증할 수 있는 도구·명령을 제시한다. C++ 동시성이라면 g++ -std=c++20 -pthread -fsanitize=thread -g ...(ThreadSanitizer)처럼 "깨진 버전은 경고가 뜨고, 고친 버전은 안 뜬다"를 확인하는 절차를 구체적으로 적는다. 다른 언어/도메인이면 그에 맞는 도구(예: -fsanitize=address, Valgrind, 정적 분석기, 프로퍼티 기반 테스트)로 대체한다.

"경고가 없다"는 "이번 실행에서 못 봤다"일 뿐 "안전 증명"이 아니라는 점을 본문에서 한 번은 짚어준다 — 특히 플랫폼(x86 vs ARM)이나 최적화 옵션에 따라 결과가 달라질 수 있는 주제에서는 필수다.

---

3. 길이 (품질의 결과이지 목표가 아니다)

• 분량은 목표가 아니라 결과다. 정해진 줄 수를 채우려고 같은 내용을 반복하거나, 답 없는 목록·자가 점검 블록을 덧붙이지 않는다(§2.5 안티패딩).
• 줄 수 하한·상한 없음: 분량 기준(최소/최대 줄 수)을 두지 않는다. "충분한가"의 기준은 줄 수가 아니라 **내용 완결성(§7)**이다 — 완결성 축(메커니즘·오개념·연결·1차 출처 등)과 §2 필수 섹션이 채워졌으면 짧아도 완성이고, 비었으면 길어도 미완성이다. 짧다고 느껴지면 줄을 늘리지 말고 §7 체크리스트에서 빠진 축을 찾아 채운다.
• 분할 판단: 파트 나누기·별도 -practice 글 분리는 줄 수가 아니라 주제 단위로 판단한다 — 한 글이 서로 다른 큰 아이디어 여러 개를 다루기 시작하면(§2.3 위반) 그때 나눈다.
• 문장: 한 문장 15~25단어 권장. 한 단락은 한 가지 주제만 다룬다.
• 진행: 단순 → 복잡, 알려진 것 → 새로운 것 순서로 쓴다.

---

4. 깊이

4.1 역사·배경이 있는 주제

• "탄생 배경" 또는 "역사/진화" 절을 포함한다.
• 가능하면 연도·인물·저서명을 명시한다 (예: Alexander 1977, GoF 1994, Cockburn 2005).

4.2 기술 개념

• **"핵심 개념"**에서: 용어 정의 → 원칙/구조 → 예시(코드 또는 다이어그램) 순서를 유지한다.
• 주의·대안: 패턴/기술별 함정, 대안, 리팩토링 팁을 다룬다.

4.3 인용

• 외부 주장·정의는 blockquote로 넣고, **출처(저자, 연도 또는 링크)**를 반드시 적는다.
• 예: > "..." — Author Name, 『Book Title』(Year)

4.4 정확성 가드 (사실·수치 검증)

기본 정확성·출처 규칙은 collection-writing-standards §1.3을 따르고, 이 절은 "정량적/측정" 주장에 대한 추가 요구사항만 다룬다.

• 사실 주장 검증: 타입 크기·정렬(sizeof), 도구·새니타이저의 동작 범위, 디스패치 메커니즘(가상 호출 vs 함수 포인터 vs 타입 소거) 등은 단정하기 전에 검증한다. 구현/플랫폼에 따라 달라지는 값은 **"구현 정의"**로 표기하고 대표 예를 든다(예: "optional<int>는 보통 8바이트, 정확한 값은 구현 정의").
• "정량적"·"측정" 표방 시 근거 필수: 제목·본문에서 "정량 분석", "마이크로벤치마크로 측정"을 표방하면, 실제 수치(플랫폼·컴파일러·플래그 명시) 또는 실행 가능한 벤치마크 스켈레톤을 최소 1개 포함한다. 수치 없이 "수 배 빠르다"처럼 단정하지 않는다(예시 수치는 "측정값은 CPU·플래그에 따라 다름"을 병기).

---

5. 시각 요소 (다이어그램·코드·표)

5.1 Mermaid·표

• 구조/흐름/역사 설명 시 Mermaid 다이어그램 또는 Markdown 표 중 하나 이상 사용을 권장한다.
• Mermaid 작성 시 rules-that-must-be-followed의 라벨 따옴표·</br> 규칙을 준수한다.

5.2 코드 블록

• 실제 코드는 반드시 언어 지정 (예: java, cpp). 의사코드·구조 설명은 text 지정을 권장한다.
• 컴파일 가능해야 한다: 핵심을 보여 주는 예제는 #include·타입 정의를 갖춰 그대로 컴파일·실행 가능하게 쓴다. 주석만 채운 블록(/* ... 처리 ... */)이나 미정의 타입·식별자(T, vec, pred, BigObject 등 정의 없이 사용)로 핵심을 대체하지 않는다. 개념만 보일 때는 반드시 text로 표기해 "의사코드"임을 명시한다.
• 50줄 초과 시 요약 발췌 또는 별도 파일 링크를 권장한다.
• 알고리즘 정답 코드는 동일 규칙의 42jerrykim.github.io 주석 규칙을 따른다.

본문과 코드의 균형: 교육 글은 설명·원칙·비교·판단 기준이 코드와 균형을 이뤄야 한다. 코드 블록만 연속해서 나열하지 않는다. 각 코드 블록 앞에는 그 코드가 다루는 개념·목적·왜 이 방식을 쓰는지를 문단으로 2문장 이상 서술한다. 필요 시 코드 뒤에는 요약·주의점·트레이드오프를 1~2문장으로 정리한다. 한 절 안에 코드 블록이 2개 이상일 경우, 블록 사이에 설명 문단을 두어 코드가 연속하지 않게 한다. (참고: 본문(문단·목록·표)이 전체 본문+코드 줄 수의 최소 40% 이상을 차지하도록 권장한다.)

5.3 표

• 비교(전통 vs 개선), 구성요소, 챕터 목록 등에 Markdown 테이블을 활용한다. 표는 문단으로 서술한 내용을 한눈에 보이게 하는 보조로 두고, 표 없이도 문단만으로 요지가 전달되도록 구성한다.
• 복잡한 내용은 "한눈에 보기" 표/타임라인/체크리스트로 요약한다.

---

6. AI 사용 시

• AI로 초안을 생성한 경우: 인용·코드·연도·사실은 사람이 1회 검토하는 것을 권장한다 (환각 방지).
• 선택 사항: frontmatter 또는 글 말미에 검증 여부·주요 참고 자료·생성일을 두어 투명성을 높일 수 있다.
• "핵심 메시지/요약" 절을 두어 학습 목표를 명시하면, 품질·일관성 검증에 도움이 된다.

---

7. 내용 완결성 — 석학(SME) 기준

형식(§2~§5)이 갖춰져도 내용 커버리지가 비면 교육 글로 실패한다. "해당 과목의 세계적 석학이 이 글 하나를 학생에게 읽혀도 충분한가?"를 기준으로 아래를 점검한다. (2026-07 전 과목 표본 진단에서 형식은 충족했지만 이 축이 빈 글이 다수 발견되어 표준화했다.)

7.1 7대 완결성 축

#	축	핵심 질문	비고
C1	핵심 개념 완전성	표준 교재/문서 목차 대비, (범위 밖이라 밝히지 않은 채) 빠진 하위 개념이 없는가? 주제의 **메커니즘(내부 동작 원리)**을 서술했는가?	일반론 필러(§2.5)가 메커니즘 설명을 대체하면 실패
C2	역사·동기	누가·언제·왜 만들었는가?	상세 기준은 §4.1
C3	실제 적용	실무·연구의 구체적 사용 사례가 있는가?
C4	흔한 오개념	학생 대부분이 틀리는 지점 2~3개를 명시적으로 교정하는가? (예: SRP="하나의 일" 오해, 데코레이터-메서드 함정)	작성 전에 오개념 목록을 먼저 적는다
C5	개념 간 연결	선행/후행·인접 개념과의 관계를 링크 또는 문단으로 이었는가?	시리즈 네비(§2.2)와 별개로 개념 수준의 연결
C6	단계적 깊이	초보 진입점과 심화 지점이 계단식인가?	다단계 대상이면 §2.6
C7	심화·검증 경로	1차 출처(원저·표준 문서·PEP·man 등)와 다음 학습 링크가 최소 1개 있는가?	인용 형식은 §4.3, 수치 검증은 §4.4

작성 전: 표준 목차 대조 → 다룰 범위와 뺄 범위 결정("다루지 않는 것" 명시) → 오개념 2~3개 목록화 → 1차 출처 확보(접근 확인).

7.2 과목별 필수 요소

컬렉션 전용 스킬이 있으면 그 스킬이 상세 기준이다. 아래는 그 위에 얹는 SME 관점 추가 항목만 적는다.

• 코딩·CS 언어 기능 (python 등): 문법 나열이 아니라 메커니즘(예: 데코레이터 → f = deco(f) 디슈가링·클로저·functools.wraps의 역할). 표준 라이브러리 우선 — 손수 구현 전에 언어 정석(예: lru_cache)을 먼저 보이고 직접 구현이 정당한 경우를 설명. 버전 의존 기능은 버전 표기. 1차 출처는 PEP/언어 레퍼런스.
• 알고리즘 (algorithm-post-writing 기준 위에): 복잡도 3중 대조 — 본문 서술·다이어그램·코드의 복잡도가 서로 일치해야 한다(표본 진단 최다 치명 결함). 정당성/불변식 한 단락("왜 이 알고리즘이 옳은가"). 대안 풀이와의 트레이드오프 비교. 자료구조·인물 표기 표준 준수(예: Fenwick=펜윅).
• 설계·아키텍처 (design-patterns, cleanarchitecture 등): 정본 정의는 원저 blockquote + 출처(§4.3). 대중적 오해 vs 원 의도 대비(C4). 안티패턴·논란·현대적 대안 필수(§2.4의 비판적 시각).
• 명령어·도구 (bashshell, cmd): 옵션 나열 전에 정신 모델(도구가 세상을 보는 방식 — awk=레코드/필드). GNU vs BSD/POSIX 이식성 차이. man/공식 문서 링크.
• 수학: 정의→정리→증명(스케치) 순서, "직관"과 "증명" 구분 표기. 정리의 전제 조건과 반례 경계. 대수·기하·수치 등 다중 표현 병행. 오개념(상관≠인과 등).
• 과학: 개념의 경험적 근거(실험·관측). 모델의 적용 범위·한계(뉴턴 vs 상대론). 수치는 단위·자릿수와 함께. 정설과 열린 문제 구분.
• 역사: 1차/2차 사료 구분과 출처. 다관점(단일 서사 금지). 단일 원인 환원·시대착오 경계. 연표·지도 앵커.
• 언어·어휘 (vocabulary-post-writing 기준 위에): 태그가 약속한 요소(Etymology/Pronunciation/Antonym 등)는 본문에 반드시 실재해야 한다(§7.3의 태그=본문 일치).

7.3 태그=본문 일치 (frontmatter 과약속 금지)

frontmatter 태그는 본문에 실재하는 내용만 약속한다. Etymology, Pronunciation, Antonym, History 같은 내용성 태그를 달았으면 해당 절/문단이 본문에 있어야 하고, 없으면 본문을 채우거나 태그를 뺀다. Markdown, Technology, Deployment처럼 주제와 무관한 보일러플레이트 태그를 개수 채우기로 넣지 않는다 — 태그 25개는 blog-post-writing의 단어/의미/도메인 특화 조합으로 채운다.

---

8. 품질 체크리스트 (게시 전 확인)

글을 게시하기 전에 아래를 확인한다. (순서는 본문 구성 → 전문가 양성 → 내용 완결성 → 길이 → 깊이 → 시각 요소 순이다.)

본문 구성

• 도입에 동기/배경이 있는가?
• 정의·원칙과 **예시(코드 또는 다이어그램)**가 있는가?
• 마무리에 요약/체크리스트/다음 글 링크 중 하나 이상이 있는가?
• 시리즈 글인 경우 선후 관계(다음 장 링크 또는 커리큘럼)가 명시되어 있는가?
• 컬렉션 소개·커리큘럼이 필요한 시리즈인 경우, 해당 내용이 00 챕터에 있는가? (_index 본문만이 아니라 00에 두었는가?)
• 시리즈/컬렉션인 경우: 00(또는 개요)에 동기(왜 배우는가), 챕터/Phase별 필요성(왜 이 순서·이 내용인가), **학습 결과(결과적으로 무엇에 도움이 되는지)**가 명시되어 있는가?
• slug가 frontmatter에 명시되어 있고, §2.2.2 형식(소문자·하이픈·영문) 및 역할별 규칙(Section / 00 / 일반 챕터)을 따르는가?
• 문단 중심: 핵심 설명이 문단으로 서술되어 있는가? 리스트·표·코드만 제거했을 때도 문단만으로 요지가 전달되는가?
• 다단계 독자 대상 시리즈인 경우(§2.6): 모든 챕터에 일관되게 "이 장을 읽기 전에"(선행 챕터 링크, 깊이, 다루지 않는 것)와 "당신의 수준에 맞는 경로" 표가 있고, 표의 섹션명이 실제 본문 제목과 일치하는가?
• 정확성이 핵심인 주제인 경우(§2.7): 깨진 코드 → 원인 → 올바른 구현 → 안전성 검증(도구·명령 포함) 순서로 진행되며, "검증 통과 = 절대 안전"이 아님을 짚었는가?

전문가 양성

• 학습 성과 목표(평가 기준)가 있는가? — 독자가 "설명·구분·선택·리팩토링" 등을 할 수 있는지 구체적으로 나열했는가?
• 판단 기준이 있는가? — 언제 사용·언제 피할지, 적용 체크리스트 또는 사용/회피 경우가 드러나는가?
• 비판적 시각이 반영되었는가? — 한계·논란·대안·트레이드오프 중 하나 이상을 다루었는가?

내용 완결성 (§7)

• C1 커버리지: 표준 교재/문서 대비 빠진 필수 하위 개념이 없는가? 범위를 좁혔다면 "다루지 않는 것"을 밝혔는가? 주제의 메커니즘이 (일반론이 아닌) 실제로 서술됐는가?
• C4 오개념: 흔한 오해 절/문단이 있고 원 개념과 대비했는가?
• C5 연결: 선행/후행·인접 개념과의 관계를 이었는가?
• C7 심화 경로: 1차 출처(원저·표준 문서·PEP·man)·다음 학습 링크가 최소 1개 있는가?
• 정합성: 본문·다이어그램·코드의 복잡도·핵심 사실이 서로 일치하는가? (3중 대조)
• 태그=본문 일치: 내용성 태그(Etymology/Pronunciation/History 등)가 본문에 실재하는가? 무관 보일러플레이트 태그가 없는가? (§7.3)
• 표준 라이브러리 우선: 손수 구현 전에 언어/도구의 정석을 먼저 보였는가? (해당 시)
• 과목별 §7.2 필수 요소를 확인했는가?

길이·안티패딩

• 분량을 줄 수 목표로 채우지 않았는가? 짧게 느껴지는 부분은 (줄 늘리기가 아니라) §7 완결성 축의 빠진 항목으로 보강했는가? (§3)
• 닫는 절(요약·FAQ·체크리스트·네비)이 종류별 1개인가? 중복 요약·답 없는 번호 리스트(질문 24/메모 20/문장 30 류)·작성자용 자기인증("게시 전 자가 점검", "평가 기준 재확인" 등)·존재하지 않는 파일 참조가 없는가? (§2.5)

깊이·인용·정확성

• 인용은 blockquote + 출처(저자·연도 또는 링크)가 있는가?
• 역사/배경이 필요한 주제인 경우, 탄생 배경 또는 역사 절이 있는가?
• 새 용어는 첫 등장 시 굵게 정의했는가?
• 정확성: 크기(sizeof)·새니타이저 동작·디스패치 메커니즘 등 사실 주장을 검증했거나 "구현 정의"로 표기했는가? (§4.4)
• 수치 근거: "정량적"·"측정"을 표방했다면 실제 수치(플랫폼·플래그 명시) 또는 실행 가능한 벤치 스켈레톤을 1개 이상 포함했는가? (§4.4)

시각 요소

• Mermaid 사용 시 라벨 특수문자는 따옴표·</br> 규칙을 지켰는가?
• 코드 블록: 실제 코드는 언어 지정, 의사코드/텍스트는 text 지정을 권장했는가?
• 코드 컴파일 가능: 핵심 예제가 #include·타입 정의를 갖춰 컴파일 가능한가? 주석뿐·미정의 타입으로 핵심을 대체하지 않았는가? (§5.2)
• 본문-코드 균형: 코드 블록만 연속하지 않았는가? 주요 코드 블록 앞에 개념·목적 설명(2문장 이상)이 있는가?