Hacker News 의견

• 검색의 기본 아이디어는 단순하고 흥미로운 문제 영역임
  하지만 대량의 데이터를 다루는 것과 모호한 쿼리를 처리하는 것이 진짜 어려움
  DBMS 기반 접근은 작은 웹사이트 수준에서는 괜찮지만, 영어 위키피디아 규모에서는 금방 한계에 부딪힘
  입문용으로는 SeIRP e-book이 좋은 무료 자료

  • 대량 데이터는 당연히 어렵지만, 모호한 쿼리를 다루는 건 “가장 관련 있는 결과를 어떻게 정할 것인가”의 하위 문제라고 생각함
    정답이 명확하지 않다는 점이 특히 까다로움
    Google은 광고를 ‘가장 관련 있는 결과’로 보여주기도 해서, Marginalia Search는 좋은 대조 사례임
    혹시 TREC 논문들을 참고해본 적 있는지 궁금함
  • 요즘은 오히려 SEO 스팸 회피가 더 큰 문제라고 생각함
    검색 엔진은 광고 수익을 노리는 적대적 플레이어들과 끊임없이 싸워야 함
    품질 지표를 계속 바꿔가며 그들이 역이용하지 못하게 하는 끝없는 고양이와 쥐의 게임이 됨
  • SQLite로 단일 서버(약 천 달러 수준)에서 텍스트 중심 비즈니스 프로세스를 돌린다면, 실질적으로 다룰 수 있는 문서 저장소의 규모가 어느 정도인지 궁금함
    1쿼리당 5초, 분당 12쿼리 정도의 속도를 기준으로 어느 정도의 코퍼스를 검색할 수 있을지 알고 싶음
  • Marginalia Search를 정말 좋아함
  • 검색의 어려움은 단순히 데이터 크기뿐 아니라, 어떤 결과를 반환할지 결정하는 문제라고 생각함
    예를 들어 Gilligan’s Island 위키 문서와 팬 블로그 중 어느 쪽이 더 “좋은” 결과인지 판단하기 어려움
    여기에 랭크 조작이나 키워드 스터핑까지 더해지면, 확장성 문제보다 훨씬 복잡한 도전이 됨

• 검색은 정말 어려운 일임
  Apple, Microsoft, OpenAI 같은 자원과 기술력이 넘치는 회사조차 검색 기능 품질이 낮음
  이는 단순한 기술 문제가 아님

  • 대부분의 회사가 검색을 잘 구현하지 못하는 이유는, 기업 문화와 개발 방식이 검색 개발과 충돌하기 때문임
    검색 품질을 높이려면 랭킹 파라미터를 세밀하게 조정해야 하는데, 이런 일은 스프린트나 Jira 같은 관리 체계로는 계획하기 어려움
    결국 개발자에게 신뢰와 자율성이 필요한 영역임
  • 하지만 어떤 회사들은 단순히 검색이 우선순위가 아니기 때문에 품질이 낮은 것
    AI 모델에는 수십억을 투자하지만, 웹앱이나 검색은 부차적이라서 그런 결과가 나오는 것임

• 10년 전쯤 검색 엔진 설계로 박사과정을 하던 동료와 함께 일한 적이 있음
  그는 검색과 데이터베이스 통합에 대해 매우 열정적으로 이야기했고, 덕분에 많은 걸 배웠음
  언젠가 Apache Solr와 Lucene의 내부를 깊이 파보고 싶음

  • 나도 내 분야 이야기를 몇 시간이고 할 수 있을 정도로 좋아하지만, 대형 시스템의 세부 구현에 관심 있는 사람은 많지 않음

• 예전에는 오픈소스 검색 솔루션이 없어서 직접 만들어야 했음
  그 경험으로 얻은 교훈은 “직접 검색 엔진을 만들지 말라”는 것임
  수년간 수많은 인력이 이 문제에 매달려왔고, 직접 만들면 끝없는 유지보수 지옥에 빠짐
  “오타 교정 기능 추가해달라”, “내년엔 분류 체계도 넣자” 같은 요구가 이어지면 끝남

• 예전에 Virginia University의 David Evans 교수가 진행한 검색 엔진 구축 강의를 정말 즐겼음
  “고전적인 검색 엔진”을 직접 만들어보는 건 매우 재미있는 프로젝트였음
  강의 링크와 YouTube 재생목록 참고 가능

  • 나도 그 강의를 들었는데, 초보 프로그래머에게도 흥미롭고 밀도 높은 수업이었음

• 내가 자주 쓰는 검색 엔진들은 2~3글자 약어나 단어를 무시하는 게 불만임
  “mp3”나 “PHP” 같은 짧은 단어를 검색할 때 제거해버리면 정말 불편함

• Toby Segaran의 Programming Collective Intelligence를 읽고 검색, 추천, 분류기 등 다양한 아이디어에 영감을 받았음

  • 나도 그 책을 좋아했지만, 저자가 나중에 유튜브에서 “이제는 구식이니 쓰지 말라”고 말한 걸 봤음
  • 정말 좋은 책이었는데, 2025년에 해당하는 최신판이 있다면 궁금함

• 흥미로운 글이었음
  인기 검색 엔진들이 사용하는 토크나이저 최적화 수준이 얼마나 높은지 궁금해짐

• 이 시스템이 얼마나 확장성 있게 작동할지 궁금함
  Elasticsearch는 권장 스케일을 넘어도 꽤 인상적인 성능을 보임

• 간단한 텍스트 검색 엔진은 만들기 어렵지 않음
  하지만 좋은 검색 엔진을 만드는 건 전혀 다른 이야기임
  단순히 BM25 같은 알고리즘을 구현하는 수준으로는 부족함
  내가 컨설팅한 회사들 대부분이 자체 솔루션을 쓰다가 결국 Elasticsearch나 Opensearch로 옮김
  자체 구현은 처음엔 단순하지만, 시간이 지나면 랭킹 문제와 성능 저하로 복잡해짐
  “느리다”, “엉뚱한 결과가 나온다” 같은 증상이 반복됨
  Elasticsearch는 이미 10년 전부터 이런 문제를 해결해왔고, 지금은 훨씬 더 발전함
  “설정이 어렵다”는 말도 있지만, 요즘은 대부분 자동 구성되고, 관리형 서비스도 많음
  Postgres보다 오히려 다루기 쉬움
  결국 중요한 건 인덱스 매핑 최적화임
  “그런 고급 기능은 필요 없다”고 말하는 사람도 있지만, 실제로는 검색 품질이 비즈니스 생존에 직결됨
  제대로 된 검색을 원한다면 결국 이런 복잡함을 감수해야 함

  • 나도 Elasticsearch를 기본으로 쓰고 있음
    최근 HN에서 자주 언급되는 SeekStorm 같은 신흥 대안도 흥미로워 보이지만, 실제 프로덕션 사례는 아직 못 봤음
  • “불필요한 기능은 없다”는 말에 공감함
    특히 dynamic mapping을 끄고 불필요한 필드 인덱싱을 막는 팁이 유용했음
  • ManticoreSearch에 대해서는 어떻게 생각하는지 궁금함
    Lucene보다 오래된 프로젝트로 알고 있음