본문 바로가기

인공지능

Manus의 Context Engineering: 에이전트 성능을 결정짓는 핵심 기술

728x90
반응형
728x170

대규모 LLM 기반 에이전트를 구축하다 보면 시간이 지날수록 모델이 점점 멍해지는 경험을 하게 됩니다. 처음에는 적절히 판단하던 에이전트가 여러 번 도구를 호출하고 작업을 진행할수록 실수를 반복하고, 문맥을 놓치고, 불필요한 행동을 하기도 합니다. 그 이유는 단순합니다. 에이전트가 생성한 도구 호출 결과들이 끝없이 컨텍스트 창에 쌓이기 때문입니다. 컨텍스트 창이 채워질수록 모델의 주의력이 분산되고, 정확도가 떨어지고, 심지어 작업 자체를 제대로 수행하지 못하게 됩니다.

Manus는 이러한 문제를 해결하기 위해 Context Engineering이라는 전략을 핵심 기술로 삼고 있습니다. 이 글에서는 Manus가 실제로 적용하고 있는 컨텍스트 관리 방식과 그 배경, 그리고 왜 이러한 구조가 LLM 에이전트 개발에서 필수가 되었는지 설명합니다.

반응형

1. 왜 Context Engineering이 필요한가

Anthropic은 에이전트를 “자신의 도구 사용과 사고 흐름을 스스로 관리하는 LLM 시스템”이라고 정의합니다. 간단히 말해, LLM이 스스로 도구를 호출하고 그 결과를 기반으로 반복적으로 다음 행동을 결정하는 구조입니다.

Manus는 대표적인 범용 소비자용 에이전트로, 평균적인 작업에서 약 50개 이상의 도구 호출이 발생합니다. 문제는 이 도구 호출 결과가 모두 LLM 컨텍스트 창에 누적된다는 점입니다. 이 누적이 커지면 다음과 같은 문제가 발생합니다.

  • 컨텍스트 창이 포화되며 모델의 집중력이 분산됨
  • 중요한 정보보다 오래된 정보가 모델의 판단에 영향을 줌
  • 모델 성능이 서서히 저하되는 ‘context rot’ 발생

Chroma의 연구에서도 이러한 성능 저하가 명확하게 드러났고, Anthropic 역시 “컨텍스트가 커질수록 주의력 예산이 줄어든다”고 설명했습니다.

이 문제는 성장한 모델의 자연스러운 한계가 아니라, 컨텍스트를 어떻게 구성하느냐의 문제입니다. 그래서 등장한 개념이 바로 Context Engineering입니다.


2. Context Engineering의 세 가지 핵심 전략

Manus는 클라우드 기반 VM을 에이전트마다 할당하여, 파일시스템과 터미널, 기본 유틸리티가 있는 ‘가상의 컴퓨터’를 제공합니다. 이 환경 안에서 Manus는 크게 세 가지 전략으로 컨텍스트를 관리합니다.

2.1 Reduce Context: 컨텍스트를 최소한으로 유지하는 기술

Manus는 도구 결과를 두 가지 형태로 저장합니다.

  • Full: 원본 도구 결과 전체
  • Compact: 원본이 저장된 파일 경로 등의 참조 정보

에이전트가 이미 활용한 오래된 결과는 Compact 형태로 치환하여 컨텍스트 창에서 제거합니다. 필요한 경우에는 파일시스템에서 원본 데이터를 다시 불러올 수 있으므로 정보 손상도 없습니다.

이 전략은 Anthropic의 context editing과 매우 유사한데, 중요한 점은 “다음 행동에 꼭 필요한 최신 정보만 Full로 남긴다”는 것입니다.

Compact 처리로 얻을 수 있는 성능 향상이 충분하지 않을 때는 Manus가 전체 작업 기록을 요약합니다. 이때도 요약은 Full 결과를 근거로 하며, Manus는 미리 정의된 요약 스키마를 사용해 일관된 형태의 결과를 생성합니다.

2.2 Offload Context: 컨텍스트 창이 아닌 파일시스템을 사용한다

에이전트가 사용할 수 있는 도구가 많아질수록 도구 정의만으로도 많은 토큰을 소모하고, 서로 비슷한 도구들 때문에 모델이 혼란을 겪기도 합니다.

이를 해결하기 위해 Manus는 다음과 같은 방식으로 작업을 ‘오프로딩’합니다.

  • 도구를 최소한으로 유지: Bash, 파일 시스템 접근 등 20개 미만의 핵심 도구만 제공
  • 나머지 복잡한 작업은 가상 머신에서 직접 실행
  • MCP 도구들도 CLI 형태로 Bash 환경에서 실행
  • 도구 결과를 전부 파일시스템에 저장해 필요할 때 검색(glob, grep 등)

Claude Skills가 “모든 스킬을 컨텍스트에 넣지 말고 파일로 저장하라”는 설계를 사용하는 것도 같은 이유입니다. 중요한 점은 모델이 지금 필요하지 않은 정보를 굳이 컨텍스트 창에 넣을 이유가 없다는 것입니다.

2.3 Isolate Context: 작업을 분리해 컨텍스트 오염을 피한다

Manus는 멀티 에이전트를 역할 기반으로 나누지 않습니다. 인간처럼 “엔지니어 역할”, “기획자 역할”로 구분할 필요가 없기 때문입니다. 대신 Manus는 “컨텍스트를 분리하기 위한 목적으로만” sub-agent를 사용합니다.

구조는 다음과 같습니다.

  • Planner: 어떤 작업을 할지 결정
  • Knowledge Manager: 파일시스템에 어떤 정보를 저장할지 판단
  • Executor Sub-Agent: Planner가 지정한 작업을 수행

초기에는 todo.md 파일로 작업 관리를 했지만, 도구 호출의 약 1/3이 todo 업데이트에 소모되는 비효율이 발생하여 Planner Sub-Agent 구조로 전환했습니다.

작업의 복잡도에 따라 컨텍스트 전달 방식도 달라집니다.

  • 단순 작업: 지시사항만 전달
  • 복잡 작업: Planner의 전체 컨텍스트를 Sub-Agent에 공유
  • 최종 결과는 Planner가 정의한 스키마에 맞춰 반환(제약 디코딩 사용)

이 접근은 Anthropic과 Cognition이 제시한 멀티 에이전트 디자인 고민과 매우 일치합니다.


3. Manus가 선택한 기술적 설계 방식

Manus의 전체 설계는 “컨텍스트는 작게, 필요한 정보는 파일시스템에서, 작업은 sandbox에서”라는 흐름으로 일관돼 있습니다.

핵심 요소를 정리하면 다음과 같습니다.

  • Full/Compact 형태의 도구 결과
  • Compact로 충분하지 않을 때 사용하는 요약 스키마
  • 20개 미만의 atomic tool
  • Bash 중심의 유틸리티 기반 실행
  • MCP도 CLI 계층으로 처리
  • 파일 시스템 기반 검색(glob, grep)
  • 모델 라우팅(Claude, Gemini, OpenAI)
  • KV Cache 기반 비용 최적화

이 모든 구조는 '컨텍스트를 가볍게 유지하면서도 필요한 기능은 모두 사용할 수 있도록’ 구성되어 있습니다.


4. 단순함이 장기적으로 유리한 이유: Bitter Lesson

AI 분야에서 오랫동안 반복된 결론은 단순합니다.
“구조적 트릭보다 계산력의 향상이 더 큰 변화를 만든다.”

이것이 Bitter Lesson입니다.

Manus의 Peak는 인터뷰에서 “Manus는 출시 이후 다섯 번이나 구조를 전면 개편했다”고 언급했습니다. 모델이 커지고 더 똑똑해질수록 오래된 구조가 오히려 성능을 제한하는 순간이 오기 때문입니다.

중요한 시사점은 다음과 같습니다.

  • 모델이 더 강해져도 성능이 개선되지 않으면, 구조가 병목일 가능성이 높다
  • 너무 복잡하고 과한 구조는 오히려 미래 모델 성능을 제한한다
  • 필요한 구조를 쓰되, 모델 발전 속도에 맞춰 정기적으로 제거해야 한다

Hyung Won Chung 역시 “현재 성능을 위해 추가한 구조가 결국 미래 성능을 막는다”고 강조한 바 있습니다.


728x90

Manus의 사례는 에이전트 시스템의 핵심이 모델 자체가 아니라 컨텍스트를 어떻게 관리하느냐에 있다는 점을 잘 보여줍니다.

핵심은 세 가지입니다.

  1. Offload
    • 도구 결과는 파일로 저장해 컨텍스트 창을 비우고
    • Bash와 기본 도구만으로 다양한 작업을 수행한다
  2. Reduce
    • 오래된 도구 결과는 Compact로 치환하고
    • 필요 시 전체 작업을 스키마 기반으로 요약해 컨텍스트를 더욱 줄인다
  3. Isolate
    • 작업을 분리하고, 필요에 따라 적절한 수준의 컨텍스트만 공유한다

이러한 구조는 성능 문제를 줄일 뿐만 아니라, 모델이 발전하더라도 기존 설계를 유지하거나 확장하기 쉬운 장점을 제공합니다. 더 나은 모델이 등장해도 기존 구조가 발목을 잡지 않도록 단순하고 유연한 설계를 유지하는 것이 중요합니다.

Manus가 계속해서 리팩터링을 반복하는 것은 바로 이 이유 때문입니다.
에이전트 개발에서 가장 큰 병목은 모델이 아니라 구조이며, Context Engineering은 이를 해결하기 위한 핵심 전략 중 하나로 자리 잡고 있습니다.

300x250

https://rlancemartin.github.io/2025/10/15/manus/

 

Context Engineering in Manus

Lance Martin Why Context Engineering Earlier this week, I had a webinar with Manus co-founder and CSO Yichao “Peak” Ji. You can see the video here, my slides here, and Peak’s slides here. Below are my notes. Anthropic defines agents as systems where

rlancemartin.github.io

728x90
반응형
그리드형