AI/LLM을 이용한 벡터 검색이란 무엇인가?

벡터 검색이란 게 대체 뭘까? 싶어서 조사해 보았습니다.

이 글을 쓰는 사람은 다음과 같은 인물입니다.

• 평소에는 SQL로 업무를 하고 있음
• 관계형 데이터베이스 (RDB)가 사고의 토대가 되어 있음
• 「벡터 검색 (Vector Search)」, 「embedding (임베딩)」, 「RAG」라는 단어는 들어봤지만,
  자신의 지식과 이어지는 맥락으로 이해하고 싶은 중견 엔지니어

목표는 단 하나입니다.

「벡터 검색은 RDB로 치면 결국 무엇인가」를 SQL의 어휘로 설명할 수 있게 되는 것

새로운 개념을 처음부터 배우는 것이 아니라, 「평소 쓰던 SQL」과 어디가 같고 어디가 다른지 대조하며 진행하겠습니다.

기존 지식에서부터 확인하는 방식이 스스로 납득하기 쉬울 것 같아 선택한 형식입니다.

평소에는 이런 검색을 합니다.

-- 완전 일치
SELECT * FROM faq WHERE question = '휴가 신청 방법';
-- 부분 일치 (모호한 검색)
...

이것들은 모두 문자·단어가 일치하는지를 보고 있습니다.

정확하고 빠르며, 결과의 이유도 설명하기 쉬운 익숙한 메커니즘입니다.

다만, 한계도 있다고 생각했습니다. 예를 들어 사용자가

「유급 휴가를 쓰고 싶을 때의 절차」

라고 검색해도, 휴가 신청 방법이라는 행은 단 하나도 히트하지 않습니다.

문자가 일치하지 않기 때문입니다.

하지만 사람이 보기에는 이 두 가지는 거의 같은 의미죠.

즉, 기존의 SQL 검색은,

• 「문자가 일치하는가」는 잘함
• 「의미가 가까운가」는 서툼

이라는 성질을 가지고 있다고 정리할 수 있을 것 같습니다.

이 「의미가 가까운 것을 찾고 싶다」는 문제를 해결하는 것이 벡터 검색이 아닐까 합니다.

조사해 보니 벡터 검색의 출발점은 매우 심플한 발상이었습니다.

문장의 「의미」를 수치의 나열 (벡터 (Vector))로 변환한다

예를 들면 다음과 같습니다.

「휴가 신청 방법」 → [0.21, -0.83, 0.05, ... ] ← 예를 들어 1536개의 수치 나열

이 수치의 나열을 **embedding (임베딩)**이라고 부른다고 합니다. 포인트는 이 수치가 무작위가 아니라는 점입니다.

의미가 가까운 문장일수록 벡터 (수치의 나열)도 가까워지도록 만들어져 있습니다.

• 「휴가 신청 방법」
• 「유급 휴가를 쓰고 싶을 때의 절차」

이 두 가지는 문자는 다르지만, 벡터로서는 가까운 위치에 배치된다는 이미지입니다.

솔직히 말하면 저는 이 부분이 가장 와닿지 않았습니다.

「의미를 숫자로 만든다」니, 대체 무엇을 어떻게 숫자로 만든다는 거야...? 하고 말이죠.

조사해서 납득한 것은 다음과 같은 이미지였습니다.

embedding (임베딩) = 그 자체의 「특징」을 여러 개의 축으로 점수 매긴 것

예를 들어, 다양한 단어를 「3개의 축」으로 점수 매겨 본다고 가정해 봅시다 (어디까지나 이미지용 예시입니다).

단어	생물 같음	탈것 같음	먹을 수 있는 정도
개	0.9	0.0	0.1
...

이렇게 하면 각 단어를 「숫자의 나열」로 표현할 수 있습니다.

• 개 =
  [0.9, 0.0, 0.1]

• 고양이 =
  [0.9, 0.0, 0.1]

• 자동차 =
  [0.0, 0.9, 0.0]

개와 고양이는 숫자가 거의 같음 → 의미가 가까움.

개와 자동차는 숫자가 완전히 다름 → 의미가 멂.

이것이 embedding (임베딩)의 정체였습니다. 「의미의 특징」을 좌표 (숫자의 나열)로서 “심어 넣기(embed)” 때문에 이런 이름이 붙은 것이군요.

이 부분도 궁금한 점이었습니다. 아까는 「생물 같음」처럼 사람이 축을 결정했지만, 실제 embedding에서는 사정이 다르다고 합니다.

• 축은 수백~수천 개가 있다.
• 게다가 각 축이 무엇을 나타내는지에 대해서는 사람이 말로 설명할 수 없다 (AI가 멋대로 만든 축).
• 숫자를 결정하는 것은 대량의 문장으로 학습한 AI 모델.

대략 말하자면, AI는 「비슷한 문맥에서 사용되는 단어끼리는 비슷한 숫자가 되도록」 학습하고 있다고 합니다. 그래서 「유급」과 「휴가」처럼 문자는 다르지만 비슷하게 쓰이는 단어는 자연스럽게 가까운 숫자가 된다는 것입니다.

다른 비유를 들자면, 지도의 위도·경도가 비슷하다고 생각했습니다. 도쿄와 요코하마는 좌표가 가까우니까 「지리적으로 가깝다」고 판단할 수 있죠. embedding은 그것의 “의미 버전” 좌표를 문장마다 할당하고 있는 것――그런 이미지로 저는 겨우 납득할 수 있었습니다.

어렵게 생각할 필요는 없을 것 같습니다. RDB의 관점에서 바꿔 말하면,

1행 = 1문서에 대해, 「의미를 나타내는 수치열(벡터열)」이라는 새로운 컬럼이 1개 늘어났다

라고 생각하면 될 것 같습니다.

id	content	embedding
1	휴가 신청 방법	[0.21, -0.83, 0.05, ...]
...
id=1

과 id=3

은 의미가 비슷하므로, 벡터의 수치도 비슷한 배열로 되어 있다는 식입니다.

이 부분이 개인적으로 가장 깨달음을 얻은 지점입니다.

기존 SQL 검색	벡터 검색
판정	일치함 / 하지 않음 (YES/NO)
가져오는 방식	조건에 맞는 행을 가져옴

납득이 가는 포인트를 한마디로 말하자면,

벡터 검색은 SQL로 말하면 ORDER BY 거리 LIMIT N

이다

완전 일치하는 WHERE가 아니라, 「가까운 순으로 정렬하여 상위 N건」이라는 발상으로 바뀌는 것이죠.

-- pgvector (PostgreSQL 확장) 예시
SELECT id, content
FROM documents
...

<=>

는 「코사인 거리 (Cosine Distance)」를 계산하는 연산자라고 합니다.

요컨대 「두 벡터가 얼마나 비슷한 방향을 향하고 있는가」를 측정하는 것입니다.

코사인 유사도 (Cosine Similarity) / 코사인 거리 (Cosine Distance)… 벡터의 「방향」의 가까움. 문장 검색에서 가장 많이 사용된다고 함
유클리드 거리 (Euclidean Distance, L2)… 좌표상의 직선 거리

세세한 구분은 나중으로 미루겠습니다.

우선은 「일치가 아니라 가까운 순 + 상위 N건」이라는 발상의 전환을 합니다.

실제로는 수백~수천 차원이지만, 억지로 2차원으로 압축하면 이런 이미지입니다.

휴가 신청 방법 ●
● 유급 휴가 사용법 ← 이 두 개는 가까움 (=의미가 가까움)
경비 정산 방법 ● ← 다른 의미이므로 떨어져 있음

「유급 휴가를 쓰고 싶을 때의 절차」를 벡터화하면, 왼쪽 상단 덩어리 근처에 떨어집니다. 그래서 글자가 일치하지 않아도 가까운 문서를 찾아낼 수 있는 것입니다.

RDB 분야에 계신 분들이 가장 먼저 걸려 넘어지는 부분이 여기라고 생각합니다. 저도 처음에는 그랬습니다.

"벡터 검색 = 그냥 똑똑한 모호한 검색 (LIKE / 애매한 검색)이잖아?"

조사해 보니, 사실 이것은 별개의 것이었습니다. 혼동하면 RAG 설계를 틀릴 수 있으므로, 이 부분은 확실히 구분해 두겠습니다.

애매한 검색이라고 불리는 것은 대체로 다음 중 하나라고 생각합니다.

LIKE '%...%'에 의한 부분 일치 - 와일드카드 검색

• 표기 불일치·오타(타입 미스)를 허용하는 fuzzy 검색 (편집 거리 / Levenshtein 등)

이것들의 공통점은, **보고 있는 것이 「글자의 형태·나열」**이라는 점입니다.

의미는 보고 있지 않습니다.

관점	애매한 검색 (LIKE / fuzzy)	벡터 검색
보고 있는 것	글자의 형태·나열 (표기)	의미
...

구체적인 예를 보면 이미지를 잡기 쉬울 것 같습니다.

「休假」(오타)로 「休暇」(휴가)를 찾고 싶다 → 이것은 애매한 검색 (fuzzy)의 특기 분야. 글자가 한 글자 다를 뿐이므로 글자 기반으로 찾아낼 수 있음 -
「유급을 쓰고 싶을 때의 절차」로 「휴가 신청 방법」을 찾고 싶다 → 글자가 일치하지 않으므로 애매한 검색으로는 히트되지 않음. 의미가 가까우므로 벡터 검색이라면 찾아낼 수 있음 -

한마디로 요약하면,

애매한 검색은 「글자의 흔들림(표기 차이)」에 강하고, 벡터 검색은 「의미의 흔들림」에 강합니다.

적합한 업무가 다를 뿐, 대립하는 기술은 아닌 것 같습니다. 실무에서는 양쪽을 병용하여 결과를 통합하는 하이브리드 검색 (Hybrid Search) (키워드 검색 + 벡터 검색)도 자주 사용된다고 합니다.

여기서 드디어 AI/LLM이 두 가지 역할로 등장합니다.

「문장 → 벡터」로 변환하고 있는 것은, 학습된 AI 모델이었습니다.

• 「의미가 가까우면 수치도 가까워진다」는 성질은, 이 모델이 방대한 문장을 학습한 결과로서 갖추고 있음
• 예: OpenAI의 embedding 모델, 각종 오픈 소스 모델 등
• 모델에 따라 출력되는 벡터의 차원 수가 결정됨 (예: 1536차원)

즉, 벡터의 「질」은 모델에 달려 있다는 것이죠. 이 부분이 AI의 전처리로서 핵심적인 역할을 하는 부분이라고 생각합니다.

ChatGPT와 같은 LLM은 똑똑하지만,

• 사내 문서
• 최신 정보
• 특정 업무의 로컬 규칙

는 모릅니다. 그래서 다음과 같은 흐름을 구성한다고 합니다.

• 사용자의 질문을 벡터화(Vectorization)한다
• **벡터 검색 (Vector Search)**으로 "관련되어 보이는 사내 문서"를 상위 N건 가져온다
• 그 문서를 LLM에 전달하며 "이것을 참고해서 답해줘"라고 지시한다
• LLM이 전달받은 문서를 **근거 (Grounding)**로 하여 답변을 생성한다

이 메커니즘을 **RAG (Retrieval-Augmented Generation / 검색 증강 생성)**라고 부른다고 합니다.

여기서 주목하고 싶은 점은 RAG의 "Retrieval (검색)" 부분입니다.

RAG의 심장부인 "관련 문서 검색"은 그야말로

DB의 역할

벡터 검색은 RAG의 토대가 되며, 이 부분이 RDB 엔지니어의 실력을 보여줄 수 있는 대목이 될 것 같습니다. "AI니까 자신과는 상관없다"가 아니라, 오히려 전문 분야의 연장선이라는 점에 여기서 조금 안심했습니다.

RDB 엔지니어로서 가장 궁금한 점은 아마 이 부분이겠죠. 저도 그랬습니다.

"그래서, 결국

테이블은 어떻게 되는 거지?"

결론부터 말씀드리면,

테이블은 그대로 존재합니다. 일반적인 테이블에 벡터 타입의 컬럼이 하나 추가될 뿐입니다.

마법 같은 별세계가 아니라, 평소 하던 테이블 설계의 연장이었습니다.

PostgreSQL + pgvector (PostgreSQL의 확장)를 예로 들면 다음과 같습니다.

-- 확장 기능 활성화
CREATE EXTENSION vector;
CREATE TABLE documents (
...

포인트는 다음 세 가지라고 생각합니다.

• embedding은 전용 타입이지만, 테이블 안의 하나의 컬럼일 뿐입니다
• department나 created_at 같은 일반적인 컬럼도 기존처럼 공존할 수 있습니다
• 기본키(Primary Key), 외래키(Foreign Key) 등 RDB의 규칙을 그대로 사용할 수 있습니다

실무에서는 긴 문서를 통째로 한 행에 넣는 경우는 드물며, 적절한 길이로 **분할 (Chunking)**하여 1 청크 = 1 행으로 만드는 경우가 많다고 합니다. doc_id와 chunk_no로 원본 문서와 연결합니다. 이것은 그야말로 테이블 설계의 문제이므로 이해하기 쉬웠습니다.

원본 문서 (PDF / Wiki 페이지)
↓ 적절한 길이로 분할
청크 1, 청크 2, 청크 3 ...
...

이 부분이 RDB 엔지니어로서 가장 기뻤던 점입니다. 메타데이터의 WHERE와 벡터의 ORDER BY를 하나의 SQL로 조합할 수 있습니다.

SELECT id, content
FROM documents
WHERE department = '인사부' -- ① 일반적인 WHERE로 모집단을 좁힘
...

이것은 "인사부의, 올해 이후 문서 중에서, 의미가 가까운 것 상위 5개"를 하나의 SQL로 표현하고 있습니다 (메타데이터 필터가 포함된 벡터 검색). WHERE로 범위를 좁힌 뒤 ORDER BY로 정렬하는 구조는 평소 쓰던 SQL 그 자체입니다.

이 부분이 개인적으로 가장 핵심적인 포인트라고 생각했습니다.

DB 자체는 "의미를 이해"하지 않습니다. 저장된 수치 벡터 간의 거리를 빠르게 계산하여 나열할 뿐입니다.

• INSERT 시: 미리 임베딩 (Embedding) 모델로 content를 벡터화하여, 그 수치열을 함께 INSERT한다
• 검색 시: 검색하고 싶은 문자열을 벡터화한 후, ORDER BY에 전달한다
• DB의 역할: 전달받은 벡터와 각 행의 벡터 사이의 거리를 계산하여 가까운 순서대로 나열한다

즉 "똑똑함 (의미 이해)"은 모델 측에 국한되어 있으며, DB는 기존처럼 "빠르고 정확하게 처리하는" 역할에 충실한 것입니다. RDB의 세계관 그대로 이해할 수 있다는 점을 알게 되어 마음이 훨씬 편해졌습니다.

한 가지 결이 다른 것이 인덱스(Index)였습니다. 완전 일치에 사용하는 B-tree와는 목적이 다르며, 벡터 검색에서는 **근사 최근접 이웃 탐색 (ANN, Approximate Nearest Neighbor Search)**용 인덱스를 사용한다고 합니다.

-- 코사인 유사도(Cosine Distance)를 위한 HNSW 인덱스
CREATE INDEX ON documents
USING hnsw (embedding vector_cosine_ops);

• HNSW… 그래프 구조를 사용한다. 정확도와 속도의 균형이 좋다
• IVFFlat… 클러스터로 나누어 탐색한다. 구축이 가볍다

"전체 데이터를 정확하게 비교하는" 것이 아니라 "대략적으로 가까운 것을 고속으로 찾아내는" 색인이라는 점만 파악해 두면 될 것 같습니다. CREATE INDEX

대상이라는 프레임워크 자체는 동일했습니다.

Pinecone, Weaviate, Milvus, Qdrant와 같은 전용 벡터 DB(Vector DB)도 있는 것 같지만, 테이블(Table), SQL, 인덱스(Index)라는 기존 기술을 그대로 활용할 수 있는 pgvector부터 시작하는 것이 RDB(관계형 데이터베이스) 분야에 종사하는 저에게는 가장 이해하기 쉬웠습니다.

완전 일치, 모호 검색, 벡터 검색을 나란히 놓고 보면 각각의 위치가 명확해집니다.

관점	완전 일치	모호 검색 (LIKE / fuzzy)	벡터 검색
비교 대상	문자가 완전히 동일한가	문자의 형태가 부분 일치 / 유사한가	의미가 유사한가
조건 작성 방식	WHERE =	WHERE LIKE 등	ORDER BY 거리 LIMIT N
강점	정확함 · 최속 · 설명 용이	표기 불일치 · 오타 대응	바꿔 말하기 · 동의어 · 문맥
인덱스	B-tree 등	B-tree / 전용	HNSW / IVFFlat (근사 최근접)
전처리	불필요	불필요	AI 모델로 벡터화

• 테이블에 행을 넣고 SQL로 추출한다는 기본 구조

• 일반 컬럼(메타데이터)과 공존하며 WHERE로 필터링할 수 있다는 점

• RDB의 설계 · 운용 · 인덱스 지식이 토대가 된다는 점

• 「일치」에서 「가까움」으로

• 검색 대상이 「문자열」에서 「의미 (벡터)」로

• 전처리로서 AI 모델 (벡터화)이 들어온다는 점

조사하며 느낀 점은, 벡터 검색이 「SQL의 완전 일치나 모호 검색을 그만두라」는 이야기가 아니라는 것이었습니다. 「의미로 찾고 싶을 때 사용하는 새로운 도구가 하나 늘어났다」 정도의 이야기인 것 같습니다. 모호 검색이 「문자의 변형」에 강한 것처럼, 벡터 검색은 「의미의 변형」에 강합니다. 그리고 그 새로운 도구를 뒷받침하는 「검색」과 「테이블 설계」는 RDB 엔지니어의 특기 분야 그 자체였습니다.

다음 단계로는 로컬 PostgreSQL에 pgvector를 설치하고, 몇 건의 데이터로

... ORDER BY embedding <=> :q LIMIT N

을 실제로 실행해 본다면 단번에 이해가 될 것이라고 생각합니다.

분명히...