$39 함정: 200개 이상의 Manus AI 작업을 추적한 결과, 크레딧의 73%가 낭비된 것을 발견했습니다
Source: Dev.to
당신은 Manus AI에 월 $39를 지불하고 있습니다. 자동 AI 작업에 $39 상당의 가치를 얻고 있다고 생각하나요? 그렇지 않습니다.
30일 동안 실행한 모든 작업을 추적한 결과, 내 크레딧 사용량의 거의 3/4가 순수한 낭비였으며, 그 원인은 예상과 다릅니다.
이것은 불평이 아닙니다. 이것은 데이터 분석입니다.
실험
나는 Manus Pro 플랜($39.99 / 월, 3 900 크레딧)에서 연속 30일 동안 217개의 작업을 기록했다. 각 작업에 대해 다음을 기록했다:
- 작업 유형 (코드 편집, 연구, 파일 작업, 웹 스크래핑, 콘텐츠 생성, 다단계 프로젝트)
- 사용된 모델 (표준 vs Max, 작업 메타데이터에 표시된 대로)
- 소모된 크레딧
- Max 모드가 실제로 필요했는지 여부 (작업 복잡도와 출력 품질로 판단)
결과는 불편했다.
원시 수치
| 지표 | 값 |
|---|---|
| 전체 추적된 작업 | 217 |
| 소모된 총 크레딧 | 4 831 (플랜 초과 24 %) |
| Max 모델로 라우팅된 작업 | 164 (75.6 %) |
| Max가 정당화된 작업 | 47 (21.7 %) |
| Max가 불필요한 작업 | 117 (53.9 %) |
| 잘못된 라우팅으로 낭비된 크레딧 | ~2 340 (48.4 %) |
이 점을 곰곰히 생각해 보세요. 내 작업의 절반 이상이 더 저렴한 모델이 동일한 결과를 낼 수 있었음에도 가장 비싼 모델에 의해 처리되었습니다.
낭비가 발생하는 곳
모든 작업을 분류한 결과, 어떤 작업 유형이 과도하게 라우팅되는지 명확한 패턴을 발견했습니다:
| 작업 카테고리 | 개수 | % 최대값으로 라우팅된 비율 | % 최대값이 필요했던 경우 | 낭비 비율 |
|---|---|---|---|---|
| 간단한 파일 편집 | 43 | 88 % | 5 % | 83 % |
| 변수 이름 변경 / 리팩터링 | 28 | 82 % | 7 % | 75 % |
| 웹 검색 / 조회 | 31 | 71 % | 13 % | 58 % |
| 템플릿 생성 | 19 | 79 % | 16 % | 63 % |
| 버그 수정 (단일 파일) | 24 | 75 % | 29 % | 46 % |
| 짧은 콘텐츠 작성 | 18 | 83 % | 22 % | 61 % |
| 다중 파일 아키텍처 | 22 | 91 % | 82 % | 9 % |
| 복합 연구 및 종합 | 16 | 94 % | 88 % | 6 % |
| 데이터 분석 및 시각화 | 16 | 88 % | 75 % | 13 % |
패턴: 일상적인 작업(파일 편집, 이름 변경, 검색, 템플릿)은 크게 과도하게 라우팅되는 반면, 복합 작업(아키텍처, 연구, 데이터 분석)은 적절하게 라우팅됩니다.
숨겨진 크레딧 낭비 요인
모델 라우팅 외에도, 다음과 같은 세 가지 추가적인 낭비 원인이 나타났습니다:
- 재시도 세금 (~15 % 전체 크레딧) – 작업이 실패하고 Manus가 재시도하면, 두 번의 시도에 대해 모두 비용을 지불합니다. 217개의 작업 중 31개(14.3 %)가 최소 한 번의 재시도를 포함했습니다. 재시도 크레딧은 동일한 오류가 발생하더라도 절대 환불되지 않습니다.
- 컨텍스트 재구축 (~12 % 전체 크레딧) – Manus는 같은 세션 내에서 이미 처리한 파일을 다시 읽습니다. 저는 에이전트가 하나의 다단계 작업에서
package.json파일을 네 번이나 읽는 것을 관찰했습니다. 각 읽기마다 파일 내용이 모델에 다시 입력되므로 크레딧이 소모됩니다. - 배치되지 않은 작업 (~8 % 전체 크레딧) – 관련 작업이 순차적으로 처리되어 배치되지 않은 경우입니다. 예를 들어, “5개의 페이지에서 제목을 업데이트”라는 작업이 하나의 배치 작업이 아니라 다섯 개의 별도 작업으로 처리됩니다. 각 작업마다 컨텍스트 로딩, 모델 초기화 등 오버헤드가 발생해 비용이 누적됩니다.
수학: 실제로 지불하고 있는 금액
$39.99 Pro 플랜(3 900 크레딧) 기준:
| 카테고리 | 크레딧 | 전체 대비 % | 실제 비용 |
|---|---|---|---|
| 생산적인 작업(올바른 모델, 낭비 없음) | 1 062 | 22 % | $8.76 |
| 올바른 모델이지만 재시도/재구성 낭비 포함 | 529 | 11 % | $4.36 |
| 잘못된 모델 라우팅(가장 큰 비중) | 2 340 | 48 % | $19.30 |
| 오버헤드(컨텍스트, 배치되지 않음) | 900 | 19 % | $7.42 |
| 총합 | 4 831 | 100 % | $39.84 |
당신은 $39.99를 지불하지만, 최적 라우팅된 생산적인 작업은 $8.76에 해당하는 가치만 얻고 있습니다. 나머지는 낭비입니다.
왜 Manus는 이것을 고치지 않는가
이것은 버그가 아니라 설계 선택입니다. Manus가 Max로 적극적으로 라우팅하는 이유는 다음과 같습니다:
- 품질 상한선이 비용 하한선보다 우선. 저렴한 모델에서 실패하기보다 비싼 모델에서 간단한 작업이 성공하는 것이 Manus의 평판에 더 좋습니다.
- 사용자 피드백 루프가 없음. 사용자가 사후에 “이 작업은 Max가 필요하지 않았다”고 말할 수 있는 메커니즘이 없습니다.
- 수익 정렬. 더 많은 크레딧 사용은 사용자를 더 높은 등급 플랜으로 빨리 이동하게 합니다.
Manus가 악의적이라고 말하는 것은 아니지만, 인센티브 구조가 여러분의 지갑에 유리하지는 않습니다.
Source: …
할 수 있는 방법
이 분석 후에 저는 효과 비용을 $39.99에서 월 약 $14‑18 정도로 낮추는 세 가지 변화를 적용했습니다:
1. 작업 분해
큰 프롬프트를 원자적 작업으로 나눕니다(예: “레이아웃 만들기”, “사이드바 내비게이션 추가”, “테이블 컴포넌트 구현”). 각 마이크로‑작업은 성공률이 높으며 Standard 로 라우팅되는 경우가 더 많습니다.
2. 지식 스니펫
다음과 같은 Knowledge 항목을 추가합니다:
hard_credit_ceiling: 120
max_steps: 20
parallel_tasks: 1이는 보수적인 동작을 강제하고 복잡한 작업에서 신용이 과다 사용되는 것을 방지합니다.
3. 모델 라우팅 레이어
작업을 가로채어 복잡도에 따라 분류하는 라우팅 스킬을 구축합니다. 단순 작업은 Standard 로 강제 라우팅하고, 진정으로 복잡한 작업만 Max 로 보냅니다. 이만으로도 낭비를 약 55 % 줄일 수 있었습니다.
결과: 월 사용량이 약 4 800 크레딧에서 ~1 800‑2 200 크레딧으로 감소했으며, 3 900 크레딧 할당량 내에 충분히 들어가고 여유도 남았습니다.
Source: …
불편한 질문
만약 기본 라우팅에 사용되는 크레딧이 73 %나 낭비되고, 해결책이 비교적 간단한 분류 레이어라면, 왜 Manus가 이를 플랫폼에 바로 구축하지 않을까요?
답은 그들이 곧—언젠가—구현할 것이라는 점이라고 생각합니다. 현재 크레딧 시스템은 수익 센터이며 비용 센터가 아닙니다. 사용자 압력이 변화를 강요할 때까지 낭비는 계속될 것입니다.
그 사이에 데이터는 명확합니다: 사용량을 추적하고, 작업을 분해하며, 라우팅 레이어를 추가하세요. 여러분의 지갑이 고마워할 겁니다.
2026년 2월 15일 ~ 3월 16일 사이에 Manus Pro 플랜에서 수집된 모든 데이터. 작업 분류는 각 작업의 입력, 출력, 모델 메타데이터를 검토하여 수동으로 수행되었습니다. 전략 3에서 언급된 라우팅 스킬은 오픈‑소스이며 GitHub에서 credit‑optimizer‑v5(MIT 라이선스)로 제공됩니다.
데이터를 비교하고 싶다면 아래에 댓글을 남기거나 creditopt.ai에서 저를 찾아 주세요.