Manus AI 에이전트 보고서

gist: renschni/Manus_report.md

저는 Manus 주제에 대해 GPT-Deep-Research를 수행하기 위한 심층 연구 프롬프트를 작성했으며, 현재 사용 가능한 오픈소스 도구로 이를 복제하는 것을 목표로 했습니다. 아래는 그 결과입니다.

TLDR: Manus AI 에이전트 보고서

Manus는 기초 모델(주로 Claude 3.5/3.7과 Alibaba의 Qwen)을 래핑한 형태로 구축된 자율 AI 에이전트입니다. 이 시스템은 웹 브라우저, 셸 명령, 코드 실행 등 다양한 도구에 완전히 접근할 수 있는 클라우드 기반 가상 컴퓨팅 환경에서 동작합니다. 시스템의 핵심 혁신은 실행 가능한 파이썬 코드를 행동 메커니즘(“CodeAct” 접근법)으로 사용한다는 점으로, 이를 통해 복잡한 작업을 자율적으로 수행할 수 있습니다. 아키텍처는 반복적인 에이전트 루프(분석 → 계획 → 실행 → 관찰)로 구성되어 있으며, 계획, 지식 검색, 메모리 관리에 특화된 모듈이 있습니다. Manus는 파일 기반 메모리를 사용하여 작업 진행 상황을 추적하고 여러 작업에 걸쳐 정보를 저장합니다. 이 시스템은 CodeActAgent(미스트랄 모델을 파인튜닝한 것), 도커(Docker)를 통한 샌드박싱, 웹 상호작용을 위한 Playwright, 오케스트레이션을 위한 LangChain 등 오픈소스 구성요소로 복제할 수 있습니다. 복제는 기술적으로 가능하지만, Manus의 신뢰성과 성능을 달성하려면 정교한 프롬프트 엔지니어링과 광범위한 테스트가 필요합니다.

Manus 자율 AI 에이전트: 기술 분석

1. 시스템 아키텍처 분석

기초 모델 백본: Manus는 자체 개발 모델이 아니라 강력한 기초 언어 모델 위에 구축되었습니다. 팀의 수석 과학자는 Manus가 처음에는 Anthropic의 Claude(특히 Claude 3.5 “Sonnet v1”)를 핵심 추론 엔진으로 사용했고, Alibaba의 Qwen 대형 모델의 파인튜닝 버전으로 보완했다고 밝혔습니다. 즉, Manus의 “두뇌”는 기존 LLM의 조합입니다. 이 백본은 지속적으로 업그레이드되고 있으며, 예를 들어 _Claude 3.7_을 내부적으로 테스트 중입니다. 보도에 따르면 Manus는 서로 다른 하위 작업에 대해 여러 모델을 동적으로 호출할 수 있으며(“다중 모델 동적 호출”), 각 모델의 강점을 활용합니다. 예를 들어, _Claude 3_는 복잡한 논리적 추론, _GPT-4_는 코딩 작업, Google의 _Gemini_는 폭넓은 지식 질의에 사용합니다(실제로 GPT-4/Gemini가 사용되었는지는 불분명하나, 언론에서 시사됨). 핵심은 Manus가 단일 독립형 모델이 아니라 최상위 LLM 위에서 오케스트레이터로 동작한다는 점입니다. 이 설계는 각 작업에 가장 적합한 AI 기능을 활용할 수 있게 해줍니다.

클라우드 에이전트와 도구 샌드박스: 일반 챗봇이 텍스트에만 국한되는 것과 달리, Manus는 클라우드 내 가상 컴퓨팅 환경에서 실행됩니다. 이 환경은 인터넷에 접속 가능한 완전한 Ubuntu Linux 작업 공간으로, Manus는 shell (루트 권한 포함), 제어 가능한 웹 브라우저, 파일 시스템, 파이썬 및 Node.js와 같은 프로그래밍 언어 인터프리터에 접근할 수 있습니다. 웹 서버를 실행하고 인터넷에 노출시키는 것도 가능합니다. 이 모든 것은 서버 측에서 이루어지므로, 사용자의 기기가 꺼져 있어도 Manus는 계속 작업을 수행할 수 있습니다. 이는 OpenAI의 실험적 “Operator”처럼 사용자의 브라우저에서 실행되는 에이전트와 구별되는 점입니다. 샌드박스된 도구 환경 덕분에 Manus는 자연어로 답변하는 것에 그치지 않고, 웹사이트 탐색, 폼 작성, 코드 작성 및 실행, API 호출 등 행동할 수 있습니다. 이 아키텍처는 Manus를 단순한 대화형 봇이 아니라 클라우드 상의 디지털 워커로 만듭니다.

에이전트 루프와 오케스트레이션: Manus는 자율성을 구조화하는 반복적 에이전트 루프를 통해 동작합니다. 각 루프 사이클은 (1) 최근 상호작용 이벤트 스트림에서 현재 상태와 사용자 요청 분석, (2) 다음에 사용할 도구 또는 작업 계획/선택, (3) 샌드박스에서 해당 작업 실행, (4) 결과 관찰 (이벤트 스트림에 추가)로 구성됩니다. 이 루프는 Manus가 작업이 완료되었다고 판단할 때까지 반복되며, 완료 시 최종 결과를 사용자에게 출력하고 대기 상태로 들어갑니다. 설계상 에이전트는 한 번에 한 도구만 사용할 수 있으며, 각 작업의 결과를 기다린 후 다음 단계를 결정합니다. 이 제어 흐름은 모델이 무분별하게 연속적인 작업을 실행하는 것을 방지하고, 시스템(및 사용자)이 각 단계를 모니터링할 수 있게 합니다.

플래너 모듈(작업 분해): 복잡한 작업을 관리하기 위해 Manus는 플래너 모듈을 도입하여 고수준 목표를 순서가 있는 단계 목록으로 분해합니다. 사용자가 목표나 프로젝트를 제시하면, 플래너는 의사코드 또는 번호가 매겨진 목록(단계 번호, 설명, 상태) 형태의 계획을 생성하여 “Plan” 이벤트로 Manus 에이전트의 컨텍스트에 주입합니다. 예를 들어, 데이터 시각화 작업을 요청하면, 플래너는 1. 데이터 수집, 2. 데이터 정제, 3. 그래프 생성, 4. 그래프 저장 및 전송_과 같은 순서를 만듭니다. Manus는 이를 로드맵으로 삼아 각 단계를 순서대로 실행합니다. 작업이 변경되면 계획도 실시간으로 업데이트할 수 있습니다. 에이전트는 각 반복마다 계획을 참조하며, 모든 단계를 완료해야 작업이 끝난다는 것을 인식합니다. 이 메커니즘은 Manus에 미래 예측 및 구조화된 의사결정 능력을 부여합니다. 이는 AutoGPT나 BabyAGI가 목표를 위한 작업 목록을 유지하는 방식과 유사합니다.

지식 및 데이터 모듈: Manus는 LLM의 내장 지식에만 의존하지 않습니다. 필요할 때 지식 베이스에서 관련 참조 정보나 모범 사례 가이드라인을 제공하는 지식 모듈이 있습니다. 이는 “Knowledge” 이벤트로 컨텍스트에 삽입되어, 에이전트가 도메인이나 작업에 특화된 유용한 정보를 얻을 수 있게 합니다(예: 에세이 작성 시 스타일 가이드나 사실 정보 제공). 동시에, 데이터소스 모듈을 통해 API로 실제 데이터를 가져올 수 있습니다. 에이전트는 사전에 승인된 데이터 API 라이브러리(날씨, 금융 등)와 그 문서를 제공받습니다. 관련이 있을 때는 웹 스크래핑 대신 파이썬 코드를 통해 API를 호출합니다. 시스템은 신뢰할 수 있는 데이터 소스를 일반 웹 정보보다 우선시합니다. 예를 들어, 날씨 정보를 얻기 위해 파이썬 코드로 Weather API를 호출할 수 있습니다. 이 접근법은 RAG(Retrieval-Augmented Generation)를 통합한 것으로, 에이전트가 외부 지식과 데이터를 적극적으로 가져와서 추론과 출력에 반영합니다. 개발자들은 Manus가 “RAG를 지원한다”고 확인했습니다. 모든 검색된 사실이나 데이터는 읽기 전용 컨텍스트로 이벤트 스트림에 삽입되어, LLM이 이를 활용할 수 있습니다.

다중 에이전트 협업: Manus 아키텍처의 주목할 만한 점은 다중 에이전트(다중 모듈) 설계입니다. 단일 에이전트가 모든 것을 처리하는 대신, Manus는 특화된 하위 에이전트나 컴포넌트가 각기 다른 작업을 병렬로 처리할 수 있도록 구조화되어 있습니다. 예를 들어, 한 하위 에이전트(또는 스레드)는 웹 브라우징과 정보 수집을, 다른 에이전트는 코딩을, 또 다른 에이전트는 데이터 분석을 담당하며, 각각의 샌드박스 환경에서 동작합니다. 상위 오케스트레이터(Manus의 메인 두뇌)가 이들을 조정하여 작업을 분할하고 결과를 통합합니다. 이 설계는 분산 문제 해결에서 영감을 얻은 것으로, 여러 전문 에이전트를 “고용”함으로써 복잡한 다면적 프로젝트를 더 효율적으로 처리할 수 있습니다. 또한, 한 에이전트가 바쁘거나 멈추더라도 다른 에이전트가 다른 하위 작업을 계속 진행할 수 있어 견고함이 향상됩니다. 궁극적으로, 이 다중 에이전트 아키텍처 덕분에 Manus는 여러 단계와 기술이 필요한 실질적인 결과물(예: 포맷된 엑셀 보고서, 웹사이트 배포 등)을 제공할 수 있습니다. 사용자 입장에서는 Manus가 모든 작업을 하나의 AI 어시스턴트로 처리하는 것처럼 보이지만, 실제로는 내부적으로 다중 에이전트가 협업합니다.

2. 기술 구성요소

실행 가능한 코드 액션(“CodeAct”): Manus의 도구 사용 메커니즘은 AI 에이전트가 환경과 상호작용할 때 코드를 작성하고 실행할 수 있다는 통찰에 기반합니다. 실제로, Manus 개발자들은 실행 가능한 파이썬 코드를 LLM 에이전트의 범용 액션 포맷으로 사용하는 2024년 연구 논문을 참고했습니다. 모델이 “SEARCH(query)”와 같은 고정된 토큰이나 엄격한 JSON 대신, 원하는 작업을 수행하는 짧은 파이썬 스크립트를 생성하는 방식입니다. 이것이 CodeAct 패러다임입니다. 모델의 “행동”이 곧 실행되는 코드입니다. 이 방식의 장점은 유연성입니다. 코드는 여러 도구나 논리를 한 번에 결합할 수 있고, 조건문, 다양한 라이브러리 활용이 가능합니다. CodeAct 논문에 따르면, 코드를 생성해 행동하는 에이전트가 단순 텍스트 도구 호출에 제한된 에이전트보다 복잡한 도구 사용 작업에서 성공률이 훨씬 높았습니다. Manus는 이를 실제로 구현했습니다. 예를 들어, 날씨 정보를 가져와야 할 때, Manus는 날씨 API 클라이언트를 호출하고 결과를 출력하는 파이썬 코드를 생성할 수 있습니다. 샌드박스는 이 코드를 실행하고 결과(또는 에러)를 관찰로 반환합니다. 이를 분석해 Manus는 코드를 조정하고 다시 시도할 수 있습니다. 즉, 스스로 디버깅이 가능합니다. 코드를 반복적으로 작성, 실행, 수정할 수 있는 능력 덕분에 Manus는 개발자처럼 문제를 해결할 수 있습니다. 도구 “명령”은 종종 코드 내 함수 호출로 구현됩니다. (내부적으로는 search_web(), open_url()과 같은 파이썬 함수 라이브러리나 API가 제공되어, 모델이 생성한 코드에서 이를 results = search_web("site:xyz.com information on ABC")과 같이 호출할 수 있게 되어 있을 것입니다.) 이 방식 덕분에 Manus는 데이터베이스 쿼리, 데이터 시각화, 복잡한 연산 등 고정된 도구로는 불가능한 작업도 수행할 수 있습니다. Manus는 사실상 파이썬을 행동 언어(CodeAct)로 사용하여, 고정된 도구 API만 가진 에이전트보다 훨씬 넓은 행동 공간을 가집니다.

도구 통합 및 제어 흐름: Manus는 수십 개의 특정 도구를 통합하지만, 표준화된 함수 호출 인터페이스로 이를 호출합니다. 시스템 프롬프트는 _모든 단계는 도구 호출(함수 호출)이어야 하며, 직접 자연어로 답변하지 말 것_이라고 명시합니다. 실제로, 사용자가 작업을 주면, 이후 Manus의 응답은 답변이 아니라 실행할 작업을 나타내는 JSON 또는 구조화된 출력입니다. 예를 들어, ‎{"action": "SEARCH", "parameters": {"query": "도쿄 최고의 호텔"}}과 같은 형식입니다. 오케스트레이터가 이를 해석해 검색을 수행하고, 결과를 다시 피드백합니다. 최종 답변이 준비될 때만 자연어 메시지를 생성합니다. 이 방식은 OpenAI의 함수 호출 포맷과 유사하며, 모델이 실제로 행동하지 않고 결과를 “환각”하는 것을 방지합니다. Manus의 도구에는 웹 검색(URL이나 데이터를 찾기 위해), 브라우저 내비게이션(URL 열기, 링크 클릭, 스크롤 등), 셸 명령(패키지 설치, 시스템 유틸리티 실행 등), 파일 조작(파일 읽기/쓰기), 코드 실행(파이썬이나 다른 언어의 코드 스니펫 실행), API 호출(앞서 언급된 한대로 해당 데이터 소스 API를 호출), 메시징(필요할 때 사용자에게 메시지를 보내거나 질문을 보내는) 등이 포함됩니다. 각 도구는 규칙에 의해 제한됩니다. 예를 들어, 되돌릴 수 없는 작업은 특별한 사용자 허가 없이는 실행하지 않으며, 비대화형 모드(예: apt-get에 -y 추가)를 선호합니다. 브라우저 사용 시에는 내용이 잘렸을 경우 스크롤하고, 검색 엔진 요약 스니펫은 무시하며, 실제 페이지를 클릭해 신뢰할 수 있는 정보를 얻도록 지시합니다. 도구 사용의 제어 흐름은 엄격합니다. 한 번에 한 도구만 실행할 수 있고, 실행 후 반드시 결과(관찰 이벤트)를 확인해야 합니다. 에러가 발생하면, 에러 메시지로 원인을 진단하고 재시도하거나, 대체 방법을 선택하며, 최후의 수단으로만 사용자에게 진행 불가를 알립니다. 이는 사람이 도구를 사용할 때(시도, 디버깅, 재시도)와 유사합니다. 도구 인터페이스는 모델이 “볼 수 있는” API로 구현됩니다. 많은 오픈소스 에이전트 프레임워크들은 모델이 출력하는 특수 토큰이나 JSON을 가로채는 방식으로 이를 구현합니다. Manus의 경우, CodeAct 접근법을 사용하므로 코드 출력 자체를 가로채는 것으로 보입니다. 예를 들어, 모델이 특수 토큰을 출력하거나 코드에서 특정 함수를 호출하면, 시스템이 이를 도구 호출로 인식하는 식입니다. 요약하자면, Manus는 자유로운 코드 작성의 유연성과 통제된 도구 API의 안전성을 결합한 것입니다. 에이전트는 코드를 통해 거의 모든 작업을 할 수 있지만, 시스템은 한 번에 한 단계씩만 실행하고 각 결과를 관찰하여 안전하게 관리합니다.

메모리 및 상태 관리: 자율 에이전트로서 Manus는 작업 전반에 걸쳐 많은 상태를 관리해야 합니다. 이를 위해 여러 가지 방법을 사용합니다.

이벤트 스트림 컨텍스트: Manus의 즉각적인 작업 메모리는 이벤트 스트림입니다. 이는 세션에서 발생한 모든 일(사용자 메시지, 에이전트의 행동, 그 결과 등)을 시간 순서대로 기록한 로그입니다. 각 반복마다 Manus는 이 스트림의 최신 부분을 받아(또는 기억하여) 다음 단계를 결정하는 데 사용합니다. 이 스트림은 모델의 컨텍스트 윈도우에 맞게 잘릴 수 있습니다(예: 최근 N개의 이벤트나 이전 이벤트의 요약만 포함). 컨텍스트를 “사용자가 X라고 말함”, “Y 행동이 실행됨”, “관찰: Y의 결과는 …”과 같이 유형별 이벤트로 구조화함으로써, 시스템 프롬프트가 모델이 다양한 정보를 구분할 수 있도록 돕습니다. 본질적으로, 이는 모델이 체인 오브 쏘트(chain-of-thought) 추론에 사용하는 구조화된 메모리입니다.
지속적 스크래치패드(파일): Manus는 메모리를 가상 파일 시스템의 파일로 적극적으로 외부화합니다. 유출된 프롬프트에 따르면, Manus는 모든 것을 채팅 컨텍스트에만 보관하려 하지 말고, 중간 결과와 노트를 파일에 저장해야 합니다. 예를 들어, Manus가 리서치 보고서를 작성할 때, 정보를 수집하면서 각 섹션별로 파일을 만들고, 나중에 이를 결합할 수 있습니다. 또한, 계획 단계의 체크리스트 역할을 하는 특별한 파일인 todo.md를 사용합니다. 각 단계를 완료할 때마다 Manus는 todo.md에서 해당 항목을 체크합니다(프롬프트에서 진행 상황에 따라 파일을 업데이트하라고 지시함). 이는 에이전트가 진행 상황을 추적하는 데 도움이 될 뿐만 아니라, 세션이 중단되거나 컨텍스트가 손실되더라도 todo 파일이 완료된 작업과 남은 작업의 진실된 기록이 됩니다. 작업이 끝나면 Manus는 todo.md를 참조해 모든 항목이 완료되었고 누락된 것이 없는지 확인할 수 있습니다. 이는 인간 프로젝트 매니저가 체크리스트를 관리하는 방식과 매우 유사하며, AI의 단기 메모리가 제한적이더라도 연속성을 제공합니다.
장기 지식 저장소(Long-Term): 앞서 언급한 Knowledge 모듈은 모범 사례와 도메인 지식의 메모리 역할을 합니다. 이는 필요할 때 Manus가 질의하는 외부 지식 베이스입니다. 예를 들어, 사용자가 Manus에게 React 앱을 만들어 달라고 요청하면, 시스템은 React 프로젝트 설정에 관한 모범 사례가 담긴 참조 스니펫을 “knowledge” 이벤트로 불러올 수 있습니다. 이렇게 하면 모델이 모든 것을 기억할 필요 없이, 큐레이션된 지식 베이스에서 힌트를 얻을 수 있습니다. 마찬가지로, Manus는 RAG(Retrieval-Augmented Generation)를 사용하므로, 사용자의 질의와 관련된 문서나 데이터를 실시간으로 가져와 컨텍스트에 통합할 수 있습니다(예: 분석용 회사 데이터, 특정 PDF 내용 등). 검색과 생성을 결합함으로써, Manus는 고정된 지식 컷오프라는 일반적인 LLM의 한계를 극복합니다.
컨텍스트 관리: 성능 유지를 위해, Manus는 LLM에 제공하는 컨텍스트의 크기를 관리해야 합니다. 아마도, 더 이상 관련 없는 오래된 이벤트는 요약되거나 삭제됩니다(예: 하위 작업이 끝나면 그 세부 내용은 간단한 메모로 정리). 프롬프트에는 대화의 먼 부분은 컨텍스트 길이 제한 때문에 기억하지 못할 수 있다고 명시되어 있습니다. Manus는 정보를 분리 저장함으로써 이 한계를 완화합니다. 코드와 데이터는 파일에 저장(필요할 때 에이전트가 열람), 원시(raw) 검색 결과는 채팅에 남기지 않고 저장하며, 결론이나 다음 행동만 라이브 컨텍스트에 남깁니다. 이 설계는 AutoGPT와 같은 시스템이 메모리를 관리하는 방식과 유사합니다(AutoGPT는 프롬프트에 담을 수 없는 정보는 로컬 파일이나 벡터 데이터베이스에 저장하고, 필요할 때 요약을 불러옴). RAG 접근법을 고려할 때, Manus 역시 벡터 스토어를 사용해 과거 대화나 검색된 문서의 관련 부분을 임베딩하고, 필요할 때 이를 불러오는 것으로 보입니다.

프롬프트 엔지니어링: Manus의 인상적인 성능은 단순히 모델 자체 때문만이 아니라, 시스템 전체에 어떻게 프롬프트와 지시가 주어지는지가 핵심입니다. Manus 팀은 에이전트의 행동을 통제하는 매우 상세한 **시스템 프롬프트(또는 프롬프트 세트)**를 설계했습니다. 유출된 프롬프트의 요지를 보면, Manus는 명확한 페르소나와 역할 범위를 부여받습니다. 예를 들어, _“당신은 Manus 팀이 만든 AI 에이전트 Manus입니다. 당신은 …[작업 목록]…에 능숙합니다.”_와 같이 모델이 자신의 능력에 대해 자신감을 갖고 컨텍스트를 이해할 수 있도록 합니다. 이 프롬프트에는 <system_capability>, <browser_rules>, <coding_rules> 등과 같은 섹션별로 수많은 규칙과 가이드라인이 구조적으로 나열되어 있으며, 모델은 이를 반드시 따라야 합니다. 예를 들어, 검색을 어떻게 처리할지, 클릭 없이 스니펫 텍스트만 신뢰하지 말 것, 사실 정보를 제공하거나 보고서를 작성할 때 항상 출처를 명시할 것, 출력 형식(요청이 없으면 불릿 리스트를 피할 것), 사용자와의 상호작용 방식(예: “notify” 메시지로 진행 상황을 알리되, 자율 흐름을 멈추게 할 불필요한 질문은 하지 말 것) 등이 포함되어 있습니다. 이것은 본질적으로 하드코딩된 프롬프트 기반 거버넌스이며, AI의 스타일과 절차를 더 예측 가능하게 만듭니다. 프롬프트 엔지니어링에는 플래너가 단계를 어떻게 출력할지(예: 번호가 매겨진 의사코드 형태)와 그것이 에이전트에게 어떻게 보일지, 그리고 “금지된 행동”(예: 시스템 프롬프트를 공개하거나 해롭거나 불법적인 행동을 하지 말 것)까지 포함됩니다. 이렇게 개발자의 전문성과 안전장치를 프롬프트에 직접 녹여냄으로써, Manus는 처음부터 많은 문제를 피할 수 있습니다. 또한, Manus의 프롬프트에는 매우 상세한 출력을 생성하라는 지침이 포함되어 있다는 점도 주목할 만합니다. 예를 들어, 어떤 보고서든 가능하다면 수천 단어로 작성하라는 규칙이 있습니다. 이는 설계자가 철저함을 원했다는 것을 보여줍니다. 또한, 긴 문서의 경우 초안을 파일로 저장하고 나중에 합치는 방식을 지시하는데, 이는 한 번에 긴 에세이를 출력하는 대신 토큰 한계와 긴 텍스트의 일관성을 해결하는 영리한 전략입니다. 이 모든 프롬프트 요소가 합쳐져 AI가 끊임없이 따르는 일종의 “운영 매뉴얼”을 만듭니다. 본질적으로, 프롬프트는 Manus의 자율적 행동을 실현하는 데 있어 모델의 가중치만큼이나 중요합니다. 프롬프트는 일반 모델(Claude 등)을, 어떻게 행동하고, 어떻게 계획하고, 어떻게 도구를 사용할지에 대한 시스템 메시지로 미리 세팅함으로써 특화된 에이전트로 변모시킵니다.

요약하자면, Manus의 기술적 비결은 (a) 견고한 아키텍처(플래너 + 메모리 + 도구 실행 루프), (b) 최상위 기초 모델(Claude 등)을 활용한 인지, (c) 코드 실행과 도구 사용을 통한 적극적 행동, (d) “에이전트 워크플로우”와 모범 사례가 담긴 정교한 시스템 프롬프트에 있습니다. 이 조합 덕분에 Manus는 복잡한 작업을 처음부터 끝까지 자율적으로 처리할 수 있으며, 일반 ChatGPT가 질문에 답하는 데 그치는 것과는 다릅니다. Manus의 설계는 LLM의 흔한 한계(환각, 장기 메모리 부재, 행동 불가)를 실용적 엔지니어링(규칙, 외부 메모리, 도구 사용 프레임워크)으로 극복합니다.

3. 구현 전략 (오픈 소스 도구로 Manus 재현하기)

아키텍처 청사진: Manus의 기능을 재현하려면 여러 구성 요소를 조합해야 합니다. 높은 수준에서, 다음과 같은 부분들로 구성된 아키텍처를 구상할 수 있습니다(다이어그램으로도 표현할 수 있음):

LLM 코어: 추론과 의사결정을 담당하는 대형 언어 모델(로컬에서 실행하거나 OpenAI/Anthropic 같은 API 사용 가능)
오케스트레이터/루프 컨트롤러: LLM을 감싸는 로직으로, 에이전트 루프를 구현(컨텍스트를 전달하고, 액션을 받아 실행한 뒤 결과를 다시 전달하는 과정을 반복)
툴/액션 인터페이스: LLM이 World와 상호작용할 수 있도록 하는 API나 함수 집합(웹 검색, 브라우저 자동화, 코드 실행 등). LLM이 작성한 코드를 안전하게 실행할 수 있는 샌드박스 환경도 포함
플래너 모듈: 작업을 하위 작업으로 분해하는 메커니즘(별도의 프롬프트나 작은 모델이 플랜을 생성할 수도 있음)
지식 검색기: 외부 데이터 소스(예: 문서의 벡터 데이터베이스, 또는 웹 검색 및 결과 수집 기능)와 연결하여 필요할 때 추가 컨텍스트를 제공
메모리 저장소: 에이전트가 진행 상황, 결과, 여러 턴이나 세션에 걸쳐 유지해야 할 정보를 기록하는 영속적 메모리(파일 또는 데이터베이스 형태)

시스템 다이어그램을 그린다면, LLM 코어가 중앙에 있고, 여러 툴 실행기(셸, 브라우저 등)로 화살표가 나가며, 플래너와 지식 모듈에서 LLM 컨텍스트로 정보를 주입하는 화살표가 들어오는 형태가 될 것입니다. 실제로 오픈소스 CodeActAgent 프로젝트는 이 아이디어와 일치하는 참조 구현을 제공합니다: (1) LLM 서버(vLLM을 사용해 모델을 API 뒤에 배치), (2) 에이전트가 생성한 코드를 세션별로 Docker 컨테이너에서 실행하는 코드 실행 서비스, (3) 대화를 중재하고 기록을 저장하는 프론트엔드/인터페이스(종종 데이터베이스 사용)로 구성되어 있습니다. Manus의 아키텍처는 여기에 추가적인 플래닝과 지식 컴포넌트가 더해진 상위 집합이지만, CodeAct의 설계를 기반으로 시작할 수 있습니다.

기반 모델 선택: Manus를 재현하려면, 가장 먼저 결정해야 할 것 중 하나가 에이전트의 두뇌 역할을 할 LLM(대형 언어 모델)을 무엇으로 할지입니다. Manus는 Claude 3.5와 Qwen 모델을 사용했습니다. 개인 개발자라면 Claude에 접근하기 어려울 수 있지만, 강력한 오픈소스 대안들이 있습니다. 유망한 방법은 연구팀이 공개한 오픈소스 CodeActAgent 모델을 사용하는 것입니다(이 모델은 7B Mistral 모델을 CodeAct 작업에 맞게 파인튜닝한 것임). 이 모델은 특히 파이썬 코드를 생성하고 실행하는 작업에 맞게 튜닝되어 있어 우리의 요구에 잘 부합합니다. 또한 큰 컨텍스트 윈도우(32k 토큰)를 지원해 이벤트 스트림과 플랜을 충분히 담을 수 있습니다. 더 강력한 기능이 필요하다면, GPT-4 API를 코어로 사용할 수도 있습니다(예를 들어 AutoGPT는 GPT-4로 에이전트를 구동합니다). 하지만 GPT-4에 의존하면 비용과 종속성 문제가 있으므로, 하이브리드 방식을 쓸 수도 있습니다: 대부분의 단계는 오픈소스 모델로 처리하고, 특히 어려운 하위 작업에만 GPT-4를 호출하는 식입니다(Manus의 멀티모델 호출 방식과 유사함). 어떤 모델을 쓰든, 중요한 것은 복잡한 시스템 프롬프트를 입력하고 함수 형태의 출력을 받을 수 있어야 한다는 점입니다. GPT-4, GPT-3.5, Claude, CodeActAgent, 파인튜닝된 Llama-2 등 모두 이 역할을 할 수 있습니다. 오픈소스 LLM을 사용할 경우, vLLM이나 FastChat처럼 OpenAI 호환 API를 제공하는 추론 서버에 모델을 호스팅하면 툴링 프레임워크와의 통합이 쉬워집니다.

툴 실행 환경: 다음으로, 샌드박스와 도구를 설정하는 것이 중요합니다. 에이전트에게 격리된 리눅스 환경을 제공하기 위해 Docker나 다른 컨테이너 기술을 사용할 수 있습니다(이렇게 하면 AI가 악의적이거나 잘못된 코드를 작성해도 호스트 시스템에 영향을 주지 않습니다). 그 컨테이너 안에는 필요한 소프트웨어, 예를 들어 Python, Node, 헤드리스 브라우저(예: Playwright나 Selenium을 통한 브라우저 자동화) 등을 설치합니다. Manus의 환경에는 Ubuntu, Python 3.10, Node.js 20, 그리고 기본적인 유닉스 유틸리티들이 포함되어 있었는데, 이는 좋은 템플릿이 됩니다. 웹 브라우징을 위해서는 Python으로 제어할 수 있는 헤드리스 브라우저를 사용하는 방법이 있습니다. playwright-python 같은 오픈소스 패키지를 사용하면 페이지를 열고, 요소를 클릭하고, 콘텐츠를 추출할 수 있습니다. 또는 더 단순하지만 제한적인 “브라우저 API”를 사용해 페이지의 HTML만 가져올 수도 있습니다(이 경우 AI가 HTML을 직접 파싱해야 함). 우리가 재현할 때는, requests나 자동화된 브라우저를 사용해 페이지 텍스트를 가져오는 open_url(url)이라는 Python 함수를 제공하고, 모델이 이를 호출하도록 할 수 있습니다. 셸 명령어를 안전하게 실행하려면, 특정 명령어만 노출하거나 모든 명령을 Python의 subprocess 인터페이스를 통해 실행하도록 할 수 있습니다. Manus의 규칙을 보면 패키지 설치나 시스템 수준 도구 실행 등에서 셸을 많이 사용하는데, 우리 에이전트도 이런 기능을 가져야 합니다. 예를 들어 run_shell(command)라는 함수를 만들어 컨테이너에서 명령을 실행하고(안전을 위해 출력은 잘라서 반환) 결과를 받을 수 있습니다. 이런 도구들은 사용하는 에이전트 프레임워크에 등록해야 합니다. 예를 들어 LangChain에서는 “Search”, “Browse”, “Execute Python” 등 각각의 기능에 대해 Tool 객체를 만들고, 에이전트가 호출할 수 있는 함수를 연결합니다. CodeAct 패러다임에서는 개별적인 툴 호출 대신, 모델이 생성한 코드에서 헬퍼 라이브러리를 import할 수 있도록 합니다. 예를 들어 agent_tools.py라는 Python 모듈을 만들어 search_web(query), get_url_content(url), run_shell(cmd) 같은 함수를 넣고, 실행 환경에 import agent_tools를 미리 추가합니다. 그러면 모델이 코드에서 agent_tools.search_web(”…”)처럼 호출하면, Python 백엔드가 실제로 검색을 수행하고 결과를 반환합니다. 이런 훅(hook)들을 세팅하는 데는 약간의 작업이 필요하지만, 일단 완료되면 모델은 사실상 액션을 위한 SDK를 갖게 됩니다. 주의할 점은, 예를 들어 네트워크 접근을 제한해 에이전트가 검증되지 않은 외부 URL을 임의로 호출하지 못하게 하고, 코드 실행에 시간/메모리 제한을 두어 무한 루프를 방지하는 등 안전장치를 반드시 포함해야 한다는 것입니다.

계획 수립 및 분해: 우리는 Manus의 플래너 모듈을 모방하고자 합니다. 가장 간단한 방법은 작업 시작 시 LLM에 다음과 같이 프롬프트를 주는 것입니다: “당신은 플래닝 어시스턴트입니다. 사용자의 목표는 X입니다. 이를 달성하기 위한 순서 있는 단계 목록으로 분해해 주세요.” 이 작업은 별도의 “플래닝 단계”에서 LLM을 호출해 수행할 수 있습니다(원한다면 더 저렴한 모델을 플래닝에 사용할 수도 있음). 그런 다음, 단계 목록을 메인 에이전트 프롬프트에 시스템 메시지로 전달합니다(예: “Plan: 1)… 2)… 등”). 또는, Manus의 프롬프트에서처럼 <planner_module>과 같은 섹션을 메인 프롬프트에 포함시켜 플래닝을 통합하고, 모델이 계획 이벤트를 업데이트하도록 지시할 수도 있습니다. 초기 구현에서는 외부 플래닝 호출이 더 이해하기 쉬울 수 있습니다. 출력된 계획은(컨텍스트 내에, 또는 Manus처럼 todo.md 파일에) 저장할 수 있습니다. 각 루프 반복마다, 에이전트에게 현재 진행 중인 단계를 상기시킬 수 있습니다(예: 프롬프트에 “Current Step: 3. Do XYZ”와 같은 문장을 포함). 이렇게 하면 에이전트가 집중할 수 있습니다. 계획은 종료 기준 또한 제공합니다 – 모든 단계가 완료되면 루프가 끝납니다. 재계획(Re-planning): 사용자가 요청을 변경하거나 예기치 않은 일이 발생하면, 계획을 다시 생성해야 할 수도 있습니다. Manus의 규칙에 따르면, 계획이 크게 변경되면 todo 리스트를 다시 작성합니다. 우리의 구현에서도, 사용자가 작업 중간에 새로운 지시를 내리면 이를 감지해 재계획을 트리거할 수 있습니다.

메모리 및 지식 통합: 지식 검색을 위해서는 자원에 따라 접근 방식을 결정해야 합니다. 한 가지 방법은 FAISS, Milvus 등과 같은 벡터 데이터베이스를 사용해 문서와 과거 대화의 임베딩을 저장하는 것입니다. 만약 에이전트의 작업과 관련된 사용법 가이드나 참고 매뉴얼 등 지식 베이스가 있다면, 이를 벡터로 색인화할 수 있습니다. 이후 사용자의 쿼리가 들어오면, 쿼리를 임베딩하여 관련 문서를 찾고, 이를 “Knowledge”라는 형태로 프롬프트에 앞부분에 추가합니다(Manus가 knowledge 이벤트를 삽입하는 방식과 유사함). LangChain은 이런 RAG 파이프라인을 위한 유틸리티를 제공합니다. 웹 검색의 경우, 전체 웹 인덱스를 유지할 수 없으므로, 에이전트는 SerpAPI, Bing Web Search API 등 검색 API를 사용해 결과를 가져옵니다. 코드나 툴 호출로 상위 N개의 결과를 받아오고, 각 결과에 대해 페이지 텍스트(길면 앞부분이나 요약만)를 가져와 다시 전달할 수 있습니다. 모델은 그 중 어떤 링크를 더 클릭할지 결정할 수 있습니다(Manus의 프롬프트에는 포괄적인 정보를 위해 여러 링크를 열고, 한 소스만 신뢰하지 말라고 명시되어 있음). 따라서 우리 에이전트도 마찬가지로, 초기 검색 후 결과를 반복하며 각 링크에 open_url을 호출해 내용을 읽도록 해야 합니다. 또한 프롬프트를 통해 에이전트가 중요한 정보를 발견하면 notes.txt와 같은 파일에 저장해 컨텍스트를 비우도록 유도해야 합니다. 실제로 Manus의 파일 사용 방식을 모방할 수 있습니다: 에이전트가 중요한 정보를 찾으면 파일 쓰기 툴을 사용해 파일에 기록하고, 이후에는 대화 내에 모든 텍스트를 남기지 않고 해당 파일만 참조하도록 지시합니다. 긴 대화를 관리하려면 요약이 필요할 수도 있습니다. 예를 들어, 이벤트 스트림(대화 로그)이 너무 커지면, 에이전트(또는 자동화된 프로세스)가 이전 부분을 요약하도록 정책을 둘 수 있습니다. 이 작업을 완전히 자동화하는 것은 다소 복잡하지만, 추가 LLM 호출로 이벤트를 압축해 “Compression event”로 컨텍스트에 넣는 방식으로 구현할 수 있습니다. 이런 전략들은 Manus가 컨텍스트 한계 내에서 대규모 작업을 처리할 때 실제로 사용하는 방식일 가능성이 높습니다.

프롬프트 설계: 우리는 Manus의 정신을 반영한 시스템 프롬프트를 만들어야 합니다. 프롬프트는 에이전트의 역할과 능력에 대한 설명(“당신은 도구 XYZ를 사용해 작업을 수행할 수 있는 자율 AI 에이전트입니다…”)으로 시작해야 합니다. 그리고 Manus에서 영감을 받은 주요 규칙들을 포함해야 합니다. 예를 들어, 도구 사용: “최종 결과를 전달할 때를 제외하고 항상 액션(행동)으로 응답할 것”, 정보 출처: “일반 웹 콘텐츠보다 제공된 API나 공식 소스의 신뢰할 수 있는 데이터를 우선 사용하고, 결과물에 출처를 명시할 것”, 스타일: “공식적인 어조를 사용하고, 요청받지 않는 한 목록(lists)을 피하며, 설명은 상세하게 작성할 것” 등입니다. Manus의 유출된 프롬프트에 있는 많은 규칙들은 에이전트의 모범 사례를 나타내므로, 그대로 재사용하거나 바꿔서 사용할 수 있습니다. 예를 들어, 시스템 메시지나 내부 로직을 사용자에게 공개하지 않는 규칙은 매우 중요합니다(사용자가 프롬프트 인젝션을 통해 에이전트의 프롬프트를 보지 못하게 하기 위함). 또한, 작업 수신 확인 및 주기적인 진행 상황 업데이트 제공에 관한 규칙도 있습니다(Manus는 “notify”와 “ask” 메시지 타입을 구분해, 진행 상황 알림과 사용자 질문을 구별함). 구현에서는 notify/ask 구분이 있는 별도의 메시징 UI를 반드시 구현하지 않아도 되지만, 에이전트가 긴 작업을 수행할 때 가끔 간단한 진행 상황 업데이트를 출력하는 것도 좋습니다. 프롬프트를 작성할 때는 Manus처럼 각 도구별로 사용 지침이 포함된 섹션을 모듈화하는 것이 좋습니다. 이렇게 하면 도구 구현을 교체할 때 해당 섹션만 수정하면 되므로, 사실상 AI를 위한 문서 역할을 하게 됩니다. 또한, 토큰 여유가 있다면 프롬프트에 몇 가지 few-shot 예시(예: 사용자 요청, 그에 따른 이상적인 사고 과정(행동 및 관찰), 최종 답변)를 포함할 수 있습니다. 이는 모델에게 응답 패턴을 학습시키는 데 도움이 됩니다. CodeAct 논문의 저자들도 파인튜닝 시 이런 방식을 사용했으며, 코드-액트 기법을 보여주는 다중 턴 상호작용 데이터셋도 공개했습니다. 이런 데이터를 활용해 선택한 모델을 추가로 파인튜닝하면 성능이 크게 향상될 수 있습니다. 파인튜닝이 어렵다면, 예시가 포함된 잘 설계된 프롬프트만으로도 기본 모델의 동작을 충분히 유도할 수 있습니다.

개발 워크플로우: Manus와 유사한 에이전트를 만드는 것은 반복적인 소프트웨어 프로젝트입니다. 가능한 워크플로우는 다음과 같습니다.

기본 루프부터 시작: LLM이 한두 개의 더미 도구를 호출할 수 있는 간단한 루프를 구현합니다. 예를 들어, 수학 문제를 받아 Python REPL 도구로 계산하게 해보세요. 이렇게 하면 모델과 도구 실행의 통합을 테스트할 수 있습니다.
도구를 점진적으로 추가: 웹 검색, 파일 I/O, 셸 등 더 많은 도구 기능을 하나씩 추가하고, 각 도구를 추가할 때마다 프롬프트에 사용법을 업데이트하고 관련 작업으로 에이전트를 테스트합니다. 예를 들어, 웹 검색을 추가한 후에는 정보를 찾아야 하는 질문을 에이전트에게 해보세요. 에이전트가 도구를 올바르게 사용하는지 모니터링합니다.
로깅 및 관찰 처리 구현: 모든 행동과 결과가 기록되도록 합니다(디버깅과 모델에 피드백을 주기 위함). 로그는 구조화된 형식을 사용하세요. 이는 행동 조정에 도움이 됩니다. Manus의 이벤트 스트림은 코드에서 이벤트 목록을 유지하고, 각 사이클마다 이를 프롬프트에 연결하는 방식으로 모방할 수 있습니다.
계획 수립 통합: 기본적인 인식과 행동이 동작하면, 플래닝 모듈을 개발합니다. 기존의 태스크 플래너를 통합하거나 LLM 자체를 사용해도 됩니다(“먼저 단계를 개요로 작성” 등). 에이전트가 계획을 보여주고 이를 따르도록 하세요. 에이전트가 계획을 무시하는 경향이 있다면 프롬프트 지침을 조정합니다. 이상적으로는, 에이전트가 계획을 염두에 두고 진행 상황을 업데이트해야 합니다. 완료된 단계를 표시하며 계획을 명시적으로 출력하게 할 수도 있습니다.
메모리/RAG 추가: 간단한 벡터 스토어를 연결하고 검색을 테스트합니다. 예를 들어, 에이전트에게 정보를 담은 문단을 주고 대화를 종료한 뒤, 새 대화에서 그 정보를 요청해 보세요. 에이전트가 저장소에서 정보를 불러올 수 있는지 확인합니다. 또는 문서를 입력시킨 뒤, 그 문서를 인용해야 하는 질문을 해보세요. 검색된 내용을 컨텍스트에 유용하게 삽입하는 파이프라인을 미세 조정하세요(예: “Reference:” 태그를 앞에 붙이기).
프롬프트와 정책 다듬기: 다양한 시나리오로 테스트하면서 문제점을 발견하게 됩니다. 예를 들어, 에이전트가 쓸모없이 반복 루프에 빠지거나 잘못된 도구를 사용할 수 있습니다. 더 많은 규칙을 추가하거나(혹은 특정 행동을 하드코딩) 해야 할 수도 있습니다. 예를 들어, 초기 Manus 베타 테스터들은 일부 오류에서 무한 루프에 빠지는 현상을 발견했습니다. 동일한 행동이 3번 반복되어도 성공하지 않으면 중단하고 사용자에게 안내를 요청하는 안전장치를 둘 수 있습니다. 또는 외부 웹사이트가 로딩되지 않으면 다른 소스를 시도하게 할 수 있습니다. 이런 문제들은 프롬프트를 통한 에이전트의 추론 개선으로 해결할 수 있지만, 일부는 외부 개입(예: 루프가 너무 오래 지속되면 중단하는 감독 함수)이 필요할 수 있습니다. Manus 팀도 프라이빗 베타 기간에 이런 예외 케이스를 해결한 것으로 보입니다(문제 수정 중이라고 언급함).
인터페이스 및 통합: 마지막으로, 에이전트 주위에 사용자 인터페이스나 API를 구축합니다. Manus는 웹 앱/디스코드 등으로 제공되지만, 복제 구현에서는 콘솔이나 간단한 채팅 웹 UI만 사용해도 됩니다. 중요한 것은 백엔드 로직입니다. 사용자가 작업을 POST할 수 있는 API 엔드포인트를 만들고, 에이전트가 루프를 시작해 주기적으로 메시지나 최종 결과를 전송하게 하세요. 장시간 실행되는 작업을 처리하는 방법도 고려해야 합니다. 일부 작업(코딩, 디버깅 등)은 몇 분 이상 걸릴 수 있으므로 비동기 처리나 백그라운드 작업 큐가 필요할 수 있습니다.

오픈소스 프로젝트 활용: 여러 오픈소스 에이전트 프레임워크가 지름길을 제공하거나 최소한 영감을 줄 수 있습니다.

LangChain – 도구 정의와 도구를 선택하는 에이전트의 뼈대를 많이 제공합니다. LangChain의 AgentExecutor를 커스텀 LLM과 커스텀 도구와 함께 사용할 수 있습니다. LangChain은 CodeAct 스타일(계획→도구 호출 문자열)을 기본적으로 지원하지는 않지만, 여러 단계의 도구 사용을 처리하는 데 여전히 쓸 수 있습니다. 검색 도구나 파이썬 실행 도구 같은 것을 직접 구현하지 않고도 빠르게 사용할 수 있는 방법입니다.
AutoGPT – 이 유명한 프로젝트는 이미 GPT-4(또는 3.5)를 사용한 자율 루프를 구현하고 있습니다. 작업 목록(플랜), 벡터 DB를 활용한 메모리, 웹 브라우징 및 파일 I/O 통합 등의 기능이 있습니다. 다만, AutoGPT의 코드베이스는 다소 방대하고 실험적으로 급하게 성장한 면이 있어 다소 복잡하다는 평이 있습니다. 그래도 코드를 연구하거나, 다른 LLM 백엔드로 포크해서 사용할 수 있습니다. AutoGPT는 AI가 자신의 계획을 비판적으로 검토하는(“critic thoughts”) 방식을 사용하는데, 이는 신뢰성을 높이는 또 다른 아이디어입니다.
BabyAGI – 작업 목록 실행에 초점을 맞춘 또 다른 오픈 프로젝트입니다. BabyAGI는 더 단순해서, 작업 목록을 유지하고 항상 맨 위의 작업을 실행하며, 필요에 따라 새로운 작업을 추가하고, 각 작업을 LLM이 수행한 뒤 목록을 업데이트합니다. 이는 Manus의 방식과는 다소 다르지만, 목표를 세분화하는 개념은 공유합니다. BabyAGI에서 작업 목록을 유지하고 우선순위를 재조정하는 개념을 참고할 수 있습니다.
CodeActAgent – Manus가 “CodeAct” 논문을 명시적으로 참조하고 있으므로, 저자들이 공개한 오픈 구현을 사용하는 것이 매우 적합합니다. CodeActAgent(특히 그들이 제공하는 파인튜닝된 모델)는 도구 사용을 위해 코드를 출력하는 에이전트 시나리오에 딱 맞게 설계되어 있습니다. 이 모델과 코드를 사용하면, API 호출 방법, 코드 액션 포맷 등 Manus의 핵심 기능을 상당 부분 바로 사용할 수 있습니다. 여기에 플래닝과 메모리 기능을 추가로 연결하면 됩니다. CodeAct 저장소에는 샘플 채팅 UI와, 확장성을 위한 Kubernetes 배포 가이드도 포함되어 있습니다. 본질적으로 CodeActAgent는 오픈소스 미니 Manus(Manus의 일부 독점적 완성도를 제외한)라고 할 수 있습니다.

API 통합 고려사항: 에이전트가 외부 서비스를 사용해야 한다면(예: GPT-4를 위한 OpenAI API 호출이나 유료 API 사용 등), 키와 쿼터를 신중하게 관리해야 합니다. 실제 Manus 서비스도 검색이나 위치 데이터용 API 키를 모델로부터 숨긴 채 사용했을 가능성이 높습니다(모델은 단순히 함수를 호출하고, 서버 측 코드가 자격증명을 붙임). 마찬가지로, 절대 API 키를 프롬프트에 넣지 마세요. 모델이 키를 유출할 수 있으니, 도구 구현 코드에만 키를 보관해야 합니다. 또한, 도구 사용에 대한 속도 제한(rate limiting)을 구현해 에이전트가(악의적이거나 실수로) API를 반복 호출하지 못하게 해야 합니다. Manus 역시 웹사이트를 DOS하거나 유료 API를 무한 루프로 호출하지 않도록 안전장치를 두었을 것입니다.

테스트 및 평가: 마지막으로, Manus와 유사한 에이전트가 제대로 동작하는지 확인하려면, Manus가 처리할 수 있다고 주장하는 다양한 작업으로 테스트해야 합니다. 예를 들어, _“주제 X에 대해 인용이 포함된 5페이지 분량의 연구 보고서를 작성하라”_와 같은 요청을 해보세요. 에이전트가 검색, 정보 취합, 출처가 포함된 구조화된 보고서 작성까지 할 수 있는지 확인합니다(이를 위해 충분한 컨텍스트나 지식 베이스를 제공해야 할 수도 있음). 또는 _“Y 기능을 하는 간단한 웹앱을 만들어라”_와 같이 파일 생성, 코드 작성, 서버 실행, URL 제공까지 할 수 있는지 테스트해보세요(이 과정에서 배포/도구 통합 능력을 확인할 수 있음). 실패 상황도 의도적으로 테스트해야 합니다. 예를 들어, 에이전트가 하면 안 되는 일을 시키거나(Manus는 프롬프트에 윤리적 가이드라인이 있음), 불가능한 작업을 시켜보세요. 이런 경우, 에이전트가 무한 반복에 빠지지 않고 결국 “할 수 없다”고 답해야 합니다. 초기 사용자 리뷰에 따르면, Manus는 때때로 사실 오류를 내거나 음식 주문, 항공권 예약 등 거래를 끝까지 완료하지 못하는 경우가 있었습니다(일부만 진행하고 끝남). 이런 시나리오를 활용해 에이전트의 부족한 점을 파악하세요. 예를 들어, 결제 정보를 입력하는 기능이 없거나, 안전상의 이유로 허용되지 않았을 수도 있습니다. 어떤 부분을 자동화하지 않을지 설계 단계에서 결정할 수 있습니다. 예를 들어, 실제로 “구매” 버튼을 클릭하는 기능은 의도적으로 비활성화해 실세계에 영향을 주지 않도록 하고, 대신 링크나 안내만 제공하게 할 수 있습니다. 이런 경계는 프롬프트에 명확히 명시해야 합니다(Manus의 프롬프트에도 “최종 확인”과 같은 민감한 작업은 사용자가 직접 하도록 요청하라는 내용이 있음).

결론적으로, Manus와 같은 자율 에이전트를 만드는 것은 복잡하지만 오픈소스 도구를 사용해 충분히 실현 가능한 프로젝트입니다. 오픈소스 도구를 사용하여 구현할 때 핵심 단계는 다음과 같습니다: 유능한 LLM을 선택하고, 에이전트로서 어떻게 행동해야 하는지 잘 안내하는 프롬프트(또는 파인튜닝)를 제공하며, 안전하게 실험할 수 있는 도구 환경(코드, 웹 등)을 마련하고, 목표를 향해 계속 진행할 수 있도록 루프 구조를 구현하는 것입니다. Manus는 기존 AI 구성요소(Claude 등)를 적절히 조합하고 신중하게 통합함으로써, AI가 스스로 적극적으로 작업을 완수하는 “디지털 직원”으로 변신할 수 있음을 보여주었습니다. 여기서 제시한 아키텍처와 기법(Manus의 설계와 관련 연구에서 도출)을 따르면, 유사한 에이전트형 AI 시스템을 재현할 수 있습니다. 처음부터 Manus의 모든 성능을 완벽히 따라가지는 못하겠지만, 반복적인 개선과 커뮤니티의 기여(초기 사용자들의 열정적인 역공학 사례처럼)를 통해, 오픈소스 Manus에 준하는 시스템이 등장할 수 있으며, 이는 자율 AI 에이전트의 역량을 투명하게 한 단계 끌어올릴 수 있습니다.

Manus AI 에이전트 보고서

TLDR: Manus AI 에이전트 보고서

Manus 자율 AI 에이전트: 기술 분석

1. 시스템 아키텍처 분석

2. 기술 구성요소

3. 구현 전략 (오픈 소스 도구로 Manus 재현하기)

Source:

On this Page

Manus AI 에이전트 보고서

TLDR: Manus AI 에이전트 보고서 ￼

Manus 자율 AI 에이전트: 기술 분석 ￼

1. 시스템 아키텍처 분석 ￼

2. 기술 구성요소 ￼

3. 구현 전략 (오픈 소스 도구로 Manus 재현하기)

Source:

On this Page

TLDR: Manus AI 에이전트 보고서

Manus 자율 AI 에이전트: 기술 분석

1. 시스템 아키텍처 분석

2. 기술 구성요소