블로그 목록으로바이브 코딩으로 만든 앱, 코드 없이 E2E 테스트하는 법
By 원영2026년 7월 25일6분업데이트 2026년 7월 26일이 글의 목차
바이브 코딩으로 앱을 만들면 코드는 순식간에 나옵니다. 그런데 그게 처음부터 끝까지 — 모든 버튼과 회원가입, 결제까지 — 진짜 되는지는 아무도 대신 확인해 주지 않습니다. 이렇게 사용자가 실제로 거치는 길을 처음부터 끝까지 따라가 보는 확인을 E2E 테스트라고 부릅니다. 코드를 못 읽으면 "전부 다시 눌러보는 것"만이 안전한데, 그 일은 배포할 때마다 불어납니다. 이 글은 그 E2E 테스트를 왜 지금은 못 하고 있는지, 그리고 코드 없이 어떻게 하는지 이야기합니다.
- AI 시대에 수정은 거의 공짜가 됐지만, 어디에 문제가 있는지 '발견'하는 일은 여전히 손으로 클릭하는 노동으로 남아 있다.
- 코드를 못 읽으면 이번 변경이 어디에 영향을 줬는지 알 수 없어 '전부 다시 눌러보기'만 안전하다 — 그 비용이 배포마다 폭발한다.
- 그래서 확인을 건너뛰게 되고, 건너뛴 곳의 에러는 당신이 아니라 사용자가 먼저 발견한다.
"AI가 다 됐다고 했는데, 왜 사용자한테는 에러가 나죠?"
Lovable, Bolt, Cursor 같은 도구로 며칠 만에 앱을 만들어 세상에 내놓습니다. 화면도 그럴듯하고, 내가 눌러본 곳은 다 됩니다. 그런데 첫 사용자가 회원가입을 하다 막히고, 결제 버튼이 먹통이고 — 정작 나는 그걸 몰랐습니다. AI는 "다 됐다"고 했으니까요.
바이브 코딩으로 만들어 본 사람이라면 이 감각을 압니다. 만드는 속도는 놀랍게 빨라졌는데, "이게 진짜 되는 게 맞나?" 라는 질문 앞에서는 여전히 막막합니다.
그리고 이건 일부의 이야기가 아닙니다. 2025년 3월 TechCrunch 보도에 따르면, Y Combinator 2025년 겨울 배치 스타트업의 4분의 1은 코드베이스의 95%를 AI가 작성했습니다. 만드는 방식은 이미 바뀌었습니다. 바뀌지 않은 건 확인하는 방식입니다.
내가 만든 화면과 사용자가 겪는 화면은 다를 수 있다 — 그 차이를 사용자보다 먼저 안다
바이브 코딩은 왜 테스트가 어려운가
AI가 코드 생산을 거의 공짜로 만들었습니다. 버그도 — 어디가 문제인지만 알면 — IDE의 AI가 10초 만에 고칩니다. 문제는 '고치기'가 아니라 '발견하기'입니다.
코드를 읽을 수 있는 개발자는 "이번엔 결제 로직을 안 건드렸으니 결제는 확인 안 해도 돼"라며 확인할 범위를 좁힙니다. 코드를 못 읽으면 그게 안 됩니다. 무엇이 무엇에 영향을 줬는지 알 수 없으니, 안전한 길은 '전부 다시 눌러보기' 하나뿐입니다.
그런데 그 비용은 앱 크기 × 배포 빈도로 불어납니다. 화면 20개짜리 앱을 주 3번 배포하면 매번 수십 번을 손으로 눌러야 합니다. 그래서 결국 '방금 만진 곳만' 대충 보고 배포합니다 — 사실상 도박입니다.
수정은 공짜가 됐지만, 어디에 문제가 있는지 발견하는 일은 여전히 손 노동으로 남았다
테스트를 건너뛰면 생기는 일
확인을 건너뛴 곳의 에러는 사라지지 않습니다. 자리만 옮깁니다 — 당신의 책상에서 사용자의 화면으로.
- 회원가입이 중간에 막혀 첫 방문자가 이탈합니다. 몇 명이 이탈했는지는 알 수 없습니다.
- 결제가 조용히 실패해, 그날 매출이 사라집니다. "결제가 안 돼요" 전화를 받고서야 압니다.
- 투자 데모 도중 버튼이 먹통이 됩니다. 첫인상은 한 번뿐입니다.
가장 아픈 건, 이 에러들이 어렵거나 드문 게 아니라는 점입니다. 대부분은 한 번만 끝까지 눌러봤다면 잡혔을 것들입니다. 문제는 그 '한 번'을 배포마다 사람이 하기가 불가능하다는 데 있습니다.
코드 없이 E2E 테스트하는 법
방법은 단순합니다. 쓰던 AI 코딩 도구(Cursor·Claude Code 등)에 Specnote 를 연결해두고, 평소 하던 대로 말하면 됩니다.
"방금 배포했는데, 회원가입 잘 되는지 확인해줘."
그 말은 곧 평범한 말로 적힌 E2E 테스트 단계가 됩니다 — "로그인 화면에 들어간다 → 이메일과 비밀번호를 넣는다 → 대시보드가 뜬다". 그리고 진짜 크로미움 브라우저가 그 단계를 사람처럼 하나씩 눌러보고, 단계마다 통과·실패를 표시합니다. 전 과정은 영상으로 남습니다. (AI 도구를 안 쓴다면 Specnote 화면에서 직접 적어도 됩니다.)
확인해줘 한 마디 → 평범한 말 단계 → 실제 브라우저 통과
핵심은 두 가지입니다. 단계가 코드가 아니라 말이라서 무엇을 확인했는지 당신이 직접 읽고 판단할 수 있고, 한 번 만들어진 단계는 배포할 때마다 자동으로 다시 실행됩니다 — '전부 다시 눌러보기'를 기계가 대신합니다.
개발자를 대체하지 않습니다
이미 코드를 읽고 쓰는 개발자라면 Playwright 같은 코드 기반 테스트 도구가 잘 맞습니다. 이 글이 다루는 건 다른 문제입니다 — 코드를 못 읽는 사람의 '발견' 문제.
AI가 앱을 만들 수 있게 됐다면, AI가 그 앱을 눌러보게도 할 수 있어야 합니다. 만드는 것과 되는지 확인하는 것은 다른 일이고, 후자는 아직 대부분 사람 손에 남아 있습니다. 그 마지막 손 노동을 넘기는 것 — 그게 전부입니다.
지금 테스트해보기
사용자보다 먼저 아세요자주 묻는 질문
E2E 테스트란 무엇이고, 테스트 자동화와 어떻게 다른가요?
E2E 테스트란 사용자가 실제로 거치는 길을 처음부터 끝까지 따라가 확인하는 방법입니다. 화면 하나가 아니라 "가입 → 로그인 → 결제"처럼 이어지는 흐름 전체를 봅니다. 테스트 자동화는 그 확인을 사람이 매번 누르지 않고 기계가 대신하게 만드는 것이라, 둘은 대체 관계가 아니라 함께 쓰는 말입니다. 이 글에서 다루는 것은 코드 없이 하는 E2E 테스트 자동화입니다.
코드를 정말 몰라도 테스트할 수 있나요?
네. 쓰던 AI 코딩 도구에 말로 부탁하거나, Specnote 화면에서 평범한 문장으로 직접 적으면 됩니다. 코드나 스크립트를 쓰지 않습니다.
앱이 자주 바뀌는데, 그때마다 다시 적어야 하나요?
아니요. 한 번 적어둔 흐름은 배포할 때마다 자동으로 다시 확인합니다. 화면이 크게 바뀐 부분만 손보면 됩니다.
AI(Cursor·Claude 등)한테 테스트를 시키면 되지 않나요?
그렇게 해봤는데도 사용자한테 에러가 났다면, 그게 이유입니다. 코드를 만든 AI가 스스로 "다 됐다"고 채점하는 것과, 실제 브라우저가 사람처럼 끝까지 눌러보는 것은 다릅니다. 왜 그런지는 AI에게 테스트를 맡겼는데, 왜 오류가 났을까요? 에서 연구 결과와 함께 자세히 다뤘습니다.
Playwright 같은 테스트 도구를 쓰면 되지 않나요?
Playwright·Cypress는 개발자가 테스트 코드를 작성해 쓰는 훌륭한 E2E 테스트 도구입니다. 다만 코드를 못 읽으면 애초에 쓸 수 없고, AI에게 테스트 코드를 짜 달라고 하면 그것 역시 당신이 못 읽는 코드가 됩니다 — 무엇을 검사하는지, 통과가 무슨 뜻인지, 실패했을 때 어디를 수정할지 판단할 수 없습니다. Specnote는 시나리오가 평범한 말이라, 무엇을 확인했는지 당신이 직접 읽고 판단할 수 있습니다.
어떤 앱에 쓸 수 있나요?
브라우저에서 도는 웹 서비스라면 — 쇼핑몰·예약·SaaS·랜딩 페이지 등 — 어떤 도구로 만들었든 됩니다.
Lovable·Bolt·Cursor로 만든 앱에도 쓸 수 있나요?
네. 무엇으로 만들었는지는 상관없습니다. 코드가 아니라 완성된 화면을 사람처럼 눌러보기 때문입니다.
