잠깐 써봤지만 클라우드 의존으로 너무 느리고 가격도 너무 비쌈. 대부분 개발자는 이미 구독형 서비스를 쓰고 있음. 기본 프롬프트만 넣은 Claude가 더 낫고, 스킬을 쓰면 더 좋아지며, Maestro 스크립트까지 쓰면 한층 더 나음.
공동 창업자 Jeff임. 좋지 않은 경험을 했다니 죄송하며, [email protected]로 보내주면 각 건을 면밀히 살펴보겠음.
대규모 브라우저·기기군에서 테스트를 병렬 실행하므로 실제로는 Claude보다 훨씬 빨라야 하며, 공개된 벤치마크로도 입증됨. 모바일 사용자 중에는 Maestro에서 넘어온 경우가 많은데, 유지보수 부담이 매우 크다고 들음.
내 구독으로 Opus 5.5와 직접 만든 Playwright 기반 실행 환경을 앱에 연결해 돌리는 것보다 어떤 점이 더 나은가?
실제 QA 요구사항에 맞춘 제로샷 그래프를 직접 만들어 쓰는 것과 비교하면 어떨까?
Momentic 엔지니어 Gabe임. Mo의 장점은 발견하는 버그의 총량임. 60분 세션 기준으로 Claude Code보다 약 5배 많은 버그를 찾으면서 버그당 비용은 35% 낮음.
이런 서비스보다 내가 만든 실행 환경에 붙일 수 있는 오픈 소스 도구를 항상 고르겠음. 비슷한 성능의 경쟁 도구가 나오지 않을 것으로 보는가? YC 2024 출신이라면 지난 2년 동안 무엇을 했는지도 궁금함.
진정한 차별점은 실제 기기에서 모바일 개발 빌드를 지원하는 것일 텐데, 로드맵에 있는지와 구현 계획을 알고 싶음. 실제 기기를 서비스 측에서 관리해 준다면 돈을 낼 의향이 있음.
Mo를 만드는 엔지니어 Henry임. 앞으로도 경쟁자는 많이 등장하겠지만, 이런 성능 개선은 쉽지 않으며 지난 2년간 구축한 내부 도구에 크게 의존함. 경쟁자가 과거의 우리 성능에 도달하더라도 우리도 계속 발전할 것이며, 벤치마크의 재현율을 보면 개선 여지도 여전히 큼. Mo는 두 번째 제품임. 지난 2년간 자연어로 테스트를 작성하고 거의 유지보수 없이 관리하는 Momentic E2E 테스트 프레임워크와 주변 도구를 개발함. 에이전트가 효율적으로 사용할 수 있도록 기반 도구를 다듬어 둔 것이 Mo에도 도움이 됨.
실제 기기 지원은 이미 개발 중이며, 몇 주 안에 공개할 예정임. 준비되면 연결하고 싶음.
소개문에 따르면 Mo는 지난 3년간의 Momentic 개발과 실제 복잡한 앱의 수백만 테스트 실행 기록을 바탕으로 만들었고, 재현율을 우선한다고 함. 그런데 정밀도는 Codex가 86%, Mo가 84%이고, 버그당 비용도 Mo는 $2.67, Codex는 $0.80임. 이게 좋은 결과인가? Mo가 버그당 돈이 더 든다는 뜻이라 혼란스러움.
Mo 엔지니어 Henry임. 숫자는 맞지만 우리가 강조하는 부분은 다름. Mo는 같은 시간에 차순위 QA 에이전트보다 실제 버그를 3배 넘게 발견함. 실제 버그를 놓치고 결함 있는 코드를 운영 환경에 배포하는 것이 QA에서 가장 나쁘기에 이 지표를 최적화함.
현재는 높은 재현율을 얻는 대신 비용이 더 들며, 정밀도는 대체로 비슷하지만 조금 낮음. 모든 지표에서 앞서고 싶고 개선 중이지만, 지금은 도구의 성능을 솔직하고 투명하게 공개한 것임. 자세한 내용은 전체 글을 참고하면 됨.
그렇다면 Codex가 더 좋고 더 저렴하다는 결론 아닌가?
본문 그대로, 비용은 더 들지만 버그도 더 많이 찾는다는 뜻임.
로그인하자 “Momentic invited you to work together”라는 초대가 옴. 어디에도 안내된 기억이 없는데, 이메일을 Slack에 자동으로 넘겨 연락하는 듯함. Momentic 설정을 확인하니 알림 항목의 Slack은 꺼져 있었음.
공개 이메일을 썼으니 나는 상관없지만, 다른 사람에게는 민감할 수 있음.
에이전트가 앱을 QA할 때 방향성 비순환 그래프(DAG)로 탐색 범위를 체계적으로 넓히는 접근에는 가치가 있어 보임. 직접 써보니 코딩 에이전트의 Playwright QA는 특정 유형의 버그를 매우 잘 잡지만 일부 경계 사례는 놓치곤 함. 따라서 버그당 비용이 높아도 더 많이 잡는 것은 유용함.
다만 이 방식은 코드베이스 전체를 훑을 때만 유용한 것 아닌가? 기능별 에이전트 반복 작업에 통합하면 변경된 기능 하나만 검사하므로 QA 범위가 이미 좁고, 이런 탐색의 철저함, 즉 재현율 최적화의 중요성도 줄어들 듯함.
PR 검사는 범위가 제한되므로 다른 에이전트 대비 가장 큰 이점이 코드베이스 전체 검사에서 나온다는 데 동의함. 그래도 기능별로 Mo를 실행할 가치는 있음. 이전 실행에서 얻은 지식을 활용해 효율적으로 검사할 수 있고, 앱이 발전함에 따라 그래프를 확장해 DAG를 최신 상태로 유지하는 데도 도움이 됨.
이 분야의 다른 제품으로 개념 검증과 시험 사용을 해본 뒤 몇 가지 궁금한 점이 생김. Momentic의 공급업체 종속성은 어느 정도인가? 에이전트가 Playwright 등의 테스트를 생성·유지하는 성숙한 QA 플랫폼이 들어설 여지가 있다고 봄. 필요할 때 다른 도구로 옮기거나, Momentic이 폐업하거나 호환성을 크게 깨는 변경을 하더라도 계속 쓸 수 있을 만큼 코드나 테스트 규격이 개방되어 있는가? 테스트의 결정성은 어느 정도이며, 주 사용자는 제품 책임자, 개발자, 테스트 개발 엔지니어(SDET) 중 누구인가? 또 Codex의 정밀도는 86%, Mo는 84%이고 버그당 비용은 각각 $0.80과 $2.67이라면 Codex가 더 좋고 저렴하다는 뜻인가?
공동 창업자 Jeff임. Mo는 자연어 테스트를 생성하지만, 원한다면 Playwright 테스트를 작성해 저장소에서 유지하도록 요청할 수 있음. 별도의 회귀 테스트 제품도 자연어 테스트를 저장소에 보관함. 이쪽은 자체 CLI만 브라우저 동작으로 변환할 수 있는 독점 형식이라 공급업체 종속성이 일부 존재하지만, 자연어이므로 이식 자체는 비교적 쉬움.
Mo는 탐색적 테스트에 집중하므로 본질적으로 비결정적임. 반면 회귀 테스트 제품에는 단일 CSS 선택자에 의존하는 수준을 넘어 다양한 캐싱이 적용됨. 신뢰성과 지연 시간을 최적화하는 핵심이며, 이것이 없으면 적당한 규모의 테스트 모음만으로도 CI가 몇 시간씩 걸릴 수 있음. https://momentic.ai/blog/teaching-browser-agents-user-intent.
회귀 테스트 제품은 코드베이스와 Git 사용이 필요해 SDET·개발자 중심이었음. Mo는 진입 장벽을 낮춰 제품 책임자, PM, QA, 경영진까지 쉽게 쓰도록 설계했지만, 핵심 사용자는 여전히 개발자임. 결국 우리가 직접 쓰고 싶은 제품을 만들고자 했음.
우리는 주어진 시간에 발견하는 버그 수, 즉 재현율을 최적화함. 벤치마크에서는 정밀도가 대략 비슷하면서 Codex와 Claude Code보다 약 3~5배 많은 버그를 발견함. 단순 실행 환경보다 비싸지만, 인프라와 병렬 에이전트 등을 모두 포함한 가격임.
일반적인 E2E 테스트처럼 항상 실행하는 고정 테스트를 작성하면서도, Cypress 등을 쓸 때처럼 요소의 사소한 변경으로 테스트가 깨질까 걱정하지 않아도 되는가?
Momentic 엔지니어 Gabe임. 가능함. Momentic CLI는 자연어로 요소를 찾고 검증 조건을 정의하는 등의 기능을 갖춰, 작은 요소 변경으로 테스트가 실패하는 것을 걱정하지 않고 E2E 테스트를 실행하도록 설계됨. 곧 Mo에 요청해 기존 테스트를 갱신하고 새 검사 범위도 추가할 수 있게 될 예정임.
한동안 Momentic을 써보고 싶어서 플랫폼에서 Mo를 실행해 봤는데, 시작 안내가 거의 없고 인증 설정 단계에서 막힘. 설정 방법을 찾으려고 20페이지씩 눌러볼 시간은 없음. 정말 마음에 들기를 바랐는데 아쉬움.
시작 과정이 기대에 못 미쳐 죄송함. [email protected]로 계정 정보를 보내주면 원인을 조사하고, 설정을 마쳐 Momentic을 사용할 수 있도록 돕겠음.
내 사이트의 한 페이지를 검사해 보니 버그 수 표시가 서로 맞지 않음. "Live Mo's screen" 아래에는 "No bugs yet"이 뜨는데 상단 탭에는 "Bugs: 11"이 표시됨. 완료 후에도 본문에는 "Mo didn't find any bugs"이라고 뜨지만 탭에는 "Bugs: 12"라고 나옴. "Needs review" 목록에 있어서 그렇더라도, 검토 대기 중인 것을 버그가 없다고 표시하는 이유를 모르겠음.
심각도가 분명히 다른데 모든 버그가 "medium"으로 분류됨. 분류 기준을 툴팁으로 보여주고, 보고서에서 어떤 버그를 "high priority"로 취급할지 직접 설정할 수 있으면 좋겠음. "stop testing" 버튼이 거의 마지막에야 나타남. 프롬프트를 고치거나, 기다리기 싫거나, 예산 소모를 막는 등 중단할 이유가 많은데 테스트 도중에는 버튼이 보이지 않았음.
발견한 버그 목록을 내보내는 기능도 있으면 좋겠음. 제목을 수동으로 복사할 수는 있지만, 초기 점검 결과를 관계자에게 공유할 수 있도록 정식 내보내기를 지원하면 편리하겠음.
버그 수 불일치는 프런트엔드 오류로 보이며, 데이터 재검증이 빠졌을 가능성이 있음. 심각도 기본값도 좀 더 조정해야 할 듯함. 분류 기준은 설정에서 직접 변경 가능함. https://app.momentic.ai/settings/mo.
"stop testing" 버튼도 확인하겠음. 내보내기는 어떤 형식을 원하는가? 현재 Linear나 다른 프로젝트 관리 도구로 버그를 동기화하는 연동을 지원하며, CLI의 qa report --output mo-report 로 전체 결과를 내보낼 수도 있음.