뒤로
G
geahoon ·

샘플 리포트를 본 분의 질문 하나로 판정 정확도를 다시 쟀어요

지난주에 가상 앱으로 돌린 샘플 리포트를 공개했는데, 스레드에서 한 분이 이렇게 물으셨어요. "고칠 것 67개랑 지금 할 일 12개는 우선순위가 다른 거야?"

화면 문구만 고치면 되는 질문이었는데, 들여다보니 더 큰 게 나왔어요. 파일 13개짜리 앱에 '출시를 막음' 이 48개였거든요. 이건 숫자 표시 문제가 아니라 판정 문제였어요.

정답을 아는 앱으로 채점부터

가상 앱을 두 개 만들었어요. 일부러 망가뜨린 v1, 출시 직전까지 거의 다 갖춘 v2. 제가 만든 거라 진짜 빈틈이 어디인지 알아요. 진단 결과를 그 정답에 맞춰 두 가지를 쟀어요.

  • 놓침: 진짜 위험 중 못 찾은 것 → 0개
  • 정확도: '출시를 막음' 이라고 한 것 중 진짜 → 17~38%

진짜 위험은 다 잡는데, 빨간불 열 개 중 예닐곱이 소음이었어요. 저장소에 백업 기록·계약서·런북이 없다는 걸 전부 '출시 불가' 로 셌더라고요. 그런 건 원래 저장소 밖에 두는 건데요.

해 본 것들

  1. 질문지 문장을 고쳤다 → 모델이 안 따랐어요. 같은 앱을 다시 돌리니 오히려 34개에서 38개로
  2. 2차 검증을 붙였다: '출시를 막음' 항목만 모아서 저장소를 다시 열어 보고 판정 → Sonnet 으로는 50~79%, 그런데 파일을 한 번도 안 열고 판단하다가 진짜 위험(마지막 자리 동시 결제)을 놓친 적이 있어요
  3. 검증만 Opus 로 → 파일을 33~44번 직접 열어 보고 86~100%, 놓침 0. 진단 1회에 $0.5, 2분 더

같은 앱을 세 번 돌렸을 때 원래는 34~40개로 흔들리던 게 검증 뒤엔 4~7개로 모였어요.

지금 샘플 리포트

'출시 전에 4개만 풀면 돼요' 로 바뀌었어요. 마지막 자리 동시 결제, 결제 응답을 통째로 로그에, 웹훅 순서가 뒤집히면 취소된 주문이 다시 결제됨으로, 로그인 메일이 테스트용 기본 메일. 넷 다 진짜예요.

질문 하나가 이번 주 일을 다 정했어요. 이상한 데 보이면 계속 물어봐 주세요 ㅎㅎ

vamuri

바이브코딩으로 만든 웹서비스가 출시 직전에 막히는 곳을 찾아 드립니다. 결제 연동, 소셜 로그인, 약관, 배포까지 저장소를 읽고 79개 항목으로 점검합니다. 지금은 무료 기간.

0

댓글

로그인 후 댓글을 남길 수 있습니다.

아직 댓글이 없습니다.