벡터 DB 회사 Chroma가 20B 검색 모델을 직접 만든 이유

RAG(Retrieval-Augmented Generation)가 정말 죽었을까요? 벡터 데이터베이스 스타트업 Chroma의 CEO Jeff Huber는 그렇다고 말합니다. 정확히는, 우리가 알고 있는 형태의 RAG가 죽었다는 것입니다. 2026년 3월 26일, Chroma는 Context-1이라는 20B 파라미터 검색 에이전트 모델을 Apache 2.0 라이선스로 공개했습니다. 벡터 DB 인프라를 만들던 회사가 직접 검색 모델을 만들어 오픈소스로 풀었습니다.

이 발표가 흥미로운 이유는 기술 자체보다 그 뒤에 깔린 논리에 있습니다. Chroma는 Context Rot이라는 문제를 정의하고, 이를 해결하기 위해 "검색"의 개념 자체를 재정의했습니다. 단순히 문서를 찾아오는 것이 아니라, 찾아온 문서를 스스로 검증하고, 불필요한 것을 제거하는 자기편집(self-editing) 메커니즘을 제안합니다. 그리고 이 모든 과정을 프론티어 모델이 아닌 소형 전문 모델에게 맡기면, 비용은 25배 줄어들고 속도는 10배 빨라진다는 것이 핵심 주장입니다.

Context Rot, 긴 컨텍스트의 불편한 진실

RAG의 작동 원리는 단순합니다. 사용자 질문과 관련된 문서 조각(chunk)을 검색하고, 이를 LLM의 컨텍스트 윈도우에 넣어 답변을 생성합니다. 문제는 이 "넣기"에 있습니다.

Chroma가 자체 연구에서 정의한 Context Rot은 LLM의 컨텍스트 윈도우에 정보가 누적될수록 성능이 하락하는 현상입니다. 128K, 200K 토큰의 긴 컨텍스트를 자랑하는 최신 모델들도 이 문제에서 자유롭지 않습니다. 컨텍스트가 길어지면 주의력(attention)이 분산되고, 관련 없는 문서가 섞이면 할루시네이션이 증가합니다.

이 문제는 이미 여러 연구에서 확인된 바 있습니다. "Lost in the Middle" 현상(컨텍스트 중간에 있는 정보를 놓치는 문제)은 2023년부터 지적되어 왔고, 컨텍스트 윈도우가 커진다고 해서 해결되지 않았습니다. 오히려 더 많은 문서를 넣을 수 있게 되면서, 더 많은 노이즈가 유입되는 역설적 상황이 발생했습니다.

기존 RAG 파이프라인의 한계를 정리하면 이렇습니다.

• 단일 패스 검색: 한 번 검색해서 상위 K개 문서를 가져오면 끝. 검색 결과의 품질을 검증하는 과정이 없습니다
• 리랭킹의 한계: Cohere Rerank, Voyage 같은 리랭커가 순서를 재조정하지만, 근본적으로 "관련 없는 문서를 제거"하지는 않습니다
• 컨텍스트 오염: 관련성이 낮은 문서가 컨텍스트에 포함되면 LLM의 추론 품질이 저하됩니다

이런 배경에서 에이전틱 RAG(Agentic RAG) 라는 새로운 접근이 부상하고 있었습니다. Self-RAG, RAPTOR, LlamaIndex의 Agentic Retrieval 등이 대표적입니다. 검색을 한 번에 끝내는 것이 아니라, 여러 차례 반복하며 결과를 개선하는 방식입니다. Chroma의 Context-1은 이 흐름의 연장선에 있으면서, 한 가지 독특한 요소를 추가합니다. 바로 프루닝(pruning), 즉 자기편집입니다.

Context-1의 자기편집 메커니즘

Context-1은 단순한 리랭커나 임베딩 모델이 아닙니다. 4가지 도구를 사용하는 검색 에이전트입니다.

네 가지 도구는 각각 다른 역할을 수행합니다.

• search_corpus: 코퍼스에서 관련 문서를 시맨틱 검색합니다. 전통적인 RAG의 검색 단계와 유사합니다
• read_document: 검색된 문서를 전체적으로 읽어 깊이 이해합니다. 단순 chunk 매칭이 아닌 문서 수준의 이해를 수행합니다
• grep_corpus: 키워드 기반으로 코퍼스를 세밀하게 탐색합니다. 시맨틱 검색이 놓칠 수 있는 정확한 매칭을 보완합니다
• prune_chunks: 가장 핵심적인 도구입니다. 수집된 문서 중 불필요한 것을 자동으로 제거합니다

기존 RAG가 "더 많이 가져오기"에 집중했다면, Context-1의 핵심은 "정확하게 덜어내기" 에 있습니다. prune_chunks는 각 문서 조각의 관련성을 평가하고, 질문에 답하는 데 필요하지 않은 것을 컨텍스트에서 제거합니다. Chroma가 보고한 프루닝 정확도는 94% 입니다. 100개의 문서 조각 중 관련 없는 것을 제거할 때, 94%의 확률로 올바른 판단을 내린다는 의미입니다.

이 자기편집 과정은 한 번으로 끝나지 않습니다. Context-1은 검색 → 읽기 → 탐색 → 프루닝의 과정을 여러 차례 반복하며, 매 반복마다 컨텍스트의 신호 대 잡음비(signal-to-noise ratio)를 개선합니다. 최종적으로 프론티어 LLM에게 전달되는 컨텍스트는 노이즈가 제거된, 고순도의 정보만 남게 됩니다.

아키텍처와 성능, 숫자가 말하는 것

Context-1의 기술적 세부사항도 주목할 만합니다.

모델 규모: 20B 파라미터의 Mixture-of-Experts(MoE) 아키텍처로, 실제 추론 시 활성화되는 파라미터는 3.6B에 불과합니다. 이는 MXFP4 양자화를 적용하면 16GB 메모리의 로컬 환경에서 구동할 수 있다는 의미입니다. MacBook Pro나 NVIDIA RTX 4090 한 장이면 충분합니다.

기반 모델: OpenAI의 gpt-oss-20b를 베이스로, LoRA(Low-Rank Adaptation) 파인튜닝과 CISPO(Contrastive Improvement through Self-Play Optimization) 라는 강화학습 기법을 적용했습니다. CISPO는 모델이 자신의 이전 검색 결과와 경쟁하며 개선하는 자기 대국(self-play) 방식입니다.

성능: Chroma의 자체 벤치마크에 따르면, Context-1은 Opus 4.5 대비 10배 빠르고 25배 저렴합니다. 동일한 검색 작업에서 Opus 4.5가 278.5초 걸리는 것을 Context-1은 28.8초에 완료합니다. 비용 차이는 파라미터 규모의 차이에서 옵니다. 프론티어 모델의 수조 개 파라미터 대신 3.6B 활성 파라미터만 사용하기 때문입니다.

오픈소스: Apache 2.0 라이선스로 HuggingFace에 가중치가 공개되어 있습니다. 누구나 다운로드하여 사용할 수 있으며, 상업적 이용에도 제한이 없습니다.

다만 한 가지 중요한 제한사항이 있습니다. Context-1 모델 자체는 공개되었지만, 이 모델을 실행하는 에이전트 하네스(agent harness) 는 아직 비공개입니다. 에이전트 하네스란 네 가지 도구를 어떤 순서로, 어떤 조건에서 호출할지를 결정하는 오케스트레이션 레이어입니다. 모델 가중치만으로는 Chroma가 보고한 성능을 독립적으로 재현하기 어렵습니다. HuggingFace 다운로드 수도 발표 직후 기준 2건에 불과하여, 커뮤니티의 독립 검증은 아직 이루어지지 않은 상태입니다.

벡터 DB의 수직 통합, 왜 인프라 회사가 모델을 만들었나

Context-1의 발표에서 가장 흥미로운 지점은 기술 자체가 아니라 누가 만들었는가입니다. Chroma는 벡터 데이터베이스 회사입니다. 2022년에 설립되어 GitHub 스타 21K를 확보한, 오픈소스 벡터 DB 시장에서 강력한 존재감을 가진 스타트업입니다. 밸류에이션은 $75M 수준입니다.

벡터 DB는 RAG 파이프라인에서 "저장소" 역할을 합니다. 임베딩된 벡터를 저장하고, 유사도 검색을 수행하는 인프라입니다. 그런 인프라 회사가 왜 직접 검색 모델을 만들었을까요?

Jeff Huber가 제시한 비전은 이렇습니다.

"RAG는 죽었습니다. Context Engineering이 왕입니다."

(원문: "RAG is Dead, Context Engineering is King")

이 선언의 맥락을 이해하려면 벡터 DB 시장의 경쟁 구도를 봐야 합니다. Pinecone, Weaviate, Milvus, Qdrant 등 벡터 DB 회사들은 모두 비슷한 가치를 제공합니다. 벡터를 저장하고, 빠르게 검색합니다. 차별화가 점점 어려워지는 시장입니다.

Chroma가 Context-1을 통해 시도하는 것은 수직 통합입니다. 단순한 벡터 저장소에서, 저장 + 검색 + 정제까지 아우르는 검색 인텔리전스 플랫폼으로의 전환입니다. 벡터 DB 시장에서 자체 검색 모델을 보유한 회사는 Chroma가 유일합니다.

이는 데이터베이스 산업의 역사에서 반복된 패턴이기도 합니다. PostgreSQL이 단순 관계형 DB에서 JSON, 전문 검색, 지리 정보까지 통합한 것처럼, 벡터 DB도 "검색 품질"이라는 상위 레이어를 흡수하려는 움직임으로 볼 수 있습니다.

하지만 이 전략에는 명확한 리스크도 있습니다. 인프라 회사가 모델까지 만든다는 것은 사업 범위가 크게 확장된다는 의미이고, $75M 밸류에이션의 스타트업이 양쪽을 모두 잘 해낼 수 있을지는 검증이 필요합니다.

에이전트 시대의 검색 분업, 실무에 미치는 영향

Context-1이 제안하는 아키텍처는 실무적으로 흥미로운 패턴을 제시합니다. 검색은 소형 전문 모델에게, 추론은 프론티어 모델에게 맡기는 분업 구조입니다.

현재 많은 에이전트 시스템은 GPT-5.2, Claude Opus 4.5 같은 프론티어 모델에게 검색과 추론을 모두 맡깁니다. 프론티어 모델이 직접 문서를 읽고, 관련성을 판단하고, 답변을 생성합니다. 이 방식은 강력하지만 비용이 높고 느립니다. 프론티어 모델의 토큰 단가로 검색이라는 "서브 태스크"를 처리하는 것은 낭비입니다.

Context-1의 분업 패턴은 이렇습니다.

1. 사용자 질문이 들어오면, Context-1(3.6B 활성 파라미터) 이 검색 에이전트로서 문서를 탐색하고 프루닝합니다
2. 정제된 고품질 컨텍스트만 프론티어 모델에게 전달합니다
3. 프론티어 모델은 노이즈 없는 컨텍스트로 추론에만 집중합니다

이 구조의 경제적 이점은 명확합니다. 검색 단계에서 프론티어 모델 API를 호출하지 않으므로, 에이전트의 검색 비용이 25배 절감됩니다. 로컬에서 16GB 메모리로 구동할 수 있으므로, API 비용이 아예 들지 않는 시나리오도 가능합니다.

이런 분업 패턴은 AI 에이전트의 비용 구조를 근본적으로 바꿀 수 있습니다. 현재 에이전트 시스템의 가장 큰 병목은 비용입니다. 복잡한 작업을 수행하는 에이전트가 프론티어 모델 API를 수십, 수백 번 호출하면 비용이 빠르게 누적됩니다. 검색처럼 반복적이고 비용 효율이 중요한 작업을 소형 모델로 분리할 수 있다면, 에이전트의 실용적 활용 범위가 넓어집니다.

코드 수준에서 Context-1을 활용하는 패턴은 아직 구체화되지 않았습니다. 에이전트 하네스가 비공개이기 때문입니다. 하지만 Chroma의 기존 Python SDK와의 통합을 고려하면, 다음과 같은 워크플로우가 예상됩니다.

# 예상되는 Context-1 활용 패턴 (에이전트 하네스 공개 시)
# 1단계: Context-1이 검색 에이전트로 동작
refined_context = context1.search(
    query="2026년 AI 규제 동향",
    corpus=chroma_collection,
    max_iterations=5,     # 검색-프루닝 반복 횟수
    prune_threshold=0.8   # 프루닝 기준 점수
)

# 2단계: 정제된 컨텍스트를 프론티어 모델에 전달
response = frontier_llm.generate(
    system="주어진 컨텍스트를 기반으로 답변하세요.",
    context=refined_context,  # 노이즈 제거된 고순도 컨텍스트
    query="2026년 AI 규제 동향을 요약해주세요."
)

이 코드는 실제 API가 아닌 예상 패턴입니다. 하지만 "검색 에이전트가 컨텍스트를 정제하고, 프론티어 모델은 추론에만 집중한다"는 분업의 핵심 아이디어를 보여줍니다.

커뮤니티 반응, 기대와 회의 사이

Context-1 발표에 대한 커뮤니티 반응은 기대와 회의가 혼재합니다.

Hacker News에서는 Context Rot 연구 자체에 대한 공감이 다수를 차지했습니다. 긴 컨텍스트에서 LLM 성능이 하락하는 경험은 많은 개발자들이 체감하고 있는 문제이기 때문입니다. 실무에서 RAG 파이프라인을 운영하면서 "문서를 많이 넣을수록 답변 품질이 오히려 떨어진다"는 경험담이 여러 건 공유되었습니다.

자기편집 메커니즘에 대해서도 긍정적 반응이 있었습니다. 기존 리랭킹이 "순서를 바꾸는" 소극적 접근이었다면, 프루닝은 "불필요한 것을 제거하는" 적극적 접근이라는 점에서 직관적으로 납득된다는 의견입니다.

그러나 회의적인 시각도 만만치 않습니다. 가장 많이 제기된 우려는 이해관계 충돌입니다.

Chroma는 벡터 DB를 파는 회사입니다. "긴 컨텍스트가 문제다"라고 주장하는 것은 결국 "벡터 DB를 써야 한다"는 논리로 이어집니다. 자기 제품을 팔기 위해 문제를 과장하는 것은 아닌지 의문입니다.

이 지적은 합리적입니다. Context Rot은 실제로 존재하는 문제이지만, Chroma가 이를 강조하는 데는 사업적 동기가 있습니다. 벡터 DB + 검색 모델 조합이 순수한 긴 컨텍스트 접근보다 우월하다는 내러티브는 Chroma의 비즈니스 모델과 정확히 일치합니다.

독립 검증 부재도 주요 우려입니다. 성능 수치(10배 빠름, 25배 저렴, 프루닝 정확도 94%)는 모두 Chroma의 자체 벤치마크에서 나왔습니다. 에이전트 하네스가 비공개인 상태에서 외부에서 이 수치를 재현할 방법이 없습니다. 학술 논문도 아직 공개되지 않았습니다.

HuggingFace에서의 다운로드 수가 발표 직후 기준 2건에 불과하다는 점도 언급되었습니다. 물론 발표 직후이므로 이 수치 자체에 큰 의미를 부여하기는 어렵지만, 커뮤니티의 실질적 관심이 얼마나 이어질지는 두고 볼 필요가 있습니다.

그럼에도 Apache 2.0 오픈소스 공개는 긍정적으로 평가됩니다. 모델 가중치가 공개되어 있으므로, 에이전트 하네스가 공개되거나 커뮤니티가 자체적으로 구현하면 독립 검증이 가능해집니다.

경쟁 구도에서 Context-1의 위치

Context-1의 포지셔닝을 이해하려면, 이것이 기존 리랭커와 다른 카테고리라는 점을 짚어야 합니다.

Cohere Rerank, Voyage Reranker 같은 도구는 검색 결과의 순서를 재조정합니다. 주어진 검색 결과 내에서 관련성이 높은 것을 상위로 올리는 역할입니다. 이들은 "순서"를 개선하지만, 근본적으로 단일 패스 검색의 틀 안에서 동작합니다.

Context-1은 자신을 "검색 에이전트" 로 규정합니다. 순서를 바꾸는 것이 아니라, 여러 번 검색하고, 읽고, 탐색하고, 제거하는 능동적 과정을 수행합니다. 기존 리랭커와는 카테고리 자체가 다릅니다.

에이전틱 RAG 생태계에서의 위치도 주목할 만합니다. Self-RAG는 LLM이 자신의 검색 결과를 반성(reflect)하는 방식이지만, 프론티어 모델을 사용하므로 비용이 높습니다. RAPTOR는 문서를 계층적으로 요약하는 접근이지만, 사전 처리에 시간이 걸립니다. Context-1은 소형 전문 모델 + 실시간 프루닝이라는 독특한 조합으로 이 생태계에서 자리를 잡으려 합니다.

전망, 검색 에이전트가 표준이 되는 세계

Context-1의 성공 여부와 관계없이, 이 발표가 가리키는 방향은 의미심장합니다.

첫째, 에이전트 내부의 전문화된 분업이 가속화될 것입니다. 프론티어 모델 하나가 모든 작업을 수행하는 구조에서, 각 서브 태스크에 최적화된 소형 모델들이 협력하는 구조로의 전환입니다. 검색은 검색 전문 모델, 코드 생성은 코드 전문 모델, 최종 추론은 프론티어 모델이 담당하는 식입니다. 이 패턴이 확산되면 에이전트의 총 비용이 크게 줄어들 수 있습니다.

둘째, "컨텍스트 품질"이 새로운 경쟁 축이 됩니다. 지금까지 RAG의 경쟁은 "더 좋은 임베딩", "더 빠른 벡터 검색"에 집중되어 있었습니다. Context-1은 검색 이후의 단계, 즉 검색 결과를 정제하는 과정에서의 경쟁을 열었습니다. "얼마나 잘 찾느냐"에서 "얼마나 잘 걸러내느냐"로 초점이 이동하는 것입니다.

셋째, 벡터 DB 시장의 경쟁 구도가 달라질 수 있습니다. Chroma가 검색 모델까지 수직 통합하는 데 성공한다면, 다른 벡터 DB 회사들도 비슷한 전략을 취할 수밖에 없습니다. 인프라 회사들이 모델 레이어까지 올라오고, 모델 회사들이 인프라 레이어까지 내려오는 수렴 현상이 나타날 수 있습니다.

물론 Context-1의 앞에는 넘어야 할 산이 있습니다. 에이전트 하네스의 공개, 독립적인 벤치마크 검증, 그리고 실제 프로덕션 환경에서의 안정성 입증이 필요합니다. $75M 밸류에이션의 스타트업이 벡터 DB와 검색 모델 두 가지를 동시에 발전시킬 자원이 충분한지도 지켜볼 문제입니다.

그러나 한 가지는 분명합니다. "문서를 검색해서 컨텍스트에 넣는다"는 RAG의 기본 공식은 변하고 있습니다. 검색이 수동적 조회에서 능동적 탐색과 정제로 진화하는 것은 시간 문제입니다. Chroma의 Context-1이 그 최종 답인지는 아직 모르지만, 올바른 질문을 던지고 있다는 점은 부정하기 어렵습니다.

RAG가 죽었는지의 여부보다 더 중요한 질문은 이것일 수 있습니다. 컨텍스트의 양이 아니라 질을 관리하는 시스템을 우리는 얼마나 빨리 갖출 수 있을까요?