RAG를 넘어 토큰 사용을 줄이는 관계형 컨텍스트 엔진

URL: https://www.youtube.com/watch?v=ORVh4GivEU0 날짜: 2026-10-10 채널: AI Engineer (aiDotEngineer) 발표자: Peter, Unblocked

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==벡터 검색만으로는 표현하기 어려운 조직의 구조적·시간적 질문까지 처리하려면, 흩어진 지식을 관계형으로 연결하고 안전한 자연어-구조화 쿼리 계층을 갖춰야 한다.==

• 기존 RAG는 코드·문서·대화처럼 의미적으로 검색할 수 있는 콘텐츠를 잘 찾지만, “지난주 내가 병합한 PR”, “누가 결제 영역을 가장 많이 리뷰했는가”처럼 필터·집계·시간 범위가 있는 질문을 벡터 저장소만으로 해결하지 못한다.
• 컨텍스트 엔진은 코드뿐 아니라 Notion 아키텍처 문서, PR, 리뷰, 이슈·티켓, Slack 대화와 조직의 사고 대응 이력을 서로 연결해 의도에 맞고 개인화되며 권한을 인식하는 grounded context를 만든다.
• 자연어를 데이터베이스 쿼리로 바꾸는 일 자체보다 동적 스키마 발견, 사용자 신원 매핑, 위험 연산 검증, 테넌트 격리, 실행 오류 자기수정이 더 어려운 핵심 인프라다.

새 직원이 조직에 합류하면 코드·문서·사고 이력을 돌아다니며 업무에 필요한 맥락을 직접 모아야 한다. 컨텍스트 엔진은 이 역할을 자동화해 에이전트에게 작업별로 촘촘하게 연결된 맥락 묶음을 제공하고, 구조화된 데이터에는 자연어 쿼리 엔진을 붙여 검색과 추론의 범위를 넓힌다.

1. 컨텍스트 엔진이 필요한 이유

1.1. 사람이 맡던 컨텍스트 계층

1. 새 직원의 온보딩 비용

   1. AI 에이전트가 없던 시절에는 사람이 조직의 컨텍스트 계층이었다. 새 직원은 코드베이스를 훑고 여러 문서 시스템을 뒤지며 업무에 필요한 정보를 찾아야 했다.
   2. 문서에 명시되지 않은 공유 역사도 별도로 복원해야 했다. 장애 대응 과정에서 쌓인 결정, 반복되는 사고의 교훈, 조직이 겪은 “전투의 상흔(battle scars)”이 중요한 맥락이 된다.

2. 흩어진 컨텍스트의 문제

   1. 조직의 지식은 코드 한 곳에 있지 않고 PR, 코드 리뷰와 댓글, 이슈와 티켓, 문서, 대화에 분산돼 있다.
   2. 각 자료는 서로 독립된 텍스트가 아니라 같은 설계·변경·장애·결정에 연결된 기록이므로, 단순히 비슷한 문서를 검색하는 것만으로는 전체 관계를 복원하기 어렵다.

1.2. 산재한 맥락을 grounded context로 바꾸기

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

   1. 여러 시스템에 흩어진 컨텍스트가 엔진으로 들어간다.
   2. 엔진은 서로 연결된(related/interrelated) grounded context를 출력한다.
   3. 출력 묶음은 질문의 의도에 특화(intent-specific)되고, 요청자의 업무와 정체성에 맞게 개인화(personalized)되며, 접근 권한을 인식(permission-aware)해야 한다.

2. 에이전트에게 주는 가치

   1. 에이전트는 조직의 신입 직원처럼 아무것도 모르는 상태에서 코드와 문서를 처음부터 뒤지는 대신, 작업에 직접 연결된 맥락을 받는다.
   2. 맥락 묶음 안의 링크는 추가 정보가 필요할 때 코드, 아키텍처 문서, PR, Slack 스레드로 바로 이동할 수 있는 jump-off point가 된다.

2. 컨텍스트 엔진의 실제 효과

2.1. Source Mark Engine 최적화 계획 비교

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

   1. Peter는 Claude에게 조직의 레이어에 있는 “source mark engine” 구성요소를 최적화할 계획을 세워 달라고 요청했다.
   2. 새 작업을 받은 Claude는 새 직원처럼 코드베이스나 조직의 설계를 알지 못한다. 먼저 코드 전체를 돌아다니며 무슨 일이 벌어지는지 추론한 뒤, 충분한 근거를 모으기 전에 자신 있게 이해했다고 가정하고 권고안을 낸다.

2. Unblocked 컨텍스트 엔진을 붙인 Claude

   1. Claude는 백엔드의 Unblocked context engine을 호출하고, 해당 최적화 작업에 맞춘 포괄적인 context bundle을 받는다.
   2. 묶음에는 소스 코드뿐 아니라 아키텍처를 설명하는 Notion 문서, 해당 컴포넌트 최적화를 논의한 PR, 관련 Slack 대화가 함께 들어간다.
   3. 여러 기록이 링크로 촘촘히 묶이므로 Claude가 추가 확인을 위해 원문을 다시 가져갈 때 정확한 출발점을 얻는다.

3. 비용과 시간 차이

   1. 컨텍스트 엔진을 붙인 세션은 약 1달러 29센트와 1분 30초가 들었다.
   2. 컨텍스트 엔진이 없는 세션은 최대 약 2달러 60센트와 3분이 걸렸다.
   3. 작업별로 미리 연결된 맥락을 제공하면 비용을 약 50% 줄일 수 있고, 탐색에 쓰는 시간도 절반 수준으로 줄어든다.

2.2. 코드 리뷰 이슈 감소 원인 추적

1. 문제 발견과 원인 축소

   1. 동료 Richie는 Unblocked의 코드 리뷰 제품을 담당한다. 코드 리뷰 제품이 표면화하는 이슈의 수가 감소하자 Unblocked에 상황을 물었다.
   2. Unblocked는 관련 기록을 빠르게 모아 가능한 원인을 좁혔다. 모델을 Opus 4.6/4.8 계열로 전환한 뒤 내부 행동 특성이 바뀌었고, 그 결과 탐지되는 이슈가 줄었을 가능성이 핵심 후보로 드러났다. 자막에는 모델 버전명이 “Opus 48 또는 Opus 46에서 Opus 48”처럼 불분명하게 인식돼 있다.

2. 맥락을 가진 자동 수정 PR

   1. Richie가 수정을 요청하자 Unblocked는 백그라운드에서 PR을 만들었다.
   2. 생성된 PR 설명은 처음 회귀를 일으킨 PR을 이해하고, 그 회귀를 논의한 Slack 대화를 찾아 관련 데이터를 끌어와 수정 근거에 반영했다.
   3. 원인 PR과 토론 스레드와 측정 데이터가 하나의 작업 맥락으로 연결됐기 때문에, 단순 코드 생성보다 설명 가능한 수정 제안이 나왔다.

3. 시연 중 드러난 운영 현실

   1. Peter는 프레젠테이션으로 돌아가려다 화면을 잃었고, 잠시 다른 키노트 파일을 띄워 청중의 웃음을 자아냈다.
   2. 시간이 부족해 컨텍스트 엔진의 가치 요약을 마친 뒤 곧바로 오픈소스 구현 단계로 넘어갔다. 짧은 발표 시간 안에 제품 효과와 핵심 구성요소를 모두 보여주려는 speedrun 형식이었다.

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

3.1. 의미적 검색이 담당하는 절반

1. RAG가 연결할 수 있는 콘텐츠

   1. RAG는 PR, 리뷰, 댓글, 이슈·티켓, 문서, 대화처럼 의미적으로 검색 가능한 내용을 다룬다.
   2. “이 코드를 찾아라”, “이 코드를 바꾼 PR은 무엇인가”, “그 변경을 논의한 Slack 스레드는 어디인가”와 같은 콘텐츠 질문에 적합하다.
   3. 에이전트 루프에 파일 검색 도구와 추가 탐색 도구를 주면 관련 기록을 단계적으로 따라가며 매우 강력한 결과를 만들 수 있다.

2. 벡터 저장소의 한계

   1. “지난주 내가 병합한 PR”, “누가 payments 영역을 가장 많이 리뷰했는가”, “현재 열린 PR은 무엇인가”는 의미적으로 비슷한 문서를 찾는 질문이 아니라 구조적 질의다.
   2. “1월 1일 이후 주별 ratio 차트를 보여 달라”처럼 시간 범위와 집계가 결합된 값은 벡터 저장소에 관계와 수치가 쿼리 가능한 형태로 인코딩돼 있지 않다.
   3. 따라서 검색(retrieval)은 의미적 retrieval과 구조적 retrieval이라는 두 절반으로 나뉘며, 후자는 별도 query engine이 필요하다.

3.2. 구조적 컨텍스트의 목표

1. 자연어를 구조화 쿼리로 전환하기

   1. 사용자가 “machine이 만든 open PR”처럼 자연어로 질문하면 시스템은 내부 데이터 모델에 맞는 구조화 쿼리를 만들어야 한다.
   2. 결과는 필터, 집계, 시간 범위, 관계 탐색을 지원해야 하며 사람뿐 아니라 채팅 에이전트도 사용할 수 있어야 한다.

2. 생성보다 어려운 주변 인프라

   1. LLM에게 쿼리 생성을 시키는 일은 상대적으로 쉽다.
   2. 실제 난제는 LLM이 올바르고 제한된 쿼리를 생성하도록 스키마·신원·권한·검증·오류복구를 둘러싸는 scaffolding이다.

4. 자연어-구조화 쿼리 엔진의 구성요소

4.1. 동적 스키마 발견

1. 문서 저장소에서 런타임 스키마 추론

   1. 오픈소스 Document Query Engine은 처음부터 스키마를 하드코딩하지 않고 문서 저장소의 여러 문서를 샘플링한다.
   2. 샘플을 바탕으로 필드 구조를 동적으로 도출한다. 모든 데이터베이스가 schema-less인 것은 아니지만, 런타임에 스키마를 발견한다는 원리는 다양한 저장소에 적용할 수 있다.

2. 열거형과 인덱스

   1. 스키마 추론에서 까다로운 부분은 enum처럼 가능한 값의 집합을 추론하는 일이다.
   2. 이런 작업은 겉보기에는 비결정적이라 LLM을 만능 망치(“Thor hammer”)처럼 쓰고 싶어지지만, 실제로는 전통적인 절차적 방법만으로도 상당히 멀리 갈 수 있다.
   3. enum 추론과 같은 작업은 충분히 결정적이므로 매번 LLM에 넘기지 않는 편이 예측 가능성과 안정성에 유리하다.
   4. GitHub 컬렉션의 pull request 문서에서 발견한 스키마에는 쿼리 성능을 높일 인덱스 정보도 포함된다.

4.2. 신원 해석(identity resolution)

1. 서로 다른 시스템의 사람 연결

   1. 사용자가 “Rashene이 만든 open PR”라고 말해도 GitHub에 저장된 이름·사용자명·이메일·식별자는 “Rashene”과 완전히 다를 수 있다.
   2. 질문의 자연어 이름을 GitHub, Slack, 문서 시스템 등 각 시스템의 실제 정체성으로 매핑해야 한다.

2. 절차적 매칭과 LLM 중재

   1. 여러 시스템의 username과 identity를 연결하는 기본 단계는 간단한 절차적 트릭과 fuzzy matching으로 처리할 수 있다.
   2. 후보가 여러 개 남을 때만 이름 목록을 LLM에 전달해 tie-breaker로 사용할 수 있다.
   3. 결정적인 매칭을 먼저 수행하고 애매한 부분에만 LLM을 쓰면 비용과 불확실성을 줄일 수 있다.

4.3. 쿼리 합성(synthesis)

1. LLM에 제공할 재료

   1. 앞 단계에서 동적으로 확인한 스키마를 프롬프트에 넣는다.
   2. 현재 날짜와 시간을 넣어 “지난주”, “1월 1일 이후” 같은 상대적·시간적 표현을 해석하게 한다.
   3. 질문한 사용자의 정보도 넣어 “Peter의 PR”이 아니라 “내 PR”처럼 요청자 기준의 표현을 해석하게 한다.

2. 합성 결과

   1. LLM은 스키마에 맞게 강하게 결합된(tightly bound) 구조화 쿼리를 생성한다.
   2. 자연어 질문을 쿼리로 바꾸는 합성 단계는 전체 파이프라인에서 대략 가장 쉬운 부분이며, 안전성은 다음 검증 계층이 책임진다.

4.4. 쿼리 검증과 테넌트 격리

1. LLM 출력은 신뢰하지 않는다

   1. LLM이 만든 쿼리는 untrusted output이다. 데이터베이스에서 위험한 연산을 실행하거나 의도치 않은 범위를 읽을 가능성이 있다.
   2. MongoDB류의 function 연산자처럼 DB 서버에서 원시 JavaScript를 실행할 수 있는 연산은 차단해야 한다.
   3. 정규 표현식도 비용과 실행 특성 때문에 허용하지 않을 수 있다. 시연에서 “제목에 authentication이 들어간 PR”을 요청했을 때 validation engine은 정규 표현식이 허용되지 않는다고 거부했다.

2. 숨겨진 필드 보호

   1. 모델에게 노출하고 싶지 않은 메타데이터 필드가 있을 수 있다.
   2. 특히 tenant ID가 들어 있는 필드를 모델이 읽거나 조건으로 직접 조작하게 두면 테넌트 경계를 넘을 수 있다.
   3. 모델이 해당 필드를 알거나 상호작용하지 못하게 숨긴 뒤, 시스템이 백그라운드에서 tenant 조건을 주입해 요청자의 테넌트로 쿼리를 제한해야 한다.

3. 검증의 목적

   1. 허용된 연산과 필드만 통과시켜 쿼리가 정확하고 안전한지 확인한다.
   2. 쿼리 문법은 맞더라도 권한 경계를 벗어나거나 정보 노출을 일으킬 수 있으므로 구문 검사만으로는 부족하다.

4.5. 실행 오류와 자기수정

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

   1. 검증 단계에서 쿼리가 거부되거나 데이터베이스 실행 중 오류가 나면 오류 메시지를 다시 LLM에 전달한다.
   2. LLM은 실패 원인을 보고 더 안전하거나 올바른 쿼리로 고친다.

2. 최대 재시도를 둔 단순 루프

   1. 구현 형태는 복잡한 마법이 아니라 제한된 최대 재시도를 가진 loop다.
   2. 시연에서 첫 쿼리는 여러 번의 시도 끝에 통과했지만 match를 사용한 정확한 제목 일치로 좁혀졌다.
   3. 데이터 안에 해당 제목과 완전히 같은 PR이 없었기 때문에 정확한 일치만으로는 결과가 나오지 않았다.
   4. full-text search를 엔진에 추가한 뒤 제목 안의 관련 단어를 더 현실적으로 찾을 수 있었고, 시연은 처음 질문부터 결과까지 완주했다.

5. 오픈소스 Document Query Engine 구축 시연

5.1. 빈 상태에서 시작하기

1. 저장소와 최초 실행

   1. Peter는 함께 구축할 오픈소스 저장소로 Document Query Engine을 열었다.
   2. 처음에는 엔진을 실행하지 않은 채 “Peter가 만든 PR”을 입력하는 실수가 있었고, 저장소를 먼저 실행한 뒤 다시 질문했다.
   3. 초기 상태에서는 배선이 전혀 연결되지 않아 질문을 해도 아무것도 출력하지 않는다. 기능을 한 단계씩 올려가며 동작을 확인하는 방식으로 구축했다.

2. 구축 순서

   1. 자동 스키마 발견으로 데이터 형태와 인덱스를 알아낸다.
   2. 신원 해석으로 자연어 이름과 실제 시스템 계정을 연결한다.
   3. 스키마·날짜·사용자 정보를 LLM에 전달해 쿼리를 합성한다.
   4. 위험 연산과 숨겨진 필드를 검증하고, 실패하면 제한된 재시도로 자기수정한다.
   5. full-text search를 보강해 정확한 제목 일치에 갇히지 않도록 한다.

5.2. 구조화 컨텍스트를 채팅 에이전트에 연결하기

1. 구조화된 질문 실행

   1. 완성된 엔진은 필터와 집계를 지원하고 시간 범위를 이해한다.
   2. 자연어 질문을 내부 쿼리로 바꾼 뒤 실제 문서를 가져오고, 생성된 쿼리를 화면에 보여 주며 실행 과정을 추적할 수 있다.

2. 인간과 에이전트의 공통 인터페이스

   1. “지난주 authentication 관련 작업은 무엇이었나?”와 같은 질문을 채팅 에이전트에 던지면 엔진이 생성한 모든 쿼리와 결과 데이터가 표시된다.
   2. 에이전트는 결과를 받은 뒤 백그라운드에서 이를 추론하고, 구조적 데이터에 근거한 답을 만든다.
   3. 최종 형태는 인간과 에이전트 모두가 사용할 수 있는 “구조적으로 쿼리 가능한 컨텍스트”다.

5.3. 로컬 컨텍스트 엔진 시뮬레이터

1. 도입 장벽을 낮추는 오픈소스 프로젝트

   1. 조직 환경 제약 때문에 Unblocked를 당장 연결하기 어려운 사용자를 위해 별도의 context engine simulator가 제공된다.
   2. 외부 서비스를 연결하지 않고도 전체 과정을 로컬에서 실행할 수 있다.

2. 작업별 A/B 테스트

   1. 시뮬레이터는 작업마다 context bundle을 만든다.
   2. 같은 작업을 컨텍스트 번들이 있는 경우와 없는 경우에 각각 실행하는 A/B 테스트를 수행한다.
   3. 에이전트가 관련 맥락을 손쉽게 사용할 때 비용·시간·결과 품질이 어떻게 달라지는지 직접 비교하게 해 준다.

3. 마무리 안내

   1. 프로젝트 접근을 위한 PR 코드가 설명란에 제공된다.
   2. Peter는 발표 마지막에 부스에 오면 코코넛을 받을 수 있다고 농담하며 발표를 끝냈다.

주요 발언 모음

“At Unblocked, we build a context engine.”

“What you get the scattered context that goes into the context engine and out the other end you get grounded context.”

“It’s intent specific. It’s personalized and it’s permissions aware.”

“RAG nails the content part.”

“Those are queries. They’re not semantic searches.”

“Generating the queries is actually the easy part. The hard part is the scaffolding that sits around it.”

“When you get the query out of the LLM, it’s untrusted.”

“Structured queryable context for agents and humans.”

핵심 데이터 & 수치

• 발표 길이: 약 20분, 실제 메타데이터 기준 1,184초.
• 컨텍스트 엔진 사용 세션: 약 1.29달러, 약 1분 30초.
• 컨텍스트 엔진 미사용 세션: 최대 약 2.60달러, 약 3분.
• 비용 절감: 발표자가 약 50% 감소로 요약.
• 컨텍스트 소스: 소스 코드, Notion 아키텍처 문서, PR, 코드 리뷰·댓글, 이슈·티켓, Slack 대화, 장애 대응의 조직 역사.
• 구조 쿼리 기능: 필터, 집계, 시간 범위, 자연어 변환, 신원 매핑, 검증, 테넌트 제한, 오류 자기수정, full-text search.
• 검색의 두 절반: 의미적 retrieval과 구조적 retrieval.
• 시연 쿼리 예시: “지난주 내가 병합한 PR”, “payments를 가장 많이 리뷰한 사람”, “1월 1일 이후 주별 ratio”, “machine이 만든 open PR”, “제목에 authentication이 있는 PR”, “지난주 authentication 관련 작업”.

결론 및 시사점

1. RAG는 콘텐츠를 의미적으로 찾아 연결하는 강력한 기반이지만 조직의 관계·집계·시간·권한 질문까지 자동으로 해결하지는 않는다.
2. 컨텍스트 엔진은 흩어진 기록을 작업별로 연결해 에이전트의 탐색 비용과 토큰 사용량을 줄이고, 코드와 설계·대화·결정의 관계를 보존한다.
3. 구조화 retrieval의 핵심 경쟁력은 LLM 호출 자체가 아니라 스키마 발견, identity resolution, 사용자 맥락 주입, 허용 연산 검증, tenant 격리, 실행 오류 자기수정에 있다.
4. 결정적인 작업은 절차적 방법으로 처리하고, fuzzy matching의 애매한 후보 선택처럼 필요한 지점에만 LLM을 배치하면 안정성과 비용 효율을 함께 얻는다.
5. LLM이 생성한 쿼리는 항상 신뢰하지 말고 위험 연산·숨겨진 메타데이터·테넌트 경계를 별도 정책 계층에서 통제해야 한다.
6. Document Query Engine과 로컬 simulator는 조직 데이터를 안전하게 연결하기 전에 구조화 쿼리와 컨텍스트 번들의 효과를 실험할 수 있는 출발점이다.
7. 에이전트의 다음 단계는 더 큰 벡터 인덱스가 아니라, 의미적 검색과 관계형·구조적 질의를 함께 처리하는 통합 컨텍스트 계층이다.