AI가 버그를 많이 찾으면 앱은 안전할까요? Momentic QA Bench를 읽는 기준

핵심 요약 (TL;DR)

버그 목록이 길다고 검수가 끝난 것은 아닙니다. Momentic은 11월 2일 실행 중인 웹앱에서 AI 에이전트가 오류를 얼마나 찾는지 평가하는 QA Bench를 공개했습니다.[1] 눈여겨볼 것은 순위보다 질문입니다. 보고한 오류가 정말 오류인지, 이미 알려진 오류 가운데 무엇을 놓쳤는지 따로 봅니다. 개발자 없이 첫 MVP를 준비할 때도 이 두 질문은 남겨 두시면 좋겠습니다.

이번 평가는 무엇을 확인하나요?

공식 보고서는 Gitea, Metabase, Twenty, Saleor를 대상으로 정해진 영역과 시간 안에서 앱을 탐색하고 오류를 보고하는 방식을 설명합니다. 코드 작성 시험이 아니라 실행되는 제품을 사용하며 문제를 발견하는 평가입니다.[1][2]

같은 앱이라도 버튼이 눌리는지, 잘못된 결과가 나오는지, 저장 후 다시 열면 내용이 남는지는 서로 다른 질문입니다. 여러분의 첫 앱도 ‘전체를 테스트해 주세요’라는 말 대신, 사용자가 끝내야 할 행동 하나를 먼저 지정해 보세요. 이 글에서는 공개 보고서와 저장소를 대조했으며 평가를 직접 재실행하지 않았습니다.

순위보다 먼저 읽어야 할 조건은 무엇인가요?

Momentic은 자사 에이전트 Mo를 포함한 평가를 직접 설계하고 실행·채점했다고 명시합니다.[1] 외부 기관이 독립적으로 확정한 성적표가 아닙니다. 또 공개 저장소는 웹 접근 조건에 예외가 있었다고 밝힙니다.[2] 같은 설명을 받았다는 이유만으로 모든 실행 조건까지 완벽히 같았다고 단정할 수 없습니다.

문서 사이의 세부 차이도 있습니다. 보고서는 어느 기존 오류와도 맞지 않는 발견을 검토해 분류한다고 설명하지만, 저장소의 일반 채점 설명에는 미확인 항목을 별도로 두고 일부 지표에서 제외한다고 나옵니다.[1][2] 따라서 이 글에서는 숫자를 옮겨 단일 우승 도구를 권하지 않습니다. 결과표와 실제 채점 절차를 함께 읽는 편이 좋겠습니다.

발견한 오류와 놓친 오류는 어떻게 다를까요?

정밀도는 보고한 문제 가운데 맞는 것이 얼마나 되는지를, 재현율은 기준으로 삼은 알려진 문제 가운데 얼마나 찾았는지를 묻습니다.[1][2] 엉뚱한 문제를 적게 보고하는 도구도 중요한 오류를 놓칠 수 있고, 많은 문제를 찾는 도구도 사람이 다시 확인할 부담을 남길 수 있습니다.

기준 목록 자체가 앱의 모든 버그를 담았다는 뜻도 아닙니다. 보고서는 해당 버전에서 확인한 오류 목록이지 가능한 오류 전체가 아니라고 설명합니다.[1] 여러분의 앱에 ‘문제 없음’이라는 답이 나왔다면, 먼저 어디를 어떤 입력으로 살펴봤는지 확인해 보세요.

첫 MVP에는 어떤 요청을 남기면 좋을까요?

가령 간단한 할 일 앱이라면 이렇게 요청할 수 있습니다. “가짜 항목을 추가하고 수정한 뒤 새로고침해 확인해 주세요. 기대한 결과와 실제 결과, 재현 순서, 확인하지 못한 부분을 나누어 기록해 주세요. 배포와 외부 발송은 하지 마세요.” 이는 평가의 공식 프롬프트가 아닌 실습용 예시입니다.

오류를 고친 뒤에는 같은 입력과 순서로 다시 실행합니다. 수정된 코드만 읽지 말고 공개 주소에서도 항목을 추가하고 다시 여는 과정을 확인하세요. 첫 사용자에게도 같은 목적의 행동을 부탁하되 정답 동작을 미리 가르치지 않고, 멈춘 지점을 적어 두시면 좋겠습니다.

FAQ: 평가에서 앞선 도구로 바꾸면 검수도 끝나나요?

아닙니다. 평가 대상과 내 앱의 자료·권한·사용 흐름은 다를 수 있습니다. 도구 선택보다 시험 범위와 재현 기록을 먼저 정해 보세요.

FAQ: 비용 표는 그대로 내 프로젝트 예산인가요?

그렇게 보기는 어렵습니다. 저장소는 비용 집계에 E2B와 채점 비용이 포함되지 않는다고 설명합니다.[2] 이 글은 요금 비교가 아니며, 실제 사용 전에는 포함 항목과 필요한 실행 범위를 따로 확인해야 합니다.

출처
[1] https://momentic.ai/blog/qa-bench
[2] https://github.com/momentic-ai/qa-bench
관찰: 2026-11-03 KST