섞어서 설계하고, 어디서 시작할지 고르기

처음부터 전면적인 그래프를 깔 필요는 없습니다. 핵심은 저장소를 여러 개 사는 일이 아니라, 원본, 검색용 정리, 관계 지식, 종합 지식을 서로 분리해 관리하는 일입니다.

네 개 층

오래 쌓이면 이것은 검색기가 아니라, 경험과 판단 근거를 다시 쓸 수 있는 지식으로 바꾸는 체계가 됩니다. 두 번째 프로젝트에서 옛 원문을 전부 다시 뒤지는 대신, 이미 만든 위키와 그래프로 관계를 보고 새 정보만 갱신할 수 있습니다. 대가도 있습니다. 위키가 바뀌면 색인, 그래프, 요약, 캐시가 함께 갱신돼야 합니다.

질문마다 다른 길

한 질문에 여러 길을 동시에 쓰기도 합니다. 그래프로 관계를 찾고, 연결된 계약 원문은 하이브리드 검색으로 확인하고, 금액은 SQL로 검증합니다.

한 문장으로 줄이면 이렇습니다. 문서형 자료는 미리 정리해 두고, 데이터베이스와 업무 앱은 원본을 그때그때 조회하며, 질문 종류에 맞는 도구로 근거를 모은 뒤 출처와 함께 답합니다.

작게 시작하고 필요할 때 키우기

PostgreSQL 전문 검색은 가벼운 시작용이고 pgvector와 같이 쓸 수 있지만, 그 순위 방식이 BM25인 것은 아닙니다. 그래프도 처음부터 Neo4j가 필요하지 않습니다. 관계의 양과 탐색 깊이가 작으면 관계 표로 시작하고, 질의가 복잡해질 때 전문 그래프 데이터베이스로 넓힙니다. 한국어 키워드 검색은 노리처럼 형태소 분석과 사용자 사전을 지원하는 도구가 유리합니다.

한눈에 보는 비교

규모별 출발점

개인·소규모. 문서 수백 건 이하, 토큰 20만 내외면 긴 문맥이나 위키부터 시작합니다. 벡터 저장소부터 세우는 것은 대개 순서가 틀렸습니다. 마크다운에 에이전트를 붙여 위키를 유지하면 검색 설비 없이도 출처 있는 답까지 갈 수 있습니다. 규모가 넘치면 고도화된 검색을 얹습니다.

팀·제품. 문서 수천에서 수만 건, 매일 질문이 있으면 고도화된 검색이 기본값입니다. 구조를 살리는 나누기, 문맥 기반 검색, 하이브리드, 재정렬, 출처 강제. 평가 집합과 사용자 반응 수집을 처음부터 붙입니다. 관계형 질문의 비중이 실제로 높을 때만 그래프를 더합니다.

대규모·규제 분야. 법률, 의료, 금융, 정책은 고도화된 검색에 구조화 자료 도구, 권한 거르기, 감사 기록이 필수입니다. 에이전트 길은 어려운 질문에만 열고, 모든 답에 출처 검증을 겁니다.

순서를 정하는 다섯 질문입니다.

1. 전체가 문맥에 들어가고 잘 안 바뀌는가? 그렇다면 긴 문맥부터.
2. 질문이 대부분 한 문서 안의 사실인가? 그렇다면 고도화된 검색.
3. 관계, 다중 홉, 전역 요약이 핵심 가치인가? 그렇다면 그래프 또는 위키의 연결.
4. 개인의 쌓이는 노트인가, 조직의 공식 문서인가? 전자는 위키, 후자는 검색과 관리 체계.
5. 문제는 지식이 아니라 모델의 행동인가? 그렇다면 미세 조정이나 지시 설계를 먼저.

2025년 ICML의 LaRA 연구도 같은 방향을 가리킵니다. 검색과 긴 문맥 중 어느 쪽이 유리한지는 모델, 문서 길이, 검색 특성, 질문 종류에 따라 달라집니다. 항상 이기는 한쪽은 없습니다.