검색 필터는 문자열이 아니라 분류 체계입니다

2026-09-04

구직 공고 검색창에 신입을 입력하면 신입 공고가 나오면 좋겠습니다.

너무 당연한 이야기죠.

그런데 여러 채용 사이트의 공고를 한곳에 모으기 시작하면, 이 당연함이 갑자기 일을 시작합니다.

여러 제공자의 공고를 한 화면에 모으면, 경력과 지역을 표현하는 방식이 다를 수 있습니다. 예를 들어 사용자가 고르는 지역 목록에는 시·도와 특정 구 단위가 함께 있을 수 있습니다. 그리고 사용자는 그 모든 사정을 모르고 3년이라고 입력합니다.

저도 사용자가 제공자별 내부 코드를 외워야 하는 검색 화면은 보고 싶지 않습니다. (외우는 순간 검색이 아니라 자격증 시험입니다.)

그래서 검색 필터는 단순 문자열 입력칸이 아니라, 사용자 언어와 각 제공자의 분류 체계 사이에 놓인 번역 계약으로 봐야 합니다.

사용자는 짧게 말하고, 시스템은 정확하게 해석해야 합니다

좋은 입력어는 짧고 기억하기 쉽습니다.

이 정도면 사용자는 무엇을 요청하는지 압니다. 하지만 시스템에는 아직 일이 남아 있습니다.

신입은 어느 제공자의 entry-level 값과 연결되는지, 3년은 정확히 3년만 의미하는지 아니면 3년을 포함하는 범위를 의미하는지, 전체는 필터를 생략하는지 아니면 모든 제공자별 값을 합치는지 결정해야 합니다.

여기서 중요한 점은 사용자가 입력한 단어를 그대로 HTTP 요청에 끼워 넣는 것이 아닙니다. 그 단어가 뜻하는 제품 수준의 의미를 먼저 정의하는 일입니다.

예를 들어 3년이라는 입력의 의미를 “3년 차만”으로 정의할지, “공고에 3년이라는 경력 조건이 포함된 결과”로 정의할지는 제품의 선택입니다. 둘 다 가능한 해석이지만, 화면과 설명이 다르게 만들어집니다.

필터는 코딩하기 전에 문장으로 설명할 수 있어야 합니다.

지역 검색도 비슷합니다.

서울이라고 입력하면 될 것 같지만, 제품이 지원하는 지역 목록에는 강남구처럼 좁은 단위와 광역 단위가 함께 있을 수 있습니다. 그 목록이 제공자 요청으로 어떻게 연결되는지는 구현 전에 따로 결정해야 합니다.

이럴 때 무제한 자유 입력은 친절해 보이지만, 제공자가 해석하지 못하는 값을 계속 만들 수 있습니다. 반대로 지원 지역 목록을 제품이 명시하면 다음이 가능해집니다.

즉, 제한된 선택지는 기능 부족이 아니라 의미가 있는 검색 결과를 지키는 장치일 수 있습니다.

물론 지역 목록은 제품의 약속이므로, “왜 이 지역만 있지?”라는 질문을 받을 수 있습니다. 좋습니다. 그 질문이 바로 목록을 확장할 때 필요한 근거가 됩니다.

여러 채용 사이트를 연동할 때 흔히 생기는 실수는, 공통 화면을 먼저 만들고 제공자 차이를 그 안에 계속 추가하는 것입니다.

그러면 if문이 자랍니다. 지역 처리도, 경력 처리도, 응답 파싱도 한 파일에서 서로를 밀어냅니다. 나중에는 새 제공자 하나를 추가하는 일이 기존 제공자 셋을 불안하게 만드는 행사처럼 느껴집니다. (개발자의 심박수도 함께 올라갑니다.)

제공자별 모듈은 이 차이를 격리합니다.

각 모듈은 자기 제공자의 응답 형식, 태그, 지역 정보, 가져오는 방법을 책임집니다. 공통 계층은 사용자가 선택한 필터의 의미와 보여줄 공고 형식을 책임집니다.

이 구분이 있으면 제품은 다음처럼 말할 수 있습니다.

사용자 입력 → 제품 분류 체계 → 제공자별 변환 → 공통 표시 형식

화면이 제공자 사정을 모르고도 일관성을 유지하는 이유가 생깁니다.

새 필터를 하나 추가하기 전에 저는 다음 네 가지를 확인하려고 합니다.

이 질문에 답하지 못하면 아직 버튼을 만들 차례가 아닙니다.

검색 화면은 입력칸 몇 개가 아닙니다. 사용자가 자기 말로 요청한 것을, 서로 다른 세계의 데이터가 같은 약속으로 받아들이게 만드는 작은 번역기입니다.

그러니 다음에 경력 3년 필터를 추가할 때는 문자열부터 보지 마세요. 먼저 그 문자열이 어떤 분류 체계의 문을 열어야 하는지부터 정해봅시다.