검색창 디자인: 검색어 입력부터 결과와 복귀까지

좋은 검색창은 무엇을 검색할 수 있는지 알려 주고, 사용자가 자기 말로 검색어를 입력하도록 도우며, 다음 행동의 결과를 예측할 수 있게 합니다. 돋보기 아이콘만 넣는 것으로 끝나지 않습니다. 입력란, 추천 항목, 검색 실행과 돌아가기 경로가 ‘목록에서 검색하는 것’과 ‘이미 아는 항목을 바로 여는 것’을 일관되게 구분해야 합니다.

먼저 검색할 대상과 과제를 정하세요. 프로젝트 라이브러리에서 디자이너는 프로젝트 이름이나 고객사, 디자인 검토에 쓰인 문구만 기억할 수 있습니다. 검색은 내비게이션의 분류와 이동 경로를 보완하는 기능이지, 아무도 이해하지 못하는 분류를 대신 해결하는 기능이 아닙니다. 여기서는 입력한 내용을 잃지 않고 ‘Spring launch’ 프로젝트를 찾는 과정을 설계합니다. 뒤에서는 기존 숙박 검색 사례에 같은 원칙을 적용해 필터와 오류 복구까지 살펴봅니다.

검색창이 무엇을 찾아 주는지 먼저 설명하세요

주변 화면만 봐도 검색 대상이 명확하다면 ‘검색’이라는 이름으로 충분합니다. 하지만 같은 헤더에서 프로젝트, 사람, 파일, 도움말까지 찾을 수 있다면 부족합니다. 사라지지 않는 레이블, 가까운 제목, 명시적인 선택기로 범위를 보여 주세요. 플레이스홀더에는 예시를 넣을 수 있지만 입력하는 순간 사라지므로 설명 전체를 맡겨서는 안 됩니다.

프로젝트 라이브러리에는 ‘프로젝트 검색’이라는 레이블을 쓰고, ‘프로젝트 이름 또는 고객사’라는 예시로 어떤 기억이 도움이 되는지 알려 줍니다. 검색 서비스가 이름만 색인한다면 댓글도 검색할 수 있다고 약속하지 마세요. 보관된 프로젝트를 제외한다면 결과 근처에 설명하거나 ‘보관된 프로젝트 포함’ 필터를 제공합니다. 드러나지 않는 제외 조건은 정상적인 검색도 고장 난 것처럼 느끼게 합니다.

전체 검색과 특정 영역 검색은 관련된 모습이되 같은 기능으로 오해되지 않아야 합니다. 청구서 표 위의 필드는 ‘청구서 검색’이라고 쓰고, 워크스페이스 전체 검색은 여러 유형을 다룰 수 있습니다. 전체 검색에서 청구서를 열어 이동하는 것과 현재 표를 좁혀 보는 것을 구분하세요. 같은 모양의 조작 요소가 페이지마다 규칙을 바꾸는 것처럼 보여서는 안 됩니다.

검색창 위치는 과제의 우선순위에 맞추세요

검색이 주요 진입점인 서비스에서는 상단의 잘 보이는 위치가 유용합니다. 다음 화면 사례처럼 검색 영역을 다른 탐색 요소와 구분하면 찾기 쉽습니다. 그렇다고 모든 페이지에 검색창을 고정해야 하는 것은 아닙니다. 읽기나 편집이 주된 화면에서는 화면 공간과 검색 접근성을 함께 고려하세요.

입력, 지우기, 검색 실행의 역할을 나누세요

‘검색’이라는 짧은 단어만 맞춰 보지 말고 실제 검색어를 읽을 만큼 입력란을 넓게 만드세요. 짧은 이름과 ‘Spring launch — client review’ 같은 긴 문구를 모두 넣어 봅니다. 긴 값은 필드 안에서 스크롤될 수 있지만 검색 버튼을 밀거나 지우기 버튼을 가려서는 안 됩니다. 눈에 보이는 포커스, 안정적인 접근 가능한 이름, 플레이스홀더에만 의존하지 않는 대비도 필요합니다.

이 라이브러리에서는 추천 항목을 선택하지 않은 채 Enter를 누르면 입력한 전체 검색어로 검색합니다. 검색 버튼도 같은 동작을 합니다. 지우기는 텍스트와 추천 목록만 지우고 현재 페이지를 떠나지 않습니다. 완성된 컴포넌트를 꾸미기 전에 정해야 할 규칙입니다. ‘검색’ 버튼이 예고 없이 첫 번째 프로젝트를 열어서는 안 됩니다.

빈 입력을 제출했을 때의 동작도 정하세요. 검색이 필수라고 오류를 보여 주기보다 기본 라이브러리 탐색 상태를 유지하는 편이 명확할 수 있습니다. 정말 검색어 없이는 작업할 수 없는 화면이라면 무엇을 입력할지 안내하세요. 아무것도 검색하지 않았는데 검색에 실패한 것처럼 보이는 빈 결과 화면을 만들지 마세요.

추천 검색어와 바로 열 항목을 구분하세요

추천 항목은 검색어를 완성하도록 돕거나, 검색 단계를 건너뛰고 아는 항목을 바로 열게 할 수 있습니다. 둘 다 유용하지만 각 행이 무엇을 하는지 보여 줘야 합니다. 이 예제에서는 ‘spring’을 입력하면 ‘추천 검색어’ 아래에 ‘spring launch 검색’을, ‘프로젝트’ 아래에 이름이 정확히 ‘Spring launch’인 항목을 보여 줍니다. 앞의 항목은 검색을 실행하고, 뒤의 항목은 프로젝트를 엽니다.

일치하는 단어만으로는 두 행을 구분할 수 없습니다. 유형과 간단한 맥락을 더하세요. 예를 들어 ‘프로젝트 · Studio team’은 같은 이름의 프로젝트를 구분하는 데 도움이 됩니다. 응답이 도착할 때도 이 맥락을 안정적으로 유지합니다. 사용자가 두 번째 항목을 누르려는 순간 목록을 재정렬해 다른 항목을 선택하게 해서는 안 됩니다.

라이브러리에서의 행동	화면의 동작	계속 표시할 정보
‘spring’ 입력	아무 항목도 열지 않고 관련 추천을 표시합니다.	입력한 검색어와 ‘프로젝트 검색’ 범위
‘spring launch 검색’ 선택	해당 검색어로 결과 페이지를 엽니다.	수정할 수 있는 필드에 표시된 검색어
‘Spring launch’ 프로젝트 선택	확인된 프로젝트를 엽니다.	이전 검색으로 돌아가는 분명한 경로
선택한 행 없이 Enter 누르기	현재 입력값을 그대로 검색합니다.	고르지 않은 추천어가 아닌 원래 입력 문구
추천 목록 닫기	검색을 실행하지 않고 팝업을 닫습니다.	수정하거나 제출할 수 있는 검색어

긴 추천 목록은 없는 것보다 나쁠 수 있습니다. 정해 둔 행 수를 채우기보다 짧고 관련 있는 목록을 우선하세요. 다른 서비스에서 가져올 수 있다는 이유만으로 프로젝트 전용 검색에 도움말을 섞지 마세요. 추천이 실제 수고를 줄일 만큼 신뢰할 수 없다면 명확한 입력란과 검색 실행 버튼부터 만드는 편이 낫습니다.

추천 콘텐츠는 검색 결과와 다르게 표시하세요

최근 검색어, 인기 검색어, 추천 콘텐츠는 각각 역할이 다릅니다. 최근 검색어는 이전 행동을 이어 가게 하고, 인기 검색어와 콘텐츠는 새로운 탐색을 제안합니다. 커머스에서 이런 항목을 함께 보여 주더라도 제목과 묶음을 구분해야 사용자가 자신의 검색과 일치한 결과인지 알아볼 수 있습니다.

최근 검색어와 자동 완성을 구분하세요

자동 완성은 지금 입력한 문구를 돕고, 최근 검색어는 과거 입력을 다시 쓰게 합니다. 계정·태그·장소처럼 결과 유형이 다르면 유형도 표시하세요. 최근 검색어를 저장한다면 개별 삭제와 전체 삭제 경로를 함께 설계합니다.

키보드와 불안정한 연결을 함께 고려하세요

입력 가능한 추천 필드는 W3C의 콤보박스 패턴(영문)에서 키보드와 접근성 동작을 참고할 수 있습니다. 아래쪽 방향키로 추천 목록에 들어가고, Enter로 선택한 항목을 확정하며, Escape로 팝업을 닫습니다. 일반적인 텍스트 편집도 계속 가능해야 합니다. 접근 가능한 이름은 검색어 자체가 아니라 검색 필드의 역할을 설명합니다.

이 규칙도 실제 설계에서는 구체적인 선택이 필요합니다. 이 예제에서는 목록이 나타났다는 이유로 첫 추천을 자동 선택하지 않습니다. 행에 강조 표시가 있다면 사용자가 그 행으로 이동했다는 뜻입니다. 강조된 행이 없으면 Enter는 입력한 문구를 검색합니다. 프로토타입으로 이 차이를 전달하되, 키보드와 보조 기술의 동작은 실제 컴포넌트에서도 확인해야 합니다.

‘spring’의 응답을 기다리는 중 사용자가 ‘summer’로 바꿨다고 해 보겠습니다. 이전 응답이 도착해도 새 검색어의 결과인 것처럼 목록을 채워서는 안 됩니다. 이 요구사항을 디자인 옆에 기록하세요. 짧은 지연 동안에는 입력란을 계속 쓰게 하고, 지연이 눈에 띄면 추천 영역 안에 간결한 로딩 안내를 보여 줍니다. 백그라운드 추천 요청 때문에 페이지 전체를 로딩 화면으로 바꾸지 마세요.

추천 기능만 실패하고 일반 검색은 동작한다면 검색 실행 경로를 유지합니다. ‘추천 검색어를 불러올 수 없습니다. Enter를 눌러 검색해 주세요’는 복구 가능한 문제를 설명합니다. 검색 전체를 사용할 수 없다면 입력값을 보존하고 다시 시도할 수 있게 하세요. 로딩, 요청 실패, 실제 추천 없음은 처음에는 선택할 행이 없다는 점이 같아도 서로 다른 상태입니다.

모바일 검색에는 입력하고 돌아올 공간을 주세요

좁은 화면에서는 작은 검색 아이콘으로 전용 검색 화면을 열 수 있습니다. 아이콘에는 접근 가능한 이름을 주고, 열린 화면에는 보이는 입력란, 명확한 닫기, 화면 키보드를 위한 공간을 마련하세요. 사용자가 검색을 열었을 때 필드로 포커스를 옮기되 라이브러리에 방문할 때마다 자동으로 옮기지는 마세요. 뜻하지 않은 키보드가 검색하기도 전에 내용을 가립니다.

검색 범위와 항목 동작은 데스크톱과 같아야 합니다. 레이블을 넣을 공간이 부족하다고 프로젝트를 여는 추천이 모바일에서는 검색어로 바뀌어서는 안 됩니다. 행동의 구분을 지우기 전에 부가 정보를 줄이세요. ‘Demo’만 넣지 말고 실제로 쓸 법한 가장 긴 프로젝트 이름도 확인합니다.

프로젝트를 열었다가 돌아오면 제출한 검색어와 유용한 결과 위치를 복원합니다. 반면 아직 제출하지 않은 모바일 검색을 취소했다면 떠나기 전 라이브러리 상태로 돌아갑니다. 두 종료 방식은 다른 의도를 나타냅니다. 각각을 지켜야 검색이 돌아올 수 없는 우회로처럼 느껴지지 않습니다.

입력 방법은 검색 대상에 맞춰 추가하세요

키워드 입력 외에 음성, 바코드, QR 코드, 사진으로 검색하게 할 수도 있습니다. 제품 포장을 보고 매장 상품을 찾는 일과 이름으로 프로젝트를 찾는 일은 입력 자료부터 다릅니다. 필요한 대상을 서비스가 실제로 인식할 수 있고, 권한 요청을 거절했을 때 텍스트 검색으로 돌아갈 수 있을 때 추가하세요. 아이콘 수가 많다고 검색이 편해지는 것은 아닙니다.

필터가 있는 숙박 검색에서는 조건을 따로 관리하세요

프로젝트 라이브러리와 달리 숙박 검색은 목적지, 날짜, 인원과 숙소 특성이 함께 결과를 결정합니다. 카테고리에 맞는 필터를 고르세요. 가격, 색상, 인기도를 모든 서비스에 똑같이 쓰기보다 실제 선택에 필요한 조건을 우선합니다.

서로 함께 성립할 수 있는 조건은 여러 개를 고르게 할 수 있습니다. 식당에서 반려동물 동반, 야외 좌석, 채식 메뉴를 함께 찾는 경우가 그렇습니다. 다만 모든 필터를 다중 선택으로 만들 필요는 없습니다. 서로 배타적인 조건은 관계를 설명하고, 적용된 필터와 해제 위치를 결과 근처에서 찾기 쉽게 보여 주세요.

결과 없음과 요청 실패에 같은 안내를 쓰지 마세요

일치하는 결과가 없으면 현재 검색어와 적용된 조건을 보여 주고, 조건 하나를 해제하거나 검색어를 바꾸게 합니다. 추천 콘텐츠는 별도의 제목 아래에 두어 결과처럼 보이지 않게 하세요. 서버 응답 실패에는 조건을 바꾸게 하는 대신 기존 입력으로 다시 시도하는 경로가 필요합니다.

숙박 검색에서 보존해야 할 입력과 상태

목적지, 날짜, 인원을 입력한 뒤 숙소 유형을 고르는 상황을 가정해 보겠습니다. 숙소 유형만 바꿨는데 날짜까지 사라지면 같은 입력을 반복해야 합니다. 각 동작이 어느 조건을 바꾸는지 먼저 구분하세요. 목적지를 등록된 장소에서 고르게 한다면 입력한 검색어와 확정된 선택도 구분해야 합니다.

숙박 검색 화면을 Pixso에서 비교할 때는 정상 결과뿐 아니라 결과 없음과 요청 실패를 나란히 놓습니다. 두 상황의 안내와 버튼이 달라야 사용자가 조건을 바꿀지, 잠시 뒤 다시 시도할지 판단할 수 있습니다.

Pixso에서 입력부터 결과까지 연결하세요

프로젝트 사례에서는 기본 라이브러리, ‘spring’ 추천 팝업이 열린 라이브러리, ‘spring launch’ 검색 결과의 세 화면을 Pixso에 만듭니다. 필드와 레이블을 프레임마다 일관되게 유지하세요. 바로 열기 동작을 검토해야 할 때는 프로젝트를 연 네 번째 화면도 추가합니다. Pixso의 인터랙티브 프로토타입 기능으로 화면 전환을 연결하고 팀과 경로를 논의할 수 있습니다.

검토자에게 ‘검색을 써 보세요’가 아니라 ‘봄 출시를 위한 고객 검토 프로젝트를 찾아 주세요’라는 과제를 주세요. 범위를 이해하는지, 추천 항목의 동작을 예상하는지, 프로젝트에서 돌아왔을 때 위치가 유지되는지 살펴봅니다. 다음에는 유용한 추천이 없는 검색어와 모바일의 긴 프로젝트 이름을 시험하세요. 컴포넌트가 깔끔해 보이는지만 묻는 것과는 다른 문제를 발견할 수 있습니다.

기존 숙박 예약 화면에서는 숙소 유형과 위치, 체크인 시간, 인원 같은 조건이 어디에 놓이는지 살펴볼 수 있습니다. 각 조건을 지우는 범위와 변경 후 결과를 함께 설계하세요.

Pixso에서 요소의 크기, 간격, 색상과 코드 정보를 확인해 화면 사양을 전달할 수 있습니다. 이 정보가 검색 기능이나 완성된 HTML 페이지를 자동으로 만드는 것은 아닙니다. 검색 요청 시점, 조건을 지우는 범위, 실패 뒤 복구 동작은 화면과 설명으로 함께 전달하세요.

검색 의도를 잃지 않는 흐름을 만드세요

개발자 전달에는 Enter의 동작, 추천 항목의 선택 표시, 지우기의 범위, 돌아왔을 때 복원할 상태를 명확히 적습니다. 좋은 검색은 팝업에 가장 많은 행을 넣는 것이 아니라, 사용자가 의도를 잃지 않고 계속 좁혀 갈 수 있게 하는 설계입니다.

Pixso에서 검색 흐름 설계하고 검토하기 →