---
title: AI_Tech_Review Writing Style Audit Harness
date: 2026-05-09
status: active
scope:
  - reports/*_final_review.md
  - reports/*_memo.md
  - reports/*_deepresearch.md
tags:
  - writing
  - style-audit
  - korean-review
  - harness
---

# AI_Tech_Review Writing Style Audit Harness

## 목적

`AI_Tech_Review`의 리뷰 글은 자료를 정리하는 데서 끝나면 안 됩니다. 독자가 처음 몇 문단에서 주제를 잡고, 중간에서는 근거를 따라가며, 마지막에는 자신의 업무와 연결해 생각할 수 있어야 합니다.

이 하네스는 작성물에 흔히 섞이는 AI식 문장 전개를 줄이기 위한 검증 루프입니다. 특히 다음 패턴을 잡습니다.

- `그래서 이번 리뷰는 ...가 아닙니다`처럼 부정으로 시작하는 메타 전환
- `최근 ...는 ...로만 읽기 어렵습니다`처럼 부정형 판단으로 주제를 여는 도입
- `A가 아니라 B입니다`를 반복해 허수아비 대비를 만드는 contrast framing
- `...가 맞습니다`, `...로 보는 것이 맞습니다`처럼 글쓴이가 판정하듯 말해 근거 설명을 건너뛰는 verdict ending
- `핵심은`, `주목할 점은`, `결론적으로`, `요컨대` 같은 자동 요약체
- `먼저 붙잡을 문장은 이것입니다`처럼 글쓴이가 독자의 읽기 방식을 지시하는 문장
- `이 리뷰에서는 ...라고 부르겠습니다`처럼 이미 통용되는 기술어를 리뷰 내부 정의처럼 만드는 문장
- `이 변화는 한 회사의 제품 발표만으로 보기는 어렵습니다`처럼 근거 범위를 방어하느라 섹션의 주제를 늦게 꺼내는 문장
- `따로따로 보면 복잡합니다. 하지만 하나로 묶으면 단순합니다`처럼 대비 템플릿으로 전환하는 문장
- `에이전트가 기억을 정리한다`, `에이전트가 결과를 평가한다`처럼 하네스가 해야 할 일을 에이전트의 행위로 잘못 쓰는 문장
- `이 문제를 직접 다룹니다`, `이런 기능은`처럼 앞 문장의 주제의식이 충분히 드러나지 않았는데 지시어로 넘기는 문장
- 글의 목적을 설명하느라 정작 주제를 늦게 보여주는 도입부
- 기술어를 많이 쓰지만 쉬운 예시와 설명이 부족한 문단
- 출처는 많지만 독자가 왜 읽어야 하는지 감각적으로 잡히지 않는 문단
- 에이전트가 작업 중 판단한 low-confidence 항목을 독자-facing 리포트에 별도 보고처럼 노출하는 문단
- 출처명, 회사명, 논문명, 사람 이름의 강조 방식이 문단마다 달라지는 문제
- 표만 있고 시각 자료가 없어 긴 기술 흐름을 독자가 한눈에 잡기 어려운 문제
- `소스`, `근거 축`, `근거 지도`처럼 작업자 내부 용어가 독자-facing 문단이나 표 제목에 들어가는 문제
- `흩어진 업데이트가 같은 방향을 가리킵니다`, `표면으로 이동합니다`, `연구 대상으로 올려놓았습니다`처럼 영어식 표현이 한국어로 직역된 문제
- `붙-`, `밀어붙-`, `이어-`, `넓어-`, `옮겨-`, `차례`, `가깝다`, `출발점`, `장치`처럼 문장을 부드럽게 만드는 접착 표현군이 반복되어 실제 행위자와 메커니즘을 흐리는 문제
- `실무적으로`, `현실적으로`, `실제로는`처럼 적용 문단으로 넘어가는 표시가 반복되어 실제 업무 장면을 대신하는 문제
- 영어식 AI문체가 한국어로 번역되면서 생기는 번역체 문제. 예: 추상 주어, 과도한 명사구, `표면으로 이동`, `질문이 넓어짐`, `나란히 놓으면` 같은 직역형 전개
- `좋은 X는 ...`, `질문은 하나입니다`, `지금까지 살펴본 자료를 어떻게 읽을 수 있을까요?`처럼 글을 자동 요약문처럼 닫는 문제
- `주제 선언 -> 용어 정의 -> 참고자료 표 -> 사례별 요약 -> 체크리스트 결론` 구조가 독자의 질문보다 작성자의 분류 체계를 먼저 보여주는 문제

## 김현중식 글쓰기 참고풀

김현중식 글쓰기 참고풀은 Obsidian의 별도 항목에서 관리합니다.

- 기본 경로: `C:\Users\angpa\Obsidian_Vault\hkim_Writings`
- KIAS/Quanta/CHEY 체크가이드: `C:\Users\angpa\Obsidian_Vault\hkim_Writings\2026-05-10_KIAS_Quanta_CHEY_참고스타일_체크가이드.md`
- 이 폴더에는 사용자가 직접 지적한 AI식 표현, 선호하는 전개 방식, 좋은 예시와 나쁜 예시, Horizon/Quanta/Science Note 적용 메모를 누적합니다.
- 이 참고풀은 `00. Inbox`가 아니라 전용 폴더에 둡니다. Inbox는 임시 캡처 위치이고, 김현중식 글쓰기 기준은 반복 사용되는 스타일 자산입니다.
- 새 코멘트를 반영할 때는 `원문 표현`, `왜 AI스럽게 보였는지`, `수정 방향`, `좋은 예시`를 함께 남깁니다.

## 현재 구축 상태

### 이미 구축된 것

- `AGENTS.md`에는 한국어 리뷰 문체 규칙이 있습니다.
- `AGENTS.md`는 `beautiful-prose` 스킬을 한국어 기술 리뷰에도 감사 기준으로 쓰도록 규정합니다.
- `AGENTS.md`는 final review 작성 시 topic-specific title, subtitle, source provenance, English-term audit, quick prose audit를 요구합니다.
- `scripts/markdown_to_html.py`는 final-review HTML mode를 지원합니다.
- `.automation/automation-controller-standard.md`는 반복 자동화와 Ralph audit를 workspace-local automation layer에 두는 구조를 정의합니다.

### 부족했던 것

- 작성 전, 작성 후, 재작성 단계에 붙는 명시적 문체 감사 루프가 분리되어 있지 않았습니다.
- AI식 문장 패턴을 어떤 순서로 잡고 어떻게 고칠지에 대한 운영 체크리스트가 없었습니다.
- 도입부에 대한 별도 기준, 즉 `주제의식 전진배치 -> 독자 경험 또는 질문 -> 쉬운 예시 -> 기술적 본론으로 진입` 구조가 명문화되어 있지 않았습니다.
- `결론 먼저`와 `주제의식 먼저`를 구분하지 않아, 초안이 AI식 단정문처럼 시작되는 문제가 있었습니다.

## 적용 대상

이 하네스는 다음 산출물에 기본 적용합니다.

- `reports/*_final_review.md`
- 독자에게 공유할 `reports/*_memo.md`
- 긴 리서치 보고서의 `Summary`, `Intro`, `Conclusion`
- Skywork prompt의 speaker-facing opening
- Obsidian mirror용 요약 문단

## 작성 전 루프

작성 전에는 아래 네 가지를 먼저 정합니다.

| 항목 | 질문 | 실패 신호 |
|---|---|---|
| 주제의식 | 이 글이 닿아 있는 질문은 무엇인가 | 반박 대상이나 메타 설명이 먼저 나온다 |
| 독자 장면 | 독자가 이미 겪었을 법한 상황은 무엇인가 | 추상어로만 시작한다 |
| 쉬운 예시 | 기술어를 어떤 생활/업무 예시로 열 수 있는가 | 기술어가 정의 없이 연속 등장한다 |
| 용어 계보 | 핵심 기술어가 어디에서 온 말이고 현재 어떤 의미로 쓰이는가 | 리뷰 안에서 임의로 만든 정의처럼 설명한다 |
| 확인한 흐름 | 어떤 논문, 회사 발표, 제품 문서, 저장소가 이 흐름을 보여주는가 | 참고자료 목록이 본문 뒤에 따로 붙기만 한다 |
| 시각 자료 | 글의 메시지를 어떤 그림, 도식, figure로 잡아줄 수 있는가 | 표만 있고 흐름이나 구조를 보여주는 그림이 없다 |

## 도입부 기준

도입부는 아래 순서를 권장합니다.

1. **전진배치된 주제의식**
   - 첫 1-2문단 안에 이 글이 어떤 질문을 다루는지 말합니다.
   - 예: `최근 GPT-5.5 업데이트를 통해 어떤 일을 얼마나 더 오래 맡길 수 있게 되었는가 하는 Agentic 작업 능력이 중요한 성능평가 요소로 보아야 함을 느낄 수 있습니다.`
   - `...가 아닙니다`, `...로만 읽기 어렵습니다`처럼 부정형 판단으로 열지 않습니다.

2. **친근한 질문**
   - 독자가 자기 경험으로 들어올 수 있는 질문을 한 번 던집니다.
   - 예: `모델에게 코드 수정이나 문서 조사를 맡겼을 때, 답변 하나보다 여러 단계를 얼마나 안정적으로 이어 가는지가 더 중요하다고 느껴본 적 있으신가요?`

3. **쉬운 예시**
   - 모델과 하네스의 차이를 업무 장면으로 설명합니다.
   - 예: `똑똑한 동료가 있어도, 접근 권한과 체크리스트와 승인 절차가 없으면 일을 끝내기 어렵습니다.`

4. **기술적 본론으로 연결**
   - 논문과 회사 사례로 들어갑니다.
   - 예: `이 흐름은 Natural-Language Agent Harnesses, Meta-Harness, Anthropic Managed Agents, DeepSeek-TUI 같은 사례에서 동시에 보입니다.`

5. **호기심을 남기는 문장**
   - 질문을 열되 결론을 숨기지 않습니다.
   - 예: `그런데 여기서 한 가지 반전이 있습니다. 더 많은 에이전트를 붙이는 설계가 항상 좋은 답은 아닐 수 있습니다.`

## 금지 또는 주의 패턴

| 피해야 할 패턴 | 이유 | 대체 방향 |
|---|---|---|
| `그래서 이번 리뷰는 A가 아닙니다` | 글의 주제보다 글쓰기 방식이 앞으로 나옴 | 주제 질문이나 독자 경험에서 바로 시작 |
| `최근 ...는 ...로만 읽기 어렵습니다` | 부정형 반전으로 독자의 관심을 끌려는 AI식 도입 | `최근 ...을 통해 ...를 함께 보아야 함을 느낄 수 있습니다` |
| `A가 아니라 B입니다` 반복 | 실제로 누가 A를 주장했는지 불분명하면 허수아비를 세워 B를 밀어붙이는 문장처럼 보임 | `관찰된 변화 -> 근거 -> B의 의미` 순서로 쓴다 |
| `...가 맞습니다`, `...로 보는 것이 맞습니다` | 글쓴이가 정답을 판정하는 어조가 되어 왜 그렇게 판단하는지 설명이 약해짐 | `어떤 자료/장면 때문에 그렇게 해석되는지`를 먼저 쓰고 판단은 자연스럽게 따라오게 한다 |
| `살펴보려 합니다`만 반복 | 독자의 관심을 늦게 붙잡음 | `왜 그런지 이번 리뷰에서 다뤄보겠습니다`처럼 구체 질문과 연결 |
| `핵심은`, `주목할 점은` 남발 | 요약문 템플릿처럼 보임 | 구체 주어와 동사로 시작 |
| `먼저 붙잡을 문장은 이것입니다` | 독자에게 결론을 지시하는 생성형 진행 멘트처럼 들림 | 메시지를 문장 자체로 바로 쓴다 |
| `이 리뷰에서는 ...라고 부르겠습니다` | 통용되는 기술어를 임의 정의처럼 보이게 함 | `...를 보통 ...라고 부릅니다`처럼 현재 사용 맥락과 참고자료를 붙인다 |
| `이 변화는 한 회사의 발표만으로 보기 어렵습니다` | 글쓴이의 근거 방어가 섹션 주제보다 앞섬 | `논문, 공식 발표, 저장소를 같이 읽으면 ...가 자주 다뤄집니다`처럼 바로 주제를 말한다 |
| `따로따로 보이면 복잡합니다. 하지만 하나의 질문으로 묶으면 단순해집니다` | AI식 대비 전환으로 들리고 문장 리듬이 기계적임 | `이 용어들을 하나씩 따라가 보면 결국 같은 질문으로 모입니다`처럼 자연스러운 연결문으로 쓴다 |
| `오래 실행되는 에이전트는 기억을 정리하고 결과를 평가해야 합니다` | 행위 주체가 어긋남. 기억 선별과 평가 루프는 하네스가 제공해야 함 | `장기 작업에는 기억을 고르고 평가하는 하네스가 필요합니다` |
| `이 문제를 직접 다룹니다` | 무엇이 문제인지 문장 안에 드러나지 않아 독자가 다시 앞 문장을 추적해야 함 | `Dreaming과 Outcomes는 기억 선별과 결과 평가를 제품 기능으로 보여줍니다` |
| 기술어 나열 | 독자가 첫 문단에서 이탈함 | 쉬운 예시 뒤에 기술어를 붙임 |
| 출처 없는 큰 결론 | 신뢰도 약화 | 회사명, 논문명, 발표일, 문서 링크를 문장 안에 배치 |
| `보류할 신호`, `확인하지 못한 항목`을 독립 섹션으로 나열 | 작성 과정의 시각이 리포트 내용에 섞임 | 확실한 근거가 있는 신호만 본문에 올리고, 불확실한 항목은 생략하거나 runlog/source note에만 기록 |
| 회사명은 bold, 논문명은 code, 제품명은 평문처럼 섞어 쓰기 | 독자가 출처와 해석을 구분하기 어려움 | 아래 `출처와 강조 규칙`을 일관되게 적용 |
| `근거 지도`, `근거 축`, `대표 소스`, `소스 성격` | 작업자 내부 용어처럼 읽힘 | `참고자료 맵`, `검증 자료표`, `확인한 흐름`, `주요 참고자료`, `자료 성격` |
| `흩어진 업데이트가 같은 방향을 가리킵니다` | 현상은 말하지만 주제가 보이지 않음 | `에이전트 경쟁은 하네스 구축 경쟁으로 넓어지고 있습니다`처럼 주제를 직접 말함 |
| `표면으로 이동합니다` | 영어식 표현의 직역처럼 들림 | `권한 부여, 승인, 감사 기록이 제품의 기본 구성요소가 되고 있습니다` |
| `연구 대상으로 올려놓았습니다` | 정보량이 낮고 어색함 | `하네스 엔지니어링 연구가 본격화되고 있습니다` |

## 작성 후 감사 루프

초안 작성 후 아래 순서로 점검합니다.

1. 메타 문장 제거
   - `이 리뷰는`, `이 글에서는`, `살펴보겠습니다`가 너무 앞에 많으면 줄입니다.
   - 단, 친근한 진행 문장으로 기능할 때는 남길 수 있습니다.

2. 부정형 전환과 허수아비 대비 점검
   - `A가 아니라 B` 문장이 rhetorical pivot인지 확인합니다.
   - `...로만 읽기 어렵습니다`, `...가 아닙니다`가 첫 문장이나 첫 문단에 있으면 우선 고칩니다.
   - 실제로 A와 B를 구분해야 하는 자료나 논문 근거가 있을 때만 남깁니다.
   - 강조를 위해 만든 대비라면, 부정문을 지우고 `주장 -> 관찰 근거 -> 개념 정리` 순서로 다시 씁니다.
   - 좋은 문장은 반박 대상을 새로 만들지 않습니다. 독자가 확인할 수 있는 변화와 근거에서 결론으로 이동합니다.

2-1. 접착 표현군과 추상 전환 점검
   - `붙-`, `밀어붙-`, `이어-`, `넓어-`, `옮겨-`, `차례`, `가깝다`, `출발점`, `장치` 같은 표현군이 반복되는지 봅니다.
   - `실무적으로`, `현실적으로`, `실제로는`이 실제 장면을 열지 않고 단락 전환 신호로만 쓰였는지 봅니다.
   - 이 표현들이 실제 관계를 설명하지 않고 문장을 매끈하게 이어주는 역할만 한다면 다시 씁니다.
   - 단어 자체를 금지하지 않습니다. 실제 동작, 자연스러운 한국어 관용, 기술적으로 정확한 연결이면 남깁니다.
   - 수정할 때는 더 멋진 표현을 찾기보다 주어와 동사를 정확히 세웁니다. 누가 어떤 권한을 부여하는지, 어떤 기록을 남기는지, 어떤 검증을 요구하는지 직접 씁니다.

2-1-1. 판정형 어미 점검
   - `...가 맞습니다`, `...로 보는 것이 맞습니다`, `...라고 보는 편이 맞습니다`가 리뷰 본문에 남아 있는지 봅니다.
   - 사실 오류를 바로잡는 문맥이 아니라면, 판정문을 설명문으로 바꿉니다.
   - 수정할 때는 `왜 그렇게 보이는가`를 먼저 씁니다. 관찰된 장면, 참고자료, 기술적 관계를 한 문장 안에 세우면 판정형 어미가 필요 없어집니다.

## Vibe Writing / 바이브퇴고 루프

사용자가 `vibe writing`, `바이브글쓰기`, `vibe 글쓰기`, `vibe 퇴고`, `바이브퇴고`, `vibe쓰기`, `김현중식으로 다듬자`라고 말하면 바로 전체 재작성으로 들어가지 않습니다. 먼저 함께 퇴고할 후보를 드러냅니다.

1. 원문에서 AI식 표현, 구조, 소제목, 문단 리듬을 찾습니다.
2. 후보를 5-10개 안팎으로 리스트합니다.
3. 각 후보마다 `왜 AI스럽게 읽히는지`, `어떤 독자 경험을 방해하는지`, `김현중식/KIAS Horizon식으로 어느 방향이 좋은지`를 짧게 씁니다.
4. 한 문장 또는 한 문단씩 대체안을 제안합니다.
5. 사용자가 `하나씩`, `단계별로`, `좋아 진행`처럼 응답하면 첫 후보부터 같이 고칩니다.
6. 사용자가 `전체 다시 써줘`라고 하면 후보 리스트를 기준으로 전체 본문을 재작성하고 다시 감사합니다.

2-2. 구조적 AI 문체 점검
   - 글이 `참고자료를 분류한 보고서`처럼 보이는지, 아니면 `독자가 기술 개념을 이해하도록 이끄는 리뷰`처럼 보이는지 확인합니다.
   - 초반에 표가 먼저 나오면, 독자가 표를 읽을 이유가 충분히 만들어졌는지 봅니다.
   - 모든 섹션이 같은 방식으로 출처를 소개하고 같은 방식으로 끝나면, 일부 섹션은 업무 장면, 실제 제품 흐름, 논문 결과의 조건에서 시작하도록 바꿉니다.

2-3. 한국어 번역체 점검
   - 영어식 AI문체가 한국어 문장으로 직역되어 남아 있는지 봅니다.
   - `질문이 넓어집니다`, `흐름이 이동합니다`, `표면으로 이동합니다`, `자료를 나란히 놓으면`처럼 추상 주어가 추상 동사를 하는 문장을 우선 봅니다.
   - 명사구가 과도하게 쌓인 문장은 동사 중심의 한국어 문장으로 다시 씁니다.
   - 해외 AI문체 연구는 참고하되, 한국어 리뷰에서는 KIAS Horizon, CHEY Science Note, 사용자의 실제 교정 코멘트를 함께 봅니다.

## Watchlist 운영 원칙

AI식 표현 풀은 금지어 사전이 아닙니다. 새 표현이 발견될 때마다 개별 규칙을 과도하게 늘리지 않습니다. 먼저 다음 네 가지 중 어디에 속하는지 분류합니다.

1. 구조 습관: 섹션 전개가 반복되는 문제
2. 접착 표현군: 문장을 매끈하게 잇지만 관계를 흐리는 단어군
3. 번역체: 영어식 논리와 명사구가 한국어에 남은 문제
4. 근거-주장 거리: 근거보다 판정, 반전, 슬로건이 앞서는 문제

이 분류 뒤에 수정 여부를 결정합니다. 표현이 자연스럽고 구체적인 역할을 하면 남깁니다. 표현이 기술 관계를 흐리거나 문체 습관으로 반복되면 고칩니다.

3. 독자 장면 추가
   - 첫 5문단 안에 독자가 떠올릴 수 있는 업무 예시가 있는지 봅니다.
   - 없으면 짧은 질문이나 예시를 넣습니다.

4. 기술어 설명
   - `하네스`, `connector`, `memory`, `orchestration`, `MCP`, `agent`가 처음 등장할 때 쉬운 설명이 있는지 확인합니다.
   - 설명이 길어지면 문장 안에서 풀고, 필요할 때만 footnote를 씁니다.
   - 이미 업계에서 쓰이는 용어는 `이 리뷰에서는 ...라고 부르겠습니다`로 정의하지 않습니다.
   - 용어가 중요하면 `원래 어디에서 쓰인 말인지 -> 지금 이 글에서는 어떤 의미로 쓰는지`를 2-3문장으로 설명합니다.

5. 주어-술어 정합성 점검
   - 문장의 주어가 실제 행위 주체인지 확인합니다.
   - 에이전트가 직접 하는 일, 하네스가 제공하는 구조, 사람이 승인하는 일, 조직이 정하는 정책을 섞지 않습니다.
   - 특히 `기억 정리`, `결과 평가`, `권한 제한`, `승인`, `감사 기록`, `되돌리기`는 모델 능력보다 하네스/운영 구조의 역할로 쓰는 편이 정확합니다.
   - 지시어(`이 문제`, `이 기능`, `이 흐름`)가 앞 문장에 기대고 있다면, 그 문장 안에서 주제어를 다시 말합니다.

6. 근거 위치 점검
   - 중요한 해석은 첫 등장 문단에 출처명이나 논문명을 붙입니다.
   - 링크는 References에만 몰아넣지 않습니다.
   - reader-facing 문맥에서는 `소스`보다 `참고자료`, `참고문헌`, `Reference`, `공식 문서`, `논문`, `저장소`를 씁니다.

7. 리듬 점검
   - 같은 길이의 문장이 5개 이상 이어지면 끊습니다.
   - 질문, 짧은 문장, 근거 문장을 섞습니다.

8. 불확실 신호 처리
   - 공식 출처나 1차 근거로 확인되지 않은 항목은 독자-facing final review 본문에 별도 섹션으로 올리지 않습니다.
   - 그 항목이 주 결론에 필요하면 더 강한 출처를 찾아 확인합니다.
   - 확인이 안 되면 runlog 또는 source note에만 남기고 final review에서는 생략합니다.
   - `주의할 주장`, `보류할 신호`, `확인하지 못한 항목` 같은 섹션은 리포트가 검증 실패 목록처럼 읽히게 만들 수 있으므로 기본 사용하지 않습니다.

9. 마무리 문단 점검
   - `정리하면`, `결론적으로` 같은 자동 요약 제목을 피합니다.
   - 독자에게 지금까지 어떤 소식을 어떻게 읽을 수 있는지 설명합니다.
   - `지금까지 ...를 살펴보았습니다`, `어떻게 읽으셨나요?`, `...가 선명해지는 것 같습니다`, `...해보시면 어떨까요`처럼 자연스러운 회고와 해석을 허용합니다.
   - 단, 친근한 말투가 근거의 확실성을 흐리면 안 됩니다. 해석과 사실을 문장 안에서 구분합니다.

10. 제목과 표 레이블 점검
   - H2/H3 제목은 현상 설명보다 주제를 말해야 합니다.
   - `근거 지도`, `근거 축`, `소스` 같은 내부 표현이 제목, 표 머리글, caption에 남아 있으면 독자용 표현으로 바꿉니다.
   - 제목이 `무엇이 어떻게 변했는가`를 말하지 못하면 다시 씁니다.
   - 제목은 `내가 자료를 어떻게 봤는가`보다 `독자가 무엇을 가져가야 하는가`를 말합니다.
   - `참고자료로 본 쟁점`처럼 작업자의 분류가 앞서는 제목보다 `AI 경쟁은 모델 바깥의 작업 환경으로 넓어지고 있습니다`처럼 메시지를 직접 말하는 제목을 우선합니다.

## 출처와 강조 규칙

출처와 강조는 일관되게 씁니다. 문단마다 임의로 굵게, 기울임, 음영을 바꾸지 않습니다.

### 강조 계층

리뷰 본문은 아래 순서로 시각적 강조를 배정합니다.

| 계층 | 사용 대상 | 사용 기준 |
|---|---|---|
| 링크 | 첫 등장하는 공식 출처, 논문, 제품 문서, 저장소 | 출처 자체가 시각적 강조 역할을 하므로 별도 bold를 붙이지 않음 |
| **Bold** | 독자가 기억해야 할 주장, 전환점, 결론 문장 | 한 섹션에 1-2개 이내. 출처명이나 회사명보다 메시지에 사용 |
| *Italic* | dek, 짧은 인용 뉘앙스, 저자 역할, 날짜, caption 보조 문장 | 본문 강조용으로 남발하지 않음 |
| 밑줄 | 실제 하이퍼링크 또는 도식 속 annotation | 일반 강조에는 사용하지 않음. 웹 문서에서 밑줄은 링크로 읽힘 |
| Roman/upright | 일반 본문, 회사명 반복 등장, 제품명 반복 등장 | 기본값. 읽는 흐름을 가장 덜 방해함 |
| `code` | 파일명, 명령어, API, 설정값, repo path, 정확한 literal | 일반 기술어, 회사명, 논문명에는 쓰지 않음 |

Bold 적용 전에는 항상 아래 질문을 합니다.

1. 이 문장이 독자가 기억해야 할 판단인가?
2. 출처명이나 명사만 굵게 하는 것은 아닌가?
3. 같은 섹션에서 이미 굵은 문장이 2개 이상 나오지 않았는가?
4. 굵게 하지 않아도 문장 자체가 충분히 분명하지 않은가?

| 대상 | 표기 방식 | 예 |
|---|---|---|
| 첫 등장하는 공식 출처, 논문, 제품 문서 | 링크를 붙인 source label | `[Anthropic의 금융 서비스 발표](...)`, `[Natural-Language Agent Harnesses](...)` |
| 논문명, 제품명, 저장소명 | 공식명 그대로 유지. 링크가 있으면 링크가 강조 역할을 대신함 | `[Meta-Harness](...)`, `[DeepSeek-TUI](...)` |
| 일반 단어와 혼동될 수 있는 제품 기능명, 평가명, 벤치마크명 | 첫 등장에 한해 `**bold**` 허용 | `**Dreaming**`, `**Outcomes**` |
| 핵심 메시지 또는 판단 문장 | `**bold**`를 제한적으로 사용 | `**하네스가 실제 성과를 가르는 층으로 올라오고 있습니다.**` |
| 중요한 읽기 포인트 | `::: highlight` callout 사용 | 보고서 전체에서 1-3개만 사용 |
| 근거 강도나 제한 사항 | `::: evidence` callout 사용 | source strength를 설명할 때만 사용 |
| 업무 적용 질문 | `::: think` callout 사용 | 독자가 자기 상황에 대입할 때만 사용 |
| 일반 회사명, 사람 이름 반복 등장 | 평문 사용 | Anthropic, xAI, DeepMind |
| 강조를 위한 이탤릭 | 기본적으로 쓰지 않음 | 외국어 제목이나 인용 뉘앙스가 필요할 때만 제한 사용 |

규칙:

- 회사명과 사람 이름은 굵게 처리하지 않습니다. 링크가 있으면 링크가 충분한 시각적 구분을 제공합니다.
- 굵게 처리할 대상은 출처명보다 메시지입니다. 다만 일반 단어처럼 보일 수 있는 기능명, 평가명, 벤치마크명은 첫 등장에 한해 bold를 허용합니다.
- 음영 callout은 구조적 역할이 있을 때만 사용합니다. 모든 중요한 문장을 callout으로 만들지 않습니다.
- References에는 모든 주요 검증 경로를 모으되, 본문 첫 언급에서도 출처가 보이게 합니다.
- 밑줄은 일반 강조 수단으로 쓰지 않습니다. 독자는 밑줄을 링크로 해석합니다.
- italic은 `차분한 보조 음성`으로 둡니다. 강한 메시지는 더 정확한 문장이나 bold로 처리합니다.

## 작성 정보 규칙

`작성 정보`는 독자-facing 보고서의 신뢰성을 높이는 짧은 provenance block입니다. 단순 작업 로그가 되면 안 됩니다.

포함할 항목:

- 작성자: 사람 또는 팀 이름. 예: `김현중, AI Governance 팀`
- 작성 보조: 사용한 AI 작성 하네스와 모델 계열을 보수적으로 표기. 예: `Codex 기반 GPT-5 계열 에이전트 하네스`
- 생성/수정일
- 주제 인입: seed가 된 영상, digest, Pulse, paper, source pack을 간단히 설명
- 주요 검증 소스: 공식 발표, 논문, 저장소 문서, 제품 문서 등 신뢰도 높은 source category
- 작성 방식: discovery map, source verification, style audit harness 적용 여부

주의:

- YouTube나 digest를 출발점으로 썼더라도, 리포트가 그 자료의 요약처럼 보이면 안 됩니다.
- `원천 자료: 유튜브 영상`처럼만 쓰지 말고, `주제 인입`과 `주요 검증 소스`를 분리합니다.
- 작성 과정의 불확실 항목을 작성 정보에 길게 나열하지 않습니다. 그런 정보는 runlog에 둡니다.

## 기술용어 설명 규칙

기술용어는 제거하지 않습니다. 대신 독자가 첫 등장 시 이해할 수 있도록 붙잡아 줍니다.

필수 점검 용어:

- `하네스`: 모델을 실제 업무에 투입하기 위한 권한, 도구, 기억, 검증, 승인 구조
- `connector`: 외부 업무 도구와 AI를 연결하는 통로
- `memory`: 이전 작업과 선호, 실패 기록을 재사용하기 위한 기억 구조
- `orchestration`: 여러 agent나 작업 단계를 역할별로 나누고 조정하는 방식
- `MCP`: 모델과 외부 도구·데이터 소스를 연결하는 표준 접점
- `semantic merge`: 줄 단위 병합을 넘어 코드 구조나 의미 단위로 병합하는 접근

권장 방식:

- 긴 footnote보다 짧은 `용어 정리` 표를 먼저 고려합니다.
- 본문 첫 등장 문장 안에서 자연스럽게 설명할 수 있으면 표보다 본문 설명을 우선합니다.
- 독자가 이미 알 가능성이 높은 모델명, 제품명, 논문명은 억지로 번역하지 않습니다.
- 핵심 용어가 리뷰 주제라면 용어의 계보를 짧게 넣습니다. 예: `test harness -> LLM evaluation harness -> agent harness`.
- 계보 설명은 출처를 붙이되 어원 강의가 되지 않게 2-3문장으로 제한합니다.

## Feynman식 한국어 설명 규칙

쉬운 글은 가벼운 글이 아닙니다. 개념을 정확히 쪼갠 다음, 독자가 이미 아는 장면에서 시작하고, 전문 용어를 필요한 순간에 붙입니다.

권장 순서:

1. 독자가 겪을 법한 장면을 먼저 둡니다.
2. 그 장면에서 막히는 질문을 하나 꺼냅니다.
3. 그 질문을 해결하는 핵심 개념을 짧게 말합니다.
4. 전문 용어와 참고자료는 그 다음에 붙입니다.
5. 마지막 문장은 다음 섹션의 질문으로 자연스럽게 이어지게 합니다.

한국어 참고 스타일:

- 스타일 레퍼런스풀은 [editorial-reference-pool](./editorial-reference-pool.md)에 둡니다.
- HORIZON 문체 패턴은 [horizon-style-patterns](./horizon-style-patterns.md)에 누적합니다.
- [Quanta Magazine](https://www.quantamagazine.org/), [고등과학원 HORIZON](https://horizon.kias.re.kr/), [최종현학술원 Science Note 과학노트](https://www.chey.org/Kor/ScienceNote/ScienceNoteList.aspx)를 기본 참고 사이트로 봅니다.
- 단, 각 매체의 문체를 그대로 따라 하지 않습니다. AI_Tech_Review에서는 내부 기술 검토 독자를 고려해 메시지와 참고자료를 더 빨리 보여줍니다.
- 배울 점은 `쉬운 장면 -> 정확한 개념 -> 전문 근거 -> 다시 쉬운 질문`의 리듬입니다.
- AI식 표현을 고친 대체안도 다시 검사합니다. `무대가 넓어집니다`, `브레이크를 겁니다`, `선명해집니다` 같은 말은 문맥에 맞으면 쓸 수 있지만, 반복되면 다시 AI식 추상문이 됩니다.

## 시각 자료와 artwork 규칙

최종 리뷰에는 표만 둘지, 도식이나 artwork를 넣을지 매번 검토합니다.

### Quanta-style article pattern

Quanta Magazine류의 과학 기사에서 빌려올 수 있는 패턴은 아래와 같습니다.

1. 큰 제목과 짧은 dek에서 메시지를 먼저 보여줍니다.
2. 첫 화면 가까이에 hero illustration을 둬서 추상 주제를 하나의 장면으로 잡아줍니다.
3. 본문 폭은 좁게 유지하고, figure는 본문보다 넓거나 독립적인 블록으로 숨을 줍니다.
4. 그림에는 반드시 caption과 credit/source note를 붙입니다.
5. 중간에는 표만 반복하지 말고, 개념 전환 지점에 작은 도식이나 pull quote를 둡니다.
6. 그림은 장식보다 `이 글을 어떻게 읽을지`를 알려주는 장치에 가까워야 합니다.

이 패턴을 그대로 복제하지 않습니다. 한국어 기술 리뷰에서는 제목과 도입부를 지나치게 문학적으로 만들지 않고, 메시지와 근거를 더 빨리 보여줍니다.

### 언제 이미지를 넣을까

- 글의 중심 메시지가 구조적 관계일 때: `Model -> Harness -> Work Outcome`
- 여러 회사/논문/도구가 하나의 흐름으로 묶일 때
- 도입부에서 독자의 주의를 잡아줄 상징적 장면이 있을 때
- 발표자료나 HTML 공유본으로 읽힐 가능성이 높을 때

### 어떤 방식이 좋은가

| 목적 | 권장 방식 | 비고 |
|---|---|---|
| 잡지형 one-cut infographic | Skywork Image 또는 GPT Image 2/imagegen 후보 | 독자가 한 컷으로 개념을 잡아야 할 때 우선 검토 |
| 정확한 흐름, 구성요소, 비교 | HTML/SVG/mermaid-like deterministic diagram | 사실 관계와 한글 라벨이 중요한 경우 우선 |
| 독자 주의를 잡는 hero artwork | GPT Image 2/imagegen 또는 Skywork `크리에이티브` | 본문 주제를 구체 사물로 열기 |
| 좋은 생성 그림이지만 메시지가 흐린 경우 | generated base + deterministic SVG/HTML annotation | 정확한 텍스트와 화살표는 모델에만 맡기지 않음 |
| 섹션별 개념 설명 | Skywork/GPT Image 2 후보 또는 작은 figure panel | 복잡한 글 중간에 배치 |
| 제품 UI나 실제 화면 설명 | 공식 screenshot 또는 직접 캡처 | 저작권과 출처 확인 필요 |

### 주제형 그림과 기술형 그림

그림을 넣기 전에 먼저 “이 그림이 독자의 관심을 여는가, 아니면 기술 관계를 설명해야 하는가”를 나눕니다.

| 그림 성격 | 목적 | 권장 생성 경로 |
|---|---|---|
| 주제형 그림 | 리뷰의 문제의식을 빠르게 느끼게 함 | GPT Image 2/imagegen hero, Skywork creative poster |
| 기술형 그림 | 구성요소, 순서, 권한, 검증, 병합, 되돌리기 관계를 읽히게 함 | Skywork/GPT Image 2 후보 + SVG/HTML 라벨, 또는 deterministic SVG/HTML |
| 참고자료형 그림 | 논문, 공식 발표, 저장소가 어느 주장에 쓰였는지 연결 | Skywork infographic 후보, 참고자료 맵, 표, NotebookLM export |
| 증거형 그림 | 실제 화면, 저장소, 데이터 구조를 확인 | 공식 screenshot 또는 Playwright capture |

Skywork나 GPT Image 2/imagegen을 쓰더라도 prompt에는 구체 사물을 넣습니다. 예: 문서 더미, 접근 권한 카드, 체크리스트, Git branch, 승인 도장, 캘린더, connector 케이블, 터미널, 감사 로그. `AI cloud`, `digital brain`, `abstract network`처럼 어디에나 붙는 표현만으로 만든 그림은 채택하지 않습니다.

기술형 그림이 필요하면 Skywork나 GPT Image 2/imagegen에 긴 한글 라벨을 맡기지 않습니다. 생성 모델은 장면의 질감과 구성을 만들고, 정확한 라벨과 화살표는 SVG/HTML로 얹는 hybrid 방식을 우선 검토합니다.

imagegen prompt는 분위기 문장보다 구체 장면 문장으로 씁니다.

1. `Subject`: 그림이 받쳐줄 주장
2. `Scene`: 주장을 보여주는 구체 사물
3. `Composition`: 시선이 먼저 가야 할 위치
4. `Style`: 기사형 과학/기술 일러스트레이션, corporate slide art 지양
5. `No text`: 가짜 글자, 로고, UI 패널 금지
6. `Annotation plan`: hybrid라면 나중에 얹을 라벨과 화살표를 미리 정함

### Visual Specificity Ladder

그림이 추상적으로 흐를 때는 아래 사다리를 따라 올립니다.

| 단계 | 쓰임 | 방식 |
|---|---|---|
| 1. Editorial metaphor | 독자의 관심을 잡는 비유적 장면 | GPT Image 2/imagegen 또는 Skywork creative |
| 2. Magazine infographic | 개념 구조를 한 컷으로 보여줄 때 | Skywork Image 또는 GPT Image 2/imagegen |
| 3. Annotated metaphor | 그림은 좋지만 주장이 덜 보일 때 | generated base + SVG/HTML 라벨 |
| 4. Technical cutaway | 구성요소와 관계를 정확히 보여줄 때 | deterministic SVG/HTML 또는 hybrid |
| 5. Process map | 순서, 승인, 재시도, 병합 흐름을 보여줄 때 | Skywork 후보 후 deterministic SVG/HTML과 비교 |
| 6. Source-grounded infographic | 참고자료 묶음이나 NotebookLM 요약을 시각화할 때 | Skywork/NotebookLM export 또는 reference map |
| 7. Evidence screenshot | 실제 제품 UI, 저장소, 데이터 구조를 증명할 때 | screenshot 또는 공식 이미지 |

본문이 3-4단계 설명을 필요로 하는데 그림이 1단계 은유에 머물면 채택하지 않습니다.

### Skywork / GPT Image 2 / imagegen 사용 기준

- Skywork Image는 잡지형 infographic, poster-like section opener, one-cut explainer의 주 후보입니다.
- GPT Image 2/imagegen은 비유적 hero image, conceptual artwork, article thumbnail, section divider, text-free infographic base에 적합합니다.
- 정확한 논문 비교, 회사별 기능표, 출처 지도처럼 사실성이 중요한 내용은 generated bitmap으로 만들지 않습니다. 이런 경우 HTML/SVG 도식이 더 낫습니다.
- generated bitmap은 분위기만 좋다고 통과시키지 않습니다. 인접 섹션의 주제를 한눈에 잡아주지 못하거나, 가짜 글자/로고/라벨이 보이거나, 흔한 AI network/cloud 이미지로 흐르면 다시 생성하거나 deterministic figure로 바꿉니다.
- alt text와 caption에는 그 그림이 받쳐주는 기술 개념을 직접 적습니다. `권한`, `기억`, `connector`, `검증`, `승인`, `병합`, `되돌리기`, `감사 기록`, `테스트`, `작업 재개`처럼 본문 메시지와 연결되는 단어가 보여야 합니다.
- project-bound 이미지는 `artifacts/final_review/figures/`에 저장하고, markdown에서 상대경로로 참조합니다.
- 이미지에는 alt text와 caption을 붙입니다.
- 이미지가 본문 메시지를 강화하지 않으면 넣지 않습니다.

### NotebookLM / Skywork 그림 사용 기준

- NotebookLM의 Infographic/Presentation Studio 출력은 현재 MCP 기본 기능으로 직접 노출되어 있지 않을 수 있습니다. 사용할 때는 브라우저 또는 수동 export 경로를 확인하고, 결과물을 `notebooklm_exports/`에 저장한 뒤 본문에 연결합니다.
- Skywork나 Nano Banana 계열 artwork를 사용할 때도 실제 export 파일, 생성 prompt, viewer capture를 함께 보관합니다. 파일이 없으면 본문에서 사용했다고 쓰지 않습니다.
- Skywork Image Agent는 article figure 후보 생성에 사용할 수 있습니다. 공식 도움말 기준으로 Images Agent는 prompt 기반 생성, 참고 이미지 기반 생성, canvas 편집, layer separation, erase, remove background, expand image, upscale, inpaint 흐름을 제공합니다. 참고 URL: `https://skywork.ai/help/tutorial?key=019c040e-a839-7550-8a19-633aeb0b1708`
- Skywork Image Agent의 적합한 쓰임은 `섹션 opener`, `one-cut editorial infographic`, `article hero 후보`, `프롬프트별 시각 콘셉트 비교`입니다. 정확한 한국어 라벨이 핵심인 도식은 Skywork 이미지 안에 맡기지 말고, 텍스트 없는 그림을 만든 뒤 HTML/SVG 라벨을 얹습니다.
- Skywork category는 그림의 목적에 맞춰 고릅니다. `인포그래픽`은 개념 구조와 비교, `포스터`는 섹션 opener와 한 문장 메시지, `소셜미디어`는 공유용 요약 카드, `로고`는 topic icon, `브랜딩`은 시리즈용 icon/palette, `크리에이티브`는 비유적 장면과 hero 후보에 씁니다.
- Skywork 개별 이미지는 project 또는 notification artifact URL에서 결과 이미지를 확인한 뒤, DOM의 `document.images`에서 원본 이미지 경로를 찾습니다. `image_process=...resize...`가 붙은 thumbnail URL은 query string을 제거해 원본 PNG가 열리는지 확인하고, 원본을 `skywork_exports/image_candidates/`에 저장합니다.
- Skywork 후보가 본문에 올라가려면 `prompt`, `project/artifact URL`, `원본 PNG`, `후보 복사본`, `채택/기각 이유`가 모두 남아 있어야 합니다. 원본은 `skywork_exports/`, 본문 후보 복사본은 `artifacts/final_review/figures/candidates/skywork-image/`에 둡니다.
- 외부 도구 그림은 초안 아이디어 수준에서 멈추지 않고 최종 그림 품질로 판단합니다. 읽히는 글자, 사실 관계, 섹션 적합성, 모바일 렌더링을 검증합니다.

더 자세한 그래픽 배치 감사 규칙은 [editorial-graphics-audit-harness](editorial-graphics-audit-harness.md)를 따릅니다.

### Multi-Generator Artwork Bake-Off

중요한 hero, 섹션 opener, 한 컷짜리 설명 그림은 한 생성기만 믿지 않고 후보를 비교할 수 있습니다.

1. 먼저 `visual brief`를 씁니다.
   - 어느 섹션에 들어가는지
   - 한 문장 메시지가 무엇인지
   - 반드시 보여야 할 대상과 관계가 무엇인지
   - 피해야 할 표현, 가짜 텍스트, 로고, UI hallucination이 무엇인지
   - image 안에 텍스트를 허용할지
2. 같은 brief를 가능한 생성 경로에 보냅니다.
   - Skywork + Playwright: magazine-quality infographic, poster, one-cut explainer
   - GPT Image 2 / `imagegen`: 기사형 은유, hero, 분위기와 subject를 잡는 그림
   - `hybrid`: 생성 그림의 질감은 좋지만 주제가 흐릴 때, SVG/HTML로 정확한 라벨과 화살표를 얹는 방식
   - NotebookLM + Playwright: source-grounded infographic이나 요약형 그림
   - deterministic SVG/HTML: 정확한 비교, reference map, process flow
3. 후보는 모두 저장합니다.
   - GPT Image 2/imagegen 후보: `artifacts/final_review/figures/candidates/<figure-slug>/imagegen/`
   - hybrid 후보: `artifacts/final_review/figures/candidates/<figure-slug>/hybrid/`
   - NotebookLM 후보: `notebooklm_exports/<figure-slug>/`
   - Skywork 후보: `skywork_inputs/`와 `skywork_exports/`
4. 선택은 아래 기준으로 합니다.
   - 본문 메시지 적합성
   - 사실성/검증 가능성
   - 가짜 글자/로고/라벨 없음
   - 한눈에 읽히는 구성
   - Quanta-style article fit
   - 모바일 HTML 렌더링
   - prompt와 export 경로 보존 여부

채택하지 않은 후보도 삭제하지 말고, 간단한 탈락 이유와 함께 candidate 폴더에 보관합니다.

### AI Updates Weekly 하네스 전환 리뷰의 권장 이미지 후보

1. Hero artwork
   - 장면: 하나의 AI 모델이 책상 위에서 여러 작업 도구, 권한 카드, 체크리스트, git branch, calendar connector와 연결된 모습
   - 목적: `모델보다 작업 환경이 중요해지는 흐름`을 직관적으로 보여줌
   - 방식: GPT Image 2/imagegen bitmap illustration 또는 Skywork creative poster

2. Architecture diagram
   - 구조: `Model` -> `Harness` -> `Tools / Memory / Permission / Evaluation / Merge` -> `Work Outcome`
   - 목적: 하네스 개념 설명
   - 방식: Skywork infographic 후보를 먼저 검토하고, 정확한 라벨이 중요하면 HTML/SVG deterministic diagram 또는 hybrid

3. Reference map
   - 구조: Papers / Companies / Open-source / Developer tools / Domain safety
   - 목적: 본문 참고자료 맵
   - 방식: Skywork infographic 후보를 먼저 만들고 HTML/SVG reference map 또는 markdown table과 비교

4. Developer bottleneck panel
   - 구조: `Generate code` -> `Test` -> `Merge` -> `Review` -> `Rollback`
   - 목적: agentic coding 병목을 시각화
   - 방식: small inline diagram

## 재작성 루프

초안이 너무 AI식으로 보이면 한 번에 전체를 고치지 않습니다. 아래 순서로 고칩니다.

1. Intro만 따로 떼어 다시 씁니다.
2. 첫 문장을 메시지로 바꿉니다.
3. 두 번째 또는 세 번째 문단에 독자 질문을 넣습니다.
4. 기술어 설명을 쉬운 업무 예시로 바꿉니다.
5. 그 다음 논문과 회사 사례를 붙입니다.
6. 마지막 문단은 글의 형식을 설명하는 대신 `왜 그런지 이번 리뷰에서 다뤄보겠습니다`처럼 독자의 궁금증을 열어둡니다.

## Intro 작성 템플릿

아래는 구조 템플릿입니다. 문장 그대로 쓰지 말고 주제에 맞게 바꿉니다.

```markdown
최근 [분야]에서는 [구체적 변화]가 자주 확인됩니다.

[독자 장면]을 해보신 적 있으신가요? 이 장면에서는 [관찰 가능한 어려움]이 곧 따라옵니다. 그래서 [실행 구조]가 중요해집니다. 쉽게 말하면, [쉬운 비유 또는 업무 예시]에 가깝습니다.

[논문 A], [논문 B], [회사 발표], [오픈소스 프로젝트]를 함께 보면 [반복해서 확인되는 설계 질문]이 보입니다. [회사]는 [제품/업무면]을 다루고, [프로젝트]는 [도구/하네스]를 실험하고 있습니다.

그런데 [반전 또는 긴장점]도 있습니다. [논문/사례]에서는 [일반적 믿음]이 꼭 좋은 답은 아닐 수 있다는 결과를 보였습니다. 왜 그런지 이번 리뷰에서 다뤄보겠습니다.
```

## 현재 AI Updates Weekly 리뷰에 적용할 방향

이번 리뷰의 도입부는 Lev Selector와 영상 자체를 전면에 두지 않습니다. 다음 메시지를 먼저 둡니다.

> 최근 AI 개발의 무게중심은 모델 순위표에서 하네스로 이동하고 있습니다.

그 다음 독자가 겪을 수 있는 장면을 둡니다.

- AI에게 저장소를 맡겼는데, 어디까지 고쳐도 되는지 매번 설명해야 하는 장면
- 메일, 캘린더, 문서, GitHub를 연결하지 못해 assistant가 답변만 하고 일을 끝내지 못하는 장면
- 여러 coding agent가 동시에 파일을 고치고 merge conflict가 나는 장면

기술 흐름은 다음 순서로 연결합니다.

1. 하네스의 쉬운 정의
2. `Natural-Language Agent Harnesses`, `Meta-Harness`
3. Anthropic Managed Agents, Claude Code Security, finance agents
4. xAI Grok connectors
5. DeepSeek-TUI, Hermes, OpenSwarm, InsForge
6. Zed, Jujutsu, Weave, Mergiraf
7. `In-Context Prompting Obsoletes Agent Orchestration for Procedural Tasks`가 제시한 긴장점

## 완료 기준

리뷰 초안은 아래 조건을 만족해야 합니다.

- 첫 문단에서 주 메시지가 보인다.
- 첫 5문단 안에 독자 질문이나 업무 예시가 있다.
- `이번 리뷰는 ...가 아닙니다`로 시작하는 부정형 메타 전환이 없다.
- `하네스`가 쉬운 언어로 설명되어 있다.
- 최소 2개 이상의 논문/회사/프로젝트가 도입부에서 자연스럽게 언급된다.
- 독자가 "왜 더 많은 에이전트가 항상 답이 아닐 수 있지?"라는 질문을 갖고 본문으로 넘어간다.