Momentic Mo: 앱을 직접 써 보며 버그를 찾는 AI QA 에이전트

Launch HN: Momentic (YC W24) – Agents that catch bugs by using your app

Nov 2, 2026•wuweiweiwu•View Original

TL;DR Highlight

프롬프트로 앱을 탐색해 버그를 찾는 Mo, QA Bench에서 라벨 버그 약 269개 발견

Who Should Read

코딩 에이전트로 빠르게 배포하면서 E2E 테스트 작성·유지가 부담스러운 웹·모바일 개발자

Core Mechanics

Mo는 프롬프트만 주면 앱을 돌아다닌다
- Mo는 프롬프트로 앱 전체를 탐색하는 AI QA 엔지니어다.
- 결과로 발견 버그, 녹화, 재현 단계를 검토할 수 있다.
QA Bench에서 Mo가 압도적으로 많이 찾았다
- Gitea, Metabase, Twenty, Saleor의 20개 영역을 영역당 60분씩 돌렸다.
- Mo는 라벨된 버그 약 269개, 다음으로 좋은 에이전트는 약 86개를 찾았다.
- 비교 대상은 Codex, Claude Code, Devin이다.
재현 확인하는 별도 에이전트가 있다
- 별도 에이전트가 기능 버그를 재현해 본 뒤에야 Mo가 보고한다.
테스트는 YAML로 저장돼 리포지토리에 남는다
- 단계와 assertion(기대 결과 확인)을 평문 영어 YAML로 쓴다.
- CLI 종료 코드를 CI의 필수 체크로 쓸 수 있다.
UI가 바뀌어도 테스트를 고쳐 준다
- 실행 중에 컨트롤을 다시 찾는 auto-heal이 있다.
- 영구 수정은 테스트 파일 diff를 제안하고 사람이 검토한다.
코딩 에이전트와 MCP로 붙는다
- MCP 서버로 코딩 에이전트에서 테스트를 작성·실행·디버그할 수 있다.
- 변경 흐름을 라이브 세션에서 확인하고 YAML로 저장한다.

Community Reactions

정밀도는 Codex가 더 높고 비용도 낮다는 지적
- 원문 인용 기준 Mo는 정밀도 84%, Codex는 86%라는 점이 언급됐다.
- 버그당 비용은 Mo $2.67, Codex $0.80이라 헷갈린다는 댓글이 여럿이었다.
직접 만든 하네스로 충분하다는 의견
- Claude에 스킬이나 Playwright 하네스를 붙이면 더 낫다는 사용 경험이 있었다.
- 몇 달 뒤 새 모델이 커스텀 하네스의 강점을 흡수할 것이라는 우려도 있었다.
클라우드 의존과 토큰 과금에 대한 반감
- 클라우드 의존이라 느리고 구독 대비 비싸다는 경험이 있었다.
- 오픈소스, 셀프호스팅, BYOA(자기 구독 사용)를 기본으로 원한다는 의견이 있었다.
통과 오탐이 정밀도·재현율보다 중요하다는 의견
- 깨진 흐름을 통과로 판정하는 경우가 더 위험하다는 의견이 있었다.
- 일부러 버그를 심어 놓치는 비율을 재고, '판단 불가'라는 제3의 답을 허용하니 거짓 통과가 줄었다는 경험이 있었다.
사용성 문제 보고
- 온보딩이 없어 인증 설정에서 막혔다는 경험이 있었다.
- iOS 앱이 호스팅 시뮬레이터와 호환되지 않는다는 오류를 겪었다는 경험이 있었다.

How to Apply

지금 쓰는 에이전트로 간이 QA 돌려 보기
- 오늘 변경한 기능 하나를 골라 코딩 에이전트에 아래 프롬프트를 붙여 넣어라.
- 발견 버그와 재현 단계를 보고 기존 테스트가 놓친 것이 있는지 비교하라.
핵심 흐름을 YAML 평문 테스트로 옮기기
- 로그인·결제 같은 핵심 흐름을 act와 assert 단계로 적어라.
- Momentic을 쓴다면 파일을 리포지토리에 커밋해 코드 리뷰 대상으로 삼아라.
CLI 종료 코드를 CI 필수 체크에 걸기
- PR마다 E2E를 돌리고 실패 시 머지를 막도록 CI 잡에 CLI를 추가하라.
- 실패는 앱 버그, 테스트 불안정, 환경 문제로 분류해 대응하라.
평가 시 비용과 정밀도를 함께 보기
- 도구를 고를 때 발견 수만 보지 말고 버그당 비용과 정밀도도 비교하라.
- 변경 기능 하나만 검증하는 루프라면 탐색 폭보다 비용이 중요한지 따져라.

Try It

복사해서 바로 해보기

# Claude Code 또는 ChatGPT에 붙여넣기 (Mo 방식의 간이 버전: 탐색 후 별도 재현 검증)

당신은 QA 엔지니어다. 아래 앱을 사용자처럼 탐색해 버그를 찾아라.
앱 주소: {{URL}}
테스트할 기능: {{기능 설명}}
기대 동작: {{기대 동작}}

단계:
1. 화면과 사용자 흐름을 탐색하며 의심스러운 동작을 목록으로 적어라.
2. 각 후보를 처음부터 다시 재현해 보고 재현된 것만 '확정 버그'로 분류하라.
3. 재현 안 된 것은 '판단 불가'로 따로 적어라. 추측해서 통과나 버그로 판정하지 마라.

출력: 확정 버그마다 제목, 재현 단계, 기대 결과, 실제 결과, 심각도.

이어서 해 볼 것: 확정 버그 하나를 Playwright 테스트로 만들어 CI에 추가해 보라.

Terminology

E2E 테스트사용자가 앱을 쓰는 처음부터 끝까지 흐름을 실제 화면에서 따라 해 보는 테스트다. 가게에서 직접 물건을 사 보며 점검하는 것과 같다.

Auto-healUI가 바뀌어 버튼 위치나 이름이 달라져도 테스트가 컨트롤을 다시 찾아 계속 진행하는 기능이다. 이사 간 친구 집을 내비가 다시 찾아 주는 것과 비슷하다.

Recall(재현율)과 Precision(정밀도)재현율은 실제 버그 중 찾아낸 비율, 정밀도는 보고한 것 중 진짜 버그인 비율이다. 그물을 넓게 칠수록 많이 잡히지만 잡동사니도 섞인다.

MCP코딩 에이전트가 외부 도구를 호출하게 해 주는 표준 연결 규격이다. 에이전트용 USB 포트로 보면 된다.

Flaky test코드 변경이 없는데도 어떤 때는 통과하고 어떤 때는 실패하는 불안정한 테스트다.

Related Resources

Momentic Mo: 앱을 직접 써 보며 버그를 찾는 AI QA 에이전트

Launch HN: Momentic (YC W24) – Agents that catch bugs by using your app

Nov 2, 2026•wuweiweiwu•View Original

TL;DR Highlight

프롬프트로 앱을 탐색해 버그를 찾는 Mo, QA Bench에서 라벨 버그 약 269개 발견

Who Should Read

코딩 에이전트로 빠르게 배포하면서 E2E 테스트 작성·유지가 부담스러운 웹·모바일 개발자

Core Mechanics

Mo는 프롬프트만 주면 앱을 돌아다닌다
- Mo는 프롬프트로 앱 전체를 탐색하는 AI QA 엔지니어다.
- 결과로 발견 버그, 녹화, 재현 단계를 검토할 수 있다.
QA Bench에서 Mo가 압도적으로 많이 찾았다
- Gitea, Metabase, Twenty, Saleor의 20개 영역을 영역당 60분씩 돌렸다.
- Mo는 라벨된 버그 약 269개, 다음으로 좋은 에이전트는 약 86개를 찾았다.
- 비교 대상은 Codex, Claude Code, Devin이다.
재현 확인하는 별도 에이전트가 있다
- 별도 에이전트가 기능 버그를 재현해 본 뒤에야 Mo가 보고한다.
테스트는 YAML로 저장돼 리포지토리에 남는다
- 단계와 assertion(기대 결과 확인)을 평문 영어 YAML로 쓴다.
- CLI 종료 코드를 CI의 필수 체크로 쓸 수 있다.
UI가 바뀌어도 테스트를 고쳐 준다
- 실행 중에 컨트롤을 다시 찾는 auto-heal이 있다.
- 영구 수정은 테스트 파일 diff를 제안하고 사람이 검토한다.
코딩 에이전트와 MCP로 붙는다
- MCP 서버로 코딩 에이전트에서 테스트를 작성·실행·디버그할 수 있다.
- 변경 흐름을 라이브 세션에서 확인하고 YAML로 저장한다.

Community Reactions

정밀도는 Codex가 더 높고 비용도 낮다는 지적
- 원문 인용 기준 Mo는 정밀도 84%, Codex는 86%라는 점이 언급됐다.
- 버그당 비용은 Mo $2.67, Codex $0.80이라 헷갈린다는 댓글이 여럿이었다.
직접 만든 하네스로 충분하다는 의견
- Claude에 스킬이나 Playwright 하네스를 붙이면 더 낫다는 사용 경험이 있었다.
- 몇 달 뒤 새 모델이 커스텀 하네스의 강점을 흡수할 것이라는 우려도 있었다.
클라우드 의존과 토큰 과금에 대한 반감
- 클라우드 의존이라 느리고 구독 대비 비싸다는 경험이 있었다.
- 오픈소스, 셀프호스팅, BYOA(자기 구독 사용)를 기본으로 원한다는 의견이 있었다.
통과 오탐이 정밀도·재현율보다 중요하다는 의견
- 깨진 흐름을 통과로 판정하는 경우가 더 위험하다는 의견이 있었다.
- 일부러 버그를 심어 놓치는 비율을 재고, '판단 불가'라는 제3의 답을 허용하니 거짓 통과가 줄었다는 경험이 있었다.
사용성 문제 보고
- 온보딩이 없어 인증 설정에서 막혔다는 경험이 있었다.
- iOS 앱이 호스팅 시뮬레이터와 호환되지 않는다는 오류를 겪었다는 경험이 있었다.

How to Apply

지금 쓰는 에이전트로 간이 QA 돌려 보기
- 오늘 변경한 기능 하나를 골라 코딩 에이전트에 아래 프롬프트를 붙여 넣어라.
- 발견 버그와 재현 단계를 보고 기존 테스트가 놓친 것이 있는지 비교하라.
핵심 흐름을 YAML 평문 테스트로 옮기기
- 로그인·결제 같은 핵심 흐름을 act와 assert 단계로 적어라.
- Momentic을 쓴다면 파일을 리포지토리에 커밋해 코드 리뷰 대상으로 삼아라.
CLI 종료 코드를 CI 필수 체크에 걸기
- PR마다 E2E를 돌리고 실패 시 머지를 막도록 CI 잡에 CLI를 추가하라.
- 실패는 앱 버그, 테스트 불안정, 환경 문제로 분류해 대응하라.
평가 시 비용과 정밀도를 함께 보기
- 도구를 고를 때 발견 수만 보지 말고 버그당 비용과 정밀도도 비교하라.
- 변경 기능 하나만 검증하는 루프라면 탐색 폭보다 비용이 중요한지 따져라.

Try It

복사해서 바로 해보기

# Claude Code 또는 ChatGPT에 붙여넣기 (Mo 방식의 간이 버전: 탐색 후 별도 재현 검증)

당신은 QA 엔지니어다. 아래 앱을 사용자처럼 탐색해 버그를 찾아라.
앱 주소: {{URL}}
테스트할 기능: {{기능 설명}}
기대 동작: {{기대 동작}}

단계:
1. 화면과 사용자 흐름을 탐색하며 의심스러운 동작을 목록으로 적어라.
2. 각 후보를 처음부터 다시 재현해 보고 재현된 것만 '확정 버그'로 분류하라.
3. 재현 안 된 것은 '판단 불가'로 따로 적어라. 추측해서 통과나 버그로 판정하지 마라.

출력: 확정 버그마다 제목, 재현 단계, 기대 결과, 실제 결과, 심각도.

이어서 해 볼 것: 확정 버그 하나를 Playwright 테스트로 만들어 CI에 추가해 보라.

Terminology

E2E 테스트사용자가 앱을 쓰는 처음부터 끝까지 흐름을 실제 화면에서 따라 해 보는 테스트다. 가게에서 직접 물건을 사 보며 점검하는 것과 같다.

MCP코딩 에이전트가 외부 도구를 호출하게 해 주는 표준 연결 규격이다. 에이전트용 USB 포트로 보면 된다.

Flaky test코드 변경이 없는데도 어떤 때는 통과하고 어떤 때는 실패하는 불안정한 테스트다.

Momentic Mo: 앱을 직접 써 보며 버그를 찾는 AI QA 에이전트

TL;DR Highlight

Who Should Read

Core Mechanics

Community Reactions

How to Apply

Try It

Terminology

관련 논문

Related Resources

Momentic Mo: 앱을 직접 써 보며 버그를 찾는 AI QA 에이전트

TL;DR Highlight

Who Should Read

Core Mechanics

Community Reactions

How to Apply

Try It

Terminology

관련 논문

Related Resources