---
title: KIAS Horizon Style Patterns for AI_Tech_Review
date: 2026-05-09
status: active
scope:
  - reports/*_final_review.md
  - reports/*_memo.md
  - skywork_inputs/
tags:
  - korean-science-writing
  - horizon
  - user-style
---

# KIAS Horizon Style Patterns for AI_Tech_Review

이 문서는 고등과학원 [HORIZON](https://horizon.kias.re.kr/)의 과학 대중 글쓰기에서 배울 수 있는 문장 운용을 `AI_Tech_Review`에 맞게 정리한 참고 문서입니다. 목적은 Horizon 문장 복제가 아닙니다. AI식 요약문과 번역체를 줄이고 `친근하지만 개념적으로 정확한 한국어 기술 리뷰`를 쓰기 위한 기준입니다.

## 참고한 샘플

| 샘플 | 참고한 점 |
|---|---|
| [인공지능 카테고리](https://horizon.kias.re.kr/horizon/%EC%9D%B8%EA%B3%B5%EC%A7%80%EB%8A%A5/) | AI 주제를 제목 질문, 원리, 장점, 한계로 나누어 다루는 방식 |
| [인공지능 기계학습 딥러닝 카테고리](https://horizon.kias.re.kr/horizon/%EC%9D%B8%EA%B3%B5%EC%A7%80%EB%8A%A5-%EA%B8%B0%EA%B3%84%ED%95%99%EC%8A%B5-%EB%94%A5%EB%9F%AC%EB%8B%9D/) | 낯선 수학·AI 개념을 질문과 짧은 역사적 배경으로 여는 방식 |
| [물리 기반 신경망은 전통적 수치해석을 대체할 수 있을까? [1]](https://horizon.kias.re.kr/29873/) | 기술의 장점을 인정하되, 블랙박스와 물리 법칙의 차이를 예시로 풀어가는 방식 |
| [물리 기반 신경망은 전통적 수치해석을 대체할 수 있을까? [2]](https://horizon.kias.re.kr/30065/) | 장점 다음에 한계를 좁혀 설명하고, 적용 가능한 조건을 분명히 하는 방식 |
| [인공지능은 예술을 창작할 수 있을까?](https://horizon.kias.re.kr/15383/) | AI의 능력을 인간 협력, 데이터, 평가 기준과 함께 설명하는 방식 |
| [생성형 인공지능 시대의 인공 역사라는 문제](https://horizon.kias.re.kr/30646/) | 생성형 AI를 사회적 기억, 역사 서술, 방법론 논쟁으로 넓혀 읽는 방식 |
| [수학 아카이브](https://horizon.kias.re.kr/horizon/archives/allarticles/mathematics/) | 전문 주제를 질문형 제목과 연재형 설명으로 분해하는 방식 |

## Horizon식 설명 리듬

### 1. 제목과 첫 문단에서 주제의식을 바로 놓습니다

Horizon 글은 “무엇을 설명하겠다”보다 “이 질문을 어떻게 생각해야 할까”에 가깝게 문을 엽니다. `온도는 어떻게 정의하고 측정하는가?`처럼 제목에서 주제의식을 바로 말하고, 첫 문단에서는 독자가 이미 알고 있는 일상적 경험에서 질문을 꺼냅니다. 다만 질문만 던지고 오래 끌지 않습니다. 곧바로 용어, 역사, 예시, 한계로 들어갑니다.

AI_Tech_Review 적용:

- `이번 리뷰에서는 ... 살펴보겠습니다`보다 `에이전트에게 일을 맡기면 곧 이런 질문이 생깁니다`가 낫습니다.
- 제목은 `현상 요약`보다 `독자가 들고 갈 질문`에 가깝게 씁니다.
- 도입부는 `...가 아닙니다`, `...로만 읽기 어렵습니다`로 시작하지 않습니다. 주제의 문을 여는 질문이나 관찰에서 시작합니다.

예:

- 약함: `모델보다 먼저 막히는 것들`
- 나음: `모델 성능 다음에 남는 질문: 하네스`
- 더 부드러움: `에이전트를 일하게 만드는 작업 구조, 하네스`
- GPT-5.5 예: `어떤 일을 얼마나 더 오래 맡길 수 있게 되었는가`

### 2. 독자의 경험에서 기술적 초점으로 이동합니다

Horizon식 글쓰기는 독자가 이미 가진 경험을 출발점으로 삼습니다. 일기예보에서 온도를 쓰는 경험, 손으로 따뜻함과 차가움을 느끼는 경험, 온도계의 눈금을 읽는 경험이 온도 정의와 측정이라는 과학적 질문으로 이어집니다. AI_Tech_Review에서도 독자가 실제로 모델을 써본 장면, 업무를 맡겨본 장면, 검증이 막힌 장면에서 기술적 초점으로 들어갑니다.

AI_Tech_Review 적용:

- `모델 성능이 전부가 아닙니다`처럼 쓰지 않습니다.
- `모델에게 코드 수정이나 문서 조사를 맡겨보면, 답변 하나의 품질만큼이나 여러 단계를 얼마나 안정적으로 이어 가는지가 중요해집니다`처럼 씁니다.
- `벤치마크 점수보다 Agentic 작업 능력이 중요합니다`처럼 기존 관심사를 밀어내지 않습니다.
- `벤치마크 점수와 함께, 어떤 일을 얼마나 더 오래 맡길 수 있는가를 보아야 합니다`처럼 초점을 확장합니다.

### 3. 설명은 초반에 충분히 하고, 뒤로 갈수록 줄입니다

도입부의 설명이 조금 길어져도 괜찮습니다. 중요한 것은 그 설명이 다음 문단의 맥락을 만드는지 여부입니다. 처음에는 독자의 경험, 쉬운 예시, 용어의 필요성을 충분히 열어두고, 뒤로 갈수록 이미 만들어진 맥락 위에서 더 짧게 말합니다.

주의:

- 설명이 길다고 모두 좋은 것은 아닙니다.
- 문장이 늘어지는 만연체가 되면 안 됩니다.
- 초반 설명은 다음 개념을 이해하게 만드는 준비여야 합니다.
- 중반 이후에는 같은 설명을 반복하지 않고, 공유된 용어와 맥락을 활용합니다.

### 4. 전문 용어는 짧은 계보와 함께 들어옵니다

Horizon은 전문 용어를 피하지 않습니다. 대신 독자가 이미 아는 장면, 역사적 맥락, 쉬운 질문을 통해 용어를 받아들일 자리를 만듭니다.

AI_Tech_Review 적용:

- `하네스`처럼 글의 중심 용어는 첫 등장 때 계보를 짧게 둡니다.
- `test harness -> LLM evaluation harness -> agent harness`처럼 길지 않은 계보가 독자의 신뢰를 만듭니다.
- 시스템 카드처럼 독자에게 낯설 수 있는 문서는 첫 등장 때 짧게 풀어줍니다. 예: `시스템 카드는 모델의 사용 조건, 안전성 평가, 알려진 한계와 배포 조건을 설명하는 문서입니다.`

### 5. 문장 전환은 개념 자체가 이끌어야 합니다

AI식 문장은 `이 관점이 중요한 이유는`, `이 변화는`, `이 문제는`처럼 글쓴이의 설명 도구가 앞에 섭니다. Horizon식 문장은 개념 자체가 다음 문장으로 넘어갑니다.

대체 방향:

| AI식 전환 | Horizon식 방향 |
|---|---|
| `이 관점이 중요한 이유는...` | `하네스가 흥미로운 대목은 모델을 바꾸지 않고도 작업 절차를 조정할 수 있다는 데 있습니다.` |
| `이 변화는 편리하지만 가볍지 않습니다.` | `connector가 붙는 순간, 편의 기능은 곧 권한 관리 문제가 됩니다.` |
| `이 질문은 실무적으로 현실적입니다.` | `실무에서는 이 질문이 곧 비용, 속도, 책임의 문제로 이어집니다.` |
| `보여주는 사례입니다.` | `...에서는 같은 질문이 더 구체적인 업무 장면으로 옮겨갑니다.` |

### 6. 부정형 반전으로 주제를 강화하지 않습니다

AI식 글은 종종 `A가 아니라 B입니다`, `...로만 읽기 어렵습니다`, `...가 아닙니다`로 주제를 세웁니다. 이 방식은 빠르게 보이지만 독자의 경험보다 글쓴이의 대비 구조가 먼저 보입니다. Horizon식 설명은 반박 대상을 먼저 세우기보다 질문과 개념을 따라가며 주제를 만듭니다.

피할 도입:

```markdown
최근 GPT-5.5 업데이트는 성능 벤치마크 점수가 높아진 통상적인 모델 발표로만 읽기 어렵습니다.
```

권장 도입:

```markdown
최근 GPT-5.5 업데이트를 통해 어떤 일을 얼마나 더 오래 맡길 수 있게 되었는가 하는 Agentic 작업 능력이 중요한 성능평가 요소로 보아야 함을 느낄 수 있습니다.
```

친근한 공유 글에서는 이렇게도 시작할 수 있습니다.

```markdown
여러분, 최근 GPT-5.5 업데이트가 된 것을 알고 계셨나요? 혹시 모델에게 코드 수정이나 문서 조사를 맡겼을 때, 답변 하나보다 여러 단계를 얼마나 안정적으로 이어 가는지가 더 중요하다고 느껴본 적 있으신가요?
```

### 7. 주어와 책임의 위치를 분명히 합니다

Horizon식 과학 글은 설명을 쉽게 하더라도 개념의 책임 위치를 흐리지 않습니다. AI 기술 리뷰에서도 마찬가지입니다.

구분:

- 모델/에이전트: 생성, 검색, 편집, 도구 호출, 제안
- 하네스: 권한 제한, 맥락 제공, 상태 기록, 평가, 승인 요청, 되돌리기
- 사람: 검토, 승인, 책임
- 조직: 정책, 데이터 경계, 감사 요구

피함:

- `오래 실행되는 에이전트는 기억을 정리하고 결과를 평가해야 합니다`

권장:

- `장기 작업에는 기억을 고르고 평가하는 하네스가 필요합니다`

### 8. 소제목은 작은 결론 또는 좋은 질문이어야 합니다

Horizon/Quanta/Science Note의 좋은 제목은 대체로 `분류`보다 `질문 또는 결론`에 가깝습니다.

AI_Tech_Review 소제목 점검:

- 이 제목만 읽어도 독자가 무슨 이야기를 가져갈지 아는가?
- 글쓴이가 참고자료를 어떻게 분류했는지보다 기술 변화가 무엇인지 말하는가?
- `보입니다`, `다룹니다`, `중요합니다` 같은 보고문보다 더 구체적인 동사를 쓰고 있는가?

## AI식 제안도 다시 검사합니다

AI식 표현을 고친다고 해서 좋은 문장이 되지는 않습니다. 특히 다음 대체안도 조심합니다.

| 겉보기에는 좋아 보이나 주의할 표현 | 문제 |
|---|---|
| `...의 무대가 ...로 넓어지고 있습니다` | 비유가 커서 자주 쓰면 AI식 추상문이 됩니다. |
| `...에 브레이크를 겁니다` | 친근하지만 기사 전체 톤과 맞지 않으면 가벼워집니다. |
| `...이 선명해집니다` | 원인과 근거가 빠지면 자동 요약문처럼 들립니다. |
| `...가 보여줍니다` | 자료를 주어로 세우는 반복 문장이 됩니다. |
| `...로 이동합니다` | 영어식 추상 동사입니다. |

좋은 대체안은 표현을 더 꾸미는 데서 나오지 않습니다. 더 정확한 주어와 장면에서 나옵니다.

## 주기적 학습 규칙

Horizon 문체 학습은 한 번으로 끝내지 않습니다.

권장 주기:

- 월 1회: HORIZON 최신 글 3편을 확인합니다.
- 분기 1회: AI/수학/물리/생명/과학사회 글을 섞어 8-10편을 다시 샘플링합니다.
- 큰 리뷰 작성 전: 해당 주제와 가까운 Horizon 글 1-2편, Quanta 글 1편, Science Note 글 1편을 빠르게 훑고 `도입 방식`, `개념 해체 방식`, `figure 배치 방식`만 기록합니다.

기록 위치:

- 공통 패턴: `.automation/horizon-style-patterns.md`
- 리뷰별 적용 메모: `notes/YYYY-MM-DD_<slug>_style_audit.md`
- 외부 레퍼런스 풀: `.automation/editorial-reference-pool.md`

주의:

- 문장을 길게 베끼지 않습니다.
- 짧은 표현도 출처를 링크로 남기고, 실제 리뷰에는 패턴만 적용합니다.
- 최신 글 확인은 주기적으로 하되, 매번 모든 리뷰에 외부 스타일 분석을 길게 붙이지 않습니다.
