Momentic, 앱을 직접 사용해 버그를 잡는 AI 에이전트로 11만 7천 개 버그 적발
Launch HN: Momentic (YC W24) – Agents that catch bugs by using your app
Momentic은 앱을 실제로 조작하며 버그를 찾는 AI QA 에이전트 'Mo'를 공개했다. 지금까지 7만 7,813개의 테스트를 생성하고 7,060만 회 이상 실행해 11만 7,010개의 버그를 잡아냈다. Notion, Quora, Webflow, Runway 등이 도입했으며, 평문 YAML로 테스트를 작성하고 CI에서 CLI 종료 코드로 검증하는 방식이다.
코딩 에이전트 덕분에 소프트웨어를 만드는 속도는 극적으로 빨라졌다. 이제 병목은 그것이 제대로 작동하는지 아는 일이다.
HN 토론
75- ice_cream_man_9
출시 축하드립니다! 흥미로워 보이네요. 제 사이트의 한 페이지에서 검사를 실행해봤습니다. 눈에 띈 몇 가지 점을 공유합니다 - 도움이 되셨으면 좋겠네요:
- 약간 혼란스럽습니다: "Live Mo's screen" 아래 창에는 "No bugs yet"이라고 나오는데, 상단 탭(Agents / Bugs / Mo's screen)에는 "Bugs: 11"이 표시됩니다. 프로세스가 끝난 후 창에는 "Mo didn't find any bugs"라고 나왔지만, 상단 탭에는 "Bugs: 12"가 표시되었습니다. 아마도 "Needs review" 목록에 있기 때문일까요? 그렇다면 검토 대기 중이라면 왜 버그가 없다고 표시되는 걸까요?
- 발견된 모든 버그가 심각도가 분명히 다른데도 "medium"으로 표시됩니다. 프로그램이 이러한 레이블을 어떻게 할당하는지 설명하는 툴팁을 추가하면 도움이 될 것입니다. 더 나아가, 예를 들어 제 보고서에 "high priority"로 플래그 지정할 버그를 사용자 지정할 수 있는 옵션이 있으면 좋겠습니다.
- "stop testing" 버튼은 프로세스가 거의 끝날 때만 나타났습니다. 뭔가 놓쳤을 수도 있지만, 마음이 바뀌어 프롬프트를 수정하고 싶거나, 기다리는 게 지루해지거나, 단순히 예산을 낭비하고 싶지 않을 때 등 중단하고 싶은 이유는 많습니다. 그런데 테스트가 진행되는 동안에는 버튼이 없었습니다.
- 발견된 버그 목록을 내보낼 수 있는 옵션이 있으면 좋겠습니다. 어차피 수동으로 선택해서 제목을 복사할 수 있으니, 제대로 된 내보내기 기능을 제공하지 않을 이유가 없습니다. 초기 감사 결과를 [...]와 공유할 수 있을 것입니다.
- beavisringdin
질문:
- 저는 이런 서비스를 사용하는 것보다 커스텀 하네스에 붙일 수 있는 오픈 소스 도구를 항상 선택할 것입니다. 성능이 동등한 경쟁자가 나타나지 않을 것이라고 어떻게 예상하시나요?
- YC 2024라면 지난 2년 동안 무엇을 하셨나요?
- 진정한 강점은 실제 기기에서 모바일 개발 빌드를 지원하는 것일 텐데, 로드맵에 있나요? 있다면 어떻게 지원할 계획인가요? 그렇다면 실제 기기를 귀사에서 처리해 주신다면 기꺼이 비용을 지불할 의향이 있습니다.
- JulianPaul
왜 이것이 제 구독으로 Opus 5.5를 직접 제 앱에 대해 커스텀 Playwright 기반 하네스로 실행하는 것보다 나은가요?
- daniiel
정밀도/재현율이 제가 가장 먼저 볼 지표인지는 잘 모르겠습니다. 왜냐하면 제가 실제로 알고 싶은 것은 도구가 이미 깨진 흐름에 대해 통과라고 말하는 빈도이고, 조용한 통과는 불안정한 테스트보다 더 나쁘기 때문입니다. 불안정한 테스트는 적어도 소음을 내니까요.
저는 같은 분야에서 무언가를 만들고 있는데, 이 문제를 꽤 일찍 겪었습니다. 그래서 제가 결국 한 것은 기본적으로 변이 테스트였습니다: 오픈 소스 앱 몇 개를 가져다가 의도적으로 버그를 심고, 도구가 그중 몇 개를 그냥 통과시키는지 세는 것입니다. 통과/실패 횟수는 전혀 흥미로운 부분이 아니었던 것 같습니다. 흥미로운 부분은 엔진이 세 번째 옵션인 "I can't tell"로 답할 수 있게 하는 것이었습니다. 왜냐하면 그것이 허용되자 거짓 통과가 대부분 사라졌고, 단순히 추측을 멈췄기 때문입니다. 저는 추측에 의한 통과는 테스트가 없는 것보다 나쁘다고 말하고 싶고, 같은 이유로 모든 실행을 재현 가능하게 유지합니다. 그렇지 않으면 제 숫자도 믿을 수 없을 테니까요.
Mo(좋은 이름이네요)가 중간 지대를 어떻게 처리하는지 궁금합니다. 문서에 따르면 재현할 수 없는 버그는 확인된 것으로 보고되지 않는다고 하는데, 어딘가에 표시되나요 아니면 그냥 버려지나요? 그리고 QA Bench의 경우, 버그를 직접 심으셨나요 아니면 기존 버그에 레이블만 지정하셨나요?
- podoman
> Mo는 지난 3년간의 Momentic과 복잡한 실제 애플리케이션에서 얻은 수백만 건의 테스트 추적을 기반으로 버그를 잡는 커스텀 에이전트 하네스입니다. Mo는 재현율을 위해 구축되었습니다: 가장 실제 버그를 많이 찾지만, Codex가 86% 대 84%로 약간 더 정밀합니다. 트레이드오프는 비용입니다: Mo는 버그당 $2.67로 Codex의 $0.80보다 비싸지만, Claude Code와 Devin보다는 저렴합니다.
이게 좋은 건가요? 그러니까 Mo가 버그당 더 많은 비용이 든다는 건가요? 혼란스럽네요.