디자이너의 바이브 코딩 1부 : AI에게 디자인 일관성 지키게 하는 법

요즘 핫한 AI를 열심히 쓰고 있는 디자이너로서, 바이브 코딩으로 재미있는 프로젝트를 하나 진행해본 뒤 그 과정에서 AI를 어떻게 활용했는지 디자이너의 입장에서 글을 써보려고 합니다. 프로젝트를 진행하는 과정 속에 AI가 어디에서 어떻게 활용되었고 어느 영역을 직접 처리했는지 등을 정리해보는 글인 만큼, 부디 바이브 코딩을 시도해보는 많은 분들에게 도움이 되면 좋겠습니다.

우선 1부인 이 글에서는 “AI에게 어떻게 디자인 일관성을 지키게 했나”를 다룬 뒤, 2부에서는 화면 구현과 배포 그리고 회고를 올리는 과정으로 진행할 예정입니다.

디자이너로서 프로젝트를 시도해보며 쓴 글인만큼 글의 포커스가 디자이너 친화적일 것이라는 생각은 들지만, 디자이너가 아닌 분들도 어떤 과정을 통해 서비스를 만들 수 있었는지 가볍게 보기 좋게 정리해 보았으니 편하게 읽어주세요 🙂

디자이너가 가볍게 구현할 만한 서비스가 뭐가 있을지 고민하다가, 분노에 가득 찬 현대인을 위해 어떤 욕을 해도 고운 말로 번역되는 서비스를 만들어 보기로 했습니다. 내가 할 말은 다 하지만 곱게 번역되어 전송되는 거죠🤗

이렇게 아이디어 구상이 완료되면 프로덕트로 만들어야 하는데요. 실제로 구현되는 프로덕트를 만들기 위해서는 작업 전 개발 로직까지 검토가 필요했습니다. 그래서 “바이브 코딩을 통해 구현 가능한 영역인가, 어떤 기술을 사용해서 만드는 게 좋은지”에 대한 기술 검토 과정을 Claude를 통해 확인한 다음 기획·디자인·개발·배포의 과정으로 해당 서비스를 제작하게 되었습니다.

대략적인 아이디어에 대해 기술 검토가 완료된 뒤에는 상세 기획과 PRD를 작성합니다. 그다음 디자인, 개발, 배포, 유지보수 등의 작업이 이루어져야겠죠. 이 모든 걸 Claude 하나로만 진행하지는 않았고, 다양한 툴과 함께 작업을 진행하였는데요. 저는 아래와 같은 툴들을 함께 사용했습니다.

1. Notion : PRD(기획 문서) 관리
2. Figma : 디자인 시스템 정의 + 와이어프레임
3. GitHub : 코드 관리
4. Firebase : 배포(호스팅)

Claude에 각 툴을 연결한 뒤, 코딩처럼 직접 하기 어려운 부분은 AI에 맡기고 제가 잘할 수 있는 영역인 “디자인 품질을 결정하고 디테일을 잡는 마무리”는 직접 진행하는 방식으로 작업했습니다. AI는 빠르게 초안을 깔아주는 역할을 해주었고, 저는 그 초안을 기반으로 최종 디자인 시안을 만드는 것이죠. 그리고 이러한 바이브 코딩에서 중요한 것은 [완벽한] 서비스를 처음부터 만들고자 하는 욕심을 버리는 것입니다. 일단 해보는 거죠.

자! 그럼 [PRD → 디자인 → 개발 → 배포] 순으로 죽이 되든 밥이 되든 시작해 볼까요?!😉

긴 프로젝트 여정의 그 첫 번째는 머릿속 아이디어를 문서로 정리하는 일입니다. AI에게 “이런 서비스를 만들고 싶다”고 설명하고 기술 검토와 함께 서비스 PRD까지 만들어 달라고 했더니, 문제 정의부터 타겟 사용자, MVP 기능, 사용자 플로우, 기술 구조, KPI, 리스크, 개발 로드맵까지 한 번에 정리해줬습니다.

클로드가 구성해준 서비스의 구조는 아래와 같이 설계되었고, 저는 이걸 기반으로 와이어프레임과 디자인 작업에 들어가기로 했습니다.

[원문 입력] → [순화하기 버튼] → [AI 변환] → [결과 출력] → [원클릭 복사]

AI를 사용해 디자인 시안을 뽑아보면 출력되는 화면의 일관성이 없는 결과물이 나오는 경우가 많습니다. 분명 내가 정의한 컬러는 레드 빛이 도는 핑크 컬러였는데 다음 화면은 미묘하게 다르다든지, 라운드 값이 미묘하게 다르기도 하죠. 그래서 작업을 진행할 때 AI가 화면을 만들 때 참고해야 할 디자인 규칙을 심어줘야 합니다.

방법으로 택한 건 DESIGN.md 문서를 만들어서 AI에게 주입시켜 주는 것이었습니다. DESIGN.md란 디자인 시스템을 다음 두 층으로 정리한 포맷을 말합니다. 해당 문서에는 색상, 타이포, 간격, 라운드 등의 값을 정의해 주며, AI는 화면을 만들 때마다 이 문서를 참조해서 디자인을 진행하므로 디자인의 일관성을 크게 해치지 않는 선에서 결과물을 받아볼 수 있게 됩니다.

1. YAML 토큰 : 색상·타이포·간격·라운드·컴포넌트를 값으로 정의
2. 마크다운 본문 : Overview → Colors → Typography → Layout → Shapes → Components → Do’s and Don’ts 순서로, “왜 이렇게 쓰는지” 의도를 설명

DESIGN.md 파일은 Figma에 정의해둔 디자인 시스템 페이지(Font / Color / Logo)를 AI가 직접 읽어서 만들도록 명령하는 방식으로 만들었습니다. Figma가 원본이고, DESIGN.md 파일은 거기서 파생된 산출물인 것이죠. 이렇게 하면 “디자인 따로, 코드 따로” 노는 문제가 일부분 해결되게 됩니다.

저의 경우 이러한 디자인 시스템 작업은 AI를 사용하지 않고 직접 구축했습니다. AI가 화면을 자동으로 만들더라도, 그 기획 의도와 무드에 맞는 가이드는 제가 직접 잡아야 한다고 생각했기 때문입니다.

다만 디자인 시스템을 처음부터 하나하나 구축하는 작업은 시간이 워낙 많이 듭니다. 그래서 저처럼 직접 만들기보다 빠르게 시도해 보고 싶으시다면, 이미 만들어진 Design System을 활용하는 방법도 제안드리고 싶습니다. Figma의 Community에 들어가면 공유된 다양한 디자인 시스템을 보실 수 있는데요. 저는 그중 Figma Community에 공유된 Anthropic 스타일의 UI 키트를 추천드리고 싶습니다. 해당 시스템을 베이스로 필요한 부분만 조금 수정해서 사용하신다면 빠르게 디자인 시스템을 구축할 수 있을 것 입니다.

디자인 시스템이 정리되었다면 해당 시스템을 기반으로 DESIGN.md 파일을 만들어야 하는데요. 방법은 다양하겠지만 저는 피그마를 Claude에 연동시킨 뒤 피그마 기반으로 DESIGN.md를 만들었습니다. AI에게 Figma에 제작되어 있는 디자인 파일의 소스를 제공한 뒤, Figma의 가이드를 기반으로 DESIGN.md 링크에 있는 형식을 참고해서 파일을 생성해 달라고 부탁했습니다.

제가 AI에게 제공했던 md 파일은 아래 링크로 올려두니 참고해 주세요.

디자인 md 파일 제작이 완료된 이후에는 이 시스템을 기반으로 개발에서 그대로 가져다 쓸 수 있는 코드 형태로 뽑아냈습니다. 요즘 프론트엔드 개발자분들이 가장 많이 쓰고있는 Tailwind 코드 형태로 시스템을 뽑아달라고 요청해 봤습니다. Tailwind가 무엇인지 궁금하실 수 있을 것 같아 관련 문서는 아래 링크로 첨부해 두겠습니다. 해당 글에서 가볍게 설명해 드리고 넘어가자면 CSS 파일을 따로 작성할 필요 없이, 미리 정의된 클래스들을 HTML 요소에 적용하는 것으로 일관된 화면을 제작하는 방식의 프레임워크입니다.

1. theme.css : Tailwind v4 @theme (CSS 변수)
2. tailwind.theme.json : Tailwind v3 theme.extend config
3. tokens.json : W3C 커뮤니티 그룹 표준(DTCG) 디자인 토큰

이렇게 하면 디자이너가 정의한 Primary/500이 코드에서 그대로 bg-primary가 되어 만들어집니다. 디자인과 코드 사이의 번역 손실이 사라져, 디자이너가 의도한 바에서 크게 벗어나지 않는 시안이 출력될 수 있게 되는 거죠.

자, 여기까지 진행했다면 Claude Code로 넘어가서 개발을 시작하면 되는데요. 여기까지가 개발을 위한 기반작업을 마무리했다고 생각하면 될 것 같습니다. 이제 순차적으로 와이어프레임 → 디자인 → 개발 → 배포 순서대로 진행하면 되는데요 이 내용은 다음 2편에서 써보도록 하겠습니다.

AI는 분명 생산성을 많이 올려줍니다. 예전 같았으면 하루 종일 기획하고 생각했을 것들을 딸깍 한 번으로 해결하게 되었으니까요. 중요한 것은 그 딸깍의 결과물을 검수하고 판단하는 것이라고 생각합니다. 이번 글에서 포인트로 짚고 싶은 부분은 아래 두 가지입니다. 자 그럼 저는 이어지는 두번째 글에서 독자분들을 또 찾아 뵙도록 하겠습니다.

1. 디자인 시스템을 구축하고 md 파일을 만들어서 디자인의 일관성을 유지하는 것
2. 해당 디자인을 기반으로 AI가 이해할 수 있는 형태의 최종 시안을 만드는 것

🔜 2부 예고 : 와이어프레임을 그리고, 해당 서비스를 코드로 구현하며 GitHub와 Firebase로 실제 서비스를 띄우기까지의 이야기