바이브코딩 사이트 배포 전, AI에게 맡겨야 할 QA 점검 방법

바이브코딩으로 웹사이트를 만들고 나면 보통 마지막 단계에서 AI에게 “잘 만들었는지 확인해줘”라고 묻게 됩니다. 하지만 이 질문에는 좋은 답이 나오기 어렵습니다. 코드를 생성한 AI가 스스로 만든 결과물을 평가하면, 눈에 띄는 오류가 없는지만 보고 실제 사용자의 실패 경로를 놓치기 쉽기 때문입니다.

배포 버튼을 누르기 전에는 칭찬을 요구하기보다 출시를 보류할 권한이 있는 QA 리드처럼 행동하라고 지시하는 편이 낫습니다. 중요한 것은 화면이 예쁘게 보이는지가 아니라, 사용자가 실수하거나 네트워크가 불안정할 때 서비스가 어떤 상태가 되는지입니다.

바이브코딩 결과물에서 가장 위험한 오류

눈에 보이는 에러는 오히려 찾기 쉽습니다. 페이지가 깨지거나 빌드가 실패하면 배포를 멈출 수 있습니다. 더 까다로운 문제는 오류 메시지 없이 기능이 틀리게 작동하는 경우입니다.

화면에서는	실제로는	확인 방법
저장 완료로 표시	서버에 기록되지 않음	새로고침 후 데이터 재조회
로그인한 사용자로 보임	권한 검사가 빠져 남의 데이터 노출	다른 계정으로 같은 URL 접근
버튼이 잘 눌림	중복 요청으로 결제가 두 번	연속 클릭·느린 네트워크 재현
데스크톱에서 정상	모바일에서 버튼이 화면 밖으로	좁은 화면 폭에서 직접 조작

따라서 배포 전 검사는 “페이지가 열리는가”가 아니라 다음 질문에 가까워야 합니다.

• 사용자가 입력을 빠뜨리거나 잘못된 값을 넣으면 어떻게 되는가?
• API가 느리거나 실패하면 현재 상태를 이해할 수 있는가?
• 새로고침과 뒤로 가기를 해도 데이터와 인증 상태가 일관적인가?
• 권한이 없는 사용자가 주소를 직접 입력하면 차단되는가?
• 성공한 것처럼 보이지만 실제 처리가 끝나지 않은 부분은 없는가?

AI에게 맡길 QA의 역할과 범위

AI에게 검사를 요청할 때는 단순한 코드 리뷰보다 역할과 행동을 구체적으로 지정해야 합니다. “문제가 있는지 찾아줘”보다 “실제 신규 방문자처럼 서비스를 사용하고, 출시를 막을 수 있는 QA 리드로서 결함을 재현하라”고 요청하는 방식이 효과적입니다.

검사 대상은 크게 기능, 화면 상태, 환경 변화, 품질과 보안으로 나눌 수 있습니다. 기능 영역에서는 회원가입, 로그인, 로그아웃, 비밀번호 재설정 같은 인증 흐름을 처음부터 끝까지 확인해야 합니다. 입력값이 비어 있거나, 이미 등록된 이메일을 사용하거나, 형식에 맞지 않는 값을 넣었을 때의 응답도 포함해야 합니다.

화면 영역에서는 정상 화면만 보지 말고 데이터가 하나도 없을 때, 로딩이 길어질 때, 요청이 실패했을 때, 접근 권한이 없을 때의 상태를 따로 점검해야 합니다. 빈 화면이 단순히 “데이터 없음”을 뜻하는지, 오류 때문에 렌더링되지 않은 것인지 구분할 수 있어야 합니다.

환경 변화도 중요합니다. 데스크톱만 확인하면 안 되며 태블릿과 모바일 화면에서 레이아웃이 실제로 사용할 수 있는지 봐야 합니다. 긴 제목, 긴 사용자 이름, 이미지가 누락된 경우, 목록에 데이터가 전혀 없는 경우처럼 콘텐츠 길이와 양이 달라지는 상황도 넣어야 합니다.

정상 경로보다 사용자 실수를 먼저 시험하기

실제 사용자는 개발자가 정한 순서대로 움직이지 않습니다. 로그인 화면에서 여러 번 클릭하고, 입력 중인 페이지를 새로고침하고, 브라우저 뒤로 가기를 누르고, 잘못된 주소를 직접 입력합니다. QA 프롬프트에도 이런 행동을 명시해야 합니다.

특히 다음 시나리오는 작은 서비스에서도 결함이 자주 드러나는 지점입니다.

중복 행동과 페이지 이동

저장·제출·결제 버튼을 빠르게 두 번 누르면 요청이 중복되지 않는지 확인해야 합니다. 요청 처리 중 버튼을 비활성화하는지, 처리 중이라는 표시가 있는지도 함께 봅니다. 새로고침 뒤 폼 데이터가 사라지는 것이 정상인지, 이미 처리된 요청이 다시 실행되는지도 기능에 따라 달라집니다.

뒤로 가기 이후 인증이 풀리거나 이전 화면의 오래된 데이터가 남는 문제도 있습니다. 브라우저의 주소만 바뀌고 실제 콘텐츠가 갱신되지 않는 단일 페이지 앱에서는 이런 현상이 특히 눈에 잘 띄지 않을 수 있습니다.

잘못된 주소와 권한 우회

존재하지 않는 URL에는 서비스의 나머지 화면과 어울리는 404 페이지가 제공되어야 합니다. 관리자용 주소나 다른 사용자의 리소스 주소를 직접 입력했을 때는 화면에서 링크를 숨기는 것만으로 충분하지 않습니다. 서버나 API에서도 권한을 확인해야 합니다.

AI에게는 일반 사용자, 로그인 사용자, 권한이 없는 사용자, 관리자처럼 서로 다른 계정 상태로 같은 URL과 API를 확인하라고 요청하는 것이 좋습니다. 단순히 메뉴가 보이는지 검사하는 것과 실제 접근이 차단되는지는 다른 문제입니다.

반응형·접근성은 마지막에 따로 보는 항목이 아니다

반응형 검사는 브라우저 창의 너비를 줄여 보는 것만으로 끝나지 않습니다. 가로 스크롤이 생기는지, 터치 영역이 너무 작은지, 모달을 닫을 수 있는지, 긴 문장이 버튼이나 표를 밀어내는지 확인해야 합니다. 이미지 비율이 달라지거나 이미지가 로드되지 않는 상황에서 레이아웃이 무너지지 않는지도 포함됩니다.

접근성에서는 마우스를 사용하지 않고 키보드의 Tab 키만으로 주요 기능을 실행할 수 있는지 보는 것이 출발점입니다. 현재 포커스 위치가 보이지 않거나 모달을 연 뒤 배경 요소로 포커스가 빠져나가면 키보드 사용자는 조작하기 어렵습니다. 입력 필드와 오류 메시지가 연결되어 있는지, 색상만으로 상태를 구분하지 않는지도 확인해야 합니다.

색상 대비 역시 디자인 취향의 문제가 아닙니다. 회색 글자와 연한 배경을 조합하면 일반 사용자에게도 읽기 어려울 수 있습니다. AI가 접근성을 확인할 때는 “문제가 없다”는 판단만 내리지 말고, 어떤 페이지에서 어떤 요소를 키보드로 이동했고 어떤 대비 또는 레이블 문제를 확인했는지 근거를 남기게 해야 합니다.

느린 네트워크와 API 실패를 일부러 만들기

개발 환경에서는 API 응답이 즉시 돌아오고 이미지도 빠르게 로드됩니다. 이 상태만 보면 로딩 화면이 실제로 필요한지, 실패 상태가 제대로 표시되는지 알 수 없습니다.

QA 과정에서는 요청이 늦어지는 상황과 서버가 오류를 반환하는 상황을 구분해 시험해야 합니다. 느린 요청 중에는 중복 제출을 막고, 사용자가 기다려야 하는 이유를 알 수 있어야 합니다. 요청이 실패한 뒤에는 무한 스피너가 계속 돌지 않아야 하며, 다시 시도할 수 있는지 또는 어떤 행동을 해야 하는지 안내해야 합니다.

네트워크가 끊겼다가 복구되는 경우, 일부 데이터만 표시되는 경우, 응답 형식이 예상과 다른 경우도 결과에 영향을 줍니다. 모든 장애를 프런트엔드에서 해결할 수 있는 것은 아니지만, 최소한 실패를 성공처럼 보여주지 않는 것이 중요합니다. API 키, 내부 오류 메시지, 스택 트레이스, 테스트용 계정 정보가 브라우저 콘솔이나 화면에 노출되는지도 같은 단계에서 확인해야 합니다.

발견한 문제는 심각도와 재현 절차로 관리하기

문제를 찾았다는 사실만으로는 수정 우선순위를 정하기 어렵습니다. 출시를 막아야 하는 문제와 다음 업데이트에서 고쳐도 되는 문제를 분리해야 합니다.

치명적 문제에는 로그인 자체가 되지 않거나, 결제·저장 같은 핵심 작업이 성공한 것처럼 보이지만 실제로 처리되지 않는 경우, 권한 우회와 민감정보 노출이 포함됩니다. 높은 위험의 문제는 특정 모바일 화면에서 핵심 버튼을 누를 수 없거나, API 실패 후 복구가 불가능하거나, 신규 사용자가 가입 과정에서 막히는 사례처럼 서비스 이용을 크게 방해하는 결함입니다.

그보다 낮은 우선순위의 시각적 어긋남이나 일부 긴 문장 처리 문제도 기록할 필요는 있지만, 핵심 흐름을 막는 결함과 같은 순서로 다루면 판단이 흐려집니다. AI에게는 각 문제마다 다음 정보를 출력하게 하는 편이 좋습니다.

• 문제가 발생한 페이지와 사용자 상태
• 재현을 위해 누른 버튼, 입력한 값, 이동한 URL
• 기대한 결과와 실제 결과
• 영향받는 사용자 범위
• 심각도와 출시 차단 여부
• 수정한 파일 또는 로직
• 수정 후 다시 실행한 테스트와 결과

“문제없음”이라는 결론도 근거가 있어야 합니다. 어떤 화면 크기를 확인했는지, 어떤 계정 상태를 사용했는지, 실패 응답과 중복 클릭을 어떻게 시험했는지 기록되지 않았다면 검사가 끝난 것이 아니라 검사가 부족한 것입니다.

배포 전 사용할 수 있는 요청문 구성

AI 코딩 도구에 한 번에 모든 것을 맡길 때는 다음과 같은 구조로 요청하면 됩니다. 점검 항목을 그대로 나열하기보다 서비스에 맞는 핵심 흐름과 실패 조건을 추가하는 것이 중요합니다.

너는 출시를 보류할 권한이 있는 냉정한 QA 리드다. 이 서비스를 처음 방문한 사용자와 로그인 사용자 관점에서 실제로 사용하며 점검하라. 데스크톱·태블릿·모바일 반응형, 인증 흐름, 입력값 검증, 로딩·빈 데이터·실패·권한 없음 상태, 버튼·링크·폼·모달의 작동 여부를 확인하라. 새로고침, 뒤로 가기, 잘못된 URL, 중복 클릭, 긴 텍스트, 누락 이미지, 느린 네트워크와 API 오류도 시험하라. 키보드 이동, 색상 대비, 콘솔 오류, 빌드 오류, 클라이언트에 노출되는 비밀정보와 권한 검사를 점검하라. 정상 경로뿐 아니라 사용자의 실수와 예상 밖의 행동을 우선하라. 발견한 문제를 심각도별로 분류하고 치명적·높은 위험 문제는 직접 수정한 뒤 동일한 시나리오로 재테스트하라. 각 결과에는 재현 절차와 실제 테스트 근거를 남겨라. 근거 없이 “문제없음”이라고 결론 내리지 마라.

다만 AI가 브라우저를 실제로 조작할 수 없는 환경이라면 “테스트했다”고 말할 수 없습니다. 이 경우에는 코드와 설정을 정적으로 검토한 항목, 실행이 필요한 항목, 사람이 직접 확인해야 할 항목을 나눠 보고하게 해야 합니다. 자동화 도구를 연결할 수 있다면 브라우저 테스트와 API 테스트를 함께 실행하고, 최소한 핵심 사용자 흐름은 실제 배포와 유사한 환경에서 다시 확인하는 편이 안전합니다.

배포 전 QA의 목적은 오류를 하나도 남기지 않는다는 약속을 만드는 데 있지 않습니다. 어떤 오류가 존재하는지, 그 오류가 누구에게 어떤 손해를 주는지, 출시 전에 반드시 고쳐야 하는지를 알 수 있게 만드는 데 있습니다. 특히 바이브코딩 결과물은 코드가 빠르게 만들어지는 만큼, 보이지 않는 상태 관리·권한·실패 처리의 빈틈을 별도로 의심해야 합니다. 화면이 정상적으로 보인다는 사실은 테스트의 시작점이지 완료 신호가 아닙니다.