RAG를 넘어선 관계형 컨텍스트 엔진으로 토큰 비용 절반 줄이기

URL: https://www.youtube.com/watch?v=djKIU-30YVc 날짜: 2026-10-14 채널: Tech Bridge 원문 제목: [한영자막] RAG만으로는 부족합니다: 토큰 비용을 절반으로 줄이는 관계형 컨텍스트 엔진 발표자: Peter, Unblocked

---

메타데이터

• 콘텐츠 유형: YouTube 기술 다이제스트
• 핵심 주제: 관계형 컨텍스트 엔진(Relational Context Engine), 검색 증강 생성(Retrieval-Augmented Generation, RAG), 자연어-구조화 쿼리 변환
• 관련 오픈소스 프로젝트: Document Query Engine, Context Engine Simulator
• Nuggets 카테고리: ai-llm
• 영상 길이: 약 18분 47초

---

📌 핵심 질문 / 핵심 논점

==RAG는 문맥의 내용을 찾는 데 강하지만, 시간·관계·집계·권한처럼 구조를 묻는 질문에는 부족하므로, 의미 검색과 구조화 쿼리를 함께 처리하는 관계형 컨텍스트 엔진이 필요하다.==

• 조직의 코드, 문서, PR(Pull Request), 리뷰, 이슈, 티켓, 대화에 흩어진 지식을 서로 연결된 컨텍스트 번들로 정리할 수 있다.
• 구조화 쿼리 생성에는 스키마 발견, 사용자 식별자 매핑, 안전성 검증, 오류 자기 수정이라는 주변 장치가 필요하다.
• 실제 Source Mark 최적화 사례에서 컨텍스트 엔진을 붙인 비용은 약 1.29달러, 소요 시간은 약 1분 30초였고, 붙이지 않은 경우 최대 약 2.60달러와 3분이 들었다.
• Document Query Engine은 필터, 집계, 시간 범위, 전문 검색, 재시도 기반 자기 수정을 지원해 에이전트와 사람이 구조화된 조직 지식을 질의하도록 한다.

컨텍스트 엔진은 단순한 벡터 검색기를 대체하는 것이 아니라 의미 검색의 반대편에 있는 구조적 검색을 보완한다. 자연어 질문을 안전한 구조화 쿼리로 바꾸고, 검색 결과를 다시 에이전트의 추론에 제공함으로써 비용과 탐색 시간을 줄이면서도 코드와 조직의 운영 맥락을 함께 보존한다.

1. 컨텍스트 엔진의 역할과 필요성

조직의 지식은 한 저장소에 모여 있지 않으며, 서로 다른 시스템에 흩어진 자료와 누적된 운영 경험을 연결해야 실제 업무에 쓸 수 있는 문맥이 된다.

1.1. 에이전트 이전의 ‘사람이 컨텍스트 레이어’였던 시기

1. 신입 직원의 정보 탐색 문제

   1. 코드베이스 탐색: 새로 합류한 사람은 조직의 코드와 구조를 파악하기 위해 많은 파일을 직접 읽어야 한다.
   2. 문서 시스템 순회: 필요한 정보를 찾기 위해 여러 문서 시스템을 오가며 업무에 필요한 조각을 모아야 한다.
   3. 조직의 공유 역사 학습: 장애 대응, 반복된 사건, 그 과정에서 생긴 ‘전투의 상흔(battle scars)’까지 장기간에 걸쳐 습득해야 한다.

2. AI 에이전트와 동일한 출발점

   1. 새 직원과 같은 상태: 컨텍스트 엔진이 없는 Claude는 새 업무를 시작할 때 코드베이스나 조직을 거의 모르는 신입 직원처럼 행동한다.
   2. 탐색 후의 과도한 확신: Claude는 코드를 훑고 어느 정도 결론에 도달하지만, 실제로 이해했는지와 무관하게 이해했다고 자신 있게 추정할 수 있다.

1.2. 흩어진 지식을 grounded context로 바꾸기

1. 컨텍스트 엔진의 입력과 출력

   1. 분산된 지식의 수집: 조직의 제도적 지식(institutional knowledge)을 코드, 문서, 협업 기록 등에서 끌어온다.
   2. grounded context 생성: 서로 관련된 자료를 연결해 근거가 있는 컨텍스트를 만든다.

2. 좋은 컨텍스트의 네 가지 속성

   1. 상호 연결성(interrelated): 각각의 자료가 고립된 검색 결과가 아니라 다른 자료와 관계를 가진다.
   2. 의도 특이성(intent-specific): 현재 요청의 목적에 맞는 정보만 묶인다.
   3. 개인화(personalized): 질문자의 정체성과 업무 맥락에 따라 관련 정보가 달라진다.
   4. 권한 인식(permissions-aware): 사용자가 접근할 수 있는 범위 안에서만 정보와 쿼리가 만들어진다.

2. 컨텍스트 엔진이 만드는 실제 가치

코드만 검색하는 것보다 설계 문서, 변경 이력, 대화까지 연결하면 에이전트의 조사 범위가 좁아지고 결과의 근거가 촘촘해진다.

2.1. Source Mark 엔진 최적화 사례

1. 컨텍스트 엔진이 없는 Claude

   1. 요청: 조직의 레이어에 있는 Source Mark 엔진 컴포넌트를 최적화할 계획을 세워 달라고 요청했다.
   2. 탐색 방식: Claude는 코드베이스를 이리저리 살피며 무슨 일이 일어나는지 추정한다.
   3. 결과의 한계: 시간이 지나 추천안을 내놓지만, 실제 이해가 아니라 ‘이해했다고 자신 있게 투사한 것’일 수 있다.

2. 컨텍스트 엔진을 연결한 Claude

   1. 작업별 번들: Unblocked Context Engine이 해당 작업에 맞는 포괄적이고 작업 특화된 컨텍스트 번들을 제공한다.
   2. 연결된 근거: Source Mark 소스 코드뿐 아니라 아키텍처를 설명한 Notion 문서, 관련 PR, 컴포넌트 최적화를 논의한 Slack 대화까지 참조한다.
   3. 후속 탐색 경로: 번들 안의 링크가 촘촘하게 연결되어 Claude가 추가 정보가 필요할 때 바로 이동할 수 있는 출발점이 된다.

3. 비용과 시간의 변화

   1. 컨텍스트 엔진 사용: 약 1.29달러, 약 1분 30초가 소요됐다.
   2. 컨텍스트 엔진 미사용: 최대 약 2.60달러와 3분이 들었다.
   3. 효과: 비용이 약 50% 감소했다. 더 많은 정보를 무작정 프롬프트에 넣는 방식이 아니라, 작업에 맞는 번들과 링크를 먼저 제공하는 방식의 효과다.

2.2. 코드 리뷰 회귀(regression) 추적 사례

1. 문제 발견

   1. 제품 지표 하락: 코드 리뷰 제품이 표면화하는 이슈 수가 점점 줄어들었다.
   2. 질문: 동료 Richie가 Unblocked에 원인을 물었고, 컨텍스트 엔진이 관련 정보를 빠르게 좁혔다.

2. 원인과 수정

   1. 모델 변경: Opus 4.6에서 Opus 4.8로 전환한 뒤 내부 동작 특성 변화가 이슈 수 하락을 유발했을 가능성이 가장 높은 원인으로 제시됐다.
   2. 자동 수정 PR: Richie가 수정해 달라고 요청하자 Unblocked가 배경 컨텍스트를 바탕으로 PR을 만들었다.
   3. 회귀의 근거 연결: 회귀를 처음 유발한 PR을 찾아내고, 같은 문제가 논의된 Slack 대화까지 발견해 수정에 필요한 데이터를 끌어왔다.
   4. 가치: 단일 코드 검색이 아니라 변경 이력과 조직의 논의가 결합되어 원인 추적과 수정안 작성이 이어졌다.

3. 데모 진행 중 발생한 상황

   1. 발표 화면 전환: Keynote 화면을 잘못 열었다가 원래 발표 화면으로 돌아오는 장면이 있었다.
   2. 시간 제약: 약 20분 발표이므로 컨텍스트 엔진의 전체 가치를 요약한 뒤 구현 단계로 빠르게 이동했다.

3. RAG가 잘하는 일과 놓치는 일

조직 데이터는 의미적으로도 검색할 수 있고 구조적으로도 질의할 수 있으므로, 한 가지 검색 방식만으로는 전체 문제를 다루기 어렵다.

3.1. RAG가 해결하는 의미적 검색

1. 컨텍스트가 흩어진 위치

   1. 코드와 변경 기록: PR, 코드 리뷰, 리뷰 댓글, 이슈, 티켓에 정보가 남는다.
   2. 비정형 협업 자료: 문서와 대화에도 설계 의도와 운영 배경이 축적된다.
   3. 두 가지 성격: 이 자료들은 의미적으로 질의할 수 있을 뿐 아니라 구조화된 속성도 가진다.

2. RAG와 에이전트 루프의 강점

   1. 내용 질문: “코드를 찾아라”, “그 코드를 바꾼 PR을 찾아라”, “그 변경을 논의한 Slack 스레드를 찾아라” 같은 질문에 강하다.
   2. 도구 결합: 에이전트 루프에 파일 검색 도구를 더하면 여러 단계의 내용 탐색을 수행할 수 있다.
   3. 한계: RAG는 관련 문서를 찾는 데는 강하지만 관계, 집계, 시간 범위처럼 데이터 구조를 계산해야 하는 질문을 벡터 저장소만으로 처리하기 어렵다.

3.2. 구조적 질문은 의미 검색이 아니다

1. 구조적 질문의 예

   1. 목록 질문: “내가 지난주에 병합한 PR은 무엇인가?”
   2. 관계 질문: “Payments를 가장 많이 리뷰한 사람은 누구인가?”
   3. 상태 질문: “현재 열려 있는 PR은 무엇인가?”
   4. 시간·집계 질문: “1월 1일부터 주간 비율(ratio)을 차트로 보여 달라.”

2. 두 종류의 검색

   1. 의미 검색(semantic retrieval): 개념과 내용의 유사성을 기반으로 관련 자료를 찾는다.
   2. 구조 검색(structured retrieval): 필터, 집계, 시간 범위, 관계를 보존하는 구조화 쿼리를 실행한다.
   3. 구현 목표: 자연어 질문을 구조화 쿼리로 바꾸어 RAG의 구조적 절반을 담당한다.

4. Document Query Engine 구현

자연어를 데이터베이스 쿼리로 바꾸는 문법 변환 자체보다, 안전하고 정확한 실행을 보장하는 주변 스캐폴딩(scaffolding)이 핵심이다.

4.1. 자연어 질문을 구조화 쿼리로 변환하기

1. 목표 입력과 출력

   1. 자연어 입력: “Rasheen이 작성한 열린 PR을 보여 줘(open PRs by Rasheen).”
   2. 구조화 출력: LLM이 질문의 의도에 맞는 필터와 조건을 포함한 쿼리를 생성한다.
   3. 초기 상태: 오픈소스 Document Query Engine을 처음 실행하면 아무 연결도 되어 있지 않아 결과를 내지 않으며, 각 구성 요소를 순서대로 추가해야 한다.

2. 생성보다 어려운 스캐폴딩

   1. 스키마 전달: LLM이 허용된 필드와 자료 구조에 정확히 묶인(tightly bound) 쿼리를 만들도록 스키마를 이해하고 전달해야 한다.
   2. 식별자 매핑: 자연어 이름과 GitHub·Slack 등 각 시스템의 실제 계정이 다를 수 있어 동일 인물을 찾아야 한다.
   3. 검증: LLM 출력은 신뢰할 수 없으므로 위험한 연산이나 테넌트 경계 침범 여부를 검사해야 한다.
   4. 오류 복구: 검증을 통과했더라도 데이터베이스 실행에서 오류가 날 수 있어 자기 수정 경로가 필요하다.

4.2. 런타임 자동 스키마 발견

1. 동적 스키마 구축

   1. 문서 샘플링: 문서 저장소에서 많은 문서를 샘플링한다.
   2. 스키마 추론: 샘플에서 필드와 자료 형태를 도출한다.
   3. 스키마리스 데이터베이스 적용: 데이터베이스가 완전한 스키마리스가 아니어도 런타임에 스키마를 동적으로 발견한다.

2. 열거형(enum) 추론

   1. 난점: 가능한 값의 집합을 찾아 enum으로 표현하는 과정은 자동 스키마 발견에서 까다로운 부분이다.
   2. LLM 사용의 위치: LLM을 만능 망치(Thor hammer)처럼 쓸 수 있고 꽤 좋은 결과를 낼 수 있다.
   3. 절차적 방법의 장점: 이 작업은 상당히 결정적이므로 전통적인 절차적 방법만으로도 매우 멀리 갈 수 있다.
   4. 원칙: 비결정적으로 보인다고 해서 항상 LLM에 맡기지 말고, 결정적으로 처리할 수 있는 부분은 일반 코드로 구현한다.

3. GitHub 컬렉션의 결과

   1. 대상 데이터: 데모의 GitHub 컬렉션은 PR 문서로 구성됐다.
   2. 생성 결과: 발견된 스키마와 함께 쿼리 성능을 높일 인덱스도 도출됐다.

4.3. 다중 시스템의 사용자 식별자 해석

1. Identity Resolution의 필요성

   1. 동일 인물의 다른 이름: GitHub의 계정명과 다른 시스템의 사용자명이 다를 수 있다.
   2. 질문 해석: “Rasheen의 열린 PR”처럼 이름으로 질문하려면 시스템별 식별자를 하나의 실제 인물로 연결해야 한다.

2. 단계적 매핑 방식

   1. 퍼지 매칭(fuzzy matching): 이름과 사용자명을 절차적으로 비교해 후보를 좁힌다.
   2. LLM의 제한적 사용: 후보가 여러 개일 때 이름 목록을 LLM에 넘겨 최종 타이브레이커(tiebreaker)로 사용할 수 있다.
   3. 구현 원칙: Unblocked 내부에서도 이 문제를 주로 단순한 절차적 트릭으로 해결하며 LLM을 모든 단계의 기본 해법으로 사용하지 않는다.

4.4. 쿼리 합성(synthesis)

1. LLM에 전달하는 컨텍스트

   1. 동적으로 발견한 스키마: 필드와 구조를 쿼리 생성의 제약으로 제공한다.
   2. 현재 날짜와 시간: “지난주”, “최근”처럼 시간 상대 표현을 실제 범위로 해석하게 한다.
   3. 질문 사용자 정보: “내 PR”을 특정 사용자인 Peter의 PR로 해석할 수 있게 한다.

2. 합성 결과

   1. 구조화 쿼리 생성: LLM은 자연어 요청을 데이터 저장소에서 실행 가능한 쿼리로 합성한다.
   2. 실행 연결: 엔진은 생성된 쿼리를 실행해 문서를 가져오고, 결과를 다음 검증 단계로 넘긴다.

4.5. 쿼리 검증과 권한 경계

1. 위험한 연산 차단

   1. 함수 연산자(function operator): 데이터베이스 서버에서 원시 JavaScript를 실행할 수 있어 허용하면 위험하다.
   2. 정책 적용: 생성된 쿼리의 연산자를 검사해 실행 가능한 범위를 제한한다.

2. 숨은 필드와 테넌트 격리

   1. 숨은 필드: LLM이 보거나 도출하거나 실행해서는 안 되는 내부 필드가 있을 수 있다.
   2. 테넌트 ID: 메타데이터 필드에 테넌트 ID가 들어 있으면 서로 다른 고객의 데이터가 섞이지 않아야 한다.
   3. 서버 측 주입: LLM이 이 필드에 직접 접근하지 못하도록 뒤에서 조건을 강제하고 필요한 필드는 시스템이 쿼리에 주입한다.

3. 검증 실패의 구체적 예

   1. 질문: “제목에 authentication이 들어간 PR”을 요청한다.
   2. 위험한 생성: LLM이 정규 표현식(regular expression) 기반 조건을 만들 수 있다.
   3. 차단 결과: 검증 엔진이 “정규 표현식은 허용되지 않는다”고 거부하고 쿼리 실행을 막는다.

4.6. 오류 피드백과 자기 수정

1. LLM에 오류를 되돌려 보내기

   1. 검증 오류 활용: 실패를 종료 신호로만 처리하지 않고 오류 내용을 LLM에 다시 전달한다.
   2. 재시도 루프: LLM이 허용되지 않은 연산을 제거하고 다른 쿼리를 다시 만들도록 한다.
   3. 상한 설정: 무한 루프를 막기 위해 최대 재시도 횟수를 둔다.

2. 정확성 문제와 전문 검색

   1. 첫 수정의 한계: 정규 표현식이 거부된 뒤 LLM이 match를 사용했지만, 이는 제목 전체와 정확히 일치하는 조건이었다.
   2. 결과 부족: 정확한 제목이 같은 PR은 존재하지 않아 검색 결과가 비어 있었다.
   3. 전문 검색(full-text search): 부분 단어·내용 검색을 위해 전문 검색을 추가했다.
   4. 최종 결과: 재시도와 전문 검색을 거쳐 자연어 질문이 처음부터 끝까지 실행 가능한 결과로 연결됐다.

5. 구조화된 컨텍스트의 에이전트 활용

구조화 쿼리 엔진은 독립적인 데이터베이스 도구에 머물지 않고, 에이전트가 의미 검색과 구조 검색을 함께 쓰는 기반이 된다.

5.1. RAG의 구조적 절반

1. 지원 기능

   1. 필터(filters): 특정 사용자, 상태, 속성에 맞는 자료를 제한한다.
   2. 집계(aggregations): 개수와 비율처럼 여러 문서를 계산한다.
   3. 시간 범위(time-scoped): 지난주, 1월 1일 이후처럼 시간 조건을 반영한다.
   4. 자기 수정(self-correcting): 검증·실행 오류를 다시 LLM에 전달해 쿼리를 고친다.

2. 사람과 에이전트 모두를 위한 인터페이스

   1. 사람의 자연어 질문: 구조화 문법을 직접 작성하지 않아도 된다.
   2. 에이전트의 도구: 에이전트는 생성된 쿼리와 결과를 이용해 조직의 운영 맥락을 추론한다.
   3. 투명한 실행 과정: 채팅 에이전트가 만든 쿼리를 화면에 표시해 어떤 자료를 조회하고 있는지 확인할 수 있다.

5.2. 인증 관련 작업의 지난주 조회

1. 질문: “지난주에 인증(authentication)과 관련해 우리가 작업한 것은 무엇인가?”라고 요청한다.
2. 실행: 채팅 에이전트가 필요한 구조화 쿼리를 여러 개 만들고 실행한다.
3. 추론: 반환된 데이터를 바탕으로 인증 관련 작업의 맥락을 정리한다.
4. 결과: 구조화되고 질의 가능한 컨텍스트가 사람과 에이전트 양쪽에 제공된다.

6. 로컬 Context Engine Simulator

실제 Unblocked를 바로 연결하기 어려운 환경에서도 컨텍스트 엔진의 효과를 검증할 수 있도록 로컬 시뮬레이터를 제공한다.

6.1. 시뮬레이터의 목적

1. 환경 제약 대응

   1. 로컬 실행: Unblocked를 즉시 연결할 수 없는 조직도 프로젝트를 로컬에서 실행할 수 있다.
   2. 오픈소스 접근: 구현을 직접 확인하고 자신의 환경에 맞춰 실험할 수 있다.

2. 작업별 A/B 테스트

   1. 번들 생성: 특정 작업마다 컨텍스트 번들을 생성한다.
   2. 동일 작업 비교: 컨텍스트가 있는 조건과 없는 조건에서 같은 작업을 실행한다.
   3. 효과 측정: 에이전트가 필요한 정보를 손끝에서 바로 얻을 때 생기는 이점을 비교해 보여 준다.

6.2. 실험 적용 순서

1. 기준선 설정: 컨텍스트 엔진이 없는 에이전트의 비용, 시간, 결과를 기록한다.
2. 번들 제공: 코드·문서·PR·대화를 작업 의도에 맞게 연결해 제공한다.
3. 동일 질문 재실행: 동일한 업무를 다시 실행한다.
4. 비교 평가: 비용 절감, 탐색 시간, 근거 연결, 결과의 실행 가능성을 비교한다.

주요 발언 모음

“RAG는 콘텐츠 부분을 훌륭하게 해결한다.”

“쿼리를 생성하는 일은 사실 쉬운 부분이다. 어려운 부분은 그 주변에 놓인 스캐폴딩이다.”

“비결정적으로 보이는 작업을 항상 LLM에 맡기지 마라. 이런 작업은 실제로 상당히 결정적일 수 있다.”

“LLM에서 나온 쿼리는 신뢰할 수 없다.”

“컨텍스트 엔진을 사용했을 때 비용이 50% 줄었다.”

“구조화되고 질의 가능한 컨텍스트는 에이전트와 사람 모두를 위한 것이다.”

핵심 데이터 & 수치

• 발표 시간: 약 20분으로 제한되어 컨텍스트 엔진 개념 설명 후 구현 데모로 빠르게 이동했다.
• Source Mark 최적화 비용: 컨텍스트 엔진 사용 시 약 $1.29.
• Source Mark 최적화 시간: 컨텍스트 엔진 사용 시 약 1분 30초.
• 비교 비용: 컨텍스트 엔진 미사용 시 최대 약 $2.60.
• 비교 시간: 컨텍스트 엔진 미사용 시 약 3분.
• 비용 효과: 약 50% 감소.
• 데이터 영역: GitHub 컬렉션에서 PR 문서를 샘플링해 스키마와 인덱스를 발견했다.
• 재시도 정책: 쿼리 검증·실행 오류를 LLM에 되돌리되 최대 재시도 횟수로 루프를 제한한다.
• 접근 제어: 숨은 필드와 테넌트 ID를 LLM의 직접 접근에서 차단하고 서버 측에서 조건을 주입한다.

결론 및 시사점

1. RAG의 역할을 의미 검색으로 정의한다: 코드, PR, 문서, Slack 대화처럼 관련 콘텐츠를 찾는 문제에는 벡터 검색과 에이전트 루프가 강력하다.
2. 구조 검색을 별도 계층으로 추가한다: 병합 시점, 사용자별 목록, 주간 추이, 집계처럼 관계와 시간을 계산하는 문제는 구조화 쿼리 엔진이 맡아야 한다.
3. LLM보다 주변 시스템이 품질을 결정한다: 스키마 발견, 식별자 해석, 권한 경계, 위험 연산 차단, 오류 재시도가 자연어-쿼리 변환의 신뢰성을 만든다.
4. 결정적인 작업은 절차적으로 구현한다: enum 추론과 계정 매핑처럼 규칙으로 처리할 수 있는 부분까지 LLM에 맡기면 비용과 예측 가능성이 나빠진다.
5. 보안 검증은 생성 이후가 아니라 실행 전 필수 단계다: 원시 JavaScript 실행, 숨은 필드 노출, 테넌트 간 데이터 횡단을 구조적으로 차단해야 한다.
6. 컨텍스트의 양보다 연결성과 적합성이 중요하다: 작업별로 연결된 근거와 후속 탐색 링크를 제공하면 토큰 비용과 조사 시간이 동시에 줄어든다.
7. 로컬 A/B 테스트로 도입 효과를 측정한다: 실제 플랫폼을 바로 연결하기 어려운 조직도 Context Engine Simulator로 비용·시간·결과 품질의 기준선을 비교할 수 있다.

핵심 요약 (20줄)

관계형 컨텍스트 엔진은 의미적으로 관련된 콘텐츠를 찾는 RAG의 강점을 구조화·시간·관계 질의로 확장한다.

조직의 코드는 PR, 리뷰, 이슈, 티켓, 문서, 대화에 흩어져 있어 서로 연결된 근거로 정리해야 업무에 쓸 수 있다.

새 직원이 코드베이스와 문서 시스템을 돌아다니며 조직의 장애 대응 역사를 배우는 과정은 컨텍스트가 없는 AI 에이전트의 상황과 닮았다.

grounded context는 자료를 서로 연결하고 요청 의도에 맞추며 사용자와 권한에 따라 개인화한다.

컨텍스트 엔진이 없는 Claude는 Source Mark 엔진 최적화 계획을 세우기 위해 코드를 탐색하고 이해했다고 자신 있게 추정했다.

컨텍스트 엔진을 연결한 Claude는 소스 코드와 Notion 아키텍처 문서, PR, Slack 대화를 묶은 작업별 번들을 받았다.

Source Mark 사례의 비용은 컨텍스트 엔진 사용 시 약 1.29달러였고 소요 시간은 약 1분 30초였다.

컨텍스트 엔진이 없을 때 비용은 최대 약 2.60달러와 3분으로 늘어 약 50%의 비용 차이가 났다.

코드 리뷰 이슈 수가 감소한 원인은 Opus 4.6에서 Opus 4.8로 바꾼 뒤의 동작 특성 변화로 좁혀졌다.

Unblocked는 원인을 유발한 PR과 관련 Slack 대화를 찾아 수정에 필요한 근거를 담은 PR을 생성했다.

RAG는 코드와 PR을 찾고 변경을 논의한 Slack 스레드를 연결하는 내용 질문에 강하다.

“지난주에 병합한 PR”이나 “1월 1일 이후 주간 비율”처럼 구조와 시간을 묻는 질문은 벡터 저장소만으로 충분하지 않다.

Document Query Engine은 자연어 질문을 필터와 집계를 포함한 구조화 쿼리로 변환한다.

런타임 스키마 발견은 문서 샘플을 분석해 필드와 enum, 쿼리 성능을 위한 인덱스를 도출한다.

enum 추론과 같은 결정적인 작업은 LLM보다 전통적인 절차적 방법으로 처리하는 편이 예측 가능하다.

다중 시스템의 사용자명은 퍼지 매칭으로 연결하고 애매한 후보만 LLM을 타이브레이커로 활용한다.

쿼리 합성에는 스키마, 현재 날짜와 시간, 질문자의 정보가 함께 제공되어 “내 PR” 같은 표현을 해석한다.

검증 엔진은 원시 JavaScript 실행, 정규 표현식, 숨은 필드, 테넌트 경계 침범을 차단한다.

검증 또는 데이터베이스 오류는 최대 재시도 루프로 LLM에 되돌리고 전문 검색으로 정확한 제목 일치의 한계를 보완한다.

Context Engine Simulator는 동일 작업의 컨텍스트 유무를 로컬 A/B 테스트해 에이전트의 비용·시간·근거 연결 효과를 측정하게 한다.