검색 UX 설계

포털의 통합검색은 사용자의 검색 의도를 알 수 없다는 이유로 가능한 많은 컬렉션(웹, 블로그, 이미지, 지식인, 뉴스 등)의 결과를 한 화면에 나열하는 방식을 택한다. 그러나 실제 사용자는 대부분 소수의 검색 소스만 반복해서 사용하며, 나머지 컬렉션은 화면을 복잡하게 만들고 스캔 비용만 늘릴 뿐이라는 관찰에서 출발한 검색 UX 재설계 사례가 있다. 개인이 수년간 직접 사용하며 다듬은 검색 UI(A la carte 검색)를 통해, "많이 보여주기"보다 "핵심 소스만 예측 가능한 순서로 덜어내어 보여주기"가 더 나은 검색 경험을 만든다는 것을 검증했다.

이 개인 프로젝트의 출발점은 2010년 구글이 Google Instant라는 이름으로 정식 출시한 실시간 검색(incremental search)의 원형을 추적하는 과정에서 드러난다. 가장 이른 원형으로 꼽히는 것은 2005년 macOS 10.4에 탑재된 스팟라이트(Spotlight)로, 검색어를 입력하는 즉시(엔터 없이) 로컬 파일 결과를 보여주는 속도로 당시 사용자들에게 충격을 주었다. 두 번째 원형은 David Watanabe가 만든 사파리 플러그인 인퀴지터(Inquisitor)로, 검색어 입력 중 구글 서제스션을 불러와 첫 번째 추천어를 자동완성하고 그 검색 결과까지 곧바로 보여주는 방식이 훗날의 구글 인스턴트와 사실상 동일했다 — 이 프로그램은 이후 야후에 인수됐지만, 야후는 지원 브라우저만 늘렸을 뿐 자사 웹 검색에는 실제로 적용하지 않았다. 국내에서는 인퀴지터가 한글 조합형 문자의 자동완성을 지원하지 않는 한계를 보완하기 위해 개인이 2008년 직접 만든 검색 UI À la carte 검색(이후 QuickFind로 개선)이 등장했는데, 이것이 바로 앞서 설명한 개인 검색 UI 리디자인 프로젝트의 출발점이다. 이 사례는 메이저 플레이어(구글)가 특정 UX 패턴을 채택하면 그 패턴이 이미 여러 해 전부터 소규모 도구·개인 프로젝트에서 검증되어 온 경우가 많다는 것, 그리고 새로운 UX 패턴의 특허성 여부보다 얼마나 빨리 대중화되느냐가 실제 확산을 좌우한다는 것을 보여준다.

검색 사용자 의도(Search User Goals)는 학술적으로 크게 세 가지로 분류된다: 특정 사이트로 이동하려는 navigational(15~20%), 정보를 얻으려는 informational(50~60%, 가장 큰 비중), 리소스를 얻으려는 transactional(25~30%). informational은 다시 닫힌/열린 질문(closed-end·open-end question), 방향이 정해지지 않은 질문(undirected question), 조언·위치·목록 요청 등으로 세분된다. 문제는 사용자의 검색 의도가 검색어 자체에 명확히 드러나지 않아 결과에 직접 반영하기 어렵다는 점이다. 대신 사용자가 검색 주제에 대해 갖고 있는 지식 수준(domain knowledge)에 따라 검색 접근 방식이 달라진다는 점에 착안할 수 있다 — 전혀 모르는 대상은 "X에 대해 알려주세요" 같은 undirected question만 가능하고, 어느 정도 알아야 open-end·closed-end 질문으로 좁혀진다. 이 때문에 검색은 한 번의 질의로 끝나지 않고, 얻은 정보를 바탕으로 다시 검색하는 과정을 반복해 목적지에 도달하는 오리엔티어링(orienteering)에 가깝다.

이 재설계의 문제의식은 앞선 글에서 더 구체적으로 다뤄진다. 네이버가 세계 최초로 선보였다는 통합검색은 정보 유형·출처별 컬렉션 검색(vertical search) 결과를 한 페이지에 모아 보여주는 한국형 검색 모델로, 유형별로 파편화된 검색결과를 함께 보여주겠다는 구글의 유니버설 서치(universal search)와 문제의식은 같지만 접근은 다르다 — 구글은 랭킹순 웹 결과를 기본으로 하되 관련도 높은 다른 유형만 추가로 노출하는 반면, 네이버·다음은 모든 키워드를 유형별로 남김없이 나눠 보여주려 한다(당시 구글코리아가 오히려 이런 로컬라이즈드 방식을 일부 도입하려던 정황도 있었다). 통합검색의 장점으로는 무엇을 찾는지 몰라도 훑어보다 발견하게 되는 recognition over recall + serendipity, 마우스 휠 성능 향상으로 스크롤 비용이 클릭만큼 저렴해졌다는 scroll is the new click, 낯선 전문(vertical) 검색엔진을 일일이 찾아 옮겨 다녀야 하는 진입 비용을 줄여준다는 점이 꼽힌다. 그러나 실제로는 과도한 정보량이 satisficing(적당히 만족하는 수준에서 탐색을 멈추는 의사결정)과 정보 과부하를 유발해 오히려 스캔 비용을 늘리며, 네이버가 자사 근거로 인용한 F자 아이트래킹 힛맵도 "검색결과 상단이 중요하다는 증거"가 아니라 "사용자가 원하는 결과를 통합검색 안에서 찾지 못해 헤매고 있다는 증거"로 재해석할 수 있다는 비판이 제기된다. 더 나아가 통합검색이 한국에서 주류가 된 배경에는 사용자 편의보다 검색광고 수익 구조(방대한 결과 지면이 상단 광고 노출을 정당화하는 구조)가 있으며, 비즈니스 키워드에서 블로그 이미지 썸네일 노출을 배제하는 등 광고 컬렉션과의 경쟁에서 다른 컬렉션에 불리하게 작동하는 정책도 함께 지적된다.

이런 관점에서 실제 사용 데이터를 분석해보면 소수의 소스가 대부분의 검색을 커버한다 — 위키백과(undirected question에 대한 최적의 답), 구글 웹검색(신뢰도 높은 best-match 결과, navigational·closed-end 질문에 강함), 네이버 블로그 검색(최신·주관적 리뷰, open-end 질문에 강함) 세 가지만으로 대부분의 검색 의도를 커버할 수 있었고, 이는 파레토 법칙처럼 상위 두세 개 소스가 전체 사용의 약 80%를 차지하는 패턴과 일치한다. 구글과 네이버 블로그는 성격이 상반되어(장기간 검증된 정보 vs 최신 트렌드 정보) 서로의 부족한 부분을 보완한다. 이에 따라 결과를 컬렉션별로 무작위 랭킹하는 대신, 위키백과 1개 → 구글웹 3개 → 블로그 5개처럼 예측 가능한 고정 개수·순서로 배치하면 불필요한 스크롤 없이도 원하는 결과를 더 잘 찾을 수 있었다(구글 상위 3개 클릭이 전체의 80%를 차지한다는 통계도 이런 배치를 뒷받침한다). 그 외의 전문(vertical) 검색엔진은 결과 하단에 모아두고, 이동 시 키워드를 다시 입력할 필요 없이 바로 검색되도록 연결한다 — 서비스를 내부에 가두기보다 더 나은 결과를 주는 외부 검색엔진으로 열어주는 편이 장기적 사용자 경험에 유리하다는 관점이다.

이 개인 검색 UI 리디자인은 결과 목록에서 URL 표시 방식도 함께 다듬었다. URL은 프로토콜(`http://`)·서버 주소(도메인)·서브 경로·페이지 이름으로 구성되지만 사용자에게 중요한 정보 위계는 서버 주소 ≫ 페이지 이름 > 서브 경로 ≫ 프로토콜 순이다. 트위터가 웹에서 트윗 속 URL을 표시할 때 ① `http://` 제거, ② URL 뒷부분 줄임, ③ `www.` 제거라는 세 방식으로 노이즈를 줄인 것도 이 위계 판단을 보여주는 사례다(`http://`는 사파리·크롬이 먼저 생략을 시작했고, 팀 버너스 리도 프로토콜에 `//`를 넣은 것을 훗날 실수로 인정했다). 검색엔진 간 비교에서도 차이가 드러난다 — 구글은 URL을 제목 바로 아래로 옮기고 중간 경로를 생략하거나 사이트 구조가 있으면 브레드크럼(breadcrumb)으로 대체해 표현하는 반면, 야후·네이버·다음(빙)은 URL을 그대로 나열하는 전형적인 방식을 따르며 가변 폭 레이아웃으로 인해 줄 길이(line length)가 인쇄물 기준(26~30자)보다 훨씬 긴 60여 자에 달해 가독성이 떨어진다. 이 개인 리디자인은 URL 텍스트 대신 파비콘(favicon)으로 출처(도메인)를 표현하고, 경로·페이지 이름은 아예 생략했으며, 링크 밑줄을 제거하고 제목뿐 아니라 본문 전체에 링크를 걸어 클릭 가능 영역을 넓히는(피츠의 법칙과 통하는) 방향으로 나아갔다 — 더 많은 정보를 욱여넣기보다 선택 판단에 기여하지 않는 정보를 덜어내 인지 비용을 줄이는 접근이다.

검색어 자동완성 UX에서도 두 가지 설계 실험이 있었다. 첫째, 추천 검색어를 목록으로 나열하면 추천 목록과 검색 결과에 주의가 분산되므로, 아이폰의 오토컴플리트 버블처럼 단 하나의 예측 검색어만 보여주는 방식이 인지 부담을 줄이고 오타도 더 잘 인지하게 했다. 둘째, 입력 중간에 의도치 않은 결과가 계속 노출되면 주의가 산만해지므로, 키 입력 타이밍을 체크해 입력이 사실상 끝났을 때만 결과를 보여주는 방식으로 노이즈를 줄였다. 이미지 노출 방식에서도 에드워드 터프티(Edward Tufte)가 강조한 "정보를 펼쳐 놓으라"는 원칙이 언급된다 — 마우스 오버해야만 추가 이미지를 보여주는 방식(stacked in time)은 비교에 필요한 정보를 감춰 사용자의 시간과 노력을 낭비시킨다.

모바일 검색 제안(Suggestion) UI에서는 플랫폼별 제약이 설계를 크게 좌우한다. iOS3 이하에서는 사파리가 텍스트 입력 시 입력 필드를 화면 중앙으로 강제 이동시켜, 입력창 아래 목록형 제안어를 2~3개밖에 보여주지 못하는 제약이 있었다. 이에 야후는 제안어를 입력창 위아래 2컬럼으로 배치하는 디바이스 특화 설계(Device-Specific Design)로 대응해 더 많은 제안어를 노출했고(구글·빙은 아예 입력창을 상단에 고정하는 방식으로 우회), iOS4부터는 입력창이 상단에 고정되도록 개선되며 제약이 완화됐다. 이 사례를 계기로 정렬을 포기하고 제안어를 자유롭게 흩뿌려 더 많이 보여주는 'Suggestion Bubbles' 아이디어도 제안되었으나, 이후 실사용 결과 노이즈(버블 형태 자체)를 없애고 예측 가능한 정렬을 살린 2컬럼 방식이 더 낫다는 결론으로 이어졌다 — 정렬을 통한 빠른 인지와 많은 키워드 노출 사이의 트레이드오프에서 결국 정렬이 우선한다는 실증 사례다. 이때 도출된 원칙은 ① PC 환경의 UI를 모바일에 그대로 답습하지 말 것, ② 입력 중에는 배경을 가려 노이즈를 줄이고 키워드에 집중시킬 것, ③ 멀티컬럼처럼 보이지만 실제로는 멀티라인으로 나열되는 형태(예: 네이버 모바일 연관검색어)는 사용자가 왼쪽 컬럼만 훑어보게 되는 인지적 착시를 유발할 수 있다는 것이다.

아이패드 정식 발매 시점(2011)의 국내 검색엔진 비교는 새로운 디바이스에 대한 디테일 대응 수준(readiness) 격차를 드러낸 사례다. 야후(미국)처럼 태블릿 전용 사이트를 만든 곳이 아직 없던 상황에서, 검색창 하나만 놓고 봐도 세 가지 디테일이 검색엔진별로 갈렸다. 첫째, 컨텍스추얼 키패드 대응 여부다. 검색창에 `type="search"` 속성을 지정하면 아이패드 가상 키패드에 줄바꿈 대신 "검색(Search)" 버튼이 뜨는데, 조사 시점에는 구글(미국)만 유일하게 이를 대응했고 국내 검색엔진은 모두 대응하지 않아 사용자가 매번 "이동(Go)"으로 검색을 실행해야 했다 — 검색창 자체가 브랜드 아이덴티티인 네이버·다음에서 특히 아쉬운 지점으로 지적된다. 둘째, 사파리의 인풋필드 프리셋 스타일과 검색창 아이덴티티의 충돌이다. `type="search"`를 적용하면 사파리가 둥글고 그림자가 들어간 자체 프리셋 스타일을 강제로 입혀, 검색창 고유의 비주얼 아이덴티티와 부딪힌다 — 이를 해소하려면 검색창 스타일을 별도로 해제(reset)하는 추가 작업이 필요하다. 셋째, 검색어 추천 기능과 아이패드 자동 수정(autocorrect) 기능의 충돌이다. 네이트는 자동 수정 기능이 활성화된 채로 추천 검색어와 겹쳐 표시돼 가독성이 떨어졌고, 파란은 추천 검색어 기능 자체가 스페이스·백스페이스를 입력해야만 나타나는 등 정상 동작하지 않았다. 이런 사례들은 새 디바이스가 등장할 때 기능 구현 자체보다 `type`·`autocorrect` 같은 입력 필드 속성 하나하나를 세심히 챙기는 디테일이 실제 사용성을 좌우한다는 것을 보여준다.

외국어 고유명사의 우리말 표기 문제도 검색 UX에 영향을 준다. 2012년 건축가 미스 반 데어 로에(Ludwig Mies van der Rohe)를 기념한 구글 두들 사례에서, 로고를 클릭하면 구글은 네덜란드식 발음인 "미스 판 데르 로에"로 검색을 실행했다. 하지만 국내에 출판된 40여 권의 관련 서적은 예외 없이 "미스 반 데어 로에"로 표기하고 있어, 신뢰도 높은 문서(위키백과 등)가 아니라 대부분 블로그 글만 상위에 노출되는 부정확한 검색 결과로 이어졌다. 이는 검색어 자체의 표기 불일치가 결과 품질을 떨어뜨리는 사례다. 해결 방향으로는 두 가지가 제시된다. 첫째, 네이버가 제공하는 "외래어발음" 추천 기능처럼 자주 사용되는(또는 흔히 잘못 사용되는) 표기를 검색 시 함께 제안하는 방식이다. 둘째, 외국어의 정확한 우리말 표기를 확인하는 가장 효율적인 방법으로 위키백과의 다른 언어판 문서 제목을 참조하는 것이다. 검색엔진이 결과에 위키백과 노출을 우선하는 것에 더해, 원어와 표준 표기를 추천어로 함께 보여주면 이런 표기 불일치로 인한 검색 실패를 줄일 수 있다.

모바일 환경의 텍스트 입력 부담을 줄이는 또 다른 접근으로 초성검색 자동완성이 있다. 2010년 다음(Daum) 모바일과 아이폰 앱이 도입한 초성입력 검색어 자동완성은 자음만 입력해도(예: "서울동물원"→"ㅅㅇㄷㅁㅇ") 매칭되는 장소를 찾아주지만, 검색 빈도가 낮은 장소명은 자동완성에 뜨지 않아 사용자가 초성을 지우고 완성형 음절로 다시 입력해야 하는 문제가 있었다. 이에 대한 해결책으로 ① 초성만으로도 매칭되는 장소(POI) 결과를 지역별로 그룹핑해 나열하는 방식, ② 초성과 음절을 섞어 입력할수록 매칭 결과가 좁혀지는 초성+음절 혼합 검색(아이나비 내비게이션 사례)이 제시됐다. 이런 초성 매칭은 검색 빈도가 낮은 결과일수록 예측 실패 확률이 높아지므로, 자동완성 목록에만 의존하지 말고 매칭 결과 자체를 보여주는 대안 경로가 함께 필요하다는 것을 보여준다. 같은 글에서는 검색 이후 길찾기로 이어지는 흐름의 UX도 함께 다뤄지는데, 위치 검색 결과가 기능이 제한된 모바일 웹페이지로 연결되는 대신 커스텀 URL 프로토콜(예: `fb://`처럼 앱 고유 스킴으로 링크를 열어 네이티브 지도 앱을 바로 실행하는 방식)을 활용하면 검색에서 길찾기까지 끊김 없이 이어지는 경험을 만들 수 있다고 제안한다.

예측 검색(인스턴트 서치)이 항상 긍정적인 경험만 주는 것은 아니다. 2011년 사례에서는 특정 상호명을 입력하는 도중, 아직 완성되지 않은 중간 글자 조합(예: "도", "도쿄")만으로 구글이 best matching suggestion 알고리즘에 따라 유튜브 성인물 검색 결과와 관련 이미지 썸네일을 최상단에 노출하는 문제가 발생했다. 원인은 두 가지가 겹친 것으로 분석됐다 — ① 입력 중인 키워드 자체가 아니라 예측된 키워드로 결과를 미리 보여주는 인스턴트 서치의 구조적 특성상 사용자가 원치 않는 중간 결과에 계속 노출된다는 점, ② 유튜브 영상 검색과 연관 검색어(suggestion) 단계에서 성인물에 대한 블랙리스트 필터링이 제대로 작동하지 않았다는 점이다. 이는 자동완성·예측 검색 설계 시 인지 부담 감소나 노이즈 최소화 못지않게, 노출되는 콘텐츠에 대한 안전장치(필터링·블랙리스트)가 함께 뒷받침되지 않으면 오히려 불쾌한 사용경험을 유발할 수 있다는 반례를 보여준다.

핵심 내용

  • 인스턴트/증분 검색(incremental search)의 원형: 2005년 macOS 스팟라이트 → 사파리 플러그인 인퀴지터(2008년 야후 인수) → 개인 프로젝트 À la carte 검색/QuickFind — 2010년 구글 인스턴트보다 수년 앞서 검증된 패턴
  • 통합검색 vs 유니버설 서치: 둘 다 유형별 파편화 해소가 목적이지만, 구글은 웹 결과 우선 + 관련 유형 추가, 네이버·다음은 모든 유형을 남김없이 분할 노출
  • 통합검색의 장점: recognition over recall + serendipity(훑어보다 발견), scroll is the new click(스크롤 비용 저렴화), 전문 검색엔진 진입 비용 절감
  • 통합검색의 한계: 의도를 모른다는 이유로 모든 컬렉션을 나열하면 오히려 스캔 비용 증가(satisficing·정보 과부하), F자 아이트래킹 힛맵은 "상단이 중요한 증거"가 아니라 "헤매고 있다는 증거"로 재해석 가능, 검색광고 수익 구조가 통합검색 채택의 실질적 동기라는 비판
  • Search User Goals: navigational · informational(최대 비중) · transactional 3분류, informational은 질문 유형별로 세분
  • Domain knowledge: 주제 지식 수준에 따라 질문 방식이 달라지고, 검색은 반복적 오리엔티어링에 가까움
  • 검색의 파레토 법칙: 소수 소스(위키백과·구글웹·네이버블로그)가 실사용의 약 80%를 커버
  • 예측 가능한 고정 배치(1-3-5)로 스캔 효율 개선, 나머지는 전문 검색엔진 링크로 위임
  • URL 정보 위계: 서버 주소 ≫ 페이지 이름 > 서브 경로 ≫ 프로토콜 — 트위터의 `http://`/`www.` 제거·URL 줄임이 대표 사례
  • 구글은 URL을 제목 아래로 이동·중간 경로 생략·브레드크럼으로 대체, 야후·네이버·다음은 URL 전체 나열 + 가변 폭 줄 길이 문제
  • 파비콘을 도메인 텍스트보다 효율적인 출처 표현 수단으로, 링크 밑줄 제거·본문 전체 링크화로 클릭 영역 확대
  • 검색어 자동완성: 단일 예측 결과 + 입력 종료 시점 감지로 인지 부담과 노이즈 최소화
  • 초성검색 자동완성(2010, 다음 모바일): 자음만으로 장소 검색, 저빈도 결과는 초성만으로 매칭 실패 → POI 그룹핑·초성+음절 혼합 검색으로 보완
  • 검색 결과에서 길찾기 앱으로 넘어갈 때 커스텀 URL 프로토콜로 네이티브 지도 앱을 직접 실행하면 흐름이 끊기지 않음
  • 정보를 펼쳐 놓기(Tufte) — 마우스 오버 의존 UI보다 한눈에 비교 가능한 노출이 효과적
  • 모바일 검색 제안 UI: 플랫폼 제약(iOS3 입력창 이동)에 대응한 디바이스 특화 설계, 정렬 vs 노출량 트레이드오프에서는 결국 정렬이 우선
  • 콘텐츠 필터링 실패 사례: 예측 검색(인스턴트 서치)이 블랙리스트 필터링 없이 작동하면 의도치 않은 성인물 등 노출로 불쾌한 사용경험을 유발할 수 있음
  • 아이패드 검색창 디테일 3가지(2011): 컨텍스추얼 키패드(`type="search"`) 미대응, 사파리 프리셋 스타일과 검색창 아이덴티티 충돌, 검색어 추천과 아이패드 자동 수정 기능의 충돌
  • 외국어 고유명사 표기 불일치: 검색어의 우리말 표기가 실제 통용 표기와 다르면 신뢰도 높은 문서 대신 부정확한 결과가 상위 노출될 수 있음 — 외래어발음 추천, 위키백과 다른 언어판 제목 참조로 보완 가능

관련 개념

출처

최종 업데이트: 2026-09-06 | 출처 9개