좋은 검색·필터 결과 섹션은 입력하는 즉시 걸러지고(UX), 남은 항목을 한눈에 읽히게 보여 주고(디자인), 결과가 없을 때 다음 행동을 알려 줍니다(마이크로카피). Findable은 이 셋을 한 섹션에서 같이 설계하고, 키보드만으로도 쓰이도록 접근성을 기본값으로 넣습니다.
요약
- 항목이 한 화면에서 비교되는 목록이면 ‘검색 버튼’ 대신 입력 즉시 거른다.
- 결과 카드는 눈이 움직이는 순서대로 정보를 배치해 빠르게 훑게 만든다.
- 빈 상태는 막다른 길이 아니다 — ‘다른 키워드로’처럼 다음 한 걸음을 적는다.
- 입력창은 Tab으로 닿고, 줄어드는 결과 수는 aria-live로 낭독기에 알린다.
처음 검색·필터 결과 섹션을 같이 만들 때, 우리는 각자 다른 데를 봤습니다. UX 담당은 “버튼을 왜 눌러야 하지, 입력하면 바로 줄어야지”라고 했고, 디자인 담당은 “줄어든 결과가 읽히지 않으면 의미가 없다”고 했고, 카피 담당은 “결과가 0개일 때가 가장 중요하다”고 했습니다. 셋 다 맞았습니다. 그래서 이 섹션은 세 사람의 합의로만 완성됩니다.
그래서, 직접 입력해 보세요
설명보다 빠릅니다. 아래 입력창에 ‘GEO’, ‘속도’, ‘폼’을 쳐 보세요. 누르는 버튼 없이 즉시 걸러집니다. 그리고 일부러 ‘zzz’처럼 없는 단어를 쳐서 빈 상태도 만나 보세요.
검색·필터 결과 (즉시 필터+빈 상태)
'GEO', '속도', '폼' 등을 입력 — 즉시 걸러집니다.
1. UX — ‘검색 버튼’을 없애면 좁히는 속도가 달라집니다
위 위젯에는 ‘검색’ 버튼이 없습니다. 한 글자 칠 때마다 목록이 줄어들죠. 한 화면 안에서 비교되는 항목이라면 이게 가장 빠릅니다. 사용자가 버튼을 찾고, 마우스를 옮기고, 누르고, 기다리는 네 단계가 통째로 사라집니다. 다만 서버를 호출해 비용이 큰 검색이라면, 사람이 타이핑을 멈춘 순간에만 요청하는 디바운스를 함께 씁니다 — 즉시성과 비용을 동시에 잡는 절충입니다.
2. 디자인 — 줄어든 결과가 ‘읽혀야’ 의미가 있습니다
거르는 게 빨라도 결과가 한 덩어리로 보이면 소용이 없습니다. 우리는 한 항목 안에서 눈이 어디부터 움직이는지를 먼저 정합니다. 제목 → 한 줄 설명 → 태그 순으로 크기와 색을 줘서, 훑기만 해도 무엇인지 알게 합니다. 줄 목록으로 충분한지, 이미지·요약을 비교해야 해서 카드가 필요한지는 콘텐츠가 정합니다 — 멋이 아니라 비교 방식이 형태를 결정합니다.
3. 마이크로카피 — 결과 0개일 때가 진짜 시험입니다
위에서 없는 단어를 쳤다면 “결과가 없어요 — 다른 키워드로”가 떴을 겁니다. 이 한 문장이 빈 상태 설계의 핵심입니다. ‘결과 없음’으로 끝내면 막다른 길이지만, 다음 행동을 권하면 길이 다시 열립니다. 실전에서는 여기에 ‘무엇을 검색했는지’를 다시 보여 주고, ‘필터 지우기’ 버튼을 같이 둡니다. 사용자가 가장 답답한 순간에, 카피가 손을 내미는 자리입니다.
4. 접근성 — 마우스 없이도 좁혀져야 합니다
입력창에는 Tab으로 닿아야 하고, 닿았을 때 포커스 링이 보여야 합니다. 그리고 결과가 줄어들 때 화면 낭독기 사용자에게도 ‘몇 건 남았다’가 들려야 합니다 — 이건 aria-live 영역으로 알립니다. 빈 상태 메시지도 마찬가지로 낭독되어야 ‘왜 아무것도 안 보이는지’를 알 수 있습니다. 보이지 않는 사용자에게 검색은 ‘소리로 듣는 좁히기’입니다.
이 세 가지가 ‘동시에’ 들어가야 하는 이유
하나라도 빠지면 섹션이 무너집니다. 즉시 필터만 있고 빈 상태 카피가 없으면, 사용자는 0개 화면 앞에서 길을 잃습니다. 카피만 좋고 결과 디자인이 나쁘면, 걸러져도 읽지 못합니다. 디자인만 예쁘고 키보드를 못 쓰면, 누군가는 아예 검색을 못 합니다. 그래서 우리는 이 섹션을 ‘한 사람의 작업’이 아니라 ‘세 직무의 합의’로 봅니다.
많은 항목을 빠르게 좁히는 게 목적입니다
검색·필터 결과 섹션의 존재 이유는 단 하나입니다. 항목이 많을 때 사용자가 ‘원하는 것 근처’까지 빠르게 가게 하는 것. 그래서 우리는 화면을 채우는 데가 아니라 ‘좁히는 속도와 명료함’에 시간을 씁니다. 위 위젯이 작아 보여도, 이 작은 합작에 세 직무의 판단이 전부 들어가 있습니다.
합작 분해 — 누가 무엇을 했나
저는 검색·필터 한 섹션을 만들 때 세 직무가 ‘어디까지 책임지는지’부터 칸으로 못 박습니다.
| 담당 | 이 모듈에서 한 일 |
|---|---|
| UX | ‘검색’ 버튼을 없애고 입력 즉시 거르기(data-k 매칭), 서버 호출형이면 타이핑 멈춤 시에만 요청하는 디바운스 절충 |
| 디자인 | 한 항목 안 시선 동선(제목→설명→태그)대로 크기·색을 배치해 훑기만 해도 읽히게 — 목록/카드는 비교 방식이 결정 |
| 마이크로카피 | 빈 상태를 ‘결과 없음’이 아니라 ‘다른 키워드로’ 다음 행동으로, placeholder에 실제 입력 예시(GEO·속도·폼) |
| 접근성 | 입력창 Tab 도달·포커스 링, 결과 수 변화·빈 상태를 aria-live로 낭독기에 알림(소리로 듣는 좁히기) |
하나라도 빠지면 섹션이 무너진다는 걸, 저는 이 표로 매번 확인합니다.
그리고 저는 이 검색 한 모듈에 들어간 기술을 칩으로 펼쳐 둡니다 — 작아 보여도 세 직무의 판단이 다 들어갑니다.
‘좁히는 속도와 명료함’에 시간을 쓰려고 고른 도구들입니다.
이 작품에 들어간 기술
이 한 섹션은 Findable의 세 가지 작업이 겹쳐진 결과입니다. 각각을 더 깊이 다룬 글을 함께 둡니다.
- 검색·필터 UX — 즉시 필터·디바운스·결과 강조의 실제 동작은 필터 인터랙션 노트에서 직접 입력해 볼 수 있습니다.
- 마이크로카피 — 빈 상태·버튼·안내 문구를 어떻게 쓰는지는 마이크로카피 노트에 정리했습니다.
- 접근성 — 키보드 이동·포커스·aria-live 같은 기본은 접근성 노트에서 라이브로 확인할 수 있습니다.
| 항목 | 끝없는 목록 | 즉시 필터 + 빈 상태 |
|---|---|---|
| 탐색 속도 | 스크롤로 일일이 찾음 | 입력 즉시 좁혀짐 |
| 결과 0개 | 빈 화면 → 막다른 길 | 다음 키워드를 안내 |
| 사용자 만족 | “원하는 게 어디 있지” | “바로 찾았다” |
검색·필터는 버튼을 눌러야 작동하게 해야 하나요, 즉시 걸러야 하나요?
빈 상태(검색 결과 없음)에는 무엇을 적어야 하나요?
검색·필터 결과를 키보드만으로 쓸 수 있어야 하나요?
결과를 줄 목록과 카드 중 무엇으로 보여줄까요?
검색창 안의 안내 문구(placeholder)는 어떻게 써야 하나요?
필터 인터랙션 노트
즉시 필터·디바운스를 직접 입력해 보기.
마이크로카피 노트
빈 상태·버튼·안내 문구 쓰는 법.
접근성 노트
키보드·포커스·aria-live 라이브 확인.
이 글의 검색·필터 위젯은 이 페이지에서 실제로 동작하는 코드입니다(외부 라이브러리 0, 공유 스크립트가 구동). 탐색 속도·만족에 대한 설명은 일반 UX 원칙이며 특정 성과를 보장하지 않습니다. 날조된 사례·수치는 사용하지 않았습니다.