바이브코딩 앱 출시 전 검증 점검표

가장 자주 비어 있는 자리입니다. 로그인은 대체로 잘 만들어지지만 로그인한 뒤의 경계는 자주 빠집니다. 계정 두 개를 만들어 A로 만든 데이터의 주소를 B의 브라우저에 그대로 넣어 봅니다. 열리면 화면만 가려 둔 상태입니다. 관리자 화면 주소를 일반 계정으로 직접 열어 보고 로그아웃한 뒤 뒤로 가기로 이전 화면이 되살아나는지도 확인합니다. 비밀번호 재설정과 이메일 변경처럼 계정을 넘길 수 있는 흐름은 따로 밟습니다. 역할이 여럿이라면 조합마다 한 번씩 확인합니다.

정상 입력은 만들어질 때 이미 확인된 자리라 여기서 다시 보지 않습니다. 필수 항목을 비운 채로 보내 보고 수량에 0과 음수를 넣습니다. 날짜를 과거로 잡고 아주 긴 문자열과 이모지를 이름 칸에 넣습니다. 화면에서 막히는지가 아니라 요청이 서버에 도달했을 때 막히는지를 봅니다. 화면 검증만 있는 앱은 요청을 직접 보내면 그대로 통과합니다. 같은 요청을 빠르게 두 번 보내 결제나 신청이 두 건 생기는지도 확인합니다. 파일 업로드가 있으면 형식과 용량 제한을 넘긴 파일로 한 번 시도합니다.

외부 모델 호출과 문자 발송, 지도와 번역처럼 건당 요금이 붙는 연동은 사용량이 곧 청구서입니다. 한 화면을 열 때 호출이 몇 번 나가는지 세어 봅니다. 새로 고침마다 반복되는 호출, 실패했을 때 무한히 다시 시도하는 코드, 로그인하지 않은 사용자도 부를 수 있는 경로가 요금이 새는 세 자리입니다. 사용자 한 명과 하루 전체의 상한을 정해 두고 그 상한에 닿았을 때 무엇을 보여 줄지도 함께 정합니다. 요금 알림을 미리 걸어 두면 청구서보다 알림으로 먼저 알게 됩니다.

외부 연동을 끊고 같은 화면을 다시 밟아 봅니다. 아무 반응이 없거나 흰 화면이 되면 사용자는 같은 동작을 되풀이합니다. 그때마다 요금이 늘고 중복 데이터가 쌓입니다. 오류 메시지에 내부 경로나 데이터베이스 문장이 그대로 나오는지도 봅니다. 결제나 저장처럼 중간에 끊기면 안 되는 흐름은 끊어 놓고 다시 시작했을 때 어느 상태로 남는지 확인합니다. 실패한 요청이 로그에 남는지 함께 확인합니다. 사용자에게 보이는 문구와 로그에 남는 내용은 따로 정합니다.

수집하는 항목을 화면 순서대로 적어 봅니다. 실제로 쓰지 않는데 받고 있는 항목은 지웁니다. 이름과 연락처, 결제 정보가 어느 저장소에 어떤 형태로 남는지, 외부 서비스로 보내는 값에 개인정보가 섞여 있는지 확인합니다. 대화 기록을 외부 모델에 보내는 앱이라면 무엇이 함께 전송되는지 한 번은 직접 봐야 합니다. 탈퇴했을 때 데이터가 지워지는 경로가 있는지도 항목에 넣습니다. 업로드한 파일이 주소만 알면 누구나 열 수 있는 상태인지도 확인합니다.

배포는 마지막 관문이 아니라 별도의 검증 대상입니다. 접속 키와 비밀번호가 코드나 저장소에 그대로 들어 있는지 찾아봅니다. 개발용 설정으로 열려 있는 디버그 화면과 시험용 계정이 남아 있는지 확인합니다. 시험 결제 설정이 실제 결제로 바뀌어 있는지, 도메인과 인증서가 붙어 있는지, 문제가 생겼을 때 이전 버전으로 되돌리는 방법이 있는지를 마지막에 밟습니다. 여기서 걸린 항목이 여러 갈래에 흩어져 있다면 혼자 메우기보다 외부 검증을 붙이는 편이 빠릅니다.