나는 계속 한 가지 의문을 품어왔다. 왜 AI Agent는 이렇게 똑똑한데 기억력은 이렇게 나쁠까?
하루 종일 대화하면서 맥락을 쌓고, 선호도를 알려주고, 모든 것을 설명해줬는데 다음 날 새 session을 열면 전부 잊어버린다. 마치 금붕어 같다. 아니, 금붕어보다 더 심하다. 금붕어는 최소한 같은 어항 안에서 헤엄치기라도 하지만, Agent는 어항이 어디 있는지조차 기억하지 못한다.
이것은 모델이 멍청해서가 아니다. GPT-5든 Claude든 추론 능력은 이미 충분히 강하다. 하지만 추론과 기억은 별개의 문제다. 아무리 뛰어난 천재를 고용하더라도, 그 천재가 매일 사무실에 출근할 때마다 어제 무엇을 했는지, 동료 이름이 뭔지, 프로젝트 진행 상황이 어디까지인지 잊어버린다면 아무 소용이 없다.
ByteDance의 화산엔진 팀도 분명 이 문제에 짜증이 났을 것이다. 그래서 그들은 OpenViking을 만들었다.
벡터 검색의 근본적인 문제
OpenViking 이야기를 하기 전에, 먼저 현재 Agent 메모리를 어떻게 처리하고 있는지 이야기해보자.
주류 방식은 RAG(Retrieval-Augmented Generation)이다. 모든 정보를 작은 조각으로 잘라서 벡터로 변환하고, 벡터 데이터베이스에 저장한 다음, Agent가 필요할 때 의미 검색으로 가져온다. 듣기에는 합리적이지 않은가?
하지만 실제로 돌려보면 문제가 많다.
첫째, 의미 검색은 정확한 검색이 아니다. “지난번 그 고객 견적서"를 물어보면, 벡터 검색은 “고객”, “견적서"와 의미적으로 유사한 모든 것을 다 가져올 수 있다. 3개월 전 것, 다른 프로젝트 것, 심지어 가격 책정 전략을 논의한 회의록까지. 당신이 원하는 것은 하나의 숫자인데, 돌아오는 것은 잡음 더미다.
둘째, 구조가 전부 흩어진다. 제목, 챕터, 계층 관계가 있는 완전한 기술 문서가 RAG에 의해 500자씩 잘린 후에는 이런 구조가 전부 사라진다. Agent가 받는 것은 파편이지, 지식이 아니다.
셋째, Token 폭발이다. 검색이 정확하지 않으니 “만약을 대비해서” 더 많이 가져올 수밖에 없고, 결과적으로 context window가 관련 없는 것들로 가득 차서 정작 중요한 정보는 밀려난다.
이것은 마치 계약서 하나를 찾으려는데, 누군가가 서류함을 전부 흩뜨려서 모든 종이를 하나의 큰 상자에 섞어 넣은 다음 “키워드로 검색하면 된다"고 말하는 것과 같다.
아니, 내가 원하는 것은 잘 정리된 파일 시스템이다.
OpenViking의 접근법: 메모리를 파일 시스템처럼 관리하기
OpenViking이 하는 것을 간단히 말하면 이렇다. 잘게 쪼개지 말고, 디렉토리 구조로 정리하라.
OpenViking은 viking:// 프로토콜을 설계하여 Agent의 모든 컨텍스트를 세 개의 네임스페이스로 나눈다:
viking://resources/— 외부 지식. 문서, API 명세, 참고 자료viking://user/— 사용자 관련. 선호도, 대화 이력, 작업 기록viking://agent/— Agent 자체의 상태. 학습한 내용, 현재 목표, 진행 중인 계획
이것은 데이터를 데이터베이스에 던져 넣는 것이 아니다. Agent를 위해 구조화된 작업 공간을 만들어주는 것이다. 마치 컴퓨터의 폴더처럼 프로젝트 문서는 한 곳에, 개인 설정은 다른 곳에, 참고 자료는 또 다른 곳에 있다. 모든 것을 한데 섞어놓고 검색에 의존하지 않는다.
하지만 진짜 대단한 것은 3단계 로딩 메커니즘이다.
L0 / L1 / L2: 먼저 디렉토리를 보고, 열지 말지 결정한다
이것이 OpenViking의 가장 핵심적인 설계이며, Token을 절약하는 핵심이다.
L0(요약 계층): 디렉토리 구조와 각 항목의 한 줄 요약만 로딩한다. Agent가 보는 것은 “이 폴더 안에 무엇이 있는가"이지, 폴더 안 모든 파일의 전체 내용이 아니다.
L1(개요 계층): Agent가 특정 항목이 관련 있다고 판단하면, 그 항목의 개요를 로딩한다. 대략 몇 단락 정도로, “이것이 내가 찾는 것인지” 판단하기에 충분한 수준이다.
L2(전체 계층): 필요하다고 확인된 후에야 전체 내용을 로딩한다.
이 논리는 사실 당신이 평소에 컴퓨터를 사용하는 방식과 같다. 컴퓨터를 켜자마자 하드 드라이브의 모든 파일을 전부 열지 않는다. 먼저 폴더 이름을 확인하고, 들어가서 무엇이 있는지 살펴본 다음, 목표 파일을 찾으면 그때 연다.
기존 RAG 방식은 이런 것이다: 컴퓨터를 켜자마자 모든 파일 내용을 화면에 쏟아붓고, Ctrl+F로 검색하는 것. Token 사용량이 폭발하는 것이 당연하다.
숫자가 말해준다
ByteDance 팀이 LoCoMo10 벤치마크 테스트에서 얻은 결과이다. 이것은 1,540개의 테스트 케이스를 포함하는 장기 대화 메모리 데이터셋으로, 각 대화는 평균 300턴, 35개의 session에 걸쳐 있다:
- 작업 완료율: 35.65% → 52.08%(+46%)
- Token 소비: 24.6M → 4.3M(-83%)
- Memory-core 모드: 완료율 51.23%, Token은 2.1M으로 압축, 기존 방식 대비 91% 절감
더 잘하면서 더 적게 쓴다. AI 분야에서 이런 경우는 드물다. 보통 성능 향상에는 비용 폭증이 따르기 마련이다.
Token을 83% 적게 쓴다는 것은 무엇을 의미할까? 만약 Agent가 하루에 1,000번의 작업을 수행하고, 매번 20,000개의 Token을 절약한다면, 하루에 2,000만 개의 Token이다. 현재 주류 모델의 가격 기준으로, 하루에 절약되는 API 비용이 상당하다.
자기 진화: Agent가 session을 넘어 학습한다
OpenViking에는 내가 아주 흥미롭다고 느끼는 설계가 하나 더 있다. Agent가 학습한 내용을 viking://agent/ 네임스페이스에 다시 기록할 수 있다.
이것은 Agent가 Session A에서 “이 사용자는 한국어를 선호한다”, “이 프로젝트의 코딩 스타일은 4칸 들여쓰기를 사용한다”, “지난번에 방법 X는 실패했고, 방법 Y가 효과적이었다” 같은 것들을 학습하면, 이 경험이 저장되어 Session B에서 바로 활용할 수 있다는 의미이다.
매번 처음부터 시작하지 않는다. Agent가 경험을 축적하고, 성장한다.
이것은 많은 Agent 팀이 하고 있는 것과 비슷하다. Agent가 session을 넘어 경험을 축적할 수 있게 하여, 매번 처음부터 시작하지 않도록 하는 것이다. 차이점은 예전에는 각자 수작업으로 만들었지만, OpenViking은 이것을 체계화했다는 것이다.
다른 솔루션과의 비교
현재 시장에서 Agent 메모리를 처리하는 솔루션은 대략 세 가지 유형이 있다:
벡터 RAG(Pinecone, Weaviate, Chroma): 의미 검색 방식. 장점은 간단하고 시작하기 쉬우며, 단점은 정확도 부족, 구조 유실, Token 낭비이다.
지식 그래프(Neo4j, 자체 구축): 노드와 엣지의 관계로 지식을 조직한다. 장점은 관계 추론이 강하며, 단점은 구축 비용이 높고, 유지보수가 복잡하며, 전문 지식이 필요하다.
OpenViking(Context Database): 파일 시스템 방식. 장점은 구조가 명확하고, Token 효율이 높으며, 학습 곡선이 낮다. 단점은 새로운 프로젝트라 생태계가 아직 구축 중이라는 것이다.
만능인 솔루션은 없다. 하지만 Agent가 처리해야 하는 것이 구조화된 업무 내용 - 프로젝트 문서, API 명세, 사용자 선호도, 작업 이력 - 이라면, 파일 시스템 논리가 벡터 검색보다 훨씬 직관적이다.
왜 이것이 중요한가
Agent 메모리는 “있으면 좋은” 기능이 아니다. Agent가 장난감에서 생산성 도구로 변하는 핵심이다.
메모리가 없는 Agent와의 모든 대화는 일회성이다. 배경을 반복해서 설명하고, 선호도를 반복해서 알려주고, 프로젝트 맥락을 반복해서 묘사해야 한다. 이것은 자동화가 아니라, 업무량을 늘리는 것이다.
좋은 메모리 시스템을 갖춘 Agent는 당신이 누구인지, 무엇을 하고 있는지, 지난번에 어디까지 했는지, 어떤 방법이 효과적이고 어떤 것이 안 됐는지를 기억한다. 그것은 진정한 협업 파트너가 되며, 말만 잘하는 검색 엔진이 아니다.
OpenViking의 18,000개 이상의 GitHub 스타와 Apache 2.0 라이선스는 커뮤니티가 이것을 얼마나 갈망하는지 보여준다. Agent 메모리는 현재 오픈소스 커뮤니티에서 가장 뜨거운 분야 중 하나이다. 모두가 “금붕어 뇌” Agent에 지쳤기 때문이다.
Agent 관련 개발을 하고 있다면, OpenViking의 아키텍처 설계를 살펴볼 가치가 있다. 반드시 사용할 필요는 없지만, 검색 대신 구조를 활용하고, 전체 로딩 대신 계층적 로딩을 활용하는 파일 시스템 사고방식은 고민해볼 만한 방향이다.
더 잘하면서 더 적게 쓴다. 이것이 좋은 엔지니어링이다.