지식 그래프가 벡터 DB를 대체할 것인가 — 기업 AI 문답 시스템의 선택 판단
← 전체 목차 · 이전: AI는 어떻게 애플(회사)과 사과(과일)를 구분하는가
기업 내부 지식 문답 시스템에서 가장 흔한 실패 경로는 세 단계로 고정되어 있다.
- 팀이 처음부터 모든 회사 문서를 전부 벡터 DB에 던져 넣는다.
- 사용자의 질문이 조금만 우회하면 AI의 답변이 완전히 못 믿을 것이 된다.
- 누군가 지식 그래프가 요즘 유행이라더라를 듣고 "벡터 DB가 안 되는 거 아니냐, 시스템을 다 뜯어 지식 그래프로 바꾸자"고 제안한다.
3단계는 큰 오해다. 둘은 서로 대체하는 관계가 아니라 잘하는 문제 유형이 완전히 다르다.
벡터 DB가 잘하는 것: 비슷한 의미 찾기
| 단계 | 시스템이 하는 일 |
|---|
| 적재 | 텍스트나 이미지를 수학 좌표 한 줄로 바꾼다 |
| 검색 | 질문도 좌표로 바꾼 뒤 어느 자료의 좌표가 가장 가까운지 계산한다 |
판정 조건은 하나뿐이다: 의미가 가깝기만 하면 찾아낸다.
사용자 검색: 「내 아이폰 화면이 깨졌어요」 [0.8, 0.2, 0.5]
공식 수리 매뉴얼: 「휴대폰 디스플레이 패널 파손」 [0.81, 0.19, 0.52]
글자 → 완전히 다름 ✗
좌표 → 매우 가까움 🔗
결과 → 매칭 성공 ✓, 올바른 수리 가이드를 찾아 준다
벡터 DB의 명확한 경계: 의미 유사 ≠ 논리 관계
사용자 질문: 「A 회사의 사장은 누구인가요?」
검색 결과: 「B 회사 사장이 어제 A 회사 팀에게 밥을 샀다.」
오류의 기제는 모델이 나빠서가 아니라 유사도 자체의 성질 때문이다. 「사장」과 「회사」 같은 단어의 의미가 매우 가까워 시스템이 이 단락을 관련 있다고 판단해 가져왔지만, 이 두 사람이 도대체 누가 누구를 관리하는지는 전혀 모른다. 사용자에게는 "시스템이 헛소리를 한다"로 보인다.
지식 그래프가 잘하는 것: 명확한 엔티티와 관계
| 그래프의 구성 요소 | 대응 | 예시 |
|---|
| 노드 | 구체적 개념 | 사람, 회사 |
| 연결선 | 그들 사이의 관계 | 누구에게 투자했는가, 누구의 공급업체인가 |
관건적 차이: 이 관계가 데이터베이스에 명확히 기록되어 있다는 것이지 의미로 추론해낸 것이 아니다.
그래프가 경로를 걷는 법: A 회사 → 공장 → 경쟁사
"A 회사의 공급업체가 또 어떤 경쟁사들에 서비스했는가"에 그래프로 답한다면:
1. 먼저 A 회사라는 노드를 찾는다
2. 「공급업체」 연결선을 따라 → 몇 개의 공장을 찾는다
3. 이 공장들에서 「고객에게 서비스」 연결선을 따라 → 나간다
4. 「경쟁사」 라벨이 붙은 회사들을 걸러낸다
전 과정이 미로를 걷듯 경로가 매우 명확하고, 산출된 결과도 논리를 따진다.
그러나 지식 그래프도 만능이 아니다: 전제는 그래프를 먼저 제대로 만드는 것
- 당신이 이 노드와 연결선들을 미리 정리해내야 하고,
- 올바르게 저장해 두어야 한다.
반례: 처음부터 A 회사와 어떤 공장 사이에 연결선을 긋지 않았다면, 아무리 물어도 시스템은 그 관계를 찾아내지 못한다. 즉 그래프의 리콜 상한은 그래프를 만드는 그 순간에 잠기며 질문 기법으로 되살릴 수 없다.
선택의 핵심 근거: 사용자가 도대체 어떤 유형의 질문을 하는가
기술의 신구가 아니라 문제 유형을 본다.
| 사용자 질문의 형태 | 더 적합한 선택 | 이유 |
|---|
| 각양각색의 표현으로 방대한 규정·운영 매뉴얼에서 관련 규정을 찾고 싶다 | 벡터 DB | 가장 직접적이고 가성비가 가장 높다 |
| 여러 겹의 관계를 넘나들어야 한다: 누가 누구를 관리하는가, 누가 누구에 의존하는가, 서로 다른 사람의 신분 비교 | 지식 그래프 | 대개 더 우위를 발휘하기 쉽다 |
그래프 쪽에는 부가 조건 두 가지가 붙으며 하나도 빠질 수 없다.
- 그래프 안의 엔티티와 관계 자체가 충분히 정확할 것
- 이 문제가 정말로 관계 경로를 따라 조회하기에 적합할 것
역방향 경계: 복잡한 관계가 없으면 억지로 그래프를 만들지 말 것
- 업무 데이터에 애초에 그렇게 복잡한 논리 관계가 없고 그저 순수한 설명 문서라면,
- 기술이 대단해 보이려고 억지로 지식 그래프를 만들지 말 것.
- 결과는 두 가지다: 좋은 결과도 나오지 않고, 대량의 시간과 비용을 낭비한다.
산업급 시스템의 성숙한 방식: 두 방향의 조합
방향 1: 벡터가 먼저 그물을 던지고 그래프가 검증한다
1. 먼저 벡터 검색으로 「큰 그물을 한 번 던진다」
의미 유사도를 아는 우위를 활용
2. 관련 가능성이 있는 문서, 대략 관련된 회사와 인명을 전부 건져 올린다
3. 그다음 지식 그래프로 꼼꼼히 검사한다
건져 올린 회사와 인명 사이에 우리가 필요로 하는 논리 연결선이 정말 있는가
방향 2: 그래프가 먼저 범위를 좁히고 벡터가 증거를 찾는다
1. 먼저 그래프로 범위를 한 부서의 몇 사람으로 좁힌다
2. 그다음 벡터 DB와 원본 문서로 돌아가
3. 그들이 구체적으로 무엇을 했는지의 증거를 찾아낸다
한 줄 총결: 셋이 각각 무엇을 담당하는가
| 컴포넌트 | 무엇을 제공하나 |
|---|
| 그래프 | 명확한 논리 골격 |
| 벡터 | 자연어에 대한 포용도 |
| 가장 원본인 문서 내용 | AI에게 최종적으로 답변할 근거 제공 |
세 번째 항목에 주목할 것: 벡터와 그래프는 물건을 찾아낼 뿐이고, 정말로 가져가서 답하는 근거는 여전히 원본 문서다.
결론: 누가 누구를 대체하는지 묻지 말고, 이 문제가 무엇에 의존하는지 물을 것
- 더 이상 묻지 말 것: 지식 그래프와 벡터 DB 중 누가 누구를 대체할 것인가?
- 물어야 할 것: 내가 지금 풀려는 이 문제는 의미상의 유사에 더 의존하는가, 아니면 명확한 논리 관계에 더 의존하는가?
많은 복잡한 시나리오의 답은 애초에 양자택일이 아니며, 두 검색 방식이 각자 가장 잘하는 부분을 처리하게 하는 것이다.
선택 절차
0. 기술을 먼저 고르지 말고 실제 질문을 먼저 수집할 것
사용자가 실제로 물을 질문 샘플이 유일한 선택 근거다
1. 각 질문을 분류
A류: 표현이 다양하고, 답은 어떤 문서 안에 쓰여 있다
(「휴가는 어떻게 신청하나요」「연차는 며칠인가요」)
B류: 여러 겹의 관계를 넘나들어야 답을 얻는다
(누가 누구를 관리하는가, 누가 누구에 의존하는가, 신분 비교)
2. 대부분 A류라면
→ 벡터 DB. 가장 직접적이고 가성비가 가장 높다
→ 기술이 대단해 보이려고 억지로 지식 그래프를 만들지 말 것
3. 뚜렷한 B류가 있다면, 착수 전에 두 전제를 먼저 검증할 것
전제 1: 그래프 안의 엔티티와 관계 자체가 충분히 정확한가
전제 2: 이 문제가 정말로 관계 경로를 따라 조회하기에 적합한가
하나라도 성립하지 않으면 아직 그래프를 만들지 말 것
4. 그래프를 만들 때 「연결선」을 리콜 상한으로 취급할 것
긋지 않은 연결선 = 영원히 조회할 수 없는 관계
5. 두 유형이 모두 있으면 조합해 쓸 것(방향 1)
벡터 검색이 큰 그물을 던짐 → 관련 문서 + 관련 회사·인명을 건져 올림
→ 지식 그래프가 그들 사이에 필요한 논리 연결선이 있는지 검사
6. 또는 반대로(방향 2)
그래프가 먼저 범위를 한 부서의 몇 사람으로 좁힘
→ 벡터 DB와 원본 문서로 돌아가 그들이 한 일의 증거를 찾음
7. 마지막 단계는 언제나 원본 문서로 돌아온다
그래프가 논리 골격을, 벡터가 자연어 포용도를 주지만
AI에게 최종 답변 근거를 제공하는 것은 가장 원본인 문서 내용이다
핵심 통찰
- "AI가 못 믿을 답을 한다"가 반드시 모델 문제인 것은 아니며, 검색 방식과 문제 유형의 불일치일 수 있다 — 실패 시나리오에서 벡터 DB는 사실 정상 작동했다. "의미가 가장 가까운" 단락을 확실히 찾아 주었고, 다만 사용자가 원한 것이 논리 관계였을 뿐이다. 이런 실패를 "모델이 나쁘다"나 "DB를 바꾸자"로 귀인하면 처음부터 방향이 틀린다.
- 유사도는 일종의 "논리 없는 정확함"이다 — "B 회사 사장이 어제 A 회사 팀에게 밥을 샀다"는 벡터 공간에서 "A 회사의 사장은 누구인가"와 확실히 가깝다. 「사장」「회사」의 의미가 가깝기 때문이다. 시스템이 잘못 가져온 것이 아니라 애초에 「누가 누구를 관리하는가」라는 개념 자체가 없다.
- 벡터의 능력 상한은 의미가 결정하고, 그래프의 능력 상한은 그래프를 만드는 그 순간이 결정한다 — 벡터 검색은 본 적 없는 표현에도 어느 정도 대응하지만, 그래프는 일단 "A 회사와 어떤 공장 사이에 연결선을 긋지 않으면" 아무리 물어도 찾지 못한다. 전자의 실패는 모호함이고 후자의 실패는 완전한 결손이므로, 두 유형의 실패는 완전히 다른 방식으로 원인을 규명해야 한다.
- 선택의 판정 기준은 "사용자가 어떤 유형의 질문을 하는가"이지 "어느 기술이 더 새롭고 유행인가"가 아니다 — 지목된 두 가지 잘못된 동기 — "지식 그래프가 유행이라니 다 뜯어 바꾸자"와 "기술이 대단해 보이려고 억지로 그래프를 만들자" — 와 업무 문제의 형태 사이에는 아무 인과 관계도 없다.
- 기술 선택은 "새 기술을 도입하지 않음"이라는 답도 허용해야 한다 — 데이터에 복잡한 논리 관계가 없고 순수한 설명 문서뿐일 때 억지로 그래프를 만드는 대가는 두 가지다: 좋은 결과도 안 나오고 대량의 시간과 비용을 낭비한다. "여기엔 그래프가 필요 없다"고 인정하는 것 자체가 가치 있는 결론이다.
- 조합 방안의 본질은 "한 방식의 강점으로 다른 방식의 실패 모드를 막는 것"이다 — 벡터가 그물을 던져 "후보 집합을 다 못 부르는 것"을 해결하고, 그래프가 검증해 "후보 집합에 논리적으로 성립하지 않는 것이 섞인 것"을 해결한다. 반대로 그래프가 범위를 좁혀 "범위가 너무 큰 것"을 해결하고, 벡터가 증거를 찾아 "관계는 있는데 사실 디테일이 없는 것"을 해결한다. 두 방향 모두 A의 강점으로 B의 약점을 메우는 것이지 단순한 중첩이 아니다.
- 검색층과 답변층을 나눠서 볼 것 — 삼분법에서 그래프가 골격을, 벡터가 포용도를 주지만 최종 답변의 근거는 가장 원본인 문서 내용이다. 즉 그래프와 벡터는 "어떻게 찾아내는가"에 속하며 "무엇으로 답하는가"를 대체하지 않는다. 구조화된 결과를 곧바로 답으로 삼는 것은 또 다른 유형의 오류다.
- 좋은 아키텍처 질문은 판정 가능하다 — "누가 누구를 대체하는가"는 제약 조건이 없어 판정할 수 없고, "이 문제는 의미상의 유사에 더 의존하는가 명확한 논리 관계에 더 의존하는가"는 선택을 관측 가능한 사용자 질문에 걸어 두었으므로 판정할 수 있다. 질문을 바꾸는 편이 답을 바꾸는 것보다 효과적이다.
엔지니어링 실전 Tips
- 「조금 우회한 질문」을 검수 케이스로 쓸 것: 실패 시나리오의 트리거 조건이 바로 이것이다. 직구 질문은 누구나 맞히므로, 선택의 차이는 한 겹 우회한 뒤에야 드러난다.
- 실패가 어느 유형인지 먼저 판단하고 무엇을 고칠지 정할 것: 답이 "관련 있어 보이는데 논리가 성립하지 않는다"면 벡터의 경계 문제이므로 그래프 검증을 더해야 하고, 답이 "아예 이 관계를 찾지 못한다"면 그래프에 연결선이 없는 문제이므로 그래프로 돌아가 보완해야 한다. 둘의 수리법은 완전히 다르다.
- 관계를 명시적 자산으로 유지 관리할 것: 그래프의 「누구에게 투자했는가」「누구의 공급업체인가」 같은 관계는 미리 정리하고 올바르게 적재해야 한다. 문서처럼 던져 넣으면 쓸 수 있는 것이 아니며, 정리와 적재 자체가 작업량이다.
- 기술 유행도를 선택 회의에 들이지 말 것: 판정 기준은 사용자 질문의 유형뿐이다.
- 조합 방안은 방향을 잘 고를 것: 후보 범위가 크고 입구가 자연어 질문이면 「벡터가 그물 → 그래프가 검증」, 입구가 이미 명확한 조직이나 부서면 「그래프가 범위 축소 → 벡터가 증거 확보」. 방향을 반대로 고르면 느리고 부정확하다.
- 원본 문서를 보존하고 가공된 구조만 저장하지 말 것: 삼분법에서 원본 문서가 답변 근거다. 벡터 인덱스만 남기거나 그래프 삼원조만 남기면 마지막 단계에서 인용할 것이 없어진다.
- 더 파고들 방향: 문제 분류 단계의 자동화(들어오는 질문이 A류인지 B류인지 온라인으로 판단해야 조합 방안이 자동 라우팅된다), 그래프 구축의 비용과 정확률 평가(투입 전에 관계 추출의 정확률이 기준에 닿는지 먼저 측정), 두 조합 방향의 트리거 조건을 명시적 규칙으로 작성, 검색 결과와 원문의 정렬 방식(답변이 소급·대조 가능한지를 결정).