← Design System

Voice

읽히는 방식.

디자인은 보이는 결정 + 읽히는 결정. 이 블로그가 쓰는 톤과 한글·영문 혼용 규칙을 정리.

01 Observer

관찰자의 시점.

"내가 X를 만들었다"보다 "X를 만들다가 Y를 발견했다". 결과보다 과정, 결정보다 관찰을 쓴다. 독자가 같은 길을 따라올 수 있도록.

Do

"색 한 톤을 바꾸려다 결국 토큰 레이어 전체를 다시 정리했습니다."

Don't

"완벽한 디자인 시스템을 구축했습니다."

02 KR + EN

한글 우선, 영문은 단어로.

문장의 뼈대는 한글, 토큰명·라이브러리·기술 용어는 영문. 한글로 음차하지 않는다. "토큰"은 한글, --text-primary는 영문 그대로.

Do

"이전 primary는 #64B5F6로 대비가 부족했습니다."

Don't

"이전 프라이머리는 #64B5F6로 컨트라스트가 부족했습니다."

03 Numbers

수치를 보여준다.

"흐릿했다" 대신 "대비비 2.4:1, AA 기준 4.5:1 미달". 주관 평가 대신 객관 지표. 수치가 곧 결정의 근거가 된다.

Do

"대비비 2.4:1 → 5.2:1로 보강해 WCAG AA 통과."

Don't

"좀 더 잘 보이도록 색을 조정했습니다."

04 Short

한 문장 짧게.

쉼표로 늘어진 문장보다 마침표로 끊은 두 문장. 짧은 문장이 한글에 더 잘 맞고, 모바일에서 더 잘 읽힌다.

Do

"Body weight를 500으로 올렸습니다. 한글이 14~17px에서 또렷해집니다."

Don't

"Body weight를 500으로 올린 결과, 한글이 14~17px 범위에서 더 또렷하게 보이게 됐다는 것을 확인할 수 있었습니다."

05 Code Inline

코드와 산문 사이.

파일 경로, 변수명, 토큰명은 인라인 코드(--font-mono)로. 실행되는 코드는 코드 블록으로. 본문에 hex 값 같은 상수가 등장하면 코드 표기.

Inline code

본문 안에서 var(--text-primary)src/styles/base/_tokens.scss를 지칭.

06 Humor

유머는 한 줄에 한 번.

기술 글이라고 건조하지 않아도 된다. 다만 농담은 한 단락에 한 번 이하 — 신호 대비 잡음이 늘어나면 독자가 정작 중요한 부분을 놓친다.

07 Personal

개인 단수, 결론은 보류.

"우리"보다 "나/제가", "그래야 합니다"보다 "이번엔 그렇게 정했습니다". 한 사람의 경험이라고 명시한다. 단정은 미루고, 다음 버전에 뒤집을 여지를 남긴다.

08 UI Labels

UI 라벨은 짧고 영문 우선.

화면 위 버튼/링크/네비게이션 라벨은 한글 산문과 다른 규칙으로 동작합니다. 짧고 익숙한 영문 동사(Copy, Skip, Detail, On this page)를 우선합니다. 반대로 콘텐츠성 라벨(변경 기록, 함께 보면 좋은)은 한글로.

Do

"Copy", "Skip to main content", "On this page", "Detail →"

Don't

"복사하기", "본문으로 건너뛰기", "현재 페이지에서", "자세히 보기 →"

Policy — 이 페이지가 그 예시

이 페이지의 메타 라벨(Voice, Do, Don't, Policy)이 영문인 이유. UI 시스템 어휘는 짧고 표준화된 코드처럼 다루고, 본문은 한글로 풀어 씁니다. 섹션 번호와 본문은 한글, 분류 태그는 영문 — 둘 다 같은 페이지에서 공존.