기업의 Context Graph가 필요한 이유와 구축법

URL: https://www.youtube.com/watch?v=cSz7aL2nl2U
날짜: 2026-10-10
채널: aiDotEngineer
원문 제목: Why Your Company Needs a Context Graph (and How to Build It) — Gil Feig, Merge
길이: 911초

📌 핵심 질문 / Context Graph가 필요한 이유

==기업용 AI가 실제로 회사 전체를 추론하려면 MCP 도구 연결만으로는 부족하며, 데이터·업무 프로세스·메모리·스킬을 함께 관리하는 Context Graph가 필요하다.==

• 단일 고객의 티켓을 조회하는 일은 라이브 API로 가능하지만, 여러 기간·여러 고객에 걸친 의미론적 질문은 API를 실시간으로 반복 호출하는 방식으로 처리하기 어렵다.
• 외부 시스템에서 동기화한 데이터와 라이브 조회를 라우터·요약기·스킬·메모리로 조합해야 질문마다 필요한 맥락만 에이전트에 전달할 수 있다.
• 모든 데이터에는 출처·조회 시각·권한·변환 이력·무효화 조건을 붙여야 비즈니스 의사결정에서 AI의 답을 검증하고 사고를 조사할 수 있다.

Context Graph는 그래프 데이터베이스의 노드와 엣지만을 뜻하지 않는다. 회사가 가진 외부 시스템의 데이터, 구조화된 내부 맥락, 에이전트가 축적한 메모리, 회사의 업무 규칙을 실행하는 스킬을 한데 묶어 회사의 두뇌처럼 작동시키는 컨텍스트 계층이다. 라이브 조회가 적합한 단순 요청과 로컬에 동기화해야 하는 깊은 분석을 분리하고, 필요한 정보만 신선도와 출처를 확인해 조합하는 것이 핵심이다.

1. 발표의 범위와 Context Graph의 정의

기술 제품을 고르는 방법보다 회사의 맥락을 어떤 구조로 모으고 선택할지에 초점을 둔다.

1.1. 발표 범위와 Merge의 배경

1. 다루는 질문

   1. 필요성: 모든 회사가 왜 Context Graph를 가져야 하는지부터 설명한다.
   2. 구성 요소: 어떤 종류의 데이터와 회사 로직을 그래프에 넣어야 하는지, 그리고 각 요소가 어떻게 결합되는지 살핀다.

2. 운영 전략

   1. 컨텍스트 선택: 어떤 순간에 어떤 에이전트와 콘텐츠가 가장 관련 있는지 고르는 방법을 다룬다.
   2. 추적성(provenance): 데이터가 어디서 왔고, 누가 언제 어떤 권한으로 요청했으며, 아직 신선한지 확인하는 방법을 다룬다.

3. Merge의 위치

   1. 회사 소개: Merge는 기업이 프로덕션 AI를 쉽게 구축하도록 돕는 연결 인프라 회사이며, 400곳이 넘는 엔터프라이즈 고객이 내부 및 고객 대면 AI에 사용한다.
   2. 고객과 제품: OpenAI, Ramp, Netflix, Perplexity 등이 고객으로 언급되며, Unified·Agent Handler·Gateway 세 제품이 관련 구성 요소를 맡는다.
   3. 규모와 출발: Gil Feig와 공동 창업자 Shen Shi가 6년 전에 회사를 세웠고, 세 차례 투자를 유치했으며, 세 도시에서 130명이 일하고 있다.

4. 현장 맥락

   1. well connected 모자: 팀이 참석자에게 “well connected”라고 적힌 모자를 나눠주며 연결성이라는 주제를 가볍게 강조한다.
   2. 마무리 방식: 발표 뒤 질문이 있으면 남아서 답하겠다고 안내한다.

1.2. 회사의 두뇌로서의 Context Graph

1. 그래프의 의미

   1. 추상화 수준: 진짜 그래프 인프라의 노드와 엣지를 구현하는 법이 아니라, 회사 전체를 이해하는 “회사 두뇌(company brain)”를 만든다는 관점이다.
   2. 기술 선택의 유보: 특정 기술을 사용하라고 지시하지 않는다. 이를 뒷받침할 좋은 기술이 많고, 구체적인 선택은 에이전트의 도움을 받아도 된다.

2. 외부·구조화 데이터

   1. 서드파티 데이터: NetSuite, Jira처럼 회사가 사용하는 다른 시스템의 데이터가 들어온다.
   2. 구조화된 컨텍스트: 서드파티에서 가져온 데이터와 회사가 컨텍스트 계층에 직접 넣은 데이터가 포함된다.
   3. 고정 문서: 에이전트가 항상 전달받아야 하는 정적 문서도 구조화된 컨텍스트의 일부가 된다.

3. 변화하는 회사 지식

   1. 메모리(memory): 사용자가 기억하라고 한 정보와 에이전트가 스스로 기억할 가치가 있다고 판단한 정보처럼 사용 과정에서 형성되는 지식이다.
   2. 스킬(skill): “고객이 행복한지 어떻게 판단하는가”, “불만이 접수되면 어느 시스템으로 보내는가”처럼 회사의 원칙·프로세스를 실행 가능한 형태로 표현한 것이다.

2. MCP 라이브 조회만으로는 부족한 이유

단일 조회와 대규모 의미론적 분석은 서로 다른 접근 패턴을 요구하므로, MCP 연결 위에 동기화 계층을 추가해야 한다.

2.1. 단일 고객 질문의 한계

1. 질문과 즉시 조회

   1. 질문: 직원이나 고객이 “지난주 고객 A가 왜 화가 났나요?”라고 묻는다.
   2. Zendesk 조회: 에이전트가 Zendesk 티켓 시스템에 접근해 지난주 고객 A가 제출한 티켓을 찾는다.
   3. 답의 재료: API 동기화가 고장 난 구체적인 내용과 고객이 총 세 건의 티켓을 제출했다는 사실을 얻으면 단일 질문에는 답할 수 있다.

2. 범위가 넓어질 때의 변화

   1. 여러 고객: “지난주에 어떤 고객들이 화가 났나요?”라고 물으면 지난주 모든 Zendesk 티켓을 읽어야 한다.
   2. 긴 기간: “지난 1년 동안 어떤 고객들이 화가 났나요?”라는 질문에는 수천 건의 티켓을 100개 단위로 계속 가져와야 하므로 타임아웃이 발생할 수 있다.
   3. 핵심 차이: 고객 A 한 명의 단순 조회와 전체 데이터셋을 가로지르는 의미론적 질문은 같은 API 호출 방식으로 처리되지 않는다.

2.2. 플랫폼 API의 접근 패턴과 동기화 계층

1. MCP가 해결하지 못하는 부분

   1. 라이브 조회의 전제: MCP는 외부 플랫폼의 API가 필요한 정보를 지금 바로 조회할 수 있을 때 강력하다.
   2. 의미론적 질의의 부재: Jira나 티켓 시스템이 “지난주에 화가 난 고객은 누구인가?”라는 자연어 질문을 직접 받아 결과를 돌려주는 엔드포인트를 보통 제공하지 않는다.
   3. 플랫폼의 유인 부족: 플랫폼이 모든 데이터를 벡터화하려면 비용이 들고, 사용자가 자체 플랫폼을 덜 방문하게 되므로 이런 의미론적 API를 제공할 유인이 적다.

2. 로컬 사본의 필요성

   1. 동기화(sync) 계층: 깊이 있는 의미론적 질문을 위해 외부 데이터의 사본을 로컬로 동기화해야 한다.
   2. 검색 구조: 로컬 벡터 데이터베이스(vector database)에 데이터를 넣어 넓은 데이터셋을 의미론적으로 검색한다.
   3. 구축 고려사항: AI가 벡터 DB를 비교적 쉽게 만들 수 있지만, 데이터를 어떻게 저장하고 어떤 방식으로 검색할지는 회사가 전략을 세워야 한다.

2.3. 라이브 조회와 캐시 조회의 경계

1. 라이브 MCP가 맞는 요청

   1. Stripe 예시: 특정 고객에 대해 Stripe에 항상 같은 질문을 하거나 한 번의 조치를 수행하는 정적 조회는 라이브 MCP로 처리할 수 있다.
   2. 장점: 라이브 API는 구축과 확장이 쉽고, 동기화 컨텍스트보다 실행 비용이 낮다.

2. 동기화가 필요한 요청

   1. 의미론적 조회: 단순 조회를 넘어 넓은 데이터셋을 분석해야 하는 질문이라면 로컬 사본이 필요하다.
   2. 비용과 복잡성: 벡터 DB 운영과 지속적인 데이터 동기화 때문에 구축과 실행이 더 복잡하고 비싸다.
   3. 신선도 문제: 외부 데이터의 변화를 따라가야 하므로 최신 상태를 유지하기가 더 어렵다.

3. Context Graph의 실행 구조

라이브·동기화 데이터가 모두 있어도 그대로 에이전트에 쏟아부을 수 없으므로, 라우팅과 요약, 회사 스킬과 메모리를 함께 둔다.

3.1. 라우터와 요약기

1. 라우터(router)

   1. 초기 분배: 프롬프트가 들어오면 어느 에이전트가 담당해야 하는지와 어느 데이터 경로로 보내야 하는지를 결정한다.
   2. 질문별 경로: 모든 질문을 모든 도구로 보내지 않고, 요구되는 회사 스킬·메모리·데이터 소스에 맞는 곳으로 보낸다.

2. 요약기(summarizer)

   1. 집계: 동기화 컨텍스트와 라이브 컨텍스트에서 모인 데이터를 한데 받는다.
   2. 압축: 대량의 검색 결과를 에이전트가 처리할 수 있는 답변 맥락으로 요약한다.
   3. 반환: 처음 프롬프트를 보낸 에이전트에 필요한 요약을 넘겨 응답을 생성하게 한다.

3.2. 스킬과 메모리가 데이터 선택을 지배하는 방식

1. 스킬이 필요한 이유

   1. 회사별 정의: “고객이 화가 났다”는 표현은 회사마다 다르게 정의된다. 어떤 회사는 열린 티켓 수를 기준으로 삼을 수 있지만, 티켓 내용이 긍정적일 수도 있다.
   2. 회사 고유 프로세스: 티켓 시스템을 쓰지 않고 고객 만족도를 위해 항상 Qualtrics 설문 데이터를 먼저 확인하는 회사도 있다.
   3. 실행 순서: 에이전트는 데이터를 조회하기 전에 관련 스킬을 확인해 회사가 만족도를 판정하는 방식과 우선 시스템을 알아야 한다.

2. 전체 흐름

   1. 질문 라우팅: 프롬프트가 적절한 에이전트로 전달된다.
   2. 규칙 확인: 에이전트가 현재 질문이나 작업과 연관된 메모리·스킬이 있는지 확인한다.
   3. 데이터 선택: 스킬이 정한 의미에 따라 동기화 캐시 DB와 라이브 MCP 조회 중 필요한 곳을 선택한다.
   4. 조합과 반환: 필요한 정보를 요약하고 응답으로 반환하며, 새로 발견한 중요한 사실은 메모리로 저장할 수 있다.

3. 현실적인 성격

   1. 마법이 아님: 특별한 마법이 아니라, 회사의 사용 사례 안에서 필요한 계산과 데이터 흐름을 정확히 설계하는 문제다.
   2. 티켓 집계 예시: 모든 고객을 모아 티켓 수를 세고 티켓 내용을 요약한 다음 각 고객의 상태를 판단하는 일은 라이브 조회만으로는 어려웠지만, 로컬 조회를 섞으면 간단해진다.

4. 네 가지 컨텍스트 계층

프롬프트·스킬·메모리도 에이전트에 전달되는 정보이므로 컨텍스트 계층에 포함하고, 외부 데이터의 전달 방식에 따라 네 가지 층으로 나눈다.

4.1. 프롬프트·스킬·메모리

1. 역할

   1. 질문 해석: 사용자 요청이 회사 안에서 무엇을 의미하는지 정한다.
   2. 탐색 지시: 어떤 데이터 소스를 어떤 순서로 확인해야 하는지 결정한다.
   3. 지속 지식: 이전 상호작용에서 저장한 사실이나 사용자가 명시적으로 기억시킨 내용을 제공한다.

2. 컨텍스트의 범위

   1. 넓은 정의: 컨텍스트를 단순한 텍스트 조각으로만 보지 않고, 에이전트에 전달되는 모든 정보로 본다.
   2. 기업 로직 포함: 회사의 정책과 프로세스가 스킬 형태로 들어가므로 도구 목록만으로는 표현할 수 없는 판단 기준이 포함된다.

4.2. 라이브 API 컨텍스트

1. 적합한 사용처

   1. 단순 검색: 특정 고객이나 특정 객체에 대한 한 번의 조회에 사용한다.
   2. 단일 실행: Stripe에서 특정 고객에 대해 한 가지 조치를 수행하는 것처럼 범위가 좁은 작업에 사용한다.

2. 운영상 특성

   1. 낮은 진입 비용: 동기화 계층보다 만들고 추가하기 쉽다.
   2. 낮은 실행 비용: 벡터 DB와 지속적 동기화가 필요 없으므로 일반적으로 더 저렴하다.
   3. 한계: 긴 기간이나 대규모 데이터셋을 가로질러 분석하면 호출 수가 늘고 타임아웃 위험이 커진다.

4.3. 캐시·동기화 컨텍스트

1. 적합한 사용처

   1. 복잡한 조회: 단순 검색이 아니라 여러 레코드 사이의 의미와 패턴을 찾아야 할 때 사용한다.
   2. 깊은 질문: 고객별 감정·상태처럼 방대한 데이터를 종합해야 하는 질문을 로컬 검색으로 처리한다.

2. 구축 방식

   1. 외부 사본: 제3자 플랫폼의 데이터를 로컬 저장소로 계속 동기화한다.
   2. 벡터 검색: 벡터 DB를 사용해 자연어 질문과 의미적으로 가까운 데이터를 찾는다.
   3. 구조 설계: 저장 단위와 검색 방식이 질의 품질을 좌우하므로 회사 데이터에 맞는 검색 전략이 필요하다.

3. 운영 부담

   1. 비용: 벡터 DB를 운영하고 동기화 파이프라인을 계속 실행해야 하므로 라이브 API보다 비싸다.
   2. 신선도: 동기화 지연으로 낡은 데이터가 들어갈 수 있어 SLA 안에 있는지 확인해야 한다.

4.4. 파생 컨텍스트(derived context)

1. 의미

   1. 새로 만든 맥락: 제3자 데이터를 가져올 때 추가로 생성해 저장하는 요약·분류·상태 같은 정보다.
   2. 재사용: 같은 질문이 반복될 때 원본을 다시 조회하고 다시 요약하지 않도록 한다.

2. 고객 티켓 예시

   1. 생성: 고객의 전체 티켓 세트를 라이브로 가져오는 순간 그 세트를 요약한다.
   2. 저장: 원본에서 추출한 요약을 구조화된 저장 컨텍스트에 기록한다.
   3. 효과: 다음에 유사한 질문이 들어오면 저장된 요약을 바로 활용해 조회와 요약 비용을 줄인다.

5. 질문이 들어왔을 때의 컨텍스트 선택 흐름

컨텍스트 선택은 스킬·메모리 일치 여부와 데이터 신선도를 순서대로 확인하고, 부족한 경우에만 라이브 조회로 내려가는 반복 과정이다.

5.1. 스킬·메모리 일치 확인

1. 일치하는 경우

   1. 스킬 실행: 질문에 맞는 스킬이나 메모리를 찾아 실행한다.
   2. 외부 데이터 불필요: 스킬 자체만으로 답할 수 있으면 추가 조회 없이 응답을 생성한다.
   3. 외부 데이터 필요: 데이터가 필요하면 다음 단계의 캐시 및 라이브 데이터 선택으로 이동한다.

2. 일치하지 않는 경우

   1. 직접 데이터 선택: 스킬·메모리 매치가 없더라도 캐시를 먼저 확인한다.
   2. 기본 경로: 캐시의 신선도를 확인한 뒤 사용할 수 없을 때 라이브 API를 호출한다.

5.2. 신선도와 SLA 확인

1. 캐시 확인

   1. 존재 여부: 필요한 정보가 동기화 저장소에 있는지 확인한다.
   2. 신선도: 데이터가 회사의 SLA 안에 있어 사용 가능한 최신 상태인지 판단한다.

2. 결정

   1. 신선함: SLA 안이면 캐시 컨텍스트를 사용한다.
   2. 낡았거나 없음: SLA를 벗어났거나 데이터가 없으면 라이브 API로 내려간다.
   3. 반복: 충분한 컨텍스트가 모일 때까지 필요한 소스를 몇 차례 순환하며 추가한다.

5.3. 응답 생성과 메모리 저장

1. 충분한 컨텍스트

   1. 발견 내용 기록: 이번 질의에서 새로 알아낸 중요한 사실이나 판단을 메모리에 저장할 수 있다.
   2. 응답: 모인 컨텍스트로 답을 생성해 클라이언트에 돌려준다.

2. 부족한 컨텍스트

   1. 추가 호출: 필요한 정보가 더 없으면 라이브 API를 호출한다.
   2. 최종 반환: 추가 결과를 합친 뒤 요약하고 클라이언트에 응답한다.

6. 추적성(Traceability)과 출처(Provenance)

데이터의 출처를 버리지 않는 것은 선택 기능이 아니라, 오래된 정보로 잘못된 비즈니스 결정을 내리지 않기 위한 기본 조건이다.

6.1. 반드시 보존할 출처 정보

1. 원천과 시각

   1. 원천 시스템: 데이터가 어떤 시스템에서 왔는지 기록한다. MCP 라이브 호출에서도 확인할 수 있고, 벡터 DB에 동기화한 데이터에도 메타데이터로 저장해야 한다.
   2. 조회 시각: 언제 가져왔는지 기록해 동기화 시점과 최신성을 판단한다.
   3. 식별자와 범위: 어떤 ID와 어떤 스코프(scope)에 해당하는 데이터인지 남긴다.

2. 접근과 변환

   1. 접근 주체: 누가 데이터에 접근했는지 기록한다.
   2. 권한: 어떤 권한으로 접근했는지 기록해 결과의 범위와 보안성을 확인한다.
   3. 변환 이력: 원본이 어떻게 생겼고 어떤 변환을 거쳐 현재 값이 되었는지 보존한다.

3. 무효화 조건

   1. 시간 기반 만료: 예를 들어 한 달이 넘은 데이터는 어떤 경우에도 유효한 것으로 간주하지 않는 정책을 둘 수 있다.
   2. 업무 기반 조건: 원천 데이터가 변경됐거나 권한·스코프가 바뀌면 저장된 컨텍스트를 무효화해야 한다.

6.2. 왜 출처가 비즈니스 AI에 더 중요한가

1. 검증 가능한 답

   1. 출처 링크: ChatGPT가 사실 뒤에 세 개의 출처를 붙이는 것처럼, AI 답변도 근거로 돌아갈 수 있어야 한다.
   2. 중요도 증가: 사업상 중요한 결정을 내릴수록 답이 어디서 왔는지 확인하는 일이 더 중요해진다.

2. 오류 조사

   1. 오래된 데이터 위험: 1년 전에 동기화한 데이터를 최신 사실로 착각하면 잘못된 결정을 낼 수 있다.
   2. 사후 분석: 내부 플랫폼에 출처를 보여주지 않더라도, 문제가 생겼을 때 어떤 데이터·권한·변환이 원인이었는지 조사할 수 있어야 한다.
   3. 운영 현실: 오류는 반드시 발생하므로, 출처 기록은 장애와 오판을 분석하기 위한 안전장치다.

7. 종합 예시: Acme 고객 상태 업데이트

“고객 Acme의 상태를 한 문단으로 업데이트하고, 갱신 위험과 최근 지원 상호작용을 포함해 달라”는 요청을 처리한다.

7.1. 데이터 선택 순서

1. 계정 요약

   1. 캐시 우선: 먼저 계정 요약(account summary)을 캐시에서 찾는다.
   2. 스킬 가정: 이 예시에는 별도의 스킬이 없다고 가정한다.
   3. 라이브 전환: 캐시가 없거나 SLA 안에서 최신이 아니면 CRM에 라이브 API 조회를 한다.

2. 최근 지원 상호작용

   1. 티켓 시스템 조회: 티켓 시스템에서 최근 지원 상호작용을 찾는다.
   2. 신선도에 따른 분기: SLA 안에 있는 캐시가 있으면 사용하고, 그렇지 않으면 라이브 조회로 전환한다.
   3. 범위 제한: 전체 티켓 이력을 가져오지 않고 최근 티켓 다섯 건만 가져온다.

7.2. 요약과 재사용

1. 파생 요약 생성

   1. 결합: CRM 계정 정보와 최근 지원 티켓을 합친다.
   2. 요약: 갱신 위험과 최근 상호작용을 포함한 한 문단 상태를 만든다.

2. 저장과 반환

   1. 저장: 만들어진 파생 요약을 이후 질문에서 쓸 수 있도록 저장할 수 있다.
   2. 반환: 최종 요약을 요청한 클라이언트에 전달한다.
   3. 타임아웃 회피: 라이브 조회에서 전체 이력을 가져오지 않는 이유는 호출 지연과 타임아웃 위험을 통제하기 위해서다.

8. 핵심 원칙과 실무적 시사점

8.1. 도구 목록을 회사의 지식으로 착각하지 않기

1. 도구는 컨텍스트가 아님

   1. 도구의 역할: 도구와 액션은 시스템에 접근하고 작업을 실행하는 수단이다.
   2. 컨텍스트의 범위: 회사 전체를 추론하려면 데이터, 동기화 데이터, 업무 프로세스, 스킬, 메모리까지 필요하다.

2. 업무 규칙의 명시화

   1. 문서화된 프로세스: 고객이 불만을 제기했을 때 무엇을 해야 하고 어디로 라우팅해야 하는지 기록한다.
   2. 스킬로 구현: 이 규칙을 회사의 스킬로 만들면 에이전트가 매번 임의로 판단하지 않고 정해진 방식으로 행동한다.

8.2. 더 많은 데이터보다 더 나은 데이터

1. 선택 원칙

   1. 신선도: 최신 데이터만 사용하고 SLA를 벗어난 데이터는 다시 조회한다.
   2. 품질: 신뢰할 수 있고 질문에 관련된 데이터만 선택한다.
   3. 최소 충분성: 필요한 것만 가져와 에이전트의 컨텍스트를 과도하게 채우지 않는다.

2. 동기화 데이터의 구조화

   1. 검색 가능성: 동기화해야 한다면 데이터를 올바른 단위와 형식으로 구조화한다.
   2. 접근 패턴: 어떤 질문에 어떤 방식으로 접근할지에 맞춰 저장·검색 전략을 설계한다.

8.3. 모든 답을 추적 가능하게 만들기

1. 근거 확인: 데이터 출처와 변환 이력이 없으면 AI가 왜 그런 답을 냈는지 알 수 없다.
2. 위험 관리: 잘못된 결정이 발생했을 때 원인을 추적할 수 있도록 모든 답에 사용된 컨텍스트를 연결한다.

주요 발언 모음

“Context Graph는 도구가 아니라 회사의 두뇌다.”

“의미론적 조회나 방대한 데이터셋을 가로지르는 분석이 필요하다면 데이터 사본을 실제로 동기화해야 한다.”

“도구는 컨텍스트가 아니다. Context Graph는 회사 전체를 추론하도록 도와준다.”

“더 많은 데이터가 항상 더 나은 것은 아니다. 신선하고 품질이 높은 데이터를 필요한 만큼만 가져와야 한다.”

“모든 답은 추적 가능해야 한다. AI가 나쁜 결정을 내렸는데 왜 그랬는지 전혀 모르는 상황에 놓이고 싶지는 않을 것이다.”

핵심 데이터 & 수치

• Merge 고객: 400곳이 넘는 엔터프라이즈 고객이 내부 및 고객 대면 AI 용도로 사용한다.
• Merge 인력과 역사: 설립 6년, 공동 창업자 2명, 투자 유치 3회, 직원 130명이다.
• Merge 제품: Unified는 고객 플랫폼의 데이터를 동기화하고, Agent Handler는 수백 개 도구와 사전 구축된 라이브 MCP 연결·거버넌스·ID·출처 기능을 제공하며, Gateway는 LLM 라우터다.
• 티켓 예시: 고객 A는 지난주 티켓을 총 3건 제출했고, Acme 상태 예시에서는 최근 지원 티켓 5건만 조회한다.
• 만료 예시: 한 달이 넘은 데이터는 유효한 것으로 취급하지 않는 무효화 정책을 둘 수 있다.
• 영상 길이: 911초(약 15분 11초)이다.

결론 및 시사점

1. 아키텍처를 분리한다: 단일 객체 조회와 대규모 의미론적 분석을 분리해, 전자는 라이브 MCP로 후자는 로컬 동기화·벡터 검색으로 처리한다.
2. 회사 로직을 데이터와 함께 둔다: 고객 만족도 정의, 라우팅 규칙, 지원 프로세스처럼 회사만의 판단 기준을 스킬로 만들고 메모리와 연결한다.
3. 라우팅·요약을 둔다: 모든 검색 결과를 에이전트에 넘기지 말고 질문을 적절한 경로로 라우팅한 뒤 필요한 컨텍스트만 요약한다.
4. 신선도를 의사결정에 포함한다: 캐시 데이터마다 SLA를 두고, 낡았거나 누락된 경우 라이브 API를 호출하는 폴백 경로를 구현한다.
5. 파생 컨텍스트를 재사용한다: 반복되는 계정·티켓 요약을 저장해 같은 원본을 매번 다시 조회하고 요약하는 비용을 줄인다.
6. 출처를 처음부터 저장한다: 원천, 조회 시각, ID와 스코프, 접근 주체와 권한, 변환 이력, 무효화 조건을 메타데이터로 보존한다.
7. 최소 충분한 데이터만 제공한다: 컨텍스트의 양보다 질문과의 관련성·품질·신선도가 중요하며, 불필요한 전체 이력은 타임아웃과 오판을 키운다.
8. Context Graph의 기준을 확장한다: 회사의 AI 계층은 도구 모음이 아니라 데이터·프로세스·스킬·메모리·액션이 함께 작동하는 운영 두뇌여야 한다.