좋은 검증은 사용자가 제출을 누른 뒤가 아니라 칸을 떠나는 순간 틀린 곳을 짚어 줍니다. Findable은 블러 시점에 형식을 확인하고, 비난 없는 문구로 ‘어떻게 고치면 되는지’를 보여주며, 맞으면 성공 신호까지 줘서 사용자가 확신을 가지고 제출하게 만듭니다.
요약
- 검증은 칸을 벗어날 때(블러)가 기본 — 고치는 중에는 입력 즉시 다시 검증한다.
- 오류 문구는 사용자를 탓하지 않는다. ‘무엇을 어떻게’ + 형식 예시 한 줄.
- 모바일은 type·inputmode·autocomplete로 키보드와 자동완성을 맞춘다.
- 맞았을 때도 성공 신호를 준다 — 침묵은 불안을 남긴다.
예전에 어떤 신청 폼을 분석한 적이 있습니다. 사람들이 제출 버튼을 평균 두 번 넘게 눌렀습니다. 이유는 단순했습니다. 한 번 누르면 페이지 맨 위로 올라가 “필수 항목을 확인하세요”라는 빨간 박스가 떴고, 정작 어느 칸이 문제인지는 직접 찾아야 했거든요. 사람은 한 번 보물찾기에 실패하면, 두 번째엔 그냥 창을 닫습니다. 그날 이후 저는 오류를 ‘제출 후 한꺼번에’가 아니라 ‘틀린 칸 옆에서 바로’ 말하는 데 집착합니다.
그래서, 직접 입력해 보세요
설명보다 빠릅니다. 아래 칸에 이메일이나 전화번호를 쳐 보세요. 형식이 맞는지 즉시 표시됩니다.
틀린 건 그 자리에서 알려줘야 합니다
이메일이나 전화번호를 입력해 보세요. 형식이 맞는지 즉시 표시됩니다.
언제 알려줄지가, 무엇을 알려줄지만큼 중요합니다
타이밍이 전부입니다. 한 글자 칠 때마다 빨간 글씨가 떴다 사라지면 사람은 다 쓰기도 전에 혼나는 기분이 듭니다. 그래서 기본은 칸을 벗어날 때(블러)입니다. 이메일을 다 적고 다음 칸으로 넘어가는 순간 확인하는 거죠. 다만 예외가 하나 있습니다. 한 번 오류가 났던 칸은, 사용자가 고치는 동안에는 입력 즉시 다시 검증합니다. ‘이제 맞다’를 1초라도 빨리 알려줘야 다시 쓰는 스트레스가 줄거든요. 처음엔 느긋하게, 고칠 땐 즉각적으로. 이게 제 규칙입니다.
‘잘못된 값’이라고 쓰면, 사용자는 자기를 탓합니다
오류 문구 한 줄이 사람을 멈추게도, 다시 입력하게도 만듭니다. 저는 두 가지를 지킵니다. 첫째, 탓하지 않기. ‘잘못 입력했습니다’가 아니라 ‘이메일 형식이 아니에요’처럼 사실만 말합니다. 둘째, 고치는 법 보여주기. 틀렸다는 말로 끝내지 않고 name@example.com처럼 올바른 형식을 한 줄 붙입니다. 위 위젯에서 일부러 틀리게 쳐 보면, 무엇을 어떻게 고치면 되는지가 같이 뜹니다. 비난 대신 안내. 이 차이가 다시 입력하는 시간을 줄입니다.
형식은 사람이 외우는 게 아니라, 칸이 거드는 겁니다
전화번호 칸에 빈 화면만 두고 ‘010-1234-5678 형식으로 입력하세요’라고 적은 폼이 많습니다. 그러면 사람이 형식을 머릿속으로 맞춰야 합니다. 저는 반대로 합니다. placeholder로 예시를 미리 보여주고, 입력하면 하이픈을 자동으로 넣습니다. 위 위젯도 숫자를 치면 전화번호로 알아보고 형식을 거듭니다. 형식을 외우게 하지 말고, 칸이 형식을 책임지게 만드는 거죠.
모바일에서는, 키보드부터 다릅니다
데스크톱에서 잘 되던 폼이 모바일에서 답답한 이유의 절반은 ‘잘못된 키보드’입니다. 이메일 칸인데 일반 키보드가 떠서 @를 찾아 헤매고, 전화번호 칸인데 문자 키보드가 떠서 숫자판을 따로 켭니다. 저는 칸마다 입력 타입을 맞춥니다. 이메일은 type="email", 전화는 type="tel", 숫자는 inputmode="numeric". 그러면 모바일에서 칸을 누르는 순간 알맞은 키보드가 뜹니다. 여기에 autocomplete를 붙이면 저장된 이메일·전화·이름이 탭 한 번에 채워져서, 입력량 자체가 절반으로 줄어듭니다.
맞았다는 말을 안 하면, 끝까지 불안합니다
많은 폼이 틀렸을 때만 빨갛게 외치고, 맞았을 때는 아무 말이 없습니다. 그런데 사용자는 ‘제대로 쓴 건가?’를 제출 직전까지 확신하지 못합니다. 저는 형식이 맞으면 초록 체크나 ‘확인됐어요’ 한마디를 꼭 띄웁니다. 위 위젯에서 올바른 이메일을 끝까지 치면 성공 표시가 뜨는 이유입니다. 오류 신호와 성공 신호가 짝을 이뤄야, 사용자가 의심 없이 제출 버튼을 누릅니다.
제출 후 한꺼번에 vs 인라인 즉시 검증
같은 폼이라도 검증을 언제 어떻게 하느냐로 경험이 갈립니다. 둘을 나란히 두면 차이가 분명합니다.
| 항목 | 제출 후 오류 | 인라인 즉시 검증 |
|---|---|---|
| 완료율 | 틀린 칸 보물찾기 → 이탈 | 틀린 칸 바로 고침 → 완료 |
| 좌절감 | 제출 눌러야 비로소 혼남 | 치는 순간 안내, 비난 없음 |
| 신뢰 | 성공 신호 없어 끝까지 불안 | 초록 체크로 확신하고 제출 |
제가 검증을 설계할 때 한 칸이 겪는 ‘검증 흐름’은 이렇게 흘러갑니다. 언제 침묵하고 언제 말을 거는지의 순서입니다.
그리고 검증이 사용자를 화나게 하는 자리는 정해져 있습니다. 어느 시점이 거슬리고, 그걸 무엇으로 바꾸는지 정리했습니다.
| 검증 시점 | 사용자가 느끼는 마찰 | 해결 |
|---|---|---|
| 입력 도중 | 다 쓰기 전 빨간 오류로 혼나는 기분 | 입력 중에는 판단을 미루고 침묵 |
| 칸을 떠날 때 | 어디가 틀렸는지·어떻게 고칠지 모름 | ‘무엇을·어떻게’를 칸 바로 아래 한 줄로 |
| 모바일 입력 | 잘못된 키보드로 형식을 못 맞춤 | type/inputmode로 알맞은 키보드 + 자동완성 |
| 형식 통과 | 맞았다는 말이 없어 제출까지 불안 | 초록 체크·‘확인됐어요’로 성공 신호 |
오류 신호와 성공 신호가 짝을 이뤄야, 사용자가 ‘됐나?’ 하고 되돌아가지 않고 끝까지 갑니다.
다른 담당자와의 연결
검증은 폼의 한 부분일 뿐입니다. 좋은 폼은 여러 디테일이 같이 움직여야 완성됩니다.
- 폼의 기본기 — 칸 수·순서·라벨: 검증을 잘해도 칸이 많으면 사람은 떠납니다. 폼 자체를 줄이는 이야기.
- 마이크로카피 — 한 줄이 행동을 바꿉니다: 오류 문구도 결국 카피입니다. 비난 없는 한 줄을 쓰는 법.
- 버튼 상태 — 누른 뒤 1초의 신뢰: 검증을 통과한 다음, 제출 버튼이 보여줄 로딩·완료 상태.
검증은 입력 도중에 보여줘야 하나요, 다 쓴 다음에 보여줘야 하나요?
오류 문구는 어떻게 써야 하나요?
전화번호 같은 형식은 어떻게 안내하나요?
모바일에서 입력을 편하게 하려면 뭘 챙겨야 하나요?
성공했을 때도 표시해야 하나요?
폼의 기본기 — 칸을 줄이는 일
완료율을 가르는 건 칸 수·순서·라벨.
마이크로카피 — 한 줄이 행동을 바꿉니다
오류 문구도 결국 카피입니다.
UX는 이렇게 합니다
사용자 흐름을 먼저, 화면은 그다음.
이 글의 검증 위젯은 이 페이지에서 실제로 동작하는 코드입니다(외부 라이브러리 0). 완료율·좌절·신뢰 관련 서술은 일반 UX 원칙이며 특정 성과를 보장하지 않습니다. 날조된 사례·수치는 사용하지 않았습니다.