미리캔버스 UX Writing 원칙

개요

원문을 어떻게 쓸 것인가를 정하는 원칙이다. 번역된 값의 표기는 「번역 String 값 표기 규칙」이, 영어 문법은 「현지화 스타일 가이드」가 다룬다. 관리 주체는 프로덕트그룹과 UI스쿼드이며, PD팀 검토가 2026-01-23 에 끝났다.

적용 범위

축	적용 / 제약
대상	신규 또는 기존 String 값을 직접 쓰거나 AI 로 작성·리뷰할 때
환경	전 화면
언어	원문 작성 단계

활용 방법

상황	방법	효과
문구를 작성할 때	「이 문구가 우리 원칙에 맞나」를 빠르게 확인한다. AI 로 생성하거나 초안을 쓸 때도 원칙을 프롬프트와 검토 기준으로 쓴다	생성과 수정 비용이 줄어든다
리뷰할 때	개인 취향(좋다·별로다) 대신 원칙을 기준으로 피드백한다. 「왜 바꿔야 하는지」를 원칙으로 설명할 수 있다	리뷰 효율이 오른다
논쟁이 생길 때	더 말을 잘하는 사람의 안이 아니라 원칙에 더 가까운 안을 선택한다	합의 기준이 생겨 정렬 비용이 줄어든다

상세 내용

1. 명확성 우선 (Clarity First)

사용자가 의미를 해석 없이 이해하게 한다.

작성 규칙

• 한 문장은 하나의 메시지 또는 하나의 행동만 전달한다.
• 모호한 표현 대신 구체적이고 측정 가능한 단어를 쓴다.
• 은유·유행어·과도한 수식어를 쓰지 않는다.
• 짧아서 오해되는 문장보다, 한 단어 더 써서 이해되는 문장을 고른다.
• 긴 설명이 필요하면 핵심 요약과 자세히 보기로 분리한다.

배경: 해석 비용은 곧 UX 마찰이다. 비전문 사용자일수록 추론에 더 취약하다. 명확성은 브랜드 톤보다 우선한다.

나쁜 예	좋은 예
한 단계 더 멋지게	레이아웃을 정렬하세요
완성도를 높여보세요	색상을 통일하세요
조금만 더 손봐볼까요?	텍스트 크기를 조정하세요

예외: 성공과 완료 상태에서 제한적인 감정 표현은 허용한다.

리뷰 체크리스트: 설명 없이 바로 이해되는가?

2. 행동 기준 명시 (Action is Explicit)

사용자가 다음에 무엇을 해야 하는지를 알려야 한다.

작성 규칙

• 안내 문장에는 다음 행동의 단서를 포함한다.
• 버튼·링크·레이블은 행동을 나타내는 동사성 명사로 쓴다. 동사성 명사란 명사 형태지만 「~하다」를 붙이면 자연스럽게 동사가 되는 말이다.
• 결과만 설명하고 행동을 제시하지 않는 문장은 피한다.
• 여러 선택지가 있으면 우선 행동을 명확히 한다.
• 행동만으로 불명확하면 대상 한 단어를 보강한다.

배경: 행동이 보이지 않으면 사용자는 멈춘다. 글로벌 사용자에게 암시는 충분하지 않다.

나쁜 예	좋은 예
저장이 완료되었습니다	저장이 완료되었습니다. 다운로드하세요
변경 사항이 있습니다	변경 사항을 확인하고 적용하세요
편집이 가능합니다	편집을 시작하세요

3. 목적 중심 서술 (User Goal Oriented)

기능이 아니라, 이 화면에서 사용자가 달성하려는 목적을 먼저 드러낸다.

작성 규칙

• 기능 설명보다 사용자의 결과를 먼저 표현한다.
• 「무엇을 할 수 있는가」보다 「무엇이 달라지는가」를 말한다.
• 시스템 관점의 표현을 사용자 관점으로 전환한다.

배경: 비전문 사용자는 기능 목록보다 결과에 반응한다. 목적 중심 언어는 학습 비용을 줄인다.

나쁜 예	좋은 예
템플릿을 선택할 수 있습니다	이 템플릿으로 디자인을 시작하세요
공유 설정을 변경할 수 있습니다	다른 사람과 디자인을 공유하세요
텍스트 편집 기능을 제공합니다	문구를 원하는 내용으로 바꾸세요

예외: 설정과 관리 화면에서 기능 나열이 필요한 경우다.

리뷰 체크리스트: 사용자 목적이 먼저 보이는가?

4. 화자 일관성 유지 (Consistent System Voice)

제품은 하나의 일관된 화자로 말한다.

작성 규칙

• 동일한 상황에서는 동일한 말투와 문장 구조를 유지한다.
• 기술과 내부 관점의 표현을 사용자 언어로 바꾼다.
• 권위적이거나 과도하게 감정적인 표현을 피한다.

배경: 화자 일관성은 신뢰와 몰입을 만든다. 화면마다 다른 화자는 제품 이해를 방해한다.

나쁜 예	좋은 예
「파일 생성 완료」 / 「이제 시작해볼까요?」	파일이 생성되었습니다. 작업을 시작하세요
「파일 오류 발생」 / 「앗, 문제가 생겼어요」	파일을 불러올 수 없습니다. 다시 시도하세요
「업로드 성공」 / 「이제 한번 만들어볼까요?」	업로드되었습니다. 디자인을 시작하세요

예외: 온보딩과 튜토리얼에서의 제한적인 친절한 톤이다.

리뷰 체크리스트: 같은 제품이 말하는 것처럼 느껴지는가?

5. 용어 체계화 (Terminology Discipline)

같은 개념은 항상 같은 용어로 표현한다.

작성 규칙

• 동일한 개념에는 하나의 표준 용어를 쓴다.
• 유사한 용어의 혼용을 금지하거나, 정의한 뒤 명확히 구분한다.
• 전문 용어는 최소화하고 첫 노출 시 맥락을 제공한다.
• 선택지와 옵션은 평행 구조로 쓴다. 평행 구조란 여러 선택지를 나열할 때 모든 옵션을 같은 형식·같은 문법·같은 관점으로 쓰는 것이다.

배경: 용어 혼용은 인지 부하를 높인다. 검색·도움말·번역의 정합성에 직접 영향을 준다. 원문에서 구분한 개념이 번역에서 한 단어로 합쳐지면 그 화면에서만 구분이 사라진다.

같은 개념은 하나로 고정한다

Log in·Sign in / 전체 보기·모두 보기 / 만들기·제작하기 / 다시 시도·재시도 는 각각 하나로 고정한다. 「페이지 삭제」와 「슬라이드 제거」가 같은 동작이면 「페이지 삭제」로 통일한다.

다른 개념은 다른 용어로 구분한다

• 팝업을 닫는 버튼과 작업을 끝내는 버튼은 「닫기」와 「종료」로 구분한다.
• 목록에서 빼는 동작과 영구 삭제하는 동작은 「제거」와 「삭제」로 구분한다. 복구 가능 여부가 다르므로 같은 말로 쓰면 사용자가 되돌릴 수 있는지 판단할 수 없다.

선택지는 평행 구조로 쓴다

정렬 드롭다운에 「이름순」·「수정된 날짜」·「생성된 날짜」를 섞어 쓰지 않는다. 「이름순」·「수정일순」·「생성일순」으로 맞춘다.

예외: 법과 정책 영역 등 정확한 구분이 필요한 경우다.

리뷰 체크리스트: 같은 개념을 다른 말로 부르고 있지 않은가?

확인 필요

항목	사유	확인 방법
원칙과 실제 String 값의 정합 여부	원칙은 2026-01-23 에 검토를 마쳤지만, 기존 String 값에 소급 적용했는지는 원문에 없다	현지화 담당자에게 기존 값의 점검 라운드 여부를 확인한다
용어 체계화 원칙과 Glossary 의 연결	「동일 개념에 하나의 표준 용어」를 요구하지만, 그 표준 용어 목록이 어디 있는지 이 문서가 가리키지 않는다	용어 관리 결정 문서의 Google Sheet SSOT 와 연결한다
AI 프롬프트로서의 활용 형태	AI 로 생성하거나 리뷰할 때 원칙을 프롬프트로 쓴다고 하는데, 그 프롬프트가 별도로 관리되는지 불명확하다	UI스쿼드에 프롬프트 템플릿의 존재를 확인한다

관련 문서

대상	경로
번역 String 값 표기 규칙	product-service/miricanvas/string-notation-rule.md
미리캔버스 IA 용어 정의 논의	product-service/miricanvas/ia-terminology.md
에디터 캔버스 2.0 용어 사전	product-service/miricanvas/canvas2-glossary.md
미리디 용어(Glossary) 관리 방법 개선	corporate/work-tools/glossary-management.md