Manus로 Manus 재구축하기: 무엇이 바뀌었고, 무엇이 깨졌으며, 우리가 지금 어떻게 일하는가
글쓴이: Tao Zhang, Manus 공동 창업자 겸 최고 제품 책임자(CPO)
9월 말, Manus 2.0 출시를 앞둔 막바지 작업 중에 저는 Slack으로 엔지니어 한 명에게 기능 요청과 버그 리포트 몇 가지를 보냈습니다. 나중에 진행 상황을 확인하러 갔더니, 그의 화면에는 Agent 세션이 여러 개 열려 있었고 일부는 Manus에서, 일부는 Codex에서 돌아가고 있었습니다. 그중 하나를 클릭해 보니 프롬프트는 제가 보낸 Slack 메시지가 한 글자도 빠짐없이 그대로 붙여넣어져 있었습니다.
1년 전이라면 그는 제 메시지를 읽고, 제가 무슨 뜻으로 말했는지 파악한 뒤 직접 코드를 작성했을 것입니다. 이제는 Agent가 요청을 읽고, 관련 코드를 찾아내서 변경 사항을 제안합니다. 엔지니어의 역할은 작업을 지휘하고, 결과를 검토하며, 그 결과에 책임을 지는 것입니다. 요청이 진행되는 대부분의 시간 동안 그는 기다리지 않고 다른 일을 할 수 있습니다. 요즘 저희 팀에서는 한 명의 엔지니어가 동시에 10~20개의 요청을 돌리는 모습이 흔한 풍경입니다.
저는 저희 팀이 얼마나 빠르게 적응했는지 자랑스럽습니다. 동시에 불안하기도 합니다. 이 속도가 맞는 걸까요? 우리가 아직 알아차리지 못한 것은 무엇일까요?
저희는 Manus에서 Agent를 만들기 때문에 두 가지 원칙을 지킵니다. 저희 제품을 실제 업무에 사용합니다. 그리고 AI가 작동하지 않는 지점을 끊임없이 찾습니다.
저는 사람과 Agent가 기본적으로 나란히 일하는 환경에서 회사 내부에 어떤 일이 벌어지는지 기록하고 싶습니다. 이 글은 엔지니어링, 제품, 마케팅 세 팀을 다루며, 잘 되지 않았던 사례도 포함합니다. 이것은 "AI 네이티브 조직"에 대한 정의가 아니라, 진행 중인 실험에 대한 보고서입니다.
지금까지 배운 것들:
•어중간한 지점은 없습니다. 기존 업무 방식에 AI를 덧붙이는 것은 때로 잡음만 더했습니다. 루프가 완전히 닫혔을 때 비로소 변화가 일어났습니다.
•Agent에게는 전체 그림이 필요합니다. 더 나은 컨텍스트가 더 나은 프롬프트보다 큰 효과를 가져왔습니다.
•신뢰는 모델의 품질만이 아니라 테스트와 컨텍스트에서 나옵니다.
•자율성에는 결승선이 필요합니다. 성공 여부를 확인할 수 있을 때만 Agent가 혼자서 돌아갈 수 있습니다. 그 외에는 사람이 결정합니다.
•병목은 이동합니다. 엔지니어링이 빨라지자 무엇을 만들지 결정하는 일이 새로운 제약이 되었습니다.
•사람의 역할은 줄어들지 않았습니다. 더 큰 영향력을 가진 일에 집중하게 되었을 뿐입니다.
1. 어중간한 지점은 없다
2026년 이전까지 저희는 대부분의 회사가 하던 대로 했습니다. 즉, 기존 업무 방식에 AI를 덧붙였습니다. 지원팀은 AI 요약으로 이슈를 표시했고, 엔지니어는 코딩 어시스턴트를 사용했으며, 봇은 채널에 분석 결과를 올렸습니다. 각 부분은 그 자체로 유용했지만, 서로 연결된 조각은 많지 않았습니다. 루프가 실제로 닫히기 전까지 저희는 그저 똑같은 옛날 방식으로 일하면서 수많은 AI가 서로 떠들어대는 상황에 놓여 있었던 것입니다.
저희가 자주 되돌아보는 말이 있습니다. 소프트웨어 엔지니어링은 시간에 대해 적분한 프로그래밍이라는 것입니다. 코드를 작성하는 일은 측정하기 쉽지만, 복잡한 제품을 수년간 건강하게 유지하는 일은 그렇지 않습니다. AI가 작성한 코드의 비율이 높다는 것은 실제 진전을 의미할 수도 있고, 누군가 나중에 치워야 할 쓰레기가 쌓이고 있다는 뜻일 수도 있습니다.
저희가 중요하게 여기는 테스트는 더 어렵습니다. Manus는 1년 넘게 운영된 복잡한 제품입니다. 새로운 업무 방식 아래에서 무너지지 않고 계속 개선될 수 있는가, 그리고 각 구성원이 더 많은 일을 해낼 수 있는가? 지금까지의 답은 "그렇다"입니다.
2. Agent에게 전체 그림을 주어라
대부분의 테크 기업과 마찬가지로, 저희도 인수인계 과정에서 가장 많은 시간을 잃었습니다. 프런트엔드 엔지니어와 백엔드 엔지니어가 각자 요청을 해석하고, 인터페이스에 대해 합의한 뒤, 서로 맞지 않는 부분을 고치는 데 며칠을 보내곤 했습니다. 두 사람이 요구 사항을 똑같이 이해하는 경우는 드뭅니다.
AI가 스택 전반에 걸쳐 코드를 작성할 수 있다면, 한 사람이 요청을 처음부터 끝까지 책임질 수 있지 않을까요? 걸림돌은 컨텍스트였습니다. 저희 코드는 별도의 저장소에 분리되어 있었기 때문에, 어떤 Agent도 전체 시스템을 한 번에 볼 수 없었습니다.
그에 대한 우리의 답은 내부 실험에서 시작되었습니다. 우리는 AI가 가능한 한 적은 인간의 입력과 거의 손으로 작성한 코드 없이 제품을 구축하는 데 얼마나 멀리 갈 수 있는지 보고 싶었습니다. 그 과정에서 개발한 방법은 지금 우리가 Manus-mono, 또는 Mono라고 부르는 내부 도구가 되었습니다.
Mono는 우리의 리포지토리를 병합하지 않습니다. 단일 진입점과 Agent를 위해 작성된 매뉴얼로 구성되어 있습니다: 각 리포지토리가 무엇을 하는지, 어떻게 서로 연결되는지, 그리고 우리가 어떻게 일하는지에 대한 내용입니다. Agent는 필요한 것은 무엇이든 가져옵니다. 우리는 또한 아키텍처 결정 기록 라이브러리를 유지하므로, 모든 Agent 세션은 단지 코드가 아닌 과거 결정의 근거에서부터 시작됩니다. 누구든 Agent와 함께 일할 때, 그 Agent는 이전에 작업한 모든 사람의 컨텍스트를 가지고 있습니다.
Mono는 단계적으로 성장했으며, 각 단계는 이전 단계가 드러낸 병목 현상을 해결했습니다:
1.전체 시스템을 봅니다. 우리는 어떤 단일 리포지토리에도 포함되지 않는 비즈니스 컨텍스트를 추가했고, 병렬 작업을 위해 Git worktree를 사용했습니다.
2.로컬에서 검증합니다. 테스트 환경에 푸시하는 데 예전에는 5~10분이 걸렸습니다. 이제 전체 Manus 스택이 노트북에서 실행되며, 검사는 몇 초 만에 끝납니다.
3.프로덕션 문제를 디버깅합니다. 범위가 지정된 권한을 통해 Mono는 프로덕션의 버그를 진단하기 위해 필요한 로그, 구성 및 오류 보고서를 읽을 수 있습니다.
4.릴리스를 처음부터 끝까지 실행합니다. 이제 Mono는 작업이 지체되곤 했던 릴리스 단계를 처리합니다. 승인 결정은 여전히 사람이 합니다.
5.엔드투엔드 테스트를 수행합니다. 검증이 느린 부분이 되자, Mono는 테스트 계정으로 실제 사용자 플로우를 브라우저와 모바일 시뮬레이터에서 실행하기 시작했습니다.
(Mono가 어떻게 작동하는지, 그리고 어떻게 발전했는지. Manus로 팀원이 제작했습니다.)
사람들은 때때로 Mono가 코드 위키인지 묻습니다. 문서화는 그 일부이지만, 나머지는 코드 주위의 모든 것입니다: 어떻게 테스트하는지, 어떻게 릴리스하는지, 무엇을 결정하고 왜 그렇게 하는지, 그리고 Agent가 무엇을 다룰 수 있고 무엇을 다룰 수 없는지에 관한 것입니다.
시간이 지나면서 Mono는 사람들이 추가할수록 더 좋아지는 공유 지식 베이스가 되었습니다. 예를 들어, 우리 운영 엔지니어는 릴리스 지원 요청을 받는 데 지쳐서 릴리스 프로세스를 Mono에 작성했습니다. 이제 누구나 릴리스를 실행할 수 있고, Agent도 할 수 있지만, 승인은 여전히 릴리스 권한이 있는 사람에게 있습니다. 저는 팀이 일하는 방식이 좋습니다: 한 사람이 자신의 불편함을 해결했고, 그로 인해 회사 전체가 조금 더 빨라졌습니다.
이제 팀은 한 사람이 모든 플랫폼에서 요청을 배포할 수 있다고 가정합니다. 우리 모바일 팀은 이 기간 내내 7명이었습니다. 그들은 두 개의 제품에 걸쳐 네 개의 앱을 유지 관리하며 웹과 보조를 맞추고 있습니다.
Mono는 하향식 지시 없이 회사 전체에 퍼졌습니다. 저는 도구만큼이나 문화가 이를 설명한다고 생각합니다. AI의 한계를 테스트하는 것은 우리가 존재하는 이유의 일부이며, 우리 조직은 수평적입니다. 도구는 조직이 허락하는 만큼만 멀리 갈 수 있습니다.
3. 루프를 닫다: 사용자의 버그 보고서에서 검증된 수정까지
Mono는 누구나 제품의 어느 부분에서든 작업할 수 있도록 해주었습니다. 그것은 절반이었습니다. 나머지 절반은 Agent가 스스로 문제를 찾도록 하는 것이었습니다.
대부분의 인터넷 회사에서 사용자의 버그 보고서는 지원, 제품, 그리고 트리아지를 거쳐야 수정할 수 있는 엔지니어에게 도달합니다.
우리의 경우, 내부 Agent가 먼저 보고서를 조사하고 문제를 원인이 된 변경사항까지 추적합니다. 그런 다음 Slack에 게시하고 해당 변경사항을 소유한 엔지니어를 태그합니다. 엔지니어는 자신이 수정할 것인지 결정하고 자신의 Agent에게 넘깁니다. 별도의 Agent가 중요한 테스트와 플로우를 실행하여 수정 사항을 확인합니다.
세 개의 Agent, 세 가지 역할: 하나는 분류하고, 하나는 작업하고, 하나는 확인합니다. 중간에 있는 사람이 결정을 내립니다. 이제 우리 엔지니어링 작업의 점점 더 많은 부분이 이렇게 시작됩니다. Agent가 문제를 사람에게 가져오는 방식으로요.
이 루프에는 명확한 한계가 있습니다. 사용자 보고서를 읽는 Agent는 코드를 변경할 수 없습니다. 조사하고 우리에게 보고만 할 수 있습니다. 변경은 엔지니어가 결정한 후 엔지니어 자신의 Agent로부터 이루어집니다. 릴리스 권한이 있는 사람의 승인 없이는 아무것도 배포되지 않습니다.
4. Agent가 작성한 코드를 신뢰하게 된 과정
오랜 기간 동안 메인 브랜치에 들어가는 모든 변경 사항은 두 명의 시니어 엔지니어 중 한 명의 승인을 받아야 했습니다. 우리는 그 단계를 건너뛸 만큼 AI를 신뢰하지 않았죠. Agent가 더 많은 코드를 생산하면서, 이 리뷰 단계가 병목이 되었습니다.
순수한 코딩 능력에 있어서는 모델이 이미 뛰어났습니다. 우리는 그 차이가 두 가지로 귀결된다는 점을 인지했습니다. 첫째, 사람은 자신의 작업을 어떻게 테스트해야 하는지 압니다. 둘째, 사람은 상·하류 논의에 참여해 왔기 때문에 비즈니스에서 "올바르다"는 것이 무엇을 의미하는지 압니다. 올바른 코드가 올바른 제품과 동일하지는 않습니다.
우리는 두 가지 모두를 해결했습니다:
•Agent가 논의에 참여하게 했습니다. 이제 각 엔지니어의 Agent는 자신이 추가된 Slack 스레드에 자리 잡고 맥락을 따라갑니다. 누군가 마침내 "Go"라고 말할 때, Agent는 이미 팀이 무엇을, 왜 결정했는지 알고 있습니다.
•Agent가 엔드투엔드로 테스트하게 했습니다. 백엔드 팀과 협력하여, 우리는 각 변경 이후 Manus에서 실제 플로우와 회귀 테스트를 실행할 수 있는 능력을 Agent에게 부여했습니다. 테스트 커버리지가 늘어나면서 우리의 신뢰도 함께 커졌습니다.
오늘날 모든 변경은 이러한 검증과, 사용 가능한 가장 강력한 모델을 실행하는 코드 리뷰 봇을 거치며, 결제 등 민감한 영역에는 추가 규칙이 적용됩니다. 봇은 큐를 대체했을 뿐, 인간의 결정을 대체한 것은 아닙니다. Agent는 풀 리퀘스트를 열 수는 있지만, 사람의 명시적 승인 없이는 메인 브랜치에 머지할 수 없습니다. 무엇을 만들고 누가 릴리스할 수 있는지는 여전히 사람이 결정합니다.
5. 자율성에는 종착점이 필요하다
신뢰에는 한계가 있고, 우리는 이를 어렵게 깨달았습니다.
한때 모두가 완전 자율 Agent 루프에 열광했고, 우리도 하나 시도해 봤습니다. Agent가 사내 피드백 채널에서 피드백을 수집하고 각 항목에 대해 프로젝트를 시작했죠. 한 팀원이 주말 내내 돌아가게 두었습니다. 월요일 아침, 200개가 넘는 항목이 그의 결정을 기다리고 있었습니다.
왜 Agent가 그 결정도 하게 두지 않을까요? 자율 루프는 시스템이 목표 달성 여부를 확인할 수 있을 때 작동합니다. 테스트는 통과하거나 실패하고, 페이지는 로드되거나 그렇지 않습니다. 대부분의 실제 업무에는 그런 확인 수단이 없습니다. 사람이 그것이 완료되었는지, 그리고 애초에 할 가치가 있었는지를 판단해야 합니다.
우리는 그 주말에서 두 가지 교훈을 얻었습니다. 첫째, 사람은 통제되지 않은 루프가 결정 사항을 만들어내는 속도만큼 결정할 수 없습니다. 둘째, 어떤 일을 할지 아무도 결정하지 않으면, 그 결과를 책임지는 사람도 없습니다. 섹션 3의 버그 수정 루프는 테스트가 성공을 정의하기 때문에 작동합니다. 제품 결정에는 테스트가 없으므로, Manus의 모든 제품 변경은 여전히 사람이 그것을 할 가치가 있는지 결정하는 것으로 시작합니다.
6. 엔지니어링이 빨라지자 제품이 병목이 되었다
전통적인 제품 프로세스에는 많은 핸드오프가 있고, 각 단계마다 우선순위가 조금씩 흐려집니다. 코딩 Agent가 엔지니어를 더 빠르게 만들면서 새로운 문제가 생겼습니다: 좋은 요구사항을 작성할 프로덕트 매니저가 부족했습니다. 처음으로 엔지니어링이 제약 조건이 아니게 된 것입니다.
Manus에서 우리의 첫 번째 해결책은 몇몇 엔지니어에게 발견부터 출시까지 문제를 책임지는 "빌더"가 되어 달라고 요청하는 것이었습니다. 기술적 판단력과 제품적 판단력을 모두 갖춘 사람은 드물었습니다. 다음으로 PM이 코드를 변경할 수 있게 했습니다. 그것도 정체되었습니다. 핸드오프는 여전히 존재했고, 엔지니어의 직감 없이 PM은 카피와 인터랙션은 바꿀 수 있어도 기저 로직은 바꿀 수 없었습니다.
Mono는 규칙을 함께 가지고 다니기 때문에 두 문제를 모두 해결했습니다:
•모델 호출이나 비용에 영향을 주는 변경은 코드 작성 전에 담당자의 승인이 필요합니다.
•모든 변경은 엔지니어의 변경과 동일한 리뷰 및 테스트를 거칩니다.
•Mono는 테스트 계정으로 가입 및 결제 과정을 거치며 각 단계를 기록할 수 있어, PM이 문제가 발생한 정확한 순간을 지목할 수 있습니다.
실제 사례는 다음과 같습니다. 음성-텍스트 변환을 담당하던 한 PM은 Manus로 10개가 넘는 모델을 벤치마크한 뒤 하나를 선택했습니다. 그녀는 Mono를 통해 프런트엔드 코드를 가져와 디자인 시스템으로 데모를 만들고, Manus에게 각 사용자 시나리오를 이미지로 렌더링하도록 하여 검토했습니다. 그녀는 그 데모를 비디오로 만들었습니다. 계획이 충분히 명확해져서, 그녀는 웹과 데스크톱 UI를 포함한 기능을 직접 구축했습니다.
그 과정에서 사람들은 세 가지 결정을 내렸습니다. 그녀는 모델을 선택했습니다. 제품 및 디자인팀이 데모를 검토했습니다. 릴리스 권한을 가진 엔지니어가 코드를 검토했습니다. 1년 전만 해도 이 중 어느 것도 가능하지 않았을 것입니다.
우리는 이를 human in the loop에서 human on the loop로의 전환이라고 설명합니다. 과거에는 AI가 작업의 70-80%를 수행하고 사람들이 나머지를 채웠습니다. 이제 사람들은 규칙을 정하고, 여러 Agent를 감독하며, 중요한 지점에서 방법과 결과를 확인하고, 필요할 때 개입하며, 결과를 책임집니다.
일부 PM들은 이제 작성된 사양서나 목업 대신 짧은 동영상을 전달합니다. 몇 분 안에 그 영상은 사용 사례, 각 화면, 각 클릭이 수행하는 작업, 엣지 케이스가 어떻게 동작하는지, 그리고 그 모든 것이 내부적으로 어떻게 작동하는지를 보여줍니다. 우리에게는 디자인, 엔지니어링, QA가 "완료"의 의미에 더 빠르게 합의할 수 있고, PM은 한 번만 설명하면 됩니다.
(음성 입력에 대한 제품 요구사항 동영상)
오늘날 우리 PM의 약 절반이 스스로 기능을 출시하고 있으며, 모든 PM이 코드를 커밋한 적이 있습니다. 디자이너들도 시작했습니다. 한 PM은 Manus 2.0의 Manus Studio 인터페이스 대부분을 작성했습니다. 또 다른 PM은 Video Editor를 작성했습니다. 이들 각각의 뒤에는 자신의 역할이 과거에 커버했던 범위를 넘어서기 위해 몇 달을 쏟아부은 사람이 있습니다. 그것이 제가 가장 자랑스러워하는 부분입니다.
이는 모든 사람이 빌더가 되어야 한다는 뜻은 아닙니다. 회사의 누구나 빌드할 수 있게 되면, 사람들이 존재해서는 안 될 것들을 출시할 수도 있습니다. 우리 제품팀은 종종 한 가지 질문을 던집니다: "이것을 만드는 데 1초가 걸리고 비용이 전혀 들지 않는다면, 출시하시겠습니까?" 때로는 답이 '아니오'입니다. 우리는 여전히 무엇이 빌드되고, 무엇이 빌드되지 않으며, 사용자가 최종적으로 무엇을 보게 될지를 결정하는 모듈 소유자가 필요합니다. 또한 Mono 같은 인프라를 유지관리하는 사람들도 필요합니다. 빌드가 쉬워질수록, 무엇을 빌드할지 결정하는 일이 더 중요해집니다.
7. 마케팅 워크플로 내의 AI 팀원
마케팅 파트너십은 스크립트 검토, 가격 책정, 계약, 승인, 결제, 출시, 결과 검토 단계를 거칩니다. 이러한 단계들은 이메일, 계약 도구, 승인 시스템, 스프레드시트, 광고 플랫폼에 분산되어 있습니다. 과거에는 업무의 상당 부분이 이들 사이에서 정보를 이동시키는 일이었고, 판단이 필요한 창의적인 작업에는 시간이 거의 남지 않았습니다.
우리는 하나의 작은 문제에서 시작했습니다: 파트너 콘텐츠나 광고가 공개되었을 때, 우리는 종종 뒤늦게 소식을 들었습니다. 그래서 AI에게 콘텐츠가 게시되는 시점을 감지하는 스크립트를 작성하게 했습니다. 그 다음에는 성과 데이터가 필요했습니다. 그 다음에는 과거 파트너십에 대한 검토가 필요했습니다. 그 다음에는 전체 내부 워크플로가 연결되었습니다: 계약이 체결되거나 승인이 완료되면, Agent가 상태를 업데이트하고 다음 단계를 담당하는 사람에게 알립니다.
Manus는 이 모든 것을 내부 사이트에 구축했습니다. 사람들에게는 대시보드와 캘린더입니다. Agent에게는 도구 모음입니다. 우리의 워크플로 내에서 그러한 도구를 사용하는 Agent를 우리는 AI 팀원이라고 부릅니다. 이는 팀이 연결한 채널과 시스템 내에서만 작동하며, 접근 범위는 이 워크플로로 한정됩니다.
다음은 이것이 수행하는 작업입니다:
•자체 큐를 관리합니다. 많은 사람이 동시에 메시지를 보내므로, 하나의 "프런트 데스크" 세션에서 모두와 대화하고 작업을 병렬 세션에 넘깁니다. 메시지가 자신과 관련 있는지, 그런 다음 현재 작업을 중단할지 아니면 기다릴지를 결정합니다. 개발 중에 이 규칙들을 스스로 제안했고, 우리는 이를 유지하기 전에 검토했습니다.
•전달된 컨텍스트에서 학습합니다. 전략 변경은 과거에는 회의와 서면 브리프를 의미했습니다. 이제 우리의 마케팅 리드는 토론 내용을 전달하면서 이렇게 말합니다: "이것을 학습해."
•장기 목표를 시야에 둡니다. 한번은, 이 Agent가 추가된 Slack 스레드에서 팀원들이 프로젝트가 어디까지 진행됐는지 기억하지 못했습니다. 태그되지 않았는데도 Agent가 답했습니다: "B는 아직 테스트 중입니다. B를 살펴보기 전에 A의 결과를 기다릴까요?"
•다른 팀과 사실을 확인합니다. 우리가 3D 모델 리깅을 출시한 후, Agent는 제품팀에 무엇이 지원되는지 물었습니다. 리깅이 물고기, 뱀, 사족 보행 동물을 포함한 7가지 카테고리를 커버한다는 사실을 알게 되었고, 덕분에 우리의 설명이 정확하게 유지되었습니다.
팀원들은 이제 과거 파트너십 기록을 읽은 이 Agent를 스크립트 및 가격 검토에 참여시키고 있습니다. 결정은 여전히 사람이 내립니다.
이 내부 사이트는 Agent를 포함한 자체 사용자들로부터도 개선될 수 있습니다. Agent가 마찰에 부딪히면 피드백 엔드포인트를 통해 요청을 제출합니다. 이는 Manus 2.0의 Automations를 통해 Manus에 개발 작업을 열고, 엔지니어가 변경 사항을 검토한 후 배포됩니다. 약 일주일 동안 실행되었습니다. 이것에 의존하기 전에 더 많은 사례가 필요합니다.
그렇다면 팀원들은 무엇을 할까요? 세 가지가 그들에게 남아 있습니다. 그들은 모든 중요한 결정을 내리고 책임집니다. Agent가 아직 보지 못한 사례들을 처리하고, 무엇을 해야 할지 또는 누구에게 물어야 할지를 가르칩니다. 그리고 Agent의 분석이 새로운 각도를 가리킬 때마다 방향을 재조정합니다.
8. 서로를 덜 방해하기
이 모든 팀에서 많은 질문은 더 이상 누군가를 방해할 필요가 없어졌습니다.
먼저 Agent에게 물어보세요. 한 팀원이 Mono에 Slack 봇을 만들었는데, 클라우드 컴퓨터에서 실행되며 스레드에서 답변합니다. 비엔지니어들이 가장 많이 사용합니다. 이 기능은 어떻게 작동하나요? 이 문자열은 어디에 있나요? 이거 출시됐나요? 더 이상 담당자를 먼저 찾을 필요가 없습니다.
상태 업데이트를 요청하는 대신 세션을 열어보세요. 엔지니어의 진행 상황은 예전에는 각자의 AI 채팅 속에만 존재했고, 로그오프하면 보이지 않았습니다. 그래서 프로젝트 구성원이 서로의 세션을 보고 참여를 요청할 수 있는 내부 기능을 만들었습니다. 엔지니어가 Agent와 함께 기능의 대부분을 구축한 뒤, PM이 같은 세션에 참여해 간격, 스타일, 문구를 조정할 수 있습니다. 다른 사람의 세션에 게시하려면 그 사람의 승인이 필요하며, 권한 설정은 아직 다듬고 있습니다.
(예시: 엔지니어, PM, 디자이너가 하나의 세션에서 작업하는 방식. 실제 가격 변경이 아닙니다.)
요점은 서로 덜 대화하는 것이 아닙니다. 서로를 덜 방해하는 것입니다.
결정해야 할 것만 결정하세요. 저희 팀의 가장 헤비한 AI 사용자는 단 하나의 역할을 가진 메인 세션을 유지합니다. 그의 결정이 필요한 사항을 각각의 권장안과 함께 나열하는 것입니다. Slack이 바빠지면 그는 거기에 끼어들지 않고 이렇게 묻습니다. "내가 지금 당장 결정해야 할 것은 무엇인가?"
저도 비슷하게 합니다. 저는 하루에 20개가 넘는 할 일이 있고, 공개적으로 밝혔듯이 ADHD가 있습니다. 저에게는 시작이 가장 어려운 부분입니다. 이제 모든 할 일이 전용 Manus 프로젝트로 들어가 각 항목을 자체 태스크로 변환합니다. 가능한 것은 바로 시작합니다. 확실하지 않을 때는 저에게 배경 정보와 어떤 PM이 담당해야 하는지를 묻습니다. 그런 다음, 제가 부여한 저의 Slack, Gmail, Notion 접근 권한을 사용해 컨텍스트를 수집하고 PM에게 한 줄짜리 메모가 아닌 완전한 요청을 전달합니다. 저에게 이 변화는 단지 효율성에 관한 것만은 아닙니다. 이제 하루 중 어디서부터 시작해야 할지 불안해하는 시간이 훨씬 줄어들었고, 이는 개인적으로 엄청난 변화입니다.
9. 비용을 들일 가치가 있을까?
저희는 AI에 많은 비용을 쓰며, 그 지출을 면밀히 추적합니다. 이를 누군가의 성과를 평가하는 데 사용하지는 않습니다. 지출 자체를 평가하는 데 사용합니다. 지금 성과를 내고 있는가, 아니면 미래를 위한 준비인가?
저희가 생각하는, 그것이 가져다 주는 것과 비용이 어디로 향할지는 다음과 같습니다:
•시간과 주의력을 얻습니다. 팀이 성장할수록 조율이 모든 사람의 주의력을 갉아먹습니다. AI는 각자의 주의력을 보호하고 자신의 업무에 대한 완전한 주도권을 부여합니다. 그리고 저희는 여전히 채용 중입니다.
•최고의 모델을 사용하는 것이 AI의 한계가 어디인지 배우는 방법입니다. 섹션 4에서 설명한 검증 및 코드 리뷰 설정은 저희가 구할 수 있는 가장 강력한 모델에서 실행됩니다. 개발자 생산성을 이끄는 동료는 이를 저희의 가장 가성비 좋은 지출이라고 부릅니다.
•비용은 제품을 통해 떨어져야 합니다. 이제 저희 개발의 더 많은 부분이 저희 자체 제품인 Manus Studio에서 이루어지므로, 사용 데이터는 tokens가 어디서 낭비되는지 보여줍니다. 수정 사항은 제품에 반영되므로, 이는 사용자에게도 Manus를 더 효율적으로 만들 것입니다. 모델이 더 저렴해지고 저희가 낭비를 제거함에 따라 오늘의 비용이 상당히 감소할 것으로 예상합니다. 이는 약속이 아니라 믿음입니다!
10. 아직 작동하지 않는 것
방해는 줄어들었지만 주의력은 더 분산되었습니다. 예전에는 하루에 네다섯 가지 일을 처리하던 사람이 이제는 한 번에 20~30가지를 동시에 진행할 수 있습니다. 전환할 때마다 컨텍스트를 다시 로드해야 합니다. AI는 사람이 할 수 있는 것을 확장하면서, 동시에 더 많은 것을 하도록 밀어붙입니다. 한 PM은 저에게 태스크가 실행 중일 때마다 또 다른 Agent를 시작하고 싶은 유혹을 참을 수 없다고 말했습니다. 더 많은 일을 하는 것이 목표가 아닙니다. 저희는 이것을 축하할 속도가 아니라 해결해야 할 문제로 다루고 있습니다.
정보가 더 흩어졌습니다. 저희 제품 책임자는 예전에는 모든 변경 사항과 그 이유를 알고 있었습니다. 이제 그는 가끔 문제를 스크린샷으로 찍어 Mono에게 "누가 이걸 바꿨어?"라고 묻습니다. 웃기지만, 질문은 진짜입니다. 모든 사람이 제품을 변경할 권한을 가질 때, 전체에 대한 책임은 누가 지는가?
공유 권한은 재설계가 필요합니다. 업무가 공유되고 넘겨질 수 있으며, Agent들이 저희의 더 많은 대화에 참여함에 따라, 무엇을 공개하고 무엇을 승인해야 하는지 결정해야 합니다.
저희의 해결책은 아직 기본적입니다. 지금은 한 Agent가 다른 Agent들을 감독하고 막힌 것과 사람의 결정이 필요한 것만 보고합니다. 더 나아질 수 있다는 것을 알고 있습니다.
11. 다음으로 구축하고 있는 것
이러한 문제들은 다른 팀들도 아마 필요로 하게 될 제품 작업을 가리킵니다. 우리는 이러한 기능들을 미리 계획하지 않았습니다. 그것들은 우리가 스스로 계속 부딪히던 문제들에서 비롯되었습니다.
•공유 작업 공간으로서의 세션. 한 사람이 문제를 제기하고, 디자이너가 해결책을 제안하고, 엔지니어가 그것을 구축하고, PM이 그것을 실행하는 모든 것이 같은 장소에서 이루어집니다.
•디바이스와 사람들을 넘나드는 작업. 로컬 머신과 클라우드 머신이 연결된 상태를 유지하여, 사람들이 자리를 비웠을 때도 작업이 계속될 수 있습니다.
•사람들이 미처 고려하지 못한 옵션을 찾아내는 Agent. 적절한 권한을 가지고 회사 시스템 내부에서 작업하는 Agent는 단순히 지시를 수행하는 것이 아니라 해결책을 제안할 수 있어야 합니다.
우리는 먼저 우리 자신에게 이러한 것들을 시도해 본 뒤, 사용자들에게 선보일 것입니다.
12. 사람들이 지금 하는 일
여러 Agent 세션을 열어놓은 엔지니어의 모습은 단지 효율성에 관한 이야기가 아닙니다. 그것은 조직이 작동하는 방식의 변화입니다. 기업들은 과거에 역할과 위계를 통해 정보를 이동시켰습니다. 한 사람이 할 수 있는 일은 얼마나 많은 사람과 자원을 활용할 수 있는지에 달려 있었습니다. 이제 우리는 AI에게 맥락과 도구를 제공하는 데 약간의 시간을 쓰고, 판단과 결정을 내리는 데 더 많은 시간을 씁니다. 점점 더 자주, 우리에게 문제를 가져오는 쪽이 Agent입니다. 그것에 대해 무엇을 할지 결정하는 것은 여전히 우리의 몫입니다.
우리는 이에 대해 농담해왔습니다: Manus가 이 정도까지 할 수 있다면, 왜 사무실에 나오나요? Agent들끼리 알아서 처리하게 두면 되지 않나요? 하지만 중요한 질문들은 여전히 사람들이 제기하고, 논쟁하고, 결정해야 합니다. 예를 들어, 무엇이 좋은 제품으로 간주되는가? 또는 조금 과장해서 말하자면, AI의 한계를 계속 밀어붙이는 진정한 매출을 가진 훌륭한 제품을 만들 것인가, 아니면 마진을 추구할 것인가? AI는 우리가 어느 쪽을 원하는지 모릅니다. 우리는 압니다. 문화와 신뢰는 매일, 그리고 중요한 순간에 함께 문제를 헤쳐나가는 데서 비롯됩니다. 그것이 모든 세션의 작업이 기반을 두는 토대입니다.
그래서, 지금으로서는 우리의 답은 이렇습니다. AI 네이티브 조직으로서의 우리의 실험에서, 사람들의 역할은 축소되지 않았습니다. 그것은 그들이 가장 큰 영향력을 발휘할 수 있는 영역에 더욱 집중되었습니다: 문제를 정의하고, 품질을 판단하고, 무엇이 할 가치가 있는지 결정하고, 결과에 대해 책임을 지는 것.
그것이 또한 우리가 여전히 채용을 진행하고 있는 이유입니다. 사람들의 기술과 판단력이 이 작업 방식의 중심에 있으며 — 그것은 당분간 바뀌지 않을 것입니다.
이 글을 쓰면서, 나는 지금으로부터 1년 뒤에 이 게시물이 무엇을 말할지 궁금합니다. 모든 회사는 서로 다른 목표, 구조, 문화를 가지고 있으므로, 표준적인 답이나 최종적인 형태는 없을 수도 있습니다. 하지만 Agent를 구축하는 회사에게, 사람과 AI가 어떻게 함께 일하는지 알아내는 것은 선택 사항이 아닙니다. 그것은 업무의 일부입니다. 우리는 계속 노력할 것이고, 배운 것을 계속 공유할 것입니다.
숫자에 관한 참고 사항. 이 게시물의 수치는 내부 기록에서 가져온 것입니다. 팀 규모와 PM 배포 수치는 10월 말 기준입니다. 일부 지점은 측정값이 아니라 추정치이거나 한 사람의 경험입니다.
