마이크로카피는 화면 안의 짧은 글자(버튼·빈 상태·오류·플레이스홀더)로 사용자가 ‘지금 뭘 해야 하지’라고 망설이는 순간을 없애는 일입니다. 버튼은 결과를 동사로, 빈 상태는 다음 행동 안내로, 오류는 비난이 아니라 해결책으로 적으면 같은 화면이 더 잘 작동합니다.
요약
- 버튼은 ‘확인’이 아니라 결과를 동사로 — ‘무료 진단 받기’.
- 빈 상태(empty state)는 막다른 길이 아니라 다음 행동을 안내하는 자리다.
- 오류 메시지는 사용자를 비난하지 말고 ‘어떻게 고치는지’를 적는다.
- 플레이스홀더로 라벨을 대신하지 않는다 — 입력하면 사라져 길을 잃는다.
입사하고 얼마 안 됐을 때, 회원가입 폼에 ‘오류가 발생했습니다’ 한 줄만 띄워두고 다음 일로 넘어간 적이 있습니다. 며칠 뒤 고객센터에서 “가입이 안 된다”는 문의가 줄줄이 들어왔습니다. 사용자는 무엇이 잘못됐는지 몰라서, 같은 버튼을 누르고 또 눌렀던 겁니다. 사실 이메일에 @가 빠졌을 뿐이었어요. 그날 이후로 저는 화면의 짧은 글자 하나가 ‘설명’이 아니라 ‘안내’가 되어야 한다고 믿게 됐습니다.
마이크로카피가 대체 뭔가요?
화면에서 본문이 아닌, 짧게 박힌 글자들입니다. 버튼 안의 두세 글자, 입력칸 위의 라벨, 아무것도 없을 때 뜨는 ‘데이터 없음’, 빨갛게 뜨는 오류 한 줄. 길이는 짧지만, 사용자가 다음 행동을 할지 말지를 결정하는 건 대부분 이 글자들입니다. 디자인이 아무리 예뻐도 여기서 막히면 사람은 그냥 나갑니다.
왜 같은 화면이 문구만으로 달라지나요?
설명보다 빠릅니다. 아래는 같은 컴포넌트입니다. ‘나쁜 카피 / 좋은 카피’ 버튼만 눌러보세요. 화면은 그대로인데 글자만 바뀝니다.
같은 화면, 문구만 바꿨습니다
'나쁜 카피 / 좋은 카피'를 눌러 같은 컴포넌트의 문구가 어떻게 바뀌는지 보세요.
같은 픽셀, 같은 레이아웃입니다. 바뀐 건 글자뿐인데, ‘좋은 카피’ 쪽은 사용자가 지금 무엇을 하면 되는지 한 번에 압니다. 제가 일하는 건 대부분 이 차이를 만드는 일입니다.
이 일을 하면서 제 머릿속에 박아 둔 문장이 하나 있어요.
사용자는 디자인 앞에서 멈추지 않습니다. 글자 앞에서 멈춥니다.
버튼에는 뭘 적어야 하나요?
버튼은 ‘동작 이름’이 아니라 ‘결과’를 적습니다. ‘확인’, ‘제출’, ‘전송’은 사용자가 누르면 무슨 일이 생기는지 말해주지 않습니다. 대신 ‘무료 진단 받기’, ‘견적 신청하기’, ‘예약 확정하기’처럼 누르면 얻는 것을 동사로 적습니다. 폼 위쪽 헤드라인이 약속이라면, 버튼은 그 약속의 마지막 한 줄입니다. 둘의 말투가 따로 놀면 사용자는 마지막 순간에 손을 멈춥니다.
빈 화면(empty state)은 왜 중요한가요?
‘데이터 없음’은 막다른 길입니다. 그런데 사용자가 처음 서비스에 들어와 가장 먼저 보는 게 바로 이 빈 화면인 경우가 많습니다. 저는 빈 화면을 ‘기회’로 봅니다. ‘아직 등록한 현장이 없어요. 첫 현장을 추가해 볼까요?’처럼, 지금 할 수 있는 한 가지 행동을 제안하면 빈 화면이 온보딩 화면으로 바뀝니다. 텅 빈 표 하나가 사용자를 떠나게 할 수도, 첫 클릭을 만들 수도 있습니다.
오류 메시지는 어떻게 쓰나요?
제가 가장 오래 다듬는 게 오류 메시지입니다. 원칙은 하나예요. 비난하지 말고 해결책을 준다. ‘오류가 발생했습니다’는 사용자에게 ‘네가 뭔가 잘못했어’라고 들리지만, 정작 무엇을 어떻게 고칠지는 알려주지 않습니다. ‘이메일에 @가 빠진 것 같아요. 다시 확인해 주세요’는 원인과 해결책을 같이 줍니다. 오류는 사용자가 실수한 순간이 아니라, 우리가 도와줄 수 있는 순간입니다.
제 책상 위 오류 메시지는 늘 이 두 가지로 갈립니다. 사용자를 세워 두는 말이냐, 다음 칸으로 데려가는 말이냐.
오류가 발생했습니다.
이메일에 @가 빠진 것 같아요. '[email protected]' 형태로 다시 입력해 주세요.
왼쪽은 무엇이 틀렸는지도, 어떻게 고치는지도 빠져 있어 사용자를 그 자리에 묶어 둡니다. 오른쪽은 원인과 해결을 한 줄에 담아, 읽자마자 손이 다시 키보드로 갑니다.
플레이스홀더와 톤은요?
두 가지를 자주 봅니다. 첫째, 플레이스홀더 남용. 입력칸 안에 회색 글씨로 라벨을 넣어두면 깔끔해 보이지만, 사용자가 입력을 시작하는 순간 그 글자는 사라집니다. 절반쯤 적다가 ‘이 칸이 뭐였더라’ 하게 되죠. 라벨은 항상 보이게 두고, 플레이스홀더는 예시(예: [email protected])에만 씁니다. 둘째, 톤 일관성. 어떤 버튼은 ‘하실래요?’, 어떤 안내는 ‘처리됨’처럼 말투가 화면마다 다르면 사용자는 서비스가 ‘여러 사람이 따로 만든 것’처럼 느낍니다. 저는 한 서비스 안에서 존댓말 정도, 권유와 단정의 비율, 이모지 사용 여부까지 한 장으로 정리해 두고 그 안에서만 씁니다.
| 항목 | 막연한 마이크로카피 | 명확한 마이크로카피 |
|---|---|---|
| 버튼(클릭) | “확인” → 무슨 일이 생길지 모름 | “무료 진단 받기” → 결과가 보임 |
| 오류(복구) | “오류가 발생했습니다” | “@가 빠진 것 같아요. 다시 확인해 주세요” |
| 빈 상태(신뢰) | “데이터 없음” → 막다른 길 | “첫 현장을 추가해 볼까요?” → 다음 행동 |
| 입력칸 | 플레이스홀더로 라벨 대체 | 라벨은 항상 노출, 예시만 플레이스홀더 |
다른 담당자와의 연결
마이크로카피는 혼자 사는 글자가 아닙니다. 폼·버튼과 한 몸으로 움직입니다. 입력칸 위의 라벨과 오류 메시지는 폼을 만드는 사람과 같이 다듬어야 합니다 — 폼 담당자의 노트에 그 실무가 있습니다. 버튼 안에 들어갈 글자(라벨)는 버튼을 설계하는 사람의 상태(로딩·완료)와 짝이 맞아야 합니다 — 버튼 담당자의 노트를 보세요. 그리고 페이지 맨 위의 헤드라인 카피가 약속을 깔아두면, 제 버튼 글자가 그 약속을 닫습니다 — 헤드라인 쓰는 법과 이어집니다.
그래서, 글자 하나를 진지하게 다룬다는 것
마이크로카피는 가장 작은 단위지만, 사용자가 행동하는 바로 그 순간에 놓여 있습니다. 버튼 글자, 빈 화면 한 줄, 오류 한 줄을 진지하게 다루는 사람이라면 폼도 속도도 같은 태도로 다룹니다. Findable에서는 이런 디테일이 기본값입니다. 당신의 화면, 어떤 글자부터 바꿔볼까요?
마이크로카피가 정말 전환에 영향을 주나요?
버튼 글자는 어떻게 써야 하나요?
오류 메시지는 어떻게 써야 하나요?
빈 상태(empty state)에는 무엇을 써야 하나요?
플레이스홀더로 라벨을 대신해도 되나요?
폼 담당자의 노트
라벨·오류·복구까지 한 몸으로.
버튼 담당자의 노트
버튼 라벨과 상태를 직접 눌러보기.
카피는 이렇게 씁니다
약속을 닫는 카피 작업 방식.
이 글의 마이크로카피 토글 위젯은 이 페이지에서 실제로 동작하는 코드입니다(외부 라이브러리 0). 전환·클릭률에 대한 설명은 일반 원칙이며 특정 성과를 보장하지 않습니다. 날조된 사례·수치는 사용하지 않았습니다.