온톨로지와 메모리 시스템 (13/13) — RAG 다음은 무엇인가: 컨텍스트 인텔리전스와 메모리 DB
RAG는 여전히 중요하다. 하지만 실제 운영 시스템이 부딪히는 문제는 점점 "무엇을 찾을까"보다 "지금 이 순간 어떤 맥락을 어떻게 구성할까"로 이동하고 있다. 검색은 시작점이고, 경쟁력은 컨텍스트 조립 능력에서 갈린다.
영문판: What Comes After RAG? The Age of Context Intelligence and Memory Databases
들어가며: 정적 RAG가 잘하는 일과, 잘 못하는 일
RAG는 한동안 생성형 AI의 가장 실용적인 답이었다. 모델의 파라메트릭 메모리만 믿지 말고, 외부 문서를 검색해서 근거를 붙인 뒤 답하게 하자는 발상은 단순하면서도 강력했다. 최신 정보, 사내 문서, 규정, 매뉴얼처럼 학습 가중치 안에 없거나 자주 바뀌는 지식을 다뤄야 하는 환경에서는 특히 그렇다.
문제는 운영 환경이 생각보다 훨씬 더 동적이라는 데 있다. 사용자의 질문은 늘 문서 검색으로만 해결되지 않는다. 같은 질문이라도 누가 묻는지, 직전 단계에서 어떤 도구 호출이 있었는지, 어떤 정책이 현재 유효한지, 방금 실패한 작업이 무엇인지에 따라 필요한 맥락이 달라진다. 많은 RAG 시스템이 여전히 "질문 하나, 검색 한 번, 상위 K개 문서 주입"이라는 정적 흐름에 머문다면, 실제 업무는 이미 그 틀을 벗어나 있다.
그래서 최근의 변화는 단순히 "더 큰 컨텍스트 윈도"나 "더 좋은 벡터 검색"만으로 설명되지 않는다. 업계의 관심은 점차 정적 RAG에서 동적으로 맥락을 구성하는 시스템, 다시 말해 여기서 말하는 컨텍스트 인텔리전스로 이동하고 있다. 이때 메모리 DB는 그 실행 기반이 되고, 블록체인은 일부 영역에서 신뢰와 계보를 남기는 보조 계층이 될 수 있다.
이 글의 핵심 주장은 간단하다. AI는 정적 RAG에서 컨텍스트 인텔리전스로 이동 중이며, 메모리 DB는 그 실행 기반, 블록체인은 선택적 신뢰·계보 계층이 될 가능성이 있다. 다만 마지막 문장은 어디까지나 조건부다. 특히 블록체인은 도움이 되는 자리와 과장되는 자리를 분리해서 봐야 한다.
1. Dynamic RAG: 검색 결과를 고정 입력으로 넣는 시대 이후
정적 RAG의 기본 모델은 비교적 선명하다. 질문이 들어오면 검색하고, 관련 문서 조각을 뽑아 프롬프트에 넣고, 모델이 답한다. 이 구조는 FAQ, 문서 기반 Q&A, 규정 조회처럼 문제 정의가 안정적인 곳에서는 여전히 매우 유효하다.
하지만 실제 운영에서는 검색 이전과 이후에 더 많은 판단이 필요하다. 질문이 모호하면 먼저 재질문해야 할 수 있다. 질의 유형이 정책 해석인지, 절차 실행인지, 데이터 조회인지에 따라 검색 대상이 달라진다. 같은 문서라도 초급 사용자에게는 요약이, 운영자에게는 원문과 변경 이력이 더 중요할 수 있다. 경우에 따라서는 문서를 찾는 것보다 최근 작업 로그, 직전 도구 호출 결과, 사용자별 선호 설정, 실패 히스토리를 더 먼저 봐야 한다.
이 지점에서 Dynamic RAG가 등장한다. Dynamic RAG는 보통 다음과 같은 특징을 갖는다.
- 질의 분류와 라우팅이 먼저 일어난다.
- 검색 대상이 문서 저장소 하나로 고정되지 않는다.
- 검색 결과를 그대로 넣지 않고 압축, 재정렬, 검증, 추가 검색을 반복한다.
- 중간 단계의 도구 실행 결과도 컨텍스트의 일부로 편입된다.
- 답변 생성 전에 "지금 부족한 맥락이 무엇인가"를 다시 판단한다.
즉 Dynamic RAG의 핵심은 검색 알고리즘 하나가 아니라 컨텍스트를 갱신하는 루프다. 문서를 찾는 시스템에서 상황을 조립하는 시스템으로 가는 것이다.
이 관점에서 보면 RAG의 단위도 달라진다. 예전에는 "좋은 청킹", "좋은 임베딩", "좋은 리트리버"가 중심이었다면, 이제는 "언제 검색하지 말아야 하는가", "어떤 상태를 장기 기억으로 승격할 것인가", "도구 결과와 문서 근거가 충돌하면 무엇을 우선할 것인가" 같은 운영 질문이 앞으로 나온다.
2. Context Intelligence: 중요한 것은 문서 검색이 아니라 맥락 구성 능력
컨텍스트 인텔리전스는 아직 업계 전체에서 딱 하나로 고정된 표준 용어라고 보기는 어렵다. 이 글에서는 이를 질문, 사용자 상태, 작업 단계, 정책, 도구 결과, 과거 기억을 함께 고려해 현재 필요한 맥락을 선택하고 조립하는 능력으로 정의하겠다.
왜 이 개념이 중요한가. LLM은 본질적으로 주어진 컨텍스트에 매우 민감하다. 같은 모델도 어떤 정보를 먼저 보았는지, 무엇을 생략했는지, 어떤 형식으로 정리했는지에 따라 결과가 크게 달라진다. 그래서 실제 성능 차이는 점점 모델 자체보다 맥락 편성 능력에서 발생한다.
컨텍스트 인텔리전스를 구성하는 요소를 거칠게 나누면 다섯 가지다.
selection: 지금 필요한 정보 후보를 넓게 모은다.ranking: 그중 무엇이 현재 단계에 가장 중요한지 정렬한다.compression: 긴 정보를 짧고 쓰기 좋은 상태로 압축한다.state binding: 현재 사용자와 작업 상태에 맞게 연결한다.refresh: 실행 결과에 따라 맥락을 계속 갱신한다.
여기서 중요한 것은 "많이 넣는 것"이 아니라 "맞게 넣는 것"이다. 긴 컨텍스트 윈도는 분명 유리하지만, 넓은 입력 창이 곧 좋은 사고를 보장하지는 않는다. 불필요한 정보, 오래된 상태, 서로 충돌하는 문서가 섞이면 모델은 더 똑똑해지기보다 더 혼란스러워질 수 있다.
그래서 앞으로의 AI 시스템은 단순한 retrieval stack보다 context operating system에 가까워질 가능성이 크다. 무엇을 기억하고, 무엇을 잊고, 무엇을 지금 꺼내고, 무엇을 검증하고, 무엇을 버릴지 결정하는 운영 계층이 핵심이 된다.
3. Memory DB: 컨텍스트 인텔리전스의 실행 기반
이때 메모리 DB의 역할이 커진다. 여기서 말하는 메모리 DB는 단순히 "빠른 캐시"만 뜻하지 않는다. 더 넓게 보면 에이전트와 AI 시스템이 상태, 기억, 사건, 요약, 선호, 작업 히스토리, 관찰 결과를 구조적으로 저장하고 다시 꺼내기 위한 운영 데이터 계층에 가깝다.
왜 벡터 DB만으로는 부족한가. 벡터 DB는 유사도 검색에 강하지만, 운영 상태 전체를 다루는 데는 한계가 있다. 실제 시스템은 다음을 함께 저장해야 한다.
- 문서 의미 검색용 임베딩
- 사용자별 장기 선호와 프로필
- 세션별 단기 작업 상태
- 도구 호출 결과와 오류 기록
- 요약본과 원문 사이의 연결
- 정책 버전과 유효 시간
- 메모리의 출처, 신뢰도, 만료 조건
이 구조는 대개 하나의 저장소로 끝나지 않는다. 현실적인 메모리 DB 아키텍처는 보통 다층 구조를 가진다.
working memory: 현재 턴 또는 현재 작업 단계에만 필요한 짧은 상태episodic memory: 이전에 어떤 시도를 했고 무엇이 성공 또는 실패했는지에 대한 사건 기록semantic memory: 정제된 사실, 규칙, 도메인 지식procedural memory: 자주 쓰는 절차, 실행 패턴, 워크플로 템플릿
핵심은 이 메모리들이 모두 같은 중요도를 가지지 않는다는 점이다. 모든 상호작용을 영구 저장하면 노이즈만 쌓인다. 반대로 너무 적게 저장하면 시스템은 매번 처음부터 다시 시작한다. 따라서 메모리 DB의 본질은 저장 그 자체보다 승격과 망각의 정책이다.
예를 들어 사용자가 한 번 우연히 언급한 취향은 장기 기억이 아닐 수 있다. 하지만 반복적으로 드러난 선호, 자주 실패하는 업무 단계, 검증된 정책 해석, 사람의 승인을 거친 요약은 장기 기억 후보가 될 수 있다. 결국 중요한 질문은 "기억할 것인가"가 아니라 "무엇을 어떤 신뢰도로 언제까지 기억할 것인가"다.
이 지점에서 메모리 DB는 실행 substrate가 된다. 컨텍스트 인텔리전스가 판단 엔진이라면, 메모리 DB는 그 판단이 읽고 쓰는 작업 표면이다. 좋은 에이전트 파이프라인은 단순히 프롬프트를 잘 쓰는 시스템이 아니라, 메모리를 구조화해 다음 판단의 재료로 돌려주는 시스템이 된다.
4. 블록체인과 AI: 실제로 도움이 되는 자리와, 과장이 시작되는 자리
블록체인은 AI와 연결될 때 자주 과장된다. 모든 모델 출력이 온체인으로 가야 한다거나, 토큰 인센티브만 붙이면 지능형 네트워크가 저절로 작동한다는 식의 이야기는 대체로 설계보다 구호에 가깝다. 대부분의 AI 추론은 속도, 비용, 프라이버시 측면에서 온체인 실행과 잘 맞지 않는다.
그렇다고 블록체인이 완전히 무의미하다는 뜻은 아니다. 오히려 역할을 좁히면 분명히 쓸모 있는 영역이 있다. 특히 다음과 같은 문제에서는 의미가 있다.
- 어떤 데이터와 모델, 어떤 프롬프트 버전, 어떤 도구 결과를 근거로 결론이 만들어졌는지 남기는
lineage - 사람이 나중에 "이 결과가 어떤 승인 체계를 거쳤는가"를 감사하는
auditability - 여러 조직이 공동으로 쓰는 메모리나 데이터 기여 이력을 상호 신뢰 없이 기록하는
shared provenance - 생성물의 출처, 서명, 타임스탬프를 남겨 위변조 분쟁을 줄이는
integrity proof
즉 블록체인은 AI의 사고 엔진이 아니라, 특정 조건에서 신뢰 계보를 외부 검증 가능하게 남기는 레이어로 보는 편이 훨씬 현실적이다.
다만 여기에도 경계선이 있다. 모든 상호작용을 체인에 쓰는 것은 대개 비효율적이다. 개인 데이터와 민감한 운영 로그는 프라이버시 이슈가 크다. 그리고 "기록이 불변이다"는 말은 종종 장점이면서 동시에 규제와 삭제 요구에 취약한 단점이 된다. 따라서 대부분의 실무 시스템에서는 원문 전체를 온체인에 두기보다, 해시, 서명, 버전 포인터, 승인 이벤트만 남기는 식의 하이브리드 구성이 더 현실적이다.
한마디로 정리하면 이렇다. 메모리 DB가 실행을 위한 기억 장치라면, 블록체인은 필요한 경우 그 기억과 의사결정의 계보를 공증하는 장치가 될 수 있다. 하지만 이 결합이 모든 AI 시스템의 기본형이 될 것이라고 단정하는 것은 아직 이르다. 이 부분은 분명히 speculative하다.
5. 에이전트 파이프라인과 운영 시스템: 왜 이 모든 것이 연결되는가
이 흐름은 에이전트 파이프라인과 만나면서 더 분명해진다. 2026년 4월 29일 게시된 유승택의 글 토스 모닥불 회고 : 프론트엔드 개발팀의 AI 활용은 토스 사례를 바탕으로 Passive RAG, 무개입형 파이프라인, 측정 가능한 생산성이라는 세 축을 강조한다. 내 기준에서 그 글이 중요한 이유는 "문서를 더 많이 쌓자"가 아니라 "지식이 살아서 흐르는 파이프라인을 만들자"는 문제의식을 분명히 보여주기 때문이다. 이 글은 바로 그 문제의식에서 한 걸음 더 나아가, 그 파이프라인이 장기적으로는 메모리와 신뢰 계층까지 필요로 하게 된다는 점을 짚고 있다.
에이전트 파이프라인을 단순화하면 이런 식이다.
- 목표를 해석한다.
- 필요한 정보와 도구를 고른다.
- 중간 결과를 읽고 상태를 갱신한다.
- 부족한 맥락을 다시 보충한다.
- 검증하고, 필요하면 재시도한다.
- 결과와 교훈 일부를 메모리로 남긴다.
이 흐름은 더 이상 "검색 후 생성"으로 설명되지 않는다. 오히려 "상태 기반 실행과 맥락 갱신"이 핵심이다. 정적 RAG가 도서관에서 책 몇 권을 가져오는 단계라면, 운영형 에이전트는 도서관, 작업대, 메모장, 감사 로그, 승인 체계를 함께 다루는 셈이다.
여기서 메모리 DB가 없다면 매 단계가 끊긴다. 이전 실패를 배우지 못하고, 사용자별 차이를 누적하지 못하고, 검증 결과를 다음 실행에 반영하지 못한다. 반대로 메모리만 많고 통제 정책이 없으면, 시스템은 곧 오래된 사실과 잡음에 잠식된다. 그래서 좋은 파이프라인은 메모리를 많이 갖는 것이 아니라 메모리를 운영 가능하게 만드는 것에 가깝다.
블록체인이 들어올 수 있다면 바로 이 운영 경계다. 예를 들어 다기관 협업, 규제 감사, 생성물의 출처 증명, 승인 체계 추적이 중요한 영역이라면 파이프라인 일부 사건을 외부 검증 가능한 로그로 남길 이유가 생긴다. 하지만 일반적인 사내 업무 자동화나 개인 생산성 도구까지 모두 그 수준의 무결성 계층을 필요로 하지는 않는다.
6. 결론: 앞으로의 AI 시스템을 설계할 때 붙잡아야 할 원칙
정적 RAG는 끝난 기술이 아니다. 오히려 많은 시스템에서 여전히 가장 비용 대비 효과가 좋은 출발점이다. 다만 거기서 멈추면, 실제 운영의 핵심 문제인 상태 변화와 맥락 조립을 다루지 못한다. 앞으로 중요한 것은 "더 많이 검색하는가"보다 "더 정확하게 현재 맥락을 구성하는가"다.
마지막으로, 실무적으로 유용한 설계 원칙을 짧게 정리해 보자.
RAG를 검색 기능으로만 보지 말고 컨텍스트 조립 파이프라인의 일부로 보라.문서 검색, 상태 저장, 도구 결과, 사용자 선호를 분리하되 연결 가능한 메모리 구조를 설계하라.모든 기억을 저장하지 말고, 승격 기준과 만료 기준을 먼저 정의하라.긴 컨텍스트를 늘리는 것보다, 어떤 맥락을 버릴지 결정하는 정책에 더 투자하라.신뢰가 중요한 영역에서는 출력보다 lineage를 설계하라.블록체인은 기본값이 아니라 선택형 감사 계층으로 검토하라.에이전트 파이프라인의 품질은 추론 한 번보다 상태 갱신과 검증 루프에서 갈린다.
정리하면 이렇다. AI의 다음 경쟁력은 정답 생성 그 자체보다 적절한 맥락을 지속적으로 구성하고, 그 과정의 기억과 신뢰를 운영하는 능력에 있다. 정적 RAG는 그 문을 연 기술이었다. 이제 중요한 것은 그 문 뒤의 운영체제를 만드는 일이다.
참고
- 유승택,
토스 모닥불 회고 : 프론트엔드 개발팀의 AI 활용, 2026-04-29, https://dev.cluster-taek.cloud/posts/toss-agent-pipeline
시리즈 전체 안내: 시리즈 목차
댓글
댓글 쓰기