바이브코딩, 디자인은?

내가 원하는 톤앤매너 맞추며 디자인하기

들어가며

Inter 폰트, 흰 배경에 보라색 그라디언트, 최소한의 애니메이션. AI스러운 디자인은 싫은데 자꾸 그런 결과물만 나온다면 어떻게 해야할까. 바이브코딩을 하는 사람들의 지향은 효율화도 있지만 내가 '만들고 싶은 걸 만든다'는 메이커 정신도 있을 거라 생각한다. 바이브코딩을 하면서 나는 특히나 디자인에 좀 집착하는 편인데 그 과정에서 얻은 배움을 공유한다.

뼈대 먼저 잡기

색상이나 세부 스타일을 정하기 전에, 레이아웃 구조부터 먼저 확인하는 게 도움이 됐다.

처음엔 바로 "예쁜 페이지 만들어줘"라고 했다가, 결과물이 내 의도와 다를 때가 많았다. 색상도 다르고, 배치도 다르고. 그래서 한 번에 다 하려고 하지 말고 단계를 나눴다.

ASCII 아트로 구조 먼저 보기

Claude한테 "레이아웃 구조만 먼저 보여줘"라고 요청하면, 이런 식으로 텍스트로 구조를 그려줬다:

+------------------+

| Header |

+------+-----------+

| Side | Main |

| bar | Content |

+------+-----------+

| Footer |

+------------------+

이렇게 보면 "사이드바가 왼쪽에 있구나", "배치가 이렇게 되겠군" 같은 게 바로 파악됐다. 색상이나 폰트 없이 순수하게 구조만 보니까 "아 이건 내가 원하는 배치가 아닌데"라는 걸 빨리 알 수 있었다.

왜 이 방식이 편했나

구조가 틀리면 나중에 고치기가 더 힘들다. 색상은 hex 코드 바꾸면 되지만, 레이아웃을 바꾸려면 코드를 많이 건드려야 하니까. 그래서 나는 이런 순서로 작업했다:

레이아웃 구조 먼저 확인 (ASCII 아트나 간단한 HTML)

구조가 맞으면 색상, 폰트 등 스타일 적용

세부 조정은 개발 서버에서 직접

페이지마다 디자인이 달라지는 문제

와조타 글쓰기 클럽을 만들면서 겪은 일이다.

처음에 로그인 페이지를 만들었다. 버튼 색은 파란색이었다. 괜찮았다. 그 다음 글쓰기 페이지를 만들었다. 버튼 색이 초록색이 되어 있었다. 클럽 홈 페이지를 만들었다. 또 다른 파란색이었다.

왜 이렇게 됐냐면, 매번 새 페이지 만들 때마다 Claude가 "적당히" 색을 골랐기 때문이다. 일관성이 없다.

내가 찾은 방법: 색상 코드를 직접 주기

이것저것 시도해보다가, 이미지로 보여주는 것보다 색상 코드를 직접 주는 게 훨씬 확실하다는 걸 알게 됐다.

Adobe Color로 팔레트 고르기

나는 Adobe Color에서 어울리는 색 조합을 먼저 골랐다.

Adobe Color 접속

"탐색" 메뉴에서 마음에 드는 팔레트 찾기

또는 "만들기"에서 보색, 유사색 등 규칙 기반으로 생성

HEX 코드 복사

그리고 Claude에게 이렇게 요청했다:

"이 컬러 팔레트를 참고해서 일관성을 지켜줘"

Primary: #F26B5B (코랄 레드) - 주요 버튼

Dark: #333333 (차콜) - 본문 텍스트

Light: #B8C4CC (쿨 그레이) - 보조 배경

Black: #1A1A1A - 강조 배경

White: #FFFFFF - 기본 배경"

이렇게 하니까 Claude가 헷갈릴 일이 없었다. "따뜻한 느낌의 색"이 아니라 "#F26B5B"라고 명확하게 지정하니까.

이미지보다 색상 코드가 나았던 이유

처음엔 브랜드 가이드 이미지를 보여주기도 했다. 근데 몇 가지 문제가 있었다:

이미지에서 색상 추출이 정확하지 않을 때가 있었다 - Claude가 비슷하지만 다른 색으로 해석할 때가 있었음

대화가 길어지면 이미지를 까먹었다 - 컨텍스트 윈도우 문제인 것 같았음

코드로 남아있으면 나중에 참조하기 쉬웠다 - design-system.md에 정리해두면 됐음

디자인 시스템 문서 만들기

아예 시스템 가이드 문서를 만들어두는 게 어떨까? docs/design-system.md 파일을 만들었다.

내가 정리해둔 것들

처음엔 색상만 정리했는데, 프로젝트가 커지면서 점점 추가하게 됐다. 나중에 보니 이런 것들이 정리되어 있으면 편했다:

1. 색상 팔레트와 용도: 색상 코드만 있으면 "이 색은 언제 쓰지?" 하고 헷갈릴 때가 있었다. 용도까지 같이 적어두니까 Claude도 나도 일관되게 쓸 수 있었다.

2. 배경-전경 조합 규칙 : "코랄 배경에 검정 글씨" 같은 조합이 나오면 가독성이 떨어진다. 어떤 조합이 괜찮은지 미리 정해두니까 실수가 줄었다.

3. 버튼 종류별 스타일: "이 버튼은 primary로 해줘"라고만 말하면 Claude가 알아서 맞는 스타일을 적용했다.

4. 반응형 규칙: 모바일이랑 데스크탑에서 너비가 달라야 할 때가 있는데, 이것도 미리 정해두니까 페이지마다 다르게 나오는 문제가 줄었다.

와조타 프로젝트의 실제 디자인 시스템 일부:

이 문서를 어떻게 썼나

이 문서를 프로젝트에 넣어두면, Claude가 CLAUDE.md 읽을 때 같이 참조한다.

"디자인가이드 문서 참조해" "Primary 버튼으로 만들어줘"

Claude가 알아서 #F26B5B 배경에 흰색 텍스트를 적용했다.

처음부터 이렇게 체계적으로 정리한 건 아니다. 작업하다가 "아 이것도 정해둬야겠다" 싶을 때마다 추가했다. 완벽한 문서를 만들려고 하기보다, 필요할 때마다 조금씩 늘려가는 게 현실적이었고, 무엇이 필요한지, 뭘 모르는지 모르는 상태였기 때문에 물어보면서 작업했다.

참고: Storybook 같은 도구도 있다

나는 마크다운 문서로 정리했는데, Storybook 같은 도구를 쓰는 방법도 있다. Storybook은 컴포넌트를 하나씩 따로 띄워서 볼 수 있는 도구다. 버튼이 어떻게 생겼는지, 카드가 어떤 상태일 때 어떻게 보이는지 미리보기 할 수 있다.

문서로 정리하는 것보다 시각적으로 확인하기 편하고, 팀으로 작업할 때 특히 유용하다고 한다. 나는 혼자 작업이라 마크다운으로 충분했는데, 프로젝트가 커지거나 다른 사람과 협업한다면 Storybook도 고려해볼 만하다.

디테일은 주석 보고 직접 수정

타이포그래피의 자간이나, 애매한 정도의 위치 수정 같은 건 Claude에게 말하면서 하는 게 오히려 시행착오가 많았다. Claude는 '눈'으로 보는 게 아니라 '코드'로 읽으니까, 사람이 직관적으로 알아듣는 말로 프롬프트를 주면 잘 알아듣지 못했다.

"여기 좀 더 위로", "간격이 좀 답답해" 같은 말은 나한테는 명확한데 Claude한테는 애매했다. 그래서 이런 세부 조정은 직접 하는 게 더 빨랐다.

주석이 뭔가

코드를 모르는 사람을 위해 설명하자면, 주석(comment)은 코드 안에 적는 메모다. 컴퓨터는 주석을 무시하고, 사람만 읽는다. 코드가 뭘 하는지 설명해두는 용도다. Claude한테 "이 코드에 주석 달아줘"라고 하면 이런 식으로 만들어준다:

여기서 //버튼 컴포넌트- 라고 써있는 부분이 주석이다.

이렇게 주석이 달려 있으면, 코드를 몰라도 "아 px-6이 좌우 패딩이구나", "tracking-wide가 자간이구나" 하고 알 수 있다.

직접 수정하는 방식

주석이 달린 코드를 받으면, 개발 서버에서 직접 보면서 수정했다.코드를 수정하면 바로 반영되니까. 색상이 마음에 안 들면 hex 코드 바꾸고, 패딩이 좁으면 숫자 올리고.

예를 들어 자간이 너무 넓다 싶으면:

tracking-wide를 tracking-normal로 바꿔보고

화면에서 바로 확인하고

마음에 들면 저장

Claude한테 "자간 좀 더 좁게"라고 말하는 것보다, 직접 바꿔보면서 눈으로 확인하는 게 나한테는 빨랐다.

로고 애니메이션: 시뮬레이션 페이지 따로 만들기

와조타 로고 애니메이션을 만들 때는 조금 다른 방법을 썼다.

문제

로고에 프레임 애니메이션을 넣고 싶었다. 16개 SVG 프레임을 순서대로 보여주는 방식으로. 근데 속도가 문제였다. 너무 빠르면 눈이 아프고, 너무 느리면 답답하고.

"200ms로 해줘" → "좀 더 빠르게" → "아니 너무 빠른데" → "150ms는 어때"

이런 식으로 계속 요청하는 게 답답했다.

속도별 시뮬레이션 페이지 만들기

그래서 Claude에게 이렇게 요청했다:

"로고 애니메이션 속도를 테스트할 수 있는 페이지 따로 만들어줘. 슬라이더로 속도 조절하고, 여러 속도를 한눈에 비교할 수 있게."

그래서 /animation-preview 페이지가 만들어졌다:

이 페이지에서 할 수 있는 것:

슬라이더로 20ms ~ 1000ms 사이 속도 조절

프리셋 버튼으로 자주 쓰는 속도 빠르게 선택 (50ms, 100ms, 150ms...)

크기 비교: 50px, 100px, 200px 버전을 나란히 보기

속도 비교: 빠른(50ms), 보통(150ms), 느린(300ms) 나란히 보기

배경 테스트: 라이트/다크 배경에서 어떻게 보이는지

Claude한테 "조금만 더 빠르게"라고 말하는 대신, 내가 직접 슬라이더를 움직이면서 딱 맞는 속도를 찾을 수 있었다. 결국 150ms가 제일 자연스러웠다.여러 옵션을 한눈에 비교할 수 있으니까 결정이 훨씬 쉬웠다. "50ms는 너무 빠르고, 300ms는 답답하고, 150ms가 딱이네."

폰트 설정: 로컬 파일로 직접 넣기

글쓰기 클럽 서비스라서 폰트도 나름 신경을 썼는데... 눈누(https://noonnu.cc/font_page/33)에서 찾아서 웹사이트에 무료로 쓸 수 있는 폰트를 찾았다.

웹폰트 연결 링크를 클로드한테 줘도 되고, 직접 폰트 파일을 주거나, 그것도 아니면 적당히 쓸 수 있는 웹폰트를 찾아달라고 해도 된다.

웹폰트 연결 링크

- 원하는 폰트가 있다면, 웹폰트로 쓸 수 있는지 검색해보면 이런 코드 같은 게 나온다. 그럼 그걸 클로드에게 주고 연결했다. https://github.com/adrinerDP/font-kopub

- 그런데 문제가 있었다. 이렇게 연결하니까, 로딩이 느릴 때 글자가 깜빡거렸다. 처음엔 기본 폰트로 나왔다가, 1초 후에 내가 설정한 폰트로 바뀌는 현상이 있어서 고민 끝에 수정.

폰트 파일 직접 넣기

- KoPub 폰트 파일을 다운받아서 프로젝트에 직접 넣었다. 이렇게 하니 로딩이 느리거나 깜빡일 때 폰트가 깨지지 않았다.

컬러 팔레트 시스템

나중에 디자인을 리뉴얼하면서 V2 디자인 시스템을 만들었다. 글판 카드에 다양한 색상을 적용하고 싶었는데, 매번 색을 정하기 귀찮았다. 그래서 8가지 컬러 팔레트를 미리 정해뒀다:

글판을 만들 때 colorIndex 만 지정하면 해당 색상이 자동으로 적용된다. 어울리는 색 조합을 미리 골라놨으니까 어떤 조합이든 괜찮다.

피그마를 조금 쓸 줄 안다면: html.to design 활용

나는 피그마를 살짝 배웠는데, 만약 피그마를 조금이라도 다룰 줄 안다면 쓸 수 있는 방법이 있다.

html.to design 이라는 피그마 플러그인이 있다.

- 웹페이지 URL을 입력하면 html 페이지를 긁어와서 디자인 요소들을 살펴볼 수 있고

- HTML 코드를 붙여넣으면, 그걸 피그마 디자인 요소로 변환해준다.

나는 저널리즘 인터랙티브 페이지들의 구조를 뜯어보고 싶어서 이걸 사용했었다.

그런데 바이브코딩을 하면서 디자인-> 코드가 아니라 코드-> 디자인으로 가서 수정하는 방식으로도 유용하게 쓸 수 있다는 걸 알게 됐다.

활용법 (디자인-> 코드로)

참고하고 싶은 페이지가 있을 때: html.to" design으로 그 페이지를 피그마에 불러온다

CSS 코드 추출: 피그마에서 해당 요소의 스타일 정보를 확인한다

Claude에게 전달: 추출한 CSS 코드를 Claude Code에게 주면서 "이 디자인을 레이아웃과 컬러 등 벤치마킹할 부분을 원칙들을 분석해줘"라고 요청한다

원칙 정리: Claude가 분석한 내용을 바탕으로 원하는 디자인 방향성과 원칙을 다듬는다

활용법 (코드-> 디자인으로)

Claude가 만들어준 코드를 피그마에서 시각적으로 확인하고 수정하는 방법이다.

코드 복사: Claude가 만들어준 HTML/CSS 코드를 복사한다

피그마로 변환: html.to.design에 코드를 붙여넣으면 피그마 요소로 변환된다

시각적으로 수정: 피그마에서 색상, 간격, 크기 등을 눈으로 보면서 조정한다

수정 사항 전달: "여기 내가 바란 건 이런 거야. 코드에 반영해줘"라고 Claude에게 요청한다

왜 이 방식이 효과적인가

결국 문제는 시각 언어를 컴퓨터에게 전달하는 것이다. "이런 느낌으로 해줘"라고 말해봤자 Claude는 내 머릿속 이미지를 모른다. 그래서 컴퓨터의 언어 = 코드로 요구사항을 전달하는 게 확실하다. "따뜻한 느낌"이 아니라 color: #F26B5B; border-radius: 8px; padding: 16px; 같은 식으로. html.to design은 이 과정을 도와준다. 마음에 드는 디자인을 코드로 변환해서, 그 코드를 기반으로 Claude와 대화할 수 있게 해주니까.

참고: Claude의 프론트엔드 스킬 시스템

그래도 클로드는 적당히 깔끔한 디자인을 잘 구현한다. 나중에 알게 된 건데, Claude에는 "프론트엔드 스킬"이라는 게 있다. Anthropic이 만든 디자인 가이드라인인데, Claude가 프론트엔드 작업을 할 때 참조할 수 있다.

프론트엔드 스킬이 뭔가

Anthropic 블로그에 따르면, LLM에게 아무 가이드 없이 랜딩 페이지를 만들어달라고 하면 거의 항상 비슷한 결과가 나온다고 한다. Inter 폰트, 흰 배경에 보라색 그라디언트, 최소한의 애니메이션. 이걸 "distributional convergence(분포적 수렴)"라고 부르는데, 학습 데이터에서 가장 흔한 패턴으로 수렴하는 현상이다. 프론트엔드 스킬은 이 문제를 해결하기 위해 만들어졌다. 핵심 원칙은 "AI스러운(generic AI slop) 디자인을 피하라"는 것이다.

구체적으로:

Inter, Roboto, Arial 같은 generic 폰트 피하기

흰 배경에 보라색 그라디언트 (AI의 대표적 클리셰) 피하기

예측 가능한 레이아웃 피하기

대신: 독특한 폰트, 강한 컬러 액센트, 비대칭 레이아웃 사용

둘 다 같은 스킬을 쓸 수 있다. claude.ai에서 간단한 UI를 테스트해보고, 마음에 들면 코드를 복사해서 프로젝트에 적용하는 방식으로 쓸 수도 있다.

관련 자료

Anthropic 블로그: Improving frontend design through Skills

클로드의 프론트엔드 스킬 문서

클로드의 프론트엔드 스킬 문서

내가 쓴 방법 정리

뼈대 먼저.

색상은 코드로.

디자인 시스템 문서 만들기.

디테일은 주석 보고 코드를 직접 수정.

시각적인 건 시뮬레이션 페이지를 따로 만들어서.

피그마 플러그인 등 다른 툴과 함께 활용.

다음 글 예고

여러 팁을 공유했고 디자인의 일관성을 위한 두 번째 시도로, 이제 컴포넌트를 만들 차례다. 다음 글에서는 자주 쓰는 디자인 요소들을 컴포넌트로 만든 경험을 공유하려 한다. SVG 파일 형식 선택부터, 테스트 페이지 만들기, 재사용 가능한 컴포넌트로 분리하는 과정을 공유한다.

이 글은 바이브코딩 시리즈의 세 번째 글입니다. 와조타 글쓰기 클럽 프로젝트 경험을 바탕으로 작성되었습니다.