사용자 테스트(UT)는 불편한 진실을 꺼내는 자리다. 최근 한 PM 부트캠프 기록(velog, @hannakwak25)이 공개한 UT 분석 결과는 그 불편함이 얼마나 구체적일 수 있는지를 잘 보여준다. 5060 시니어 사용자 5명을 대상으로 진행한 테스트에서, 참여자 전원(5/5) 이 핵심 버튼을 첫 시도에 발견하지 못했다. 이전 추천 보기 버튼이 스크롤을 내려야 보이는 위치에 있었기 때문이다. 발견성(discoverability) 실패가 단순한 레이아웃 문제가 아니라 이탈과 직결되는 제품 리스크라는 걸, 숫자가 냉정하게 증명했다.
문제는 버튼 위치만이 아니었다. 후기 작성 시 별점 필수 입력을 인지하지 못한 참여자가 5명 중 4명, 가격순 필터 기능을 인지한 참여자는 단 한 명도 없었다. 이 결과가 특히 날카로운 이유는, 만족도 설문에서는 긍정적인 응답이 나왔지만 실제 행동 관찰에서는 반복적인 발견성 실패가 관찰됐다는 점이다. 자기보고(self-report)와 행동 데이터 사이의 간극—이것이 UT가 존재하는 이유다. 공통 원인은 하나로 수렴됐다: 핵심 기능이 스크롤 하단이나 텍스트 형태로만 존재해, 시각적으로 도드라지지 않는다는 것.
여기서 프론트엔드 개발자로서 자연스럽게 떠오르는 질문이 있다. "이 문제를 수정한 UI를 얼마나 빨리 사용자 앞에 다시 올려놓을 수 있는가?" 전통적인 흐름이라면 디자이너에게 수정 요청 → 개발자 구현 → 스테이징 배포 → 재검증의 루프를 돌아야 한다. 빠르면 며칠, 느리면 몇 주다. 그런데 같은 주, 흥미로운 소식이 들어왔다. Vercel이 AI 빌더 Lovable과의 제로컨피그 통합을 공식화한 것이다(Dev Signal #64).
Lovable 프로젝트를 GitHub에 연동하면, Vercel이 Nitro를 통해 빌드 설정 없이 자동 배포한다. vercel.json도, 커스텀 빌드 커맨드도 없다. Lovable에서 변경이 발생하면 Git 푸시와 동일한 방식으로 배포가 트리거된다. 이전까지 AI 생성 앱이 '장난감처럼 느껴졌던' 가장 큰 이유—배포 마찰—가 사라진 셈이다. 결과적으로 Lovable에서 생성한 코드가 공유 가능한 URL로 도달하는 시간이 사실상 0에 수렴한다.
이 두 흐름을 엮으면 하나의 실용적인 설계 사이클이 만들어진다. UT에서 발견된 문제를 자연어로 Lovable에 설명하고("이전 추천 보기 버튼을 스크롤 없이 상단에서 바로 보이게, 별점 입력을 시각적 강조와 함께 필수 안내 추가"), 생성된 프로토타입을 Vercel이 즉시 배포한다. 그리고 그 URL을 다음 UT 세션에 올린다. 기획-디자인-개발-배포-검증의 루프가 하루 안에 닫힐 수 있다.
물론 이 접근에는 한계가 있다. Lovable이 생성한 코드는 프로덕션 코드베이스와 분리된 프로토타입이며, RLS 경계나 엣지 케이스는 여전히 개발자가 직접 판단해야 한다. 하지만 그 판단을 내리기 전에 '이 UI 변경이 실제로 사용자 행동을 바꾸는가'를 먼저 검증할 수 있다는 것이 핵심이다. AI 빌더는 완성된 제품을 만드는 도구가 아니라, 검증 비용을 낮추는 도구로 읽어야 한다.
특히 5060 시니어 사용자처럼 디지털 리터러시가 다양한 그룹을 대상으로 한 제품이라면, 이 빠른 검증 사이클은 더 중요해진다. 이들에게는 코치마크 하나의 위치, 버튼 레이블 한 단어가 전환율과 이탈률을 가르는 변수가 된다. UT 결과가 나온 당일, 가장 심각한 discoverability 이슈를 수정한 프로토타입을 만들고, 다음 날 소규모 재검증을 돌릴 수 있다면—팀이 우선순위 논쟁에 쓰는 시간을 실제 데이터로 대체할 수 있다.
앞으로 UT 분석 결과를 받아드는 팀의 첫 번째 액션이 달라질 것이다. 스프레드시트에 이슈를 정리하고 다음 스프린트를 기다리는 대신, 가장 치명적인 발견성 문제 하나를 골라 AI 빌더에 프롬프트를 던지고, 그날 안에 URL을 공유하는 흐름으로. UT가 '보고서'가 아니라 '다음 실험의 시작점'이 되는 문화는, 결국 이렇게 마찰을 없애는 도구들이 만든다.