AI 에이전트의 '망각' 문제를 해결하는 컨텍스트 계층 설계: RAG, 지식 그래프, 메모리의 실무 아키텍처

AI 에이전트가 "올바른 정보를 가져오지 않는다", "과거의 판단을 잊어버린다", "권한 외의 데이터를 참조한다"와 같은 문제는 모델의 성능이 아니라 컨텍스트 계층 (Context Layer) 설계에 기인합니다.

본 기사에서는 엔터프라이즈용 AI 에이전트에 있어 RAG, 지식 그래프, 엔터프라이즈 메모리(Enterprise Memory)라는 3가지 요소를 어떻게 조합하고, 이를 API 연동, 권한 제어, 감사, 운용으로 어떻게 구현하는지 해설합니다. 경영론이 아닌 시스템 설계, 데이터 기반, 거버넌스의 관점에서 실무적으로 정리합니다.

AI 에이전트가 업무 판단을 수행할 때, 단일 데이터 소스만으로는 불충분합니다. ERP의 트랜잭션, 지식 베이스의 정책, 마스터 데이터의 엔티티 관계, 과거 워크플로우 이력, 사용자의 액세스 권한——이러한 것들을 가공되지 않은 상태 그대로 프롬프트(Prompt)에 채워 넣어도 에이전트는 혼란에 빠집니다.

컨텍스트 계층은 다음과 같은 4가지 기능을 담당합니다.

선택 (Selection): 태스크에 진정으로 관련된 정보만을 추출한다 -
해석 (Interpretation): 유효한 정책과 구버전 초안을 구별하는 등 비즈니스적인 의미를 부여한다 -
권한 (Permissioning): 에이전트가 참조해도 좋은 데이터로만 액세스를 제한한다 -
패키징 (Packaging): 에이전트가 효율적으로 처리할 수 있는 형식으로 정형화한다

이러한 기능이 없으면 에이전트는 "과도한 프롬프트" 또는 "제어 불가능한 검색" 중 하나에 빠지게 됩니다.

컨텍스트 계층은 데이터 기반과 에이전트 실행 계층 사이에 위치하며, 선택·해석·권한·패키징의 4가지 제어 기능을 가진다

RAG (Retrieval-Augmented Generation)는 엔터프라이즈 지식 베이스에서 관련 문서를 검색하여 에이전트의 판단 재료로 제공하는 가장 일반적인 컴포넌트입니다. 하지만 단순히 벡터 DB에 문서를 집어넣는 것만으로는 작동하지 않습니다.

소스 품질: 공식 정책, 구버전 초안, 비공식 메모가 혼재되어 있으면 검색 결과에 노이즈가 섞인다. 코퍼스(Corpus) 자체의 클렌징이 최우선이다. -
청킹 전략 (Chunking Strategy): 비즈니스 문서의 구조(섹션, 조항, 단락)에 따른 분할이 필요하다. 글자 수 기반의 기계적인 청킹은 피해야 한다. -
메타데이터 설계: 유효일, 버전, 지역, 기능, 기밀 수준, 상태, 문서 소유자. 이것들은 임베딩 벡터(Embedding Vector)보다 중요하다. -
검색 전략: 시맨틱 검색 (Semantic Search) + 키워드 필터 + 메타데이터 필터의 조합. 워크플로우 문맥에 따른 쿼리 확장(Query Expansion)도 유효하다. -
리랭킹 (Reranking): 초기 검색 결과를 비즈니스적 중요도에 따라 재정렬한다. 특히 여러 유사 문서에 서로 다른 상태가 있는 경우 필수적이다. -
답변 평가: "그럴듯한 답변"이 아니라, 올바른 문서를 가져왔는지, 유효한 정책을 인용했는지, 혼재를 방지했는지를 평가한다. -

가장 위험한 실수는 기술적으로 뛰어난 RAG를 구축하면서 권한을 무시하는 것입니다. 에이전트는 의미적으로 관련된 문서를 가져올 뿐만 아니라, 해당 문서가 현재 사용자나 워크플로우에서 액세스 가능한지 여부를 검색 시에 체크해야 합니다.

# 권한 인식 RAG의 의사 코드 예시
def permission_aware_retrieve(query, user_id, workflow_context):
# 1. 시맨틱 검색
...

RAG가 "쓰여 있는 내용"을 검색하는 것에 반해, 지식 그래프 (Knowledge Graph)는 "무엇이 무엇과 연결되어 있는가"를 표현합니다. 엔터프라이즈의 업무 판단은 단일 문서나 테이블에서는 도출할 수 없는 복잡한 관계성에 의존합니다.

전사적인 지식 그래프를 한꺼번에 구축하려고 하면 프로젝트는 실패합니다. 대신 우선순위가 높은 유스케이스(Use Case)별로 **도메인 특화 그래프 (Domain-specific Graph)**부터 시작해야 합니다.

조달: 벤더-계약-카테고리-정책의 관계 그래프 -
고객 서비스: 고객-제품-티켓-SLA의 관계 그래프 -
재무 결산: 엔티티-계정-분개-컨트롤의 관계 그래프

// 조달 예외 처리에서의 그래프 쿼리 예시
MATCH (requester:Employee {id: $requester_id})
MATCH (category:Category {name: $category_name})
...

도메인 우선 접근 방식에는 가치 창출 시간 단축, 비즈니스 소유자에 의한 검증 용이성, 거버넌스의 간소화라는 세 가지 이점이 있습니다.

메모리는 단일 프롬프트(Prompt)나 쿼리(Query)로는 유지할 수 없는 컨텍스트(Context)를 에이전트에게 제공합니다. 엔터프라이즈 업무는 여러 단계와 여러 날에 걸쳐 진행되므로, 메모리가 없다면 '조작 기억 상실' 상태에 빠지게 됩니다.

메모리 유형	설명	저장 기간	주의 사항
세션 메모리 (Session Memory)	단일 대화 내의 문맥 (예: 현재 논의 중인 송장 번호)	세션 종료 시까지	장기 보관 불필요
...

보유 (Retention): 무엇을, 어느 기간 동안 저장하고, 언제 삭제할지를 정의합니다. -
개인정보 보호 (Privacy): 메모리에 기밀 데이터가 포함된 경우, 엄격한 액세스 정책 (Access Policy)을 적용합니다. -
감사 (Audit): 어떤 메모리가 어떤 추천에 사용되었는지 설명 가능하게 합니다. -
수정 (Correction): 에이전트가 잘못된 결론을 메모리에 저장했을 경우, 사람이 수정하거나 플래그(Flag)를 지정할 수 있는 메커니즘을 마련합니다.

# 메모리 관리 정책 설정 예시
memory_policy:
workflow_memory:
...

RAG, 지식 그래프 (Knowledge Graph), 메모리는 상호 보완적입니다. 실제 엔터프라이즈 워크플로우에서는 이들이 연계되어 작동합니다.

RAG: 해당 구매 정책 및 계약 조항을 검색 -
지식 그래프 (Knowledge Graph): 요청자, 카테고리, 공급업체, 계약, 승인 경로 간의 관계를 취득 -
메모리: 과거에 유사한 케이스가 서류 미비로 반려되었음을 상기

RAG: 회계 가이드라인 및 마감 절차서를 검색 -
지식 그래프 (Knowledge Graph): 엔티티(Entity)-계정-분개-통제 간의 관계를 매핑 -
메모리: 과거의 예외 사항 및 컨트롤러(Controller)의 판단 이력을 참조

컨텍스트 계층의 품질을 평가하기 위해서는 다음 관점들을 체크리스트로 활용합니다.

정확성 (Accuracy): 에이전트가 항상 최신의 유효한 정책을 참조하고 있는가 -
권한 준수 (Authorization Compliance): 액세스 권한이 없는 데이터를 절대 참조하지 않는가 -
일관성 (Consistency): 동일한 워크플로우 내에서 모순되는 판단을 내리지 않는가 -
설명 가능성 (Explainability): 어떤 컨텍스트를 바탕으로 판단했는지 추적할 수 있는가 -
수정 가능성 (Correctability): 잘못된 메모리나 검색 결과를 사람이 수정할 수 있는가 -

RAG, 지식 그래프, 메모리는 서로 대체하는 것이 아니라 보완하는 것입니다. 이들을 통합한 컨텍스트 계층이 엔터프라이즈 AI 에이전트의 신뢰성을 결정짓습니다.

만약 현재의 AI 에이전트가 '프롬프트 엔지니어링 (Prompt Engineering)'과 '애드혹(Ad-hoc) 검색'에 의존하고 있다면, 다음 우선순위는 컨텍스트 계층의 구축입니다. 정확하고, 관련성이 높으며, 안전한 컨텍스트——그것이야말로 에이전트에 대한 운영 신뢰를 형성하는 기반이기 때문입니다.

참고