| 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 챕터, 체크리스트가 필요한) 글을 작성·보강할 때.
함께 적용
0. 핵심 원칙 (항상 우선 적용)
본문을 작성·수정하기 전, 아래 3원칙을 먼저 점검한다 (상세는 §2.5/§4.4/§5.2).
- 안티패딩: 분량은 목표가 아니라 결과다. 닫는 절(요약·FAQ·체크리스트·네비)은 종류별 1개만 두고, 중복 요약·답 없는 번호 리스트(질문 24/메모 20류)·작성자용 자기인증("게시 전 자가 점검" 등)·존재하지 않는 파일 참조를 본문에 넣지 않는다.
- 컴파일 가능한 코드: 핵심 예제는
#include·타입 정의를 갖춰 컴파일 가능해야 한다. 주석뿐인 블록·미정의 타입으로 핵심을 대체하지 않는다.
- 수치·사실 근거: "정량적"·"측정"을 표방하면 실제 수치(플랫폼·플래그 명시) 또는 실행 가능한 벤치를 포함하고, 크기·새니타이저·디스패치 같은 사실 주장은 검증하거나 "구현 정의"로 표기한다.
1. 목적
- AI 보조로 작성하는 교육 자료의 본문 구성·길이·깊이·시각 요소를 표준화한다.
- 역사·배경·인용이 있는 주제는 출처와 맥락을 명확히 한다.
- 전문가 양성에 맞게, 학습 성과 목표·판단 기준·실무 적용·비판적 시각을 요구한다.
- 게시 전 품질 체크리스트로 누락·환각을 줄인다.
2. 본문 구성
2.0 본문 서술 원칙 (문단 중심)
- 문단이 설명의 중심: 본문에서 개념·원칙·판단 기준·학습 결과는 **문단(연속된 문장)**으로 서술하여, 리스트·표·코드 블록 없이도 독자가 핵심을 이해할 수 있도록 구성한다.
- 리스트·표·코드는 부가: 목록(불릿/번호 리스트), 표, 코드 블록, Mermaid 다이어그램은 문단으로 서술한 내용을 요약·구체화·시각화하는 보조 수단으로 둔다. 즉, "문단으로 말한 뒤 리스트/표/코드로 정리·예시" 순서를 지향한다.
- 평가 기준·학습 목표: "이 글을 읽은 후 달성해야 할 목표"처럼 리스트로만 제시하는 경우, 그 앞에 같은 내용을 문단으로 요약하여, 리스트를 읽지 않아도 문단만으로 무엇을 할 수 있게 되는지 전달되게 한다.
2.1 필수 섹션 순서
다음 순서를 지키되, 주제 성격에 따라 일부 절은 생략 가능하다.
- 도입: 동기/배경 — "왜 이 주제인가", 인용문·훅 또는 정의 한 줄 + 동기. 시리즈 전체의 도입인 00 챕터에는 컬렉션 전체 동기와 챕터별 필요성·학습 결과까지 포함하는 것이 좋다.
- 정의·원칙: 핵심 용어 정의(첫 등장 시 굵게), 원칙·구조(목록 또는 표).
- 예시 또는 코드: 실제 동작을 보여주는 코드 블록 또는 다이어그램.
- 비교·트레이드오프 또는 요약: 전통 vs 개선, 장단점, 한눈에 보기 표 등.
- 마무리: 다음 중 하나 이상 — "핵심 요약" 테이블, "평가 기준/체크리스트", "핵심 메시지", "다음 장에서는" 링크.
- 전문가 양성 요소(아래 §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)
정확성이 핵심인 주제(동시성, 메모리 안전성, 동기화, 자료구조 불변식 등)는 코드를 다음 순서로 배치한다.
- 깨진 코드: 흔히 작성하는 자연스럽지만 잘못된 버전을 먼저 보여준다.
- 원인 설명: 왜 깨졌는지를 표준/사양 또는 메모리 모델 같은 근거 있는 언어로 설명한다("우연히 동작함"과 "보장됨"을 구분).
- 올바른 구현: 표준 라이브러리 기능 또는 정립된 패턴으로 고친 버전을 제시한다.
- 안전성 검증: 두 버전을 실제로 검증할 수 있는 도구·명령을 제시한다. 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·표
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. 품질 체크리스트 (게시 전 확인)
글을 게시하기 전에 아래를 확인한다. (순서는 본문 구성 → 전문가 양성 → 내용 완결성 → 길이 → 깊이 → 시각 요소 순이다.)
본문 구성
전문가 양성
내용 완결성 (§7)
길이·안티패딩
깊이·인용·정확성
시각 요소
