---
name: blog-style
description: 작성한 기술 블로그 초안을 be_zion(velog.io/@be_zion) 고유 문체와 구조로 변환한다. 초안이 완성된 후 velog 게시 전에 사용.
argument-hint: "[선택사항: 초안 내용 또는 파일 경로]"
---

# be_zion 블로그 스타일 변환

## 목적

작성된 기술 블로그 초안을 be_zion의 고유한 글쓰기 스타일로 변환한다.
분석 출처: https://velog.io/@be_zion/posts (최신 10건 기준)

---

## be_zion 스타일 핵심 특징

### 1. 전체 구조 패턴

```
[도입부]  문제 제시 또는 기술적 맥락 → 독자가 왜 읽어야 하는지 명확히
[본문]    개념 → 원리 → 구현 → 트레이드오프 순서로 단계적 전개
[마무리]  단순 요약 X → 메타인지적 전환 (더 큰 맥락, 설계 철학으로 연결)
```

섹션 간 구분은 `---` 사용. 소제목은 `##`, `###` 계층 유지.

### 2. 도입부 스타일

- 현재 기술 생태계의 맥락 또는 문제 상황으로 시작
- "왜 이 글을 쓰는가"를 첫 문단에서 명확히
- 질문 형식으로 독자 몰입 유도 가능
  - 예: "LLM은 왜 외부 도구가 필요한가?"
- 긴 글은 TL;DR 섹션으로 빠른 요약 제공

### 3. 설명 방식

**추상 → 구체 순서**
- 개념을 먼저 정의하고, 구체적 예시로 전환
- 코드, 표, ASCII 다이어그램으로 시각화

**대비 구조 적극 활용**
- A vs B, before/after, 방식1 vs 방식2
- 예: "캘린더 기준 vs Sliding Window"
- 양극단을 제시하여 선택 근거를 명확히

**핵심 강조 방식**
- 중요 개념: `**볼드**` 처리
- 핵심 메시지: 블록인용(`>`)으로 감싸기
- 섹션 번호: 이모지 활용 (1️⃣, 2️⃣, 3️⃣)

### 4. 트레이드오프 명시

설계 결정에는 반드시 트레이드오프를 드러낸다.

```
✅ 이 방식을 선택한 이유
❌ 이 방식의 한계
→ 따라서 이 맥락에서는 ~가 더 적합하다
```

### 5. 논리 연결사

- 결론 도출: "따라서", "정리하면", "결국"
- 전환: "반면", "그러나", "이와 달리"
- 강조: "핵심은", "중요한 점은"

### 6. 마무리 스타일

단순 요약이 아닌 **메타인지적 전환**으로 마감:
- 기술 상세 → 설계 철학으로 확장
- 개인 경험 글: 자기성찰 + 미래 방향
- 예: "단순 사용법이 아니라, 프로토콜 수준에서 어떻게 설계되는지에 대한 이해가 중요하다"

### 7. 제목 스타일

- 본론 중심, 기술 용어 명시
- 부제목: 이모지 + 번호 + 한국어
  - 예: `1️⃣ 일간 랭킹의 시간 기준`
- 시리즈물: `주제 - 세부 내용` 패턴
  - 예: `MCP 구조 분석 - Orchestration Layer`

---

## 워크플로우

### Step 1: 초안 수집

인수로 초안이 전달된 경우 그대로 사용.
전달되지 않은 경우 사용자에게 초안 내용을 요청한다.

### Step 2: 초안 분석

초안을 읽고 다음을 파악한다:

- **핵심 주제**: 이 글이 전달하려는 핵심 메시지 1~2줄
- **대상 독자**: 입문 / 중급 / 심화
- **글 유형**: 개념 설명 / 구현 경험 / 설계 분석 / 오픈소스 기여
- **현재 구조**: 도입부가 있는지, 마무리가 어떻게 되어 있는지

### Step 3: 스타일 갭 분석

현재 초안과 be_zion 스타일의 차이를 파악한다:

```
| 요소 | 현재 초안 | be_zion 스타일 | 변환 필요 여부 |
|------|----------|---------------|-------------|
| 도입부 | ... | 문제/맥락 제시 | Y/N |
| 섹션 구조 | ... | --- 구분, 이모지 번호 | Y/N |
| 설명 방식 | ... | 추상→구체, 대비 구조 | Y/N |
| 트레이드오프 | ... | 명시적 | Y/N |
| 마무리 | ... | 메타인지적 전환 | Y/N |
```

### Step 4: 스타일 변환 적용

다음 순서로 변환한다:

**4a. 제목 재작성**
- 기술 용어 중심으로
- 필요 시 `주제 - 세부내용` 패턴 적용

**4b. 도입부 재작성**
- 문제 상황 또는 기술 맥락으로 시작
- 질문으로 독자 몰입 유도
- 500자 이상 글이면 TL;DR 추가

**4c. 본문 구조 재편**
- 섹션 간 `---` 삽입
- 소제목에 이모지 번호 적용
- 추상 → 구체 순서로 재배치
- 대비 구조가 가능한 부분 식별 후 적용

**4d. 핵심 강조 처리**
- 핵심 개념 `**볼드**` 처리
- 가장 중요한 메시지 1~2개 블록인용(`>`)으로 변환
- 코드, 표, 다이어그램이 빠진 부분 보완

**4e. 트레이드오프 섹션 보강**
- 설계 결정이 있는 모든 부분에 트레이드오프 명시
- "왜 이 방식을 선택했는가"를 명확히

**4f. 마무리 재작성**
- 단순 요약 제거
- 기술 상세에서 설계 철학 또는 더 큰 맥락으로 전환
- 개인 경험 글이면 자기성찰 + 미래 방향 추가

### Step 5: 파일로 저장

변환된 글을 채팅에 출력하지 않고 **파일로 저장**한다.

**파일 경로 규칙:**
```
docs/blog/YYYY-MM-DD-<제목-슬러그>.md
```
- 날짜: 오늘 날짜 (YYYY-MM-DD)
- 슬러그: 제목을 소문자 영문/숫자/하이픈으로 변환 (한글 제목이면 핵심 키워드를 영문으로)
- 예: `docs/blog/2026-04-11-claude-api-streaming-simulation.md`

파일을 저장한 뒤 채팅에는 다음만 출력한다:

```
📝 초안 저장 완료: docs/blog/YYYY-MM-DD-<슬러그>.md

## 변환 요약
- 제목: [변경 전] → [변경 후]
- 주요 변경: (3~5줄)
- 추가 제안: (선택적으로 보강하면 좋을 부분)

파일을 열어 직접 수정하세요.
```

---

## 스타일 예시

### 도입부 예시

```markdown
Redis를 캐시로만 쓴다면 절반만 쓰는 것이다.

실시간 랭킹을 구현하다 보면 자연스럽게 마주치는 문제가 있다.
"어느 시점을 기준으로 집계할 것인가?" 이 질문 하나가
데이터 구조 선택, TTL 전략, 정합성 보장 방식 전체를 결정한다.
```

### 트레이드오프 예시

```markdown
**캘린더 기준 vs Sliding Window**

| 방식 | 장점 | 단점 |
|------|------|------|
| 캘린더 기준 (00:00~23:59) | 구현 단순, 직관적 | 자정 직후 랭킹 급변 |
| Sliding Window (최근 24시간) | 부드러운 변화 | 구현 복잡, 스토리지 증가 |

> 완벽함보다 신뢰성. 자정 이슈를 감수하더라도 캘린더 기준이 운영 부담이 적다.
```

### 마무리 예시

```markdown
이 글에서 다룬 것은 단순한 Redis 명령어가 아니다.

"데이터를 어떻게 저장할 것인가"가 아니라
"시간을 어떻게 정의할 것인가"가 랭킹 시스템의 핵심이다.
기술 선택은 항상 비즈니스 요구사항의 해석에서 시작된다.
```

---

## 주의사항

- 원본 초안의 **기술적 사실과 내용은 변경하지 않는다**
- 스타일 변환이지 내용 추가가 아니다. 없는 내용을 지어내지 않는다
- 초안에 코드가 있으면 코드 자체는 그대로 유지한다
- 저자의 고유한 경험담이나 개인적 판단은 보존한다