개요
Mealio의 레시피 검색 기능을 설계하다가 문득 이런 생각이 들었습니다.
"왜 검색창에 처음부터 필터를 안쓸까? 어차피 나중에 필터 걸고 정렬도 할거면, 검색 실행 전에 먼저 다 적용하게 만들면 UX도 단순하고 요청 횟수도 아끼고 좋지 않나?"
어째서인지 우리가 아는 서비스들은 그렇게 하지 않습니다.
- 검색어만으로(또는 최소한의 조건으로) 먼저 검색을 실행합니다.
- 결과 화면에서 필터를 추가로 좁히고, 그 때마다 쿼리가 다시 호출됩니다.
- 정렬 순서(최신순, 가격순, 관련도순 등)를 바꾸면 또 한 번 쿼리가 호출됩니다.
이렇게 놓고 보면 사실 꽤 비효율적으로 보입니다. 필터와 정렬을 검색 이전 단계에서 한꺼번에 결정하게 하면, 검색 실행 시점에 단 한 번의 쿼리로 끝낼 수도 있습니다. 서버 부하나 응답 지연, 캐싱 전략까지 생각하면 분명 괜찮아 보입니다.
그럼에도 필터와 정렬을 앞단에 몰아넣지 않는 이유는 Progressive Disclosure(점진적 정보 공개) 때문입니다. 이 글에서는 Progressive Disclosure의 개념과 중요성, 그리고 예외에 대해 다룹니다.
Progressive Disclosure란
단계적 공개(Progressive Disclosure)는 초기 단계에서 전부를 보여주는 방법(Full Disclosure) 대신 단계적으로 받아들일 수 있을만큼 적절하게 나누어 필요하거나 요청을 받은 정보들만 보이도록 하여 복잡한 정보를 효율적으로 다루는 전략적인 방법을 말한다. 위키백과
UX에서는 처음에 가장 중요한 옵션만 보여주고, 저빈도 기능은 사용자가 요청할 때까지 후속 화면으로 미루는 규칙을 의미합니다.
Progressive Disclosure는 학습 용이성, 사용 효율, 오류율을 함께 개선할 수 있습니다. 초보자는 당장 필요 없는 고급 옵션을 고민하느라 실수할 여지가 줄고, 숙련자도 자주 쓰지 않는 항목을 매번 거쳐가지 않아도 됩니다.
처음부터 모든 옵션을 한꺼번에 제시하면 사용자는 다음과 같은 문제를 겪을 수 있습니다.
- 결정할 게 너무 많아짐: 한 번에 결정해야 할 항목이 많을수록 인지적 과부하가 생기고, 의사결정을 미루거나 포기할 확률이 높아집니다.
- 판단 근거 없이 답해야 함: 아직 판단할 근거(결과, 맥락)가 없는 상태에서 결정부터 요구받으면, 사용자는 근거 없이 추측으로 답하게 됩니다.
- 초기 화면이 복잡해짐: 정작 중요한 첫 액션으로 가는 진입장벽이 높아집니다.
UX 설계에서 Progressive Disclosure는 대략 세 갈래로 나누어집니다.
- 단계형(step-by-step): 복잡한 작업을 순서대로 쪼개서 배치
- 조건부(conditional): 사용자가 요청할 때까지 저빈도 작업을 숨김
- 맥락형(contextual): 이전 입력이나 상황에 맞춰 추가 정보를 띄움
이 세가지 유형을 필터/정렬 배치 문제에 대입하면 왜 정렬이 결과 화면에 있어야 하는지, 왜 필터가 검색 이후 단계에 배치되어야 하는지 설명할 수 있습니다.
정렬을 먼저 배치하지 않는 이유
1. 정렬은 결과가 있어야 의미가 생긴다
정렬은 이미 존재하는 데이터를 어떤 기준으로 재배열할지에 대한 결정입니다. 그런데 검색을 실행하기도 전에는 사용자에게 무엇을 정렬할지에 대한 실체가 없습니다. 결과가 10개인지 10,000개인지, 가격대가 균일한지 다양한지, 애초에 정렬할 만큼 의미 있는 차이가 있는지조차 알 수 없는 상태입니다. 이런 상태에서 정렬 기준부터 정하라고 하면, 아직 보지도 않은 것을 어떻게 보고 싶은지 미리 답하라는 요구와 비슷해집니다.
2. 정렬은 반복적인 행동이다
실제 사용자 행동에서 정렬은 한 번에 결정되지 않습니다. 가격 낮은 순으로 봤다가 결과가 마음에 안 들면 인기순으로, 다시 최신순으로 계속 바꿔보는 식으로 시행착오를 거칩니다. 필터처럼 확정하고 다음 단계로 넘어가는 결정이 아니라, 결과 화면에 머무르면서 반복적으로 실험하는 행동에 가깝습니다. 이런 실험적인 상호작용은 결과를 눈앞에 두어야 자연스럽고, 결과 화면을 벗어난 곳에 배치하면 오히려 왕복 비용만 늘어날 수 있습니다.
3. 인지 부하가 늘어난다
필터와 정렬을 같은 화면에서 배치하면 사용자는 서로 다른 성격의 결정을 같은 타이밍에 처리해야 합니다. 화면 하나에 여러 책임이 부여되고, 이는 검색 실행률을 떨어뜨릴 위험도 있습니다.
필터를 검색어와 함께 배치하지 않는 이유
1. 보면서 고르는 게 더 쉽다
사람은 스스로 무언가를 떠올리는 것보다, 눈앞에 제시된 것 중에서 고르는 걸 훨씬 편하게 느낍니다. 검색을 실행하기 전에 어떤 브랜드로, 어떤 가격대로 필터링할지를 미리 정하라고 하면, 사용자는 머릿속으로 존재하지도 않는 선택지를 상상해서 답해야 합니다. 반면 일단 결과를 보여주면, 실제로 존재하는 브랜드 목록과 가격 분포가 화면에 나타나고, 사용자는 그중에서 고르기만 하면 됩니다. 훨씬 편한 방식입니다.
2. 빠른 피드백이 신뢰를 만든다
검색이라는 행위에서 사용자가 가장 먼저 확인하고 싶은 건 내 검색어가 유효한 결과를 만들어내는지입니다. 여러 필터를 조합해서 조건을 다 만든 뒤에야 결과를 처음 보게 되면, 그 사이의 모든 설정이 결과 0건으로 무너질 위험을 안고 갑니다. 반대로 키워드만으로 먼저 결과를 보여주면, 사용자는 검색이 잘 작동한다는 확신을 빠르게 얻고, 그 다음 단계로 자연스럽게 필터를 좁혀나갑니다.
3. 사용자는 범위를 점진적으로 좁혀나간다
사용자의 실제 탐색 과정은 대개 막연한 키워드 → 결과 확인 → 조건 추가 → 결과 확인의 반복입니다. 사용자가 처음부터 완벽하게 정제된 의도를 갖고 있지 않다는 걸 전제로 합니다. 검색은 의도를 발견해가는 과정에 가깝고, 처음부터 확정된 질의를 던지는 행위는 아닙니다.
성능 효율 vs UX 효율
중요한 사실은 쿼리 호출 횟수를 줄이는 건 시스템 관점의 효율이지, 사용자 관점의 효율이 아니라는 것 입니다.
| 관점 | 최적화 대상 | 발생 비용 |
|---|---|---|
| 성능 | 쿼리 횟수, 서버 부하, 응답 시간 | 인프라 비용, 지연 |
| UX | 의사결정 비용, 인지 부하, 완료율 | 이탈, 낮은 전환율, 사용자 불만 |
쿼리를 한 번 줄여서 응답 속도를 빠르게 만드는 것과, 사용자가 검색을 포기하지 않고 원하는 결과에 도달하는 것 중 무엇이 서비스 전체의 성공에 더 크게 기여할지 생각해보아야 합니다.
쿼리 비용은 인프라 업스케일링이나 캐싱, 인덱싱으로 어느 정도 상쇄할 수 있지만, 사용자가 검색 자체를 포기하고 이탈하는 비용은 복구하기 어렵습니다. 결과적으로 더 비싼 비용(사용자 이탈)을 더 싼 비용(추가 쿼리)으로 막는 것이 합리적인 선택입니다.
예외 케이스
1. 사용자가 이미 명확한 의도를 갖고 재방문하는 경우
저장된 검색 조건, 최근 필터 재사용, 특정 카테고리 전용 랜딩 화면처럼 이미 뭘 원하는지 아는 맥락에서는 사전 설정이 오히려 단계를 줄여줄 수 있습니다.
2. 결과 집합이 이미 익숙한 도메인인 경우
예를 들어 특정 브랜드 목록이 항상 고정적인 B2B 도구라면, 필터 옵션이 결과에 의존하지 않으므로 미리 보여줘도 무방합니다.
3. 검색어가 필터와 동등하거나 후순위인 경우
커머스처럼 키워드가 먼저인 맥락도 있지만, 탐색의 출발점이 키워드가 아닌 UX도 있습니다. 사용자가 정확한 단어를 떠올리기보다 상황/조건으로 후보를 받고 싶을 때, 검색어는 선택적인 보조 조건이 되고 필터가 주된 진입 경로가 될 수 있습니다.
4. 파워 유저를 위한 고급 검색
법률/특허 검색이나 데이터 분석 툴 처럼 조건을 정교하게 미리 세팅하는 것 자체가 목적인 화면에서는 오히려 정교한 사전 설정이 필요합니다.
Mealio의 레시피 검색 UX
Progressive Disclosure를 전제할 때, Mealio는 예외가 두 가지 있습니다.
- 예외 케이스 2번: 요리 레시피라는 누구나 아는 익숙한 도메인
- 예외 케이스 3번: 검색보다는 후보 추천의 개념에 더 가까움
사용자는 미리 알고 있는 요리 이름으로 특정 레시피를 찾을 때도 있지만, 대부분은 "저녁 뭐 먹지"에 가까운 추천을 원합니다. 이 경우 카테고리나 조리 시간처럼 상황을 정의하는 필터가 검색어보다 앞서는 편이 자연스럽고, 검색어는 필요할 때만 쓰는 보조 조건에 가깝습니다.
그래서 다음과 같은 필터(키워드 포함) → 결과 확인 → 정렬 구조로 설계하였습니다.
1. 필터 화면이 곧 검색 의도
이 화면에서는 카테고리, 난이도, 조리 시간 범위처럼 상황을 좁히는 조건을 중심에 두고, 검색어는 선택적으로 함께 둘 수 있게 했습니다. 정렬 선택지는 아예 노출하지 않습니다. 사용자가 이 화면에서 내리는 결정은 검색을 실행할지 말지, 그리고 어떤 조건으로 실행할지뿐입니다.
2. 검색 후 정렬
결과 목록 위에 정렬 드롭다운이 놓여 있고, 사용자가 기준을 바꾸면 같은 화면 안에서 곧바로 결과가 다시 요청됩니다. 화면을 벗어나지 않고도 눈앞의 결과를 보면서 정렬 기준을 이리저리 바꿔볼 수 있는 구조입니다. 앞서 이야기한 정렬의 탐색적이고 반복적인 특성과 맞닿아 있는 부분입니다.
3. 필터 칩 표시
검색어, 난이도, 조리 시간, 카테고리 조건이 각각 하나의 칩으로 나열되고, 특정 칩을 지우면 그 조건만 빠진 채로 결과가 다시 조회됩니다. 사용자가 결과를 보고 이 조건은 너무 좁았다고 판단했을 때, 정확히 그 조건만 되돌릴 수 있게 해주는 장치입니다.
4. 필터로 회귀하는 경로
이때 지금까지 적용된 조건은 그대로 유지된 채 필터 화면으로 이동하므로, 처음부터 다시 조건을 입력할 필요 없이 기존 조건 위에서 세부 사항만 조정할 수 있습니다. 이를 통해 결과 범위를 점진적으로 좁힐 수 있습니다.
정리하면 Mealio는 Progressive Disclosure를 기반으로 도메인 특성과 검색 목적에서 예외를 적용하여 필터를 선배치하고, 정렬은 정석으로 검색 결과 후에 배치하는 방식으로 UX를 설계하였습니다.
맺음말
나름 성능과 UX 사이에서 트레이드오프를 고민할 수 있는 사례였습니다. 물론 UX를 손해보면서 까지 극한으로 성능을 최적화해서 얻는 것이 무엇인가에 대한 생각도 들었습니다. 당연한 말로 항상 중간에서 적당히가 중요하지만, 대부분의 서비스는 UX를 조금 더 중요하게 보지 않았나 싶습니다.
UX를 연구하는 사람이라면 사소한 경로까지도 세심하게 신경써야 한다고 생각합니다. 사실 별 생각 없이 프로젝트를 빠르게 완성하고 싶었다면 레퍼런스만 따라가면 그만이었습니다. 개발이든 비즈니스든 이유 없이 당연한 선택은 없기 때문에, 늘 의심하고 질문해야 성장하는 것 같습니다.