AI 맥락 관리의 정답은 결국 같은 곳을 가리킨다

AI코리아24 오늘의 AI 브리핑 관련 기사

3월 15일, 바이트댄스 산하 Volcengine이 AI 에이전트용 오픈소스 컨텍스트 데이터베이스 OpenViking 을 공개했습니다. 같은 주, Anthropic은 Claude Opus 4.6과 Sonnet 4.6의 1M(100만) 토큰 컨텍스트 윈도우 를 정식 출시했습니다. 하나는 맥락을 구조화해서 저장하는 도구이고, 다른 하나는 맥락을 한 번에 더 많이 읽는 능력입니다. 방향은 다르지만 둘 다 같은 문제를 풀려고 합니다. AI는 왜 대화가 길어지면 앞부분을 잊어버리는가.

AI코리아24에서 개발 중인 맥락 주입기 AIKeep24 도 바로 이 문제에서 출발했습니다. 그리고 OpenViking의 아키텍처를 들여다보면, AIKeep24가 독자적으로 도달한 설계와 놀랍도록 닮아 있습니다. 서로 다른 출발점에서 같은 구조에 도착한 것입니다. 이 글에서는 왜 그럴 수밖에 없는지, 그리고 컨텍스트 윈도우가 아무리 커져도 이 문제가 사라지지 않는 이유를 살펴봅니다.

모든 맥락 관리 도구가 같은 결론에 도달하는 이유

AI 대화의 맥락을 관리하려면 결국 세 가지가 필요합니다. 요약, 태깅, 원문 보존 입니다. 이것은 누가 먼저 생각했느냐의 문제가 아니라, 문제의 본질이 그 답을 강제하는 구조입니다.

요약 은 가볍게 맥락을 유지하기 위한 것입니다. AI의 컨텍스트 윈도우는 유한합니다. 대화 원문을 전부 넣으면 금방 한계에 부딪힙니다. 핵심만 압축해서 넣어야 적은 토큰으로 많은 맥락을 전달할 수 있습니다. OpenViking은 이것을 L0(한 줄 요약)과 L1(핵심 개요)으로 구현했습니다. AIKeep24는 청크 요약과 통합 요약, 그리고 체크포인트로 구현했습니다. 이름은 다르지만 하는 일은 같습니다. 긴 내용을 단계별로 압축하는 것입니다.

원문 보존 은 디테일을 유지하기 위한 것입니다. 요약은 편리하지만 반드시 정보를 잃습니다. “정확히 뭐라고 했는지”를 나중에 확인해야 하는 순간이 반드시 옵니다. OpenViking은 이것을 L2(전체 원문)로 두고 필요할 때만 로딩합니다. AIKeep24는 청크별 원문 대화를 D1 데이터베이스에 함께 저장합니다. 둘 다 “요약으로 빠르게 훑되, 원문으로 돌아갈 수 있는 경로를 남겨둔다”는 원칙을 따릅니다.

태깅 은 검색의 편리함을 위한 것입니다. 요약과 원문이 쌓여도 찾을 수 없으면 소용없습니다. 프로젝트명, 토픽, 기술 스택, 날짜 같은 메타데이터를 붙여야 나중에 “그때 그 대화”를 정확히 찾을 수 있습니다. OpenViking은 파일시스템 구조의 디렉토리와 URI로 이것을 해결합니다. AIKeep24는 로컬 LLM이 저장 시점에 자동으로 분류한 프로젝트, 토픽, 기술 스택, 상태 태그로 해결합니다. 접근 방식은 다르지만, “맥락에 구조를 부여해야 검색이 가능하다”는 결론은 동일합니다.

요약으로 가볍게, 원문으로 정확하게, 태깅으로 찾기 쉽게. 이 세 축은 맥락 관리라는 문제를 풀려면 반드시 도달하게 되는 구조입니다. OpenViking이든 AIKeep24든, 혹은 앞으로 나올 어떤 도구든 이 세 가지를 빠뜨리면 실용적으로 작동하지 않습니다.

OpenViking과 AIKeep24의 닮은 점과 다른 점

구조가 닮았다고 해서 같은 도구는 아닙니다. 두 프로젝트의 목적과 대상이 다릅니다.

OpenViking 은 AI 에이전트 시스템을 위한 범용 인프라입니다. OpenClaw 같은 에이전트가 수백 개의 문서, 기억, 스킬을 체계적으로 관리할 수 있도록 가상 파일시스템을 제공합니다. 대규모 엔터프라이즈 환경에서 여러 에이전트가 공유 맥락을 사용하는 시나리오를 겨냥합니다. Python 3.10+, Go 1.22+, GCC 9+ 등의 개발 환경이 필요하고, VLM과 임베딩 모델을 별도로 설정해야 합니다.

AIKeep24 는 개인 사용자의 AI 대화에 특화된 실전 도구입니다. 크롬에서 AI와 대화하면 확장 프로그램이 자동으로 턴을 감지하고, 로컬 LLM(EXAONE 3.5 7.8B)이 20턴 단위로 요약합니다. 사용자가 별도로 설정하거나 명령을 내리지 않아도 대화가 끝나면 자동으로 저장됩니다. 맥락이 필요하면 버튼 하나로 주입합니다.

계층 구조도 비교해볼 수 있습니다. OpenViking의 L0(한 줄 요약)은 AIKeep24의 체크포인트에 해당합니다. L1(핵심 개요)은 통합 요약에, L2(원문)는 청크별 원문 보존에 대응합니다. OpenViking의 Directory Recursive Retrieval은 AIKeep24의 프로젝트별 Browse 기능과 개념적으로 같습니다. 상위 구조에서 출발해 하위로 좁혀가며 원하는 맥락을 찾는 방식입니다.

가장 큰 차이는 접근성입니다. OpenViking은 개발자가 설치하고 설정해야 쓸 수 있는 인프라입니다. AIKeep24는 크롬 확장을 설치하면 바로 작동하는 도구입니다. 같은 문제를 같은 구조로 풀되, 한쪽은 플랫폼 레벨에서, 다른 한쪽은 개인 사용자 레벨에서 접근합니다.

1M 컨텍스트 윈도우가 이 문제를 해결하지 못하는 이유

2026년 3월 13일, Anthropic은 Claude Opus 4.6과 Sonnet 4.6의 1M 토큰 컨텍스트 윈도우를 정식 출시했습니다. 100만 토큰이면 약 75만 단어, A4 용지로 1,500페이지 이상을 한 번에 읽을 수 있는 양입니다. 이전 모델의 200K 토큰에서 5배 늘어난 것입니다.

이 소식을 듣고 “그러면 맥락 관리 도구가 필요 없어지는 거 아닌가?”라고 생각할 수 있습니다. 직관적으로는 맞는 말 같지만, 실제로는 그렇지 않습니다. 이유는 세 가지입니다.

첫째, 컨텍스트 로트(Context Rot) 문제입니다. 컨텍스트 윈도우가 커질수록 모델의 정보 회수 정확도가 떨어지는 현상입니다. Anthropic 스스로가 이 현상을 인정하고 있습니다. “컨텍스트 윈도우의 토큰 수가 증가하면 모델이 정보를 정확히 회수하는 능력이 저하된다”는 것이 공식 설명입니다. 학술적으로는 “Lost in the Middle” 문제로 알려져 있습니다. 모델은 컨텍스트의 처음과 끝에 있는 정보는 잘 기억하지만, 중간에 있는 정보를 놓치는 경향이 있습니다. 100만 토큰을 넣을 수 있다는 것과 100만 토큰을 모두 정확히 활용한다는 것은 전혀 다른 이야기입니다.

둘째, 세션 간 연속성 문제 는 컨텍스트 윈도우 크기와 무관합니다. 아무리 큰 컨텍스트 윈도우도 새 세션을 열면 비어 있습니다. 어제 나눈 대화, 지난주에 내린 결정, 한 달 전에 합의한 방향은 새 대화창에 없습니다. “어제 어디까지 했지?”라는 질문은 컨텍스트 윈도우가 10M이 되어도 해결되지 않습니다. 이것은 저장과 검색의 문제이지 윈도우 크기의 문제가 아닙니다.

셋째, 비용과 속도 문제입니다. 컨텍스트 윈도우를 가득 채울수록 API 호출 비용이 늘고 응답 속도가 느려집니다. 실제 업무에서 매번 100만 토큰을 넣는 것은 비현실적입니다. 필요한 맥락만 골라서 최소한의 토큰으로 주입하는 것이 비용과 성능 모두에서 효율적입니다.

이것이 바로 OpenViking이 L0/L1/L2 계층을 만들고, AIKeep24가 Light/Full 두 단계 주입 모드를 만든 이유입니다. 요약으로 먼저 가볍게 맥락을 잡고, 정말 필요할 때만 원문을 로딩합니다. OpenViking의 자체 보고에 따르면 이 방식으로 토큰 사용량을 6분의 1로 줄이면서 작업 완료율은 오히려 높아졌습니다. 컨텍스트 윈도우가 아무리 커져도 “전부 넣는 것”보다 “구조화해서 필요한 것만 넣는 것”이 더 좋은 결과를 만든다는 뜻입니다.

맥락 관리는 결국 사람의 기억과 같다

사람의 기억도 같은 구조로 작동합니다. 우리는 모든 경험을 원문 그대로 기억하지 않습니다. 중요한 사건은 핵심만 요약해서 장기 기억에 저장하고, 세부 사항은 필요할 때 떠올리려 합니다. “그때 그 프로젝트에서 무슨 결정을 내렸지?”라고 먼저 떠올리고, 구체적인 내용이 필요하면 메모나 문서를 찾아봅니다. 그리고 “그 프로젝트”, “재작년”, “김 과장이랑 같이 한 것” 같은 태그로 기억을 검색합니다.

요약은 장기 기억, 원문은 기록 보관, 태깅은 기억의 인덱스입니다. AI의 맥락 관리가 이 구조에 수렴하는 것은 자연스러운 일입니다. 문제의 본질이 같으면 해결책도 같을 수밖에 없습니다.

OpenViking은 이것을 에이전트 시스템의 인프라로 구현했고, AIKeep24는 개인 사용자의 크롬 확장으로 구현했습니다. 규모와 대상은 다르지만 원리는 동일합니다. 그리고 Claude의 1M 컨텍스트 윈도우는 이 구조를 대체하는 것이 아니라, 이 구조 위에서 더 잘 작동하는 기반입니다. 더 큰 윈도우에 더 잘 구조화된 맥락을 넣을 수 있으니까요.

마무리

AI와 긴 대화를 나누는 모든 사람은 같은 불편을 겪습니다. 대화가 길어지면 AI가 앞부분을 잊고, 새 세션을 열면 처음부터 다시 설명해야 합니다. 이 문제를 풀기 위해 만들어진 도구들이 요약, 원문 보존, 태깅이라는 동일한 세 축에 도달하는 것은 우연이 아닙니다. 문제가 답을 결정하는 것입니다.

컨텍스트 윈도우가 100만이 되든 1,000만이 되든, “무엇을 넣을 것인가”를 결정하는 구조는 여전히 필요합니다. 더 큰 창이 아니라 더 나은 기억이 필요한 시대입니다.

#컨텍스트엔지니어링 #AIKeep24 #OpenViking #Claude #맥락관리 #로컬LLM #바이브코딩 #AI기억