바이브코딩하다 보면 UI는 생각보다 참고하기 쉽습니다. 마음에 드는 사이트를 찾고 화면을 캡처하거나, getdesign.md 같은 파일에 디자인 규칙을 정리해서 AI에게 참고시키면 됩니다.

 

그런데 어느 순간 이런 생각이 들더라고요.

예쁜 UI보다 더 중요한 UX는 어디서, 어떻게 벤치마킹하지?

 

버튼 색깔이나 카드 모양은 눈에 보이지만 UX는 화면 한 장만 캡처해서는 잘 보이지 않습니다. 회원가입을 얼마나 간단하게 만들었는지, 가입 후 사용자를 어디로 보내는지, 빈 화면에서는 무엇을 보여주는지, 오류가 발생하면 어떻게 복구시키는지 같은 사용자의 전체 흐름이 UX니까요.

 

UX는 화면이 아니라 '사용 과정'을 벤치마킹

UX가 좋다고 생각하는 서비스를 하나 정해서 실제 사용자처럼 사용해보는 겁니다.

가입 → 온보딩 → 첫 핵심 기능 → 저장/수정 → 오류 → 결제 → 구독 관리/해지

 

그리고 이 과정에서 디자인보다 이런 걸 기록합니다.

  • 핵심 기능까지 몇 번 클릭하는가?
  • 가입할 때 무엇을 요구하는가?
  • Empty State에서 다음 행동을 알려주는가?
  • 작업 성공/실패를 어떻게 알려주는가?
  • 실수했을 때 Undo가 가능한가?
  • 결제와 해지는 몇 단계인가?

 

직접 해봐도 되고, 요즘은 브라우저를 직접 조작할 수 있는 AI Agent에게 시켜도 됩니다.

중요한 건 **"이 사이트 디자인 분석해줘"**가 아니라 **"신규 사용자처럼 직접 사용하면서 UX 흐름을 분석해줘"**라고 시키는 것입니다.

 

벤치마킹한 UX는 어디에 저장할까?

저라면 프로젝트에 UX.md를 하나 만들겠습니다.

좋은 서비스 여러 개를 분석하다 보면 반복적으로 등장하는 패턴이 있습니다. 특정 서비스를 그대로 따라 하는 게 아니라 이런 공통점을 우리 서비스가 지켜야 할 UX 규칙으로 만드는 겁니다.

 

예를 들면 이런 것들입니다.

  • 가입할 때 불필요한 정보는 요구하지 않는다.
  • 가입 직후 빈 대시보드부터 보여주지 않는다.
  • 핵심 기능까지 클릭 수를 최소화한다.
  • Empty State에는 다음 행동을 위한 CTA를 넣는다.
  • 저장/완료 후에는 즉시 피드백을 준다.
  • 오래 걸리는 작업은 현재 진행 상태를 보여준다.
  • 오류가 나도 사용자가 입력한 내용은 최대한 보존한다.
  • 오류 메시지는 문제만 알려주지 말고 다음 행동도 알려준다.
  • 삭제처럼 위험한 작업에는 확인 또는 Undo를 제공한다.
  • 권한은 앱 실행 직후가 아니라 실제 필요한 순간에 요청한다.

 

이런 규칙들이 하나둘 쌓이면 UX.md 자체가 꽤 중요한 프로젝트 자산이 됩니다.

 

UX.md가 커지면 역할별로 분리

처음에는 UX.md 하나면 충분하지만 프로젝트가 커지면서 규칙이 많아지면 역할별로 나눌 수 있습니다.

  • UX.md → 프로젝트 전체 공통 UX 원칙
  • flows/onboarding.md → 회원가입 / 로그인 / 온보딩
  • flows/payment.md → 결제 / 구독 / 해지
  • flows/errors.md → 오류 / 실패 / 복구
  • flows/mobile.md → 모바일 UX
  • benchmarks/ → 실제 서비스에서 발견한 좋은 UX 사례

 

여기서 benchmarks와 UX.md의 역할은 구분하는 게 좋을 것 같습니다.

benchmarks에는 관찰한 사례를 저장하고, UX.md에는 여러 사례에서 반복적으로 발견한 원칙을 저장하는 겁니다.

 

그리고 Cursor, Codex, Claude Code에게 새로운 기능을 만들게 할 때 그냥 "이 기능 만들어줘"라고 하지 않고,

UX.md 확인 → 관련 Flow 확인 → 구현 → UX 검토

이 순서로 작업시키는 겁니다.

 

AI에게는 이렇게 시켜볼 수 있습니다

새로운 기능을 구현하기 전에 UX.md를 먼저 읽어줘.

해당 기능과 관련된 flows 문서가 있다면 함께 확인하고, 프로젝트의 UX 규칙을 지키면서 구현해줘.

benchmarks 폴더에 참고할 사례가 있다면 화면이나 문구를 그대로 복제하지 말고, 왜 해당 UX가 편리한지 원칙을 추출해서 현재 서비스에 맞게 적용해줘.

구현이 끝나면 UX.md와 관련 flows 문서를 기준으로 다시 검토하고, UX 규칙을 위반했거나 개선할 부분이 있으면 알려줘.

 

결국 이것도 바이브코딩의 컨텍스트 관리

처음에는 **"이 사이트처럼 예쁘게 만들어줘."**라고 했다면, getdesign.md가 생기면서 **"우리 디자인 규칙대로 만들어줘."**가 되고, UX.md까지 쌓이면 **"우리 서비스의 UX 원칙대로 만들어줘."**가 됩니다.

 

UI는 사용자가 보는 것이고, UX는 사용자가 겪는 것입니다.

바이브코딩에서도 UI 레퍼런스만 모으지 말고 좋은 서비스를 직접 사용하거나 AI Agent에게 사용시켜서 UX를 분석하고, 거기서 발견한 공통적인 원칙을 나만의 UX.md로 계속 자산화하는 것.

 

이것도 꽤 중요한 바이브코딩 노하우가 아닐까 싶습니다.

[블로그에서 더 자세히 보실 수 있습니다]