AI에게 색을 눈으로 짐작해 넘기지 마세요, 코드로 건네야 합니다

AI에게 "이 화면 느낌으로 만들어줘"라고 말하면 처음에는 꽤 그럴듯한 결과가 나옵니다. 그런데 두 번째 화면부터 이상해집니다. 버튼 색이 조금 달라지고, 회색 배경이 한 톤 떠 보이고, 카드 안쪽 여백이 이전 화면과 맞지 않습니다. 사람 눈에는 작은 차이처럼 보이지만 제품 안에서는 금방 누적됩니다.

문제는 AI가 색을 못 알아보는 것이 아닙니다. 화면 캡처는 의도를 담은 자료가 아니라 결과를 찍은 그림입니다. 그림에는 #3E5F94라는 색상 역할도, 이 색이 primary인지 surface인지도, hover와 disabled가 어떻게 이어지는지도 들어 있지 않습니다. AI는 캡처를 보고 최대한 추정합니다. 다만 그 추정은 매번 약간씩 달라집니다.

작은 팀은 여기서 시간을 잃습니다. 디자이너가 없어도 제품을 만들 수 있게 된 시대라서 오히려 디자인 언어를 더 정확하게 다뤄야 합니다. "비슷하게"를 반복하면 빨라지는 것처럼 보이다가, 어느 순간 모든 화면을 다시 맞추는 비용이 생깁니다.

핵심 정리

1. 01AI에게 넘길 것은 최종 화면 이미지가 아니라 색상 역할, 간격 규칙, 컴포넌트 상태를 담은 작은 디자인 계약입니다.
2. 02hex 값 하나보다 중요한 것은 그 값이 어디에 쓰이는지입니다. primary, background, border, text 같은 역할명이 함께 있어야 재사용됩니다.
3. 03스크린샷은 참고 자료로만 쓰고, 구현 지시는 토큰과 CSS 변수, 컴포넌트 props처럼 기계가 그대로 적용할 수 있는 형태로 줘야 합니다.
4. 04디자인 핸드오프의 목표는 예쁜 설명이 아니라 다음 화면에서도 같은 판단이 반복되게 만드는 것입니다.

용어 정리

디자인 토큰

색, 간격, 폰트, 반경 같은 시각 결정을 이름 붙인 값입니다. 코드와 디자인 도구가 같은 이름을 공유할 때 힘이 납니다.

token

역할명

색의 생김새가 아니라 쓰임을 설명하는 이름입니다. 예를 들어 indigo보다 primary, gray보다 border가 더 오래갑니다.

role

핸드오프

디자인 의도를 구현자가 재현할 수 있게 넘기는 과정입니다. AI 협업에서는 사람이 아니라 에이전트가 첫 구현자가 됩니다.

handoff

캡처

최종 결과를 찍은 이미지입니다. 맥락을 빠르게 보여주지만 규칙과 예외를 보존하지 못합니다.

reference

화면을 넘기면 AI는 규칙이 아니라 결과를 봅니다

스크린샷은 사람끼리 대화할 때 강력합니다. "이런 톤", "이 정도 여백", "이 버튼 느낌"을 빠르게 공유할 수 있기 때문입니다. 문제는 AI에게 스크린샷만 넘기는 순간입니다. AI는 그 화면이 어떤 디자인 시스템에서 나왔는지 모릅니다. 회색이 배경인지 비활성 상태인지, 파란색이 브랜드 색인지 링크 색인지, 16px 여백이 우연인지 규칙인지 알 수 없습니다.

결과는 "거의 맞지만 조금 다른" 쪽으로 흐릅니다. 한 번의 화면에서는 티가 덜 납니다. 리스트와 상세 화면까지 이어지면 차이가 보입니다. 설정, 모달, 빈 상태에서는 더 쉽게 드러납니다. 같은 primary 버튼인데 어느 화면은 더 진합니다. 다른 화면은 더 둥글고 hover가 없습니다. 사람은 이 차이를 나중에 발견하고 다시 프롬프트를 씁니다.

이때 문제를 AI 성능으로만 보면 해결이 늦어집니다. 더 좋은 모델은 이미지를 더 잘 읽겠지만, 그래도 이미지가 규칙으로 변하지는 않습니다. 규칙은 사람이 이름 붙이고 정리해야 합니다. AI에게 필요한 것은 "보고 따라 할 그림"이 아니라 "다음에도 같은 결정을 내릴 기준"입니다.

작은 팀에서는 이 차이가 큽니다. 디자이너와 프론트엔드 엔지니어가 같은 자리에 앉아 픽셀을 맞추는 시간이 없기 때문입니다. 화면이 늘어날수록 사람이 직접 감리하는 방식은 깨집니다. 초기에 조금 귀찮더라도 색과 간격을 토큰으로 넘기는 습관이 더 싸게 먹힙니다.

토큰은 색을 예쁘게 부르는 이름이 아닙니다

토큰을 단순한 색상표로 이해하면 반쪽만 쓰는 것입니다. #3E5F94 같은 값은 중요합니다. 더 중요한 것은 그 값이 왜 존재하는지입니다. 이 색이 primary action인지, mascot hoodie인지, link인지, focus ring인지가 빠지면 AI는 같은 값을 엉뚱한 곳에 복사합니다.

좋은 토큰은 역할을 설명합니다. --color-action-primary, --color-surface-raised, --color-border-muted, --radius-card, --space-section처럼 쓰임이 보이면 다음 화면에서도 판단이 이어집니다. AI는 "파란색 버튼"보다 "primary action button"을 더 안정적으로 재현합니다. 사람도 리뷰할 때 무엇이 틀렸는지 말하기 쉬워집니다.

여기서 토큰은 거창한 디자인 시스템을 뜻하지 않습니다. 처음에는 20줄짜리 CSS 변수여도 충분합니다. 브랜드 색 4개, 텍스트 색 3개, 배경 색 2개, 간격 5개, 반경 3개만 있어도 화면의 흔들림은 크게 줄어듭니다. 중요한 것은 모든 값을 다 정하는 것이 아니라 자주 반복되는 결정을 이름으로 고정하는 것입니다.

토큰은 AI에게만 좋은 것도 아닙니다. 사람이 나중에 색을 바꾸고 싶을 때도 값 하나를 따라가면 됩니다. "사이트 전체를 조금 더 차분하게" 같은 요청이 들어오면, 화면마다 눈대중으로 고치는 대신 역할 단위로 조정할 수 있습니다. 디자인 언어가 문서와 코드 사이에서 살아남는 구조가 됩니다.

AI에게 줄 자료는 작고 정확해야 합니다

AI 협업에서 좋은 자료는 길이가 아니라 적용 가능성으로 판단해야 합니다. 디자인 가이드가 40페이지여도 실제 구현자가 찾을 수 없으면 소용없습니다. 짧은 DESIGN.md 하나가 더 강할 때도 있습니다. 색과 간격을 정확히 담은 경우입니다. 타이포그래피와 컴포넌트 상태도 함께 담아야 합니다.

내가 쓰기 좋은 형태는 세 가지입니다. 첫째는 토큰 표입니다. 색상과 간격을 값과 역할로 묶습니다. 둘째는 컴포넌트 계약입니다. 버튼과 카드의 기본 상태를 적습니다. 탭과 입력창의 금지사항도 짧게 붙인다. 셋째는 예시 화면입니다. 이때 이미지는 주 자료가 아니라 검수용 참고 자료입니다.

AI에게는 이렇게 말하는 편이 낫습니다. "이 스크린샷처럼 만들어줘"가 아니라 "아래 토큰과 컴포넌트 계약을 기준으로 화면을 만들고, 스크린샷은 밀도와 정보 구조 참고로만 봐라." 이 한 문장만으로도 작업의 기준이 달라집니다. 이미지가 왕이 아니라 규칙이 왕이 됩니다.

물론 모든 것을 코드로만 설명할 수는 없습니다. 브랜드의 온도, 일러스트의 성격, 페이지의 리듬은 여전히 이미지가 빠릅니다. 이미지를 버리자는 이야기는 아닙니다. 이미지가 맡을 일과 코드가 맡을 일을 나누자는 이야기입니다. 이미지는 감각을 보여주고, 토큰은 반복을 보장합니다.

작은 팀의 디자인 시스템은 운영 습관입니다

디자인 시스템이라고 하면 대기업의 거대한 컴포넌트 라이브러리를 떠올리기 쉽습니다. 작은 팀에게 필요한 것은 훨씬 작습니다. 지금 만드는 화면에서 반복되는 판단을 다음 화면에서도 재사용할 수 있게 남기는 일입니다. 이 정도만 해도 AI와의 협업 품질은 달라집니다.

처음에는 문서가 지저분해도 괜찮습니다. 오히려 너무 멋진 문서보다 실제 작업 중 계속 수정되는 문서가 낫습니다. 버튼을 만들다가 hover 규칙이 필요하면 추가하고, 카드가 많아지면 elevation 규칙을 추가하고, 표가 생기면 줄 간격과 border 규칙을 추가하면 됩니다. 핵심은 화면을 만들 때마다 규칙이 조금씩 쌓이는 구조입니다.

AI는 이런 구조에서 강해집니다. 매번 새로 감을 잡는 에이전트가 아니라, 프로젝트의 작은 디자인 언어를 읽고 들어오는 구현자가 됩니다. 프롬프트가 줄어드는 것보다 중요한 변화는 리뷰의 기준이 생긴다는 점입니다. "별로야" 대신 "이 버튼은 action-primary가 아니라 secondary입니다"라고 말할 수 있습니다.

결국 AI 디자인 협업은 더 멋진 이미지를 뽑는 문제가 아닙니다. 이미지를 보고 끝내는 단계에서, 규칙을 남기고 다시 쓰는 단계로 넘어가는 문제입니다. AI에게 눈대중을 시키지 말고, 반복 가능한 디자인 언어를 건네야 합니다.