/omd-kr-writer

name: omd:kr-writer
description: "한국어 블로그·장문 글을 12개 voice preset으로 작성하거나 다듬는다 — toss-tech-design (default), karrot-neighborly, brunch-maker-popular, naver-d2-engineering, biz-formal-report, academic-paper, journalism-broadsheet, kakao-warm-product, line-global-saas, academic-lecture-essay, emotional-brand, legal-disclosure."
user-invocable: true

omd:kr-writer

oh-my-design의 한국어 본문 작성 스킬. **preset_id 인자**로 12개 voice 중 선택.

0. preset_id 인자

호출 envelope:

agent: omd-kr-writer
inputs:
  preset_id: toss-tech-design  # 또는 아래 12개
  task: "당근 디자인 분석 글 작성"
  ...

지원 preset 12개. 각 preset의 핵심 spec은 아래 **§9 (preset 요약 spec)** 에 self-contained로 수록 — 이 SKILL.md만으로 12개 preset 전부 실행 가능.

| # | preset_id | 종결 | 분량 (한글) | 용도 | |---|---|---|---|---| | 1 | `toss-tech-design` ⭐ (default) | 해요체 -요 | 5,500~7,000자 | omd 블로그 본문, 디자인 deep-dive | | 2 | `karrot-neighborly` | 해요체 + 동네 lexicon | 3,000~5,000자 | 마케팅, 커뮤니티 글 | | 3 | `brunch-maker-popular` | 해요체 80% + 회상 `-했다` | 4,000~6,000자 | 회고, 포스트모템, 메이커 에세이 | | 4 | `naver-d2-engineering` | 하십시오체 -합니다 | 자유 | 엔지니어링 분석 글 | | 5 | `biz-formal-report` | 하십시오체 -습니다 | 자유 | 보고서·기획서·BRD | | 6 | `academic-paper` | 해라체 `-한다`/`-이다` | 자유 | 학술 논문, 연구 노트 | | 7 | `journalism-broadsheet` | 해라체 `-다`/`-했다` | 자유 | 보도자료, 신문기사 | | 8 | `kakao-warm-product` | 해요체 + 감정 표현 | 자유 | 카카오톡·카카오뱅크 in-app copy | | 9 | `line-global-saas` | 하십시오체 + 다국어 친화 | 자유 | 한일 brand voice, 글로벌 SaaS | | 10 | `academic-lecture-essay` | 해요체 + 학술 lexicon | 자유 | 교양 강연, 지식 에세이 | | 11 | `emotional-brand` | 해요체 + 외래어 자유 | 자유 | 무신사·29CM 패션 커머스 | | 12 | `legal-disclosure` | 하십시오체 + 한자어 | 자유 | 법무·약관·고지사항 |

**호출 시 preset 미지정 → `toss-tech-design` 적용.**

본 문서의 § 1~8은 default preset (`toss-tech-design`)의 상세 spec. 다른 preset 선택 시 §9의 해당 preset 요약 spec 룰로 substitution.

preset 전환 예시

같은 콘텐츠를 다른 preset으로 옮길 때 standard rewrite 룰 — 아래 핵심 변환 + §9 spec만으로 수행 가능. (확장 5-step rule은 dev 레포 research doc §14 — 배포본 미포함.)

| from | to | 핵심 변환 | |---|---|---| | `biz-formal-report` | `toss-tech-design` | `-합니다`→`-해요` · 한자어 풀이 · 50자+ 문장 쪼개기 · source에 저자 사실이 있을 때만 1인칭 | | `toss-tech-design` | `biz-formal-report` | `-요`→`-니다` · 인사 제거 · 섹션 번호 (1.1) · 한자어 회복 | | `academic-paper` | `toss-tech-design` | `-한다`→`-해요` · `우리는`→`저는` · 인용 형식 인라인 | | `karrot-neighborly` | `toss-tech-design` | "동네" lexicon 제거 · 분석 voice 강화 · 5,500자+ | | `journalism-broadsheet` | `toss-tech-design` | `-다`→`-요` · 인용 상태와 원문 보존 · source에 저자 사실이 있을 때만 1인칭 | | `legal-disclosure` | `kakao-warm-product` | 한자어 → 우리말 · 수동 → 능동 · 친근 어휘 보강 |

한국어 어말어미 — 6단계 speech level

| 단계 | 격식 | 친근 | 종결예 | preset 매핑 | |---|---|---|---|---| | 하십시오체 | ✓ | ✗ | -습니다 | biz-formal / legal / line | | 하오체 | ✓ | ✗ | -오, -소 | (구식, 거의 안 씀) | | 하게체 | △ | △ | -네, -게 | (구식, 윗사람→아랫사람) | | 해라체 | ✗ | ✗ | -다, -한다 | academic / journalism | | 해요체 ⭐ | △ | ✓ | -요, -아요 | toss / karrot / kakao / brunch / lecture / emotional | | 해체 (반말) | ✗ | ✓✓ | -아, -이야 | (사용 안 함 — disrespectful) |

omd 디폴트는 **해요체**. 격식이 필요하면 하십시오체. 학술/뉴스만 해라체. 그 외 모든 경우 해요체.

---

Default preset (toss-tech-design)

oh-my-design 블로그의 한국어 본문을 **Toss Tech 디자인 카테고리** 수준의 voice로 작성. Brunch와 당근 미디엄도 보조 참고.

1. Voice DNA — 한국 디자인 블로그 명문 공통 패턴

첫 단락

독자가 바로 이해할 수 있는 구체적인 문제, 장면, 관찰, 또는 결론으로 시작한다. 이름·직무·개인 경험이 입력에 명시된 경우에만 1인칭 소개를 쓸 수 있다. 저자 신원이나 경험을 추측해 `안녕하세요. [직무] [이름]이에요.` 같은 소개를 만들지 않는다. 인사는 글의 목적에 도움이 될 때만 짧게 쓴다.

종결 어미 룰

| 사용 | 빈도 | |---|---| | `-요` | **100%** (default) | | `-했어요`, `-있어요`, `-거예요`, `-네요` | 자주 | | `-아요`, `-이에요` | 자주 | | `-습니다`, `-는다`, `-한다` | **금지** (관공서 톤) | | `-입니다`, `-합니다` | **금지** |

문장 호흡

• **평균 35~50자/문장**. 80자+ 문장 = 쪼개기.
• 두 문장 연결: `~했고, ~했어요.` → 가급적 `~했어요. ~했어요.` 두 문장으로.
• 접속사 `그리고`/`그래서`/`그런데` 남발 금지. 단락 이행은 새 단락으로.
• 감탄/조사 `~네요`, `~죠`, `~인가요?` 적절히 — 글이 살아남.

단락 길이

• **평균 3~5 문장 / 단락**. 80자+ 단락 = 쪼개기.
• 한 줄 단락 OK — 강조용.
• 글 전체에서 80% 이상이 짧은 단락.

마무리

글에서 확인한 결론이나 다음 판단으로 끝낸다. 댓글 요청, 다음 글 예고, 제품 설치 안내 같은 CTA는 brief가 요구하고 실제 독자 행동과 연결될 때만 쓴다. 제공되지 않은 링크·명령·제품 기능을 만들지 않는다.

2. 구조 템플릿 — 디자인 시스템 분석 글

한국어 H2 헤더 패턴

영문 식 `## Insight 1 — OKLCH-based perceptual color scaling` 같은 무거운 헤더는 금지. 한국어는 **짧고 호흡감 있게**.

| 영문 패턴 | 한국어 변환 | |---|---| | `## 1. A short history of "the Toss feel"` | `## 토스 느낌의 시작` | | `## 2. The atmosphere — calm, confident, deceptively simple` | `## 화면을 열면 흰 캔버스` | | `## 3. Insight 1 — OKLCH-based perceptual color scaling` | `## 토스는 색을 수학으로 정의해요` | | `## 4. What to steal` | `## 가져가도 좋은 것` | | `## 5. What NOT to steal` | `## 따라하면 안 되는 것` |

원칙: 헤더는 **3~12자**. 문장형 OK, 호기심 유발 OK, 결론 spoiler OK.

권장 글 구조 (5,500자+ 목표)

1. **문제 또는 글 소개** (~300자) — 독자가 알아야 할 맥락 + 오늘 다룰 질문 + 분석 방법 2. **브랜드 배경** (~600자) — 회사 역사 짧게, 디자인이 왜 지금처럼 됐는지 3. **첫 인상 — 화면을 열면** (~700자) — 시각 톤, 색, 타입, 첫 느낌 4. **인사이트 1** (~700자) — 발견 1개, 왜 중요한지, 어떻게 따라할지 5. **인사이트 2** (~700자) 6. **인사이트 3** (~700자) 7. **인사이트 4** (~700자) 8. **인사이트 5** (~600자) — 더 짧아도 OK 9. **가져가도 좋은 것** (~400자) — 5개 정리 (불릿 OK) 10. **따라하면 안 되는 것** (~400자) — 5개 정리 11. **마무리** (~200자) — 핵심 판단 또는 다음 단계. CTA는 brief에 있을 때만

목표: **5,500자~7,000자** (한국어, 공백 제외).

3. 이미지/figure 정책

이미지는 근거를 설명하거나 독자의 이해를 높이는 경우에만 넣는다. 개수 할당량은 없다.

• 실제로 존재하고 사용 권한이 확인된 에셋만 참조한다.
• 제공된 스크린샷·다이어그램·컬러 그리드가 본문 주장과 직접 연결될 때 배치한다.
• alt 텍스트는 이미지가 전달하는 정보를 간결하게 설명한다. figcaption은 출처나 본문과의 관계가 필요할 때만 쓴다.
• 에셋이 없으면 `./images/...png` 같은 placeholder를 만들지 않는다. 필요한 이미지와 목적을 handoff에 적는다.
• 라이브 캡처나 새 이미지 생성은 현재 작업에 해당 도구와 권한이 명시된 경우에만 수행한다.

4. 인사이트 본문 패턴

각 인사이트는 다음 4 단락 구조 권장:

1. **현상 단락**: "토스를 열면 이상한 게 있어요. ~" — 호기심 hook 2. **데이터 단락**: "실제로 CSS 번들을 뜯어보니, ~ 81번 등장하더라구요." — 숫자/증거 3. **이유 단락**: "왜 이렇게 했을까요? ~" — 디자인 thesis 4. **적용 단락**: "여러분 작업에 가져가려면, ~" — actionable

5. 안티패턴 (절대 금지)

• ❌ `-습니다`, `-한다`, `-할 것이다` 등 격식체
• ❌ `~할 수 있다` 식 가능형 남발 → `~할 수 있어요`
• ❌ 영어를 한글로 번역만 한 듯한 문장 (`이것은 우리가 만든 시스템이다` — X. `우리가 만든 시스템이에요.` — O)
• ❌ 영문 인용 부호 그대로 (`"trust comes from clarity"`) → `"신뢰는 깊이가 아니라 명확함에서 온다"` (한글 번역 + 영문 옆에 작게)
• ❌ 머리말 `## 1. 인사이트 1 — Insight 1: OKLCH-based ~` 식 형식적 헤더
• ❌ 마지막에 "감사합니다." 한 줄 → 톤 깨짐. 차라리 안 쓰기.
• ❌ 문단 사이를 `**굵게**` 강조로 도배 — 시각 노이즈
• ❌ 5