LLM은 언어를 이해하고 생성하는 능력에서 이미 성능을 입증했죠. 하지만 LLM을 단순한 대화 도구가 아니라 실제로 “일을 하는 존재”, 즉 에이전트로 사용하려는 순간부터 구조적 한계가 있습니다.
작업이 길어질수록 정확도가 떨어지고, 중간 단계에서 사실과 다른 내용을 만들어내며, 여러 작업을 동시에 시키면 앞뒤가 엉키는 현상이 반복됩니다. 이 문제를 해결하기 위해 컨텍스트 윈도우를 키우는 방향으로 달려왔죠. 컨텍스트를 늘리면 더 많은 정보를 기억할 수 있고, 더 복잡한 작업을 처리할 수 있을 것이라는 기대 때문입니다.
이 흐름의 대표적인 사례가 구글의 제미나이입니다. 구글은 제미나이 1.5에서 처음으로 “컨텍스트가 병목”이라는 문제를 정면으로 제기하며 100만 토큰급 롱 컨텍스트 전략을 공개했습니다. 단순한 성능 개선이 아니라, 기존 LLM이 대형 입력을 다루지 못하는 구조적 한계를 해결하려 했습니다. 이후 제미나이 3에 이르러서는 이 전략이 실험이나 옵션이 아니라 기본 설계로 확장되며, 컨텍스트를 키우는 접근이 TPU랑 엮이면서 구글의 핵심 전략임을 확실히 했죠.
반면 오늘 메타가 대규모 금액을 들여 인수한 마누스(Manus)는 정반대의 전략을 보여줍니다. (물론 LLM 회사가 아니라 에이전트 회사지만요) 마누스는 컨텍스트를 키우는 방식이 근본 해법이 아니며, 오히려 컨텍스트를 기억으로 쓰려는 발상 자체가 에이전트의 신뢰성을 무너뜨린다고 봤습니다.
예를 들어 글로벌 AI 반도체 관련 기업 50곳을 조사해 각 기업의 핵심 제품, 기술 특징, 최근 투자 및 파트너십 동향을 정리하고, 근거 URL을 붙여 표로 제출하라는 요청이 있다고 해보죠.
이 과제는 단순히 정보량이 많아서 어려운 것이 아닙니다. 동일한 형식을 유지해야 하고, 진행 상태를 추적해야 하며, 중간 오류를 복구해야 하고, 무엇보다 환각 없이 끝까지 일관성을 유지해야 합니다. 즉, 지식의 문제가 아니라 작업 관리와 기억 구조의 문제입니다.
전통적인 LLM 단독 방식에서는 이 과제가 하나의 컨텍스트 안에서 처리됩니다. 모델은 계획을 세우고, 기업을 하나씩 나열하며, 조사 결과를 대화 컨텍스트에 계속 쌓아갑니다. 초반 5~10개 기업까지는 비교적 안정적입니다.
그러나 기업 수가 늘어날수록 모델은 동시에 여러 부담을 떠안게 됩니다. 목표를 유지해야 하고, 몇 번째 기업까지 진행했는지를 기억해야 하며, 각 항목의 형식을 일관되게 유지해야 합니다. 이 과정에서 컨텍스트는 점점 혼탁해지고, 어느 순간부터 LLM은 실제 조사 대신 그럴듯한 패턴을 채워 넣기 시작합니다.
즉, LLM은 컨텍스트가 길어질수록 어텐션 계산의 복잡도가 증가하고 중요한 정보에 집중하지 못하는 니들 인 어 헤이스택(Needle In A Haystack) 문제가 발생합니다.
앞부분은 비교적 정확하고, 뒷부분은 불안정해지는 이유입니다. 사용자는 결과를 받아도 검증을 해야 하고, 그 순간 자동화의 이점은 사라집니다.
LLM은 내부 연산 측면에서는 극도로 병렬적입니다. 어텐션 계산과 행렬 연산은 GPU 상에서 대규모 병렬로 수행됩니다. 그러나 하나의 생각을 빠르게 계산하는 병렬성이죠.
“기업 50개 조사”에서 필요한 병렬성은 여러 생각을 동시에 굴리는 병렬성, 즉 작업 병렬성입니다. LLM은 단일 컨텍스트, 단일 주의 흐름을 유지하는 구조이기 때문에 여러 독립 작업을 안정적으로 병렬 처리할 수 없습니다.
마누스 는 이 문제를 컨텍스트 확장으로 풀지 않았습니다. 마누스 의 출발점은 컨텍스트를 기억으로 보지 않는 데 있습니다. 컨텍스트는 순간적인 사고를 위한 초고속 작업 공간이며, 반도체 구조로 비유하면 SRAM에 가깝습니다. 작고 빠르지만, 오래 유지하거나 방대한 정보를 담기에는 적합하지 않은 공간입니다.
마누스 방식은 개별 워커 에이전트의 컨텍스트를 수천 토큰 이내의 짧은 구간으로 제한합니다. 이렇게 하면 GPU 내부 연산 시 KV 캐시(Key-Value Cache)의 크기가 작게 유지되어 연산 효율이 극대화되고, 모델은 주어진 아주 짧은 정보 안에서만 추론하므로 결과의 정확도와 출력 형식의 일관성이 비약적으로 높아집니다. 각 작업이 끝나면 해당 세션의 KV 캐시를 즉시 폐기하여 자원 낭비를 막습니다.
중앙 컨트롤러가 전체 과제를 50개의 하위 태스크로 분해하고, 각 태스크를 50개 워커 에이전트에 배분합니다. 워커는 매번 비어 있는 컨텍스트에서 단 하나의 기업만 조사합니다. 작업이 끝나면 워커의 컨텍스트는 폐기됩니다. 생각은 사라지고, 결과만 남습니다.
그 결과는 파일 시스템과 데이터베이스에 저장됩니다. 각 기업의 조사 결과는 개별 파일로 남고, 근거 URL과 요약, 오류 기록도 함께 저장됩니다. 원문이 필요하면 웹페이지 전체를 파일로 저장해 두고, 컨텍스트에는 파일 경로만 유지합니다. 느리지만 용량이 크고, 작업이 끝난 뒤에도 사라지지 않는 기억입니다. 중앙 컨트롤러는 어떤 파일을 언제 읽고 쓸지를 결정하는 메모리 컨트롤러 역할을 합니다. 워커는 장기 기억을 직접 관리하지 않고, 필요한 부분만 전달받아 처리합니다. 이 구조 덕분에 멀티작업이 가능해지고, 실패가 발생해도 해당 워커만 재실행하면 됩니다.
겉보기에는 이 방식이 느려 보이죠. 워커를 생성하고, 파일을 읽고 쓰며, 컨트롤러를 거치는 오버헤드가 있기 때문입니다. 그러나 실제 체감 속도는 종종 더 빠릅니다.
첫째, 병렬성이 확보됩니다. 50개 기업 조사는 본질적으로 병렬 가능한 작업이며, 워커 구조는 이를 그대로 활용합니다.
둘째, LLM 추론 자체가 파일 I/O보다 훨씬 느린 경우가 많아 파일 접근이 병목이 되지 않습니다.
셋째, 컨텍스트가 짧아져 각 추론 비용이 감소합니다.
넷째, 실패 재시도가 크게 줄어듭니다. 단독 LLM처럼 처음부터 다시 시작할 필요가 없기 때문입니다. 마누스가 빠르게 느껴지는 이유는 연산 속도가 빨라서가 아니라, 불필요한 재사고를 제거했기 때문입니다.
그렇다면 구글의 전략은 마누스와 완전히 반대일까요. 그렇지 않습니다. 구글의 제미나이 전략은 1.5에서 시작해 3에서 더욱 분명해진 “롱 컨텍스트” 노선입니다. 멀티태스크 운영 문제를 해결하기 위한 선택이라기보다, 대형 입력과 전역 문맥을 한 번에 이해해야 하는 문제를 풀기 위한 선택입니다. 코드 저장소 전체를 읽거나, 수백 페이지 문서 묶음을 분석하거나, 긴 영상과 오디오를 통째로 이해하는 과제는 잘개 쪼개는 순간 관계가 깨질 수 있습니다.
이런 문제에서는 요약이나 분해보다 긴 컨텍스트가 정직한 해법이 됩니다. 제미나이 1.5에서 롱 컨텍스트가 도입되고, 제미나이 3에서 그 크기와 활용 범위가 더 확장된 이유가 여기에 있습니다.
그래서 마누스와 제미나이는 같은 문제에 대한 다른 답이 아니라, 다른 문제 공간을 겨냥한 서로 다른 전략입니다. 마누스는 멀티태스크, 장기 프로젝트, 오류 복구, 근거 축적처럼 운영이 핵심인 문제를 겨냥합니다.
제미나이는 쪼개면 안 되는 거대한 입력과 전역 문맥 이해를 겨냥합니다. 컨텍스트를 키우는 전략은 끝난 것이 아니라, 특정 문제 영역에서 계속 확장되고 있습니다. 다만 모든 문제의 해답은 아니라는 얘기죠. RAG는? 그건 다음에..
이 논의를 반도체 메모리 계층으로 정리하면 명확해집니다. LLM의 컨텍스트는 SRAM입니다. 빠르지만 작고 휘발적입니다. 마누스는 이 SRAM을 키우지 않고 복제해 병렬로 사용하며, 파일과 DB라는 SSD 계층에 기억을 외부화합니다. 반면 구글의 전략은, 가능한 한 큰 입력을 SRAM에 한 번에 올려 전역적으로 처리하려는 접근입니다. 어느 쪽이 옳다기보다, 어떤 문제를 풀 것인가에 따라 선택이 달라집니다.
마누스의 방식은 인지적 부하를 구조적으로 분산하여 작업의 무결성을 확보하는 것이고, 제미나이의 방식은 인지의 폭을 물리적으로 확장하여 정보의 통합성을 유지하는 것입니다. 이는 결국 분산 처리 시스템(Distributed System)과 중앙 집중형 고성능 시스템(Monolithic High-performance System)의 대결로도 볼 수 있습니다.
결론은 명확합니다. AI 에이전트의 미래는 단순히 모델의 크기를 키우거나 컨텍스트의 길이를 늘리는 것만으로 완성되지 않습니다. 핵심은 실시간 사고 공간(Context)과 영구적 정보 저장소(Storage), 그리고 이 둘을 유기적으로 조율하는 Controller 을 어떻게 설계하느냐에 달려 있습니다.
마누스는 분산 배치하고 상태 관리를 외부화하는 운영체제형 해법, 즉 컨텍스트 엔지니어링을 제시했고, 제미나이는 분절할 수 없는 거대 맥락을 한 번에 소화하는 컨텍스트 확장을 택한겁니다.
정교한 운영이 필요한 루틴한 업무나 50개 기업 조사 같은 대규모 리서치는 마누스식의 컨텍스트 엔지니어링으로 처리하고, 전사적인 전략 수립이나 고난도의 법률,기술 분석처럼 통합적 맥랏과 시야가 필요한 과업은 제미나이식의 컨텍스트 확장으로 풀어내는 하이브리드로 흘러가겠죠
