바이브코딩 시작하는 방법: 읽기 목록 앱에서 배울 첫 프롬프트

핵심 요약 (TL;DR)

첫 바이브코딩 소재가 떠오르지 않는다면, 매일 쌓이는 ‘나중에 읽을 링크’부터 살펴보셔도 좋습니다. 9월 9일 Show HN에 소개된 RDLTR의 제작자는 여러 기기에 흩어진 읽을거리를 정리하려고 앱을 만들었으며, 코드 대부분을 Claude Code가 작성했다고 밝혔습니다. 다만 직접 사용하고 시험하며 화면을 다듬는 데에도 많은 시간을 썼다고 덧붙였습니다.[1] 이 사례의 출발점은 거대한 서비스가 아니라, 읽지 않은 목록을 비우고 싶은 개인의 불편이었습니다.

저장보다 ‘읽고 나서’가 중요한 이유는 무엇일까요?

제작자가 설명한 핵심은 링크를 열어 읽으면 대기 목록에서는 빠지고 보관함에는 남는 방식입니다. 수집량보다 읽기를 끝내는 경험을 중심에 둔 셈입니다.[1] 이 차이는 작은 앱을 기획할 때 좋은 질문이 됩니다. 사용자가 무엇을 추가하는지만 보지 말고, 어떤 순간에 일을 끝냈다고 느끼는지도 정해 보세요.

가령 문의 접수 앱이라면 제출 폼만이 아니라 ‘답변을 마친 문의’의 자리가 필요합니다. 장보기 앱이라면 품목 추가보다 구매한 항목을 치우는 행동이 중요할 수 있습니다. 여기서부터는 RDLTR의 기능 설명이 아니라, 사례를 내 첫 프로젝트에 적용하는 설계 제안입니다.

첫 프롬프트는 어떻게 써 볼 수 있을까요?

다음처럼 범위를 좁혀 보세요. “개인용 읽기 목록 웹페이지를 만들어 주세요. 링크와 제목을 저장하고, 읽음 버튼을 누르면 대기 목록에서 보관함으로 옮겨 주세요. 로그인과 AI 요약은 제외합니다. 빈 목록 안내와 잘못된 주소 오류를 만들고, 저장 위치와 데이터가 지워지는 조건도 설명해 주세요.”

중요한 것은 실제 RDLTR을 복제하는 일이 아닙니다. 입력, 상태 변경, 다시 찾기라는 흐름을 내가 이해할 수 있는 크기로 만드는 것입니다. 첫 화면이 나오면 링크를 넣고 읽음 처리한 뒤, 새로고침해도 의도한 상태가 유지되는지 확인하세요. 보관함에서 다시 대기 목록으로 돌려놓는 행동도 함께 시험하면 좋습니다.

어느 시점에 기능을 더해야 할까요?

제작자 소개에는 브라우저 확장, 공유 경로, 요약 등 여러 기능이 등장하지만, 앱은 몇 달 동안 작업한 결과물입니다. 최근 소개됐다는 사실을 ‘하루 만에 만든 앱’으로 읽으면 안 됩니다.[1] 초보자가 그 기능 목록을 첫 프롬프트에 모두 넣을 이유도 없습니다.

먼저 본인의 링크로 며칠 써 보세요. 저장이 귀찮은지, 읽음 처리가 어색한지, 예전 링크를 못 찾는지 적습니다. 그다음 가장 자주 막힌 행동 하나만 고치세요. AI가 만든 화면을 매번 새로 꾸미는 대신, 실제로 불편했던 장면을 다음 수정의 근거로 쓰는 편이 낫습니다.

공개 배포 전에는 개인 링크가 다른 방문자에게 보이지 않는지 별도로 확인해야 합니다. 특히 인증이 필요한 주소나 고객 문서는 테스트 재료로 넣지 마세요. 개인용 실습이 곧 여러 사람이 안전하게 쓰는 서비스는 아닙니다.

FAQ: 이 사례는 비개발자도 같은 결과를 낸다는 증거인가요?

아닙니다. AI 작성 비중과 개발 과정은 제작자의 자기보고입니다. 독자의 숙련도나 작업 시간까지 보장하지 않습니다. 이 글에서도 제품 내부 동작이나 제작 시간을 직접 재현하지 않았습니다.

FAQ: AI 요약부터 붙이는 편이 더 좋지 않을까요?

읽기 목록의 기본 흐름을 먼저 확인하는 편을 권합니다. 요약을 추가하면 외부 전송 범위와 호출 비용, 요약이 원문을 잘못 전달하는 경우까지 검토해야 합니다. 작은 실습의 첫 질문은 ‘얼마나 똑똑한가’보다 ‘내가 끝까지 쓰는가’입니다.

Sources

[1] https://news.ycombinator.com/item?id=49629747