AI로 웹사이트 만들기, YAVCHN은 왜 기사와 댓글을 한 화면에 놓았을까요?

핵심 요약 (TL;DR)

YAVCHN은 Hacker News와 Lobsters의 기사·토론을 함께 읽는 웹앱입니다. 제작자는 기사와 댓글 사이를 오가는 탭 이동이 번거로워 만들었다고 설명합니다.[2] 최근 소개된 이 바이브코딩 사례가 보여 주는 출발점은 거대한 새 서비스가 아니라, 이미 하는 행동에서 불편한 이동을 줄이는 일입니다. 첫 웹사이트도 기능 수보다 사용자가 끝내려는 행동으로 설명해 보시면 좋겠습니다.

무엇이 불편해서 다른 화면을 만들었을까요?

제작자 Paul Parks는 README에서 HN 토론을 새 탭으로 열고, 그 안에서 원문으로 이동한 뒤 다시 토론으로 돌아오는 과정을 이야기합니다. 원문을 대략 살펴보고 흥미로운 토론이 있는지 함께 확인하고 싶었다는 것입니다.[2] 그래서 기사 목록 옆의 읽기 창에 추출한 원문과 토론을 위아래로 배치했습니다.

Hacker News 소개 시각은 한국 시간 10월 5일 오후 9시 24분입니다.[1] 소개 제목과 공개 저장소는 바이브코딩으로 만든 리더임을 명시합니다.[1][2] 다만 이는 최근 커뮤니티에 소개된 시점이지 처음 개발하거나 출시한 날이라는 뜻은 아닙니다. 제작자가 코딩 경험이 없었다거나 AI가 전부 만들었다고 확인된 것도 아닙니다.

‘뉴스 사이트 만들기’ 대신 무엇을 요청하면 좋을까요?

‘뉴스 사이트를 만들어 주세요’라고 요청하면 로그인, 추천, 검색, 알림부터 떠올리기 쉽습니다. 반면 이 사례의 중심 질문은 짧습니다. ‘이 기사를 읽을 가치가 있는지, 토론과 함께 빠르게 판단할 수 있을까?’ 화면의 역할이 먼저 정해집니다.

여러분의 첫 시제품이라면 이렇게 범위를 좁혀 보세요. ‘예시 기사 세 개를 목록에 놓고, 선택하면 본문과 댓글을 같은 화면에 보여 주세요. 계정과 추천은 제외하고 원문으로 가는 링크를 남겨 주세요.’ 이는 YAVCHN의 실제 제작 프롬프트가 아니라, 사례에서 도출한 연습용 제안입니다. 먼저 직접 준비한 예시 자료로 흐름을 확인하면 외부 데이터 연결과 화면 설계를 나누어 생각할 수 있습니다.

한 화면에 모으면 언제나 편해질까요?

데스크톱에서 넓게 펼친 화면이 휴대전화에서도 편하리라고 단정할 수는 없습니다. 작은 화면에서는 기사와 댓글 중 무엇을 먼저 보여 줄지, 목록으로 돌아갈 때 읽던 위치를 어떻게 유지할지 따로 확인해 보세요. 이 글에서 모바일 사용성을 실측한 것은 아닙니다.

원문을 가져오지 못하는 경우도 첫 검수에 넣을 만합니다. 빈 화면을 성공처럼 남기기보다, 읽을 수 없다는 안내와 원문으로 이동할 방법을 제공하는 편이 낫습니다. YAVCHN의 README는 원문과 원래 토론으로 돌아가는 링크를 설명합니다.[2] 새 화면을 만드는 일이 원래 출처와 이용 맥락을 지우는 일이 되어서는 안 됩니다.

FAQ: 이 웹앱에서 HN 계정으로 로그인해야 하나요?

공개 사이트는 HN·Lobsters 로그인 정보를 받지 않으며, 투표나 답글은 원래 사이트에서 하도록 안내합니다.[3] 읽기 경험을 개선하는 기능과 원본 서비스의 계정 기능을 분리한 것입니다. 여러분도 첫 MVP에서 꼭 필요한 계정인지 먼저 물어보세요.

FAQ: 그대로 따라 만들면 하루 만에 끝낼 수 있나요?

그런 일정은 확인되지 않았습니다. README의 에이전트 코딩에 대한 표현을 누구에게나 적용되는 제작 시간으로 바꾸면 안 됩니다.[2] 여기서는 사이트를 직접 제작·배포한 실습이 아니라 공개 사례를 살펴봤습니다. 첫 목표는 같은 속도가 아니라, 한 기사를 골라 읽고 원문으로 돌아오는 흐름을 스스로 확인할 수 있는 상태로 잡으시면 좋겠습니다.

출처
[1] https://news.ycombinator.com/item?id=49963936
[2] https://github.com/paulmooreparks/yavchn
[3] https://yavchn.com/hn/