요약
Momentic의 Mo는 앱을 직접 써 보며 버그를 찾고 재현 절차와 회귀 테스트를 남깁니다.
Momentic은 와이 콤비네이터 2024년 겨울 기수 스타트업으로, 자연어로 쓰는 E2E 테스트(사용자처럼 앱 전체 흐름을 확인하는 테스트) 도구를 만들어 왔습니다. 새 제품 Mo는 웹·iOS·안드로이드 앱을 스스로 탐색하는 AI QA 에이전트입니다.
왜 중요한가
- 코딩 에이전트가 퍼질수록 배포 실패도 늘어, 실행 중인 앱을 직접 확인하는 검증이 중요해집니다.
핵심 내용
- 버그마다 재현 절차를 붙이며, 별도 에이전트가 다시 재현해 본 뒤에야 보고합니다.
- 실행 결과는 PR마다 도는 회귀 테스트(고친 기능이 다시 망가졌는지 보는 테스트)로 바뀝니다.
- UI가 바뀌면 요소를 다시 찾아 테스트를 고치고, 실패를 앱 버그·불안정성·환경 문제로 나눕니다.
작성자 설명
Momentic을 만드는 웨이웨이와 제프입니다. Playwright·Selenium 테스트에 시달린 끝에 대신 테스트할 에이전트를 만들었습니다. 앞으로의 QA는 스크립트 작성이 아니라 에이전트의 직접 시험이 될 것이라고 봅니다.
오픈소스 앱 4개에서 사람이 표시한 버그 1,396개를 두고 60분씩 겨뤘습니다. 검출률은 전체 버그 중 찾은 비율, 정밀도는 보고 중 진짜 버그 비율입니다.
- Mo: 269개, 검출률 19.3%, 정밀도 84%, 버그당 2.67달러
- Codex: 86개, 6.2%, 86%, 0.80달러
- Claude Code: 59개, 4.2%, 80%, 4.09달러
- Devin: 27개, 1.9%, 84%, 3.89달러
새로 가입하면 Mo 사용액 250달러를 드립니다.
HN 반응
- Codex보다 버그당 비용이 비싸고 정밀도도 낮다는 지적에, 팀은 진짜 버그를 놓치지 않는 검출률이 핵심이라고 답했습니다.
- 직접 만든 하네스가 더 싸다는 반론과, 찾은 버그 수보다 실행당 오탐 수가 중요하다는 실사용자 의견이 나왔습니다.
저는 직업상 실제 브라우저를 몰아서 웹사이트를 테스트하다 보니, 이런 도구를 쓰는 구매자 입장에서 말씀드립니다. 에이전트를 계속 쓸지 말지는 버그를 몇 개 찾느냐가 아니라, 빨간불이 떴을 때 제가 직접 다시 확인하지 않고도 그 결과를 믿을 수 있느냐로 갈립니다.
초반에 두 가지로 크게 데였습니다. 에이전트가 쓴 검증 코드는 검증하기 안정적인 쪽으로 흘러가는 경향이 있습니다. 페이지 문구, 고정된 설정값, 요소가 존재하는지 여부 같은 것들이죠. 이런 검증은 디자인을 싹 바꿔서 흐름이 깨져도 계속 초록불이라서, 그 테스트 묶음은 저에게 아무 정보도 주지 못했습니다. 또 한 번 실행에 노이즈 섞인 결과가 하나만 나와도 저는 리포트를 아예 읽지 않게 됩니다(그 뒤로는 진짜 문제가 들어 있어도 저에게 그 도구는 죽은 도구입니다).
제 채점 방식을 바로잡아 준 건 스테이징 복사본에 알려진 결함을 심어 두는 것이었습니다. 총액을 잘못 계산하는 쿠폰, 비활성화됐는데도 제출되는 버튼, 엉뚱한 오류 문구를 띄우는 토스트 같은 것들이요. 그다음 에이전트를 5~6번 돌려서 심어 둔 결함 중 몇 개를 보고하는지, 한 번 실행에 오탐이 몇 개인지 셉니다. 제가 보는 숫자는 찾은 버그 총수가 아니라 실행당 오탐 수입니다.
Gabe 님이 말씀하신 5배 수치와 관련해서, 서로 다른 흐름에서 같은 결함이 두 번 보고되면 중복은 어떻게 제거하나요? 그리고 체험판을 쓰기 전에 알려 주실 수 있는 실행당 오탐 수치가 있나요? 저라면 제일 먼저 물어볼 질문입니다.
이게 왜 내 구독으로 Opus 5.5에 직접 Playwright 기반 하네스를 얹어 내 앱에 돌리는 것보다 나은 거죠?
안녕하세요, 저는 Momentic 엔지니어 중 한 명인 Gabe입니다. 전반적으로 Mo의 강점은 찾아내는 버그의 총량입니다. Claude Code와 비교하면 60분 세션 기준으로 버그를 대략 5배 찾으면서 버그당 비용은 35% 적습니다.
쓴 교훈(bitter lesson)에 대해서는 어떻게 생각하세요? 모델이 계속 좋아지기만 하면 어떻게 되나요?
좋은 질문입니다. 한마디로 저희 하네스와 e2e 테스트는 최전선 모델과 경쟁하는 게 아니라 보완하는 관계입니다. 도메인 특화 작업에서는 아키텍처 선택과 여러분이 제공하는 데이터가 정말 중요합니다. Mo는 이전 Momentic 테스트 결과, 저희 KB 같은 하네스 전용 도구를 활용해서 일하게 되고, 나중에는 새 Momentic 회귀 테스트도 만들어 낼 겁니다. 모델이 더 똑똑하고 유능해지면 AI가 생성한 테스트의 효율(커버리지와 실행 시간)이 좋아지고, 탐색적 테스트에서 같은 일을 반복하는 일도 이상적으로는 줄어들 겁니다.
그럼 순정 Claude Code랑 비교했다는 건가요??? 그건 뭐... 가장 낮은 기준이잖아요.
맞습니다, 순정 CC는 꽤 형편없었어요. 그래서 agent browser와 Playwright MCP를 붙인 CC와 Codex, 그리고 Devin까지 비교했습니다. 더 보고 싶은 에이전트나 구성이 있으신가요?
누가 browser-use를 추천해 줘서 지금 벤치마크에 돌리고 있습니다. 결과는 여기에 올려 두고 있으니 더 보고 싶으시면 확인해 보세요: https://momentic.ai/qa-bench
그런 건 전부 아주 순진한 접근이라고 생각해요. 저는 지금 스크린샷과 애플리케이션 상태를 뽑는 파이프라인을 스크립트로 짠 다음, 그 스크린샷과 상태를 clef에 질문지와 함께 돌려요. 스크립트는 결정적(deterministic)이고, clef는 비용이 몇 푼 아니면 그 이하인데 믿을 만하기까지 하고, 질문지는 스크립트에서 뽑아내고 필요하면 더 강한 LMM으로 올립니다(제가 써 본 바로는 그럴 일이 거의 없었어요). "갖다 꽂으면 되는" 솔루션은 아니지만 설정은 꽤 간단하고 CI에도 붙일 수 있어요. 완벽하진 않아도 하네스가 뭐든 간에 Claude나 GPT 모델을 들이붓는 것보다 성공률이 높고 비용 효율은 훨씬 좋았어요.
말씀하신 건 일반 Momentic 테스트의 "AI 체크"라고 부르는 것과 아주 비슷합니다. 이미 알고 있는 흐름에서는 아주 잘 작동하고, 많은 고객이 Momentic을 좋아하는 주된 이유 중 하나이기도 합니다. Mo는 이걸 대체하는 게 아니라 그 위에 쌓아서, 스크립트를 미리 만들어 두지 않았거나 계속 남겨 두고 싶지 않은 새 흐름을 찾아내 테스트할 수 있게 해 줍니다. 가까운 시일 안에 Mo가 나중에 다시 돌릴 수 있는 지속 가능한 테스트도 제안하게 될 텐데(말씀하신 것과 본질적으로 똑같습니다), 이미 알려진 흐름에서는 비용이 크게 줄고 일관성이 크게 좋아질 겁니다.
알겠습니다. 그러니까 QA 테스트 흐름을 찾는 작업당 비용을 좁게 최적화하고, 결국에는 그 흐름을 지속 가능한 형태로 문서화하는 하네스라는 거네요? 누가 Mo한테 자기 컨텍스트와 도구가 어떻게 생겼는지 물어보는 걸 막는 장치는 있나요?
아니면 실제 QA 요구사항에 맞춘 커스텀 zeroshot 그래프 기반 방식도 있고요.
녹화와 단계 기록 부분이 눈에 띄었습니다. 설명만 달랑 있는 버그 리포트는 재현하기까지 보통 말이 오가는 일이 많은데, 실제 단계가 같이 있으면 그런 수고를 꽤 덜 것 같습니다. 다만 애매한 경우에도 그게 통할지 궁금합니다. 버그인지 분명하지 않은 리포트일 때, 같은 증거가 있으면 종결하기가 더 빨라지나요, 아니면 결국 누군가 파헤쳐 보고 판단해야 하나요? 그리고 유효하지 않은 리포트에 표시를 해 두면 다음에 받는 결과가 실제로 달라지나요, 아니면 그 한 번의 실행 결과만 정리되는 정도인가요?
Momentic 데모 잘 봤습니다. 저희 Vostride도 비슷한 걸 만들고 있는데, 저희는 검증 계층 자체도 누구나 검증할 수 있게 열려 있어야 한다고 생각합니다.
저희는 오픈소스 자기 개선형 QA 에이전트 agent-qa( https://github.com/vostride/agent-qa )를 만들었습니다. 하네스는 3~6개월마다 낡아 버리는데, 안타깝게도 큰 업체들은 배의 방향을 틀지 못해서 이미 뒤처져 있습니다. Momentic도 마찬가지고요.
Momentic의 벤치마크를 자기들이 만든 것이 아니라 중립적인 벤치마크에서도 보고 싶습니다.
Vostride는 agent-qa를 벤치마크에 돌려 봤고 이미 여러 곳에서 앞서고 있습니다.
AndroidWorld 벤치마크 1위 ( https://vostride.com/benchmark/android-world )
AppControlBench - https://vostride.com/benchmark/app-control-bench
agent-qa를 확인해 보세요: https://vostride.com/
GitHub - https://github.com/vostride/agent-qa
안녕하세요! 데모를 봐 주셔서 감사합니다! 다른 공개 벤치마크에서도 Mo를 돌려 보고 결과를 공유하고 싶습니다. 그런데 프레임워크가 앱에서 흐름을 그냥 실행하는 것과 구별해서 버그를 찾는 능력은 어떻게 평가하시나요? 사이트도 살펴봤는데, 미리 작성한 테스트 케이스에 의존하고 스스로 탐색하지 않는다는 점에서 Mo보다는 Momentic 회귀 테스트에 가까운 제품으로 보입니다. 비교하신다면 저희 AI action이 더 맞을 수도 있겠네요?
질문입니다.
저라면 이런 서비스보다 내 커스텀 하네스에 붙일 수 있는 오픈소스 도구를 항상 고를 겁니다. 그만큼 성능이 나오는 경쟁자가 앞으로 나타나지 않을 거라고 보시나요?
YC 2024라면 2년 동안 뭘 하셨나요?
진짜 강점은 실제 기기에서 모바일 개발 빌드를 지원하는 거라고 생각하는데, 로드맵에 있나요? 있다면 어떻게 지원할 계획인가요? 실제 기기를 그쪽에서 맡아 준다면 저는 돈을 내고 쓸 겁니다.
안녕하세요! Mo를 만드는 엔지니어 중 한 명인 Henry입니다. 질문에 답변드리겠습니다.
이미 그렇듯이 앞으로도 경쟁자는 많이 나올 거라고 예상합니다. 다만 이런 성능 향상을 이루는 건 간단한 일이 아니고, 지난 2년간 저희가 만든 많은 내부 도구에 기대고 있다고 생각합니다(다음 답변 참고). 어떤 소프트웨어든 그렇듯 결국 저희의 과거 성능을 따라잡는 새 경쟁자는 분명 나오겠지만, 저희도 제품을 계속 발전시켜 나갈 겁니다. 벤치마크의 재현율 수치에서 보시듯 아직 개선할 여지가 많습니다.
Mo는 사실 저희의 두 번째 제품입니다. 지난 2년간 저희는 Momentic e2e 테스트 프레임워크와 그 주변 도구를 만들었는데, 엔지니어링 팀이 일상 영어로 테스트를 작성하고 거의 손 안 대고 유지보수하면서 품질을 직접 책임질 수 있게 해 주는 제품입니다. 에이전트가 효율적으로 쓰고 더 나은 결과를 내도록 밑바탕 도구를 다듬는 데 이미 많은 시간을 들였기 때문에, Mo는 그 위에 잘 쌓을 수 있었습니다.
실제 기기 지원은 이미 작업 중입니다! 몇 주 안에 출시될 겁니다. 준비되면 꼭 연락드리고 싶습니다.
저는 주로 Playwright aria 스냅샷을 썼고 스크린샷은 덜 썼어요. 스크린샷에는 불필요한 정보가 너무 많은데 aria 스냅샷은 아주 잘 작동하거든요. 탐색에도 aria 스냅샷을 써 보셨나요?
그리고 와, 저도 그 2년짜리 작업과 비슷한 걸 만들고 있었어요. 그런데 테스트를 실제 코드베이스에 저장한다는 생각은 못 했어요. 바이브 코더 같은 사람들은 코드베이스를 아예 안 들여다보게 하는 게 목표였거든요. 그런데 여기 내용을 읽다 보니 제 방식을 다시 생각하게 되네요. 왜 굳이 인위적인 제약을 두고 있었던 걸까요?
답변 감사합니다. expo react native용으로 간편한 에이전트 기반 E2E 테스트와 디버깅이 있으면 저한테 아주 유용할 것 같은데, 어떻게 연락하는 게 가장 좋을까요?
(엔지니어링 팀이 일상 영어로 테스트를 작성하고 거의 손 안 대고 유지보수하면서 품질을 직접 책임질 수 있게 해 준다는 말씀이요.)
그건 거의 똑같은 약속을 했던 Cucumber/Gherkin과 뭐가 다른가요? 그게 어떻게 끝났는지는 다들 알잖아요. 왜 이번에는 같은 아이디어를 구현한 게 다르게 될 거라고 보시나요?
(Mo는 지난 3년간의 Momentic와 복잡한 실제 애플리케이션에서 나온 수백만 건의 테스트 트레이스를 바탕으로 만든, 버그를 잡기 위한 커스텀 에이전트 하네스입니다. Mo는 재현율에 맞춰 만들어졌습니다. 가장 많은 진짜 버그를 찾지만, 정밀도는 Codex가 86% 대 84%로 조금 더 높습니다. 대신 비용이 트레이드오프인데, Mo는 버그당 $2.67이고 Codex는 $0.80이며 Claude Code와 Devin보다는 쌉니다.)
이거 좋은 건가요? 그러니까 Mo는 버그당 돈이 더 든다는 거잖아요? 헷갈리네요.
안녕하세요! Mo를 만드는 엔지니어 중 한 명인 Henry입니다. 숫자는 제대로 보셨는데, 저희가 내리는 결론은 조금 다릅니다.
저희가 보여 주려는 핵심은 Mo가 같은 시간에 차선 QA 에이전트보다 3배 넘는 진짜 버그를 찾는다는 점입니다. QA에서 최악은 진짜 버그를 놓친 채 깨진 코드를 프로덕션에 내보내는 일이기 때문에, 저희는 이 지표를 가장 중점적으로 최적화합니다. 지금은 그만큼 높은 재현율을 얻는 대신 비용이 더 드는 트레이드오프가 있습니다. 정밀도는 대체로 비슷하지만 근소하게 낮다고 말씀드리겠습니다.
물론 모든 수치에서 다른 에이전트를 앞서면 좋겠고 그렇게 되도록 적극적으로 작업하고 있지만, 지금은 이 도구가 어떤 수준인지 솔직하고 투명하게 보여 드린 것입니다.
자세한 내용은 전체 글을 참고해 주세요!
(QA에서 최악은 진짜 버그를 놓친 채 깨진 코드를 프로덕션에 내보내는 일이라는 말씀이요.)
도메인에 따라 다를 수도 있겠지만, 저는 "발견된 버그를 전부 고친다"는 게 사실상 불가능한 코드베이스에 익숙합니다. 사소한 버그 1000개를 찾는 건 도움이 안 돼요. 목표는 심각한 버그를 찾는 겁니다.
맞는 말씀이고, 이 벤치마크를 만들면서 저희도 느낀 점입니다. 앱의 버그를 하나도 빠짐없이 주석으로 달아 두는 건 불가능하진 않더라도 극도로 어렵습니다. 저희가 심각도 가중 점수로 담아내려던 것도 바로 이 부분입니다. 에이전트가 사소한 UI 흠을 잔뜩 찾을 때보다 정말 심각한 버그를 찾았을 때 훨씬 더 높은 점수를 받아야 하니까요. 다만 벤치마크 v2를 내놓을 때 확실히 개선할 수 있는 부분입니다.
그 재현율 목표를 달성하는 게 얼마나 중요한지 분명히 밝히면 글이 좀 더 탄탄해질 것 같아요.
저도 검색 품질은 재현율이 좌우한다고 믿지만, 지표와 결과 사이의 연결이 더 명확할 수도 있었는데 그렇지 않았어요. 얼핏 보이는 것보다 훨씬 강한 세일즈 포인트를 갖고 계신 것 같습니다.
그나저나 팀 여러분 축하합니다! 정말 멋진 결과예요.
감사합니다! 맞는 피드백입니다. 글을 더 분명하게 고치겠습니다. 픽스처를 더 늘리고 Mo도 더 최적화한 v2 벤치마크도 곧 내놓을 수 있기를 바라고 있습니다.
이 문장은 너무 못 썼어요. 말하려던 건 자기네 제품이 재현율이 훨씬 높고, 정밀도는 약간 낮고, 비용은 Codex와 Claude Code 사이쯤이라는 거예요. 아래에 넣은 차트를 보면 알 수 있는데, 이렇게 헷갈리는 글이 아무도 못 알아챈 채로 어떻게 HN에 올라왔는지 모르겠네요.
그러게요. 결론이 그냥 Codex가 더 싸고 더 좋다는 거 아닌가요?
LLM이 자기 가정을 스스로 강화한다는 대목은 제가 계속 겪는 문제와 맞아떨어집니다. 같은 모델이 코드와 테스트를 같이 쓰면 테스트가 구현을 그대로 반영해서 구조상 당연히 통과해 버립니다. 더 좋은 모델보다 도움이 된 건 역할을 분리하는 것이었습니다. 예를 들면 코드가 나오기 전에 스펙이나 티켓을 보고 테스트를 쓰거나, 구현 프롬프트를 한 번도 보지 못한 리뷰어 패스를 두는 식입니다. Mo는 PR 설명이나 스펙을 입력으로 받나요, 아니면 실행 중인 앱만 탐색하나요?
안녕하세요! 네, 작업을 수행하는 모델과 검증하는 모델을 다르게 쓰는 건 저희도 겪어 본 문제입니다. 실제로 Mo 안에서도 이런 실패를 피하려고 의심스러운 버그를 찾는 모델과 그 결과를 확인하는 모델을 다르게 씁니다.
Mo는 스펙 없이도 돌아가지만 PR 리뷰 모드나 자유 탐색 모드를 지원합니다. 실행시키고 싶은 스펙이 있다면 에이전트에 넘겨 주셔도 됩니다.
(Momentic이 함께 작업하자고 초대했습니다)
로그인하면 이메일이 자동으로 Slack에 넘어가서 연락이 오는 모양인데, 어디에도 그런 설명이 있었던 기억이 없어요. Momentic 설정에 가서 확인해 보니 알림 섹션에는 Slack이 꺼져 있고요...
저는 공개용 이메일을 써서 상관없지만 다른 사람들은 그렇지 않을 수도 있어요.