컨텍스트 엔지니어링 in Manus
TMT왜 컨텍스트 엔지니어링인가
이번 주 초, 저는 Manus 공동 창업자 겸 CSO Yichao “Peak” Ji와 웨비나를 진행했습니다. 영상은 여기, 제 슬라이드는 여기, Peak의 슬라이드는 여기에서 보실 수 있습니다. 아래는 제 노트입니다.
Anthropic은 에이전트를 LLM이 자신의 프로세스와 도구 사용을 스스로 지휘하며, 작업을 수행하는 방식을 통제하는 시스템으로 정의합니다. 간단히 말해, 도구를 루프로 호출하는 LLM입니다.
Manus는 가장 인기 있는 범용 소비자 에이전트 중 하나입니다. 일반적인 Manus 작업은 50회의 도구 호출을 사용합니다. 컨텍스트 엔지니어링이 없다면, 이러한 도구 호출 결과가 LLM 컨텍스트 윈도우에 누적됩니다. 컨텍스트 윈도우가 채워지면 LLM 성능이 저하된다는 관찰이 많이 있습니다.
예를 들어, Chroma는 컨텍스트 부패(context rot)에 관한 훌륭한 연구를 했고 Anthropic은 증가하는 컨텍스트가 LLM의 주의 예산을 고갈시킨다고 설명했습니다. 따라서 에이전트를 구축할 때 LLM의 컨텍스트 윈도우에 무엇을 넣을지 신중히 관리하는 것이 중요합니다. Karpathy가 명확히 설명했습니다:
컨텍스트 엔지니어링은 (에이전트의 궤적에서) 다음 단계에 정확히 필요한 정보만으로 컨텍스트 윈도우를 채우는 섬세한 기술이자 과학입니다
컨텍스트 엔지니어링 접근법
각 Manus 세션은 전용 클라우드 기반 가상 머신을 사용하여, 에이전트에게 파일 시스템이 있는 가상 컴퓨터와 이를 탐색하는 도구, 그리고 샌드박스 환경에서 명령(예: 제공된 유틸리티 및 표준 셸 명령)을 실행할 수 있는 능력을 부여합니다.
이 샌드박스에서 Manus는 컨텍스트 엔지니어링을 위해 세 가지 주요 전략을 사용하며, 이는 Anthropic이 여기에서 다루고 제가 여러 프로젝트에서 본 접근과도 일치합니다:
- 컨텍스트 축소
- 컨텍스트 오프로드
- 컨텍스트 분리
컨텍스트 축소
Manus의 도구 호출에는 “전체(full)”와 “간결(compact)” 표현이 있습니다. 전체 버전은 도구 호출의 원시 콘텐츠(예: 완전한 검색 도구 결과)를 포함하며 샌드박스(예: 파일 시스템)에 저장됩니다. 간결 버전은 전체 결과에 대한 참조(예: 파일 경로)를 저장합니다.
Manus는 오래된(“stale”) 도구 결과에 압축을 적용합니다. 이는 전체 도구 결과를 간결 버전으로 교체한다는 의미입니다. 이렇게 하면 에이전트가 필요할 때 전체 결과를 다시 가져올 수 있으면서도, 에이전트가 이미 의사결정을 위해 사용한 “오래된” 결과를 제거해 토큰을 절약할 수 있습니다.
더 최신 도구 결과는 에이전트의 다음 결정을 안내하기 위해 전체로 유지됩니다. 이는 컨텍스트 축소에 일반적으로 유용한 전략으로 보이며, Anthropic의 컨텍스트 편집(context editing) 기능과 유사하다는 점을 확인했습니다:
컨텍스트 편집은 토큰 한계에 접근할 때 컨텍스트 윈도우 내의 오래된 도구 호출과 결과를 자동으로 정리합니다. 에이전트가 작업을 실행하고 도구 결과가 누적되면서, 컨텍스트 편집은 오래된 콘텐츠를 제거하여 대화 흐름을 보존하고, 수동 개입 없이 에이전트가 더 오래 실행될 수 있도록 사실상 확장합니다.
압축이 체감효용 감소 지점(아래 그림 참조)에 도달하면, Manus는 궤적(trajectory)에 요약을 적용합니다. 요약은 전체 도구 결과를 사용해 생성되며, Manus는 요약 필드를 정의하는 스키마를 사용합니다. 이를 통해 어떤 에이전트 궤적에도 일관된 요약 객체를 생성합니다.
컨텍스트 분리
Manus는 다중 에이전트에 대해 실용적 접근을 취하며, 의인화된 역할 분담을 피합니다. 인간은 인지적 한계로 인해 역할(디자이너, 엔지니어, 프로젝트 매니저)로 조직하지만, LLM은 반드시 동일한 제약을 공유하지는 않습니다.
이를 염두에 두면, Manus에서 하위 에이전트의 기본 목표는 컨텍스트를 분리하는 것입니다. 예를 들어, 수행할 작업이 있으면 Manus는 해당 작업을 자체 컨텍스트 윈도우를 가진 하위 에이전트에 할당합니다.
Manus는 작업을 할당하는 플래너, 대화를 검토하고 파일 시스템에 무엇을 저장할지 결정하는 지식 관리자를 두고, 플래너가 할당한 작업을 수행하는 실행자 하위 에이전트를 사용하여 다중 에이전트를 구성합니다.
Manus는 처음에 todo.md를 사용해 작업 계획을 했지만, 전체 행동의 약 3분의 1이 할 일 목록 업데이트에 소비되어 토큰을 낭비한다는 것을 발견했습니다. 그들은 전용 플래너 에이전트로 전환하여 실행자 하위 에이전트를 호출해 작업을 수행하도록 했습니다.
최근 팟캐스트에서 Anthropic의 다중 에이전트 연구자 Erik Schluntz는 유사하게 플래너로 다중 에이전트 시스템을 설계하여 작업을 할당하고, 하위 에이전트를 시작하는 통신 프로토콜로 함수 호출을 사용한다고 언급했습니다. Erik과 Cognition의 Walden Yan이 제기한 중심 과제는 플래너와 하위 에이전트 간 컨텍스트 공유입니다.
Manus는 이를 두 가지 방식으로 해결합니다. 단순한 작업(예: 플래너가 하위 에이전트의 출력만 필요로 하는 이산적 작업)에서는, 플래너가 지시사항을 생성하여 함수 호출을 통해 하위 에이전트에 전달합니다. 이는 Claude Code의 작업 도구와 유사합니다.
더 복잡한 작업(예: 하위 에이전트가 플래너도 사용하는 파일에 기록해야 하는 경우)에서는, 플래너가 자신의 전체 컨텍스트를 하위 에이전트와 공유합니다. 하위 에이전트는 여전히 고유한 행동 공간(도구)과 지시사항을 가지지만, 플래너가 접근 가능한 전체 컨텍스트를 함께 전달받습니다.
두 경우 모두 플래너는 하위 에이전트의 출력 스키마를 정의합니다. 하위 에이전트는 결과를 제출하는 submit results 도구로 이 스키마를 채운 후 플래너에게 결과를 반환하며, Manus는 정의된 스키마 준수를 보장하기 위해 제한 디코딩(constrained decoding)을 사용합니다.
컨텍스트 오프로드
도구 정의
우리는 종종 광범위한 행동을 수행할 수 있는 에이전트를 원합니다. 물론 많은 도구 모음을 LLM에 바인딩하고, 모든 도구 사용법에 대한 자세한 지시사항을 제공할 수 있습니다. 하지만 도구 설명은 소중한 토큰을 사용하고, 많은(종종 중복되거나 모호한) 도구가 모델 혼란을 유발할 수 있습니다.
제가 보는 트렌드는, 에이전트가 소수의 일반 도구만을 사용하여 에이전트에게 컴퓨터 접근을 제공한다는 것입니다. 예를 들어, Bash 도구와 파일 시스템에 접근하는 몇 가지 도구만으로도, 에이전트는 매우 광범위한 행동을 수행할 수 있습니다!
Manus는 이를 함수/도구 호출 계층과 가상 컴퓨터 샌드박스로 구성된 계층화된 행동 공간으로 생각합니다. Peak는 Manus가 20개 미만의 원자적 함수 집합을 사용한다고 언급했는데; 여기에는 Bash 도구, 파일 시스템을 관리하는 도구, 코드 실행 도구 같은 것이 포함됩니다.
함수 호출 계층을 비대하게 만드는 대신, Manus는 대부분의 행동을 샌드박스 계층으로 오프로드합니다. Manus는 Bash 도구로 샌드박스에서 많은 유틸리티를 직접 실행할 수 있고, MCP 도구는 에이전트가 Bash 도구를 사용해 실행할 수 있는 CLI를 통해 노출됩니다.
Claude의 skills 기능도 유사한 아이디어를 사용합니다: skills는 파일 시스템에 저장되고, 바운드 도구로서가 아니라, Claude는 작업을 점진적으로 발견하고 사용할 수 있도록 몇 가지 간단한 함수 호출(Bash, 파일 시스템)만 필요로 합니다.
점진적 공개(progressive disclosure)는 Agent Skills를 유연하고 확장 가능하게 만드는 핵심 설계 원칙입니다. 잘 구성된 매뉴얼이 목차로 시작해, 특정 챕터로 이어지고, 마지막에 상세한 부록을 제공하는 것처럼, skills는 Claude가 필요한 정보만 로드하게 해줍니다 … 파일 시스템과 코드 실행 도구를 가진 에이전트는 특정 작업을 수행할 때 스킬 전체를 컨텍스트 윈도우에 읽어들일 필요가 없습니다.
도구 결과
Manus는 파일 시스템에 접근할 수 있기 때문에, 컨텍스트(예: 도구 결과)를 오프로드할 수도 있습니다. 위에서 설명했듯, 이는 컨텍스트 축소에 핵심적입니다; 도구 결과는 간결 버전을 생성하기 위해 파일 시스템으로 오프로드되며, 이는 에이전트의 컨텍스트 윈도우에서 오래된 토큰을 제거하는 데 사용됩니다. Claude Code와 유사하게, Manus는 기본 유틸리티(예: glob와 grep)로 인덱싱(예: 벡터스토어) 없이 파일 시스템을 검색합니다.
모델 선택
단일 모델에 고정하기보다는, Manus는 작업 수준 라우팅을 사용합니다: 코딩에는 Claude, 멀티모달 작업에는 Gemini, 수학과 추론에는 OpenAI를 사용할 수 있습니다. 전반적으로 Manus의 모델 선택 접근은 비용 고려에 의해 좌우되며, KV 캐시 효율성이 중심적 역할을 합니다.
Manus는 많은 에이전트 턴 전반에 걸쳐 비용과 지연을 줄이기 위해 캐싱(예: 시스템 지시사항, 오래된 도구 결과 등)을 사용합니다. Peak는 분산 KV 캐시 인프라가 오픈소스 모델에서 구현하기 어렵지만, 프론티어 제공자에서는 잘 지원된다고 언급했습니다. 이러한 캐시 지원은 특정(에이전트) 사용 사례에서 프론티어 모델을 실제로 더 저렴하게 만들 수 있습니다.
‘쓴 교훈(Bitter Lesson)’을 염두에 두고 구축하기
우리는 쓴 교훈(Bitter Lesson)에 대해 논의하며 마무리했습니다. 저는 AI 엔지니어링에 대한 그 함축적 의미에 관심이 있어 왔습니다. Boris Cherny(Claude Code 창시자)는 쓴 교훈이 Claude Code를 비의견적(unopinionated)으로 유지하기로 한 그의 결정에 영향을 주어, 모델 개선에 더 쉽게 적응할 수 있게 했다고 언급했습니다.
끊임없이 개선되는 모델 위에 구축한다는 것은 지속적인 변화를 받아들이는 것을 의미합니다. Peak는 Manus가 3월 출시 이후 다섯 번 리팩터링되었다고 말했습니다!
또한 Peak는 모델이 발전함에 따라 에이전트의 하네스(harness)가 성능을 제한할 수 있다고 경고했습니다; 이는 바로 쓴 교훈이 지적한 과제입니다. 우리는 특정 시점의 성능을 개선하기 위해 구조를 추가하지만, 이 구조는 연산(모델)이 성장하면서 성능을 제한할 수 있습니다.
이를 방지하기 위해, Peak는 다양한 모델 강도에 걸친 에이전트 평가를 수행할 것을 제안했습니다. 더 강한 모델에서도 성능이 향상되지 않는다면, 여러분의 하네스가 에이전트를 방해하고 있을 수 있습니다. 이는 하네스가 “미래 지향적”인지 테스트하는 데 도움이 됩니다.
Hyung Won Chung(OpenAI/MSL)의 발표는 모델 개선에 따라 구조(예: 하네스/가정)를 지속적으로 재평가해야 할 필요성을 더욱 강조합니다.
현재 사용 가능한 연산(compute)과 데이터 수준에 필요한 구조를 추가하라. 나중에는 그것들을 제거하라, 왜냐하면 이러한 지름길은 추가적인 개선을 병목으로 만들 것이기 때문이다.
결론
에이전트에게 컴퓨터 접근(예: 파일 시스템, 터미널, 유틸리티)을 제공하는 것은 많은 에이전트에서 보는 공통 패턴이며 Manus도 포함됩니다. 이는 몇 가지 컨텍스트 엔지니어링 전략을 가능하게 합니다:
- 컨텍스트 오프로드
- 도구 결과를 외부에 저장: 전체 도구 결과를 컨텍스트가 아닌 파일 시스템에 저장하고,
glob와grep 같은 유틸리티로 필요 시 접근 - 행동을 샌드박스로 밀어 넣기: 많은 유틸리티를 도구로 바인딩하기보다, 샌드박스에서 실행 가능한 소수의 함수 호출(Bash, 파일 시스템 접근)을 사용
- 컨텍스트 축소
- 오래된 결과를 압축: 컨텍스트가 채워지면 오래된 도구 결과를 참조(예: 파일 경로)로 대체; 최근 결과는 다음 결정을 안내하기 위해 전체로 유지
- 필요 시 요약 적용: 압축의 체감효용이 떨어지면, 전체 궤적에 스키마 기반 요약을 적용
- 컨텍스트 분리
- 이산 작업에는 하위 에이전트 사용: 역할 분담이 아니라 컨텍스트 분리를 주 목적로, 자체 컨텍스트 윈도우를 가진 하위 에이전트에 작업을 할당
- 컨텍스트를 신중히 공유: 단순 작업에는 지시사항만 전달; 하위 에이전트가 더 많은 컨텍스트를 필요로 하는 복잡 작업에는 전체 컨텍스트(예: 궤적과 공유 파일 시스템)를 전달
마지막으로, 모델이 개선됨에 따라 하네스가 성능을 제한하지 않도록(예: “쓴 교훈에 물든(Bitter Lesson‑pilled)”) 보장하세요. 모델 강도에 걸친 테스트로 이를 검증할 수 있습니다. 단순하고 비의견적인 설계가 모델 개선에 더 잘 적응하는 경우가 많습니다. 마지막으로, 모델이 개선됨에 따라 에이전트를 다시 구축하는 것을 주저하지 마세요(Manus는 3월 이후 5회 리팩터링!).