바이브 코딩한 앱이 실제로 작동하는지 어떻게 알 수 있을까?

앱을 만들었다. 클릭해서 살펴봤다. 버튼이 작동했다. 레코드가 저장됐다. 대시보드가 업데이트됐다. 기분이 좋다.

하지만 그 코드를 작성한 건 당신이 아니고, 솔직히 말하면 아마 읽어보지도 않았을 것이다. 그러니 실제로 아는 것은, 딱 한 번, 당신이, 시도해본 그 한 가지 일에 대해 작동했다는 것뿐이다. 그것이 정말로 ‘작동한다’는 것에 관한 나머지 모든 것은 신뢰의 문제다.

대부분의 사람이 테스트하는 유일한 경로는 해피 패스다

바이브 코딩한 앱을 테스트하는 모습은 보통 이렇다. 파일 하나를 업로드하면 처리된다. 폼 하나를 제출하면 레코드가 나타난다. 버튼 하나를 클릭하면 워크플로가 실행된다. 그게 전부다. 그것이 테스트의 전부다.

게으름의 문제가 아니다. 기반 로직을 작성하지 않은 사람이 하는 수동 테스트의 자연스러운 한계다. 잘못될 수 있다고 상상할 수 있는 것만 테스트할 수 있고, 코드를 읽을 수 없다면 시스템이 아니라 데모를 테스트하는 셈이다. 해피 패스는 AI가 확실히 최적화한 유일한 경로다. 애초에 앱을 만들어낸 프롬프트 속 시나리오가 바로 그것이기 때문이다.

문제는 실제 사용이 해피 패스에만 머물지 않는다는 것이다. 실제 사용자는 더블클릭한다. 탭을 두 개 연다. 뒤로 가기를 누르고 다시 제출한다. 빌더 본인이 자신의 앱을 예상한 순서대로 한 번, 신중하게 클릭해볼 때는 이런 것들이 전혀 드러나지 않는다.

실제로 문제가 터지는 곳은 동시성이다

가장 명확한 예는 동시성이며, 정확히 무엇을 확인해야 하는지 알고 있어도 손으로 테스트하기는 정말 어렵다.

크레딧 기반 기능을 떠올려보자. 사용자가 프로세스를 실행하면 크레딧이 소모되고, 잔액 확인이 크레딧이 다 떨어지면 이를 막아야 한다. 이제 같은 사용자가 탭 다섯 개를 열고, 첫 번째 결제 확인이 끝나기도 전에 같은 1초 안에 다섯 개의 프로세스를 시작하는 경우를 떠올려보자. 확인 후 차감하는 로직이 이런 중첩 상황을 처리하도록 만들어지지 않았다면, 다섯 개 프로세스 모두가 차감이 기록되기 전에 잔액 확인을 통과할 수 있다. 결과적으로 사용자는 감당할 수 없는 프로세스를 실행하고, 크레딧 잔액은 마이너스가 되고, 계정 상태는 아무도 예상하지 못한 방식으로 틀어진다.

버튼을 한 번 클릭해서는 이를 잡아낼 수 없다. 탭 다섯 개를 열어야 한다는 생각을 하고, 클릭 타이밍을 같은 1초 이내로 맞추고, ‘잔액 확인’과 ‘잔액 차감’이 서로 경쟁할 수 있는 별개의 두 단계라는 사실을 알고 있어야 한다. 이것은 테스트 누락이 아니다. 한 번에 하나씩 클릭하는 수동 테스트로는 구조적으로 찾아낼 수 없는 종류의 버그다. 이 버그는 여러 일이 동시에 일어날 때만 존재하며, 혼자 테스트하는 사람이 그런 조건을 의도적으로, 게다가 반복 가능하게 만들어내기는 쉽지 않기 때문이다.

이것이 바로 AI가 생성한 앱에 대한 연구가 아무도 대비하지 않는 실패 모드로 지적하는 엣지 케이스다. AI는 질문받은 특정 성공 시나리오를 위한 경로를 만들 뿐, 동시 편집이나 중복 클릭, 단계 사이의 타이밍 간격을 위한 경로는 만들지 않는다. 그리고 그 결과로 생긴 손상은 오류를 내지 않고, 몇 주 후 보고서나 잔액이 이상해 보일 때까지 조용히 그 자리에 남아 있을 뿐이다.

이를 잡아낼 테스트를 거의 아무도 작성하지 않는 이유

이런 종류의 버그에 대한 정직한 해결책은 자동화된 테스트다. 단위 테스트, 통합 테스트처럼 사람의 상상력과 인내심에 의존하는 대신 다섯 개의 동시 요청을 시뮬레이션하고 결과를 기계적으로 확인할 수 있는 무언가 말이다. 자동화된 테스트는 지치지 않고, 엣지 케이스를 잊지 않으며, 월요일에 고친 것이 화요일에 깨지지 않았는지 확인하기 위해 변경할 때마다 다시 실행할 수 있다.

실제로는 바이브 코더가 이런 것을 갖추고 있는 경우는 거의 없다. 테스트 스위트를 작성하는 것은 그 자체로 독립적인 기술이며, 기능이 작동하는지가 아니라 실패 모드에 대해 추론해야 하므로 앱 자체를 작성하는 것보다 어렵다고도 할 수 있다. 부탁하면 AI 에이전트가 테스트를 작성할 수 있지만, 그래도 누군가는 부탁해야 한다는 것을 알아야 하고, 테스트가 실제로 무엇을 확인하는지 이해해야 하며, 앱이 그 밑에서 변할 때마다 계속 최신 상태로 유지해야 한다. 화요일 오후에 클라이언트 포털을 출시하는 비기술 빌더에게는 그것이 너무 큰 도약이며, 빠르게 바이브 코딩하는 기술 빌더조차도 어차피 다음 프롬프트로 갈아치울 코드를 위해 멈춰서 테스트 커버리지를 작성하는 일은 거의 없다.

그래서 대부분의 바이브 코딩한 앱에서 테스트의 현실적인 상태는, 무엇이 잘못될 수 있는지 추측할 능력이 가장 부족한 사람이 딱 한 번 진행하는 해피 패스 클릭 테스트다. 그것이 바로 신뢰 격차다. 앱이 작동한다는 것을 검증하는 것이 아니라, 시도해본 그 한 가지에 근거해 작동하기를 바라는 것이다.

‘시각적 확실성’이 실제로 의미하는 것

바라는 것에 대한 진짜 대안이 있으며, 그것은 ‘테스트 스위트 작성법을 배우라’는 것이 아니다. 애초에 로직이 숨겨져 있지 않은 기반 위에 위험한 부분을 만드는 것이다.

시각적 확실성이란 설정 패널을 열어서 생성된 코드를 한 줄도 읽지 않고도 어떤 사용자 그룹이 레코드를 볼 수 있는지, 블록이 데이터 소스에 정확히 어떤 필터를 적용하는지, 워크플로가 순서대로 단계별로 정확히 무엇을 하는지 확인할 수 있다는 뜻이다. 동작을 테스트해서 그 뒤에 있는 규칙을 추론하는 것이 아니라, 규칙을 직접 읽는 것이다.

이는 신뢰 격차가 가장 큰 비용을 초래하는 범주, 즉 결제 로직, 권한, 동시 사용자가 있는 모든 것에서 가장 중요하다. Softr 같은 플랫폼은 권한, 데이터 제한, 워크플로 단계를 신뢰하기 위해 한 줄씩 감사해야 하는 AI 생성 코드가 아니라 시각적이고 검사 가능한 설정으로 유지함으로써 이를 해결한다. 한 클라이언트가 다른 클라이언트의 레코드를 볼 수 있는지 알고 싶다면 데이터 제한 규칙을 열어서 읽으면 된다. 다섯 개의 동시 로그인을 시뮬레이션하고 AI가 경쟁 상태를 제대로 처리했기를 바랄 필요가 없다. 그 규칙을 집행하는 것은 당신의 특정 프롬프트를 위해 AI가 작성한 맞춤 확인이 아니라 플랫폼 자체의 검증된 인프라이기 때문이다.

그렇다고 모든 커스텀 기능이 설정 패널 안으로 사라진다는 뜻은 아니다. 진짜로 커스텀한 UI라면, 하나의 컴포넌트에만 범위가 한정되고 플랫폼의 기존 권한 및 데이터 레이어를 통해 연결되는 바이브 코딩 블록은 앱 전체 분량의 생성된 비즈니스 로직과는 전혀 다른 위험이다. ‘AI가 이 한 부분을 잘못 처리했다’는 것의 파급 범위가 결제 시스템 전체가 아니라 블록 하나로 한정되기 때문이다.

결국 남는 분기점

당신의 앱이 주말 프로젝트거나 아무도 돈을 내지 않는 프로토타입이라면, 그냥 출시하고, 해피 패스를 한 번 클릭해보고, 넘어가면 된다. 위험 부담은 당신이 실행한 수동 테스트의 위험 부담 그 자체다.

그것이 클라이언트 포털이나 예약 시스템, 크레딧, 잔액, 역할이 관련된 것이라면, 정직한 질문은 ‘이걸 테스트했나?‘가 아니다. ‘잘못됐을 때 정말로 문제가 될 부분을 실제로 검증할 수 있는가, 아니면 AI의 말을 그냥 믿고 있는가?‘다. 답이 신뢰라면, 그것은 이전에 Day Two 문제에서 다뤘던 것과 같은 분기점이며, 당신이 누구인지에 따라 두 갈래 모두 타당하다.

코드를 읽을 수 있거나 배울 의지가 있다면, 다른 빌더로 옮기지 말고 실제 도구로 그 격차를 메워라. Cursor는 실제 코드베이스 안에서 작동하므로 동시성 테스트를 요청하고 그 결과를 직접 읽을 수 있다. Replit은 클라우드 환경을 제공해서 테스트 스위트를 실행하는 것이 뒷전이 아니라 루프의 정상적인 일부가 된다. 두 경우 모두 격차는 AI의 능력이 아니라, 테스트를 요청해야 한다는 것을 아는지, 그리고 그 결과가 괜찮은지 판단할 수 있는지에 있다.

코드를 읽을 수 없고, 잘못된 권한이나 마이너스 잔액이 실제로 문제가 되는 종류의 앱을 만들고 있다면, 위험한 부분을 규칙을 추측하는 대신 직접 읽을 수 있는 기반으로 옮겨라. 그것이 실제로 만들고 있는 앱이라면 클라이언트 포털 랭킹을 확인해보라. 잘못된 추측이 가장 큰 비용을 치르는 곳이 바로 거기이기 때문이다.