바이브코딩 시작하는 방법, Quaesito처럼 친구들의 퀴즈 한 판부터 만들까요?

핵심 요약 (TL;DR)

친구들과 퀴즈를 즐기는 앱 Quaesito의 제작자는 Claude Code와 반복적으로 대화하며 프로젝트 전체를 바이브코딩했다고 밝혔습니다.[3] 이 사례의 출발점은 거창한 서비스가 아니라, 슬라이드나 PDF보다 재미있게 퀴즈 모임을 진행하고 싶다는 구체적인 바람입니다. 첫 MVP를 준비한다면 기능의 개수보다 ‘누가 어떤 화면에서 무엇을 하는가’를 먼저 정해 보세요.

친구들의 퀴즈 모임은 어떻게 앱이 되었을까요?

Quaesito는 진행자의 노트북에서 실행하고, 화면을 TV로 공유하며, 참가자는 같은 로컬 네트워크에 연결된 휴대폰으로 답하는 구조입니다. 제작자는 다양한 질문 형식과 멀티미디어를 원했지만, 첫 릴리스의 범위를 감당할 수 있는 수준으로 유지하려 했다고 설명합니다.[3]

한국 시간 2026년 10월 11일 오후 10시 52분에 Show HN에 올라온 소개 글입니다. 이 시각은 제품의 최초 출시일을 뜻하지 않습니다.[3] 이 글은 제작자의 설명과 공개 저장소를 읽은 사례 소개이며, 앱을 설치해 실제 퀴즈 모임을 진행한 후기는 아닙니다.

첫 MVP에서는 어느 화면부터 만들면 좋을까요?

공개 저장소는 브라우저에서 퀴즈를 만들고, 큰 화면을 보여 주며, 참가자가 QR 코드로 들어와 답하는 흐름을 설명합니다. 실제 행사 전에 가상의 휴대폰으로 시험하는 기능도 안내합니다.[4] 화면을 만드는 일과 여러 사람이 함께 쓰는 상황을 확인하는 일이 구분되어 있는 셈입니다.

여러분이 처음 만든다면 모든 질문 유형을 한꺼번에 구현하기보다, 진행자가 문제를 열고 참가자가 답한 뒤 결과가 보이는 한 흐름부터 요청해 보세요. 예를 들어 ‘진행자 화면과 참가자 화면을 나눠 주세요. 객관식 문제 하나를 열고 답을 제출하면 결과를 확인할 수 있게 해 주세요’라고 시작할 수 있습니다. 이는 원작의 개발 프롬프트가 아니라 초보 실습을 위한 제안입니다.

AI가 전부 만들었다면 확인할 일도 줄어들까요?

저장소에는 AI 도우미 Claude가 코드·테스트·문서를 작성했다는 안내와 함께, 보증 없이 제공된다는 고지가 있습니다.[4] 생성된 테스트가 있다는 사실만으로 여러분의 환경에서 행사가 문제없이 진행된다고 보장되지는 않습니다. 정답 처리, 제출 마감, 같은 답을 반복해서 누를 때의 처리는 직접 정한 기대 결과와 대조해 보세요.

특히 진행자와 참가자의 화면을 따로 확인하는 편이 좋습니다. 진행자가 다음 문제로 넘어갔는데 참가자의 화면이 이전 문제에 머무르는 상황, 연결이 끊겼다가 다시 들어오는 상황도 검수 목록으로 남겨 보세요. 이는 발견된 결함이 아니라 제안하는 확인 항목입니다.

같은 Wi-Fi에서 실행하면 무엇이 달라질까요?

제작자는 로컬 네트워크에서 작동하도록 신경 썼으며 제삼자 서비스로 요청을 보내지 않는다고 설명합니다.[3] 다만 이는 제작자 설명이고, 이번 조사에서 통신을 분석한 결과는 아닙니다. 로컬 실행이라는 구조와 실제 네트워크 동작을 직접 확인했다는 주장은 구분해야 합니다.

FAQ: Windows와 macOS에서도 검증된 앱인가요?

제작자는 Windows·macOS·Linux 지원을 설명하면서, 자신이 시험한 환경은 Linux뿐이라고 밝혔습니다.[3] 지원 목록과 실사용 검증 범위를 같은 말로 읽지 마세요. 모임에 쓸 기기에서 먼저 확인하는 편이 좋습니다.

FAQ: 초보자도 바로 같은 앱을 만들 수 있나요?

이 사례는 제작 기간이나 초보자의 성공을 보장하지 않습니다. 여러 질문 유형과 배포 기능을 그대로 따라가기보다, 아는 문제 하나로 참여부터 결과까지 이어지는 흐름을 완성해 보세요. AI에게 맡길 첫 범위와 사람이 확인할 완료 조건을 함께 적는 것이 시작점입니다.

Sources

[3] https://news.ycombinator.com/item?id=50043311
[4] https://github.com/ggirelli/quaesito