소개
바이브코딩으로 앱을 만들어 본 분이라면 아실 거예요. "되는 것 같은데... 진짜 되나?" 하는 찜찜함. 출시 전에 뭘 확인해야 할지 몰라서 그냥 올렸다가 사용자가 먼저 버그를 발견하는 일이요.
저는 코드를 직접 보지 않고 전부 AI한테 맡기는 쪽인데, 그래도 "내 앱이 해야 할 일을 하는가"는 확인할 수 있더라고요. 검증은 코드 실력이 아니라 "생각하는 방식"에 가깝거든요. 식당 위생 점검관이 요리할 줄 몰라도 점검하듯요. 제가 출시 전에 쓰는 체크리스트를 공유합니다.
진행 방법 — 3단계
1단계 · "꼭 돼야 하는 일"을 평범한 말로 적는다
기술 명세 말고, 사용자가 하는 행동을 적습니다. 초기 앱은 의외로 짧아요.
- 가입하고 로그인할 수 있다
- 우리 앱의 핵심 기능 한 가지를 할 수 있다
- 로그인 후 내 데이터를 볼 수 있다
- (결제가 있으면) 결제를 끝낼 수 있다
이게 끝입니다. 이게 당신의 테스트 계획이에요.
2단계 · 각 단계에 "성공한 모습"을 붙인다
"가입 버튼을 누른다"는 테스트가 아닙니다. "가입 버튼을 누르면 → 대시보드로 넘어가고 → 오른쪽 위에 내 이름이 보인다" 가 테스트예요. 성공한 모습을 정의해야 클릭이 점검이 됩니다.
3단계 · "조용한 실패"를 노린다
가장 위험한 건 화면은 멀쩡한데 속으로는 안 된 경우입니다.
폼은 제출됐는데 데이터가 저장 안 됨 / 결제는 됐는데 구독이 활성화 안 됨 / 메일은 발송됐는데 도착 안 함. 이건 화면만 봐서는 안 보입니다. 각 단계의 "성공한 모습"을 미리 정해놨을 때만 잡혀요.
손이 벅차지면
위를 매번 직접 하기 벅차지면 E2E 자동 검증 도구들이 사람처럼 클릭해서 대신 확인해줍니다(오픈소스 Autonoma 같은). 다만 이런 도구는 대체로 코드·터미널 흐름 위에서 돌아가서, 설치는 AI한테 맡기더라도 결과를 받아보는 자리가 개발 쪽에 가깝더라고요. 코드 안 보는 1인 운영자라면, 일단 위 3단계를 매번 빠짐없이 돌리는 습관부터가 큰 차이를 만듭니다.
결과와 배운 점
- 검증은 "모든 걸 다 확인"이 아니라 "제일 중요한 몇 개를 빠짐없이"입니다.
- "성공한 모습"을 정의하는 한 줄이 거의 전부를 결정해요.
- 완벽한 품질보다 "최소한 이건 된다"는 안심이 출시에는 더 중요하더라고요.
이 체크리스트가 도움 되면 좋겠어요 🙂
