배포 버튼을 누르기
전에

바이브 코딩으로 기능을 완성했다. 로그인 작동하고, 데이터 저장되고, 결제까지 된다. 배포 버튼에 손이 간다. 잠깐. AI가 만든 코드가 기능적으로 완벽하더라도, 디자인 측면에서 AI는 체계적으로 특정 영역을 놓친다. 그리고 그 빈틈이 사용자에게는 "이거 AI가 만들었네"라는 인상을 준다.

이 네 가지는 AI가 구조적으로 약한 영역이다. AI는 시각적 결과물을 보지 못한 채 코드만 생성하기 때문이다. 데스크톱에서 보기 좋은 3열 그리드가 모바일에서 어떻게 보이는지, line-height 1.5의 한글이 얼마나 빽빽한지, hover 없는 버튼이 사용자에게 어떤 느낌인지 — AI는 이런 "체감"을 계산하지 못한다.

좋은 소식은, 이 문제들 대부분이 30분이면 잡힌다는 것이다.

아래 체크리스트는 배포 직전에 30분 안에 수행할 수 있는 디자인 QA 항목이다. 전문 디자이너의 리뷰를 대체하지 않지만, "AI가 만든 티"의 80%는 이것만으로 제거된다. 6개 카테고리, 24개 항목.

체크리스트는 수동이다. 매 배포마다 24개를 확인하는 것은 현실적이지 않다. 자동화가 필요하다. 비주얼 리그레션 테스팅은 코드 변경 전후의 스크린샷을 비교해서 의도하지 않은 시각적 변화를 잡아내는 방법이다.

그러나 1인 메이커에게 Chromatic이나 Percy는 과할 수 있다. 간소화 버전이 있다. AI에게 스크린샷을 주고 디자인 리뷰를 요청하는 것이다. Claude나 GPT-4V는 스크린샷을 분석해서 간격 불일치, 색상 문제, 정렬 오류를 잡아낼 수 있다.

이 방법은 완벽하지 않지만, 비용 0원으로 1분 안에 피드백을 받을 수 있다. Playwright MCP를 사용하면 이 과정을 자동화할 수도 있다 — 코드 변경 후 자동으로 스크린샷을 찍고, AI가 이전 버전과 비교하고, 문제가 있으면 경고를 보내는 파이프라인이다.

이 시리즈의 첫 편에서 시작한 질문으로 돌아간다. "바이브 코딩으로 만든 것을 어떻게 제품으로 만드는가?"

답은 인디해커들의 실전에 있다. 성공한 1인 메이커들은 놀라울 정도로 비슷한 패턴을 따른다.

공통 패턴이 보인다. 디자인 퀄리티보다 문제 해결이 수익을 만든다. 그러나 "최소한의 일관성"은 반드시 필요하다. 사용자는 "못생긴 것"은 용서하지만, "불일치하는 것"은 불신한다. 버튼 색이 페이지마다 다르고, 간격이 들쭉날쭉하면 — 기능이 아무리 좋아도 사용자는 "이거 믿을 수 있나?"를 의심한다.

하이브리드 모델을 제안한다. AI로 빠르게 만들고, 검증된 부분만 정밀하게 다듬는다.

이 우선순위의 핵심은 "모든 것을 한 번에 완벽하게 만들려 하지 않는다"는 것이다. 전환 화면을 먼저 다듬고, 나머지는 사용자 피드백이 쌓이면 그때 개선한다. 데이터 없이 디자인을 다듬는 것은 AI에게 "예쁘게 만들어"라고 하는 것과 같다 — 방향 없는 노력이다.

시리즈 전체를 관통하는 원칙은 하나다.