문제 해결과 고급 운영 노하우

실패를 빨리 알아차리는 사람이 Manus를 오래 쓴다

Manus를 능숙하게 쓰는 사람은 프롬프트를 화려하게 쓰는 사람이 아닙니다. 오히려 반대에 가깝습니다. 오래 쓰는 사람일수록 지시문은 담백하고, 작업은 작게 나누고, 중간 결과를 자주 저장합니다. 그리고 무엇보다 Manus가 잘못된 길로 가고 있다는 신호를 빠르게 알아차립니다.

처음에는 누구나 이런 생각을 합니다. '조금만 더 기다리면 끝나겠지.' '같은 프롬프트를 다시 보내면 이번에는 되겠지.' '답이 이상하니 재생성하면 좋아지겠지.' 하지만 Agent Mode에서 이 방식은 크레딧과 시간을 빠르게 태웁니다. Manus는 단순한 답변 생성기가 아니라 웹을 열고, 파일을 읽고, 코드를 실행하고, 샌드박스에서 작업을 이어 가는 실행형 에이전트입니다. 따라서 문제가 생겼을 때는 채팅을 다시 보내는 것보다 작업 상태를 진단하는 것이 먼저입니다.

이 장의 핵심은 한 문장입니다.

Manus 운영의 실력은 실패하지 않는 데서 나오지 않고, 실패를 작게 만들고 빠르게 복구하는 데서 나온다.

멈춤, 반복 루프, 부정확한 결과, 샌드박스 연결 문제, 과도한 크레딧 소모는 모두 Manus를 쓰다 보면 만나는 자연스러운 운영 이슈입니다. 중요한 것은 당황하지 않고 같은 순서로 확인하는 것입니다.

문제를 네 층으로 나누어 본다

Manus가 멈춘 것처럼 보일 때 원인은 하나가 아닙니다. 내 브라우저가 멈췄을 수도 있고, Manus 서비스가 일시적으로 느려졌을 수도 있고, 샌드박스가 끊겼을 수도 있고, 프롬프트 자체가 너무 복잡해 Manus가 다음 행동을 결정하지 못했을 수도 있습니다. 외부 모니터링 서비스도 Manus의 웹, API, 컴퓨터 구성 요소 상태를 나누어 추적하고 장애 이력을 기록합니다. 이는 사용자가 겪는 문제가 항상 개인 환경의 문제가 아닐 수 있음을 보여 줍니다.¹

처음부터 원인을 단정하지 말고 다음 네 층으로 나누어 보세요.

이렇게 나누면 해결 순서가 보입니다. 화면 문제라면 재시작이 맞고, 서비스 문제라면 기다리거나 시간대를 바꾸는 것이 맞습니다. 하지만 작업 설계 문제라면 아무리 새로고침을 해도 해결되지 않습니다. 그때는 프롬프트를 고쳐야 합니다.

멈췄을 때는 같은 프롬프트를 다시 보내지 않는다

Manus가 멈추면 가장 하고 싶은 행동은 같은 프롬프트를 다시 보내는 것입니다. 그러나 긴 작업에서는 이것이 가장 비싼 실수일 수 있습니다. 같은 작업을 처음부터 다시 시작하면 이미 완료한 웹 탐색, 파일 분석, 코드 실행, 보고서 초안 작성이 반복됩니다. 크레딧도 다시 쓰고, 운이 나쁘면 두 번째 작업도 같은 지점에서 멈춥니다.

먼저 오류 메시지와 실행 로그를 봅니다. 화면에 server busy, connection lost, internal server error, high load, file not found, permission denied 같은 메시지가 있는지 확인합니다. 그다음 Manus의 사고 과정, 실행 단계, 브라우저 방문 기록, 터미널 출력, 파일 생성 기록을 살핍니다. 중요한 질문은 하나입니다. 어디까지는 성공했고, 어디서부터 멈췄는가?

멈춤 복구는 다음 순서로 진행하는 것이 안전합니다.

이때 사용할 수 있는 복구 요청문은 다음과 같습니다.

작업이 멈춘 것 같습니다.
같은 작업을 처음부터 다시 시작하지 마세요.
먼저 지금까지의 진행 상황을 요약하세요.

다음 항목을 알려 주세요.
1. 마지막으로 성공한 단계
2. 실패하거나 멈춘 단계
3. 사용한 파일, URL, 코드, 명령
4. 현재 남아 있는 중간 산출물의 파일 경로
5. 이어서 진행할 수 있는 가장 작은 다음 행동

가능하다면 현재 상태에서 이어서 진행하세요.
불가능하다면 재시작에 필요한 체크포인트 파일을 만들어 주세요.

이 프롬프트의 목적은 Manus를 '다시 시작 모드'가 아니라 '복구 모드'로 전환하는 것입니다. 사람에게 일을 맡겼을 때도 마찬가지입니다. 인턴이 보고서 80%를 만들다가 컴퓨터가 꺼졌는데, 다시 처음부터 조사하라고 시키지는 않습니다. 어디까지 했는지 확인하고 거기서 이어 가게 해야 합니다.

server busy와 connection lost를 다루는 법

server busy는 Manus가 요청을 처리할 여유가 부족하다는 신호일 수 있습니다. connection lost는 사용자의 화면과 작업 환경 사이의 연결이 끊겼다는 뜻일 수 있습니다. 둘은 비슷해 보이지만 대응은 조금 다릅니다.

server busy가 보이면 일단 무리하게 재시도하지 않습니다. 같은 요청을 여러 번 누르면 작업 대기열이 꼬이거나 중복 작업이 생길 수 있습니다. 몇 분 기다린 뒤, 작업이 계속 살아 있는지 확인합니다. 팀에서 여러 명이 동시에 비슷한 증상을 겪고 있다면 개인 문제가 아니라 서비스 측 문제일 가능성이 큽니다. 급하지 않은 대규모 리서치, 웹사이트 빌드, 슬라이드 자동 제작은 피크 시간대를 피해 실행하는 편이 안정적입니다.

connection lost가 보이면 먼저 내 쪽 연결을 확인합니다. 브라우저 탭을 새로고침하고, 데스크톱 앱이라면 완전히 종료한 뒤 다시 엽니다. 웹 버전이라면 다른 브라우저나 시크릿 창에서도 같은지 확인할 수 있습니다. 다만 새 작업을 만들기 전에 기존 작업 화면이 복구되는지 먼저 확인하세요.

복구 후에는 Manus에게 바로 이렇게 묻습니다.

방금 연결이 끊겼습니다.
현재 작업 상태를 점검하세요.
새로운 작업을 시작하지 말고, 기존 작업에서 이어갈 수 있는지 확인하세요.
중간 파일과 마지막 실행 결과를 먼저 보여 주세요.

이 작은 문장이 중요합니다. 연결이 끊긴 뒤 사용자가 성급하게 '계속해'라고만 말하면 Manus는 현재 상태를 충분히 확인하지 않고 다음 단계로 넘어갈 수 있습니다. 그러면 앞 단계가 실제로 완료되지 않았는데 완료된 것으로 착각하는 일이 생깁니다.

샌드박스가 끊겼을 때 잃지 않게 운영한다

Manus는 사용자의 지시를 처리하기 위해 격리된 가상 작업 환경, 즉 샌드박스에서 파일 작업, 브라우저 작업, 코드 실행 등을 수행합니다. Manus 도움말은 샌드박스가 작업 실행을 위한 격리 환경이며, 연결 문제가 길어질 경우 자동 리셋이 일어날 수 있다고 설명합니다. 또한 작업 진행 기록은 보호될 수 있지만, 샌드박스 가상 머신 리셋 과정에서는 내부 파일 손실이 발생할 수 있다는 점도 함께 안내합니다.²

따라서 실무에서는 이렇게 이해하는 것이 안전합니다.

대화 기록은 남을 수 있지만, 샌드박스 안의 임시 파일은 언제든 사라질 수 있다고 가정한다.

이 가정으로 운영하면 습관이 달라집니다. 중요한 산출물이 만들어졌을 때 바로 내려받고, 중간 파일의 경로를 기록하고, 실행한 명령과 현재 상태를 별도 요약으로 남깁니다. 긴 작업을 맡길 때는 Manus에게 작업 폴더 안에 다음 파일을 만들게 하는 것이 좋습니다.

특히 state_snapshot.md는 장기 작업의 보험입니다. 다음 요청문을 Knowledge나 즐겨찾는 프롬프트로 저장해 두세요.

지금부터 긴 작업을 진행합니다.
각 주요 단계가 끝날 때마다 state_snapshot.md를 업데이트하세요.
다음 내용을 반드시 포함하세요.

1. 현재 목표
2. 완료한 단계
3. 아직 하지 않은 단계
4. 사용한 입력 파일과 경로
5. 생성한 출력 파일과 경로
6. 실행한 주요 명령 또는 코드 파일
7. 발견한 오류와 우회 방법
8. 다음에 이어서 할 가장 작은 작업

샌드박스 연결이 끊겨도 이 파일만 보면 이어서 진행할 수 있어야 합니다.

이 방식은 귀찮아 보이지만, 한 번만 큰 작업을 잃어 보면 바로 이해됩니다. 리서치 40분, 데이터 전처리 20분, 차트 생성 10분을 날리는 것보다 체크포인트 파일 하나를 만드는 편이 훨씬 쌉니다.

루프는 세 번 반복되면 개입한다

Manus가 같은 검색어를 반복해서 검색하거나, 같은 버튼을 계속 클릭하거나, 같은 코드를 조금씩 바꿔 실행하거나, 비슷한 문장만 반복해 출력하는 순간이 있습니다. 이것을 루프라고 부릅니다. Manus형 에이전트의 오픈소스 사례에서도 도구를 선택하지 못한 채 selected 0 tools to use 같은 상태가 반복되거나, 사용 가능한 도구 설명만 되풀이하는 문제가 보고된 바 있습니다.³

루프는 오래 기다린다고 자연스럽게 풀리지 않는 경우가 많습니다. 사용자는 '열심히 일하는 중'으로 보지만, 실제로는 같은 실패를 반복하고 있을 수 있습니다. 기준은 간단합니다.

동일한 검색, 클릭, 코드 실행, 응답 생성이 세 번 이상 반복되면 루프로 판단한다.

루프를 발견하면 '왜 아직 안 끝났어?'라고 묻기보다, 바로 행동 방식을 바꾸라고 지시해야 합니다.

루프 차단 모드로 전환하세요.
방금 시도한 방법을 중단하세요.

먼저 다음을 요약하세요.
1. 반복된 행동은 무엇이었는가
2. 그 방법이 실패한 이유는 무엇인가
3. 현재 목표를 달성하는 다른 접근법 2가지는 무엇인가
4. 각 접근법의 장단점은 무엇인가
5. 지금 선택할 가장 안전하고 짧은 다음 행동은 무엇인가

같은 검색어, 같은 클릭, 같은 코드 실행을 반복하지 마세요.
새 접근법을 선택하기 전에는 내 승인을 기다리세요.

루프 차단의 핵심은 Manus에게 '계속해'가 아니라 '멈추고 관찰하라'고 말하는 것입니다. 에이전트는 목표를 향해 움직이도록 설계되어 있기 때문에, 목표가 모호하면 엉뚱한 방식으로 계속 움직일 수 있습니다. 이때는 관찰, 판단, 다음 행동을 다시 정렬해야 합니다.

루프의 종류에 따라 대응도 달라집니다.

루프는 Manus의 실패라기보다 운영자의 개입 시점을 알려 주는 신호입니다. 세 번 반복되면 멈추세요. 다섯 번, 열 번까지 기다리는 것은 인내심이 아니라 크레딧 낭비입니다.

부정확한 결과는 재생성보다 검증 절차로 고친다

결과가 이상할 때 '다시 만들어 줘'라고 말하면 가끔 좋아집니다. 하지만 중요한 작업에서는 위험합니다. 재생성은 오류를 고치는 것이 아니라 다른 버전의 오류를 만들 수 있습니다. 숫자는 바뀌었지만 근거가 사라지고, 문장은 자연스러워졌지만 출처가 더 약해질 수도 있습니다.

정확도 문제는 재생성이 아니라 검증 절차로 다뤄야 합니다. 원본 데이터, 출처 범위, 계산식, 코드 실행 결과, 상충 자료, 불확실한 항목을 분리해서 확인해야 합니다.

다음 프롬프트는 부정확한 결과를 다시 잡을 때 유용합니다.

검증 모드로 전환하세요.
결과물을 바로 다시 쓰지 말고, 먼저 오류 가능성을 점검하세요.

다음 표를 만드세요.
1. 결과물의 핵심 주장 또는 수치
2. 근거가 되는 원본 파일, 행, 열, URL, 문서 위치
3. 사용한 계산식 또는 추론 과정
4. 직접 확인 여부
5. 상충되는 자료가 있는지
6. 확실함, 불확실함, 확인 불가 중 하나의 상태
7. 수정 제안

원본에서 직접 확인하지 못한 내용은 단정하지 마세요.
확인 불가 항목은 본문에서 제거하거나 별도 표시하세요.

데이터 분석이라면 계산을 다시 실행하게 해야 합니다.

원본 데이터에서 최종 수치가 만들어지는 과정을 다시 재현하세요.
필터 조건, 제외한 행 수, 결측값 처리, 중복 제거 기준, 계산식을 모두 표시하세요.
가능하면 같은 계산을 코드로 한 번 더 실행하고 결과를 비교하세요.

웹 리서치라면 출처 범위를 제한합니다.

공식 문서, 기업 공시, 정부·공공기관, 학술자료를 1순위 출처로 사용하세요.
블로그, 커뮤니티, 광고성 글은 보조 참고로만 사용하세요.
서로 다른 출처의 수치가 충돌하면 하나로 합치지 말고 충돌표를 만드세요.

파일 내용 요약이라면 근거 위치를 요구합니다.

첨부 파일 요약을 검증하세요.
각 요약 문장마다 근거가 되는 파일명, 페이지, 섹션, 표 제목 또는 행 번호를 표시하세요.
파일에서 찾을 수 없는 내용은 추정으로 표시하고, 최종 요약에서 제외하세요.

중요한 수치, 인용, 파일 내용은 Manus가 직접 확인한 근거와 함께 제출하게 해야 합니다. '그럴듯함'은 검증이 아닙니다. 근거 위치가 있어야 검증입니다.

긴 작업은 체크포인트 방식으로 운영한다

Manus에게 '시장 조사부터 보고서와 슬라이드까지 한 번에 만들어 줘'라고 맡기고 싶을 때가 있습니다. 가능할 때도 있습니다. 그러나 긴 작업일수록 맥락 손실, 루프, 파일 손실, 크레딧 과소비 가능성이 커집니다.

안정적인 운영 패턴은 다음과 같습니다.

여기서 중요한 것은 목표를 세 개 이내로 제한하는 것입니다. 하나의 작업에 시장 조사, 고객 세분화, 광고 카피, 웹사이트 제작, 이메일 발송, 성과 대시보드까지 모두 넣으면 Manus는 열심히 움직이지만 결과가 흐려집니다. 목표가 많을수록 완료 조건도 모호해집니다.

긴 작업 시작 프롬프트는 이렇게 쓸 수 있습니다.

이 작업은 긴 작업이므로 체크포인트 방식으로 진행하세요.

핵심 목표는 다음 3개입니다.
1. 경쟁사 5곳의 가격과 기능 조사
2. 비교표와 핵심 인사이트 작성
3. 10장 이내 발표 슬라이드 초안 구성

완료 조건은 다음과 같습니다.
- 각 경쟁사마다 공식 출처 URL이 1개 이상 있어야 합니다.
- 확인 불가 항목은 추정하지 않고 표시해야 합니다.
- 슬라이드는 제목, 핵심 메시지, 필요한 시각자료 설명까지만 작성합니다.

중단 조건은 다음과 같습니다.
- 공식 출처를 3곳 이상 찾지 못하는 경우
- 같은 검색이 3회 이상 반복되는 경우
- 로그인이 필요한 페이지에 막히는 경우
- 예상보다 작업 범위가 커지는 경우

먼저 전체 계획만 제시하고 내 승인을 기다리세요.
승인 후에는 1단계만 실행하고 중간 산출물을 저장하세요.

이 프롬프트는 Manus의 자율성을 줄이는 것이 아닙니다. 오히려 더 잘 쓰기 위한 레일을 깔아 주는 것입니다. 기차가 레일 위에서 가장 빠르듯, 에이전트도 명확한 단계와 정지 조건이 있을 때 더 안정적으로 움직입니다.

크레딧이 과도하게 소모될 때 확인할 것

크레딧이 많이 쓰였다는 것은 Manus가 많은 일을 했다는 뜻일 수 있습니다. 하지만 많은 일이 곧 좋은 일은 아닙니다. 불필요한 웹 탐색, 반복 실행, 대용량 파일 처리, 모호한 목표, 과도한 재생성이 겹치면 결과는 별로인데 크레딧만 빠르게 줄어듭니다.

Manus 도움말은 크레딧을 아끼기 위해 관련 질문을 묶고, 지시를 명확하고 간결하게 만들며, 같은 질문을 무작정 반복하지 말고 초기 응답을 바탕으로 수정하라고 안내합니다.⁴ 여기서 한 가지 균형이 필요합니다. 작은 질문을 매번 새 작업으로 만드는 것도 낭비이고, 너무 큰 일을 한 번에 던지는 것도 낭비입니다.

구분은 이렇게 하면 됩니다.

크레딧 과소비의 원인과 처방은 다음 표처럼 정리할 수 있습니다.

크레딧 절약 모드는 프롬프트에 직접 넣는 것이 좋습니다.

크레딧 절약 모드로 작업하세요.

제한 조건은 다음과 같습니다.
1. 웹 검색은 최대 8회까지만 수행합니다.
2. 우선 확인할 사이트 목록을 먼저 제안하고 승인 후 진행합니다.
3. 코드 실행은 최대 5회까지만 반복합니다.
4. 전체 파일 처리 전에 샘플 50행으로 먼저 테스트합니다.
5. 최종본을 만들기 전에 목차와 출력 형식을 먼저 확인받습니다.
6. 목표 달성이 어렵다고 판단되면 계속 시도하지 말고 중단 사유를 보고합니다.

이 제한은 Manus를 답답하게 만드는 장치가 아닙니다. 비용과 품질을 동시에 지키는 운영 장치입니다.

실전 문제 해결 라이브러리

Manus를 오래 쓰면 비슷한 문제가 반복해서 나타납니다. 아래 사례들은 실제 업무에서 바로 쓸 수 있는 복구 방식입니다.

사례 1: Wide Research가 거의 끝나 갈 때 실패했다

대규모 리서치가 18단계쯤 진행된 뒤 멈추면 가장 아깝습니다. 이때 처음부터 다시 실행하면 같은 자료를 다시 찾고, 같은 페이지를 다시 읽고, 같은 요약을 다시 만들 수 있습니다. 먼저 현재까지 수집한 출처와 중간 요약을 고정해야 합니다.

Wide Research 작업이 중간에 실패했습니다.
처음부터 다시 시작하지 마세요.
현재까지 수집한 모든 출처, 요약, 표, 미완성 메모를 정리하세요.
완료된 항목과 미완성 항목을 나누고, 남은 작업만 새 계획으로 제안하세요.

핵심은 '전체 재실행'이 아니라 '남은 범위 재실행'입니다. 출처 30개 중 24개를 이미 정리했다면 나머지 6개와 결론 통합만 하면 됩니다.

사례 2: 보고서가 그럴듯하지만 출처가 약하다

Manus가 만든 보고서는 문장이 좋을수록 위험합니다. 출처가 없는 확신 문장은 외부 공개용으로 쓸 수 없습니다.

보고서 문장을 개선하지 말고 출처 검증부터 하세요.
모든 핵심 주장에 대해 근거 URL, 확인 날짜, 원문 위치를 붙이세요.
근거가 약한 문장은 삭제 후보로 표시하세요.
상충 자료가 있으면 결론을 단정하지 말고 비교표로 제시하세요.

보고서 품질은 문장력보다 추적 가능성에서 나옵니다. 나중에 누가 물었을 때 '어디서 나온 말인가'를 답할 수 있어야 합니다.

사례 3: 슬라이드 디자인 수정이 끝없이 반복된다

슬라이드는 자주 루프에 빠집니다. 색을 바꾸면 레이아웃이 틀어지고, 레이아웃을 고치면 문장이 길어지고, 문장을 줄이면 메시지가 약해집니다. 이때는 한 번에 전체를 고치지 말고 수정 범위를 잠가야 합니다.

전체 슬라이드를 다시 만들지 마세요.
이번 수정 범위는 3, 5, 8번 슬라이드의 레이아웃만입니다.
문구와 데이터는 변경하지 마세요.
수정 전후 차이를 표로 요약하고, 변경한 이유를 한 줄씩 설명하세요.

디자인 작업에서는 '전체 개선'이라는 말이 위험합니다. '몇 번 슬라이드의 무엇을 바꿀지'가 있어야 합니다.

사례 4: 웹사이트나 앱 빌드가 오류를 반복한다

웹사이트와 앱 제작은 파일, 라이브러리, 실행 환경, 브라우저 확인이 얽혀 있습니다. 오류가 나면 Manus가 패키지를 바꾸고, 구조를 바꾸고, 코드를 다시 쓰다가 점점 복잡해질 수 있습니다.

앱 전체를 다시 작성하지 마세요.
현재 오류를 최소 재현 예제로 줄이세요.
오류 메시지, 관련 파일, 실행 명령, 예상 동작, 실제 동작을 먼저 정리하세요.
수정은 한 번에 하나의 원인만 대상으로 하세요.
수정 후에는 동일한 테스트 명령으로 확인하세요.

빌드 문제의 원칙은 단순합니다. 전체를 갈아엎기 전에 오류를 작게 만듭니다. 작은 오류는 고칠 수 있지만, 큰 혼란은 디버깅하기 어렵습니다.

사례 5: 브라우저 자동화가 로그인, 캡차, 결제 화면에서 막혔다

Manus가 브라우저를 다룰 수 있다고 해서 모든 웹 작업을 끝까지 맡겨도 되는 것은 아닙니다. 초기 평가 기사에서도 음식 주문, 항공권 예약, 식당 예약, 게임 제작 같은 복합 작업에서 충돌이나 미완료 사례가 보고되었습니다.⁵ 특히 로그인, 캡차, 결제, 예약 확정, 제출 버튼은 자동화의 경계선입니다.

로그인, 캡차, 결제, 예약 확정, 제출 단계에서는 멈추세요.
현재 화면에서 사용자가 직접 처리해야 할 항목을 설명하세요.
입력한 내용이 있다면 제출 전 검토표로 정리하세요.
최종 버튼은 누르지 마세요.

브라우저 자동화에서 가장 좋은 원칙은 '마지막 버튼은 사람이 누른다'입니다. Manus는 준비하고, 사람은 승인합니다.

사례 6: 파일을 찾을 수 없다고 한다

file not found는 가장 흔하면서도 쉽게 해결되는 오류입니다. 파일이 없을 수도 있지만, 대부분은 경로가 다르거나, 업로드가 안 되었거나, 현재 작업 폴더가 다릅니다.

파일을 찾기 전에 현재 작업 디렉터리를 확인하세요.
파일 목록을 출력하고, 예상 파일명과 실제 파일명을 비교하세요.
상대 경로와 절대 경로를 모두 확인하세요.
파일이 없다면 다시 업로드해야 하는지 알려 주세요.

파일명에 공백, 한글, 괄호, 버전 번호가 섞여 있으면 오류가 더 잘 납니다. 긴 작업에서는 파일명을 단순하게 바꾸는 것만으로도 안정성이 올라갑니다. 예를 들어 2026_05_sales.csv, customer_sample.csv, final_report.md처럼 쓰는 편이 좋습니다.

사례 7: My Computer에서 명령 실행이 불안하다

로컬 컴퓨터에서 Manus가 명령을 실행할 때는 늘 보수적으로 운영해야 합니다. 특히 삭제, 이동, 덮어쓰기, 동기화 폴더 수정은 되돌리기 어렵습니다.

실제 변경 전에 dry-run을 수행하세요.
변경 계획표를 먼저 만드세요.
기존 경로, 새 경로, 변경 이유, 되돌리는 방법을 표시하세요.
삭제 명령은 사용하지 말고 필요한 경우 trash 폴더로 이동하는 계획만 제안하세요.
내 승인 전에는 실행하지 마세요.

Allow Once와 Always Allow 중에서는 기본적으로 Allow Once가 안전합니다. 반복적이고 낮은 위험의 명령만 예외적으로 허용하세요.

사례 8: 데이터 분석 결과의 합계가 맞지 않는다

합계 오류는 단순 계산 실수일 수도 있고, 필터·중복·조인 오류일 수도 있습니다. 최종 표만 다시 계산하지 말고 원본에서 결과까지의 경로를 재현해야 합니다.

합계가 맞지 않습니다.
최종 표만 수정하지 말고 원본 데이터에서 다시 계산 과정을 재현하세요.
중복 제거 전후 행 수, 결측값 처리, 제외한 상태값, 조인 방식, 필터 조건을 표로 보여 주세요.
상위 10건과 무작위 20건 샘플을 원본과 대조하세요.

데이터 분석에서 '숫자를 고치는 것'은 해결이 아닙니다. 숫자가 왜 틀렸는지 찾아야 같은 오류가 반복되지 않습니다.

사례 9: Manus가 도구를 쓰지 않고 설명만 반복한다

Agent Mode인데도 도구를 선택하지 않고 '제가 할 수 있는 일은…' 같은 설명만 반복할 때가 있습니다. 이때는 다음 행동을 작게 지정합니다.

설명을 반복하지 말고 다음 행동 하나만 수행하세요.
현재 목표를 달성하기 위해 필요한 도구를 하나 선택하세요.
도구가 필요 없다면 도구 없이 답할 수 있는 범위와 한계를 먼저 말하세요.
도구를 선택할 수 없다면 이유를 한 문장으로 설명하고 사용자에게 필요한 정보를 질문하세요.

도구 선택 실패는 종종 목표가 너무 추상적일 때 생깁니다. '분석해 줘'보다 '첨부 CSV의 월별 매출 합계를 계산해 표로 보여 줘'가 훨씬 낫습니다.

사례 10: 크레딧이 예상보다 너무 빨리 줄었다

작업이 끝난 뒤 크레딧이 많이 줄어든 것을 보고 놀랐다면, 다음 작업부터는 사전 예산을 세워야 합니다. Manus가 실제로 몇 번 검색했고, 몇 번 코드를 실행했고, 대용량 파일을 몇 번 읽었는지 확인합니다.

이번 작업의 크레딧 과소비 원인을 분석하세요.
웹 검색, 파일 처리, 코드 실행, 재시도, 결과 재작성으로 나누어 어떤 부분이 비용을 키웠는지 설명하세요.
다음번 같은 작업을 30퍼센트 이상 줄여 수행하려면 어떤 제한 조건을 넣어야 하는지 제안하세요.

크레딧 관리는 사후 불평이 아니라 사전 설계입니다. 다음 작업의 검색 횟수, 반복 횟수, 파일 범위, 산출물 형식을 제한하면 비용 예측이 쉬워집니다.

작업 일지와 사고 기록을 남긴다

고급 사용자는 프롬프트만 저장하지 않습니다. 실패 기록도 저장합니다. 어떤 요청에서 잘 되었고, 어떤 요청에서 멈췄고, 어떤 제한 조건이 효과가 있었는지 기록해 둡니다. 이것이 쌓이면 나만의 Manus 운영 매뉴얼이 됩니다.

작업 일지는 간단하면 됩니다.

문제가 컸다면 짧은 사고 기록을 남깁니다. 기업의 장애 회고처럼 거창할 필요는 없습니다. '무엇이 일어났는가, 왜 일어났는가, 다음번에는 어떻게 막을 것인가'만 있으면 됩니다.

이번 Manus 작업 실패를 회고해 주세요.
다음 형식으로 정리하세요.

1. 원래 목표
2. 실제로 일어난 문제
3. 문제가 처음 관찰된 시점
4. 원인 후보
5. 사용자가 더 빨리 알아차릴 수 있었던 신호
6. 복구에 성공한 방법
7. 다음번 프롬프트에 추가할 예방 문구

이런 기록은 팀에서 특히 강력합니다. 한 사람이 겪은 실패가 팀 전체의 운영 자산이 되기 때문입니다.

고급 운영의 핵심은 세 가지 정지 버튼이다

Manus를 잘 쓰려면 시작 지시만 잘 쓰면 안 됩니다. 멈추는 조건을 잘 써야 합니다. 자동화 도구는 '언제 시작할지'보다 '언제 멈출지'가 더 중요할 때가 많습니다.

좋은 프롬프트에는 세 가지 정지 버튼이 들어갑니다.

프롬프트 끝에 다음 문장을 붙이는 습관을 들이세요.

완료 조건, 중단 조건, 승인 조건을 지키세요.
중단 조건에 해당하면 계속 시도하지 말고 현재 상태와 선택지를 보고하세요.
승인이 필요한 행동은 실행하지 말고 대기하세요.

이 문장은 Manus를 불신해서 넣는 것이 아닙니다. 일을 잘 맡기기 위해 넣는 것입니다. 좋은 관리자는 부하 직원에게 목표뿐 아니라 권한과 한계도 알려 줍니다. Manus도 마찬가지입니다.

문제 해결은 사용법이 아니라 운영 체계다

Manus를 처음 배울 때는 기능이 눈에 들어옵니다. Chat Mode, Agent Mode, Knowledge, Wide Research, Design View, My Computer 같은 기능이 신기합니다. 하지만 시간이 지나면 기능보다 운영이 중요해집니다. 멈췄을 때 어디를 볼지, 루프를 언제 끊을지, 샌드박스 파일을 어떻게 보존할지, 부정확한 결과를 어떻게 검증할지, 크레딧을 어떻게 통제할지가 실제 생산성을 결정합니다.

Manus는 완벽한 직원이 아닙니다. 그러나 잘 관리하면 매우 유능한 실행자입니다. 사람에게 일을 맡길 때도 목표, 자료, 마감, 보고 방식, 중단 기준을 알려 주어야 합니다. Manus에게도 같은 원칙이 필요합니다.

마지막으로, 모든 긴 작업 앞에 다음 운영 프롬프트를 붙여 보세요.

이 작업은 안정성과 비용 효율이 중요합니다.

다음 원칙으로 진행하세요.
1. 먼저 계획을 세우고 내 승인을 기다립니다.
2. 한 번에 한 단계씩 실행합니다.
3. 각 단계가 끝나면 중간 산출물과 상태 요약을 저장합니다.
4. 같은 행동이 3회 반복되면 루프로 판단하고 중단합니다.
5. 원본에서 확인하지 못한 사실은 단정하지 않습니다.
6. 검색, 코드 실행, 파일 처리의 반복 횟수를 제한합니다.
7. 결제, 발송, 삭제, 권한 변경, 대량 수정은 실행하지 않습니다.
8. 문제가 생기면 처음부터 다시 시작하지 말고 복구 계획을 제안합니다.

이 한 덩어리의 지시문은 Manus를 더 느리게 만드는 것이 아니라 더 오래, 더 안전하게 쓰게 해 줍니다. 고급 사용자는 더 많은 일을 한 번에 맡기는 사람이 아닙니다. 실패해도 무너지지 않는 방식으로 일을 맡기는 사람입니다.

참고

¹StatusGator Manus status monitoring

²Manus Help Center sandbox issue

³OpenManus loop issue example

⁴Manus Help Center credit optimization

⁵TechCrunch Manus early testing report