거버넌스 — KRDS UX Writing 가이드라인

개요

UX Writing 거버넌스는 "좋은 글쓰기를 위한 조직적 인프라"입니다. 개인의 노력이 아니라 시스템이 일관성을 보장합니다.

#	조건	핵심 목표	주요 담당
①	단일 진실 공급원	마스터 문서 1개 — 부서별 사본 금지	UX Writer PM
②	Figma 컴포넌트 결합	버튼·폼 기본 텍스트를 규칙 예시로 세팅	디자이너 UX Writer
③	Living Glossary	금지어·대체어 DB화, 개발 상태값 동기화	UX Writer 개발
④	UX Writing QA 의무화	배포 전 텍스트 검수 프로세스 강제화	PM UX Writer
⑤	라이팅 자동화 (Linting)	주관 부사·이중 피동 자동 경고 도구	개발 UX Writer
⑥	철학 내재화 교육	규칙 암기 전 "왜" 먼저 — 정기 교육	PM UX Writer

왜 6가지 조건인가? UX Writing 실패의 90%는 나쁜 글쓰기가 아니라 나쁜 운영 구조에서 비롯됩니다. 가이드라인이 문서로만 존재하면, 담당자가 바뀌는 순간 규칙도 사라집니다. 6가지 조건은 사람이 아닌 시스템이 일관성을 유지하도록 만듭니다.

① 단일 진실 공급원 (Single Source of Truth)

UX Writing 기준은 반드시 한 곳에만 존재해야 합니다. 부서마다 "우리 버전"의 가이드라인이 생기면, 조직 전체가 다른 기준으로 글을 씁니다.

🚫 분산 구조 (현실의 함정)

기획팀 가이드라인.xlsx (2023년 버전)
개발팀 UX Writing 정리.notion
디자인팀 Figma 코멘트 모음
마케팅팀 캐치카피 규칙.pptx

✅ 단일 진실 공급원

KRDS UX Writing 가이드라인 (이 사이트)
→ 모든 팀이 이 URL을 기준으로 참조
→ 변경은 이 사이트에만 반영
→ 각 팀은 사본 없이 링크만 공유

운영 규칙

항목	규칙
마스터 문서	이 가이드라인 사이트 1개 — 버전 관리는 GitHub
부서별 사본 금지	팀 내부 문서에 규칙을 복사하지 않음. 필요하면 URL을 링크
변경 권한	UX Writer(초안) → UX Researcher·디자이너 검토 → 배포
변경 이력	git commit 메시지로 추적 — 날짜·이유·담당자 명시
주기적 검토	분기 1회 — 실제 서비스와 가이드라인 간 간극 점검

사본이 생기는 신호: "우리 서비스는 조금 달라서요"라는 말이 나오면 파생 가이드 문제입니다. 기관별 파생 가이드를 참고하여 오버라이드 방식으로 처리하고, 사본은 만들지 않습니다.

② Figma 컴포넌트 결합

디자이너가 버튼 컴포넌트를 가져다 쓰는 순간, 올바른 기본 텍스트가 자동으로 따라와야 합니다. 규칙을 읽지 않아도 규칙이 적용됩니다.

컴포넌트 기본값 세팅 원칙

컴포넌트	🚫 나쁜 기본값	✅ 올바른 기본값
주요 버튼	확인 / Button	[대상 + 동사] 예: 지원금 신청하기
취소 버튼	취소 / Cancel	작성 내용 삭제하기
입력 레이블	이름 / Label	성명 (가장 보편적 명사)
플레이스홀더	입력하세요 / Enter here	하이픈(-) 제외, 숫자만 입력 (예: 01012345678)
오류 메시지	오류가 발생했습니다	[원인] + [해결 방법] 구조
빈 화면	데이터 없음	아직 신청한 [대상]이 없습니다. → [행동] 버튼

Figma 운영 가이드

FIGMA LIBRARY 규칙

컴포넌트 Description 필드 = UX Writing 규칙

Figma 컴포넌트의 Description에 해당 컴포넌트의 UX Writing 규칙 요약과 이 가이드라인 URL을 기재합니다.
디자이너가 컴포넌트를 선택하면 규칙이 바로 보입니다. 별도 문서를 열 필요가 없습니다.

기본값의 힘: 사람은 기본값을 바꾸지 않는 경향이 있습니다 (기본값 편향). 올바른 기본값을 설정하면, 규칙을 가르치지 않아도 대부분의 경우 올바른 텍스트가 나옵니다.

③ Living Glossary (살아있는 용어집)

용어는 살아있습니다. 새로운 행정 용어가 생기고, 금지어가 추가되고, 개발 상태값이 바뀝니다. 용어집은 '문서'가 아니라 '데이터베이스'여야 합니다.

용어집 4대 항목

항목	내용	업데이트 주기
금지어	주관 부사, 과도한 행정어, 이중 피동형 등 사용하면 안 되는 단어	수시 (새 오류 발견 시)
대체어	금지어에 대한 올바른 표현 1~3가지	금지어 등록 시 동시
행정 용어 번역	행정 전문어 → 일상어 매핑 (예: 과오납 → 잘못 낸 돈)	월 1회 또는 신규 용어 등장 시
개발 상태값	API·DB의 status 코드 → 사용자 표시 텍스트 매핑	개발 스프린트마다

🚫 고정된 용어 목록 (죽은 문서)

UX Writing 금지어 목록.xlsx
최종수정: 2024-03-15
담당자가 바뀌면 아무도 업데이트 안 함

✅ 살아있는 용어 DB

GitHub 저장소 또는 Notion 데이터베이스
→ PR로 변경 이력 추적
→ 개발 상태값 코드와 연동
→ 린터 도구가 이 DB를 참조

개발 상태값 연동 예시

API status 값	🚫 나쁜 표시 텍스트	✅ UX Writing 표시 텍스트
`PENDING`	PENDING / 대기중	접수됨 — 담당자가 확인 중입니다
`IN_REVIEW`	검토중	심사 중 (영업일 기준 3~5일 소요)
`SUPPLEMENTAL_REQUIRED`	보완 필요	서류 보완 필요 — [보완 내용 확인하기]
`APPROVED`	승인됨	승인 완료 — [결과 확인하기]
`REJECTED`	반려	반려됨 — 이유를 확인하고 재신청할 수 있습니다

Living Glossary 실패 패턴: 용어집이 특정 담당자의 개인 파일에 있으면 그 사람이 퇴사하는 순간 사라집니다. 반드시 조직이 소유하는 공용 저장소에 관리합니다.

④ UX Writing QA 의무화

개발 QA는 당연하게 여기면서 UX Writing QA는 생략합니다. 배포 전 텍스트 검수는 선택이 아닙니다.

UX Writing QA 체크포인트

시점	검수 항목	담당
디자인 완료 시	버튼 레이블, 폼 레이블, 오류 메시지, 빈 화면 텍스트 — 가이드라인 준수 여부	UX Writer
개발 완료 시	실제 구현된 텍스트가 디자인과 일치하는지, 동적 변수 [대괄호] 표시 정상 여부	개발 UX Writer
배포 직전	최종 스테이징 환경에서 금지어·오타·일관성 체크	PM UX Writer

QA 체크리스트 항목

버튼 레이블이 [목적어+동사형] 구조인가? (예: 신청서 제출하기)
모든 오류 메시지가 [원인 + 해결 방법] 구조인가?
행정 전문어가 일상어로 번역되었는가? (Living Glossary 대조)
주관 부사(빠르게, 이미, 지금, 너무)가 없는가?
이중 피동(~되어졌습니다)이 없는가?
동적 변수가 [대괄호]로 시각 분리되었는가?
빈 화면에 원인과 대안 행동이 있는가?
선택지(체크박스·라디오)가 긍정문인가?
스크린 리더 오독 기호(★ ◆ →)가 없는가?
숫자 단위가 밀착 표기(15,000원, 30일)인가?

QA를 티켓으로 만들어라: UX Writing QA를 "담당자가 알아서"가 아니라 Jira/GitHub 이슈로 트래킹합니다. 배포 전 해결되지 않은 UX Writing 이슈는 P1 버그와 동등하게 취급합니다.

⑤ 라이팅 자동화 (Writing Linter)

코드는 린터가 검사합니다. 텍스트도 같은 원칙을 적용합니다. 사람이 매번 확인하는 것보다 자동화 도구가 더 일관성 있게 오류를 잡습니다.

자동 감지 대상 패턴

오류 유형	감지 패턴 예시	심각도
이중 피동	~되어졌습니다, ~되어집니다, ~하여지다	ERROR
주관 부사	빠르게, 신속히, 이미, 지금 바로, 너무, 매우, 간편하게	ERROR
과도한 존칭	~하시기 바랍니다, ~하여 주시기 바랍니다, 양지하시기 바랍니다	WARN
금지 기호	★, ◆, ●, !!, →→	WARN
단위 분리	15,000 원, 30 일, 10 MB (숫자와 단위 사이 공백)	WARN
행정 전문어	Living Glossary 금지어 목록과 대조	WARN

자동화 도입 방법

옵션 A — 간이 린터 (즉시 시작 가능)

정규식 기반 스크립트

Living Glossary의 금지어 목록을 정규식으로 변환하여, 배포 전 CI/CD 파이프라인에 텍스트 스캔 단계를 추가합니다.
구현 시간: 1~2일. 한국어 형태소 분석 없이도 대부분의 패턴을 감지합니다.

옵션 B — 형태소 분석 기반 (정밀 검사)

KoNLPy 또는 Kiwi 기반 분석

한국어 형태소 분석기를 사용해 더 정밀하게 이중 피동·존칭 패턴을 감지합니다.
구현 시간: 1~2주. 오탐률이 낮고 복잡한 패턴도 감지 가능합니다.

자동화의 한계: 린터는 "확실히 나쁜 것"만 잡습니다. 맥락에 따른 판단(어떤 피동형이 자연스러운지)은 여전히 UX Writer의 몫입니다. 자동화는 사람을 대체하는 것이 아니라, 반복 검수 부담을 줄이는 도구입니다.

⑥ 철학 내재화 교육

규칙을 외우게 하는 교육은 실패합니다. "왜 이렇게 써야 하는가?"를 먼저 이해해야 규칙을 스스로 확장할 수 있습니다.

교육 설계 원칙

🚫 규칙 전달 중심 교육

"버튼에는 목적어+동사 구조를 써야 합니다."
"이중 피동은 금지입니다."
"주관 부사를 쓰지 마세요."
→ 기억에 남지 않고, 새 상황에 적용 불가

✅ 철학 이해 중심 교육

"시민은 버튼을 읽지 않고 클릭합니다.
그렇기 때문에 무엇을 하는지 즉각 알 수 있어야 합니다."
→ 원리를 이해하면 새 컴포넌트에도 스스로 적용

교육 프로그램 구조

구분	대상	내용	주기
온보딩	신규 입사자 전원	KRDS UX Writing 3대 원칙 (왜 이렇게 쓰는가) + 실습 30분	입사 첫 주
정기 세션	개발·디자인·기획 팀	실제 서비스의 Before/After 사례 리뷰 — 월 1회 30분	월 1회
가이드라인 업데이트	전체 팀	규칙이 바뀌거나 추가될 때 변경 이유 공유	변경 시
심층 워크숍	UX Writing 관련 직군	어려운 케이스 토론 — 판단 기준 내재화	분기 1회

교육 효과 측정

Before/After 비율로 측정

교육 전후 실제 서비스의 금지어 밀도, UX Writing QA 이슈 수, 린터 경고 수를 비교합니다.
"얼마나 잘 쓰는가"보다 "금지된 패턴이 얼마나 줄었는가"가 실질적 지표입니다.

최소 교육 단위: 조직의 상황이 어렵다면, 최소한 이것만 합니다. 월 1회 30분, 실제 서비스에서 발견한 나쁜 예시와 개선 사례를 팀 전체가 함께 봅니다. 이것만으로도 인식이 달라집니다.

도입 체크리스트 — 우선순위 순

한 번에 6가지를 모두 할 필요는 없습니다. 영향력이 큰 것부터 순서대로 도입합니다.

우선순위	조건	도입 난이도	영향 범위
1순위	③ Living Glossary 구축	낮음 (스프레드시트로 시작 가능)	즉시 전 팀에 영향
2순위	④ UX Writing QA 의무화	중간 (프로세스 합의 필요)	배포 품질 직접 개선
3순위	① 단일 진실 공급원	낮음 (기존 문서 정리)	장기적 일관성 기반
4순위	② Figma 컴포넌트 결합	중간 (디자이너 협업 필요)	디자인 단계에서 오류 예방
5순위	⑥ 철학 내재화 교육	중간 (콘텐츠 준비 필요)	장기적 조직 역량
6순위	⑤ 라이팅 자동화 (Linting)	높음 (개발 리소스 필요)	반복 검수 비용 절감