바이브코딩에서 UI보다 중요한 UX, 어떻게 벤치마킹하고 관리할까?

바이브코딩을 하다 보면 UI는 생각보다 참고하기 쉽습니다. 마음에 드는 사이트를 찾고 화면을 캡처하거나, 디자인 특징을 분석해서 AI에게 참고시키면 됩니다.

프로젝트에 getdesign.md 같은 파일을 만들어 색상, 타이포그래피, 여백, 버튼, 카드 등 디자인 규칙을 저장해두고 Cursor, Codex, Claude Code가 계속 참고하도록 만드는 방법도 있습니다.

그런데 어느 순간 이런 생각이 들었습니다.

예쁜 UI보다 더 중요한 UX는 어디서, 어떻게 벤치마킹해야 할까?

버튼 색깔이나 카드 모양은 눈에 보이지만 UX는 화면 한 장만 캡처해서는 잘 보이지 않습니다. 회원가입은 얼마나 간단한지, 가입 후 사용자를 어디로 안내하는지, 빈 화면에서는 무엇을 보여주는지, 오류가 발생하면 어떻게 복구할 수 있는지 등은 직접 사용해봐야 알 수 있습니다.

UX는 화면이 아니라 사용자가 서비스를 이용하면서 겪는 전체 과정에 가깝기 때문입니다.

UI 벤치마킹과 UX 벤치마킹은 다르다

UI 벤치마킹이 무엇을 보여줄 것인가에 가깝다면 UX 벤치마킹은 사용자가 어떻게 행동하게 할 것인가에 더 가깝습니다.

그래서 UX를 벤치마킹할 때는 화면을 수집하는 방식부터 달라져야 합니다.

UX 벤치마킹 → 분석 → 자산화 과정을 보여주는 흐름도

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

UX가 좋다고 생각하는 서비스를 하나 골랐다면 화면만 캡처하지 말고 신규 사용자가 되어 처음부터 직접 사용해보는 것이 좋습니다.

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

이 흐름을 실제로 따라가면서 각 단계에서 사용자가 무엇을 보고, 무엇을 선택하고, 어디에서 고민하게 되는지를 관찰하는 겁니다.

예를 들어 이런 것들을 기록할 수 있습니다.

• 핵심 기능에 도달하기까지 몇 번 클릭하는가?
• 회원가입 과정에서 어떤 정보를 요구하는가?
• 가입 직후 사용자를 어디로 보내는가?
• Empty State에서 다음 행동을 알려주는가?
• 사용자가 다음에 무엇을 해야 하는지 명확한가?
• 저장이나 작업 완료 후 어떤 피드백을 제공하는가?
• 시간이 오래 걸리는 작업의 진행 상태를 어떻게 보여주는가?
• 오류가 발생했을 때 사용자가 어떻게 복구할 수 있는가?
• 오류가 발생해도 작성하던 내용이 유지되는가?
• 실수로 삭제했을 때 Undo가 가능한가?
• 결제까지 몇 단계가 필요한가?
• 구독 해지는 얼마나 쉽게 찾을 수 있는가?

이런 것들이 실제로 벤치마킹해야 할 UX입니다.

UX 벤치마킹도 AI Agent에게 시킬 수 있다

물론 여러 서비스를 하나씩 직접 사용하고 기록하는 것은 꽤 번거로운 작업입니다.

요즘은 브라우저를 직접 조작할 수 있는 AI Agent를 이용해서 이런 조사 작업의 상당 부분을 맡길 수도 있습니다.

중요한 것은 프롬프트입니다.

단순히 **"이 사이트 디자인 분석해줘"**라고 요청하면 대부분 색상, 레이아웃, 버튼, 폰트 같은 UI 분석으로 끝납니다.

대신 AI에게 신규 사용자의 역할을 부여하고 실제 사용 흐름을 따라가도록 요청합니다.

경쟁 서비스 UX 조사 프롬프트

너는 사용성 전문가야.

아래 서비스를 신규 사용자라고 생각하고 직접 사용해줘.

가입부터 핵심 기능 사용, 오류 상황, 결제/구독/해지까지의 전체 UX 흐름을 단계별로 분석해줘.

각 단계에서는 다음 항목을 기록해줘.

• 단계 이름과 목적
• 화면에서 보이는 핵심 요소
• CTA, 입력창, 안내 문구
• 다음 단계까지 필요한 클릭 또는 주요 행동 수
• 사용자의 목표 달성까지 발생하는 마찰 지점
• 오류 또는 실패 상황의 처리 방법
• 좋았던 UX
• 아쉬웠던 UX
• 우리 서비스에 적용할 수 있는 UX 원칙

단순히 화면 디자인을 평가하지 말고 사용자가 처음 서비스를 접해서 핵심 가치를 경험할 때까지의 흐름을 중심으로 분석해줘.

분석 대상 서비스: [URL]

이렇게 하면 경쟁 서비스의 화면을 그대로 따라 하는 것이 아니라 왜 이 서비스가 사용하기 편한지를 분석하는 자료를 만들 수 있습니다.

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

UX를 조사했다면 결과를 채팅창에 남겨놓고 끝내기보다 프로젝트의 자산으로 만드는 것이 좋습니다.

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

좋은 서비스 여러 개를 분석하다 보면 반복적으로 등장하는 패턴이 있습니다.

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

• 가입할 때 불필요한 정보를 요구하지 않는다.
• 가입 직후 아무것도 없는 화면부터 보여주지 않는다.
• 사용자가 첫 번째 성공 경험까지 최대한 빨리 도달하게 한다.
• 핵심 기능까지 필요한 클릭 수를 최소화한다.
• Empty State에는 다음 행동을 위한 CTA를 제공한다.
• 저장이나 작업 완료 후에는 즉각적인 피드백을 제공한다.
• 오래 걸리는 작업은 현재 진행 상태를 보여준다.
• 오류가 발생해도 사용자가 입력한 내용은 최대한 보존한다.
• 오류 메시지는 문제뿐 아니라 다음에 해야 할 행동까지 알려준다.
• 삭제처럼 위험한 작업에는 확인 또는 Undo를 제공한다.
• 카메라, 알림, 위치 등의 권한은 실제 필요한 순간에 요청한다.
• 결제 전에는 가격, 결제 주기, 갱신 조건을 명확하게 보여준다.

이런 규칙들이 하나둘 쌓이면 UX.md는 단순한 메모 파일이 아닙니다.

AI가 새로운 기능을 만들 때마다 참고하는 우리 제품의 UX 원칙이 됩니다.

benchmarks → UX.md → flows → AI Coding Agent의 관계를 보여주는 구조도

UX.md와 벤치마크 자료는 역할을 분리한다

여기서 한 가지 문제가 생깁니다.

여러 서비스를 계속 조사하다 보면 UX.md가 경쟁 서비스 사례로 가득 차기 시작합니다.

그래서 저는 벤치마크와 원칙을 분리해서 관리하는 방식이 좋다고 생각합니다.

한 문장으로 정리하면 이렇습니다.

벤치마크는 '증거'이고 UX.md는 '원칙'입니다.

예를 들어 어떤 서비스에서 가입하자마자 샘플 프로젝트를 자동으로 만들어주는 UX를 발견했다고 해보겠습니다.

이 사례 자체는 benchmarks에 기록합니다.

그런데 여러 서비스를 조사해보니 신규 사용자가 빈 화면을 마주하지 않도록 비슷한 장치를 사용하고 있었습니다.

그렇다면 UX.md에는 특정 서비스 이름 대신 이렇게 일반적인 원칙으로 저장합니다.

"신규 사용자가 첫 화면에서 아무것도 없는 Empty State를 마주하지 않도록 한다."

이렇게 해야 특정 서비스를 복제하는 것이 아니라 좋은 UX에서 원칙을 추출할 수 있습니다.

UX.md가 커지면 Flow를 분리한다

처음부터 복잡한 디렉터리를 만들 필요는 없습니다.

처음에는 UX.md 하나로 시작해도 충분합니다.

내용이 많아지기 시작하면 역할별로 분리합니다.

UX.md
→ 프로젝트 전체 공통 UX 원칙

flows/onboarding.md
→ 회원가입 / 로그인 / 온보딩

flows/payment.md
→ 결제 / 구독 / 갱신 / 해지

flows/errors.md
→ 오류 / 실패 / 재시도 / 복구

flows/mobile.md
→ 모바일 환경 UX

benchmarks/
→ 실제 서비스에서 발견한 좋은 UX 사례

프로젝트 안의 UX 문서 구조를 폴더 트리 형태로 시각화

수집한 UX를 UX.md로 정리하는 것도 AI에게 시킨다

벤치마크가 여러 개 쌓였다면 사람이 일일이 공통점을 찾을 필요도 없습니다.

AI에게 여러 benchmark 파일을 읽히고 반복적으로 나타나는 패턴을 추출하게 할 수 있습니다.

UX.md 정리 프롬프트

benchmarks 폴더에 저장된 UX 분석 자료를 모두 확인해줘.

각 서비스의 UI나 문구를 그대로 따라 하지 말고 여러 서비스에서 반복적으로 발견되는 좋은 UX 패턴을 찾아줘.

각 패턴을 다음 구조로 정리해줘.

• 원칙
• 왜 중요한가
• 우리 서비스에서는 어떻게 적용할 것인가
• 적용하면 안 되는 예외 상황
• 참고한 benchmark 사례

비슷한 원칙은 하나로 통합하고 특정 서비스에만 해당하는 기능은 공통 UX 원칙에 포함하지 마.

기존 UX.md가 있다면 기존 규칙과 중복되는 내용도 확인해줘.

마지막으로 정리된 결과를 UX.md에 반영할 수 있는 형태로 작성해줘.

이 과정을 반복하면 서비스를 벤치마킹할수록 우리 프로젝트의 UX 컨텍스트가 계속 좋아지는 구조를 만들 수 있습니다.

실제 바이브코딩에서는 이렇게 사용한다

이제 Cursor, Codex, Claude Code에게 기능을 만들라고 할 때 바로 구현부터 시키지 않습니다.

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

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

예를 들어 AI의 프로젝트 지침에 다음과 같은 규칙을 추가할 수 있습니다.

기능 구현 전 UX 검토 프롬프트

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

해당 기능과 관련된 flows 문서가 있다면 함께 확인해줘.

프로젝트의 UX 원칙을 지키면서 기능을 구현하고 benchmarks 폴더에 참고할 사례가 있다면 화면이나 문구를 그대로 복제하지 말고 해당 사례가 해결한 UX 문제와 원칙만 참고해줘.

구현이 끝나면 UX.md와 관련 flows 문서를 기준으로 다시 검토해줘.

UX 규칙을 위반한 부분, 사용자가 혼란스러울 수 있는 부분, 불필요한 클릭이나 입력, Empty State, Loading, Error, Success 상태에서 빠진 부분이 있다면 알려줘.

이렇게 하면 AI가 기능을 만들 때마다 제각각 UX를 결정하는 문제를 어느 정도 줄일 수 있습니다.

UI Reference → UX Benchmark → UX 자산화 → AI Coding Agent → Better Product 전체 흐름

결국 바이브코딩도 컨텍스트 관리가 중요하다

처음 바이브코딩을 시작하면 보통 이렇게 요청합니다.

"이 사이트처럼 예쁘게 만들어줘."

조금 익숙해지면 getdesign.md 같은 디자인 가이드를 만들어서,

"우리 디자인 규칙대로 만들어줘."

라고 요청할 수 있습니다.

그리고 UX.md까지 쌓이면 한 단계 더 나아갑니다.

"우리 서비스의 UX 원칙대로 만들어줘."

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

AI가 코드를 빠르게 만들어주는 시대가 되면서 화면을 구현하는 속도 자체는 점점 차별점이 되기 어려워지고 있습니다. 오히려 사용자를 어떤 흐름으로 안내하고, 처음 서비스를 사용한 사람이 얼마나 빨리 가치를 경험하게 할 것인지가 제품의 차이를 만들 수 있습니다.

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

좋은 UI를 AI에게 보여주는 것에서 한 단계 더 나아가,

좋은 UX가 무엇인지 AI에게 계속 가르쳐주는 것.

앞으로 바이브코딩에서 꽤 중요한 컨텍스트가 되지 않을까요?