검색 결과 카드 디자인: 검색된 이유를 보여 주세요

검색 결과 세 개에 같은 단어가 들어 있어도 각각 답하는 질문은 다를 수 있습니다. “내보내기”를 검색한 사람에게 필요한 것은 브라우저에서 따라 할 절차일 수도, API 엔드포인트일 수도, 최신 릴리스에서 기능이 바뀌었는지에 대한 확인일 수도 있습니다. 검색어가 들어 있는 제목만 나열해서는 어느 결과가 도움이 될지 충분히 알기 어렵습니다.

검색 결과 카드 디자인은 사용자가 클릭하기 전에 그 판단을 할 수 있게 만드는 작업입니다. 각 결과에 알아볼 수 있는 문서 유형, 어디로 이어지는지 보여 주는 정보, 검색어와의 관련성을 설명할 충분한 맥락을 담으세요. 목적은 검색 엔진의 순위를 꾸미는 것이 아니라, 나열된 결과에 실제로 무엇이 있는지 독자가 판단하도록 돕는 것입니다.

검색 결과 세 개와 하나의 구체적인 작업에서 시작하세요

가상의 보고서 제품을 생각해 봅시다. 고객 지원 담당자는 필터가 적용된 보고서를 브라우저에서 CSV 파일로 내려받아야 합니다. 도움말 문서에서 “내보내기”를 검색하니 아래 세 결과가 나옵니다. 다음 제목과 발췌문은 하나의 예시 콘텐츠 묶음입니다. 레이아웃을 비교할 때도 같은 내용을 유지하세요.

이 작업은 튜토리얼에서 시작하는 것이 적절합니다. API 레퍼런스는 프로그램으로 실행하는 동작을 설명하고, 릴리스 노트는 전체 사용 절차를 안내하기보다 변경 사항을 설명합니다. 내보내기 요청이 무엇을 반환하는지 알고 싶은 개발자라면 같은 목록에서 다른 문서를 고를 것입니다. 어느 결과가 모든 상황에서 “더 좋은” 것은 아닙니다.

여기서는 검색 결과가 이미 있는 상황을 다룹니다. 필터 컨트롤을 바꾸거나 결과가 없을 때 안내하는 일은 탐색 과정의 다른 문제를 해결합니다. 그 부분이 문제라면 필터 UI 디자인 안내(영문)나 빈 상태 디자인 패턴을 참고하세요. 지금은 후보 문서가 있고, 독자가 그 차이를 알아볼 수 있어야 합니다.

제목 옆에 문서 유형과 위치를 보여 주세요

“튜토리얼”, “API 레퍼런스”, “릴리스 노트”처럼 문서가 어떤 방식으로 도움을 주는지 나타내는 짧은 유형명을 사용하세요. 아이콘은 이를 보조할 수 있지만 일반적인 페이지 모양만으로 차이를 전달하기는 어렵습니다. 튜토리얼이 첫 번째라는 이유만으로 “추천”을 붙이지 마세요. 그러면 카드에서 근거를 설명하지 않은 평가를 내리는 셈이 됩니다.

경로는 또 다른 맥락을 제공합니다. “API v2 › 보고서 › 내보내기”는 특정 API 버전에서 이 엔드포인트가 속한 위치를 보여 줍니다. “가이드 › 보고서 › 내보내기”는 일반 사용자의 작업 절차에 속한 안내임을 알려 줍니다. 모든 내부 검색 결과에 긴 호스트 이름을 반복하면 공간은 쓰지만 도착점의 차이는 드러나지 않습니다. 결과가 실제로 여러 사이트에 걸쳐 있고 출처가 선택에 중요할 때 도메인을 보여 주세요.

제목을 문서로 이동하는 기본 링크로 사용하세요. 각 행에 똑같은 “열기” 링크만 있으면 링크를 따라 탐색하는 사람이 목적지를 구분하기 어려워집니다. W3C의 링크 목적 안내(영문)는 링크 텍스트나 프로그램이 파악할 수 있는 맥락으로 목적을 알 수 있도록 설명합니다. 화면에서 가깝게 놓는 것만으로 그 관계가 형성되지는 않습니다. 구현 시 각 결과를 의미상 하나의 묶음으로 구성하고, 열리는 페이지의 제목이 목록에서 설명한 내용과 일치하도록 하세요.

이 사례의 경로는 설명용 텍스트이며, 별도의 탐색 링크 세 개가 아닙니다. 이렇게 하면 핵심 선택을 문서 열기에 집중할 수 있습니다. 제품에서 분류별 탐색도 제공한다면, 작은 경로 조각마다 알리지 않고 링크를 붙이기보다 명확한 보조 동작으로 설계하세요.

원문의 뜻을 바꾸지 않으면서 검색된 이유를 보여 주세요

문서 소개와 검색어에 따라 달라지는 발췌문은 역할이 다릅니다. 소개는 문서 전체를 요약하고, 발췌문은 그 안의 관련 부분을 보여 줍니다. 튜토리얼의 “보고서를 열고”라는 문장은 브라우저에서의 절차임을 알 수 있어 유용합니다. 이미 구체적인 제목 아래에 “보고서 내보내기의 모든 것을 알아보세요”를 반복해도 판단 근거는 거의 늘어나지 않습니다.

Algolia의 강조 표시·스니펫 안내(영문)는 일치하는 검색어를 강조하고 주변 단어를 함께 반환하는 방식을 설명합니다. 이런 기능은 검색어가 어디에 등장하는지 보여 줄 수 있습니다. 그러나 그 문서가 사용자의 질문에 답하는지, 최신인지, 다른 결과보다 앞에 나올 만한 이유가 있는지까지 입증하지는 않습니다.

발췌문을 줄일 때는 의미를 한정하는 문장을 지키세요. API 결과에는 “CSV 파일이 아니라 작업 ID”라는 내용을 남겨야 합니다. 그렇지 않으면 지원 담당자가 파일을 바로 내려받는 방법으로 오해할 수 있습니다. 릴리스 노트에서도 “예약 내보내기가 추가되지 않습니다”를 유지해야 합니다. 문장을 부정 표현 앞에서 잘라내거나 “예약 내보내기”만 발췌하면 독자에게 필요한 정보가 달라집니다.

일정한 글자 수에서 끊고 말줄임표를 붙이기보다, 공간에 맞으면서 뜻이 통하는 완전한 문장이나 구절을 선택하세요. 안전 조건이나 제약을 담을 수 없다면 한 줄을 더 허용하거나, 뜻을 바꾸지 않는 더 짧은 부분을 고릅니다. 검색 색인에 쓸 만한 발췌문이 없다면 실제 문서 소개를 대신 쓰고 요약임을 나타내세요. 인용문을 지어내거나 검색어가 일치하는 부분인 것처럼 표현해서는 안 됩니다.

문장을 편하게 읽을 수 있을 정도로만 강조 표시를 사용하세요. 제목과 스니펫에 검색어가 있다고 카드 전체를 칠할 필요는 없습니다. MDN의 mark 요소 안내(영문)에 따르면 이 요소는 현재 맥락과 관련된 텍스트를 나타내며, 대부분의 스크린 리더는 기본적으로 그 강조를 알려 주지 않습니다. 색으로 표시한 부분이 없어도 발췌문의 뜻은 통해야 합니다. 중요한 차이는 텍스트로 명확히 표현하세요.

어떤 정보에 공간을 할애할지 정하세요

유용한 카드는 문서 대시보드를 작게 줄여 놓은 화면이 아닙니다. 각 필드가 독자의 어떤 판단을 돕는지, 작은 레이아웃에서도 어느 부분을 유지해야 하는지 정하세요. 다음 규칙은 보고서 사례에 맞춘 것입니다. 다운로드 가능한 파일 목록이라면 필요한 정보가 달라질 수 있습니다.

서로 다른 필드에 같은 정보를 중복하지 마세요. API 경로에 이미 “v2”가 있으므로 버전 배지를 반드시 하나 더 붙여야 하는 것은 아닙니다. 반대로 모든 행의 높이를 맞추려고 중요한 차이를 없애서도 안 됩니다. 릴리스 노트의 버전이 튜토리얼의 수정일보다 더 중요한 판단 기준일 수 있습니다.

내용이 없는 메타데이터 자리는 카드에 표시하지 마세요. 검토일이 없다면 임의의 수집 시각을 “수정됨” 아래에 보여 주기보다 해당 필드를 생략하는 편이 정확합니다. 분류가 빠진 문제도 원래 콘텐츠 모델에서 해결해야 합니다. 장식용 아이콘을 보고 문서 유형을 추정해도 된다는 뜻은 아닙니다.

카드 테두리뿐 아니라 판단에 필요한 정보도 재배치하세요

좁은 화면에서는 제목과 유형부터 배치하고, 문서를 구분하는 경로와 뜻이 통하는 발췌문을 유지하세요. 내보내기 문서 세 개를 구별하는 단어를 지우기 전에 반복적인 장식부터 줄입니다. 유형, 날짜, 작성자, 경로, 버전을 회색 한 줄에 모두 넣으면 공간에 들어가더라도 정보를 나누어 읽기 어렵습니다.

긴 제목은 줄바꿈하고 실제 문구로 테스트하세요. 두 줄 스니펫은 시작 레이아웃으로 유용하지만, 모든 언어와 모든 조건 문장이 두 줄 안에 들어간다는 보장은 아닙니다. 릴리스 노트에서는 세 카드의 높이를 정확히 맞추는 것보다 예약 내보내기를 추가하지 않았다는 부정 문장을 유지하는 것이 중요합니다.

Algolia가 공개한 문서 검색 개편 사례(영문)에서 구체적인 비교를 볼 수 있습니다. 데스크톱에는 결과 목록과 미리보기를 함께 두고, 모바일·태블릿에서는 미리보기 대신 짧은 설명을 사용했습니다. 콘텐츠 유형별로 결과를 묶은 방식도 설명합니다. 이는 해당 구현에서 내린 선택이지, 모든 검색 인터페이스에 미리보기나 같은 그룹 구성이 필요하다는 근거는 아닙니다.

결과가 세 개라면 각 카드 안의 유형명만으로 충분할 수 있습니다. 영역을 나누면 정보를 정리하는 효과보다 제목만 늘어날 수 있습니다. 결과가 많아 그룹화가 도움이 된다면 그룹 이름과 탐색 순서를 분명히 하세요. 선택적으로 제공하는 미리보기는 세부 정보를 더해야지, 결과가 무엇인지 알아보는 유일한 장소가 되어서는 안 됩니다. 마우스를 올리지 않아도 도움이 될 결과를 고르고 열 수 있어야 합니다.

선택하는 순간에도 각 필드의 정보를 믿을 수 있어야 합니다

카드의 제목, 발췌문, 경로, 버전은 같은 문서를 가리켜야 합니다. 최신 제목에 구판의 발췌문을 붙이면 그럴듯하지만 오해를 부르는 결과가 됩니다. 예시 API 결과에 “API v2”라고 표시했다면, 열었을 때 설명 없이 다른 버전의 문서로 보내서는 안 됩니다. 이동되거나 대체되거나 오래된 문서를 어떻게 나타낼지 검색 색인·콘텐츠 담당자와 정하세요.

검색 색인에 남아 있다는 이유만으로 공개가 제한된 제목이나 발췌문을 노출하지 마세요. OWASP는 요청마다 권한을 검증하도록 권장합니다(영문). 이를 검색에 적용하면, 어떤 메타데이터를 공개할 수 있는지 정하고 문서를 열 때뿐 아니라 결과를 반환할 때도 그 정책을 적용해야 한다는 뜻입니다. 목록을 불러온 뒤 접근 권한이 달라질 수도 있습니다. 결과를 열 때 현재 권한을 따르고, 보호되는 발췌문을 공개하지 않으면서 적절한 복구 상태를 보여 주세요.

기본 동작은 해당 문서에 맞아야 합니다. “보고서를 CSV로 내보내기”를 열면 안내 문서가 나와야지 다운로드가 시작되어서는 안 됩니다. “지금 내보내기”는 결과에 영향을 주는 별도의 제품 동작이며, 그에 맞는 권한 확인과 상태 처리가 필요합니다. 검색어에 어떤 동작의 이름을 썼다고 그 동작을 실행할 권한이 생기지는 않습니다.

카드를 다듬기 전에 Pixso에서 같은 콘텐츠로 검토하세요

Pixso 디자인 파일에 검색 결과 카드 컴포넌트를 만들고 제목, 유형, 경로, 발췌문을 별도의 텍스트 레이어로 구성하세요. 위의 예시 콘텐츠 그대로 인스턴스 세 개를 채웁니다. 제목만 있는 초기 프레임, 정보를 보강한 결과 프레임, 좁은 화면 프레임을 준비하세요. 같은 문서를 비교해야 추가한 맥락이 어떤 도움을 주는지 알기 쉽습니다. 버전마다 제목을 바꾸면 비교 결과에 그 차이까지 섞입니다.

좁은 프레임에서는 간격뿐 아니라 어떤 내용을 유지할지도 결정하세요. 튜토리얼 제목은 줄바꿈하고, API 응답의 한정 조건과 릴리스 노트의 예약 내보내기 관련 문장은 남깁니다. 조건에 따라 표시하는 필드와 잘라내기 규칙은 컴포넌트 옆에 주석으로 기록하세요. 구현 담당자가 어떤 단어를 빼도 되는지 추측하게 해서는 안 됩니다.

프로토타입에서 결과 제목을 해당 문서 프레임으로 연결하고, 검색어를 유지한 채 돌아갈 경로도 제공하세요. 이는 탐색 결정을 표현하는 모델이지 동작하는 검색 색인이 아닙니다. 캔버스 위의 보고서 앱은 검토 중인 디자인이며, Pixso 자체의 검색 동작을 보여 주는 것이 아닙니다.

동료에게 브라우저에서 필터가 적용된 보고서를 CSV로 내려받는 데 필요한 문서를 골라 달라고 요청하세요. 이어 API가 무엇을 반환하는지 찾는 과제와, 릴리스 2.8에서 예약 내보내기가 도입되었는지 확인하는 과제도 제시합니다. 각 선택을 뒷받침한 필드가 무엇인지 들어 보세요. 가장 최근처럼 보이는 날짜가 항상 가장 좋은 답이라고 가정하는 등 잘못된 이유로 맞는 카드를 클릭해도 디자인 문제는 남아 있습니다.

마지막으로 키보드 탐색과 더 큰 글자 크기에서 같은 경로를 확인하세요. 독자가 어디로 이동할지 알아보고, 제약을 끝까지 읽고, 검색어를 다시 만들지 않아도 돌아올 수 있을까요? 문제가 드러난 필드나 발췌문을 다듬으세요. 성공은 행을 더 화려하게 꾸미거나 클릭 수를 늘리는 데 있지 않습니다. 문서들 사이에서 왜 그것을 골랐는지 설명할 수 있는 선택이어야 합니다.

Pixso에서 정보가 충실한 검색 결과 페이지를 디자인해 보세요 →