웹 서비스 검색 기능, 필터와 정렬 데이터를 먼저 설계하는 법

“검색창만 넣으면 사용자가 원하는 항목을 바로 찾을 수 있지 않을까?”

“필터는 화면 디자인이 나온 뒤에 정해도 늦지 않을까?”

“정렬 순서는 최신순 하나면 충분한지 판단이 서지 않는다.”

검색 기능은 검색창을 추가하는 일이 아니라, 사용자가 무엇을 어떤 기준으로 찾을지 데이터와 운영 규칙으로 정하는 일입니다. 검색어, 필터, 정렬의 역할을 나누고 관리자 입력 방식까지 연결해야 결과 기준을 운영 중에도 설명하고 바꿀 수 있습니다.

크로플을 운영하며 웹과 앱, 업무 시스템을 포함한 50건 이상의 SI 수탁개발에서 기획과 개발을 함께 맡아 왔습니다. 검색 기능이 뒤늦게 요구사항에 들어오는 경우, 막히는 지점은 검색 화면 자체보다 기존 데이터에 검색 기준이 없는 상황인 경우가 많았습니다. 그래서 검색 기능을 논의할 때는 화면보다 먼저 “어떤 값을 저장하고 누가 관리할 것인가”를 확인합니다.

검색어, 필터, 정렬을 왜 나누어 설계해야 할까요?

검색어는 사용자의 표현으로 대상을 찾고, 필터는 구조화된 조건으로 결과를 좁히며, 정렬은 남은 결과의 표시 순서를 정합니다. 세 역할을 분리해야 필요한 데이터와 변경 범위를 판단할 수 있습니다.

예를 들어 사용자가 회의실을 입력하는 일은 검색어에 해당합니다. 그중 서울에 있고 수용 인원 10명 이상인 항목만 보는 일은 필터이며, 결과를 가까운 순이나 등록일 순으로 보는 일은 정렬입니다.

Google Programmable Search Engine은 구조화된 데이터에 대해 속성별 필터링, 속성별 정렬, 범위 제한을 별도 연산으로 제공하며, 정렬에는 숫자나 날짜처럼 해석 가능한 필드가 필요하다고 안내합니다.

대한민국 정부의 KRDS 검색 서비스 패턴도 검색어 입력, 결과 확인, 목록 탐색, 상세 검색 조건 설정, 기존 조건을 유지한 재검색을 구분하고 기본 정렬과 필터 컨트롤을 안내합니다.

따라서 기획서에는 단순히 “검색 기능”이라고 쓰기보다 아래 질문을 따로 남기는 편이 좋습니다.

1. 사용자는 어떤 단어로 항목을 찾는가?
2. 사용자는 어떤 속성으로 결과를 좁히는가?
3. 여러 결과 중 무엇을 먼저 봐야 하는가?

이 세 질문에 답하지 못한 상태에서 화면부터 만들면, 나중에 관리자 입력 항목을 추가하거나 기존 데이터를 다시 정리해야 할 수 있습니다.

검색 기능 기획서에는 어떤 데이터를 먼저 적어야 할까요?

검색 화면보다 먼저 검색 대상 필드, 입력 방식, 노출 조건, 갱신 책임자를 정해야 합니다. 그래야 사용자 화면과 관리자 화면이 같은 기준을 사용합니다.

제가 업무 시스템을 설계할 때 중요하게 보는 원칙은 하나의 데이터 모델이 여러 화면을 담당하게 만드는 것입니다. 목록, 상세, 관리자 입력, 검색 결과가 각자 다른 기준을 쓰면 같은 항목이 화면마다 다르게 보일 수 있습니다.

Google Cloud Agent Search는 정형 데이터 스토어의 필드값이나 메타데이터를 기준으로 필터링할 수 있다고 설명합니다. 다만 이는 해당 제품의 기능과 처리 방식에 관한 설명이므로, 모든 검색 시스템이 같은 방식으로 동작한다고 볼 수는 없습니다.

기획서에는 기능명보다 데이터 단위로 다음 내용을 남겨보세요.

가령 지역 필터가 필요하다면 주소 문장 안에서 단어를 찾는 방식만으로 충분한지, 시도나 시군구처럼 별도 필드가 필요한지를 판단해야 합니다. 반대로 지역으로 결과를 좁힐 일이 없는 작은 서비스라면, 처음부터 세분화된 지역 체계를 만들 필요는 없습니다.

필터 값은 어떤 방식으로 관리해야 할까요?

반복해서 결과를 좁히는 기준은 검색 시스템이 식별할 수 있는 구조화된 필드로 관리하는 편이 좋습니다. 다만 자유로운 설명이 필요한 정보까지 모두 선택형 값으로 바꿀 필요는 없습니다.

Google의 검색 문서는 구조화된 데이터를 객체와 속성의 집합으로 설명하고, 필드 존재 여부와 특정 값에 따른 결과 필터링을 지원합니다. 패싯이나 필터에 쓸 속성은 검색 시스템이 식별 가능한 필드값으로 전달되어야 합니다.

실무에서는 같은 의미의 상태가 진행, 진행중, 운영 중처럼 여러 표기로 입력되는지 확인할 필요가 있습니다. 이런 값이 핵심 필터라면 운영자가 고르는 후보를 정하거나 입력 규칙을 문서화하는 방식이 관리에 도움이 될 수 있습니다. 이는 특정 검색엔진의 보편 규칙이 아니라, 데이터 입력 기준을 유지하기 위한 운영 판단입니다.

반면 제목, 상세 설명, 후기처럼 사용자의 표현을 담아야 하는 정보는 자유 텍스트로 남길 수 있습니다. 다음처럼 역할을 나누면 판단이 쉬워집니다.

• 제목과 설명: 사용자의 언어를 담는 자유 텍스트
• 서비스 분류와 공개 상태: 반복적으로 거르는 선택형 값
• 가격, 수용 인원, 등록일: 범위 비교나 정렬에 쓰는 숫자와 날짜
• 태그: 검색어를 보완하는 여러 개의 보조 분류

Google Programmable Search Engine 문서에서는 속성별 정렬과 범위 제한에 숫자나 날짜로 해석 가능한 값이 필요하다고 설명합니다. 이 조건은 해당 제품의 구조화 검색 기능에 관한 것이지만, 숫자와 날짜를 텍스트 설명에만 묻어두지 말아야 하는 이유를 보여줍니다.

정렬 기준은 최신순 하나로 끝내도 될까요?

최신순은 기본 정렬이 될 수 있지만, 사용자의 선택 기준이 시간 외 요소에 달려 있다면 별도의 정렬값과 운영 규칙을 검토해야 합니다.

정렬은 결과를 보기 좋게 만드는 장치만이 아니라 사용자가 무엇을 먼저 보게 되는지를 정하는 기준입니다. “인기순”을 넣고 싶다면 인기의 근거가 조회 수인지, 신청 수인지, 판매 수인지, 운영자 우선순위인지 먼저 정해야 합니다.

구조화된 정렬에서는 정렬에 필요한 속성이 없거나 값이 해석되지 않는 결과가 정렬 대상에서 제외될 수 있습니다. 따라서 정렬을 제공하려면 정렬 필드의 존재 여부와 데이터 형식을 기획 단계에서 확인해야 합니다.

KRDS는 검색 결과에서 기본 정렬과 필터 컨트롤을 제공하고, 사용자가 설정한 조건을 확인하며 재검색할 수 있도록 안내합니다.

검색 결과가 적고 운영자가 직접 확인할 수 있는 초기 서비스라면 이름 검색과 최신순만으로 시작할 수 있습니다. 반면 항목이 계속 등록되고 사용자가 특정 조건을 반복해 찾는 서비스라면, 필터와 정렬에 필요한 값을 데이터 구조에 반영할지 초기에 검토하는 편이 좋습니다.

개발 전에는 어떤 질문으로 검색 요구사항을 검토하면 될까요?

검색 요구사항은 “검색 기능이 필요한가”보다 “사용자가 어떤 질문을 반복해서 해결하려는가”부터 확인해야 합니다. 그 질문을 데이터 조건으로 바꿀 수 있을 때 구현 범위가 선명해집니다.

착수 전에 담당자와 다음 항목을 확인해 보세요.

1. 사용자가 목록에서 가장 자주 구분하려는 기준은 무엇인가?
2. 그 기준은 관리자 화면에서 빠짐없이 입력할 수 있는가?
3. 값이 비어 있거나 잘못 입력되면 결과에서 어떻게 처리할 것인가?
4. 공개 사용자와 관리자에게 같은 필터를 보여야 하는가?
5. 기본 정렬은 사용자의 선택 목적과 맞는가?
6. 나중에 추가할 필터가 있다면 지금 저장해야 할 값은 무엇인가?

이 체크리스트의 목적은 기능 목록을 늘리는 것이 아닙니다. 검색 결과의 기준을 한 문장으로 설명할 수 있는지 확인하는 데 있습니다. 구현 브리프에도 화면 이름만 적기보다 검색 대상 필드, 노출 제외 조건, 필터 조건, 정렬 규칙을 분리해 적어야 개발자가 기준을 추측하지 않게 됩니다.

사용자가 반복해 찾는 조건이 아직 불분명하다면 검색어와 최소한의 상태 필터부터 시작할 수 있습니다. 반대로 서비스 분류나 업무 규정이 이미 명확하다면, 그 기준을 처음 데이터 모델에 반영할지 검토하는 편이 낫습니다.

결론

웹 서비스 검색 기능의 핵심은 검색창이 아니라 검색 가능한 데이터의 기준입니다. 검색어, 필터, 정렬이 각각 어떤 질문에 답하는지 나눈 뒤 관리자 입력 방식까지 연결해 설계하세요.

검색어는 사용자의 표현을 받아들이고, 필터는 반복되는 선택 조건을 관리하며, 정렬은 결과의 우선순위를 보여줍니다. 이 세 요소를 데이터 필드와 운영 규칙으로 번역하면 개발 범위와 이후 변경 범위를 설명하기 쉬워집니다.

처음부터 모든 조건을 넣을 필요는 없습니다. 다만 나중에 필요할 가능성이 높은 검색 기준이 있다면, 그 값을 어디에 어떤 형식으로 저장할지는 초기에 결정해야 합니다.

자주 묻는 질문

검색 기능은 MVP에서 빼도 되나요?

가능합니다. 목록 수가 적고 사용자가 몇 개의 항목만 탐색하는 초기 서비스라면 검색 없이 시작할 수 있습니다. 다만 이후 검색을 넣을 가능성이 높다면 이름, 상태, 분류, 등록일처럼 기준으로 쓸 핵심 값은 분리해 저장할지 검토해야 합니다.

검색어와 태그는 같은 것 아닌가요?

같지 않습니다. 검색어는 사용자가 직접 입력하는 표현이고, 태그는 운영자가 항목에 부여하는 보조 분류값입니다. 태그는 검색을 보완할 수 있지만 필수 상태나 핵심 분류를 모두 태그로 관리하면 운영 기준이 흐려질 수 있습니다.

필터는 몇 개부터 시작하는 것이 좋나요?

정해진 개수는 없습니다. 사용자가 반복적으로 결과를 좁히는 기준부터 넣으면 됩니다. 운영자가 값을 빠짐없이 입력할 수 없는 필터라면 개수를 늘리기보다 데이터 관리 방식을 먼저 정해야 합니다.

인기순 정렬은 어떻게 정의해야 하나요?

먼저 인기의 근거를 정해야 합니다. 조회, 신청, 판매, 관리자 추천 중 무엇을 사용할지와 갱신 주기, 집계 대상, 값이 없는 신규 항목의 처리 방법을 함께 문서화해야 합니다.

제 도움이 필요하시다면

검색 기능을 새로 기획하거나 기존 관리자 시스템에 추가하려는 경우, 사용자 질문을 데이터 필드와 구현 범위로 바꾸는 작업부터 검토할 수 있습니다.

크로플은 웹과 업무 시스템 수탁개발에서 검색 대상, 관리자 입력 항목, 권한별 노출, 정렬 규칙을 하나의 데이터 모델로 연결하는 설계를 다룹니다. 어떤 필터를 운영할지, 기존 데이터에 무엇이 부족한지 정리되지 않은 상황이라면 이 검토가 적합합니다.

현재 서비스의 목록 구조, 관리자 운영 방식, 추가하려는 검색 조건을 관리형 문의 카드로 알려주시면 구현 전에 정리할 판단 항목을 함께 살펴보겠습니다.