바이브코딩 시작하는 방법, ‘같은 기온인데 왜 더 덥지?’에서 앱을 찾아볼까요?

핵심 요약 (TL;DR)

첫 앱의 아이디어는 거창한 시장보다 자주 느끼는 불편에서 나올 때가 있습니다. 9월 27일 Hacker News에 제작 경험을 공개한 Wet Bulb Tracker의 출발점은 ‘익숙한 기온인데 예전보다 더 덥게 느껴진다’는 질문이었습니다. 제작자는 화면을 Figma에서 다듬고, 계산 모델의 Swift 구현에 Claude Code의 도움을 받았다고 설명합니다. 여기서는 이 제작 과정과 공개 제품 페이지를 살펴봅니다. 앱을 직접 실행하거나 계산의 정확성을 검증한 리뷰는 아닙니다.

날씨 앱을 하나 더 만드는 것과 무엇이 다를까요?

제작자가 집중한 것은 날씨 정보의 양이 아니라 숫자의 의미를 전달하는 방식이었습니다. 공개 글에는 색으로 구분한 단계, 시간대별 흐름, 알림을 통해 정보를 한눈에 이해시키려 했다는 설명이 나옵니다. 공식 페이지에서도 도시 검색과 시간대별 예보, 알림 기능을 소개합니다. 다만 최근 날짜는 제작 후기의 게시 시점이며, 앱이 그날 처음 출시됐다는 뜻은 아닙니다.

이 사례를 입문자의 관점으로 옮기면 질문이 달라집니다. ‘새로운 날씨 서비스를 만들까?’보다 ‘내가 이미 보는 정보 중 매번 해석하기 어려운 것은 무엇인가?’가 됩니다. 일정의 빈 시간, 매장의 재고 상태, 운동 기록의 변화도 출발점이 될 수 있습니다. 데이터를 더 모으기 전에 사용자가 어떤 판단에서 막히는지 적어 보는 것입니다.

AI에게 첫 화면은 어떻게 부탁하면 좋을까요?

실제 날씨나 건강 계산을 바로 붙이지 않고, 가상의 자료로 화면부터 만들어 보세요. 예를 들면 ‘샘플 시간대와 설명을 보여 주는 모바일 화면을 만들어 주세요. 선택한 시간의 설명이 바뀌고, 자료가 없을 때는 없다고 표시해 주세요. 실제 위험도는 계산하지 마세요’처럼 요청할 수 있습니다. 이 문장은 독자를 위한 연습 예시이지 제작자가 사용한 프롬프트는 아닙니다.

첫 화면에서는 색만으로 뜻을 전달하지 않는 편이 좋습니다. 색과 함께 짧은 상태 이름, 자료의 시각, 설명 문장을 두세요. 숫자가 없는 상황을 정상값처럼 보이지 않게 만드는 일도 중요합니다. 처음부터 계정과 알림까지 붙이지 않아도, 사람이 시간을 골라 정보를 이해하는 흐름은 검토할 수 있습니다.

계산은 AI가 만들었으니 믿어도 될까요?

제작자는 AI의 도움을 받은 범위를 계산 모델 구현으로 구체적으로 설명합니다. 이것이 공식의 타당성이나 모든 입력의 정확성을 증명하지는 않습니다. 습구온도와 습구흑구온도 지수인 WBGT도 같은 이름으로 뭉뚱그려 다루면 안 됩니다. 전문 지표를 제품에 넣는 순간에는 원문 정의와 단위, 적용 조건을 별도로 확인해야 합니다.

공식 제품 페이지 역시 인식과 계획을 돕는 용도이며, 정부의 기상 경보·작업장 안전 지침·의료 조언을 대신하지 않는다고 밝힙니다. 첫 프로젝트라면 건강 판단처럼 오차의 대가가 큰 영역보다 가상의 자료를 읽기 쉽게 보여 주는 연습부터 시작하세요. AI가 구현할 수 있다는 사실과 내가 책임 있게 제공할 수 있다는 판단은 다릅니다.

FAQ: 앱 전체를 AI가 만들었다는 사례인가요?

그렇게 단정할 수 없습니다. 원문은 제작자가 화면을 반복해 설계했고 계산 구현에서 AI 도움을 받았다고 설명합니다. 사람의 설계와 AI의 구현 지원을 구분해서 읽는 편이 정확합니다.

FAQ: 직접 만든 연습 화면은 언제 배포하면 좋을까요?

가상 자료라는 표시를 남긴 뒤 공개 주소에서 휴대폰으로 열어 보세요. 시간 선택과 빈 자료 표시가 작동하는지 확인하고, 다른 사람이 설명을 이해하는지 관찰하면 됩니다. 실제 건강 알림 서비스의 공개와는 별개의 연습입니다.

제작 후기: https://news.ycombinator.com/item?id=49863884
제품 설명·주의사항: https://tulkitdesign.com/wet-bulb-temperature-alerts-tracker/
관찰 시점: 2026-09-28 KST