AI로 만든 MVP, Wonderhop의 첫 이용자들은 어떤 오류를 찾아냈을까요?

핵심 요약 (TL;DR)

작동하는 앱을 공개한 뒤에는 만든 사람이 예상하지 못한 사용법이 나타납니다. 한국 시간 10월 14일 HN에 소개된 브라우저 게임 Wonderhop에서는 모드 전환의 혼란, 지나치게 친절한 AI 판정, 휴대폰 입력 오류가 이용자 댓글로 드러났습니다.[1] 첫 MVP를 검증할 때는 칭찬의 양보다 사용자가 멈춘 순간을 기록하는 편이 유용합니다.

제작자가 맡긴 일과 직접 정한 일은 무엇인가요?

Wonderhop은 질문에 직접 답을 입력하는 게임입니다. 모드에 따라 사람들이 많이 할 답이나 드문 답 등을 찾습니다. 제작팀은 코드의 상당 부분을 AI 도구로 작성했지만, 콘셉트와 미술 방향, 디자인 선택은 사람이 맡았다고 설명합니다.[1]

제작자는 개발자들이라고 자신들을 소개했습니다. 따라서 이 사례를 ‘개발 경험 없이 완성한 앱’으로 바꾸어 말해서는 안 됩니다. 개발자 없이 MVP를 시작하려는 분에게도 참고할 지점은 있습니다. 코드를 누가 썼는지보다, 공개 후 어떤 질문으로 피드백을 받고 무엇을 사람이 판단했는지를 보는 것입니다.

이용자들은 서로 다른 세 가지 문제를 어떻게 드러냈나요?

한 이용자는 다시 플레이하는 듯한 버튼을 눌렀다가 모드가 달라졌다는 것을 뒤늦게 알았다고 썼습니다. 현재 목표를 입력란 가까이에 안내해 달라는 제안도 남겼습니다.[1] 이는 코드 오류를 보고한 것과 다릅니다. 기능은 진행되지만 사용자가 규칙을 잘못 이해하는 문제입니다.

다른 이용자는 도시 이름 대신 도시를 묘사하는 말을 넣었는데, AI가 실제 도시명으로 바꾸어 답을 인정했다고 보고했습니다. 제작자는 문제를 인정하고 수정하겠다고 답했습니다.[1] 답을 유연하게 이해하는 능력이 게임의 도전 조건과 충돌할 수 있음을 보여 줍니다. 다만 이 댓글만으로 모든 판정이 잘못됐다고 결론 내릴 수는 없습니다.

또 다른 이용자는 iOS Safari에서 오답 뒤 다시 입력하려 할 때 키보드가 입력란을 가린다고 신고했습니다. 제작자는 수정됐을 것이라며 재확인을 부탁했습니다.[2] 이 글에서는 해당 기기에서 재현하거나 수정 후 동작을 다시 시험하지 않았습니다. 수정 답변과 검증 완료는 다르게 읽어야 합니다.

내 MVP에서는 피드백을 어떻게 수정 요청으로 바꿀까요?

예약 문의 앱이라면 ‘어떤 버튼을 눌러야 할지 모르겠다’, ‘조건에 맞지 않는 입력이 통과한다’, ‘휴대폰에서 입력란이 가려진다’를 다른 문제로 적어 보세요. 각각 안내 문구, 판정 규칙, 화면 배치의 수정으로 이어질 수 있습니다. 이는 사례에서 도출한 실습 제안입니다.

AI에게는 감상만 전달하지 말고 사용 기기, 입력 순서, 기대한 결과와 실제 결과를 함께 주세요. 수정 뒤에는 같은 순서를 다시 밟고, 원래 정상적으로 되던 입력도 확인하세요. 실패 장면을 남기면 다음 버전에서도 같은 문제가 돌아오지 않았는지 비교할 기준이 됩니다.

공개 피드백의 목적을 ‘좋다는 말을 듣기’보다 ‘설명 없이 끝까지 사용할 수 있는지 보기’로 정해 보세요.

FAQ: 이용자 댓글이 있으면 고객 검증이 끝난 건가요?

아닙니다. 여기서 확인한 것은 공개 이용자의 경험담입니다. 유료 고객이나 반복 이용, 매출을 검증한 자료는 아닙니다. 사용성 피드백과 사업의 수요 검증을 같은 성과로 묶지 마세요.

FAQ: AI가 고쳤다고 하면 바로 배포해도 되나요?

수정됐다는 설명만으로 통과시키지 않는 편이 좋습니다. 신고된 기기와 입력 순서에서 문제를 다시 확인하고, 결과와 남은 제약을 기록하세요. 이번 제작자의 답변 역시 독립적인 재검증 결과로 소개하지 않았습니다.

출처
[1] https://news.ycombinator.com/item?id=50080246
[2] https://news.ycombinator.com/item?id=50106387
서비스: https://wonderhop.io/en/
관찰: 2026-10-16 KST. 소개 날짜는 HN 게시 시각 기준입니다.