AI로 첫 웹앱 만들기, Koi.rest처럼 ‘잠깐 머물 곳’부터 만들어 볼까요?

핵심 요약 (TL;DR)

물고기를 바라보며 잠깐 쉬는 웹사이트도 첫 프로젝트가 될 수 있습니다. 9월 25일 한국 시간 새벽, 제작자 Paul은 Show HN에 Koi.rest를 소개했습니다. JavaScript를 모르고 당장 배울 여력도 없어 미뤄 두었던 가상 연못을 AI의 도움으로 만들었다는 이야기입니다. 개발 경험이 전혀 없는 사람의 사례는 아닙니다. 제작자는 자신을 개발자로 소개했고, 이번에 낯선 언어의 구현을 AI에 맡겼다고 설명합니다. 이 글의 날짜는 커뮤니티 소개일이며 최초 출시일을 뜻하지 않습니다.

왜 거창한 서비스 대신 연못이었을까요?

제작자의 출발점은 개인적인 필요였습니다. 발코니의 작은 정원을 만드는 일이 아직 끝나지 않은 상황에서, 누구나 들를 수 있는 가상의 공간을 떠올렸다고 합니다. 문제는 아이디어가 아니라 구현 방법을 몰라 시작을 미루고 있었다는 점이었습니다.

공개 사이트에 들어가면 연못과 물고기를 볼 수 있고, 소리와 타이머를 고르는 조작부가 있습니다. 실제 브라우저에서도 연못 화면과 해당 조작부를 확인했습니다. 다만 여러 방문자가 같은 상태를 공유하는지, 소리가 모든 환경에서 재생되는지까지 시험한 것은 아닙니다. 소개문이 내세우는 휴식 경험 역시 의료적 효과로 해석해서는 안 됩니다.

코드를 맡기면 사람에게는 무슨 일이 남을까요?

Paul은 자신이 조정하고, 더하고, 빼고, 그리고, 조사하고, 질문하고, 시험했다고 적었습니다. 직접 코드를 쓰지 않았을 뿐 제작에서 손을 뗀 것은 아니라는 설명입니다. 첫 앱 제작에서 기억할 구분입니다.

AI에게 구현을 맡길수록 사람은 “어떤 느낌이면 충분한가”를 구체적으로 판단해야 합니다. 조용히 쉬고 싶은 페이지라면 눈에 띄는 버튼을 계속 추가하는 것이 개선이 아닐 수 있습니다. 무엇을 넣느냐만큼 무엇을 덜어 내느냐가 결과를 만듭니다. 이런 취향과 목적은 코드 생성 도구가 대신 정해 주기 어렵습니다.

내 아이디어도 작은 경험으로 줄일 수 있을까요?

처음부터 회원 관리와 결제까지 갖춘 서비스를 목표로 삼기보다, 사용자가 들어와서 느끼거나 끝낼 장면 하나를 적어 보세요. “링크를 열고 바로 잠깐 쉴 수 있다”처럼 짧아도 좋습니다. Koi.rest가 보여 주는 것은 모든 앱을 작게 만들라는 규칙보다, 작은 경험도 독립적인 결과물이 될 수 있다는 가능성입니다.

AI에게 줄 요청도 그 장면을 중심으로 써 보세요. 예를 들어 “처음에는 설명보다 풍경이 먼저 보이고, 소리는 사용자가 원할 때 조절하게 해 주세요”처럼 화면에서 확인할 행동으로 바꿉니다. 이는 제작자의 실제 프롬프트가 아니라, 사례를 참고한 연습 예시입니다. 사용한 모델이나 제작 시간은 원문에 없으므로 추정하지 않는 편이 정확합니다.

공개하기 전에는 무엇을 확인하면 좋을까요?

쉬는 페이지라면 사용자가 원치 않는 소리나 움직임을 멈출 수 있는지 먼저 보세요. 휴대폰에서 조작부가 화면을 가리지 않는지, 새로 들어온 사람이 설명 없이 시작할 수 있는지도 확인할 만합니다. 친구에게 링크를 보내고 첫 행동을 관찰하면, 기능을 더 만드는 것과 사용하기 편해지는 것의 차이가 드러납니다.

이 확인 목록은 제품에 결함이 있다는 지적이 아니라 첫 웹앱을 위한 제안입니다. 완벽한 기술을 갖추기 전이라도 만들 수 있지만, 결과를 판단하는 일까지 생략할 수는 없습니다.

FAQ: 코딩을 전혀 몰라도 같은 결과를 만들 수 있나요?

이 사례만으로 보장할 수 없습니다. 제작자에게는 개발 경험이 있었고 JavaScript가 낯설었습니다. 초보자라면 작은 화면에서 시작해 실제 실행과 수정 과정을 함께 익히는 편이 좋습니다.

FAQ: 이런 작은 사이트도 MVP인가요?

하나의 경험에 대한 반응을 확인하는 시제품으로 볼 수 있습니다. 다만 공개됐다는 사실만으로 사업성이나 수익이 검증된 것은 아닙니다.

출처: https://koi.rest/
제작자 글: https://news.ycombinator.com/item?id=49837006
확인: 2026-09-25 KST.