LLM 설계자를 위한 사고 전환: DB 검색 vs 임베딩 기반 검색
들어가며: 지금 왜 이 이야기를 해야 할까?
GPT와 같은 LLM의 등장은 단순히 '새로운 툴'의 등장을 넘어서, 정보 탐색과 연결 방식 자체의 변화로 이어진다. 많은 개발자들은 여전히 RDB나 키워드 중심의 검색 관점에서 사고하지만, LLM 시대에는 '임베딩'이라는 전혀 다른 전제가 필요하다.
대부분의 개발자들이 LLM 기반 RAG 시스템을 설계할 때 실수하는 근본 원인은, 기존의 DB(정합성 기반) 사고방식을 그대로 임베딩(의미 기반) 시스템에 적용하려 하기 때문이다.
전통적인 DB 검색 사고방식과 임베딩 기반 의미 검색 사고방식의 본질적인 차이를 비교하면서, LLM 설계자로서 반드시 이해해야 할 핵심적인 사고 전환의 지점을 짚어보려 한다.
1) 전통적 DB 검색: 구조화된 세계의 논리
| 요소 | 설명 |
| 🎯 정합성 중심 | 키워드, ID, 조건이 "정확히 일치"하는 것을 찾는다 |
| 🧱 스키마 기반 구조 | 명확한 컬럼/필드 기반 → 검색 최적화 가능 |
| 🔎 쿼리 기반 탐색 | SELECT, WHERE, LIKE 등 명시적 탐색 |
| ❌ 불일치 시 0건 반환 | 키워드 누락 시 결과 없음 |
| ✅ 예측 가능성 | 정확도, 응답 속도, 트랜잭션 정합성 확보 |
2) 임베딩 기반 검색: 의미의 벡터 공간
| 요소 | 설명 |
| 🔄 의미 기반 유사도 | 문장 간의 "뜻이 비슷한 정도"를 수치(벡터)로 비교 |
| 🧠 벡터 공간 | 고차원 수치 배열로 표현된 의미 모델 (예: [0.24, -0.91, ...]) |
| 🎯 근접성 중심 | 정확히 일치하지 않아도 "비슷한 의미"라면 결과로 채택됨 |
| ⚠️ 확률적 일치 | 불완전한 문장, 애매한 표현도 일종의 해석 대상 |
| ✅ 맥락 이해 가능 | GPT가 벡터 결과를 기반으로 맥락 내 해석/응답 가능 |
3) 두 시스템의 충돌 지점
| DB 사고 | 임베딩에서 실패하는 이유 |
| “더 쪼개면 정밀하겠지” | → GPT는 조각난 문장 간 맥락을 이해하지 못함 |
| “정확한 키워드만 있으면 된다” | → 의미가 다르더라도 유사도로 인해 오답 유도 가능 |
| “유사한 결과 = 정답” | → 벡터 유사도는 항상 신뢰도와 일치하지 않음 |
| “검색 결과 그대로 보여주면 됨” | → GPT는 해석 가능한 구조로 된 의미 단위가 필요함 |
4) 올바른 설계 패러다임
의미 기반 청크를 설계하고, 그 구조 안에서 GPT가 판단/추론할 수 있도록 구성해야 한다.
- 청크 수보다 청크 품질이 중요 (양보다 구조)
- 하나의 청크는 의미 단위 + 맥락 흐름 + 전략 중심이어야 함
- GPT는 “검색된 결과”를 출력하는 게 아니라 “이해한 후 응답”한다
항목전통 DB 검색임베딩 기반 검색
| 질의 방식 | 명시적 조건(Query) | 자연어 의미 기반 질의 |
| 데이터 구조 | 정형화된 테이블 | 비정형 문서도 포함 가능 |
| 일치 기준 | 정확한 문자열 매칭 | 벡터 간 의미 유사도 |
| 활용 목적 | 정확한 정보 추출 | 유사/관련 정보 탐색 |
| 설계 포인트 | 스키마, 인덱스 | 임베딩 전략, chunk 관리 |
DB 검색은 "무엇을 정확히 찾을 것인가"에 집중하지만, 임베딩 검색은 "무엇과 의미상 가까운가"에 집중한다.
LLM 기반 검색 시스템을 설계할 때 다음과 같은 전환적 관점이 필요하다:
- 쿼리 튜닝 → 임베딩 품질 관리
- SQL 최적화처럼, 이제는 embedding vector의 품질과 관리가 핵심이 되어야 한다
- 스키마 설계 → 컨텍스트 단위 Chunk 설계
- 정형 테이블을 넘어, 문서 내 의미 단위로 정보를 나누는 전략이 필요하다
- 정합성 중심 → 의미 중심의 검색 인프라
- 정답만 반환하는 것이 아니라, 질문과 가까운 의미의 맥락을 보여주는 설계가 중요하다
- 단순 검색 → 응용형 시스템 설계
- RAG, Agent, FAQ 자동화 등 다양한 활용으로 확장되어야 한다
마무리하며: LLM 시대, 우리는 이렇게 달라져야 한다
DB 검색은 "정확한 것을 찾는 도구" LLM + RAG는 "의미를 기반으로 추론하고 해석하는 보조 두뇌"
이 둘은 완전히 다른 구조이며,
기존 개발자의 검색 설계 직관은 임베딩 기반 시스템에서는 적용되지 않는다.
AI-native 서비스는 의미 기반의 사고 구조와 추론 중심 응답 구조를 기반으로 설계되어야 한다.
이제는 데이터를 '찾는 것'이 아니라, 데이터가 의미의 공간에서 어디에 있는지를 이해하는 것이 중요하다. LLM 설계자는 SQL과 테이블을 넘어, 임베딩과 벡터 공간, 의미 기반 검색이라는 새로운 '좌표계'에서 사고할 수 있어야 한다.
“정답을 찾는 것”에서 “의미를 구성하는 것”으로.
이것이 LLM 시대의 사고 전환이다.