글을 시작하기에 앞서 제가 경험한 바이브 코딩은 다른 디자이너분들이 직접 프로젝트를 만들면서 시도한 경우와는 조금 결이 다르다고 미리 알립니다. 이번 작업의 출발점은 자사 서비스 중 오래된 구성의 웹페이지를 최신 환경에 맞게 업데이트하는 것이었습니다. 완전히 새로운 기획을 하는 대신 현재 메인으로 사용 중인 웹페이지와 구조, 스타일을 맞추고, 기술 스택을 기존 웹 구성에서 React 기반 환경으로 전환하는 것에 집중했습니다.
이 과정에서 자연스럽게 제가 직접 코딩을 시도하게 되었는데 디자인–개발 간 커뮤니케이션을 빠르게 하고, 수정과 반영을 반복하는 사이클을 능동적으로 관리하기 위한 선택에 가까웠습니다. 개편 작업을 하다 보면 바로 확인하고 싶은 UI 조정들이 많아지기 때문에, 직접 다루는 편이 전체 흐름에 더 도움이 되었거든요.
많고 많은 AI 툴 중에서 하나 선택하기
이번 작업에서 별도의 무거운 기획 단계나 복잡한 개발 프로세스가 필요한 건 아니었습니다. 기본적인 페이지 구성은 이미 어느 정도 갖춰져 있었고, 제가 필요했던 건 바로바로 코드를 만져보고 화면에서 결과를 확인할 수 있는 기능이었어요. 그래서 별도의 셋업에 시간을 쓰는 대신, 빠른 실험과 즉각적인 화면 반영이 가능한 Lovable을 선택했습니다. Lovable은 바이브 코딩에 최적화된 환경이라 이번 작업의 목적과도 잘 맞았고, 디자인과 개발 사이의 전환을 자연스럽게 이어주는 데도 큰 도움이 되었습니다.
- 명령한 구조가 바로 화면에 표시되고
- 간단한 수정 요청으로도 바로 조정 가능하고
- 파일 구조 고민 거의 없음
많은 분들이 Claude도 적극적으로 사용하지만, 이번 작업에서는 Claude 사용 대신 Gemini를 사용해 초안과 프롬프트를 빠르게 정리한 뒤, 그 결과물을 바로 Lovable에서 화면으로 구현해 나가는 방식을 택했습니다. 기획 단계가 크지 않았던 만큼 즉각적으로 코드를 만들어보는 흐름이 중요했기 때문이에요. 효율과 작업 속도에 맞춰 Gemini, Lovable 조합을 선택했다고 보면 될 것 같아요.
당연한 이야기지만, 어떤 프롬프트냐에 따라 결과물은 전혀 달라집니다.
“ㅇㅇ한 느낌으로 ㅇㅇ하게 ㅇㅇ해줘”처럼 AI에게 많은 부분을 맡기는 간단한 프롬프트 작성으로도 꽤 그럴싸한 결과물을 만들어냅니다. 그래도 역시 디자이너인지라, 그 결과물이 약간 아쉽게 느껴지더라고요. 그래서 Gemini를 활용해 아예 섹션 안에 들어갈 내용을 상세하게 넘버링하여 프롬프트를 입력했습니다. 각 섹션별 내용과 함께 어떤 스타일로 배치하면 좋을지까지 함께 명령했습니다. 그럼 아무리 섹션이 많은 페이지여도 웬만한 구성은 프롬프트로도 어느 정도 정리가 됩니다. 이 프롬프트로 바이브 코딩을 실행해보면 놀랍게도 그 많은 양의 정보를 꽤나 깔끔하게 처리하는 모습을 볼 수 있었습니다.
스타일은 어떻게 적용했나?
이번 개편 작업은 완전히 새로운 디자인을 만드는 프로젝트가 아니었기 때문에, 사용할 스타일 역시 어느 정도 범위가 정해져 있었습니다. 기존 웹사이트와 완전히 다른 분위기로 흐르면 안되니까요. 기본적인 무드와 핵심 요소만 제가 직접 정리해 입력했습니다. 다만 모든 속성을 하나하나 세세하게 지정하진 않았습니다. 처음부터 너무 디테일하게 통제하기보다는 초반은 AI가 스스로 풀어내도록 학습한 후, 수정을 진행할 때 전체적인 톤앤매너와 놓치면 안 되는 핵심 스타일만 명확히 제시해서 보충하는 방식으로 진행했습니다.
제가 정의한 기준은 크게 이런 방향성이었습니다.
- 강조와 정보 구조가 명확하게 드러날 것
- 모든 페이지에서 스타일과 리듬이 일관될 것
- 인터랙션이 어색하지 않고 서비스의 성격과 맞을 것
그리고 기존 웹사이트의 브랜드 감각을 잃지 않기 위해 필요한 CSS 요소만 최소한으로 정리해 먼저 공유했습니다.
- 컬러 : 메인/서브 컬러, 강조색, 배경 톤, 텍스트 대비
- 박스 스타일 : border 굵기와 radius 정도, 기본적인 shadow 깊이
- 레이아웃 여백 : 필요한 경우에만 margin·padding 따로 수정함
즉, 전체적인 방향성과 브랜드 무드만 확실히 해주고, 나머지는 AI가 자연스럽게 구현하도록 맡긴 방식이었습니다.
그리고 또 테스트?
Lovable이 생성한 화면을 그대로 신뢰하기보다는, 처음에 제가 작성했던 기획 의도(프롬프트)가 올바르게 전달되고 있는지 점검해보고 싶었습니다. 그래서 화면 생성 후 검토 과정에서 Gemini를 한 번 더 참여시켰습니다. Gemini를 통해 정제된 프롬프트를 Lovable에 넣어 화면을 생성한 뒤, 다시 Gemini에게 그 결과물을 검토하게 하는 방식입니다. Gemini가 기획자이자 리뷰어가 된 셈입니다.
결과적으로 이 프로세스가 꽤 효과적이었습니다. Lovable이 만들어낸 화면이 제가 의도한 메시지를 올바르게 구현했는지, 흐름이나 배치에서 사용성이 떨어지는 부분은 없는지 등을 Gemini가 기획 관점에서 진단해주면서, 일종의 상호 검증 루틴이 만들어졌습니다. 덕분에 제가 혼자 작업할 때보다 훨씬 더 빠르게 누락을 발견하고, 전체 완성도를 안정적으로 끌어올릴 수 있었습니다.
개발자없이 여기까지 하다니…
이번 작업에서 가장 놀란 건 개발자의 직접적인 도움 없이도 화면 구조와 코드가 꽤 안정적으로 정리되었다는 점이었습니다. 물론 복잡한 기능이나 백엔드 로직은 개발자의 손길이 반드시 필요하지만, 적어도 이번처럼 적은 기능과 구조가 명확한 페이지라면 프론트 레벨에서는 AI만으로도 기본 골격을 만들어내더라고요.
특히 인터랙션 부분이 가장 편했습니다. “가벼운 애니메이션으로 자연스럽게 전환되면 좋겠다.” “mouse over를 하면 hover 효과를 그림자 강조가 느껴지게 해달라.”와 같이 추상적인 표현만으로도 Lovable이 꽤나 제대로 해석해 어느 정도 구현해주는 것을 보면서 예전 같았으면 구체적인 수치까지 요청해야 했던 작업들이 훨씬 부드럽게 진행된다고 느꼈습니다. 확실히 바이브 코딩을 통한 프론트 생산성은 정말 크게 달라지긴 했습니다.
어쩌면 디자이너에게도 또 다른 기회
이번 프로젝트는 전체 작업 효율을 크게 끌어올린 경험이었습니다. 기획 초안 정리, 화면 구성, 인터랙션 확인까지 이어지는 과정을 이전보다 훨씬 빠르게 눈으로 확인하고 수정할 수 있었습니다. 디자이너가 구상한 내용을 즉시 화면으로 검증하는 것은 생산성 측면에서 상당히 큰 장점이었습니다. 또한 개발자와의 협업 방식에서도 변화가 있었습니다. 개발자의 전문적인 판단이 필요한 부분은 여전하지만 프론트 구조가 어느 정도 정리된 상태로 전달되다 보니 세부적인 소통에 소요되던 시간이 자연스럽게 줄었습니다.
바이브코딩이 디자이너에게 반드시 필요한 기술은 아니더라도, 직접 경험해보는 것이 확실히 시야가 넓어집니다. 화면 구조나 인터랙션 구현 방식에 대한 이해가 늘어나면 디자인 과정에서도 판단이 더 명확해지고, 개발자와의 커뮤니케이션 역시 자연스럽게 수월해집니다. 디자인을 바라보는 관점이 한 단계 확장된 느낌이 들었습니다. 이번 작업은 빠르게 결과물을 내보이는 것도 중요했지만, 결과적으론 향후 협업 방식과 작업 프로세스에 대해 다시 생각해보는 계기였습니다.
디자이너가 기획 초안을 구상하거나, 다른 사람을 설득해야 할 때 실물 자료로 활용하기에도 매우 유용한 방식이라는 생각이 들었습니다. 실제 화면을 보여주면서 대화를 시작할 수 있으니, 앞으로의 프로젝트에서도 충분히 활용해볼 만한 가치가 있다고 느꼈습니다.
최신 마케팅/고객 데이터 활용 사례를 받아보실 수 있습니다.