바이브코딩 할 일 앱, 첫 프롬프트보다 평가 목록이 중요한 이유

핵심 요약 (TL;DR)

바이브코딩으로 할 일 앱을 만들 때는 예쁜 화면보다 ‘어떤 일을 먼저 보여줘야 하는가’를 먼저 정하시는 편이 좋습니다. 3 & Done 제작자가 공개한 경험은 첫 생성보다 반복 검증이 중요하다는 사례입니다. 아래 프롬프트와 테스트 절차는 원문을 그대로 재현한 것이 아니라 초보자를 위한 실습 제안입니다.

3 & Done은 어떤 문제를 해결하려고 했나요?

제작자 dmayle은 2026년 10월 19일 22시 7분 KST에 Hacker News에서 제작 경험을 소개했습니다. Anthropic 모델의 도움으로 앱을 만들었으며, 한 번의 요청으로 완성한 제품은 아니라고 설명합니다. 할 일 목록에서 오늘의 세 가지와 그 이유를 고르는 기능을 위해 예상 결과가 있는 평가 목록을 보관하고, 프롬프트나 모델을 바꿀 때 다시 확인했다고 합니다.[1]

이는 제작자의 자기보고입니다. 공개 체험 페이지에서는 할 일을 입력하고 세 가지를 고르는 화면을 확인했지만, 추천의 정확도나 장기 사용 효과를 독립 검증한 것은 아닙니다.[2] 최근 공개된 제작기이지, 최근 이틀 동안 처음부터 개발했다는 뜻도 아닙니다.

첫 프롬프트는 어떻게 좁히면 좋을까요?

처음부터 로그인과 음성 입력, 자동 메일까지 붙이지 마세요. ‘가짜 할 일 다섯 개를 입력하면 오늘 할 세 개와 이유를 보여주는 웹 화면을 만들어 주세요. 저장과 외부 전송은 하지 말고, 아직 AI를 연결하지 않은 부분은 예시 결과라고 표시해 주세요’로 시작해 보시면 좋겠습니다.

이 단계의 완료 조건은 생성된 코드의 양이 아닙니다. 목록을 바꾸면 화면이 바뀌는지, 빈 입력을 설명하는지, 사용자가 선택을 수정할 수 있는지입니다. 버튼이 보이는 것과 목적에 맞게 작동하는 것을 구분하는 연습입니다.

추천이 틀렸을 때 무엇을 고쳐야 하나요?

‘추천을 더 똑똑하게 해 주세요’ 대신 실패한 입력과 기대한 결과를 함께 남겨 보세요. 예를 들어 내일 마감인 자료 정리가 빠지고 기한 없는 책장 정리가 선택됐다면, 마감 우선 규칙을 설명할 수 있습니다. 다만 모든 상황에서 마감만 우선하라고 단정하지 말고 사용자가 정한 중요도도 확인해야 합니다.

가상의 평일, 휴일, 마감이 겹치는 날을 각각 적어 두고, 규칙을 수정할 때 같은 입력을 다시 넣어 보세요. 한 사례를 고친 뒤 다른 사례가 망가졌는지 비교하는 것입니다. 결과가 예상과 다르면 AI의 오류뿐 아니라 내가 정한 기대 순서가 모호했는지도 살펴보시면 좋습니다.

배포 뒤 사용자에게 무엇을 물어야 하나요?

미리보기 주소를 공유하기 전에는 새 브라우저에서 입력부터 결과까지 직접 확인해 보세요. 실제 AI 연결은 그다음 단계로 두고, 비밀키를 화면 코드에 넣지 않도록 별도 검토를 요청하세요. 첫 사용자에게는 회사 업무나 개인정보 대신 가짜 목록을 주는 편이 안전합니다.

‘디자인이 괜찮나요?’보다 ‘이 세 가지를 고른 이유를 이해했나요?’, ‘바꾸고 싶은 항목은 무엇인가요?’를 물어보세요. 막힌 지점과 수정 전후 결과를 함께 기록하면 다음 프롬프트가 구체적인 개발 요청이 됩니다.

FAQ: 처음 만들 때 자주 묻는 질문은 무엇인가요?

처음부터 자동 이메일이 필요한가요?

이 실습에서는 필요하지 않습니다. 먼저 화면에서 선택과 수정이 되는지 확인하고, 메일은 발송 동의와 중복 발송 방지까지 검토할 수 있을 때 붙이세요.

평가 목록이 있으면 정답을 보장하나요?

아닙니다. 준비한 사례에서 변화를 비교하는 장치입니다. 실제 사용자가 다르게 판단한 사례를 반영하며 기대 결과도 고쳐 나가야 합니다.

어떤 원문을 확인했나요?

[1] 제작자 게시글과 답변: https://news.ycombinator.com/item?id=50151980

[2] 공개 체험 화면: https://3anddoneapp.com/try

원문과 화면 확인: 2026년 10월 21일 07시 02분 KST. 회원가입과 추천 실행은 하지 않았습니다.