Claude Code로 만든 읽기 목록 웹앱, 초보자는 무엇을 따라 해볼까요?

핵심 요약 (TL;DR)

RDLTR은 쌓인 읽을거리 탭을 줄이려고 만든 웹앱입니다. 제작자는 Claude Code가 코드 대부분을 작성했지만, 직접 사용하고 테스트하며 화면을 다듬는 데도 많은 시간을 썼다고 밝혔습니다.[1] 초보자가 가져올 교훈은 같은 서비스를 복제하는 일이 아니라, ‘저장하고 읽으면 목록이 줄어든다’는 행동을 화면과 데이터로 연결하는 연습입니다.

AI로 만든 웹사이트에서 무엇을 배울 수 있나요?

한국 시간 9월 10일 오전 2시 6분 21초, 제작자는 Hacker News에 RDLTR 제작기를 올렸습니다. 이는 API로 확인한 게시 시각이며, 사이트가 처음 배포된 시각은 아닙니다. 여러 기기와 브라우저에 읽을 탭이 쌓이는 불편이 출발점이었습니다. 기존 읽기 목록은 계속 커지기만 해서, 읽을수록 비워지는 경험을 원했다고 설명합니다.[1]

이 차이는 프롬프트에도 반영할 수 있습니다. “북마크 사이트를 만들어 주세요” 대신 “URL을 저장하면 미읽음 목록에 표시하고, 읽음 처리하면 그 목록에서 제외해 주세요. 새로고침해도 상태는 유지해 주세요”라고 요청하는 식입니다. 이 문장은 원작자의 실제 프롬프트가 아니라, 사례를 바탕으로 제안하는 학습용 예시입니다.

화면이 만들어진 다음에는 무엇을 확인해야 하나요?

제작자는 Bun, TypeScript, HTMX, SQLite를 사용하고, 변경 사항을 전달하는 SSE와 Hetzner VPS 배포를 소개했습니다.[1] 초보자가 이 구성을 그대로 따라야 하는 것은 아닙니다. 먼저 자신이 이해할 수 있는 환경에서 저장, 표시, 읽음 처리의 흐름을 완성하는 편이 좋습니다.

검증할 때는 버튼이 눌리는지만 보지 마세요. 같은 링크를 두 번 저장하면 어떻게 되는지, 빈 주소를 제출하면 설명이 나오는지, 읽음 처리 후 새로고침해도 결과가 유지되는지 확인해 보세요. 실패하면 AI에게 “안 됩니다”라고만 하지 말고, 입력값과 클릭 순서, 기대한 결과, 실제 결과를 함께 전달하세요. 이는 직접 재현한 RDLTR의 결함이 아니라, 비슷한 웹앱을 만들 때 사용할 점검 제안입니다.

배포 후 피드백은 어떻게 수정 요청으로 바꾸나요?

HN 댓글에는 무한 스크롤 때문에 하단 메뉴에 있는 도움말을 볼 수 없다는 지적이 있었습니다.[1] 기능이 존재하는 것과 사용자가 그 기능을 찾는 것은 다르다는 좋은 사례입니다. 다만 댓글의 보고이지, 이번 조사에서 직접 재현한 현상은 아닙니다.

자신의 사이트에서 같은 문제가 확인된다면 “도움말을 항상 접근 가능한 상단 메뉴로 옮기고, 좁은 화면에서도 가리지 않게 해 주세요”라고 요청할 수 있습니다. 수정 뒤에는 실제 배포 주소에서 긴 목록을 내려 보고 도움말에 도달하는지 다시 확인하세요. 로컬 화면만 확인하고 끝내지 않는 것이 중요합니다.

자주 묻는 질문은 무엇인가요?

AI가 대부분 작성했다면 사람은 무엇을 했나요?

제작자는 직접 사용하며 테스트하고 UI를 다듬었다고 명시했습니다.[1] 따라서 ‘AI가 알아서 완성했다’는 사례로 읽기보다, 생성된 결과를 생활 속에서 반복해서 고친 사례로 보는 편이 정확합니다.

읽은 링크는 누구나 계속 보관할 수 있나요?

공식 도움말은 영구 보관과 비공개 페이지를 Plus 기능으로 안내합니다.[2] 소개 글의 큰 그림만 보고 모든 계정의 동작이 같다고 생각하면 안 됩니다. 자신의 연습 앱도 읽음 처리와 삭제, 보관을 구분해 설명해 두세요.

이 글은 직접 만들어 본 후기인가요?

아닙니다. 제작자의 원문과 공개 페이지를 확인한 사례 분석입니다. 로그인하거나 앱을 배포해 보지는 않았습니다. 제안한 프롬프트와 점검 순서는 독자가 자기 프로젝트에 적용할 연습안입니다.

관찰 시점: 2026-09-11 KST

Sources

[1] https://news.ycombinator.com/item?id=49629747
[2] https://rdltr.app/help