바이브코딩, 디자인은 이렇게 시작하세요
비개발자 PM 취준생의 바이브코딩 기록/레슨런 #6
바이브코딩 하는 비디자이너 주목!
기획만 준비되어 있다면 디자인 단계는 꽤 효율적으로 진행할 수 있답니다.
이번 글에서는 바이브코딩 시 디자인 단계를 최대한 쉽게 해낼 수 있는 방식을 공유하고자 한다.
‘쉽게’라 함은 다음과 같다.
디자인 스킬 없이 UI 디자인을 만들어낼 수 있고
개발이나 퍼블리싱 지식 없이도 이 디자인을 작동하게 만들 수 있는
시간 측면에서 가장 효율적인 방법
디자인 전문가가 아닌 기획자로서 꽤 많은 시행착오를 겪으며 터득한 방식이기에 나와 같은 비디자이너라면 얻어갈 점이 있을 것이다.
들어가기 전에
비개발자라면 바이브코딩 시작하기 전 기획부터 준비해야 한다. 아직이라면 이전 글부터 읽어볼 것을 권한다.
기획이 끝났다면 실제 목적조직이 굴러가듯 개발과 디자인을 병행하면 된다.
그중 디자인 단계의 핵심 포인트부터 짚어보자.
하나,
우리(비디자이너, 비개발자)가 할 것은 디자인과 퍼블리싱을 동시에 하여, 각 화면들의 프론트엔드 코드를 미리 준비해두는 일이다. 퍼블리싱이란 피그마 등으로 만들어둔 디자인을 코드로 옮기는 작업을 말한다.
둘,
무조건 클로드를 활용한다. Cursor 안에서 API를 사용하는 게 아닌, 클로드 웹사이트에서 진행한다. 이는 클로드가 25년 12월 기준 아래 사진처럼 코드를 실시간으로 시각화해서 보여 주는 유일한 LLM이기 때문이다.
마지막으로,
나는 크롬 익스텐션을 만들고 있기 때문에 적응형 디자인을 기준으로 설명한다. 반응형 디자인은 아직 도전할 엄두를 내지 못했다(성공한 분 계신가요). 바이브코딩이 처음이라면 적응형 디자인으로 시작해보는 것을 추천한다. 품이 들어갈 다른 부분들이 충분히 많으니 아낄 수 있는 시간은 최대한 아끼자.
좀더 자세한 내용은 4편에 나와 있으니 참고 바란다.
1단계: 제품의 디자인 컨셉 잡기
1. 원하는 디자인 컨셉을 말로 표현한 글이나 레퍼런스 이미지를 준비한다.
2. 미리 만들어둔 와이어프레임 스크린샷과 함께 클로드에 첨부한다.
3. ‘~~한 디자인 컨셉으로 해당 와이어프레임을 디자인해줘’라고 명령한다.
4. 디자인이 뚝딱 나온다.
5. 나온 디자인 컨셉이 마음에 들지 않는다면 몇 번 더 시도하자.
마음에 드는 컨셉의 디자인이 나왔다면 이게 바로 내 제품의 디자인 원칙이 되는 거다.
디자인 컨셉을 어떻게 잡아야할지 모르겠더라도 괜찮다. 이렇게 즉흥적으로 쓴 프롬프트로도 괜찮은 스타일을 얻었다.이때 주의할 점 한 가지가 있다. 내가 만들고자 하는 화면 외의 요소들이 구현되어 있지는 않은지 확인해야 한다는 것이다.
여기서 코드가 구현된 모습을 보자. 얼핏 보기엔 내가 만들려는 하얀 컨테이너 안에 요소들이 잘 들어가 있는 것 같다. 그러나 그 외에도 배경에 색이 들어가있고 투명한 원이 여기저기 보인다.
이런 것들은 모두 클로드가 임의로 만든 디자인 요소이다. 이렇게 실제 서비스에 들어가지 않을 요소가 포함된 코드는 꼭 미리 확인하고 제거해두자.
애니메이션도 마찬가지다. 안 쓸 거면 빼자. 실수로 넣었다간 꽤 골치 아파진다.
2단계: 화면 만들기
이렇게 디자인 스타일이 반영된 첫 화면이 나왔고,
이 버튼을 누르면 javascript(또는 다른 언어)로 쓰인 우리의 프론트엔드 코드를 확인할 수 있다.
이걸 가지고 다른 화면들을 하나씩 제작하면 된다.
1. 아까 결과물로 나왔던 코드를 복사한다.
2. 클로드에서 새로운 대화를 시작하고 입력창에 코드를 붙여넣는다
3. ‘이 코드랑 완전히 동일한 포맷으로 다음 와이어프레임을 디자인해줘.’ 라는 프롬프트와 함께 와이어프레임 스크린샷을 첨부한다.
그리고 본격적인 화면 제작 전 아래 두 가지를 꼭 미리 계획해 두자.
1. 화면 간 전환 애니메이션
클로드에게 디자인을 맡기면 애니메이션도 마음대로 넣어 버린다. 이게 의도와 맞지 않으면 나중에 코드들을 이어붙일 때 문제가 생기기 때문에 미리 계획을 세워 둘 것을 권한다.
기본적인 전환 애니메이션 정도는 클로드가 어렵지 않게 구현하니 최소한의 것들로 구성하자. 복잡한 애니메이션은 시간 잡아먹는 주범이니 최대한 피해야 한다.
2. 코드 파일을 어떻게 구성할 것인가
지금까지는 화면 하나당 코드파일 하나를 생성한다는 전제 하에 설명했다. 그러나 사실 화면 2~3개 정도까지는 하나의 코드 파일에 넣어도 괜찮다. 실제로 슬라이드 등 전환 애니메이션은 그렇게 했을 때 더 구현하기가 쉽다(AI 피셜이라 사실과 다를 수 있습니다)고 한다.
나도 처음에는 화면 하나당 파일을 하나씩 생성하다가 이후에는 플로우별로(ex. 온보딩 플로우 등) 파일을 만들어 화면을 두세 개씩 묶어두었다.
3단계: 디테일 수정하기
필요 시 디테일을 수정한다.
사실 시간이 제일 많이 드는 파트가 바로 여기다. 하나의 프롬프트는 내 머릿속 생각의 반의 반도 담지 못하기 때문이다. 그래서 AI 퍼블리셔와 계속해서 커뮤니케이션을 하며 머릿속 그림을 구현해내야 하는 것이다.
이때 염두에 두어야 할 중요한 포인트는 ‘디테일에 대한 집착을 포기하자’이다.
디자인 철학이 확고한 사람일수록 이 과정이 다소 답답할 수 있다. 클로드가 제멋대로 디자인한 결과물을 가지고 시작해야 하지, 개발 지식 없어서 코드를 직접 수정하지도 못하는 노릇이지.. 때문에 포인트 하나하나에 대한 변경사항을 AI가 알아들을 수 있는 명령으로 언어화해야 하는 것이다. 이 때문에 수정 한 번에 걸리는 시간이 일반적인 업무 방식보다 훨씬 길고 비효율적이다. 여기에다 디테일에까지 집착하기 시작하면 시간과 토큰이 쭉쭉 닳기 마련이다.
사실 이건 내 경험담이고, 1인 사이드프로젝트를 하고 있다면 최대로 경계해야 할 문제이기도 하다.
이런 상황을 최대한 겪지 않으려면 프로젝트 초반에 가치의 우선순위를 잘 설정해두는 게 중요하다. 항상 우선순위와 최종 목적에 따라 움직여 최대 효율을 내는 것이 PM의 미덕이지 않은가?
특히 취준생에게는 시간이 가장 큰 가치를 지닌 자원이다. 그러니 디자인이 내 취향에 맞는지, 토스처럼 유려한 UX가 구현되었는지와 같은 기준은 당분간 후순위에 두고 혼자 일하더라도 확고한 원칙을 세워 일해야겠다는 생각이 든다.
이렇게 비디자이너가 AI로 디자인하는 방식을, 항상 그렇듯 [바이브코딩의 관점]에서 꽤 상세하게 소개해 보았다. 여기까지 읽어주신 분들이라면 틀림없이 무라도 썰 준비가 되어 계실 테니 어렵더라도 꼭 시도해 보시길 바란다.
다음 이야기로는 튼튼한 프로젝트의 초석을 마련하는 개발 구조를 잡는 법, 그리고 디자인과 개발을 효율적으로 멀티태스킹하는 법에 관한 글들을 순서대로 발행하고자 한다.
이 외에도 글에 적힌 내용에 대해 궁금한 점이 있다면 자유롭게 댓글 남겨주세요! 해당 부분에 대한 답변을 또 새로운 글로 발행해 보도록 하겠습니다.
