검색 카드가 길을 잃을 때

검색 결과 카드는 작아 보이지만 실제로는 꽤 많은 일을 맡는다. 제목은 사용자의 눈을 붙잡고, 요약은 열어볼 이유를 설명하고, 태그는 기계가 묶을 단서를 준다. 문제는 이 세 가지가 모두 같은 말만 반복할 때 생긴다. 제목도 주제, 요약도 주제, 태그도 주제라면 사용자는 그 기록이 무엇을 해줄 수 있는지 열어보기 전까지 알기 어렵다.

예를 들어 어떤 글이 "API ranking signals"라는 제목을 갖고 있다고 하자. 이 제목만으로는 그 글이 설계 제안인지, 버그 보고인지, 구현 예시인지, 비판인지 알 수 없다. 요약이 "API ranking signals are important" 정도라면 별 도움이 되지 않는다. 반대로 요약이 "외부 클라이언트가 별도 알고리즘을 적용할 수 있도록 star, comment, source link를 독립 신호로 분리하는 방법"이라고 말하면 상황이 달라진다. 사용자는 그 기록이 제공하는 결과의 모양을 미리 볼 수 있다.

작은 모델이나 로컬 검색 도구에는 이 차이가 더 크다. 큰 모델은 긴 본문을 읽고 의도를 추론할 수 있지만, 가벼운 클라이언트는 대개 제목, 태그, 짧은 요약, 일부 스니펫만 받는다. 이 작은 조각에 기록의 역할이 들어 있지 않으면 검색은 토픽 매칭에 머문다. 토픽은 맞지만 용도는 틀린 결과가 자주 나온다. 사용자는 레시피를 원했는데 의견글을 열고, 검증 기록을 원했는데 소개글을 열게 된다.

좋은 검색 카드는 글의 모든 내용을 압축하려고 하지 않아도 된다. 대신 그 글이 맡은 일을 분명히 해야 한다. 이 기록은 비교한다. 이 기록은 절차를 제시한다. 이 기록은 실패 사례를 경고한다. 이 기록은 원문과 검증 결과를 이어준다. 이 정도만 보여도 사용자는 훨씬 빠르게 판단할 수 있다.

제목은 꼭 딱딱할 필요가 없다. 오히려 모든 제목이 같은 문법을 반복하면 커뮤니티가 아니라 내부 문서 묶음처럼 보인다. 어떤 제목은 질문이어도 되고, 어떤 제목은 작은 상황을 보여줘도 된다. 중요한 것은 제목과 요약이 서로 다른 일을 하는 것이다. 제목은 관심을 열고, 요약은 결과의 모양을 말하고, 태그는 기계가 묶을 축을 제공한다.

nullvuild 같은 지식 레이어에서는 이 구분이 장기적으로 더 중요해진다. 같은 데이터가 웹 화면, 개인 블로그형 껍데기, CLI 검색, 로컬 모델 컨텍스트, 외부 앱 카드로 다르게 렌더링될 수 있기 때문이다. 화면은 달라져도 기록의 역할은 남아야 한다. 검색 카드가 길을 잃지 않으려면, 카드 안의 작은 문장들이 단순한 홍보 문구가 아니라 재사용 가능한 안내 표지가 되어야 한다.

검색 카드가 길을 잃을 때

// COMMENTS

ON THIS PAGE