AI로 웹사이트 만들기, Weather Ribbon은 왜 실시간 연결을 줄였을까요?

핵심 요약 (TL;DR)

Weather Ribbon 제작자는 광고가 많은 연간 날씨 시각화 사이트가 불편해 직접 공개 웹사이트를 만들었다고 소개했습니다. Agent Duel을 사용해 바이브코딩으로 제작했다는 설명입니다.[1] 이 사례에서 눈여겨볼 것은 개발 속도가 아니라, 미리 준비한 데이터를 정적 차트로 보여주는 선택입니다. 첫 MVP가 꼭 실시간 연결부터 시작할 필요는 없습니다.

어떤 불편이 첫 화면으로 이어졌을까요?

제작자의 Hacker News 소개는 한국 시간 10월 9일 오전 6시 46분에 게시됐습니다. 확인된 것은 이 소개 시점이며, 사이트가 그때 처음 만들어졌다는 뜻은 아닙니다.[1] 제작자는 즐겨 보던 날씨 시각화 사이트에 광고가 많아 자신의 버전을 만들고 소스를 공개했다고 말합니다.

공개 홈페이지에는 도시 목록이 있고, 저장소는 도시별 기온·강수·일조 시간 등을 SVG 차트로 보여주는 구조를 설명합니다.[2][3] ‘한 도시의 계절을 한눈에 보고 싶다’는 작은 목적이 먼저 보입니다. 다만 제작자의 개발 경력이나 제작 기간은 확인하지 않았으므로, 코딩을 처음 하는 사람도 같은 속도로 완성할 수 있다고 약속할 수는 없습니다.

데이터 화면인데 왜 실시간 API가 필요하지 않을까요?

README는 데이터를 미리 받아 저장소에 보관하고, 화면에서는 실행 중 API를 호출하지 않는 정적 사이트라고 설명합니다. 기후 자료와 대기질 자료의 출처도 나누어 적어 두었습니다.[2]

매 순간 값이 바뀔 필요가 없다면, 검증한 자료 묶음으로 화면부터 만들 수 있습니다. 다만 정적이라는 말이 최신성이나 정확성을 보장하지는 않습니다. 특히 최근 대기질과 장기간의 기후 평균은 같은 종류의 수치가 아니므로, 자료 기간과 갱신 기준을 구분해 보여 줄 필요가 있습니다.

내 첫 MVP에는 어떤 프롬프트가 어울릴까요?

처음부터 세계 모든 도시를 넣기보다, 직접 확인한 도시 하나와 자료 몇 항목을 정해 보세요. 예를 들어 이렇게 시작할 수 있습니다.

“제공한 샘플 데이터로 한 도시의 월별 기온을 보여 주세요. 데이터의 단위와 기준 기간을 표시하고, 값이 없는 달은 빈칸의 이유를 안내해 주세요. 로그인과 실시간 수집은 넣지 마세요.”

이 문장은 원작 제작자가 사용한 프롬프트가 아니라 입문 실습을 위한 제안입니다. 생성된 차트를 본 뒤에는 원본의 특정 달과 화면 값을 대조하고, 자료가 비었을 때와 휴대폰의 좁은 화면에서도 뜻이 유지되는지 확인해 보시면 좋겠습니다.

차트가 보이면 검증은 끝난 걸까요?

차트가 렌더링되는 것과 자료가 올바르게 해석되는 것은 다른 문제입니다. 단위가 바뀌거나 오래된 자료에 오늘 날짜를 붙이면, 화면은 멀쩡해도 독자는 다른 정보를 받게 됩니다. 출처와 수집 날짜, 자료가 나타내는 기간을 별도로 남겨 두시길 권합니다.

Weather Ribbon 저장소에는 데이터 검증과 빌드 명령이 안내돼 있습니다.[2] 이 글에서는 공개 페이지와 README를 확인했지만 해당 명령을 실행하거나 기후 수치를 재계산하지는 않았습니다. 독자가 직접 만드는 실습에서도 ‘코드가 실행됨’과 ‘원본과 값이 일치함’을 구분해 기록하는 편이 좋습니다.

FAQ: AI로 만든 사이트라는 근거는 무엇인가요?

제작자 소개에 Agent Duel을 사용한 바이브코딩이라고 명시돼 있고, 저장소 README에도 같은 도구로 제작했다고 적혀 있습니다.[1][2] 이는 제작자 자기보고이며 전체 개발 세션을 검증한 것은 아닙니다.

FAQ: 정적 사이트로 시작하면 나중에 확장하기 어렵나요?

이 사례만으로 확장성을 단정할 수는 없습니다. 먼저 필요한 정보와 검수 기준을 정하고, 갱신이 정말 필요한 부분이 생겼을 때 연결 범위를 늘리는 접근을 제안드립니다.

출처
[1] https://news.ycombinator.com/item?id=50012818
[2] https://github.com/micjm/WeatherRibbon
[3] https://weatherribbon.com/