Momentic Mo 출시: AI QA 에이전트가 앱에서 버그를 찾습니다 (QA Bench vs Codex, Claude Code, Devin)

Momentic의 Mo가 베타를 종료하고 이제 에이전트형 QA 엔지니어로 일반 공개되었습니다. 실제 애플리케이션을 처음부터 끝까지 구동하고, 버그를 찾아내며, 발견한 내용을 파일로 정리합니다. 이번 출시가 중요한 이유는 검증을 코딩 에이전트가 이미 활동하는 루프에 통합하기 때문입니다. Mo는 코딩 에이전트 세션, PR 댓글, Momentic 앱 또는 qa CLI에서 실행되며, Mo가 버그를 보고하기 전에 별도의 에이전트가 각 기능 버그를 재현하려고 시도합니다. 출시 HN 스레드(155포인트, 105댓글)는 구체적인 벤치마크 호기심과 버그당 비용, UI 아래의 관찰 가능성, 벤더 종속, 시끄러운 온보딩에 대한 날카로운 회의론이 섞여 있었습니다.

Mo가 무엇이고 어디에 적합한가

Mo는 3년간의 Momentic 작업과 실제 애플리케이션의 수백만 테스트 추적을 기반으로 구축된 맞춤형 에이전트 하네스로, 테스트 작성보다는 검증에 초점을 맞춥니다. Momentic 사이트는 문제를 다음과 같이 설명합니다: "코딩 에이전트는 소프트웨어를 훨씬 빠르게 구축할 수 있게 만들었습니다. 이제 병목은 작동하는지 아는 것입니다." Mo는 에이전트 루프 내부에 속하는 것으로 판매되며, 변경 사항을 작성한 코딩 에이전트가 MCP를 사용하여 테스트를 작성하고, 라이브 세션에서 확인하고, 코드와 함께 YAML을 커밋할 수 있습니다.

출시 시점에 공개된 사이트 누적 수치:

생성된 테스트: 77,813
실행된 테스트 실행: 70,607,819
검증된 변경 사항: 339,166
검증된 PR: 80,290
자동 치유: 8,932,104
발견된 버그: 117,010

주요 고객으로는 Notion, Quora, Webflow, Framer, Xero, Whatnot, Retool, Runway, Bilt, Collectors, Podium, SPS Commerce, GPTZero, Vapi, Mutiny, Squire, Arena, Kumo가 있습니다.

5단계 워크플로우

Momentic은 제품을 5개의 루프로 설명합니다: 각 AI 단계에서 에이전트가 참조할 용어, 비즈니스 규칙 및 예상 동작을 기록하는 지식 베이스; 실행 중 UI가 변경될 때 컨트롤을 다시 찾는 런타임 복구; 검토를 위해 테스트 파일 diff를 제안하는 영구 치유; 코딩 에이전트가 테스트를 작성하고 확인할 수 있는 MCP 통합; 스크린샷과 추적이 포함된 단계별 실패 증거; 병합 또는 배포 전에 종료 코드를 요구할 수 있는 CLI.

테스트는 일반 영어 YAML로 작성되어 저장소에 버전 관리됩니다. 분류 루프는 실패를 애플리케이션 버그, 불안정성 또는 환경 문제로 분류하고, AI 분류는 검토를 위한 수리를 제안합니다.

QA Bench 결과: Mo 대 Codex, Claude Code, Devin

QA Bench는 Gitea, Metabase, Twenty 및 Saleor 전반의 20개 영역에서 Mo, Codex, Claude Code 및 Devin을 평가했으며, 각 영역당 60분이 주어졌습니다. Momentic은 Mo가 약 269개의 라벨링된 버그를 찾았고, 다음으로 좋은 에이전트는 약 86개를 찾았다고 보고합니다.

Momentic의 자체 출시 프레임은 스레드를 지배한 두 가지 정직한 주의 사항을 추가합니다. 정밀도: Mo 84% 대 Codex 86%. 비용: "Mo는 버그당 $2.67로 Codex의 $0.80보다 비싸지만 Claude Code와 Devin보다는 저렴합니다." 한 댓글 작성자 @podoman은 이를 눈에 띄게 혼란스러운 표정으로 읽었습니다:

이게 좋은 건가요? Mo가 버그당 더 많은 비용이 드는 건가요? 혼란스럽네요.

같은 트레이드오프가 @staindk에 의해 제기되었으며, 이 프레임이 효과적으로 Codex가 더 낫고 더 저렴하다고 말하는 것인지 물었습니다. Momentic의 자체 입장은 재현 우선입니다: 다른 에이전트가 놓치는 버그를 잡는 대가로 낮은 정밀도와 높은 버그당 비용을 수용합니다.

하네스가 탐색하는 방법: DAG 탐색 및 재현

Momentic은 Mo를 DAG 기반 탐색 그래프로 설명하며, 댓글 작성자들은 이를 실질적인 기술적 주장으로 받아들였습니다. @2001zhaozhao는 DAG가 탐색 표면적을 체계적으로 증가시키기 때문에 거기에 실제 무언가가 있다고 주장했으며, 개인적인 경험에서 코딩 에이전트 내의 Playwright 스타일 QA 단계가 특정 버그 클래스를 안정적으로 잡지만 가장자리 사례는 놓친다고 언급했습니다. 같은 댓글 작성자는 핵심 뉘앙스를 제공했습니다:

이 DAG 접근 방식은 코드베이스 전체 버그 스윕에만 유용한 것 같습니다? 실제로 기능별 에이전트 루프에 통합하면 각 변경 후 QA는 이미 좁습니다(변경된 기능 하나만 테스트하면 되므로), 그래서 이런 탐색 철저성 최적화(작성자 자신의 말로 "재현")는 덜 중요합니다.

@karinago는 해당 맹점 우려를 제기했습니다: 판매 포인트가 LLM이 자신의 가정을 강화하기 때문에 테스트에 서툴다는 것이고, Mo가 Momentic 자체 제품의 수백만 추적으로 구축되었다면, 하네스가 모델 수준이 아닌 하네스 수준에서 맹점이 생기는 것을 어떻게 피합니까?

Momentic이 Mo가 잡았다고 말하는 예시 버그

사이트는 감지 단계별로 라벨링된 흐름 및 영향별 익명화된 버그 세트를 게시합니다. 대표적인 예:

소비자 핀테크 로그인 라우팅 변경이 새 기기 2FA 프롬프트를 조용히 건너뛰었으며, 기능 브랜치에서 감지됨.
라이드셰어 앱의 실시간 ETA 구독이 종속성 업데이트 후 조용히 실패했으며, 스테이징에서 감지됨.
웰니스 앱의 iOS 수명 주기 변경이 화면 잠금 시 활성 수면 타이머를 재설정했으며, CI에서 감지됨.
음식 배달 결제 양식 리팩터링이 체크아웃 시 저장된 카드 사전 채움을 중단했으며, 배포 8분 전에 감지됨.
소매 마켓플레이스가 2페이지로 이동할 때 모든 활성 카테고리 및 가격 필터를 재설정했으며, 야간 실행에서 감지됨.
여행 마켓플레이스의 검증 변경이 최종 체크아웃 단계에서 다중 구간 프로모션 코드를 거부했으며, 병합 전에 감지됨.
스트리밍 플랫폼의 로케일 감지 버그가 첫 재생 시 잘못된 자막 트랙을 선택했으며, 출시 전에 감지됨.
하루 스윕이 12개의 버그를 잡았고 감지되지 않고 출시되었을 레거시 API 문제를 노출했으며, 출시 전에 감지됨.

이것들은 제품 마케팅 주장이며 그렇게 취급해야 합니다; 출처는 재현을 제공하지 않습니다.

댓글 작성자들이 도전한 것: 비용 모델, 관찰 가능성 및 종속

토큰 비용 및 BYO 구독 질문

가장 직접적인 경제적 반대는 @aliasxneo에서 나왔으며, 토큰당 SaaS 가격을 "현재 구독 위기의 스테로이드"로 규정하고 기본값은 BYOA(자체 에이전트 가져오기)여야 한다고 주장했습니다. 주장은 여러 프론티어 구독에서 남은 할당량이 있는 개발자가 Momentic 내에서 이를 사용할 수 없어 양도할 수 없는 토큰에 대한 두 번째 병렬 지출을 강요한다는 것이었습니다. @AgentMasterRace는 서비스가 짧은 사용에서 너무 느리고 비싸다고 보고했으며, 스킬과 maestro 스크립트가 있는 Claude를 선호했습니다. @JulianPaul은 기본 제품 질문을 명확하게 물었습니다: 기존 구독에서 맞춤 Playwright 기반 하네스를 사용하여 프론티어 모델을 앱에 직접 가리키는 것보다 Mo가 왜 더 낫습니까?

에이전트가 UI 아래를 볼 수 있습니까?

@bsp580은 스레드에서 가장 날카로운 기술적 관찰 가능성 질문을 던졌습니다: 실패가 화면에 없을 때 에이전트에게 실패 표면이 얼마나 보입니까?

제가 겪는 많은 실패는 화면에 보이지 않습니다: 오류 본문과 함께 200을 반환하는 요청, 재시도 루프, 조용히 실패하는 호출. 에이전트가 실패한 흐름에 대한 네트워크 트래픽을 받습니까, 아니면 스크린샷과 뷰 계층만 받습니까?

@moon0917은 QA Bench 대상 중 하나인 Saleor의 구체적인 예에서 같은 점을 제기했습니다. 그들은 더티 목록에서만 실행되어야 하는 가격 재계산 작업을 설명했지만, 필터링된 쿼리셋이 변수에 다시 할당되지 않아 모든 목록이 매 실행마다 재계산되었습니다. 단위 테스트는 관련 없는 이유로 녹색을 유지했고 no-op은 최종 출력이 여전히 유효했기 때문에 프로덕션에 남아 있었습니다. Momentic에 대한 그들의 질문: Mo가 외부 상태가 올바르게 보이는 조용한 no-op 클래스를 잡습니까, 아니면 주로 보이는 상태 차이에 연결됩니까?

결정론, 종속 및 대상 사용자

@staindk는 엔터프라이즈 채택에 중요한 구매자 질문을 그룹화했습니다: 벤더 종속이 어떻게 생겼는지, Momentic 코드 또는 테스트 표준이 플랫폼에서 이동하거나 종료를 견디기에 충분히 개방될 것인지, 테스트가 얼마나 결정적인지, 의도된 사용자가 제품 소유자, 개발자 또는 SDET인지.

@beavisringdin은 세 가지를 더 추가했습니다: 맞춤 하네스에 묶인 오픈 소스 도구 선호, YC W24 회사가 2년 동안 무엇을 해왔는지에 대한 명시적 질문, 실제 기기에서 모바일 개발 빌드 지원에 대한 로드맵 질문, 실제 기기 지원이 처리된다면 제품 비용을 지불하겠다고 제안했습니다.

재시도 루프, 통과 침묵 및 중간 지점

@bshafiq는 하네스가 로드되지 않는 요소를 클릭하는 데 갇힌 에이전트를 어떻게 처리하는지, 특히 하드 최대 단계 제한이 있는지 아니면 실행을 종료하는 더 스마트한 상태 변경 감지가 있는지 물었습니다.

@daniiel은 QA 에이전트에게 정밀도와 재현이 먼저 중요한 지표가 아니라고 주장했습니다. 최악의 결과는 이미 깨진 흐름에서 조용한 통과이기 때문입니다:

조용한 통과는 불안정한 테스트보다 나쁩니다. 불안정한 테스트는 적어도 소음을 만들기 때문입니다.

그 댓글 작성자는 변형 테스트 스타일 평가를 실행하고 오픈 소스 앱에 버그를 심고 얼마나 많은 버그가 통과했는지 계산했다고 설명했으며, "모르겠다"라는 세 번째 가능한 답변을 추가하면 엔진이 추측을 중단하여 대부분의 잘못된 통과를 제거했다고 보고했습니다. Momentic에 대한 열린 질문: Mo가 재현할 수 없는 버그가 어디에도 나타나지 않거나 삭제되는지, QA Bench 버그가 심어진 것인지 아니면 기존 애플리케이션에서 라벨링된 것인지.

비버그에서 배우기, PR 수준 범위 및 해자

@gophigure는 발견을 "버그 아님"으로 표시하는 것이 다음 실행에 Mo에게 무언가를 가르치는지, 아니면 같은 발견이 다시 나타나는지 물었습니다. @throwaway7783은 이전 고용주에서 Codex와 Claude Code에 소스 코드 액세스와 브라우저 및 Playwright 제어를 제공했다고 설명했으며, 그들이 버그를 찾고 관련 UI 및 백엔드 코드와 상관시켰다고 보고했습니다. 이는 소스 코드 액세스가 있는 벤치마크 변형을 시사합니다. @bortimus는 스레드에서 가장 간단한 질문을 물었습니다: 해자는 무엇입니까? @maxdo는 벤치마크 프레임 자체에 반박하며, 벌거벗은 버그 찾기 에이전트를 제품 지식이 있는 실제 엔지니어링 하네스와 비교하는 것은 사과와 사과 비교가 아니라고 주장했습니다.

초기 사용자가 보고한 온보딩 및 UX 마찰

모든 댓글이 아키텍처에 관한 것은 아니었습니다. @ecares는 Mo에 가입한 후 사실상 온보딩이 없었고, 인증 구성에서 흐름이 멈추고 페이지를 통과하는 명확한 경로가 없다고 보고했습니다. @ice_cream_man_9는 개인 사이트의 한 페이지에서 Mo를 실행하고 네 가지 UI 문제를 나열했습니다: 상태 표시기가 "아직 버그 없음"이라고 말하는 동안 탭은 "버그: 11"을 보고했고, Mo가 버그를 찾지 못했다고 말하는 동안 탭은 12를 보여주었습니다; 모든 버그가 심각도 기준에 대한 설명 없이 "중간"으로 라벨링되었고 우선 순위를 다시 정할 방법이 없었습니다; 테스트 중지 버튼이 실행 중 내내 사용 가능하지 않고 실행 끝에만 나타났습니다; 발견된 버그 목록에 대한 내보내기가 없었습니다. @vfosnar는 개인 정보 보호 문제를 지적하며 Momentic이 사전 통지 없이 로그인 시 연락을 위해 이메일을 Slack에 넘겨준 것으로 보이며, 제품 내 Slack 알림 설정은 꺼져 있었다고 말했습니다.

출시를 읽는 방법

Momentic의 핵심 베팅은 테스트 병목이 테스트 작성에서 코딩 에이전트의 변경이 실제로 작동하는지 아는 것으로 이동했으며, 실제 애플리케이션 추적으로 구축된 목적에 맞는 하네스가 일반 코딩 에이전트보다 재현에서 우월할 것이라는 것입니다. 게시된 QA Bench 수치는 제한된 데이터 세트에서 재현 주장을 지원하지만 Codex가 약간 더 정밀하고 버그당 훨씬 저렴하다는 것도 인정합니다. 스레드에서 가장 강력한 미해결 질문은 Mo가 뷰 계층에 표시되지 않는 조용한 실패를 볼 수 있는지, 가격 모델이 자체 에이전트 가져오기 워크플로우의 부상을 견딜 수 있는지, 팀이 벤더 관계가 종료될 때 YAML 테스트를 추출할 수 있는지입니다. 이러한 질문은 구매자가 수제 Playwright 하네스를 교체하기 전에 주장해야 할 질문입니다.