---
name: release-copy
description: LinKHU 버전을 올린 뒤 사용자에게 알릴 문구를 쓸 때 사용. 릴리스 노트에서 사용자 노출 변경만 골라 스토어 설명(docs/store-listing.md)의 업데이트 섹션과 커뮤니티 홍보 글(docs/community-post.md)을 갱신한다. "버전 올렸으니 스토어 문구 써줘", "업데이트 안내 글 써줘", "에브리타임에 올릴 글", "2.6.0 문구로 바꿔줘" 같은 요청에 사용.
---

# 릴리스 문구 쓰기

**릴리스 노트를 사용자 언어로 다시 쓰는 일이다. 옮겨 붙이는 일이 아니다.**

원본 두 개를 제자리에서 갱신한다. 매번 새로 짓지 않는다.

| 문서 | 쓰는 곳 | 독자 |
|---|---|---|
| [`docs/store-listing.md`](../../../docs/store-listing.md) | Chrome / Firefox / Whale 설명란, What's new | 설치를 고민하는 사람 |
| [`docs/community-post.md`](../../../docs/community-post.md) | 에브리타임 등 커뮤니티 게시글 | LinKHU를 모르는 사람 |

두 글은 같은 릴리스를 다루지만 독자가 다르다. 스토어 글은 이미 페이지에 들어온 사람에게 목록으로 알리고, 커뮤니티 글은 아무 맥락 없는 사람에게 이게 뭔지부터 설명한다. 한쪽을 복사해 다른 쪽에 넣지 않는다.

## 순서

### 1. 무엇이 바뀌었는지 읽는다

```bash
VERSION=$(node -p "require('./src/manifest.json').version")
cat "release-notes/v$VERSION.md"
```

버전은 `src/manifest.json`이 원본이다. 문구에 적는 번호는 여기서 가져온다.

### 2. 사용자 노출 변경만 고른다

**`### Internal` 섹션은 통째로 버린다.** 사용자가 화면에서 겪지 않는 변경이다.

`Features`와 `Fixes`에서도 화면에 드러나는 것만 남긴다. **3~5개.** 더 늘리면 아무것도 안 읽힌다. 릴리스 노트가 10줄이어도 사용자 눈에 보이는 사건은 보통 서너 개다.

기준은 하나다 — **사용자가 그 항목을 읽고 "그래서 내가 뭘 할 수 있는데"에 답할 수 있는가.**

| 릴리스 노트 원문 | 문구 |
|---|---|
| 색상을 디자인 토큰으로 일원화하고 주색을 역할별로 분리 | 버린다. 화면에서 겪는 일이 아니다 |
| 다크 테마 아이콘 생성 스크립트 추가 | 버린다. 결과는 "다크에서 또렷하게 보인다"로 이미 다른 줄에 있다 |
| 시스템·라이트·다크 3단계 테마 추가 | 남긴다. 사용자가 누를 버튼이 생겼다 |

### 3. 지난 버전 항목을 내린다

**업데이트 섹션은 다음 릴리스에서 사라진다.** 계속 알릴 기능이라면 `[주요 기능]`이나 `[편의 기능]`으로 옮긴 뒤 업데이트 섹션에서 지운다.

v2.4.0의 문의하기가 그렇게 내려갔다. v2.4.0에서는 새 기능이라 업데이트 항목이었고, v2.5.0에서는 `[편의 기능]`의 한 줄이 되었다. 이 단계를 건너뛰면 기능이 조용히 사라진다 — 스토어 설명에 문의하기가 한 줄도 없는 채로 남는다.

두 문서 모두에서 확인한다.

### 4. 사용자 문장으로 고쳐 쓴다

- **내부 용어를 쓰지 않는다.** 디자인 토큰, 생성 스크립트, 워크플로우, 리팩터링, 스펙, 검증 — 전부 사용자 어휘가 아니다.
- **동작으로 쓴다.** "테마 토글 컴포넌트 추가"가 아니라 "헤더의 버튼으로 시스템/라이트/다크를 바꿀 수 있습니다".
- **고친 것은 증상으로 쓴다.** "이랬던 문제가 없어졌습니다"가 "안정성을 개선했습니다"보다 짧고 정확하다.
- **없는 기능을 만들지 않는다.** 릴리스 노트에 없는 항목은 쓰지 않는다. 여기서 지어낸 문장이 스토어 심사와 사용자 기대에 그대로 남는다.
- **버전 번호를 손으로 세지 않는다.** 1단계의 `$VERSION`을 쓴다.

### 5. 두 문서를 갱신한다

- `docs/store-listing.md` — 한국어 블록의 `[vX.Y.Z 업데이트]` 섹션을 교체한다. 나머지 섹션은 3단계에서 옮길 게 없으면 건드리지 않는다.
- `docs/community-post.md` — 첫 줄의 `(vX.Y.Z 업데이트)` 목록을 교체한다. 본문·설치 링크·맺음말은 그대로 둔다.

### 6. 검증한다

```bash
VERSION=$(node -p "require('./src/manifest.json').version")

# 두 문서 모두 새 버전을 말하는가 (각 1이어야 한다)
grep -c "v$VERSION" docs/store-listing.md docs/community-post.md

# 지난 버전 표기가 남아 있는가 (0줄이어야 한다)
grep -nE "v[0-9]+\.[0-9]+\.[0-9]+ 업데이트" docs/store-listing.md docs/community-post.md | grep -v "v$VERSION"

# 내부 용어가 새어 나갔는가 (0줄이어야 한다)
grep -nE "토큰|리팩터|워크플로우|스크립트|스펙|커밋|검증 추가" docs/store-listing.md docs/community-post.md
```

그리고 **릴리스 노트와 나란히 놓고 읽는다.** 지어낸 항목이 있는지는 명령으로 안 잡힌다.

## 하지 말 것

- **`### Internal`을 요약해서 넣지 않는다.** 요약해도 사용자에게는 여전히 남의 일이다.
- **모든 항목을 넣지 않는다.** 목록이 길수록 새 기능이 묻힌다.
- **문서를 새로 쓰지 않는다.** 두 원본은 릴리스마다 제자리에서 고친다. 매번 새로 지으면 말투와 링크가 판마다 갈라진다.
- **스토어 대시보드에 붙여넣는 것까지 대신하지 않는다.** 문서를 갱신하는 데서 끝내고, 붙여넣기는 [Store Release Checklist](../../../docs/store-release-checklist.md)를 따라 사람이 한다.

## 관련 문서

- [Release Process](../../../docs/release-process.md) — 버전 올리기부터 스토어 배포까지 전체 절차
- [Store Release Checklist](../../../docs/store-release-checklist.md) — 스토어별 제출 절차