Home
Blog
클로드 코워크와 같은 장기 운영 에이전트가 등장하면서 RAG는 구식이 되어가고 있나요?

클로드 코워크와 같은 장기 운영 에이전트가 등장하면서 RAG는 구식이 되어가고 있나요?

Engineering

January 27, 2026

Min Yin

클로드 코워크는 클로드 데스크톱 앱의 새로운 에이전트 기능입니다. 개발자의 관점에서 보면 기본적으로 모델을 둘러싼 자동화된 작업 실행기로, 로컬 파일을 읽고, 수정하고, 생성할 수 있으며 각 단계에 대해 수동으로 프롬프트할 필요 없이 다단계 작업을 계획할 수 있습니다. Claude Code 뒤에 있는 동일한 루프가 터미널 대신 데스크톱에 노출되어 있다고 생각하면 됩니다.

Cowork의 핵심 기능은 상태 손실 없이 장시간 실행할 수 있다는 점입니다. 일반적인 대화 시간 초과나 컨텍스트 재설정이 발생하지 않습니다. 작업을 계속하고, 중간 결과를 추적하고, 여러 세션에서 이전 정보를 재사용할 수 있습니다. 기본 메커니즘은 지속적인 작업 상태 + 컨텍스트 이월에 가깝지만 '장기 기억'이라는 인상을 줍니다. 어느 쪽이든, 자체 메모리 계층을 구축하지 않으면 모든 것이 초기화되는 기존 채팅 모델과는 다른 경험을 제공합니다.

이는 개발자에게 두 가지 실질적인 질문을 제기합니다:

모델이 이미 과거 정보를 기억할 수 있다면 RAG 또는 에이전트 RAG는 여전히 어디에 적합할까요? RAG가 대체될 것인가?
로컬 코워크 스타일의 에이전트를 원한다면 장기 메모리를 직접 구현하려면 어떻게 해야 할까요?

이 글의 나머지 부분에서는 이러한 질문을 자세히 다루고 벡터 데이터베이스가 이 새로운 '모델 메모리' 환경에 어떻게 적합한지 설명합니다.

클로드 코워크와 RAG: 차이점은 무엇인가요?

앞서 말씀드렸듯이 Claude Cowork는 로컬 파일을 읽고 쓰고, 작업을 더 작은 단계로 나누고, 상태를 잃지 않고 계속 작업할 수 있는 Claude Desktop 내부의 에이전트 모드입니다. 자체 작업 컨텍스트를 유지하므로 여러 시간이 걸리는 작업도 일반 채팅 세션처럼 초기화되지 않습니다.

RAG (검색 증강 세대)는 모델에 외부 지식에 대한 액세스 권한을 부여하는 또 다른 문제를 해결합니다. 데이터를 벡터 데이터베이스로 색인하고 각 쿼리에 대한 관련 청크를 검색하여 모델에 공급합니다. 이 시스템은 문서, 로그, 제품 데이터 등을 위한 일종의 '장기 메모리'를 LLM 애플리케이션에 제공하기 때문에 널리 사용됩니다.

두 시스템 모두 모델이 '기억'하는 데 도움이 된다면 실제 차이점은 무엇일까요?

Cowork의 메모리 처리 방식

Cowork의 메모리는 읽기-쓰기 방식입니다. 상담원은 현재 작업 또는 대화에서 어떤 정보가 관련성이 있는지 판단하여 메모리 항목으로 저장하고 나중에 작업이 진행됨에 따라 해당 정보를 검색합니다. 이를 통해 Cowork는 장기 실행 워크플로우, 특히 진행에 따라 새로운 중간 상태를 생성하는 워크플로우에서 연속성을 유지할 수 있습니다.

RAG와 에이전트 RAG의 메모리 처리 방식

표준 RAG는 쿼리 중심 검색으로, 사용자가 무언가를 요청하면 시스템이 관련 문서를 가져오고 모델이 이를 사용해 답변하는 방식입니다. 검색 코퍼스는 안정적으로 유지되고 버전이 관리되며 개발자는 코퍼스에 들어가는 내용을 정확하게 제어할 수 있습니다.

최신 에이전트 RAG는 이 패턴을 확장합니다. 모델은 워크플로를 계획하거나 실행하는 동안 언제 정보를 검색할지, 무엇을 검색할지, 어떻게 사용할지 결정할 수 있습니다. 이러한 시스템은 Cowork와 마찬가지로 긴 작업을 실행하고 도구를 호출할 수 있습니다. 하지만 에이전트 RAG를 사용하더라도 검색 계층은 상태 중심이 아닌 지식 중심으로 유지됩니다. 에이전트는 권위 있는 사실을 검색할 뿐, 진화하는 작업 상태를 코퍼스에 다시 기록하지 않습니다.

이를 다른 방식으로 바라볼 수도 있습니다:

코워크의 메모리는 작업 중심적입니다. 에이전트가 자신의 진화하는 작업 상태를 쓰고 읽습니다.
RAG는 지식 기반입니다. 시스템이 모델이 의존해야 하는 기존 정보를 검색합니다.

리버스 엔지니어링 클로드 코워크: 장기 실행 에이전트 메모리를 구축하는 방법

Cowork가 많은 사랑을 받는 이유는 다단계 작업을 지속적으로 잊지 않고 처리하기 때문입니다. 개발자의 입장에서 어떻게 그렇게 긴 세션 동안 상태를 유지할 수 있는지 궁금합니다. 앤트로픽은 내부를 공개하지 않았지만, Claude의 메모리 모듈에 대한 이전 개발 실험을 바탕으로 적절한 멘탈 모델을 구성할 수 있습니다.

Claude는 영구적인 장기 메모리 계층과 온디맨드 검색 도구라는 하이브리드 설정에 의존하는 것 같습니다. Claude는 모든 요청에 전체 대화를 채우는 대신, 관련성이 있다고 판단되는 경우에만 과거 컨텍스트를 선택적으로 가져옵니다. 이를 통해 모델은 매번 토큰을 날려버리지 않고도 높은 정확도를 유지할 수 있습니다.

요청 구조를 세분화하면 대략 다음과 같습니다:

[0] Static system instructions
[1] User memory (long-term)
[2] Retrieved / pruned conversation history
[3] Current user message

흥미로운 동작은 구조 자체가 아니라 모델이 무엇을 업데이트하고 언제 검색을 실행할지 결정하는 방식입니다.

사용자 메모리: 퍼시스턴트 레이어

Claude는 시간이 지남에 따라 업데이트되는 장기 메모리 저장소를 유지합니다. 그리고 ChatGPT의 예측 가능한 메모리 시스템과 달리 Claude는 좀 더 "살아 있는" 느낌을 줍니다. 메모리를 XML과 유사한 블록에 저장하고 두 가지 방식으로 업데이트합니다:

암시적 업데이트: 때로는 모델이 안정적인 선호도나 사실이라고 판단하여 조용히 메모리에 기록하기도 합니다. 이러한 업데이트는 즉각적인 것이 아니라 몇 번의 턴 후에 나타나며, 관련 대화가 사라지면 오래된 기억이 사라질 수 있습니다.
명시적 업데이트: 사용자는 memory_user_edits 도구를 사용하여 메모리를 직접 수정할 수 있습니다("X 기억하기", "Y 잊어버리기"). 이러한 쓰기는 즉각적으로 이루어지며 CRUD 작업처럼 동작합니다.

Claude는 백그라운드 휴리스틱을 실행하여 지속할 가치가 있는 내용을 결정하며, 명시적인 지시를 기다리지 않습니다.

대화 검색: 온디맨드 부분

Claude는 많은 LLM 시스템처럼 롤링 요약을 유지하지 않습니다. 대신 컨텍스트가 누락되었다고 생각될 때마다 호출할 수 있는 검색 함수 도구 상자가 있습니다. 이러한 검색 호출은 매번 발생하는 것이 아니라 모델이 자체적인 내부 판단에 따라 트리거합니다.

가장 눈에 띄는 것은 conversation_search 입니다. 사용자가 "지난달의 그 프로젝트"와 같이 모호한 말을 하면 Claude는 종종 이 도구를 실행하여 관련 턴을 찾아냅니다. 주목할 만한 점은 문구가 모호하거나 다른 언어로 된 경우에도 여전히 작동한다는 것입니다. 이는 꽤 분명한 의미를 내포하고 있습니다:

일종의 의미론적 매칭(임베딩)
아마도 정규화 또는 경량 번역과 결합되었을 것입니다.
정확성을 위해 계층화된 키워드 검색

기본적으로 이것은 모델의 도구 세트에 번들로 제공되는 미니어처 RAG 시스템과 매우 유사합니다.

Claude의 검색 동작이 기본 히스토리 버퍼와 다른 점

테스트와 로그를 보면 몇 가지 패턴이 눈에 띕니다:

검색은 자동으로 수행되지 않습니다. 모델이 언제 호출할지 선택합니다. 이미 충분한 컨텍스트가 있다고 판단되면 굳이 호출하지 않습니다.
검색된 청크에는 사용자 및 어시스턴트 메시지가 모두포함됩니다 . 이는 유용합니다. 사용자 전용 요약보다 더 많은 뉘앙스를 유지합니다.
토큰 사용 내역은 정상적으로 유지됩니다. 매번 기록이 주입되지 않기 때문에 긴 세션이 예측할 수 없을 정도로 늘어나지 않습니다.

전반적으로 검색이 모델 자체의 추론 루프의 일부로 이루어진다는 점을 제외하면 검색 증강 LLM처럼 느껴집니다.

이 아키텍처는 영리하지만 무료는 아닙니다:

검색은 지연 시간과 더 많은 "움직이는 부분"(인덱싱, 랭킹, 재랭킹)을 추가합니다.
이 모델은 때때로 컨텍스트가 필요한지 여부를 잘못 판단하여 데이터를 사용할 수 있음에도 불구하고 고전적인 'LLM 건망증'이 나타납니다.
모델 동작은 프롬프트 입력뿐만 아니라 보이지 않는 도구 트리거에 따라 달라지기 때문에 디버깅이 더 까다로워집니다.

장기 기억 처리에서 클로드 코워크와 클로드 코덱스 비교

검색에 중점을 둔 Claude의 설정과 달리 ChatGPT는 훨씬 더 구조화되고 예측 가능한 방식으로 메모리를 처리합니다. 의미론적 조회를 수행하거나 오래된 대화를 미니 벡터 저장소처럼 처리하는 대신 ChatGPT는 다음과 같은 계층화된 구성 요소를 통해 각 세션에 직접 메모리를 주입합니다:

사용자 메모리
세션 메타데이터
현재 세션 메시지

사용자 메모리

사용자 메모리는 주요 장기 저장소 계층으로, 여러 세션에 걸쳐 지속되며 사용자가 편집할 수 있는 부분입니다. 여기에는 이름, 배경, 진행 중인 프로젝트, 학습 환경 설정 등 매우 일반적인 것들이 저장됩니다. 모든 새 대화는 시작할 때 이 블록이 주입되므로 모델은 항상 일관된 사용자 보기로 시작합니다.

ChatGPT는 이 계층을 두 가지 방식으로 업데이트합니다:

명시적 업데이트: 사용자가 모델에 "이걸 기억해" 또는 "저걸 잊어버려"라고 말하면 메모리가 즉시 변경됩니다. 이는 기본적으로 모델이 자연어를 통해 노출하는 CRUD API입니다.
암시적 업데이트: 모델이 직책이나 환경 설정과 같이 장기 기억에 대한 OpenAI의 규칙에 맞는 정보를 발견하고 사용자가 메모리를 비활성화하지 않은 경우, 조용히 자체적으로 추가합니다.

개발자의 관점에서 이 계층은 간단하고 결정론적이며 추론하기 쉽습니다. 임베딩 룩업이나 무엇을 가져올지에 대한 휴리스틱이 필요하지 않습니다.

세션 메타데이터

세션 메타데이터는 스펙트럼의 반대편에 위치합니다. 수명이 짧고 영구적이지 않으며 세션이 시작될 때 한 번만 삽입됩니다. 대화의 환경 변수라고 생각하면 됩니다. 여기에는 다음과 같은 것들이 포함됩니다:

사용 중인 디바이스
계정/구독 상태
대략적인 사용 패턴(활동 일수, 모델 분포, 평균 대화 길이)

이 메타데이터는 모델이 장기 메모리를 오염시키지 않으면서 현재 환경에 맞는 응답(예: 모바일에서 더 짧은 답변 작성)을 형성하는 데 도움이 됩니다.

현재 세션 메시지

표준 슬라이딩 창 기록으로, 토큰 한도에 도달할 때까지 현재 대화에 있는 모든 메시지입니다. 창이 너무 커지면 오래된 대화는 자동으로 삭제됩니다.

결정적으로, 이 퇴거는 사용자 메모리나 교차 세션 요약에는 영향을 미치지 않습니다. 로컬 대화 기록만 축소됩니다.

Claude와 가장 큰 차이는 ChatGPT가 "최근 대화이지만 현재 대화가 아닌" 대화를 처리하는 방식에서 나타납니다. Claude는 관련성이 있다고 판단되는 경우 검색 도구를 호출하여 과거 컨텍스트를 검색합니다. ChatGPT는 그렇게 하지 않습니다.

대신 ChatGPT는 모든 대화에 삽입되는 매우 가벼운 교차 세션 요약을 유지합니다. 이 계층에 대한 몇 가지 주요 세부 정보입니다:

이 계층은 어시스턴트 메시지가 아닌 사용자 메시지만 요약합니다.
안정적인 테마나 관심사를 포착하기에 충분한 15개 정도의 아주 작은 항목 세트를 저장합니다.
임베딩 계산, 유사성 순위, 검색 호출을 수행하지 않습니다. 기본적으로 동적 조회가 아닌 미리 씹어낸 컨텍스트입니다.

엔지니어링 관점에서 볼 때, 이 접근 방식은 유연성과 예측 가능성을 맞바꿉니다. 이상한 검색 실패가 발생할 가능성이 없으며, 즉시 가져오는 것이 없으므로 추론 대기 시간이 안정적으로 유지됩니다. 단점은 6개월 전의 임의의 메시지가 요약 레이어에 포함되지 않는 한 ChatGPT가 이를 가져오지 않는다는 것입니다.

상담원 메모리를 쓰기 가능하게 만들기 위한 과제

상담원이 읽기 전용 메모리 (일반적인 RAG)에서 사용자 작업, 결정 및 기본 설정을 기록할 수 있는 쓰기 가능한 메모리로이동하면 복잡성이 급격히 증가합니다. 더 이상 단순히 문서를 검색하는 것이 아니라 모델이 의존하는 상태를 유지해야 하기 때문입니다.

쓰기 가능한 메모리 시스템은 세 가지 실제 문제를 해결해야 합니다:

무엇을 기억할 것인가: 에이전트는 어떤 이벤트, 선호도 또는 관찰 내용을 보관할 가치가 있는지 결정하기 위한 규칙이 필요합니다. 이러한 규칙이 없으면 메모리의 크기가 폭발적으로 증가하거나 노이즈로 가득 차게 됩니다.
메모리를 저장하고 계층화하는 방법: 모든 메모리가 같은 것은 아닙니다. 최근 항목, 장기적인 사실, 임시 메모는 모두 서로 다른 저장 계층, 보존 정책, 색인 전략이 필요합니다.
검색을 방해하지 않고 빠르게 쓰는 방법: 메모리는 지속적으로 기록되어야 하지만, 시스템이 높은 처리량의 삽입을 위해 설계되지 않은 경우 잦은 업데이트로 인해 인덱스 품질이 저하되거나 쿼리 속도가 느려질 수 있습니다.

과제 1: 기억할 가치가 있는 것은 무엇인가?

사용자가 하는 모든 작업이 장기 기억에 남아야 하는 것은 아닙니다. 누군가 임시 파일을 만들었다가 5분 후에 삭제하는 경우, 이를 영원히 기록하는 것은 누구에게도 도움이 되지 않습니다. 이것이 바로 핵심적인 어려움입니다. 시스템이 실제로 중요한 것을 어떻게 결정할까요?

(1) 중요도를 판단하는 일반적인 방법

팀은 보통 여러 가지 휴리스틱을 혼합하여 사용합니다:

시간 기반: 오래된 작업보다 최근 작업이 더 중요함
빈도 기반: 반복적으로 액세스한 파일이나 작업이 더 중요함
유형 기반: 일부 개체는 본질적으로 더 중요합니다(예: 프로젝트 구성 파일과 캐시 파일).

(2) 규칙이 충돌하는 경우

이러한 신호는 종종 충돌합니다. 지난주에 만들었지만 오늘 많이 편집한 파일-나이와 활동 중 어느 쪽을 우선시해야 할까요? "정답"은 하나도 없기 때문에 중요도 점수가 금방 지저분해지는 경향이 있습니다.

(3) 벡터 데이터베이스의 도움

벡터 데이터베이스를 사용하면 수동 정리 없이 중요도 규칙을 적용할 수 있는 메커니즘을 제공합니다:

TTL: Milvus는 설정된 시간이 지나면 자동으로 데이터를 제거할 수 있습니다.
감쇠: 오래된 벡터는 가중치를 낮춰 자연스럽게 검색에서 사라지도록 할 수 있습니다.

과제 2: 실제 메모리 계층화

에이전트 실행 시간이 길어질수록 메모리가 쌓입니다. 모든 것을 빠른 스토리지에 보관하는 것은 지속 가능하지 않으므로 시스템에는 메모리를 핫 (자주 액세스하는) 계층과 콜드 (거의 액세스하지 않는) 계층으로 분할할 수 있는 방법이 필요합니다.

(1) 메모리가 차가워지는 시기 결정하기

이 모델에서 핫 메모리는 지연 시간이 짧은 액세스를 위해 RAM에 보관되는 데이터를 의미하며, 콜드 메모리는 비용을 줄이기 위해 디스크나 오브젝트 스토리지로 이동되는 데이터를 의미합니다.

메모리가 차가워지는 시점을 결정하는 방법은 여러 가지가 있습니다. 일부 시스템에서는 경량 모델을 사용해 작업이나 파일의 의미와 최근 사용량을 기반으로 의미론적 중요성을 추정합니다. 30일 동안 액세스하지 않았거나 일주일 동안 검색 결과에 나타나지 않은 메모리를 옮기는 등 단순한 규칙 기반 로직에 의존하는 시스템도 있습니다. 사용자는 특정 파일이나 작업을 중요하다고 명시적으로 표시해 항상 핫 메모리로 유지하도록 할 수도 있습니다.

(2) 핫 메모리와 콜드 메모리가 저장되는 위치

일단 분류되면 핫 메모리와 콜드 메모리는 서로 다르게 저장됩니다. 핫 메모리는 RAM에 유지되며 활성 작업 컨텍스트나 최근 사용자 작업과 같이 자주 액세스하는 콘텐츠에 사용됩니다. 콜드 메모리는 액세스 속도는 느리지만 스토리지 비용이 훨씬 저렴한 디스크 또는 S3와 같은 객체 스토리지 시스템으로 이동됩니다. 콜드 메모리는 거의 필요하지 않고 일반적으로 장기간 참조할 때만 액세스하기 때문에 이러한 절충안이 잘 작동합니다.

(3) 벡터 데이터베이스의 지원 방법

밀버스와 질리즈 클라우드는 단일 쿼리 인터페이스를 유지하면서 핫-콜드 계층형 스토리지를 활성화하여 이러한 패턴을 지원하므로 자주 액세스하는 벡터는 메모리에 유지되고 오래된 데이터는 자동으로 더 저렴한 스토리지로 이동합니다.

과제 3: 메모리를 얼마나 빠르게 기록해야 할까요?

기존의 RAG 시스템은 일반적으로 데이터를 일괄적으로 씁니다. 인덱스는 오프라인으로 재구축되며, 종종 하룻밤 사이에 재구축되고 나중에야 검색이 가능해집니다. 이 접근 방식은 정적 지식 기반에는 적합하지만 에이전트 메모리에는 적합하지 않습니다.

(1) 상담원 메모리에 실시간 쓰기가 필요한 이유

상담원 메모리는 사용자 행동이 발생하는 대로 캡처해야 합니다. 행동이 즉시 기록되지 않으면 다음 대화 차례에 중요한 컨텍스트가 부족할 수 있습니다. 이러한 이유로 쓰기 가능한 메모리 시스템에는 지연된 오프라인 업데이트가 아닌 실시간 쓰기가 필요합니다.

(2) 쓰기 속도와 검색 품질 사이의 긴장감

실시간 메모리는 매우 짧은 쓰기 지연 시간을 요구합니다. 동시에 고품질 검색은 잘 구축된 인덱스에 달려 있으며, 인덱스 구축에는 시간이 걸립니다. 쓸 때마다 인덱스를 재구축하는 것은 비용이 너무 많이 들지만, 인덱싱이 지연되면 새로 쓴 데이터가 일시적으로 검색에 보이지 않게 됩니다. 쓰기 가능한 메모리 설계의 핵심은 바로 이 절충점입니다.

(3) 벡터 데이터베이스의 지원 방법

벡터 데이터베이스는 쓰기와 인덱싱을 분리함으로써 이 문제를 해결합니다. 일반적인 해결책은 쓰기를 스트리밍하고 증분 인덱스 빌드를 수행하는 것입니다. Milvus를 예로 들면, 새로운 데이터는 먼저 인메모리 버퍼에 기록되어 시스템이 빈번한 쓰기를 효율적으로 처리할 수 있습니다. 전체 인덱스가 구축되기 전에도 동적 병합 또는 대략적인 검색을 통해 몇 초 내에 버퍼링된 데이터를 쿼리할 수 있습니다.

버퍼가 미리 정의된 임계값에 도달하면 시스템은 일괄적으로 인덱스를 구축하고 이를 유지합니다. 이렇게 하면 실시간 쓰기를 차단하지 않고도 장기 검색 성능이 향상됩니다. 빠른 수집과 느린 인덱스 구축을 분리함으로써 Milvus는 에이전트 메모리에 적합한 쓰기 속도와 검색 품질 간의 실질적인 균형을 달성합니다.

결론

Cowork는 지속적이고 상태 저장적이며 긴 타임라인에 걸쳐 컨텍스트를 전달할 수 있는 새로운 종류의 에이전트를 엿볼 수 있게 해줍니다. 하지만 장기적인 기억은 그림의 절반에 불과하다는 점도 분명해졌습니다. 자율적이고 신뢰할 수 있는 프로덕션 지원 에이전트를 구축하려면 진화하는 대규모 지식 기반에 대한 구조화된 검색이 여전히 필요합니다.

RAG는 세상의 사실을 처리하고, 쓰기 가능한 메모리는 에이전트의 내부 상태를 처리합니다. 그리고 벡터 데이터베이스는 이 두 계층이 함께 작동할 수 있도록 색인, 하이브리드 검색, 확장 가능한 스토리지를 제공하는 교차점에 위치합니다.

장기적으로 운영되는 에이전트가 계속 발전함에 따라 아키텍처는 이러한 하이브리드 설계로 수렴될 가능성이 높습니다. 코워크는 RAG가 없는 세상이 아니라 그 아래에 벡터 데이터베이스로 구동되는 더 풍부한 메모리 스택을 갖춘 에이전트로 향하는 방향에 대한 강력한 신호입니다.

이러한 아이디어를 살펴보고 싶거나 자체 설정에 대한 도움을 받고 싶으시다면 Slack 채널에 참여하여 Milvus 엔지니어와 채팅하세요. 더 많은 실무 지침이 필요하면 언제든지 Milvus 오피스 아워 세션을 예약할 수 있습니다.