디자인 시스템과 일관성 관리

한 화면을 멋지게 만드는 일은 생각보다 빨리 됩니다. 문제는 그다음입니다. 로그인 화면은 세련됐는데 설정 화면에 가면 버튼이 달라지고, 대시보드는 같은 제품인데도 폰트 분위기가 미묘하게 바뀌고, 모바일 화면으로 넘어가면 여백이 갑자기 성격이 달라집니다. 사용자는 이런 차이를 정확히 설명하지 못해도, 아주 빠르게 알아차립니다. "뭔가 덜 정리돼 보인다"는 느낌으로요.

Stitch를 쓸 때도 이 지점이 중요합니다. 첫 화면이 잘 나오는 것보다, 열 번째 화면까지 같은 팀이 만든 것처럼 보이게 하는 일이 훨씬 어렵습니다. 실제 사용자 포럼에서도 새 화면을 만들수록 헤더, 로고, 글꼴, 레이아웃의 연속성이 흔들린다는 이야기가 반복해서 나옵니다.¹

이 챕터에서는 그 문제를 감으로 버티지 않고, 시스템으로 다루는 방법을 살펴보겠습니다. 핵심은 네 가지입니다. 디자인 토큰으로 기준값을 고정하고, 테마로 제품의 톤을 묶고, DESIGN.md로 규칙을 문서화하고, 기존 화면의 맥락을 다음 화면으로 계속 전달하는 것입니다.

왜 일관성은 한 번에 무너질까

일관성이 깨지는 이유는 대개 단순합니다. 화면을 만들 때마다 매번 "그때그때 예쁘게" 결정하기 때문입니다. 첫 화면에서는 버튼 반경이 12px 느낌이었고, 다음 화면에서는 10px쯤이 더 단정해 보여 바꾸고, 또 다른 화면에서는 카드 그림자를 조금 더 진하게 주는 식입니다. 한 번 한 번은 합리적이지만, 결과적으로 제품은 조금씩 다른 목소리를 내기 시작합니다.

특히 Stitch처럼 생성 속도가 빠른 도구에서는 이 문제가 더 쉽게 생깁니다. 속도가 빠르다는 건 방향을 빨리 탐색할 수 있다는 뜻이지만, 동시에 기준 없이 여러 변형을 만들면 화면마다 스타일이 슬쩍 미끄러질 수 있다는 뜻이기도 합니다. 그래서 Stitch를 잘 쓴다는 것은 단순히 프롬프트를 잘 쓰는 것이 아니라, 무엇을 고정하고 무엇을 바꿀지 구분하는 일에 가깝습니다.

디자인 토큰: 취향을 규칙으로 바꾸는 최소 단위

디자인 토큰은 반복해서 쓰는 시각 규칙에 이름을 붙인 값입니다. 쉽게 말해 "자주 쓰는 디자인 결정의 별명"입니다. 색상, 간격, 글자 크기, 모서리 반경, 그림자 같은 값을 그냥 감으로 쓰지 않고, 재사용 가능한 기준으로 만드는 것이죠. 디자인 토큰 표준화 논의에서도 토큰은 색상, 간격, 타이포그래피 스케일 같은 디자인 시스템의 가장 작은 결정 단위로 설명됩니다.²

예를 들어 버튼 배경색을 매번 #2563EB처럼 직접 쓰는 대신 primary라고 부르고, 카드 안쪽 여백을 매번 20px, 24px, 22px로 흔들지 않고 space-5처럼 정해 두는 방식입니다. 이렇게 하면 화면이 늘어나도 선택지는 줄고, 품질은 오히려 안정됩니다.

아주 단순한 예를 들면 이런 식입니다.

여기서 중요한 포인트는 "값"보다 "이름"입니다. 값만 있으면 그냥 스타일 모음집입니다. 이름이 있어야 규칙이 됩니다. 특히 primary, success, danger, muted 같은 의미 기반 토큰은 나중에 테마를 바꾸거나 다크 모드를 추가할 때 훨씬 강력합니다.²

테마는 토큰의 조합이다

토큰이 재료라면, 테마는 요리입니다. 같은 구조를 유지한 채 제품 분위기만 바꾸고 싶을 때 테마가 필요합니다. 예를 들어 라이트 테마와 다크 테마는 레이아웃이 달라도 안 되고, 컴포넌트 성격이 달라도 안 됩니다. 같은 제품이 조명만 바뀐 것처럼 느껴져야 합니다.

Stitch에서 여러 화면의 일관성을 잡을 때도 이 생각이 중요합니다. 이미 생성한 화면들을 각각 따로 고치기보다, 여러 화면을 함께 선택한 뒤 공통된 테마 변경을 적용하는 방식이 훨씬 안정적입니다. 2026년 공식 업데이트에서도 Stitch는 프로젝트 전체 맥락을 바탕으로 여러 아이디어를 병렬 탐색하고, 디자인 규칙을 재사용하는 방향을 강화했다고 설명합니다.³

즉, "이 화면만 더 따뜻하게"보다 "프로젝트 전체를 차분한 중명도 블루 계열로 정리해 달라"가 더 좋은 요청일 때가 많습니다. 개별 화면을 예쁘게 만드는 수정은 빠르지만, 제품을 같은 제품처럼 보이게 만드는 수정은 보통 전역 수준에서 이뤄져야 합니다.

Stitch에서 DESIGN.md가 중요한 이유

여기서 DESIGN.md가 등장합니다. DESIGN.md는 디자인 시스템을 사람과 AI가 함께 읽을 수 있는 문서로 정리한 파일입니다. 색상, 타이포그래피, 간격, 컴포넌트 패턴, 금지 규칙 같은 내용을 한곳에 모아 두는 일종의 "시각적 계약서"라고 생각하면 됩니다.

Google은 2026년 업데이트에서 DESIGN.md를 agent-friendly markdown file이라고 설명했습니다. 즉, 사람이 참고하는 가이드일 뿐 아니라, AI가 다음 화면을 만들거나 다른 도구로 내보낼 때도 함께 읽을 수 있는 기준 문서라는 뜻입니다.³

이 문서가 좋은 이유는 단순합니다. AI는 눈치로 기억하지 않습니다. 텍스트로 남겨진 규칙을 더 잘 따릅니다. 그래서 DESIGN.md가 있으면 다음 화면을 생성할 때도, 코딩 에이전트에게 UI를 맡길 때도, "이 프로젝트는 어떤 색을 쓰고 어떤 여백 리듬을 가지는지"를 반복해서 설명할 필요가 줄어듭니다.

다만 기대치는 현실적으로 잡을 필요가 있습니다. DESIGN.md가 있다고 해서 모든 화면이 자동으로 완벽해지는 것은 아닙니다. 이 문서는 자동 조종 장치라기보다, 스타일 드리프트를 줄이는 기준점에 가깝습니다.

DESIGN.md에는 무엇을 적어야 할까

좋은 DESIGN.md는 길다고 좋은 것이 아닙니다. 애매하지 않아야 좋습니다. 처음부터 백과사전처럼 만들기보다, AI와 팀이 반복해서 참조해야 하는 핵심 규칙부터 선명하게 적는 편이 낫습니다.

최소한 다음 항목은 들어가는 것이 좋습니다.

• 브랜드 톤 한 줄: 차분한지, 대담한지, 신뢰형인지, 친근한지

• 핵심 토큰: primary, surface, text, border, radius, spacing scale, typography scale

• 대표 컴포넌트 규칙: 버튼, 카드, 입력창, 내비게이션의 기본 상태와 변형

• 공통 레이아웃 원칙: 최대 너비, 섹션 간격, 카드 밀도, 반응형 기준

• 금지 패턴과 예외: 너무 강한 그림자 금지, 한 화면에 폰트 웨이트 3개 초과 금지 같은 규칙

여기에 한 줄씩만 더해도 문서는 훨씬 강해집니다. 예를 들어 "기본 버튼은 둥글지만 장난스럽지 않다", "금융 정보 카드에는 과한 그래디언트를 쓰지 않는다", "모바일 하단 내비게이션은 모든 핵심 플로에서 동일한 높이와 아이콘 스타일을 유지한다" 같은 문장들입니다. 숫자만 적힌 파일보다, 판단 기준이 함께 적힌 파일이 실제로 훨씬 쓸모 있습니다.

기존 화면 맥락을 유지하는 실전 전략

이제 가장 중요한 질문으로 가보겠습니다. 이미 잘 나온 한 화면의 분위기를 다른 화면에 어떻게 이어 붙일까요?

가장 좋은 방법은 "잘 나온 한 화면"을 기준 화면으로 삼는 것입니다. 대개 홈 화면이나 핵심 대시보드, 혹은 브랜드 성격이 가장 잘 담긴 랜딩 화면이 여기에 해당합니다. 이 기준 화면에서 색상, 폰트, 여백, 카드 스타일 같은 디자인 DNA를 먼저 뽑아야 합니다. Stitch는 URL에서 디자인 시스템을 추출하거나, DESIGN.md를 다른 프로젝트로 가져와 규칙을 재사용하는 흐름을 지원합니다.³

핵심은 새 화면을 빈 캔버스에서 다시 상상하지 않는 것입니다. 기존 화면을 기준점으로 삼고, 그 맥락을 다음 화면으로 넘겨야 합니다. 이때 실무적으로는 세 가지가 특히 효과적입니다.

첫째, 새 화면을 만들기 전에 기준 화면을 먼저 고르고, 그 화면의 톤을 유지하라고 명시합니다.

둘째, 반복되는 구조를 먼저 고정합니다. 헤더, 사이드바, 하단 탭, 기본 버튼, 기본 카드처럼 제품의 얼굴 역할을 하는 요소는 초반에 기준을 정해야 합니다.

셋째, 화면 단위 수정이 아니라 시스템 단위 수정으로 올라갑니다. 예를 들어 설정 화면의 카드만 반경을 바꾸는 대신 카드 토큰 자체를 바꾸는 식입니다. 제품이 커질수록 예외 처리보다 시스템 수정이 훨씬 싸집니다.

URL, 레퍼런스, 기존 프로젝트를 활용하는 법

아직 디자인 시스템이 없는 팀이라면 오히려 시작이 쉽습니다. 먼저 기존 마케팅 사이트나 이미 잘 정리된 자사 페이지 하나를 기준으로 잡아도 됩니다. Stitch는 URL을 넣어 디자인 언어를 추출하고, 그 토큰과 스타일을 새 화면 생성의 바탕으로 삼는 흐름에 강점이 있습니다.³

다만 여기서 중요한 습관이 하나 있습니다. 추출된 결과를 그대로 믿지 말고, 가장 먼저 핵심 토큰을 검토해야 합니다. 잘못 잡힌 색상 하나, 애매한 폰트 해석 하나가 이후 모든 화면에 번지기 때문입니다. 첫 단추가 틀어지면 다음 다섯 화면도 성실하게 틀어집니다. AI는 참 부지런하게 실수합니다.

이미 다른 프로젝트에서 잘 정리한 화면이 있다면, 새 프로젝트를 시작할 때 그 결과물과 DESIGN.md를 함께 참고 자료로 넣어 기억을 이어 가는 방법도 유용합니다. 제품군이 여러 개라도 브랜드 톤이 같아야 한다면, 이전 프로젝트의 규칙을 뼈대로 재사용하는 편이 훨씬 안정적입니다.

작은 팀이 바로 써먹는 운영 방식

작은 팀에서는 디자인 시스템이라는 말이 너무 거창하게 들릴 수 있습니다. 하지만 실제로는 복잡한 도구보다 운영 습관이 더 중요합니다.

가장 단순한 운영 방식은 이렇습니다. 먼저 핵심 화면 하나를 뽑아 기준 화면으로 지정합니다. 그다음 색상, 타이포, 간격, 버튼, 카드 규칙을 DESIGN.md에 짧게 정리합니다. 이후 새 화면은 반드시 그 기준 화면과 DESIGN.md를 함께 참조해서 생성합니다. 여러 화면을 만든 뒤에는 멀티 선택이나 공통 수정 요청으로 전체 결을 한 번 더 맞춥니다.³

이 루틴만 지켜도 "한 장씩 예쁜 화면"에서 "같은 제품처럼 보이는 화면 묶음"으로 수준이 올라갑니다. 디자인 시스템은 거대한 사전이 아니라, 반복할수록 더 싸지고 더 안정되는 작업 방식입니다.

흔한 실패 네 가지

일관성 관리는 대개 거창한 이론보다 작은 실수에서 무너집니다.

첫 번째는 화면마다 새 프롬프트로 출발하는 것입니다. 이러면 AI는 매번 새 작품을 만들려고 합니다. 우리는 새 작품이 아니라, 같은 시리즈의 다음 화가 필요합니다.

두 번째는 스타일 단어만 남기고 값은 남기지 않는 것입니다. "모던하게", "깔끔하게", "프리미엄하게"만으로는 부족합니다. 최소한 핵심 색상, 타이포 스케일, 간격 체계는 토큰으로 고정해야 합니다.

세 번째는 예외를 전역 규칙보다 많이 만드는 것입니다. 예외가 많아질수록 시스템은 약해지고, 결국 다시 손수 정리해야 합니다.

네 번째는 DESIGN.md를 만들어 놓고 실제 생성 흐름에 넣지 않는 것입니다. 문서는 저장용이 아니라 참조용입니다. 새 UI를 만들 때마다 그 규칙을 함께 읽히게 해야 드리프트를 줄일 수 있습니다.³

결국 중요한 것은 "같은 제품의 말투"다

디자인 시스템을 만든다고 해서 모든 화면이 똑같아져야 하는 것은 아닙니다. 오히려 좋은 시스템은 화면마다 역할은 다르게 두되, 말투는 같게 만듭니다. 온보딩은 가볍고, 대시보드는 밀도 있고, 설정은 차분해도 괜찮습니다. 하지만 버튼의 성격, 여백의 리듬, 텍스트 위계, 표면의 질감은 같은 팀의 판단처럼 이어져야 합니다.

Stitch는 이 작업을 빠르게 시작하게 도와줍니다. 그러나 속도가 곧 일관성을 보장하지는 않습니다. 일관성은 결국 기준을 만들고, 그 기준을 문서화하고, 다음 화면을 만들 때마다 다시 참조하는 습관에서 나옵니다.

한 화면을 잘 만드는 능력은 인상적인 결과를 줍니다. 여러 화면을 같은 제품처럼 보이게 만드는 능력은 신뢰를 만듭니다. 그리고 제품은 대개, 인상보다 신뢰로 오래 갑니다.

참고

¹How to Maintain Style Consistency

²Design Tokens Community Group - World Wide Web Consortium (W3C)

³Introducing "vibe design" with Stitch