메타에 3억 달러에 인수된 Manus, LangChain과 함께 에이전트 개발 핵심 원칙을 공개하다

메타가 Manus를 3억 달러에 인수한 소식이 화제지만, 진짜 중요한 건 Manus가 LangChain과의 공동 발표에서 밝힌 내용입니다. 이 발표는 실제로 작동하는 AI 에이전트를 만들기 위한 핵심 원칙들을 낱낱이 공개했고, 스타트업들이 흔히 저지르는 실수와 실제로 성과를 내는 전략 사이의 명확한 경계를 그었습니다.

컨텍스트 부패의 역설

에이전트에는 도구가 필요합니다. 도구가 많을수록 더 많은 일을 할 수 있죠. 하지만 함정이 있습니다. 에이전트가 사용하는 도구가 늘어날수록 컨텍스트도 비대해지고, 그 결과 성능이 떨어집니다.

Manus는 이를 **컨텍스트 부패(Context Rot)**라고 부릅니다. 에이전트 개발의 핵심에 자리한 역설입니다. 에이전트를 더 강력하게 만드는 바로 그것이, 동시에 에이전트를 더 멍청하게 만듭니다.

해법은 컨텍스트 엔지니어링입니다. 다음 단계에 필요한 정보만 모델에게 보여주고, 나머지는 철저히 배제하는 것입니다.

Manus가 제시한 6가지 구체적인 기법은 다음과 같습니다.

• Offload(오프로드) - 토큰을 많이 차지하는 데이터는 컨텍스트에 두지 말고 파일 시스템으로 옮긴다
• Reduce(축소) - 더 이상 쓸모없는 정보는 적극적으로 제거한다
• Compact(압축) - 복구 가능한 데이터는 가역적으로 압축한다 (예: 파일 내용은 제거하되 경로는 유지)
• Summarize(요약) - 정보를 비가역적으로 압축하되, 반드시 구조화된 스키마를 통해 처리한다
• Retrieve(검색) - 필요할 때 검색을 통해 정보를 제공한다
• Isolate(격리) - 각자 독립된 컨텍스트를 가진 서브에이전트를 활용한다

핵심 통찰은 이것입니다. 컨텍스트 관리는 있으면 좋은 최적화가 아닙니다. 에이전트가 확장될 수 있는지, 아니면 자기 자신의 무게에 짓눌려 무너지는지를 결정하는 핵심 아키텍처 설계 판단입니다.

Product-Market Fit 전에 파인튜닝하지 마라

Manus가 지적한 가장 흔한 스타트업 실수 중 하나는 제품-시장 적합성(Product-Market Fit)을 찾기 전에 특화 모델을 만드는 것입니다.

논리는 간단합니다. 범용 모델에 강력한 컨텍스트 엔지니어링을 결합하면 훨씬 빠른 반복 주기가 가능합니다. 초기에 파인튜닝을 하면, 아직 검증되지 않은 사용자 행동에 대한 가정에 스스로를 가두게 됩니다.

더 날카로운 포인트는 이겁니다. 모델을 개선할 수 있는 속도가 제품 혁신 속도의 상한선을 결정합니다. 파인튜닝은 그 주기를 느리게 만듭니다. 컨텍스트 엔지니어링은 빠르게 유지합니다.

파인튜닝은 제품이 작동한다는 것을 증명한 후에 하세요. 그 전에는 가장 비싼 형태의 조기 최적화일 뿐입니다.

멀티 에이전트 패턴: 두 가지 근본적 접근법

Manus는 서로 다른 유형의 작업에 적합한 두 가지 근본적인 멀티 에이전트 패턴을 식별했습니다.

커뮤니케이팅 패턴(Communicating Pattern) - 서브에이전트가 빈 슬레이트에서 시작합니다. 메인 에이전트가 집중된 요청을 보내고, 서브에이전트는 독립적으로 처리한 뒤 결과를 반환합니다. 코드 검색이나 데이터 조회처럼 컨텍스트가 적게 필요하고 병렬화가 가능한 작업에 적합합니다.

공유 메모리 패턴(Shared Memory Pattern) - 서브에이전트들이 전체 대화 이력을 공유하되, 서로 다른 프롬프트와 도구 세트로 동작합니다. 각 단계가 이전 결과 위에 쌓이는 심층 리서치처럼 복잡하고 상호 의존적인 작업에 적합합니다.

둘 사이의 선택은 능력의 문제가 아니라 컨텍스트 요구 사항의 문제입니다. 하위 작업이 자체 완결적이면 커뮤니케이팅 패턴을 쓰고, 전체 그림이 필요하면 공유 메모리 패턴을 쓰면 됩니다. 이 판단을 잘못하면 불필요한 컨텍스트에 토큰을 낭비하거나, 에이전트에게 필요한 정보를 주지 않는 결과를 초래합니다.

도구 과부하를 막는 3계층 액션 스페이스

도구가 너무 많으면 모델이 혼란에 빠집니다. Manus의 해법은 모델이 한 시점에 볼 수 있는 범위를 제한하는 계층형 아키텍처입니다.

원자 계층(Atomic Layer) - 10~20개의 핵심 기능: read, write, shell, browser. 항상 사용 가능하며 모델이 직접 사용합니다.

샌드박스 유틸리티(Sandbox Utilities) - 변환기, 린터, 포매터 같은 사전 설치된 CLI 도구들. 전용 도구로 노출하지 않고, 모델이 셸을 통해 호출합니다.

패키지 및 API(Packages and APIs) - 사전 인증된 API 키가 포함된 Python 스크립트. 전체 API 표면을 모델에게 노출하지 않으면서 외부 서비스와의 상호작용을 처리합니다.

이 계층 구조 덕분에 모델의 의사결정 공간이 관리 가능한 수준으로 유지됩니다. 200개의 도구 중에서 고르는 대신, 15개 핵심 액션에서 선택하고 나머지는 셸로 위임합니다. 결과적으로 도구 선택의 정확도가 높아지고, 혼동이나 환각에 의한 도구 호출이 줄어듭니다.

평가 지표의 재설계

GAIA 같은 공개 벤치마크는 실제 사용자의 선호를 반영하지 못합니다. Manus의 입장은 명확합니다. 골드 스탠다드는 완료된 세션에 대한 사용자 평점이며, 1점에서 5점으로 평가합니다.

세 가지 평가 원칙이 도출되었습니다.

1. Q&A 테스트보다 실행 테스트 - 에이전트가 샌드박스에서 실제로 작업을 완료할 수 있는가? 그것이 작업에 대한 질문에 답할 수 있는지보다 중요합니다.
2. 주관적 품질에는 사람의 리뷰가 필요 - 시각적 완성도, 톤, 전체적인 일관성은 자동으로 점수를 매길 수 없습니다. 사람이 직접 결과물을 확인해야 합니다.
3. 벤치마크 점수는 필요하지만 충분하지 않다 - 기본 역량은 증명할 수 있습니다. 제품이 좋다는 것까지 증명하지는 못합니다.

핵심 교훈

오버엔지니어링이 적이다.

가장 큰 성능 향상은 복잡성을 더하는 데서 오는 게 아니라, 복잡성을 제거하는 데서 옵니다. 모델이 할 일을 더 어렵게 만들지 마세요. 더 쉽게 만드세요.

이것이 메타가 Manus에 3억 달러를 지불한 이유일 겁니다. 화려한 기능 때문이 아니라, 본질에 집중하는 설계 철학 때문입니다. 불필요한 것을 걷어내고, 컨텍스트를 철저하게 관리하고, 모델이 자기 자신의 상태에 빠져 허우적대는 대신 작업에 집중할 수 있는 시스템을 만드는 것.

프로덕션에서 살아남는 에이전트는 가장 많은 기능을 가진 에이전트가 아닙니다. 각 기능 하나하나가 제 역할을 하는 에이전트입니다.