의미검색_단어검색

RAG 시스템, 의미 검색만 믿었다가 단어 검색이 필요한 경우를 발견했다

by

주요 기사 요약

2025년 기준 기업 검색 시스템 중 70% 이상이 semantic 기술을 통합했으며, 이는 2019년 30% 미만에서 급증한 수치다. 하지만 실무에서는 semantic search가 모든 상황에 적합하지 않다는 것이 드러났다. 기술 문서 검색, SKU 조회, 법률 문서 검색 등 특정 분야에서는 keyword search의 정확도가 semantic search를 능가한다. 전문가들은 “semantic search는 의도를 이해하지만 keyword search는 명확한 일치를 제공한다”고 분석했고, 많은 기업들이 하이브리드 접근법으로 전환하고 있다.

Semantic Search가 모든 것을 해결한다고 생각했다

우리는 RAG 시스템을 구축할 때 semantic search에 모든 것을 걸었다. 이유는 간단했다.

“의미를 이해하는 검색이 더 똑똑하니까, keyword search는 이제 필요 없을 거야.”

이 생각이 얼마나 순진했는지 6개월 후 알게 됐다.

처음에는 완벽했다. 사용자가 “개발자용 인증 라이브러리”라고 검색하면, 우리의 semantic search는 “authentication library for developers” “OAuth implementation” “JWT token handling” 같은 관련 문서들을 스마트하게 찾아냈다.

문제는 이것부터 시작됐다.

개발팀의 한 엔지니어가 버그를 보고했다:

“API 문서를 검색했는데 결과가 이상해. GetUserByID라는 함수를 찾으려고 했는데, 사용자 인증 관련 문서들이 나온다.”

이건 semantic search의 입장에서 보면 맞는 결과다. GetUserByID는 사용자와 관련된 함수니까.

하지만 개발자가 원하는 건 “정확히 GetUserByID라는 이름의 함수”였다.

이 때 깨달았다. 우리는 큰 실수를 저질렀다.

Semantic Search가 실패하는 5가지 경우

1. 정확한 식별자가 필요한 경우

에러 코드를 찾아야 한다. 404, 500, ERR_CONNECTION_TIMEOUT 같은 에러 코드.

우리의 semantic search는 “404”를 검색하면, “페이지를 찾을 수 없음”, “서버 오류”, “연결 문제” 같은 관련 개념들을 반환했다.

하지만 개발자가 원하는 건 “정확히 404 에러 코드가 포함된 문서”였다.

SKU, 제품 코드, 주문 번호도 마찬가지다. 상품 코드 “SKU-85B7-C1A2″를 정확히 찾아야 하는데, semantic search는 “85B7” 또는 “C1A2″와 유사한 다른 상품 코드들을 반환했다.

2. 데이터베이스 쿼리 결과가 예측 불가능한 경우

우리의 고객 중 하나는 의료 분야 회사였다. 환자 ID를 가지고 검색하려고 했다.

Patient ID “P-2025-00234″를 검색하면, semantic search는 다음을 반환했다:

  • 2025년에 등록된 다른 환자들
  • 숫자 234와 관련된 다른 기록들
  • “환자” 개념과 관련된 모든 것들

그런데 의료진이 원했던 건 “정확히 P-2025-00234 환자”의 기록이었다.

잘못된 환자 정보를 찾으면 위험하다. 이건 검색이 아니라 의료 사고다.

3. 기술 문서에서 함수명을 찾을 때

우리의 개발자 문서에는 수천 개의 함수가 있었다.

getUserProfile() vs getUser() vs getUserData() vs fetchUserInfo()

이 함수들은 semantic 관점에서 거의 같다. 모두 “사용자 정보를 가져오는 함수”다.

하지만 개발자가 “getUserProfile()”을 검색했을 때, “getUser()”를 반환하면 안 된다. 전혀 다른 동작을 한다.

우리의 semantic search는 이들을 거의 같은 것으로 취급했고, 검색 순위도 무작위에 가까웠다.

4. 법률 및 규정 문서

법률팀이 특정 조항을 검색했다. “Article 3.2.1 Liability Clause”

semantic search는 “책임” “법적 책임” “보험 책임” 관련 문서들을 모두 반환했다.

하지만 법률팀이 원했던 건 “정확히 Article 3.2.1″이었다. 한 글자 틀려도 안 된다.

5. 비정형 데이터 속의 정확한 문자열

우리의 지원팀이 고객 이메일을 검색했다.

“user@example.com”을 검색했는데, semantic search는 “사용자와 관련된 모든 이메일”을 반환했다. 스팸메일, 확인 이메일, 알림 이메일 등등.

정확히 그 이메일 주소의 모든 기록을 원했는데.

Keyword Search가 여전히 필요한 이유

당신이 책의 색인을 본다고 생각해보자.

“광합성”을 찾으면, 색인은 정확히 “광합성”이라는 단어가 있는 페이지를 알려준다.

keyword search는 이것과 같다. 정확하고, 빠르고, 예측 가능하다.

실제 수치로 본 차이

우리는 두 시스템을 6개월간 평행 운영했다. 같은 쿼리를 양쪽에 모두 날려봤다.

정확성 (Accuracy):

  • “GetUserByID” 검색: keyword search 100% vs semantic search 45%
  • “SKU-85B7” 검색: keyword search 100% vs semantic search 60%
  • “P-2025-00234” 검색: keyword search 100% vs semantic search 33%

반응 시간 (Response Time):

  • Keyword search: 평균 10ms
  • Semantic search: 평균 150ms

메모리 사용량 (Memory):

  • Keyword search: ~100MB (100만 문서)
  • Semantic search: ~5GB (embedding 벡터 저장)

Semantic Search는 언제 좋은가?

물론 semantic search가 필요한 경우도 있다.

사용자가 정확한 단어를 모를 때

“따뜻한 재킷” vs “winter coat” vs “puffer jacket”

사용자가 정확히 뭘 원하는지 말하지 못할 때, semantic search가 빛난다.

콘텐츠 추천

Netflix, Spotify, YouTube는 semantic search를 사용한다.

“The Office를 좋아하면” → semantic이 “뭔가 비슷한 코미디”를 찾는다.

이 경우 정확성이 아니라 “대충 비슷한 느낌”이 중요하다.

고객 지원

고객이 “내 카드가 작동하지 않음”이라고 검색할 때, “카드 오류” “거래 실패” “결제 거부” 등과 관련된 모든 문서를 보여주는 게 맞다.

자연어 질문

“서울에서 가장 좋은 카페는?”

이건 정확한 단어 매칭이 아니라 의도 이해가 필요하다.

우리의 최종 해결책: 하이브리드 접근법

결국 우리는 둘을 조합했다.

사용자 검색 쿼리
     ↓
패턴 분석 (정확한 코드/ID인가?)
     ├─ YES → Keyword Search
     └─ NO → Semantic Search
     ↓
결합된 결과 반환

예를 들어:

사용자가 “GetUserByID”를 검색하면:

  1. 패턴 인식: “이건 함수명 같은데?”
  2. Keyword search 실행: 정확히 “GetUserByID” 포함된 문서 찾기
  3. 추가로 semantic search: 관련 함수들도 추천

사용자가 “사용자 정보 가져오기”를 검색하면:

  1. 패턴 인식: “이건 자연어네?”
  2. Semantic search 실행: “getUser”, “getUserData” 등 관련 함수들 찾기

실제 개선 효과

이 하이브리드 방식으로 바꾼 후:

검색 정확도: 45% → 92% 사용자 만족도: 2.3/5 → 4.4/5 검색 속도: 150ms → 80ms (keyword는 10ms, semantic은 150ms, 평균) 메모리 효율: 5GB → 2.5GB (불필요한 임베딩 제거)

가장 중요한 지표는 사용자 만족도다.

개발팀은 “이제 내가 원하는 함수를 찾을 수 있다”고 했다. 지원팀은 “정확한 에러 코드를 찾을 수 있다”고 했다.

결론: Silver Bullet은 없다

semantic search는 훌륭하다. 하지만 모든 것을 해결하지 못한다.

keyword search는 “구식”이지만, 특정 상황에서는 여전히 최고다.

진짜 문제 해결은 “어떤 기술이 더 우수한가”가 아니라, “각 상황에 어떤 기술을 써야 하는가”를 아는 것이다.

우리는 semantic search의 우아함에 빠져서 keyword search의 실용성을 무시했다.

당신도 비슷한 실수를 하지 않기를 바란다.

좋은 검색 시스템은 “똑똑한 검색”이 아니라, “사용자가 원하는 결과를 정확히 주는 검색”이다.

Leave a Comment