designpaca/packages/skill/references/product-copy.md

product-copy — 제품 UI 카피

4단계에서 버튼·폼 라벨·상태 메시지·오류·빈 상태·토글처럼 제품이 스스로 말하는 문구를 쓸 때 읽는다. 히어로 표제·섹션 제목·소개 문단을 쓸 때는 §13-b·§13-c를 연다. 5단계 프리플라이트의 카피 검토에서 다시 연다.

브랜드 차별성을 주장하는 마케팅 헤드라인·브랜드 약속의 슬롭 지문(so you can… 테스트, 구문·어휘 지문)은 이 문서가 아니라 antipatterns.md 6절이 정본이다. 히어로 표제·섹션 제목·소개 문단의 한국어 문장 결함(번역체, 선언·잠언형 과장, 감성 어휘 반복, 영문 장식 라벨)은 이 문서 §13-c가 정본이다. 두 문서는 같은 대상을 다른 각도에서 본다 — 헤드라인이 버튼·토글 같은 제품 UI 라벨을 겸하면 두 문서를 모두 확인한다.

라벨은 셋 중 하나다. 하드 게이트는 위반하면 통과시키지 않는다(WCAG 등 규범·기능 요건). 프로젝트 계약은 이 프로젝트가 그 조건을 선택했을 때 지키는 약속이다(용어 체계, 어투 통일 같은 자체 결정). 관찰 후보는 시작값이고 실제 렌더·독자 반응에서 확인해 조정한다. 절 제목에 주된 위계를 붙이고, 절 안에서 다른 위계가 섞이면 문장 앞에 굵게 라벨을 따로 단다.

이 문서를 읽는 법

상황	읽을 곳
새 카피를 쓰기 전에 뭘 먼저 봐야 하나	§1
같은 개념을 화면마다 다르게 부르고 있는 것 같다	§2
오류·삭제 확인·결제 화면의 톤이 다 같아 보인다	§3
한 화면에 해요체와 합니다체가 섞인다	§4
버튼 라벨을 어떻게 짓나	§5
오류 메시지를 쓴다	§6
빈 상태·빈 목록 문구를 쓴다	§7
내부 개발 용어가 라벨에 새어 나온 것 같다	§8
{name}을(를) 삭제했습니다 같은 변수 삽입 문장	§9
토글·링크 텍스트·placeholder	§10
물음표·느낌표·줄임표를 언제 쓰나	§11
숫자·단위·금액·날짜·시간 표기	§11-1
영문 라벨의 대소문자 규칙	§12
실제 서비스 사례가 궁금하다	§13
브랜드 헤드라인 후보를 고른다 · 메타 서술 금지	§13-b
히어로 표제·섹션 제목·소개 문단이 번역체이거나 과장돼 보인다	§13-c
카피 findings를 어떻게 검증·보고하나	§14
상호·가격·후기 같은 실제 값이 아직 없다	§16
감사 직전	§15

---

0. 언제·범위

이 문서는 4단계에서 폼·상태·오류·빈 상태·토글처럼 제품이 스스로 말하는 문구를 쓸 때 연다. 5단계 프리플라이트에서 카피만 따로 다시 훑을 때도 연다. 링크 텍스트·placeholder의 접근성 배선(스크린리더 순서, aria-describedby, 포커스 이동)은 이 문서가 아니라 accessibility.md가 정본이며, 이 문서는 그 위에 얹히는 문구 내용만 다룬다.

---

1. 기존 보이스·용어 확인 — 프로젝트 계약

새 카피를 쓰기 전에 프로젝트에 이미 있는 카피를 읽는다. design.md, 기존 화면의 라벨·토스트·오류 문구, 저장소에 남은 스타일 가이드를 먼저 훑어 제품이 이미 쓰고 있는 용어·어투·로케일 관행을 파악한다[SKILL-BETTER-WRITING]. SKILL.md의 우선순위 원칙(사용자 지시 → design.md → 기존 토큰·코드 → designpaca 기본값)이 토큰·코드에 대해 요구하는 것과 같은 태도를 카피에도 적용한다 — 새로 지어내기 전에 이미 있는 답을 먼저 찾는다.

---

2. 용어 일관성 — 프로젝트 계약

한 개념에는 한 용어만 쓴다. 메뉴에서 보관함이라고 부른 것을 토스트에서 저장소로 이동이라고 부르면, 사용자는 같은 일을 두 번 배워야 한다[SKILL-BETTER-WRITING].

grep 방법

1. 화면에 쓰인 명사·동사를 후보로 뽑는다(예: 삭제/제거/지우기, 보관/저장소/아카이브).
2. 저장소 전체에서 각 후보를 grep해 실제로 몇 군데서 어떤 말로 쓰이는지 센다.
3. 가장 많이 쓰인 쪽을 기준으로 정하거나, 사용자에게 더 명확한 쪽을 고른다. 어느 쪽이든 design.md에 기록한다.
4. 소수파 표현을 전부 grep으로 찾아 바꾼다. 코드 식별자(archiveItem 같은 함수명)까지 바꾸라는 뜻은 아니다 — 사용자가 보는 문자열만 대상이다.

---

3. 톤과 위험 매트릭스 — 관찰 후보

모든 문구를 같은 톤으로 쓰면, 정말 조심해야 하는 순간(삭제·결제)도 일상 안내와 구분되지 않는다. 상황의 위험 수위에 따라 톤 강도를 다르게 가져간다[SKILL-BETTER-WRITING].

위험 수위	상황 예	톤	이유
일상	목록 화면, 설정, 일반 안내 문구	중립·간결	매번 감정을 실으면 정말 중요한 순간의 톤이 묻힌다
주의	로그아웃, 구독 변경, 여러 항목 일괄 처리	신중·결과를 분명히 말함	다음에 무슨 일이 벌어지는지 오해하면 안 된다
파괴	삭제 확인, 탈퇴, 결제 취소	차분·군더더기 없음(장난기·이모지 배제)	가벼운 톤은 행동의 무게와 어긋난다
오류	폼 검증 실패, 저장 실패, 네트워크 오류	담백·비난하지 않음	§6 참고 — 과한 사과·느낌표는 문제를 가리지 않는다
금전·보안	결제, 개인정보 변경, 본인 인증	진지·조건을 흐리지 않고 명시	오해가 실제 손실로 이어질 수 있다

이 위험 수위는 0단계 인터뷰에서 정한 브리프의 톤 프리셋(brief-interview.md)과 다른 층이다 — 브리프의 톤이 전체 브랜드 인상을 정하고, 이 표는 그 톤 안에서 상황별 강도를 조절한다. 장난스러운 브랜드 톤이라도 결제·보안 화면까지 그 장난기를 그대로 옮기지 않는다.

---

4. 어투 일관성 — 프로젝트 계약

한 제품 안에서 해요체(~해요, ~돼요)와 합니다체(~합니다, ~됩니다)를 섞으면 어투가 흔들려 보인다. 어느 쪽을 쓸지는 브랜드 톤에 따라 프로젝트가 정하고, 정했으면 화면 전체에서 지킨다.

이 규칙의 근거는 1차 출처로 확인되지 않았다 — 실무에서 두 어체를 상황별로 섞어 쓰는 사례가 보고되긴 하나, 그 출처가 1차 공식 자료가 아니라서 이 문서는 규범이 아니라 프로젝트 계약으로만 둔다. 브리프나 기존 화면이 이미 특정 어체를 쓰고 있으면 그것을 따르고(§1), 새로 정해야 하면 0단계 인터뷰의 톤 질문과 함께 확정한다. 확정한 뒤에는 §2와 같은 방법으로 grep해 혼용된 곳을 찾는다.

---

5. 버튼 레이블 — 프로젝트 계약

행정안전부 KRDS(공공 디자인 시스템) 지침은 버튼 텍스트를 원칙적으로 동사형으로 쓰도록 규정한다. 완료·닫기·취소·추가·삭제처럼 이미 관용적으로 쓰이는 명사형은 예외다[KO-KRDS]. 명사·형용사 라벨(저장 버튼입니다 같은 서술이 아니라 그냥 저장 완료 같은 애매한 상태명)은 버튼을 눌렀을 때 무슨 일이 일어나는지 예측하기 어렵게 만든다.

• 결과를 말한다. 버튼을 누르면 정확히 무슨 일이 일어나는지 동사구로 쓴다 — 제출 대신 변경사항 저장, 확인 대신 계정 삭제[SKILL-FRONTEND-DESIGN].
• 확인 대화상자 버튼은 결과를 반복한다. 이 프로젝트를 삭제할까요?라는 대화상자의 버튼은 확인/취소가 아니라 삭제/취소로 쓴다. 예/아니오로 두면 사용자가 방금 읽은 질문을 다시 떠올려야 동의 대상을 알 수 있다[SKILL-BETTER-WRITING].
• 같은 행동은 버튼 → 확인 → 토스트까지 같은 이름을 쓴다. 게시 버튼을 누르면 게시됨 토스트를 띄운다. 버튼은 게시인데 토스트가 발행을 완료했습니다로 바뀌면 같은 행동인지 다시 확인해야 한다[SKILL-FRONTEND-DESIGN].
• 다단계 플로우의 어휘를 한 체계로 고정한다. 진입은 시작하기, 진행은 계속 또는 다음 중 하나만(둘을 같은 플로우에서 섞지 않는다), 종료는 완료처럼 각 단계 역할에 한 단어만 배정하고 프로젝트 전체에서 유지한다[SKILL-BETTER-WRITING].

---

6. 오류 문구 — 프로젝트 계약(내용) / 관찰 후보(어휘)

오류 상태가 존재해야 한다는 요구는 preflight.md §4-1의 상태 완결성 검사가 이미 다룬다. 여기서는 그 오류 문구가 실제로 무엇을 말해야 하는지를 다룬다. 화면에서 문구가 나타나는 위치·타이밍(실시간 검증인지 제출 시인지)·aria-live·포커스 이동 같은 배선은 accessibility.md §6(타이밍·포커스 이동)·§7(상태 알림)이 정본이다.

프로젝트 계약 — 오류 문구는 항상 두 가지를 함께 말한다. 무엇이 잘못됐는지, 그리고 어떻게 고치는지다. 하나만 있으면 사용자는 다음 행동을 스스로 추측해야 한다[SKILL-BETTER-WRITING].

하드 게이트 — 입력 오류가 감지되고 고칠 방법을 알고 있으면 그 방법을 제시해야 한다(WCAG 3.3.3 Error Suggestion, AA)[WCAG-22]. 그 밖의 오류 문구 기준(어휘·톤·비난 주어 회피 등)은 기존대로 프로젝트 계약이다.

관찰 후보 — 어휘 선택. 비난하는 주어를 쓰지 않는다(당신이 잘못 입력했습니다 대신 형식이 올바르지 않습니다처럼 상황을 주어로 둔다). 과한 사과와 느낌표를 쓰지 않는다 — §3의 오류 톤과 같은 이유다.

상황	나쁜 예	좋은 예	왜
필수 입력 누락	오류가 발생했습니다	이메일을 입력해 주세요	무엇이 비었는지 말하지 않음 → 말함
형식 오류	잘못된 값입니다	전화번호는 숫자만 10~11자리로 입력해 주세요	고치는 법이 없음 → 있음
저장 실패	죄송합니다ㅠㅠ 문제가 생겼어요!	저장하지 못했습니다. 다시 시도해 주세요	과한 사과·느낌표 → 담백하게, 다음 행동 제시

같은 오류가 반복해서 발생한다면 문구를 더 다듬기보다 왜 반복되는지(입력 제약, 폼 흐름)를 4단계 인터랙션 설계에서 다시 본다. 이 문서는 문구 내용만 다루며, 인터랙션 재설계는 이 문서의 범위 밖이다.

---

7. 빈 상태 — 프로젝트 계약(내용) / 관찰 후보(어휘)

프로젝트 계약 — 빈 상태는 세 가지를 한 번에 말한다. 무엇이 비었는지(정체성), 왜 비었는지, 다음에 무엇을 할 수 있는지다. 항목이 없습니다 한 줄만 있으면 사용자는 이 화면이 고장인지 정상인지부터 판단해야 한다[SKILL-BETTER-WRITING].

관찰 후보 — 검색·필터 빈 상태는 사용자가 입력한 조건을 그대로 보여준다. 검색 결과가 없습니다보다 '디자인'에 대한 검색 결과가 없습니다가 사용자의 입력을 그대로 확인해 주고, 이어서 탈출구(필터 초기화, 다른 검색어 제안)를 함께 둔다.

상황	나쁜 예	좋은 예
첫 사용, 데이터 없음	항목이 없습니다	아직 등록한 프로젝트가 없습니다. 새 프로젝트를 만들어 보세요
검색 결과 없음	검색 결과가 없습니다	'디자인'에 대한 검색 결과가 없습니다. 다른 검색어를 시도하거나 필터를 초기화해 보세요
필터로 전부 걸러짐	결과 없음	적용한 필터와 일치하는 항목이 없습니다. 필터 초기화

도움말 링크 같은 지속적인 정보를 빈 상태에만 있게 두지 않는다 — 데이터가 채워진 뒤에도 같은 도움말을 찾을 수 있어야 한다.

---

8. 평이한 말·기기 동사·독자 지칭·내부 용어 — 관찰 후보

• 독자의 어휘로 쓴다. 일반 사용자 제품은 시스템 구현 방식이 아니라 사용자가 실제로 하는 일로 이름 붙인다 — webhook이 아니라 알림, payload가 아니라 보낸 내용. 개발자·전문가가 독자인 제품은 업계 표준 용어를 그대로 쓴다 — 개발자 도구에서 webhook·API 키·payload는 정확한 도메인 용어이고, 풀어 쓰면 오히려 무엇인지 알 수 없다. 독자가 누구인지는 브리프에서 정한다. 이 검사는 antipatterns.md §6(진단)·§9(grep)의 내부 구현 용어 grep 후보(webhook·config·payload·schema)와 같은 검사이며, 여기서는 화면에 노출되는 모든 라벨·설정 이름에 같은 기준을 적용한다[SKILL-FRONTEND-DESIGN].
• 입력 방식에 맞는 동사를 쓴다. 터치 인터페이스 안내에 클릭을, 마우스 중심 안내에 탭을 쓰지 않는다. 입력 방식을 특정할 수 없는 라벨(아이콘 버튼 등)은 동사 없는 명사형도 대안이다[SKILL-BETTER-WRITING].
• 독자 지칭과 소유격을 절제한다. 안내문은 한국어의 주어 생략을 살려 -하세요체로 직접 쓰는 편이 자연스럽다. 오류 문구에서 저희가·우리가 같은 서비스 쪽 주어를 남용하지 않는다(§6의 불러오지 못했습니다처럼 상황 주어가 더 담백하다). 소유격도 필요할 때만 쓴다 — 내 즐겨찾기가 다른 사용자의 즐겨찾기와 헷갈릴 우려가 없으면 즐겨찾기로 충분하다[SKILL-BETTER-WRITING].
• 특정 집단을 전제하는 표현을 쓰지 않는다. 성별·연령 등을 전제한 예시 문구나 관용구는 다른 독자를 배제할 수 있다.

---

9. 문장 조각 조립 금지와 한국어 조사 처리 — 관찰 후보

관찰 후보(엔지니어링 관행). 변수 주변에 고정 문구를 이어 붙여 문장을 조립하지 않는다. ${count} 개의 항목이 삭제되었습니다처럼 숫자·이름 앞뒤에 고정된 조각을 붙이는 방식은 그 변수가 조사·복수형·문장 구조에 영향을 주는 언어에서 깨지기 쉽다[SKILL-BETTER-WRITING]. 완성된 문장을 통째로 템플릿화하거나, 조사가 필요 없는 문장 구조로 바꾼다.

한국어에서는 조사(을/를, 이/가, 은/는, 으로/로)가 변수의 마지막 글자 받침 유무에 따라 갈린다는 문제가 하나 더 있다. 완성형 한글 음절(유니코드 U+AC00~U+D7A3, 11,172자)은 마지막 글자의 코드값에서 0xAC00을 뺀 값을 28로 나눈 나머지가 0이면 받침이 없다.

// 받침 유무로 조사 짝을 고른다
function hasBatchim(syllable) {
  const code = syllable.charCodeAt(syllable.length - 1) - 0xAC00;
  if (code < 0 || code > 11171) return null; // 완성형 한글 음절이 아님(로마자·숫자 등)
  return code % 28 !== 0;
}

function pickJosa(word, withBatchim, withoutBatchim) {
  const has = hasBatchim(word);
  if (has === null) return null; // 판별 불가 — 아래 재구성 대안을 쓴다
  return has ? withBatchim : withoutBatchim;
}

// "${name}을(를) 삭제했습니다" 대신
const josa = pickJosa(name, '을', '를');
`${name}${josa} 삭제했습니다`

로마자·숫자로 끝나는 변수는 코드로 판별할 수 없다. iPhone, 3번 처럼 완성형 한글 음절이 아닌 문자로 끝나면 받침 여부가 발음마다 갈려 규칙 하나로 못 맞힌다. 이런 값이 들어갈 자리는 조사가 아예 필요 없도록 문장을 다시 짠다 — 예: ${name}${josa} 삭제했습니다 대신 ${name} 항목을 삭제했습니다처럼 조사 앞에 고정 명사(항목)를 끼워 받침 문제를 피한다.

---

10. 토글 라벨·링크 텍스트·placeholder

10-1. 토글 라벨 — 관찰 후보

토글은 켜졌을 때 일어나는 일을 기준으로 라벨링한다. 알림 끄기라는 라벨의 토글을 껐을 때 알림을 받는 상태가 되면(이중 부정), 사용자는 지금 상태가 무엇인지 헷갈린다. 알림 받기로 쓰고 켜진 상태 = 알림을 받는 상태로 맞춘다[SKILL-BETTER-WRITING].

10-2. 링크 텍스트

하드 게이트 — 링크의 목적은 링크 텍스트만으로, 또는 텍스트와 프로그램적으로 결정 가능한 맥락을 합쳐서 알 수 있어야 한다[WCAG-LINK].

관찰 후보 — 스크린리더의 링크 목록 탐색 모드는 맥락 없이 링크 텍스트만 순서대로 읽으므로, 그런 상황에서도 통하도록 목적어를 넣는다 — 더보기 단독 대신 가격표 보기[SKILL-BETTER-WRITING]. 한 화면에 더보기 링크가 여러 개면 각각 접미사로 구분한다(사례 더보기, 요금제 더보기).

링크 텍스트가 목적지를 말하는지는 preflight.md C5가 판정한다 — 이 절은 그 링크의 문구 작성법만 더한다.

10-3. placeholder는 라벨이 아니다 — 하드 게이트

모든 입력에는 보이는 <label>이 있어야 하고, placeholder는 그 label을 대신할 수 없다. 이 요건의 정본은 accessibility.md와 preflight.md §1이다. 이 문서가 더하는 내용은 카피뿐이다 — placeholder에는 예상 형식의 예시만 넣는다(010-1234-5678처럼 전화번호 형식 예시). 실제로 입력해야 할 값이나 지시문을 placeholder에만 넣지 않는다.

10-4. 아이콘 버튼의 라벨과 접근 가능한 이름 일치 — 하드 게이트

아이콘+텍스트 버튼에서 화면에 보이는 문구와 별도로 aria-label을 새로 지어 붙이면, 보이는 텍스트가 접근 가능한 이름 안에 포함되어야 한다 — 음성 입력 사용자가 화면에서 읽은 말을 그대로 불러 조작할 수 있어야 한다[WCAG-LABEL-NAME]. 아이콘 전용 버튼의 이름을 어떻게 배선하는지(aria-label vs 시각적으로 숨긴 텍스트)는 accessibility.md와 icons.md §8이 정본이다.

---

11. 문장 부호 — 관찰 후보

한국어 문장 부호는 2014년 12월 개정, 2015년 1월 시행된 한글 맞춤법 규정을 따른다. 마침표·물음표·느낌표·쉼표·가운뎃점·쌍점·빗금·따옴표(2종)·괄호(3종)·낫표(2종)·화살괄호(2종)·줄표·붙임표·물결표·드러냄표·숨김표·빠짐표·줄임표 등 약 20개 범주로 규정돼 있다[KO-PUNCT]. 개별 부호의 세부 적용 범위(가운뎃점의 정확한 용법, 따옴표 종류별 우선순위 등)는 이번 조사에서 1차 출처로 확인하지 못했다 — 세부 판정이 필요하면 국립국어원 어문 규정 원문을 프로젝트에서 직접 재확인한다.

제목·라벨에서 가운뎃점·em dash를 남용하는 구체적 지문은 이 문서가 아니라 antipatterns.md §4·§6이 맡는다(중복 규정하지 않는다). 이 문서가 더하는 것은 상태 문구 관행뿐이다.

• 진행 중 상태는 줄임표로 표시할 수 있다(저장 중…, 불러오는 중…). 스피너·프로그레스 표시와 함께 써도 된다.
• 물음표·느낌표는 §3의 톤과 위험 수위를 넘지 않는 범위에서만 쓴다. 오류·파괴적 확인에는 느낌표를 쓰지 않는다(§6과 같은 이유).

11-1. 숫자·단위·금액·날짜 표기 — 프로젝트 계약(한 프로젝트 안에서 하나로 통일)

typography.md가 값과 단위 표기의 정본으로 이 절을 가리킨다. 아래는 한국어 UI의 시작값이다. 프로젝트에 이미 표기 규칙이 있으면 그것을 따르고, 어느 쪽이든 design.md에 한 줄로 고정한다.

항목	시작값	비고
숫자 + 한글 단위	붙여 쓴다: 3개, 10명, 2시간	단위 명사는 원칙상 띄어 쓰지만 아라비아 숫자와 함께 쓰면 붙여 쓸 수 있다(한글 맞춤법 제43항). UI에서는 붙여 쓰기가 관행이다
숫자 + 단위 기호	10kg, 25%, 3.5GB 붙여 쓰기가 한국 UI 관행	과학·기술 문서처럼 SI 표기를 따르는 맥락이면 10 kg으로 띄운다. 섞지 않는다
금액	12,000원(세 자리 쉼표 + 원 뒤붙임)	₩12,000은 좁은 표·다국어 화면에서만. 큰 금액 요약은 1.2만 원, 3억 2,000만 원처럼 만 단위로 끊는다. 정확한 값이 필요한 곳(결제·영수증)에서는 축약하지 않는다
날짜	2026. 10. 1.(숫자 뒤 마침표, 마침표 뒤 띄움, 끝의 마침표 포함) 또는 2026년 10월 1일	둘 중 하나로 통일. 표·목록처럼 좁은 곳은 숫자형, 문장 안은 글자형이 읽기 쉽다. 요일은 (수)
시간	오후 3:30 또는 15:30	하나로 통일. 상대 시간(3분 전)은 24시간 안에서만 쓰고 정확한 시각을 툴팁·상세로 함께 둔다
범위	10~20개, 10월 1일~3일	물결표를 붙여 쓴다
가운뎃점	짝을 이루는 어구를 묶을 때(시·도, 읽기·쓰기)	제목·라벨에서 남용하는 지문은 antipatterns.md가 맡는다

코드로 만든다. 금액·날짜·상대 시간·복수형은 손으로 문자열을 조립하지 않고 Intl.NumberFormat('ko-KR', { style: 'currency', currency: 'KRW' }), Intl.DateTimeFormat, Intl.RelativeTimeFormat, Intl.PluralRules(영어 등 복수형이 있는 언어)로 만든다. 로케일이 바뀌어도 표기가 따라온다. Intl 기본 출력이 위 표와 다르면(예: ₩12,000) 프로젝트 규칙에 맞게 감싸는 함수 하나를 두고 모든 화면이 그것을 쓴다.

---

12. 라틴 문자 UI의 대소문자 정책 — 관찰 후보

언제: 프로젝트 UI에 영문 라벨이 있을 때 연다. 한국어는 대소문자 구분이 없어 이 절이 적용되지 않는다.

버튼·메뉴·제목 같은 요소 유형별로 타이틀 케이스(Save Changes)와 문장체(Save changes) 중 하나를 정해 그 유형 전체에서 통일한다. 같은 유형 안에서 섞이면(Save Changes 버튼 옆에 Discard changes 버튼) 비일관으로 읽힌다. 확신이 안 서면 문장체가 더 안전한 시작값이다[SKILL-BETTER-WRITING]. 군더더기 없는 평이한 동사와 문장체 톤을 기본으로 한다는 원칙도 같은 방향이다[SKILL-FRONTEND-DESIGN].

---

13. 사례 — 토스 글쓰기 원칙

토스 기술 블로그가 공개한 글쓰기 원칙은 핵심 가치 5가지(Clear·Concise·Casual·Respect·Emotional)와 실행 원칙 8가지로 구성된다[KO-TOSS-WRITING]. 예를 들어 Clear는 단어의 의미가 모호하지 않고 한 번에 이해되는 문장인지 점검하는 것이고, Casual은 금융·IT 업계에서 쓰던 어려운 용어와 딱딱한 뉘앙스를 쉽고 친절하게 고쳐 쓰는 것이다.

이 사례는 한 회사가 실제로 공개한 원칙의 예시이지, 모든 프로젝트가 그대로 따라야 할 규범이 아니다. 공공기관·의료·B2B처럼 브리프의 톤이 다르면 그대로 옮기지 않는다. §1의 원칙대로, 새 프로젝트의 어투는 그 프로젝트의 브리프와 기존 카피에서 먼저 확인한다.

---

13-b. 헤드라인 후보는 화법을 바꿔 비교한다 — 관찰 후보

브랜드·마케팅 헤드라인을 쓸 때 첫 문장을 그대로 채택하지 않는다.

1. 후보를 5개 쓴다.
2. 그중 서로 다른 화법 3종을 고른다 — 사실(무엇을 하는가, 숫자·대상이 있는 문장), 명령(독자가 할 행동), 장면(독자가 겪는 순간 하나).
3. 각 후보에 "경쟁사 이름으로 바꿔도 성립하는가"를 묻는다. 성립하면 버린다(반사실 검사, antipatterns.md §6).
4. 채택한 후보와 채택 이유 한 줄을 design.md에 적는다.

메타 서술을 쓰지 않는다. "이 페이지는 ~를 보여 줍니다", "~하는 방식을 살펴볼 수 있습니다"처럼 페이지가 자기 자신을 설명하는 문장은 브랜드의 목소리가 아니다. 브랜드는 자기 페이지를 해설하지 않고 대상에 대해 말한다. 시안이 가상이라는 고지도 히어로 헤드라인·본문에 넣지 않는다 — 고지 위치는 trustworthy-showcases.md를 따른다.

13-c. 마케팅·브랜드 카피 — 번역체·과장 걷어내기 — 프로젝트 계약

히어로 표제, 섹션 제목, 소개 문단처럼 브랜드가 방문자에게 직접 거는 문장에 적용한다. 실측 사고: 쇼케이스 페이지를 돌려 읽은 사용자가 "다 영어 번역체와 쓸데없이 너무 이상한 카피, 중2병 같은 게 많다"고 지적했다. 시각이 아무리 정교해도 표제 한 줄이 번역 소설처럼 읽히면 페이지 전체가 AI 결과물로 읽힌다.

이 절은 한국어 문장 자체의 결함(번역체·과장·감성 어휘 반복)의 정본이다. 경쟁사 이름으로 바꿔도 성립하는지(차별성)는 antipatterns.md §6, 후보를 화법별로 비교하는 절차는 §13-b, 한 회사의 어투 원칙 사례는 §13이 맡는다. 순서는 이렇다 — §13-b로 후보를 만들고, 이 절의 지문으로 걸러내고, antipatterns §6 치환 검사로 차별성을 확인한다.

목표. 실제 한국 회사·가게 사이트에 그대로 걸려도 어색하지 않은 문장. 읽는 사람이 3초 안에 무엇을, 누구에게, 왜 좋은지를 안다. 멋은 디자인이 내고, 문장은 정확하고 담백하게 쓴다.

13-c-1. 걷어낼 지문

지문	알아보는 법	나쁜 예	고친 예
무생물 주어 + 사람 동사	도시·빛·공간·데이터가 묻고, 말하고, 기억하고, 이야기한다	28개 도시가 10초마다 묻는다 (모니터링 SaaS)	전 세계 28개 지점에서 10초마다 서버 상태를 확인합니다
		빛이 먼저 말을 건다 (안경원)	렌즈 굴절 검사부터 착용 조정까지 한 시간이면 끝납니다
명사로 끝나는 수수께끼 표제	~하는 각도, ~하는 온도, ~의 결, ~라는 시간으로 끝나고 무엇을 파는지 안 나온다	흰 빛 한 줄이 색으로 갈라지는 각도 (광학 부품)	분광기용 프리즘과 회절격자를 소량 주문 제작합니다
		아침을 데우는 온도 (카페)	매일 아침 7시, 그날 볶은 원두로 내립니다
선언·잠언형 과장	짧은 단정문이 교훈처럼 끝난다. 침묵이 말한다, 말이 없다, 본질만 남겼다, 우리는 ~를 믿는다	동의는 신호보다 먼저 기록됩니다 (학원 등록)	등록 전에 환불 규정과 개인정보 이용 동의를 한 화면에서 확인합니다
		본질만 남겼습니다 (가구)	원목 다리와 상판, 나사 네 개로 조립합니다
~가 아니라 ~다 대구 남발	한 페이지에 대조 대구가 둘 이상. 첫 대구도 실제 비교 대상이 없으면 결함이다	향은 냄새가 아니라 기억이다 (향 공방)	쑥·백단·침향을 손으로 빚어 30일 말린 선향입니다
영어 직역 구문	~를 통해, ~에 있어서, ~함에 있어, ~되어지다, 가장 ~한 ~ 중 하나, 독자를 부르는 당신의, 여정, 새로운 차원, 재정의	당신의 건강 여정을 재정의합니다 (한의원)	허리·어깨 통증 진료, 평일 저녁 8시까지 예약할 수 있습니다
		데이터를 통해 가장 혁신적인 교육 경험 중 하나를 제공합니다 (온라인 강의)	매주 퀴즈 결과로 다음 주 복습 범위를 정해 드립니다
~를 만나보세요·~를 경험하세요 반복	섹션마다 같은 권유 어미로 끝난다	새로운 위스키의 세계를 만나보세요 (위스키 바)	싱글 캐스크 40종을 잔 단위로 주문할 수 있습니다
감성 어휘 반복	결, 온도, 숨, 여백의 미, 시간을 담다, 머무는, 스미는, 깃든이 한 페이지에 두 번 이상	시간이 깃든 공간, 머무는 숨의 결 (한옥 스테이)	1938년에 지은 한옥, 객실 3개, 조식은 마당에서 냅니다
내용 없는 영문 장식 라벨	THE ARCHIVE, NO. 01 — ESSENCE, CHAPTER ONE처럼 아래 내용과 관계없는 영문 대문자 라벨	NO. 01 — ESSENCE (법률사무소 업무 소개)	업무 분야 (또는 라벨을 지우고 섹션 제목만 둔다)

영문 장식 라벨은 기본 언어 규칙(SKILL.md 핵심 규칙 8)과 같은 방향이다. 브랜드명·제품명처럼 원래 영문인 고유명사는 해당하지 않는다.

13-c-2. 이렇게 쓴다

• 표제는 사실 + 이득. 무엇을 하는 곳·제품인지를 숫자나 구체 명사로 말하고, 그래서 방문자에게 무엇이 좋은지를 붙인다.
• 업종 관례 어휘를 쓴다. 카페는 원두·로스팅·영업시간, 클리닉은 진료 과목·예약, SaaS는 요금·연동·도입 사례, 학원은 반 편성·수강료·시간표. 방문자가 검색창에 칠 단어가 표제와 소제목에 있어야 한다.
• 자연스러운 한국어 어순. 주어를 사람이나 회사로 두거나 생략한다. 조사를 정확히 쓰고, 존댓말 어미는 하나로 통일한다(§4).
• 개성은 구체성에서 낸다. 실제 공정, 장소, 사람, 숫자, 고유명사가 개성이다. 형용사와 은유로 내지 않는다.
• 은유는 한 페이지에 한 곳까지. 브랜드 슬로건 하나 정도만 허용하고, 나머지 표제·섹션 제목·소개 문단은 정보 문장으로 쓴다. 은유를 쓴 자리 바로 아래에는 그 은유를 풀어 주는 사실 문장을 둔다.

13-c-3. 두 가지 읽기 검사

1. 소리 내어 읽기. 표제·히어로 문단·섹션 제목을 소리 내어 읽는다. 번역 소설처럼 들리거나, 낭독하기 민망하면 고친다.
2. 그 업종 사장님 검사. "이 가게·회사 대표가 손님에게 이 말을 직접 하겠는가"를 묻는다. 카페 사장님은 "아침을 데우는 온도"라고 하지 않고 "7시에 엽니다"라고 한다.

grep 후보(문맥 확인 필요, 검출 자체는 실패가 아니다).

를 통해|에 있어서|함에 있어|되어지|중 하나|당신의|여정|재정의|새로운 차원
만나보세요|경험하세요
결$|온도$|숨$|머무는|스미는|깃든|여백의 미|시간을 담
가 아니라|이 아니라

같은 후보가 한 페이지에서 두 번 이상 걸리면 반복 지문으로 본다. 판정은 critique.md §2-1 R7(카피 목소리)이 하고, 0점이면 Direction(D6)이다.

---

14. 검증

카피 findings는 1차로 소스(코드·design.md) 대조만으로 판정할 수 있다 — 용어 일관성(§2), 버튼 동사(§5), 오류·빈 상태 문구 내용(§6·§7)은 렌더를 새로 켜지 않아도 확인 가능하다[SKILL-BETTER-WRITING]. 다만 잘림·줄바꿈의 영향을 받는 카피(버튼 라벨, 제목, 좁은 카드 안 문구)는 소스만으로 판정하지 않는다 — 실제 렌더에서 줄바꿈·말줄임(text-overflow: ellipsis)·좁은 폭 재배치를 확인한다.

카피 결함에도 별도 심각도 체계를 두지 않는다. 이 문서 각 절에 붙은 하드 게이트/프로젝트 계약/관찰 후보 라벨을 그대로 finding의 위계로 쓴다 — 예: 링크 텍스트 위반(§10-2)은 하드 게이트, 오류 문구에 수정법이 없는 것(§6)은 프로젝트 계약, 어휘 선택(비난 주어, 과한 사과)은 관찰 후보다.

---

15. 체크리스트 (구현 중 자기 점검 — 납품 판정은 preflight.md X7)

납품 판정은 preflight.md X7이 하고, 링크 텍스트의 목적지는 C5, placeholder와 라벨은 A5, 아이콘 버튼 이름은 A11이 판정한다.

• 숫자·단위·금액·날짜 표기를 §11-1 표의 한 방식으로 통일했고 design.md에 적었다
• 헤드라인이 메타 서술("이 페이지는 ~를 보여 줍니다")이 아니다. 후보를 화법별로 비교했다(§13-b)
• 히어로 표제·섹션 제목·소개 문단을 소리 내어 읽었고, 번역체·잠언형 과장·감성 어휘 반복·영문 장식 라벨이 없다. 은유는 페이지에 한 곳까지다(§13-c)
• 새 카피를 쓰기 전에 기존 화면·design.md의 용어를 확인했다(§1)
• 같은 개념을 화면마다 다른 말로 부르지 않는다 — grep으로 소수파 표현을 찾아 통일했다(§2)
• 일상·주의·파괴·오류·금전 상황의 톤 강도가 다르다(§3)
• 한 화면·한 제품 안에서 해요체·합니다체가 섞이지 않는다(§4)
• 버튼 라벨이 동사형이고 결과를 말한다. 파괴적 확인 버튼은 결과를 반복한다(§5)
• 같은 행동이 버튼 → 확인 → 토스트까지 같은 이름을 쓴다(§5)
• 오류 문구가 무엇이 잘못됐는지와 어떻게 고치는지를 함께 말한다. 비난·과한 사과·느낌표가 없다(§6)
• 빈 상태가 정체성·이유·다음 행동을 말한다. 검색 빈 상태는 입력한 조건을 보여준다(§7)
• 내부 구현 용어(webhook·config·payload·schema)가 사용자 라벨로 새지 않았다(§8)
• 변수 주변에 문장 조각을 조립하지 않았다. 조사가 필요한 자리는 받침 판별 또는 문장 재구성으로 처리했다(§9)
• 토글 라벨이 켜진 상태를 기준으로 쓰였다(§10-1)
• 영문 라벨이 있다면 요소 유형별로 대소문자 정책이 통일돼 있다(§12)
• 잘림·줄바꿈에 영향받는 카피(버튼·제목·좁은 카드)는 실제 렌더로 확인했다(§14)

---

16. 실제 값이 아직 없을 때 — placeholder 규약 — 프로젝트 계약

동네 가게나 새 제품의 사이트는 상호·주소·가격·시간표·사람 이름이 전부 사용자만 아는 값이다. 사용자가 "아직 없다"고 하면 두 가지 실패가 나온다: 중괄호 토큰이 날것으로 찍힌 납품물, 또는 그럴듯하게 지어낸 수업명과 강사 약력. 둘 다 막는다.

1. 무엇이 placeholder인가. 사용자만 아는 사실 전부다 — 상호, 사람 이름, 주소·연락처, 가격, 시간표, 수업·상품 이름, 후기, 수치. 문장으로 된 사실(강사 약력, 연혁)도 같다. 그럴듯하게 지어내지 않는다(SKILL.md 하드 게이트 7).
2. 무엇은 써도 되나. 업종에서 누구에게나 참인 설명(필라테스가 무엇인지), 행동 안내(예약 방법의 틀), 섹션 제목·버튼 라벨. 사용자가 준 말에서 벗어나는 주장은 쓰지 않는다.
3. 화면에서의 모양. 자리의 뜻이 읽히는 대괄호 표기([스튜디오 이름], [1회 체험 가격])를 실제 서체·크기로 넣고, 한 가지 표식(예: 점선 밑줄)을 토큰으로 정해 전부에 똑같이 준다. 표기는 사이트 기본 언어로 쓴다. 길이는 실제 값의 예상 길이에 맞춘다 — 짧은 자리표시로 맞춘 레이아웃은 실제 값에서 깨진다.
4. 코드에서의 모양. 값은 한 곳(콘텐츠 파일이나 페이지 머리의 상수 블록)에 모으고 마크업은 거기서 읽는다. 사용자가 한 곳만 고치면 되게 한다.
5. 목록. design.md 미확정 절과 납품 보고의 "정해 주셔야 할 것"에 placeholder를 전부 나열한다(이름 · 어디에 보이는지).
6. 빠지면 구조가 무너지는 자리(후기 섹션, 강사 소개)는 placeholder로 채우지 말고 섹션을 뺀 뒤 "값을 주시면 넣을 자리"로 보고한다(하드 게이트 7의 (c)).