벡터는 닮은 것을, 그래프는 연결된 것을 찾습니다 — 떡볶이로 설명한 RAG

RAG 도입을 검토하는 분들과 만나면 거의 매번 같은 질문을 받습니다. 벡터DB와 그래프DB 중에 뭘 써야 하느냐는 질문입니다. 처음에는 임베딩과 코사인 유사도부터 차근차근 설명했습니다. 설명이 끝나갈수록 상대의 표정이 더 흐려져 있었습니다.

같은 설명을 열 번쯤 반복하다가 비유를 하나 만들었습니다. 분식집 이야기입니다. 이 글은 강의가 아니라 제가 실제로 미팅에서 쓰는 설명을 정리한 기록입니다. 이 블로그에 쌓인 RAG 운영 회고들이 전제하고 있는 기초이기도 합니다.

컴퓨터는 글의 뜻을 모릅니다

컴퓨터는 문장의 의미를 이해하지 못합니다. 그래서 모든 문장을 숫자 성적표로 바꿔서 보관합니다. 저는 이것을 맛 성분표라고 부릅니다.

떡볶이를 성분표로 적으면 이렇습니다.

매운맛 9

단맛 6

짠맛 4

신맛 1

실제로는 항목이 네 개가 아니라 1024개입니다. 그리고 항목에 이름이 없습니다. 이 칸은 매운맛이라고 정해둔 것이 없고 그냥 숫자 1024개입니다. 사람이 읽어봐야 아무 의미가 없습니다. 오직 다른 성분표와 비교할 때만 쓸모가 생깁니다.

문장이 길어져도 칸은 늘지 않습니다

설명할 때 가장 자주 막히는 지점이 여기입니다. 떡볶이 한 접시든 열 접시든 성분표는 네 칸 그대로입니다. 양이 늘어난 것이지 항목이 늘어난 것이 아닙니다.

문장도 같습니다. "안녕" 두 글자도 1024칸이고, A4 두 장짜리 문서도 1024칸입니다. 글자가 많아지면 숫자 개수가 늘어나는 것이 아니라 각 칸의 값이 조정될 뿐입니다.

1024라는 숫자 자체는 모델마다 다릅니다. 768인 모델도 있고 1536인 모델도 있습니다. 중요한 것은 숫자가 몇이냐가 아니라 길이가 고정되어 있다는 점입니다.

검색은 비율이 닮은 것을 찾는 일입니다

"맵고 단 거 뭐 있어?"라는 질문도 똑같이 성분표로 바뀝니다. 매운맛 8 / 단맛 7 / 짠맛 2 / 신맛 1 정도가 됩니다. 그리고 창고에 쌓인 성분표들과 하나씩 비교합니다.

여기서 핵심은 양이 아니라 비율을 본다는 점입니다. 그래서 다섯 글자짜리 짧은 질문과 300글자짜리 긴 문단을 나란히 놓고 비교할 수 있습니다. 질문은 짧고 문단은 길어서 비교가 안 되는 것이 아니라, 둘 다 같은 길이의 비율표로 바뀐 다음에 만나기 때문입니다.

이렇게 닮은 문단을 찾아 AI에게 함께 넘겨주는 것이 RAG입니다.

검색이 안 된다는 호소는 대개 비빔밥 문제입니다

비빔밥으로 성분표를 만들면 나물과 고기와 계란과 고추장이 전부 뭉개져 평균이 됩니다. 그래서 "고소한 나물 있어?"라고 물으면 분명 나물이 들어 있는데도 걸리지 않습니다. 다른 재료들이 성분표를 애매하게 만들어버린 탓입니다.

문단도 같습니다. 한 문단에 주제 다섯 개가 섞여 있으면 그 문단의 성분표는 다섯 개의 평균이 됩니다. 그중 하나만 겨냥한 질문은 그 문단을 놓칩니다. 답이 분명히 그 안에 있는데도 놓칩니다.

그래서 문단을 잘게 쪼개어 저장합니다. 비빔밥을 통째로 재지 말고 나물과 고기와 계란을 따로 재두는 방식입니다. 다만 너무 잘게 쪼개면 문맥이 끊겨서 문단 하나만으로는 뜻이 통하지 않습니다. 쪼개기도 만능은 아닙니다.

검토 자리에서 "우리 문서는 검색이 안 된다"는 호소를 받으면, 저는 모델을 바꾸는 이야기를 하기 전에 문단부터 봅니다. 넓은 질문에 답변이 빠지는 현상도 대개 같은 뿌리에서 나옵니다.

성분표에 절대 안 적히는 것이 있습니다

성분표로는 알 수 없는 사실이 하나 있습니다. 떡볶이와 순대는 같은 분식집에서 판다는 사실입니다. 이건 맛의 문제가 아니라 관계입니다. 성분표 어디에도 적혀 있지 않습니다.

그래서 관계는 따로 지도로 그려둡니다.

떡볶이 ──같은가게── 순대 ──만든사람── 김사장

그래프DB는 무엇과 무엇이 어떻게 연결되어 있는지만 저장하는 곳입니다. 맛은 모릅니다. 대신 김사장이 만든 메뉴가 무엇인지, 그 메뉴들이 어느 가게에 걸려 있는지를 압니다. 벡터는 닮은 것을 찾고 그래프는 연결된 것을 찾는다는 말이 여기서 나옵니다.

지도부터 볼지, 맛부터 볼지

둘은 경쟁 상대가 아니라 같이 쓰는 짝입니다. 다만 어디서 시작하느냐가 갈립니다.

맛부터 보는 경우(벡터 우선) — "맵고 단 거"처럼 붙잡을 이름이 없을 때입니다. 성분표로 비슷한 것을 하나 찾고, 그다음 지도를 펴서 연결된 것들을 함께 가져옵니다.

지도부터 보는 경우(그래프 우선) — "김사장네 가게 메뉴 중 매운 것"처럼 이름이 딱 나올 때입니다. 지도에서 스무 개로 먼저 좁히고 그 안에서만 성분표를 비교합니다. 10만 개를 전부 뒤지는 것보다 정확합니다.

한 문장으로 줄이면 이렇습니다. 질문에 붙잡을 이름이 있으면 지도 먼저, 없으면 맛 먼저입니다.

그래프 우선이 항상 정확하지는 않습니다. 이름을 잘못 잡으면 처음부터 엉뚱한 스무 개로 좁혀버립니다. 그래서 진입점 선택은 한 번 정하고 끝나는 설정이 아니라 질문 유형별로 계속 손보는 대상입니다.

그리고 둘을 그냥 동시에 돌리는 방식은 생각만큼 잘 풀리지 않습니다. 서로의 결과를 모른 채 각자 답을 들고 오기 때문입니다.

이 비유가 감추는 것

비유는 성분표의 각 칸이 사람이 정한 축인 것처럼 들리게 만듭니다. 실제 차원은 사람이 해석할 수 없는 값입니다. 이 칸이 매운맛이라고 지목할 수 있는 칸은 없습니다.

설명할 때 이 대목을 꼭 덧붙입니다. 빼놓으면 다음 미팅에서 그 매운맛 칸을 우리가 직접 조정할 수 있느냐는 질문이 돌아옵니다. 비유는 입구를 열어주는 도구이고, 입구를 지나면 비유를 내려놓아야 하는 지점이 옵니다.

용어 대응표

미팅에서 비유로 설명한 뒤에는 이 표를 함께 봅니다. 개발팀과 대화할 때 쓰는 말로 옮겨두면 이후 논의가 어긋나지 않습니다.

검토 자리에서 확인하는 것들

벡터는 닮은 것을 찾고, 그래프는 연결된 것을 찾습니다. 경쟁이 아니라 짝입니다. 도입을 검토하는 자리에서 이 비유를 깔고 나면 확인할 것이 네 가지로 정리됩니다.

우리 문서의 한 문단이 몇 개 주제를 담고 있는지

사용자 질문에 사람·조직·제품처럼 붙잡을 이름이 자주 등장하는지

그 이름들이 관계로 정리되어 있는지, 아니면 문서 본문에만 흩어져 있는지

검색이 안 될 때 문단 구조를 보기 전에 모델 교체부터 검토하고 있지는 않은지

이 네 가지는 기술 선택이 아니라 데이터 상태에 대한 질문입니다. 도구를 고르기 전에 답이 나와 있어야 비교가 의미를 갖습니다.

여기까지가 제가 미팅에서 쓰는 설명의 전부입니다. 이 다음부터, 그러니까 실제로 운영에 올린 뒤에 무엇이 깨지고 무엇을 다시 손보게 되는지는 이 블로그의 RAG 회고 글들에 나눠 적어두었습니다.