핵심 요약

  • 클레어의 시험에서 메타의 개인 AI 에이전트 Muse는 가족 일정과 아침 소식지를 매끄럽게 다뤘지만, 브라우저를 이용한 쇼핑에서는 오류를 보였다.
  • Muse는 개인 정보가 필요한 순간 접근 권한을 묻고, 알아낸 내용을 확인한 뒤 행동에 앞서 다시 허락을 구했다.
  • 워프의 AI 팩토리 Wilson은 슬랙 요청부터 작업 분류, 구현, 테스트와 PR 생성까지 개발 과정을 연결한다. 잭 로이드에 따르면 착수부터 PR까지 평균 35분이 걸리지만 첫 인간 검토는 3.5시간 뒤에 이뤄진다.
  • 워프는 PR당 인간 개입 횟수와 에이전트 실행 평가를 살피고, 실제 작업을 재실행해 모델을 비교한다. 로이드는 무엇을 만들지 결정하는 일에는 여전히 고객 이해와 제품 판단이 필요하다고 봤다.

Muse가 만든 가족용 아침 소식지

클레어는 메타의 개인 AI 에이전트 Muse로 가족 일정 관리, 이메일 정보 활용, 목표 설정, 브라우저 구매를 시험했다. 클레어의 평가에 따르면 Muse는 테스트 과정에서 터미널이나 이해하기 어려운 오류를 드러내지 않았고, 부자연스러운 순간에 권한을 요청하지도 않았다.

Muse가 첫 시도에 만든 가족용 아침 소식지는 클레어가 OpenClaw와 Codex로 만들어 본 결과보다 보기 좋고 구성이 세심했다. PDF에는 아이와 뉴스를 이야기할 때 쓸 질문이 담겼고, 일정 충돌도 찾아냈다. 이는 클레어의 한 차례 사용 경험에 근거한 비교다.

개인 정보를 다루는 권한 요청과 작업 기록

Muse는 처음부터 모든 정보에 접근하는 대신 해당 정보가 필요한 시점에 허락을 구했다. 클레어의 이메일을 읽어 가족 정보를 정리한 뒤에는 파악한 내용을 요약해 보여주고, 그 정보를 사용해도 되는지 다시 물었다.

각 작업의 활동 기록에는 도구 호출, 스크립트, 검색과 개별 수행 단계가 남았다. 클레어는 결과에 이르기까지의 과정을 확인할 수 있다는 점을 높이 평가했다. 화면에서 쓰는 말도 기술 용어보다 피드, 아이디어, 목표, 라이브러리처럼 일상적인 표현에 맞춰져 있었다.

지속적인 목표와 브라우저 작업의 한계

Muse는 한 번에 끝낼 수 없는 개인 목표에도 여러 차례 문맥을 모으고 알림을 설정했다. 클레어가 시험한 사례는 작은 집에서 방을 함께 쓰며 생후 8개월 반 아이의 수면 습관을 조정하는 일이었다.

반면 특정 색상의 뉴발란스 9060을 찾는 쇼핑 작업에서는 잘못된 결과를 제시했고 구매도 마치지 못했다. 영화 오디세이 표를 살 때는 더 나은 모습을 보였지만 처음에는 다른 영화를 열었다. 클레어의 시험은 Muse의 브라우저 작업이 아직 일관되게 성공하지는 않는다는 점을 보여줬다.

워프의 AI 팩토리가 연결한 개발 과정

워프 공동 창업자이자 CEO인 잭 로이드는 AI 팩토리를 코드를 작성하는 에이전트 하나가 아니라 개발 과정 전체를 조율하는 체계로 설명했다. 워프의 Wilson은 슬랙 요청을 받아 작업을 분류하고 Linear 티켓을 만든 뒤, 구현과 PR 생성, 컴퓨터를 이용한 품질 확인, 병합까지 이어갈 수 있다. 원문 제목은 워프의 월간 PR 규모를 2,000건으로 제시한다.

로이드에 따르면 Wilson이 작업에 착수해 PR을 만들기까지는 평균 35분이 걸린다. 반면 첫 인간 검토는 3.5시간 뒤에 도착한다. 워프는 에이전트에게 작업을 요청한 사람도 결과를 검토할 수 있게 했지만 인간 검토 자체를 없애지는 않았다. 로이드는 신뢰가 쌓이면 일부 변경 사항은 사람의 검토 없이 병합할 수 있을 것으로 예상했다.

속도보다 인간 개입과 실행 품질을 측정한다

로이드는 PR당 인간 개입 횟수를 팩토리 효율의 핵심 지표로 본다. 슬랙의 추가 지시, 티켓의 설명 보완, 코드 검토 중 수정 요구가 늘어나면 에이전트가 빠르게 코드를 작성해도 사람의 시간이 병목이 되기 때문이다.

워프는 실제 팩토리 작업을 다른 모델 설정으로 다시 실행하고, 운영 환경에서 쓰는 평가 방식으로 결과를 비교한다. 로이드는 워프의 작업에서는 모델 선택이 비용에 가장 큰 영향을 주고 문맥 관리가 그다음이라고 설명했다. 모든 에이전트 실행도 여러 항목으로 평가한다. 여기에는 현재 동작만 확인하는 중복 테스트를 만들었는지가 포함된다. 평가 비용을 감안해 중간급 모델을 판정에 사용하고, 작업별로 평가 비율을 조절할 수 있다.

실패한 실행은 개선 자료가 된다. 워프는 보통 20~25개 사례가 모여 패턴을 확인할 수 있을 때 관찰 에이전트가 원인을 분석하고 에이전트 설정 변경을 제안하도록 한다. 설정이 코드로 관리되기 때문에 에이전트가 자신이 따르는 지침을 수정하는 흐름도 가능하다.

개발 밖의 활용과 남은 제품 판단

대담 중 로이드는 Figma 슬라이드 재설계, 최근 4주간 Granola 대화 기록에서 가장 흔한 영업 질문 10개 추출, Google Sheets의 잠재 고객 재접촉 목록 작성을 병렬로 실행했다. 슬라이드도 쓸 만했지만, 로이드는 영업 대화 분석이 더 중요했다고 봤다. 분석은 ‘구매할지 직접 만들지’가 가장 빈번한 고객 질문이라고 제시하고 근거를 함께 보여줬다.

Wilson 작업은 공유 슬랙 채널에서 진행돼 동료들이 숙련자의 지시와 수정 과정을 볼 수 있다. 다만 로이드는 구현 속도가 빨라져도 무엇을 만들지는 별개의 문제라고 강조했다. 워프는 그 판단을 위해 사용자 인터뷰, 디자인 논의와 실제 사용 관찰을 계속한다.

Muse 사례는 개인 AI에서 정보 접근 방식과 작업의 가시성이 사용 경험을 좌우함을 보여준다. 워프 사례는 개발 자동화의 성과를 코드 작성 속도만이 아니라 인간의 개입, 평가 품질과 제품 판단까지 함께 살펴야 함을 보여준다.