프롬프트만으로 웹앱을 만들 수 있는지 확인하려고 2026년 9월 10일 Windows 11과 Chrome에서 25분 집중 타이머를 직접 제작하고 저장·시작·일시정지 동작을 검증했습니다.
이번 검증에서 실제로 만든 것
이번 글의 목표는 완성된 코드를 받아 적는 것이 아니라, 코딩 경험이 적은 사람이 요구사항을 어떻게 설명해야 작동하는 결과물에 가까워지는지 확인하는 것이었습니다. 테스트용 앱은 별도 프레임워크 없이 HTML, CSS, JavaScript 세 파일로 만들었습니다. 화면에는 25분 집중 모드와 5분 휴식 모드, 시작·일시정지·초기화 버튼, 오늘 끝낼 일을 저장하는 입력란을 넣었습니다. 데이터는 외부 서버가 아니라 브라우저의 로컬 저장소에만 보관하도록 제한했습니다.
처음 요청에는 목적, 화면에 반드시 있어야 할 요소, 저장 방식, 성공 조건을 함께 적었습니다. “예쁜 타이머를 만들어 줘”처럼 결과를 판정하기 어려운 문장 대신 “집중 25분과 휴식 5분을 전환할 수 있고, 시작 후 초 단위가 감소하며, 입력한 할 일이 새로고침 후에도 남아야 한다”처럼 관찰 가능한 조건을 사용했습니다. 이 차이가 바이브코딩에서 가장 중요한 출발점입니다.
AI에게 전달한 요구사항을 쪼개는 방법
첫 번째 묶음은 기능입니다. 집중 모드는 25분, 휴식 모드는 5분으로 고정하고 모드 버튼을 누르면 시간이 즉시 바뀌도록 요청했습니다. 시작 버튼을 누르면 표시 시간이 감소하고, 실행 중에는 버튼 문구가 일시정지로 바뀌며, 초기화를 누르면 선택한 모드의 처음 시간으로 돌아와야 한다고 적었습니다. 이렇게 상태 변화까지 정의하면 단순한 정적 화면이 아니라 테스트 가능한 프로그램이 됩니다.
두 번째 묶음은 데이터입니다. 할 일 입력값은 저장 버튼을 눌렀을 때 localStorage에 기록하고, 페이지를 다시 열면 저장된 문구를 읽어 화면 아래에 표시하도록 요청했습니다. MDN의 Window.localStorage 문서에서 데이터가 브라우저 세션을 넘어 저장될 수 있다는 동작 범위를 확인했습니다. 민감한 정보나 여러 기기에서 동기화해야 하는 데이터에는 이 방식을 사용하면 안 된다는 제한도 요구사항에 포함했습니다.
세 번째 묶음은 화면과 접근성입니다. 버튼 이름만 읽어도 행동을 알 수 있게 하고, 실행 상태와 남은 시간을 화면에 표시하며, 움직임 감소 설정을 사용하는 환경에서는 불필요한 전환 효과를 줄이도록 했습니다. 모바일에서는 타이머 카드와 설명 영역이 한 열로 쌓이도록 반응형 기준도 적었습니다. 디자인 취향보다 먼저 기능의 우선순위와 실패 조건을 적어야 수정 요청이 짧아집니다.
직접 실행한 테스트 환경과 입력값
테스트 날짜: 2026년 9월 10일. 환경: Windows 11, Chrome, 1280×900 브라우저 화면, 로컬 정적 웹 서버. 입력값: “타이머 웹앱 실제 동작 검증”. 확인한 동작: 할 일 저장, 25분 타이머 시작, 초 단위 감소, 일시정지 버튼 전환입니다. 계정 로그인, 외부 API, 광고 코드, 분석 스크립트는 사용하지 않았습니다.
먼저 입력란에 테스트 문구를 넣고 저장 버튼을 눌렀습니다. 화면 하단이 “저장됨: 타이머 웹앱 실제 동작 검증”으로 바뀌는 것을 확인했습니다. 이어서 시작 버튼을 눌렀을 때 버튼 문구가 “일시 정지”로 바뀌었고, 남은 시간이 25:00에서 24:59로 감소했습니다. 계속 실행한 뒤 24:42까지 감소한 화면을 별도로 남겼습니다. 마지막으로 일시정지를 눌렀을 때 시간이 멈추고 버튼 문구가 “계속”으로 바뀌었습니다.
위 영상은 같은 Chrome 세션에서 1초 간격으로 기록한 여섯 장의 실제 화면을 연결한 것입니다. 시간을 임의로 편집한 예시 애니메이션이 아니라, 실행 중인 페이지에서 남은 시간이 감소하는 상태를 캡처했습니다.
작동하지 않을 때 확인할 순서
버튼을 눌러도 시간이 줄지 않으면 먼저 브라우저 개발자 도구의 콘솔에서 오류를 확인합니다. 그다음 시작 버튼에 클릭 이벤트가 연결됐는지, 남은 시간을 보관하는 값이 숫자인지, 한 번에 두 개 이상의 타이머가 실행되고 있지 않은지 살펴봅니다. 수정 요청에는 “안 돼요”라고만 쓰지 말고 오류 문구, 재현 순서, 기대 결과, 실제 결과를 함께 넣는 편이 좋습니다.
새로고침 후 할 일이 사라지면 저장 버튼을 누른 시점에 localStorage.setItem이 호출되는지, 페이지가 열릴 때 getItem으로 같은 키를 읽는지 확인합니다. 브라우저의 사생활 보호 모드나 사이트 데이터 삭제 설정에 따라 값이 보존되지 않을 수 있습니다. 저장 공간 동작은 브라우저와 사용자 설정의 영향을 받으므로 서버 데이터베이스처럼 취급하면 안 됩니다.
시간이 한꺼번에 건너뛰거나 늦게 표시되는 경우도 있습니다. MDN의 setInterval 문서처럼 반복 호출 간격은 정확한 실행 시각을 보장하지 않습니다. 운영용 타이머라면 단순히 1씩 빼는 방식보다 시작 시각과 현재 시각의 차이로 남은 시간을 다시 계산해야 백그라운드 탭 지연에 더 잘 대응할 수 있습니다.
프롬프트를 수정할 때 지켜야 할 기준
한 번에 전체 코드를 다시 만들게 하기보다 실패한 동작 하나를 고쳐 달라고 요청하는 편이 안전합니다. 예를 들어 저장 기능이 문제라면 화면 디자인은 유지하고 저장 키와 로드 시점만 수정하도록 범위를 제한합니다. 수정 후에는 기존에 되던 시작·일시정지·초기화 기능도 다시 확인합니다. 새 기능 하나를 추가할 때마다 이전 기능이 깨지지 않았는지 보는 회귀 검사가 필요합니다.
AI가 만든 코드도 출처와 책임이 사라지는 것은 아닙니다. 외부 패키지를 추가했다면 공식 문서와 라이선스를 확인하고, API 키는 코드에 직접 넣지 않으며, 사용자가 입력하는 값은 화면에 다시 표시하기 전에 안전하게 처리해야 합니다. 결제, 인증, 개인정보, 파일 업로드가 들어가는 앱은 이번 타이머보다 위험 범위가 훨씬 넓으므로 전문가 검토와 별도 보안 시험이 필요합니다.
한계와 실패 조건
이번 결과는 로컬 브라우저에서 실행한 작은 학습용 웹앱입니다. 여러 기기 동기화, 사용자 계정, 서버 백업, 알림 권한, 오프라인 앱 설치 기능은 검증하지 않았습니다. 브라우저 탭이 백그라운드로 이동하면 반복 타이머 호출이 지연될 수 있고, 사용자가 사이트 데이터를 지우면 저장한 할 일도 사라집니다. 따라서 생산성 서비스나 유료 제품에 그대로 배포할 수준이라고 단정할 수 없습니다.
또한 여섯 장을 연결한 작동 영상은 화면 변화 확인을 위한 짧은 증거이며 장시간 정확도를 증명하지 않습니다. 25분 전체가 정확히 끝나는지, 절전 모드에서 복구되는지, 다양한 모바일 브라우저에서 같은 결과가 나오는지는 후속 테스트가 필요합니다. 독자는 자신의 환경에서 같은 입력과 확인 순서를 반복한 뒤 결과가 다르면 브라우저 버전과 오류 메시지를 함께 기록해야 합니다.
결론과 다음 단계
바이브코딩의 핵심은 긴 프롬프트가 아니라 관찰 가능한 성공 조건입니다. 기능, 데이터, 화면, 제한을 나누어 요청하고 실제 브라우저에서 입력·상태 변화·실패 조건을 확인하면 AI가 만든 코드를 그대로 믿는 위험을 줄일 수 있습니다. 이 사이트가 어떤 기준으로 직접 검증 자료를 만드는지는 dea:no 소개 페이지에서도 확인할 수 있습니다.
다음 단계에서는 이 타이머에 완료 알림과 키보드 조작을 추가하되, 기능을 추가하기 전 현재 저장·시작·정지 동작을 자동 검사로 고정할 예정입니다. 기능 수를 늘리는 것보다 재현 가능한 증거와 한계를 함께 남기는 것이 더 중요한 완성 기준입니다.