바이브코딩으로 만든 웹앱, 공개하기 전에 무엇을 테스트해야 할까요?

개발 화면에서 버튼을 한 번 눌러보고 결과가 나오면 앱이 완성된 것처럼 느껴집니다.

신청 버튼이 눌림
→ 신청 완료 문구가 보임
→ 기능 완성

하지만 실제 사용자는 우리가 예상한 순서로만 움직이지 않아요. 필수 항목을 비워두고, 버튼을 연속으로 누르고, 이전 화면으로 돌아갑니다. 휴대전화의 느린 네트워크에서 사용하거나 이미 가입한 이메일을 다시 입력하기도 합니다.

테스트는 앱이 “한 번 작동하는지” 보는 일이 아닙니다.

정상적인 상황에서 원하는 결과가 나오는가?
잘못된 상황에서 데이터가 망가지지 않는가?
문제가 생겼을 때 사용자가 다음 행동을 알 수 있는가?

이 세 가지를 확인하는 일이에요.

테스트할 대상은 화면이 아니라 사용자 흐름이에요

버튼의 색과 모양만 확인해서는 신청 기능을 테스트했다고 보기 어렵습니다.

신청이라는 한 흐름에도 여러 단계가 있습니다.

신청 페이지 진입
→ 정보 입력
→ 제출
→ 서버가 입력 확인
→ 데이터베이스에 저장
→ 완료 화면 표시
→ 확인 이메일 발송
→ 관리자가 신청 내역 확인

화면에는 완료라고 나왔지만 데이터가 저장되지 않을 수 있고, 저장은 됐지만 관리자가 찾을 수 없을 수도 있어요. 이메일 발송이 실패했는데 신청 자체까지 실패로 처리되는 문제도 생길 수 있습니다.

테스트할 때는 먼저 서비스의 중요한 흐름을 적어보세요.

• 회원가입과 로그인
• 예약 또는 신청
• 주문과 결제
• 파일 업로드
• 내 정보 조회와 수정
• 취소와 환불
• 관리자 처리

모든 화면을 똑같이 깊게 검사하기보다 고객의 돈, 개인정보와 핵심 결과가 걸린 흐름부터 확인하는 편이 좋습니다.

1. 정상 흐름을 처음부터 끝까지 확인해요

먼저 사용자가 안내대로 행동하는 기본 흐름을 확인합니다. 개발에서는 이런 경로를 해피 패스(happy path)라고 부르기도 해요.

예약 서비스라면 다음처럼 진행할 수 있습니다.

1. 예약 가능한 시간을 선택합니다.
2. 이름과 연락처를 입력합니다.
3. 예약 버튼을 누릅니다.
4. 완료 안내를 확인합니다.
5. 새로고침하거나 다시 로그인합니다.
6. 내 예약 목록에서 같은 예약을 확인합니다.
7. 관리자 화면에서도 예약을 찾습니다.
8. 확인 메시지가 도착했는지 봅니다.

중요한 것은 화면의 문구와 실제 데이터가 일치하는지 확인하는 것입니다.

화면: 예약 완료
데이터베이스: 예약 없음

→ 성공이 아니라 오류

테스트할 때 생성한 데이터에는 알아보기 쉬운 이름을 사용하세요. 운영 환경에서 확인해야 한다면 실제 고객 데이터와 섞이지 않도록 테스트 주문임을 표시하고, 결제는 소액으로 진행한 뒤 취소까지 확인합니다.

2. 비어 있거나 잘못된 입력을 넣어봐요

실제 사용자는 입력 형식을 모를 수 있고, 붙여넣기하면서 공백을 넣을 수도 있습니다.

각 입력 항목에서 다음을 확인하세요.

• 필수 항목을 비워도 제출할 수 있나요?
• 이메일에 @가 없어도 저장되나요?
• 전화번호에 하이픈이나 공백이 섞이면 어떻게 처리하나요?
• 글자 수가 지나치게 길면 화면이나 데이터가 깨지나요?
• 가격이나 수량에 음수와 소수를 넣을 수 있나요?
• 날짜가 이미 지났거나 예약 범위를 벗어나도 선택되나요?
• 앞뒤 공백과 대소문자를 일관되게 처리하나요?

브라우저 화면에서 입력을 막았다고 끝이 아닙니다. 브라우저의 검사는 우회할 수 있으므로 서버도 같은 기준으로 입력을 확인해야 해요.

오류가 났을 때는 사용자가 무엇을 고쳐야 하는지 구체적으로 알려줘야 합니다.

오류가 발생했습니다

보다

이메일 주소를 확인해주세요

가 다음 행동을 찾기 쉽습니다.

3. 중복 클릭과 반복 요청을 확인해요

네트워크가 느리면 사용자는 버튼이 눌리지 않았다고 생각해 여러 번 누릅니다.

결제 버튼 두 번 클릭
→ 주문 두 개 생성
→ 결제 두 번 승인

화면에서 버튼을 잠시 비활성화하는 것도 필요하지만 그것만으로 충분하지 않습니다. 같은 요청이 서버에 여러 번 도착해도 결과가 한 번만 만들어지는지 확인해야 해요.

다음 상황을 시험해보세요.

• 제출 버튼을 빠르게 두 번 누릅니다.
• 로딩 중에 새로고침합니다.
• 완료 화면에서 이전 페이지로 돌아가 다시 제출합니다.
• 같은 이메일로 회원가입을 반복합니다.
• 같은 좌석이나 재고를 두 사람이 거의 동시에 선택합니다.
• 결제 성공 직후 브라우저를 닫습니다.

결제, 쿠폰, 예약과 재고처럼 중복 처리가 큰 문제를 만드는 기능에는 요청을 한 번만 처리하기 위한 고유한 키와 데이터베이스 제약이 필요할 수 있습니다.

4. 실패하는 상황을 일부러 만들어요

정상 동작만 확인하면 장애가 생겼을 때 앱이 어떻게 반응하는지 알 수 없습니다.

테스트 환경에서 안전하게 다음 상황을 만들어볼 수 있어요.

• 네트워크를 느리게 하거나 잠시 끊습니다.
• 서버가 오류를 돌려주게 합니다.
• 잘못된 API 키를 사용하는 별도 환경에서 확인합니다.
• 외부 이메일 발송을 실패시킵니다.
• 결제 테스트창에서 결제를 취소합니다.
• 업로드할 수 없는 형식이나 너무 큰 파일을 선택합니다.
• 만료된 로그인 세션으로 보호된 기능을 요청합니다.

실패했을 때 확인할 질문은 세 가지입니다.

사용자에게 실패 사실을 알렸는가?
중간 데이터가 잘못 남지 않았는가?
나중에 원인을 찾을 기록이 남았는가?

예를 들어 확인 이메일 발송이 실패했다고 이미 저장한 신청까지 없애야 하는 것은 아닐 수 있습니다. 핵심 업무와 부가 작업의 실패를 어떻게 나눌지 미리 결정해야 해요.

오류를 재현하고 로그로 원인을 찾는 방법은 AI가 버그를 계속 못 고칠 때 로그를 추가하는 방법에서 이어서 볼 수 있습니다.

5. 로그인과 권한을 사용자별로 확인해요

로그인한 사용자 한 명으로만 테스트하면 권한 문제를 놓치기 쉽습니다.

최소한 다음 계정을 준비하세요.

로그아웃 상태
일반 사용자 A
일반 사용자 B
관리자

그리고 주소와 요청값을 바꾸어 다음을 확인합니다.

• 로그아웃한 사용자가 로그인 전용 페이지를 열 수 있나요?
• 사용자 A가 사용자 B의 데이터 주소를 열 수 있나요?
• 사용자 A가 사용자 B의 데이터를 수정하거나 삭제할 수 있나요?
• 일반 사용자가 관리자 API를 직접 요청할 수 있나요?
• 관리자 메뉴만 숨긴 것이 아니라 서버에서도 권한을 검사하나요?
• 탈퇴하거나 정지된 계정의 기존 세션은 어떻게 처리되나요?

권한 테스트는 화면에 메뉴가 보이는지보다 서버가 실제 요청을 거부하는지가 중요합니다.

로그인·세션·권한의 차이를 먼저 이해하면 왜 여러 계정으로 확인해야 하는지 더 쉽게 알 수 있어요.

6. 새로고침과 직접 주소 진입을 확인해요

앱 안의 버튼만 따라가면 정상인데 주소를 직접 열거나 새로고침하면 실패하는 경우가 있습니다.

• 목록이 아닌 상세 페이지 주소부터 직접 엽니다.
• 로그인 전 받은 주소를 로그인 후 다시 엽니다.
• 데이터가 없는 상세 주소를 입력합니다.
• 제출 직후 새로고침합니다.
• 브라우저의 뒤로 가기와 앞으로 가기를 사용합니다.
• 다른 탭에서 같은 데이터를 수정한 뒤 돌아옵니다.

존재하지 않는 데이터에는 적절한 안내를 보여주고, 이미 처리한 요청이 새로고침 때문에 반복되지 않아야 합니다. 로그인이 필요하다면 로그인 후 원래 보려던 페이지로 돌아오게 할 수도 있어요.

7. 휴대전화와 여러 화면 크기에서 사용해봐요

개발 중에는 넓은 모니터만 보게 되지만 실제 방문자는 휴대전화로 들어올 수 있습니다.

화면 폭만 줄여보는 것에서 끝내지 말고 실제 기기에서도 주요 흐름을 완료해보세요.

• 제목과 버튼이 화면 밖으로 나가지 않나요?
• 키보드가 열렸을 때 입력칸과 제출 버튼이 가려지지 않나요?
• 버튼과 링크를 손가락으로 누르기 충분한가요?
• 긴 이메일, 상품명과 오류 문구가 레이아웃을 깨뜨리지 않나요?
• 날짜 선택과 파일 업로드가 모바일에서도 작동하나요?
• 느린 이동통신 환경에서 로딩 상태가 보이나요?
• 가로·세로 전환 뒤 입력 내용이 유지되나요?

가능하다면 아이폰과 안드로이드, 서로 다른 브라우저에서 핵심 흐름을 확인하세요. 모든 기기를 완벽히 지원하기 어렵다면 고객이 많이 쓰는 환경부터 우선순위를 정할 수 있습니다.

8. 개발 환경이 아니라 실제 배포 환경을 확인해요

로컬에서 통과한 테스트가 운영 환경에서도 통과한다는 보장은 없습니다.

배포 환경에는 다음 차이가 있을 수 있어요.

• 운영용 환경변수가 빠졌습니다.
• 실제 도메인의 로그인 리디렉션 주소가 등록되지 않았습니다.
• 데이터베이스 마이그레이션이 적용되지 않았습니다.
• 서버와 데이터베이스의 Region이 다릅니다.
• 외부 서비스가 로컬 주소만 허용하고 있습니다.
• 대소문자가 다른 파일명이 로컬에서는 열리고 배포에서는 실패합니다.

따라서 출시 후보 버전을 실제 주소에 배포한 뒤 핵심 흐름을 다시 확인해야 합니다.

내 컴퓨터에서는 되는데 배포하면 안 되는 이유와 개발·운영 환경을 나눠야 하는 이유를 함께 참고하세요.

기능이 제대로 작동하는지 확인한 다음에는 비밀 키 노출, 서버 권한과 입력값 검증처럼 공격 경로를 따로 살펴봐야 합니다. 이 항목은 바이브코딩 웹앱 보안 체크리스트에서 이어서 점검할 수 있어요.

9. 자동 테스트와 사람이 하는 테스트를 함께 사용해요

사람이 직접 눌러보는 테스트는 문구, 흐름과 사용성을 발견하는 데 좋습니다. 하지만 같은 기능을 수정할 때마다 모든 경우를 손으로 반복하기는 어렵습니다.

자동 테스트는 정해둔 동작을 코드로 반복 확인합니다.

단위 테스트
→ 가격 계산이나 입력 변환처럼 작은 로직 확인

통합 테스트
→ 서버와 데이터베이스처럼 여러 부분의 연결 확인

브라우저 테스트
→ 사용자가 클릭하고 입력하는 전체 흐름 확인

Next.js 공식 테스트 가이드 (새 탭에서 열림)도 Jest·Vitest 같은 단위 테스트 도구와 Playwright·Cypress 같은 브라우저 테스트 도구를 목적에 따라 나누어 안내합니다. 프로젝트의 구조와 중요한 흐름에 맞는 범위부터 시작하세요.

모든 문장과 화면을 자동화할 필요는 없습니다. 먼저 다음처럼 실패했을 때 피해가 큰 흐름을 선택하면 됩니다.

• 로그인과 권한
• 주문 금액 계산
• 결제 성공과 중복 처리
• 예약 가능 인원 계산
• 개인정보 수정

자동 테스트가 통과해도 실제 운영 설정, 모바일 사용성과 외부 서비스 장애까지 모두 보장하는 것은 아닙니다. 자동 테스트와 배포 후 확인을 함께 사용해야 해요.

10. 출시 뒤 문제를 발견할 준비도 테스트해요

출시 전에 모든 문제를 발견할 수는 없습니다. 그래서 문제가 생겼을 때 알아챌 수 있는지도 확인해야 합니다.

• 서버 오류 로그를 볼 수 있나요?
• 중요한 실패가 발생하면 운영자가 알림을 받나요?
• 사용자가 어느 단계에서 멈췄는지 확인할 수 있나요?
• 배포 버전과 오류 발생 시점을 연결할 수 있나요?
• 문제가 큰 경우 이전 배포로 되돌릴 수 있나요?
• 데이터베이스와 업로드 파일의 백업 방법을 알고 있나요?

로그가 무엇이고 왜 필요한지 이해한 뒤, 출시 후에는 어떤 지표를 확인해야 하는지까지 이어서 점검할 수 있습니다.

AI에게 테스트 계획부터 요청해요

AI에게 “테스트해줘”라고만 하면 빌드 한 번을 실행하고 끝낼 수 있습니다. 중요한 사용자 흐름과 증거 형식을 함께 지정하세요.

이 웹 애플리케이션을 공개하기 전에 테스트 계획을 만들어줘.
아직 코드는 수정하지 마.

먼저 서비스의 핵심 사용자 흐름과
실패했을 때 피해가 큰 기능을 찾아줘.

각 흐름마다 아래 경우를 포함해줘.
- 정상적인 입력과 완료
- 빈 값, 잘못된 값, 경계값
- 중복 클릭과 새로고침
- 네트워크와 외부 서비스 실패
- 로그아웃, 다른 사용자, 관리자 권한
- 모바일과 주요 브라우저
- 로컬과 실제 배포 환경의 차이
- 데이터베이스에 남아야 하는 최종 결과

테스트 항목을 다음 열의 표로 정리해줘.
우선순위 | 준비 조건 | 실행 단계 | 예상 결과 | 실제 결과 | 증거

자동화할 가치가 높은 항목도 따로 표시해줘.
확인하지 못한 항목을 통과로 표시하지 마.

계획을 만든 다음 실제 테스트에서는 화면 캡처, 응답 상태, 생성된 테스트 데이터와 로그처럼 결과를 확인할 증거를 남기게 하세요.

공개 전 최소 체크리스트

• 가장 중요한 사용자 흐름을 처음부터 끝까지 완료했습니다.
• 화면의 성공 문구와 데이터베이스 결과가 일치합니다.
• 빈 값, 잘못된 값과 매우 긴 값을 확인했습니다.
• 제출 버튼을 여러 번 눌러도 중복 처리되지 않습니다.
• 네트워크와 외부 서비스 실패 시 안내와 기록이 남습니다.
• 로그아웃·다른 사용자·관리자 권한을 각각 확인했습니다.
• 새로고침, 뒤로 가기와 직접 주소 진입을 확인했습니다.
• 실제 휴대전화에서 핵심 흐름을 완료했습니다.
• 실제 배포 주소와 운영용 데이터베이스에서 확인했습니다.
• 결제가 있다면 테스트 결제뿐 아니라 실제 소액 결제와 취소를 확인했습니다.
• 오류 로그, 알림, 분석과 되돌리기 방법을 준비했습니다.
• 수정 뒤 기존 핵심 기능이 다시 통과하는지 확인했습니다.

정리

• 화면이 한 번 작동하는 것과 실제 서비스로 안전하게 작동하는 것은 다릅니다.
• 버튼보다 사용자의 시작부터 데이터 저장과 운영 확인까지 전체 흐름을 테스트하세요.
• 정상 입력뿐 아니라 잘못된 입력, 중복 요청과 실패 상황을 일부러 만들어야 합니다.
• 로그인 기능은 여러 사용자와 관리자의 권한을 나누어 확인합니다.
• 새로고침, 직접 주소 진입, 모바일과 느린 네트워크도 실제 사용 환경입니다.
• 로컬 테스트 뒤에는 실제 배포 환경에서 다시 확인합니다.
• 중요한 로직과 반복할 흐름은 자동 테스트로 남기고, 사용성과 운영 설정은 사람이 함께 확인합니다.
• 모든 문제를 미리 없앨 수 없으므로 출시 뒤 발견하고 대응할 준비도 테스트해야 합니다.

테스트의 목표는 “오류가 하나도 없다”고 선언하는 것이 아닙니다. 고객이 중요한 일을 끝낼 수 있고, 실패해도 데이터가 망가지지 않으며, 문제가 생기면 원인을 찾을 수 있다는 증거를 만드는 것입니다.