Manus가 복구에 대해 실제로 발표한 내용
여기에 인용된 모든 내용은 Manus 고객 센터의 서비스 변경 안내 문서에서 가져온 것입니다. 제3자의 요약이나 Manus가 공식적으로 발표하지 않은 수치는 포함되어 있지 않습니다.
복구 기간에는 마감일이 없으며, 파일만이 유일한 열쇠입니다
"8월 25일 오전 8시부터 서비스 변경의 영향을 받은 모든 사용자는 이전에 저장한 백업 패키지를 사용하여 계정과 작업을 복구할 수 있습니다."
배포된 사이트의 경우, Manus는 기한이 없다는 점이 의도된 것임을 명확히 하고 있습니다. 배포된 모든 웹사이트는 삭제가 시작된 시점부터 "사용자가 데이터를 적극적으로 복구할 때까지(복구 포털은 8월 25일 오전 7시 59분에 열림) 접속할 수 없습니다. 복구 시점은 사용자가 결정하므로 정해진 종료일은 없습니다."
이러한 유연성의 이면에는 백업 기간이 영구적으로 종료되었다는 사실이 있습니다. 분실된 파일에 대해 공식 문서는 먼저 클라우드 드라이브의 휴지통과 버전 기록을 확인하라고 안내한 뒤, 다음과 같이 덧붙입는다. "파일이 실제로 분실되었거나 손상된 경우, 데이터 백업 기간 내에 새 백업을 생성해 주십시오. 데이터 백업 기간이 종료되면 새 백업을 만들 수 없습니다." 또한 다운로드 폴더를 정리하다가 실수로 위반하기 쉬운 취급 주의 사항도 있습니다. "백업 파일을 수정, 이름 변경 또는 이동하지 마십시오. 파일이 사용 불가능해질 수 있습니다."
복구는 단 한 번만 실행됩니다
이 문장은 복구 안내 문서에 두 번 등장하는데, 이는 대개 제공업체가 사용자들이 이 부분을 놓칠 것이라 예상할 때 쓰는 방식입니다. "복구는 단 한 번만 완료할 수 있습니다."
주변 문단은 이것이 생각만큼 가혹하지 않은 이유와 유일한 안전장치가 어디에 있는지 설명합니다. "데이터 복구는 여러 백업 패키지 업로드를 지원합니다. 업로드 후 콘텐츠를 중복 제거하고 통합하여 가장 완전한 작업 데이터 세트를 복구합니다. 데이터 복구는 단 한 번만 수행할 수 있습니다. 복구를 진행하기 전에 백업 패키지가 올바르고 최신 버전을 포함하고 있는지 신중하게 확인하고 확인하는 것을 강력히 권장합니다."
따라서 파일 하나로 제한되는 것은 아닙니다. 제한되는 것은 단 한 번의 완료된 복구이며, 원하는 모든 것이 해당 업로드에 포함되어 있어야 합니다. 안전장치는 좁지만 확실합니다. "패키지 검증 실패 시도는 완료된 복구로 간주되지 않으므로, 완전한 세트로 다시 시도할 수 있습니다." 업로드 거부는 기회 소진이 아닙니다. 잘못된 세트를 성공적으로 복구하는 것이 기회 소진입니다.
두 개의 패키지, 그리고 대부분의 실패를 유발하는 4GB 분할
백업은 서로 다른 역할을 하는 최대 두 개의 아카이브를 생성했습니다. 계정 데이터 백업(Account Data Backup)은 "10MB 이하로 이메일 첨부 파일로 제공되는 소형 파일"이며, Type C 사용자만 생성할 수 있었습니다. 이 사용자들에게 이 파일의 의존성은 절대적입니다. "계정 데이터 백업이 없으면 작업 데이터를 복구할 수 없습니다."
작업 데이터 백업(Task Data Backup)은 대용량 파일이며, Manus는 그 내용을 다음과 같이 평이하게 설명합니다. "귀하의 작업, 생성된 파일(웹사이트 및 슬라이드 등), 구성 데이터가 포함되어 있습니다."
그리고 대부분의 혼란을 야기하는 제약 조건이 있습니다. "단일 데이터 패키지의 상한선은 4GB입니다. 예를 들어, 총 8GB는 두 개의 4GB 백업 패키지로 분할됩니다." 복구 측면에서 이는 엄격한 요구 사항이 됩니다. "내보내기에 여러 파일이 포함된 경우, 번호가 지정되지 않은 메인 패키지와 동일한 내보내기에서 생성된 번호가 지정된 모든 part 패키지를 함께 업로드하십시오. 불완전한 패키지 세트는 복구할 수 없습니다."
내보낸 파일이 12GB였다면 세 개의 파일이 있는 것이며, 세 파일 모두 동일한 작업에서 함께 업로드되어야 합니다.
계정 유형에 따라 적용되는 단계가 다릅니다
Manus는 영향을 받은 계정을 세 가지 유형으로 분류했으며, 복구 경로는 유형에 따라 다릅니다. 유지된 계정의 경우 다음과 같습니다. "Type A 및 B 사용자: 귀하의 계정은 영향을 받지 않으며 평소와 같이 Manus를 계속 사용할 수 있지만, 삭제된 작업 데이터, Manus가 생성한 아티팩트 및 권한이 부여된 커넥터는 나중에 백업 파일을 사용하여 직접 복구하지 않는 한 회복할 수 없습니다."
삭제된 계정의 경우 다음과 같습니다. "Type C 사용자: 귀하의 계정은 삭제된 상태로 유지되며 로그인할 수 없습니다. Manus 서비스를 사용하려면 새 계정을 만들어야 합니다." 이들의 순서는 계정이 먼저이고, 그 다음이 작업 데이터입니다.
팀의 경우 세 가지 제약 조건이 더 추가됩니다. "팀 소유자만 팀 데이터를 복구할 권한이 있습니다. 팀원은 팀 데이터 복구를 시작할 수 없습니다." 아무도 복구하지 않는 경우: "팀 소유자가 복구를 수행하지 않으면 팀 데이터를 회복할 수 없으며 팀원은 해당 데이터에 액세스할 수 없습니다." 그리고 임의로 행동하기 전에 두 번 읽어볼 가치가 있는 지침이 있습니다. "이 목적으로 새 팀을 생성하지 마십시오. 원래 팀의 백업 패키지는 새로 생성된 팀으로 복구하거나 병합할 수 없습니다." 개인 계정과 팀을 모두 보유한 사람은 "두 개의 별도 계정 복구 작업과 데이터 복구 작업을 완료해야 합니다."
이것이 바꾸는 것과 바꾸지 못하는 것
복구되는 대상은 명확히 정의되어 있습니다. 작업, 웹사이트 및 슬라이드를 포함하여 생성된 파일, 그리고 구성 데이터입니다. 배포된 사이트는 자동으로 복구됩니다. "작업 데이터 백업을 복구하면 배포된 웹사이트가 자동으로 다시 온라인 상태가 됩니다." 타사 커넥터는 절반만 복구된 상태로 돌아옵니다. "데이터 복구는 타사 커넥터도 복구하지만, 해당 토글을 수동으로 다시 켜야 합니다."
복구되지 않는 대상 역시 백업 가이드의 단 한 문장으로 명확하게 정의되어 있습니다. "백업은 생성된 시점의 데이터 스냅샷만 캡처하며 새 작업을 자동으로 동기화하지 않습니다." 패키지는 내보내기 시점에 고정되어 있습니다. 마지막 내보내기와 삭제 기간 사이에 생성된 모든 것은 패키지에 포함되어 있지 않으며, 어떤 복구 작업으로도 이를 만들어낼 수 없습니다.
세 번째 범주가 있으며, 그 경계를 긋는 것은 Manus입니다. 백업을 생성할 수 없었던 팀원들은 "일반 텍스트 내보내기를 통해 작업 데이터의 읽기 가능한 사본을 내보낼 수 있지만, 이는 백업과 다르며 작업 데이터를 가져오거나 복구하는 데 사용할 수 없다"는 안내를 받았습니다.
이를 두 가지 서로 다른 형태에 대한 설명으로 이해하십시오. 하나는 사람이 읽을 수 있고 어디서나 재사용할 수 있지만, 제공업체의 복구 도구는 이를 수락하지 않습니다. 다른 하나는 복구 도구에서 수락되지만 다른 용도로는 쓸모가 없습니다. 이번 이벤트에서 세 번째 형태, 즉 귀하가 일하는 방식에 대해 도구가 학습한 기록을 귀하와 다른 시스템이 모두 활용할 수 있는 형태로 만들어낸 것은 아무것도 없습니다. 작업 아카이브는 이를 담고 있지 않습니다. 일반 텍스트 내보내기 역시 마찬가지입니다. 패키지에 애초에 포함되어 있지 않았으므로 패키지에서 나올 수도 없습니다. 이는 일반적인 사용 중에 Manus loses your project history 현상이 발생할 때 나타나는 것과 동일한 공백입니다.
사람들이 오해하기 쉬운 사실들
"기한이 없다는 것은 시급하지 않다는 뜻이다." 정말 중요했던 마감일은 이미 지났습니다. 백업 파일은 Manus의 표현을 빌리자면 "데이터를 복구할 수 있는 유일한 수단"이며, 다시 생성할 수 없고, 이름을 바꾸거나 이동하면 "사용 불가능해질 수 있습니다."
"일단 복구를 시작해보고 어떻게 되는지 보겠다." 검증 실패만 비용이 들지 않습니다. 완료된 복구는 기회가 소진된 것이며, 공식 문서는 진행하기 전에 패키지가 "올바르고 최신 버전을 포함하고 있는지" 확인할 것을 요청하고 있습니다.
"우리 팀원 중 누군가가 처리할 수 있을 것이다." 소유자만 팀 데이터를 복구할 수 있으며, 소유자의 계정 자체가 삭제된 경우 먼저 본인 계정부터 복구해야 합니다.
"백업은 내 계정의 복사본이다." 이는 타임스탬프가 찍힌 스냅샷일 뿐입니다.
"먼저 대체 도구를 선택해야겠다." 기존에 가지고 있던 것을 복구하는 것과 지속 가능한 지식이 다음에 머무를 곳을 결정하는 것은 서로 다른 시간 축에 있는 두 개의 별개 결정입니다. 순서를 잘못 잡으면 결국 둘 다 하지 못하게 됩니다.
해결책: 단일 복구 작업에 의존하지 않는 곳에 재사용 가능한 절반을 보관하기
복구는 아티팩트를 돌려줍니다. 하지만 그 아티팩트를 훌륭하게 만들었던 부분, 즉 수십 번의 시도를 통해 다듬은 브리프, 거부한 출처와 그 이유, 팀이 실제로 수용하는 형식 등은 어떤 아카이브 형식도 담아내지 못하는 레이어에 존재합니다. 이 레이어는 특정 벤더의 내보내기 도구에 종속되지 않는 곳에 보관할 가치가 있습니다.
이것이 바로 MemoryLake가 존재하는 이유입니다. 귀하가 소유하는 메모리 레이어로, 귀하의 어시스턴트와 에이전트가 각 벤더의 비공개 아카이브 형식이 아닌 API를 통해 읽어옵니다. 설정은 세 단계로 진행됩니다.
1단계: API 키 생성
로그인한 후 워크스페이스 설정에서 API 키를 생성합니다. 이는 어시스턴트와 에이전트가 사용할 자격 증명이며, 단일 도구가 아닌 귀하에게 귀속되므로 나중에 도구를 변경해도 무효화되지 않습니다.

2단계: 첫 번째 메모리 업로드
아티팩트보다는 재사용 가능한 절반부터 시작하십시오. 마침내 좋은 결과를 만들어낸 실무 브리프, 신뢰하지 않기로 결정한 출처, 팀의 명명 및 서식 규칙, 계속해서 반복되는 제약 조건(대상 독자, 톤앤매너, 결과물에 절대 포함되어서는 안 될 두 가지 사항 등)이 이에 해당합니다. 파일은 있는 그대로 업로드되며, MemoryLake가 멀티모달 파일을 처리하므로 규칙을 인코딩하는 슬라이드 덱이나 스프레드시트를 직접 입력할 수 있습니다.

3단계: AI 및 에이전트 연결
실제로 사용하는 어시스턴트를 연결합니다. 그 이후부터 지속 가능한 절반은 현재 사용 중인 도구 내부에서 매번 재구축되는 대신 한 곳에서 읽어옵니다. 도구가 변경되거나 인수되거나 아카이브에서 복구하라는 요청을 받더라도, 해당 레이어는 도구 내부에 있었던 적이 없으므로 영향을 받지 않습니다.

두 가지 솔직한 한계가 있습니다. MemoryLake는 귀하의 Manus 작업을 복구하거나, 백업 패키지를 읽거나, 복구 도구와 어떤 방식으로든 상호작용할 수 없습니다. 그 경로는 전적으로 Manus를 통해서만 진행되며, 이 섹션은 이번 라운드가 아닌 다음 라운드에 관한 것입니다. 또한 아카이브를 대체하지는 않습니다. 파일과 결과물은 여전히 백업에 보관되어야 합니다.
실제 업무에서 이것이 바꾸는 것
당장은 작업 순서가 바뀝니다. 패키지 세트를 확인하고, 한 번 복구한 다음, 재사용 가능한 레이어가 어디로 갈지 별도로 결정하십시오.
향후 1년 동안은 서비스 변경으로 인해 발생하는 비용이 달라집니다. 방금 발생한 이벤트는 지정된 기간, 두 가지 패키지 유형, 공개된 복구 경로, 지원 채널 등 이례적으로 문서화가 잘 되어 있었습니다. 대부분의 중단 상황은 이보다 훨씬 더 혼란스럽습니다. 도구가 기능을 중단하거나, 요금제가 변경되거나, 워크스페이스가 마이그레이션되거나, 인수가 완료되는 등의 상황이 발생합니다. 내보내기를 해두었다면 아티팩트 수준에서는 이 모든 상황에서 살아남을 수 있습니다. 하지만 계속해서 유실되는 레이어는 축적된 이해입니다. 왜냐하면 이는 대개 내보낼 수 있는 방법이 전혀 없기 때문입니다. 아카이브와 메모리 레이어가 왜 동일한 객체가 아닌지에 대해서는 what makes memory persistent를 참조하십시오.
또한 도구를 전환할 때 재구축해야 하는 양도 달라집니다. 지속 가능한 절반이 이미 도구 외부에 있는 경우, 대안을 평가하는 것은 도구에게 처음부터 다시 가르치는 것이 아니라 이미 알고 있는 것을 가리키도록 하는 문제입니다. 이는 carrying context between tools의 배경이 되는 논리와 동일하며, Manus에 계속 머물든 그렇지 않든 적용됩니다.
복구 기회를 사용하기 전 권장 사항
먼저 동일한 내보내기에서 생성된 모든 파일을 찾으십시오. 번호가 지정되지 않은 메인 패키지와 번호가 지정된 모든 part 파일이 포함되어야 합니다. 불완전한 세트는 복구할 수 없으며, 일부만 있는 세트를 업로드하는 것이야말로 단 한 번뿐인 기회를 낭비하는 가장 확실한 방법입니다.
어떤 것도 이름을 바꾸거나, 이동하거나, 압축을 풀지 마십시오. 공식 문서에 따르면 파일을 수정하면 사용 불가능해질 수 있습니다. 이름을 건드리지 않고 하나의 폴더에 복사해 두십시오.
작업에 대한 기억과 타임스탬프를 대조해 보십시오. 마지막 내보내기 시점이 중요하게 생각하는 작업보다 이전이라면, 해당 작업은 패키지에 포함되어 있지 않으며 어떤 복구 작업으로도 이를 바꿀 수 없습니다. 나중에 아는 것보다 미리 아는 것이 좋습니다.
일치하는 계정으로 로그인했는지 확인하십시오. Manus는 로그인된 계정과 백업을 대조하여 검증하며, 일치하지 않으면 "Account Information Inconsistent" 오류와 함께 프로세스가 중단됩니다. "Backup couldn't be verified" 및 "[permission_denied] HTTP 403"을 포함하여 관련 오류에 대해 공개된 해결 방법은 로그아웃한 후 백업이 속한 계정으로 다시 로그인하여 재시도하는 것입니다.
팀을 소유하고 있다면 한 번이 아니라 두 번의 복구를 계획하십시오. 본인 계정이 삭제된 경우 개인 계정을 먼저 복구한 다음 팀을 복구해야 하며, 복구할 목적으로 새 팀을 생성하지 마십시오.
복구 후 커넥터를 다시 활성화하고 확인하십시오. 복구하면 커넥터는 돌아오지만 토글은 꺼진 상태로 유지되므로, 온전해 보이는 자동화가 실제로는 아무 작업도 수행하지 않을 수 있습니다.
기억이 생생할 때 재사용 가능한 절반을 기록해 두십시오. 이 장을 마무리하기 전에 20분을 투자하여 어떤 패키지에도 포함되지 않았던 브리프, 규칙, 거부된 접근 방식 등을 캡처해 두십시오. 이것이 이번 이벤트에서 재발을 방지할 수 있는 유일한 부분입니다. 팀의 지식이 여러 어시스턴트에 분산되어 있다면, auditing what each one actually remembers부터 시작하는 것이 좋습니다.
결론
Manus는 시간 제한을 없애는 대신 제약 조건을 유지했습니다. 준비가 되면 언제든지 복구할 수 있지만 기회는 단 한 번뿐이므로, 버튼을 누르기 전에 사전 작업이 이루어져야 합니다. 완전한 패키지 세트를 모으고, 파일 이름을 그대로 두고, 내보내기 날짜를 확인하고, 올바른 계정으로 로그인되어 있는지 확인하십시오.
그런 다음 나머지 절반은 별도로 처리하십시오. 작업과 파일은 패키지에 들어 있었기 때문에 복구할 수 있었습니다. 하지만 그 주변에 구축된 이해는 어떤 패키지에도 들어 있지 않았으며, 이는 해결 가능한 상태입니다. 단, 이를 유실한 도구의 외부에서만 가능합니다.