이 글은 바이브 코딩으로 웹 목업을 제작하는 데서 그치지 않고, Flutter 구현과 Figma 문서화까지 실제 프로덕트 사이클을 한 차례 진행한 경험을 바탕으로 작성했습니다.
요즘 개발 분야에서 ‘바이브 코딩(Vibe Coding)’이라는 말을 자주 접한다.
자연어로 원하는 기능을 설명하고, AI가 생성한 코드를 바탕으로 애플리케이션을 만들어 가는 방식이다. 몇 번의 프롬프트만으로 그럴듯한 화면이 만들어지는 모습은 분명 인상적이다.
하지만 실제 프로젝트에 적용하려면 조금 다른 질문이 생긴다.
바이브 코딩은 빠르게 데모 화면을 만드는 단계를 넘어, 실제 프로덕트 개발 과정에서도 유용할까?
이번 PoC에서는 이 질문을 직접 확인해 보기로 했다. 기획과 디자인을 함께 진행하며 웹 목업을 만들고, 검증된 결과를 Flutter 애플리케이션으로 옮겼다. 개발 이후에는 브라우저 익스텐션을 활용해 화면을 Figma로 정리하며 유지보수를 위한 문서화까지 마무리했다.
이번에 진행한 전체 흐름
↓
바이브 코딩으로 웹 목업 제작
↓
화면과 사용자 흐름 검증
↓
Flutter 애플리케이션으로 마이그레이션
↓
브라우저 익스텐션을 활용한 Figma 변환
↓
디자인 기준과 유지보수 문서 정리
즉, 이번 경험은 단순히 “AI로 화면 하나를 만들어 봤다”는 이야기가 아니다. 아이디어를 화면으로 구체화하고, 실제 애플리케이션으로 구현한 뒤, 다음 작업을 위한 문서까지 남기는 하나의 프로덕트 사이클 전체에 바이브 코딩을 적용해 본 기록이다.
PoC에서는 완성도보다 확인 속도가 중요했다
PoC의 목적은 완성된 제품을 만드는 것이 아니다. 우리가 생각한 아이디어가 실제로 동작할 수 있는지, 사용자가 어떤 흐름으로 기능을 이용하게 될지, 핵심 기능이 충분한 가치를 제공하는지를 빠르게 확인하는 과정이다.
그런데 전통적인 절차를 모두 밟다 보면 생각보다 많은 시간이 필요하다.
- 요구사항을 문서로 정리한다.
- 화면 구성을 기획한다.
- 와이어프레임과 디자인 시안을 만든다.
- 개발자가 이를 해석해 구현한다.
- 구현 결과를 보며 다시 기획과 디자인을 수정한다.
규모가 큰 프로젝트에서는 필요한 과정이다. 그러나 빠른 검증이 중요한 PoC에서는 각 단계의 전달과 확인 자체가 부담이 되기도 한다.
그래서 이번에는 기획과 디자인을 완전히 분리하지 않았다. 아이디어를 설명하면서 동시에 화면을 만들고, 실제로 동작하는 결과물을 보며 기획을 구체화하기로 했다.
1. 기획과 디자인을 한 번에 진행하다
처음부터 Flutter로 개발하지는 않았다.
웹 환경은 화면을 빠르게 만들고 수정하기에 유리하다. 생성형 AI 역시 HTML, CSS, React 같은 웹 기술을 활용한 UI 생성에 비교적 능숙하다.
먼저 서비스의 목적과 필요한 화면을 자연어로 설명했다.
- 서비스의 핵심 사용자는 누구인가?
- 사용자가 첫 화면에서 무엇을 확인해야 하는가?
- 핵심 기능까지 몇 단계로 이동해야 하는가?
- 버튼과 정보의 우선순위는 어떻게 구성할 것인가?
- 모바일 화면에서는 어떤 형태로 보여야 하는가?
AI가 생성한 첫 결과물은 당연히 완벽하지 않았다. 하지만 중요한 것은 완벽한 디자인이 아니었다. 머릿속에만 있던 아이디어를 즉시 화면으로 확인할 수 있다는 점이었다.
“이 버튼은 사용자가 놓칠 수 있으니 더 강조하자.”
“여러 메뉴를 보여주기보다 하나의 흐름에 집중하자.”
이런 판단을 문서나 정적인 와이어프레임이 아니라, 브라우저에서 실제로 동작하는 화면을 보면서 내릴 수 있었다.
기획서를 먼저 완성하고 디자인을 시작한 것이 아니라, 화면을 만드는 과정 자체가 기획 과정이 된 셈이다.
2. 웹 목업은 버리는 결과물이 아니었다
웹으로 만든 결과물은 단순한 이미지가 아니었다. 버튼을 누르고, 화면을 이동하고, 데이터를 입력해 볼 수 있는 인터랙티브 목업이었다.
덕분에 정적인 디자인만으로는 발견하기 어려운 문제도 초기에 확인할 수 있었다.
- 사용자가 다음에 무엇을 해야 하는지 알기 어렵다.
- 앞뒤 화면의 정보가 중복된다.
- 핵심 기능까지 너무 많은 클릭이 필요하다.
- 입력 과정이 예상보다 길다.
- 모바일 화면에서 중요한 정보가 아래로 밀린다.
이런 문제를 Flutter 개발 이후에 발견하면 화면 구조와 상태 관리까지 함께 수정해야 할 수 있다. 반면 웹 목업 단계에서는 비교적 부담 없이 구조를 바꿀 수 있었다.
결국 웹 목업은 보여주기 위한 데모가 아니라, Flutter 구현 전에 시행착오를 흡수하는 설계 도구가 되었다.
3. 빠른 시작의 대가, QA에서 만난 부채
프로젝트를 진행하며 초반 작업 속도는 확실히 빨랐다. 기획을 화면으로 옮기고 주요 기능을 구현하는 단계까지는 바이브 코딩의 장점이 분명하게 느껴졌다.
문제는 QA에 들어가면서부터였다.
초반에 빠르게 작업한 만큼, QA 단계에서 그 부채를 돌려받는 느낌이 강했다.
화면이 많아지고 비슷한 컴포넌트가 늘어나자 디테일한 수정이 점점 어려워졌다. 특정 영역의 폰트나 간격만 바꾸려고 했는데 엉뚱한 위치까지 함께 수정되거나, AI가 정확한 대상을 찾지 못해 같은 요청을 두세 번 반복하는 일도 있었다.
기존 QA에서는 수정할 위치를 표시한 이미지가 큰 도움이 됐다. 그러나 바이브 코딩이 섞인 프로젝트에서는 이미지가 있어도 코드 속 정확한 컴포넌트와 속성을 찾는 데 시간이 더 걸렸다.
돌이켜보면 문제는 AI가 코드를 작성했다는 사실 자체보다, AI와 사람이 함께 참고할 공통 기준 없이 빠르게 결과물부터 쌓았다는 점에 가까웠다.
4. 속도를 유지하려면 최소한의 작업 규칙이 필요했다
이 문제를 해결하기 위해 다음 작업부터는 개발을 시작하기 전에 최소한의 틀을 먼저 정해 두어야 한다고 판단했다.
모든 값을 처음부터 완벽하게 고정하자는 의미는 아니다. 큰 기준을 먼저 만들고, 변경이 필요할 때 관련 화면에 한 번에 반영될 수 있는 구조를 준비하자는 것이다.
기본 본문 폰트를 16px로 정했다면 이유 없이 15px짜리 본문이 새로 생기지 않아야 한다.
간격 기준을 12px로 정했다면 특정 화면만 임의로 15px을 사용하는 방식도 피해야 한다.
프로젝트 성격에 따라 값은 달라질 수 있지만, 최소한 다음 항목은 작업 전에 정의해 두는 편이 좋다.
- 디자인 해상도 기준: 예) 모바일 360 × 800, 웹 콘텐츠 안전 영역 1200px
- 폰트 체계: 본문, 보조 설명, 제목 등의 크기와 굵기
- 의미 기반 색상 토큰: primary, surface, error처럼 역할 중심으로 정의
- 간격 기준: 반복해서 사용할 spacing scale
- Radius: 카드, 버튼, 입력창 등에 적용할 모서리 기준
- Elevation과 Shadow: 계층을 표현하는 그림자 규칙
- 아이콘 규칙: 아이콘 크기와 내부 패딩
- 상태 화면 원칙: 로딩, 빈 화면, 오류 상태의 기본 형태
- 고유 네이밍: 컴포넌트와 하위 요소에 예측 가능한 이름 사용
특히 네이밍은 타협하지 않기로 했다
AI가 임의로 만든 랜덤한 이름이 쌓이면, 이후 수정 요청에서 대상을 특정하기가 어려워진다. 그래서 컴포넌트와 내부 요소의 이름만큼은 사람이 이해할 수 있고 중복되지 않는 방식으로 정할 필요가 있었다.
이상적인 수정 요청은 다음처럼 대상과 디자인 토큰을 정확하게 가리킬 수 있어야 한다.
“Card1의 Card1_subTitle 폰트 크기를 font2로 변경하고, 색상 토큰은 main2를 적용해 줘.”
이런 요청이 가능하려면 코드, 화면, 디자인 문서가 같은 언어를 사용해야 한다. 결국 필요한 것은 거대한 규정집이 아니라, AI가 작업을 시작하기 전에 읽을 수 있는 짧고 명확한 실행 가이드였다.
다음 프로젝트에서는 이 가이드를 먼저 만들고, 작업 중 발견한 예외를 계속 보완하는 방식으로 운영해 볼 생각이다. 이렇게 하면 바이브 코딩의 초반 속도를 유지하면서 QA 단계의 반복 수정도 줄일 수 있을 것이다.
5. 검증된 웹 목업을 Flutter로 옮기다
웹 목업을 통해 화면 구조와 사용자 흐름이 어느 정도 정리된 뒤 Flutter 마이그레이션을 시작했다.
여기서 중요한 점은 웹 코드를 그대로 Flutter 코드로 변환하지 않았다는 것이다. 웹과 Flutter는 UI를 구성하는 방식도 다르고, 상태 관리와 라우팅, 반응형 화면을 처리하는 방법도 다르다.
대신 웹 목업에서 검증한 내용을 구현 기준으로 활용했다.
- 화면의 전체 레이아웃
- 사용자의 이동 흐름
- 컴포넌트의 우선순위
- 버튼과 입력 요소의 동작
- 로딩·오류·빈 화면 등의 상태
- 모바일 환경에서의 정보 배치
이미 눈으로 확인한 결과물이 있었기 때문에 Flutter 개발 과정에서 “어떤 화면을 만들어야 하는가”를 다시 고민하는 시간이 크게 줄었다.
AI에게도 전체 앱을 한 번에 만들어 달라고 하기보다, 화면과 기능을 작은 단위로 나누어 구현하도록 했다. 생성된 코드는 직접 실행하고 검토하면서 프로젝트 구조에 맞게 수정했다.
AI가 코드를 만들더라도 직접 확인한 항목
- 위젯이 불필요하게 거대해지지 않았는가?
- 공통 컴포넌트를 적절히 분리했는가?
- 상태와 UI가 과도하게 결합되지 않았는가?
- 예외 상황이 처리되어 있는가?
- 임시 데이터와 실제 로직이 구분되어 있는가?
- 나중에 수정하기 어려운 코드가 만들어지지 않았는가?
바이브 코딩이 구현 속도를 높여 주는 것은 사실이지만, 생성된 코드의 품질까지 자동으로 보장해 주는 것은 아니다.
6. 개발은 끝났지만 문서가 남지 않았다
빠르게 만드는 데 집중하다 보면 흔히 발생하는 문제가 있다. 결과물은 있는데, 그 결과물이 어떤 기준으로 만들어졌는지 설명하는 문서가 부족하다는 점이다.
PoC 단계에서는 큰 문제가 없어 보일 수 있다. 개발자 본인이 화면 구조와 의도를 모두 기억하고 있기 때문이다. 그러나 시간이 지나거나 새로운 사람이 프로젝트에 참여하면 상황이 달라진다.
- 어떤 화면이 최신 버전인지 알기 어렵다.
- 사용된 색상과 여백의 기준을 찾기 어렵다.
- 비슷한 컴포넌트가 조금씩 다르게 구현된다.
- 수정할 때마다 실제 앱을 실행해야 한다.
- 기획자와 디자이너가 개발 코드를 기준으로 소통해야 한다.
바이브 코딩으로 개발 속도를 높였지만, 유지보수를 위해서는 결국 화면과 디자인 기준을 정리할 필요가 있었다.
7. 브라우저 익스텐션으로 Figma 문서화하기
이 문제를 해결하기 위해 브라우저 익스텐션을 활용했다.
Figma 앱이랑 mcp를 이용하면 더 쉽게할 수 있지만, 그러한 유로 서비스를 활용할 환경이 주어지지 않아서 브라우저에서 작업하기로 했다.
방법은 간단하다. ChatGPT App에서 프로젝트를 타겟하고 브라우저에 피그마를 띄우고 옮겨달라고하면 된다.
Figma에서는 다음 내용을 중심으로 정리했다.
- 화면별 사용자 흐름
- 공통으로 사용되는 UI 컴포넌트
- 색상과 타이포그래피
- 버튼과 입력 요소의 상태
- 주요 간격과 레이아웃 규칙
- 개발 과정에서 변경된 화면
- 구현 시 참고해야 할 설명
물론 브라우저 화면을 Figma로 가져온 결과가 항상 완벽한 것은 아니다. 오토 레이아웃이나 레이어 이름, 컴포넌트 구조는 추가로 정리해야 했다.
그럼에도 처음부터 모든 화면을 Figma에서 다시 그리는 것보다 훨씬 빠르게 문서화의 출발점을 만들 수 있었다.
이번 테스트는 Figma MCP를 사용한 방식이 아니었다. ChatGPT 브라우저 익스텐션으로 구현된 웹 화면을 캡처하고 변환하는 방식으로 진행했으며, 자세한 가이드 없이 AI 작업만 약 30분 정도 실행했다.
완벽하게 정리된 디자인 시스템이라기보다, 개발 완료 후에도 기존 웹 결과물을 활용해 Figma 문서화의 초안을 만들 수 있는지 확인한 실험에 가깝다. 실제 결과를 바탕으로 팀에 필요한 수준과 정리 범위를 판단해 보면 좋겠다고 생각했다.
개발을 위해 만든 하나의 결과물이 다음 단계의 기준이 되고, 다시 유지보수를 위한 문서의 재료가 되었다.
바이브 코딩이 특히 효과적이었던 부분
① 아이디어를 곧바로 화면으로 확인할 수 있었다
추상적인 대화가 빠르게 구체적인 결과물로 바뀌었다. 설명만으로 논의할 때보다 서로의 생각을 맞추기 쉬웠다.
② 시행착오를 개발 초기에 처리할 수 있었다
웹 목업 단계에서 사용자 흐름과 화면 구조를 조정해, Flutter 구현 이후 큰 폭으로 수정하는 일을 줄일 수 있었다.
③ 의사소통의 기준이 명확해졌다
“조금 더 깔끔하게” 같은 모호한 표현 대신, 실제 화면을 보면서 변경할 부분을 구체적으로 이야기할 수 있었다.
④ 하나의 결과물을 다음 단계에서도 재사용했다
웹 목업은 검증용 프로토타입에서 끝나지 않고 Flutter 개발과 Figma 문서화의 기준으로 이어졌다.
그렇다고 모든 것을 AI에게 맡길 수는 없었다
바이브 코딩은 빠르지만 방향을 정해 주지는 않는다.
어떤 문제를 해결해야 하는지, 사용자에게 어떤 경험을 제공할 것인지, 생성된 결과가 프로젝트의 목적에 맞는지는 여전히 사람이 판단해야 한다.
AI가 만든 화면은 겉보기에는 그럴듯하지만 실제 사용자 흐름과 맞지 않을 수 있다. 생성된 코드 역시 당장은 동작하더라도 유지보수하기 어려운 구조일 수 있다.
그래서 사람의 역할은 줄어들었다기보다 달라졌다고 느꼈다.
- 무엇을 만들 것인가?
- 어떤 단위로 요청할 것인가?
- 결과물에서 무엇을 검증할 것인가?
- 어떤 코드는 수정하거나 버려야 하는가?
- 이후 유지보수까지 고려하면 어떤 구조가 적절한가?
직접 모든 코드를 입력하는 시간은 줄었지만, 결과를 평가하고 다음 방향을 정하는 판단은 오히려 더 중요해졌다.
마치며
이번 PoC를 통해 바이브 코딩은 단순히 코드를 빠르게 생성하는 방법이 아니라는 것을 느꼈다.
기획을 화면으로 바꾸고, 화면을 실제 제품으로 옮기고, 완성된 결과를 다시 유지보수 가능한 문서로 정리하는 과정 전체에서 활용할 수 있었다.
웹에서는 빠르게 실험하고,
Flutter에서는 제품에 맞게 구현하고,
Figma에서는 다음 작업자를 위해 맥락을 남긴다.
바이브 코딩은 개발 과정 자체를 없애 주지 않는다. 대신 각 단계 사이에서 반복되던 번역과 전달 작업을 줄여 준다.
중요한 것은 AI가 얼마나 많은 코드를 작성했느냐가 아니다. 아이디어에서 검증 가능한 결과물까지 얼마나 빠르게 도달했고, 그 결과를 얼마나 지속 가능한 형태로 남겼느냐다.
이번 경험을 통해 얻은 결론은 분명하다.
바이브 코딩은 프로토타입을 빠르게 만드는 요령에 그치지 않는다. 잘 활용하면 기획, 디자인, 개발, 문서화를 하나의 연속된 흐름으로 연결할 수 있는 꽤 실용적인 작업 방식이다.
댓글