Beyond RAG: Build a Relational Context Engine from Scratch — Peter Werry, Unblocked

한 줄 핵심

이 영상은 RAG를 검색의 절반으로 보고, 문서의 구조·신원·검증·재시도를 결합한 관계형 컨텍스트 엔진으로 자연어를 신뢰할 수 있는 데이터베이스 쿼리와 채팅 에이전트로 바꾸는 방법을 보여준다.

시간별 요약

1. 0:00
   Unblocked, 그리고 검색의 절반에 불과한 RAG Unblocked는 사람과 에이전트를 위한 조직 컨텍스트를 제공하는 컨텍스트 엔진을 만들며, 이 워크숍의 목표는 기존 RAG가 잘하는 의미 검색을 넘어 자연어를 실제 데이터베이스 쿼리로 바꾸는 나머지 절반을 구현하는 것이다.
2. 2:58
   흩어진 컨텍스트와 그 안의 구조 PR, 이슈, 문서, Slack 같은 곳에 흩어진 정보는 의미적으로도 찾을 수 있지만 작성자, 날짜, 상태, 관계 같은 구조도 함께 가진다. 단순 벡터 저장소에 다 넣는 방식은 이런 구조적 질문에 약하므로, 문맥 엔진은 의미 관계와 구조 관계를 함께 다뤄야 한다.
3. 5:15
   "지난주에 내가 머지한 PR"이 의미 검색에서 틀리는 이유 PRs I merged last week 같은 질문은 비슷한 문장을 찾는 문제가 아니라 머지 여부와 시점 같은 관계를 찾는 문제다. 의미적으로 비슷하지만 3년 전에 머지된 PR을 가져오면 오답이 되므로, 이런 질문에는 구조화된 쿼리가 필요하다.
4. 6:39
   모델에 필요한 네 가지: 스키마, 신원, 검증, 재시도 정확한 쿼리를 만들려면 모델이 스키마를 알고, Peter와 GitHub 로그인 같은 신원 매핑을 처리하고, 위험한 출력은 검증으로 차단하며, 실패 시 스스로 다시 시도해야 한다. 전체 흐름은 스텁 엔진에서 시작해 단계적으로 기능을 붙여 실제 동작하는 시스템으로 완성된다.
5. 9:16
   스텁된 엔진과 채팅 탭 초기 인터페이스는 아직 동작하지 않는 쿼리 입력창과, 별도로 구현된 채팅 탭으로 구성된다. 이후의 작업은 이 진입점을 중심으로 기능을 하나씩 붙여 나가는 방식으로 진행된다.
6. 10:11
   300개 문서 샘플링으로 스키마 발견하기 사전 스키마가 없을 때는 문서를 샘플링해 필드와 타입을 추론하고, 누락값은 건너뛰며 enum도 규칙 기반으로 뽑아낸다. 이런 추출은 LLM보다 절차적 코드로 처리하는 편이 더 결정적이고, 결과로 생성된 스키마와 인덱스는 이후 쿼리 합성에 사용된다.
7. 12:28
   신원 해석: Peter와 GitHub 로그인 자연어의 사람 이름이 실제 저장소의 사용자 로그인과 다를 수 있으므로, 이름을 그대로 매칭하면 아무 것도 찾지 못할 수 있다. 이를 해결하려면 Levenshtein 거리 같은 단순한 퍼지 매칭이나 동적 매핑을 통해 자연어 인명을 내부 식별자로 바꿔야 한다.
8. 14:36
   쿼리 계획: 강제 도구 호출과 현재 날짜 스키마와 도구를 넘겨주고 이름 추출용 도구 호출을 강제하면 모델이 쿼리 계획을 생성하고 실제 실행 단계로 넘어간다. 시간 조건이 들어간 질문은 현재 날짜와 시간을 프롬프트에 넣어 주어야 temporal query를 더 정확하게 만들 수 있다.
9. 16:27
   검증: 허용 목록, 숨김 필드, 테넌트 분리 쿼리 출력은 신뢰할 수 없으므로 허용된 연산자와 필드만 통과시키는 allow list 검증이 필요하다. 또한 ID나 메타데이터 같은 숨김 필드는 LLM에 노출하지 않고, 멀티 테넌트 환경에서는 테넌트 식별자를 내부에서 다시 주입해 격리를 보장해야 한다.
10. 19:35
    재시도 루프와 정확한 일치 실패 시의 전체 텍스트 검색 검증 실패나 실행 오류가 나면 에러를 다시 모델에 넣어 최대 횟수까지 재시도하며 쿼리를 스스로 수정하게 한다. 여전히 정확한 일치만으로 부족할 때는 full text search를 추가해 저수준 키워드 검색과 구조 필터를 함께 사용한다.
11. 22:29
    같은 엔진 위에서 추론하는 채팅 에이전트 채팅 탭의 에이전트는 쿼리 플레이그라운드와 같은 백엔드 엔진을 쓰지만, 가져온 결과를 바탕으로 추가 추론까지 수행한다. 그래서 단순 조회를 넘어서 "지난주에 인증 관련 작업이 있었는가" 같은 복합 질문에도 답할 수 있다.
12. 23:35
    재사용 가능한 아이디어 요약 전통적 RAG가 잘 못 푸는 구조적·시계열적 질문에는 스키마 인식, 동적 스키마 발견, 신원 해석, 검증, 오류 재시도가 결합된 엔진이 필요하다. 이 엔진은 필터링, 집계, 시간 범위 검색, full text search, 자기 수정까지 갖춘 채팅 에이전트의 기반이 된다.
13. 25:39
    Q&A: 스키마 확장, 수집, Slack, MCP, 하이브리드 검색 질의응답에서는 여러 데이터 소스와 큰 스키마를 어떻게 확장할지, 지속적 수집과 비용을 어떻게 다룰지, Slack이 왜 질문과 의사결정에 중요할지, MCP로 이런 구조를 어떻게 노출할지, 의미 검색과 lexical search를 결합한 하이브리드 검색을 어떻게 쓰는지가 논의된다.

실무 인사이트

• 구조적 질문을 다루는 검색 시스템은 벡터 검색만으로 끝나지 않고, 스키마 추론·신원 매핑·검증·재시도까지 한 흐름으로 설계해야 실무에서 쓸 수 있다.
• 안전성은 LLM에게 맡기기보다 allow list, 숨김 필드 제거, 테넌트 재주입처럼 절차적 코드로 강하게 통제하는 편이 낫다.
• 의미 검색은 단독 해법이 아니라 시작점으로 쓰고, 이후 구조화 쿼리와 도구 호출로 좁혀 가는 하이브리드 방식이 가장 실용적이다.