AI로 기획/개발/디자인까지 혼자 MVP 출시하기(2)
바이브코딩 툴 디깅하기
*혹시 1편을 보지 않으셨다면, 아래 링크를 통해 1편부터 보시길 추천드립니다.
화면 설계하기
사업개발팀의 요청사항과 저의 기획 방향성에 따라 기능 정의 후 SiteMap과 UserScenario를 간단히 정리했습니다. 구조가 매우 간단하여 IA, UserFlow 등은 생략했습니다.
간단한 SiteMap과 차트 형태의 UserScenario SiteMap 옆에 각 화면에 필요한 기능과 표시되어야 할 정보들을 영역별로 정리해 줍니다. 오른쪽은 유저 시나리오를 단계별로 정리한 것입니다. 글로 정리하면 아래와 같습니다.
#UserScenario
(상황) 운전자가 차량 관리 목적으로 연료첨가제 상품군의 구매를 고민합니다.
(행동) 검색 엔진에서 연료첨가제 관련 키워드 검색하고, 연료첨가제 비교 사이트에 진입해 상품의 항목별 후기를 비교합니다.
(결과) 구매의사가 있는 상품을 결정한 뒤 판매 채널로 이동하여 구매 전환이 일어납니다.
화면 구현하기
이제 서비스의 화면을 디자인합니다. 우선 바이브 코딩 툴의 실무 활용성을 파악하기 위해 지금까지 정리된 기획 내용만으로 프롬프트를 작성해서 구현해 보았습니다. V0, Lovable, Figma Make 3개의 툴을 비교했으며, 한국어로 프롬프트를 작성하고 GPT로 보완 후 최종 프롬프트를 정리하여 동일하게 툴별로 웹페이지 구현을 요청했습니다.
결과물을 보면서 툴 별로 짧게 특장점을 정리해 보았습니다. 수정 없이 1회 프롬프트만으로 완성된 결과물에 대한 비교입니다.
바이브코딩 프런트 구현 비교 (V0, Lovable, Figma Make)V0 : 디자인 적으로 아쉬운 부분이 많았습니다. 기능면에서 검색과 필터를 잘 구현했지만 동작하지 않았습니다. 컴포넌트의 레이아웃 정리가 다소 부족해 시각적 그룹핑이 안 되는 부분이 있었습니다. 또 적용된 디자인 시스템의 Primary Color가 붉은 톤으로 어색한 부분이 있었고, 색상 그림자 같은 요소의 시각적인 위계 구현이 부족했습니다.
Lovable : 가장 베스트 시안을 구현했습니다. 기능면에서 검색, 필터, 페이지간의 이동 모두 작동했으며, 색상과 그림자 같은 시각적인 위계도 잘 표현했습니다. 특히 텍스트의 간격이나 컴포넌트의 레이아웃을 가장 잘 표현해서 시각적인 불편함이 없었습니다.
Figma Make : 러버블과 비슷했지만 추구하는 기본 디자인시스템이 러버블과는 다르게 굉장히 미니멀했습니다. 기능과 페이지 이동 모두 잘 작동했지만, 필터 부분의 UX구현이 VO와 러버블보다 완성도가 낮았습니다.
한 번의 프롬프트로 완성된 결과물을 봤을 때는 러버블이 가장 완성도 높은 웹페이지를 구현해 주었습니다. 이후 러버블에서 개선이 필요한 부분을 프롬프트를 통해 반복적으로 수정이 가능했지만, 여러 번의 프롬프트 수정으로 시행착오가 많았고, 미세하게 레이아웃이 마음에 들지 않은 부분이 다수 있었습니다. 이런 부분의 디자인을 직접 수정할 수도 없고, 코드 레벨에서 직접 수정하는 것은 익숙하지 않다 보니 오히려 진행에 허들이 생겼습니다.
결과물의 완성도는 생각보다 높았지만 의도대로 수정하기가 쉽지 않았기 때문에, 현재는 100% 텍스트 프롬프트만으로 원하는 방향으로 웹페이지를 구현하기 어렵다고 결론을 냈습니다.
이후 디자인과 코드를 동기화하여 작업을 할 수 있는 MCP(Multi-Context Protocol)를 활용해 작업하기로 합니다. 이렇게 하면 피그마에서 디자인을 수정함에 따라 커서의 코드에 반영이 가능하기 때문에 디자인 관점에서 코드 수정이 가능해집니다.
MCP 활용하기
와이어프레임 설계와 프레임 네이밍 피그마에서 Lo-fi 와이어프레임을 작성한 뒤, 몇 가지 중요한 컴포넌트만 디자인을 진행하였고 해당 디자인을 기준으로 커서에게 웹페이지를 구현해 달라고 요청했습니다. 혹여 일정 부분이 정확히 구현되지 않아도 피그마에서 문제가 있는 부분의 프레임을 선택하고 ‘이 부분 간격과 레이아웃 다시 조정해 줘’라고 커서에게 요청하면서 디테일한 수정이 가능합니다.
단 수정 시 프레임명이 비슷하면 간혹 오류가 날 수 있으니, 우측 이미지처럼 프레임명을 잘 정리해 줬습니다. 이렇게 정리해 둔 프레임명은 데이터를 하드코딩 할 때도 유용하게 쓰입니다. 1편에서 정리한 데이터들을 알맞은 위치에 매칭시키기 위해 프레임명과 DB의 칼럼명을 똑같이 네이밍 한 후 커서에게 매칭시켜 달라고 요청했습니다.
서버 없이 정적 배포를 진행할 예정이기 때문에 데이터는 모두 수기로 넣어줘야 했는데, 이렇게 명령하면 DB에 정리된 모든 상품 정보를 한 번에 입력할 수 있습니다.
정제된 데이터를 빠르게 하드코딩하기 위해 프레임과 DB구조 매칭해당 방법으로 데이터 입력까지 마친 후, 시각적으로 보완할 부분들을 정리해서 커서에게 수정을 명령했습니다. 이렇게 전체 구조가 잡힌 상태에서 디테일한 부분에 대한 개선이나, 확장, 변경 등을 요청했을 때 요구 사항대로 굉장히 잘 구현해 줘서 만족스러웠습니다.
개선사항 프롬프트 예시
�‘상세 보기’ 버튼의 위계를 색상으로 더 강조해 줘 (개선)
� Category 버튼의 텍스트 앞에 맥락에 맞는 아이콘을 추가해 줘 (확장)
�카드형 UI를 3열 배열 반응형에 알맞게 조절해 줘 (구조 변경)
프롬프트만으로 디자인 개선하기커서에게 이렇게 단편적인 개선을 명령하고 이게 더 좋은 디자인인가? 이런 인터렉션이 더 좋은 고객 경험인가? 판단하면서 디자인을 반복 개선했습니다. 이 과정에서 제가 생각하지 못한 hover 인터렉션은 추가해 주거나, 시각적 위계를 고려해 포인트 색상을 잡아주는 등 결과적으로 더 나은 부분이 있었습니다. 바이브 코딩의 이런 효용이 앞으로 MVP 기획할 때, 굉장히 많은 도움이 될 것 같습니다. 똑같은 리소스로 만든 MVP의 완성도가 훨씬 높아질 테니까요.
이렇게 프론트 구현이 최종적으로 마무리되었습니다. 다음 편은 최종 완성본 공유와 레슨런을 총정리하는 내용으로 마무리하려고 합니다. 빠르게 마지막 편 써오겠습니다! 조금만 기다려주세요.
궁금한 부분이 있으시거나, 커피챗이 필요하다면 언제든지 편하게 댓글 또는 이메일로 요청해 주세요.
moo_tae@kakao.com
