바이브코딩 툴로 프로토타입(X) 프로덕션(O) 을 위한 HTML 초안 만들기: 실제 현업 적용사례

소개

지난번 바이브 코딩 툴(cursor)로 실제 서비스를 구현하면서,
프로토타입을 넘어서 실제 프로덕션을 코딩 툴로 작업할수 있지 않을까? 하는 생각에 시도해보게 되었습니다.
이번에 현업에서 실제 작업하던 서비스는 외부 사용자가 아닌 '내부 저작자'들이 사용하는 서비스이기때문에 디자인요소가 매우 중요하지 않았기에 시도해볼 수 있었습니다.

진행 방법

PRD 작성 : 클로드 + GPT

개발 : Cursor + 클로드 코드

디자인 컴포넌트 : Tailwind CSS

결과와 배운 점

🎯 배경: 왜 이 방식을 선택했나?

기존 개발 프로세스는 다음과 같은 구조였습니다:

• 기획 → 디자인 → 퍼블리싱 → 개발

• 1번 사이클을 도는 데만 2~3개월 소요

• 각 단계마다 요구사항 누락, 소통 오류, 일정 지연 발생

그래서 목표를 이렇게 잡았습니다:

기획자가 직접 "개발 가능한 HTML"을 만들고, 1주 만에 개발팀에 전달하자.

프로젝트 예시:

• 복잡한 기술이 포함된 플로우 : AI 박싱 API, 정규화, 좌표 변환 등

• 사용자 화면: PDF 파일 업로드 → 1차 박싱 → 2차 박싱 → OCR 변환

📋 전체 프로세스

1단계: 요구사항 정의 및 플로우 설계

기존의 개발된 화면이 있었지만, JSP로 아주 간단하게 개발된 서비스였고,
추가적인 기능고도화를 위해서는 UI/UX개선이 필수적이었습니다. 따라서 현재의 상태 / 향후 반영해야 하는 기능&플로우 등을 GPT와 CLAUDE를 통해 어떤 방향이 좋을지 논의하며 PRD를 다듬어 나갔습니다. (이 부분은 생략할게요)

UI/UX 프로토타입을 살펴보기위해 Lovable, V0 등의 서비스에 PRD를 올려 가장 적합한 형태의 UI 예시를 잡았습니다.

[Lovable로 만든 프로토타입 예시]

ALT

한국 웹 사이트의 스크린 샷

[실제 구현된 화면 예시]

ALT

한국어 텍스트가있는 웹 사이트의 스크린 샷

-> 실제 화면에 대한 정책도 '개발정보'라는 버튼을 추가하여 바로 확인할 수 있도록 하였습니다.

🔍 핵심 원칙

• 사용자 플로우 중심으로 설계

• 기술적 복잡성은 최대한 UI에서 감춤

# 플로우차트 작성 시 주의사항
- 사용자 기준 화면 단위로 구성
- 예외 흐름/에러 시나리오 포함

2단계: 컴포넌트 시스템 구축

이번 프로젝트의 목적은 디자인-퍼블리싱작업을 없애고 최대한 개발팀에서 바로 개발이 가능한 형태를 만들자! 였습니다. 그래서 각각의 사용자 플로우에 맞는 주요 페이지를 HTML로 제작하기로 했습니다 (미리 개발팀과 공유함)

하지만 초반에는 디자인CSS통일을 하지 않은 채로 페이지별로 끊어서 작업하다보니,
공통된 ( 헤더/프로그레스 바 등등) 영역을 매번 페이지마다 작업해야 하는 문제가 생기더라고요.

그래서 이 부분은 컴포넌트 가이드 문서를 별도로 제작하여 참조문서를 만들고, 항상 해당 가이드를 참고하여 각 페이지별로 작업할 수 있도록 했습니다.

🛠️ Design Token 기반 Tailwind 시스템 도입

:root {
  --primary-color: #4f46e5;
  --secondary-color: #7c3aed;
  --success-color: #10b981;
  --spacing-md: 1rem;
  --radius-md: 0.5rem;
}

• 컴포넌트 가이드 문서(components_index.html) 별도 제작

• 공통 레이아웃/헤더/네비게이션은 이 문서 기준으로 관리

추가로 프로토타입이 아니다보니 버튼 하나도 옮길때마다 구체적인 위치와, 정확한 프롬프트를 주는 것이 굉장한 피로도였습니다. 실제로 Figma MCP를 연동하여, Cursor로 구현한 화면을 다시 디자인화 하는 작업을 진행했는데 기대에 미치지 못하더라구요....

(실제로 피그마로 디자인 --> Cursor로 옮기는 작업은 어느정도 퀄리티가 나오나, 반대로는 아직 쉽지 않은 것 같습니다. 아래와같이 이상오묘(?)하게 만들어줌.... )

ALT

중국어 텍스트가있는 페이지의 스크린 샷

그러다가 UI/UX를 자유롭게 바이브 수정할수있는 Stagewise툴을 알게됬고,
설치 후 활용할 수 있게 되었습니다. (프론트앤드 익스텐션프로그램인데, 아직 에이전트까지 설치해서 해보진 않았어요!)

ALT

보라색 배경의 주황색과 파란색 시계

ALT

한국 웹 사이트의 스크린 샷

3단계: 기능 중심 화면 제작 (HTML)

'화면만 예쁘게' 만드는 것이 아니라, 개발자가 실제로 활용 가능한 구조로서 작동하는
서비스용 페이지를 HTML로 직접 구현하는것이 최종적인 결과물이었습니다.

페이지 구성 요소:

1. 반응형 3컬럼 레이아웃

2. 인터랙티브 UI 버튼

3. 상태 관리 및 사용자 피드백 구조 포함

4단계: 개발 전달용 패키지 구성

실제 전달할때는 아래와같은 파일구조로 정리하였고 주요하게는 아래 폴더구조로 세팅하였습니다.

📋 개발팀 전달 문서
1.실제 주요 페이지별 HTML파일
2.공통 컴포넌트 가이드 문서
3.개발가이드 문서
4.정책서 (실제 HTML파일에도 '기능 명세'로 버튼을 두었지만, 취합된 형태로 제공)

prototype-v4/
├── 01_entry.html                    # 진입점
├── 02_primary_boxing_v2.html        # 1차 박싱
├── 03_secondary_boxing.html         # 2차 박싱
├── 04_ocr_conversion.html           # OCR 변환
├── tailwind-components.css          # 컴포넌트 시스템
├── README_CSS.md                    # 개발 가이드
└── newplan.md                       # 기술 정책서

🚀 깨달은 점들

1. 유지보수 : 실제 전 단계를 최소화하기위해 작업한것이었는데, 디자인/퍼블리싱을 끼지 않고 모든 작업을 하다보니 유지보수도 기획단에서 모두 진행해야 하는 문제(?)가 생기더라고요. 이부분을 어떻게 효율화 해야 할지 고민하는 중입니다 🙂

2. 프로토타이핑이 아닌 프로덕션 : 바이브코딩으로 '프로토타입'까지는 구현하는데 매우 훌륭한 방식이지만, 프로덕션까지 이어지는건 아직까지는 유지보수나 여러가지 면에서 제약이 있는 것 같습니다. 조직의 모든 구성원이 어느정도 align된 이해도를 가지고, 진행하는 부분이 중요한 것 같아요. 팀과 함께 협업하며, 프로덕션으로 활용하기 위해 더 효율적인 방안도 고민해보고있습니다.
   

3. UI/기능 수정 : Figma로 MCP연동하여 작업하는 것보다 Stagewise로 작업하면 UI요소를 쉽게 수정할수 있는데, 아직 테스트해보는중이라 좀더 시도해볼 예정입니다! ㅎㅎ