Vercel 의 디자인 시스템 명세서는 정말 교과서적인 예시라고 할 만합니다.
오늘 Vercel 의 DESIGN.md 를 진지하게 분석해 봤습니다. 라이트 테마와 다크 테마를 모두 지원하며, 색상, 폰트, 간격, 컴포넌트, 모션, 카피라이팅 규칙을 실행 가능한 디자인 방법론으로 완벽하게 설명하고 있습니다.
앞으로 제 모든 제품의 design.md 를 이 방식을 따라 작성해도 될 것 같다는 생각이 들었습니다.
자세한 내용은 여기 있습니다:
DESIGN.md 가 무엇인지 잘 모르시는 분들도 계실 텐데요. 간단히 말해, AI 가 읽을 수 있도록 작성된 디자인 명세서입니다. AI 가 코드 작성을 도울 때 어떤 색상을 사용해야 하고, 어떤 폰트 크기를 적용해야 하며, 요소 간 간격은 얼마나 되어야 하는지 알려주는 역할을 합니다.
이 파일이 없으면 AI 가 생성하는 인터페이스는 매번 달라 보이고, 일관된 스타일을 유지하기 어렵습니다.
Vercel 의 DESIGN.md 를 읽고 나서 깨달은 점은, 좋은 DESIGN.md 는 단순히 AI 에게 어떤 헥스 코드나 폰트 크기를 사용해야 하는지 알려주는 것을 훨씬 넘어선다는 것입니다. 그것은 디자인 사고의 전체 집합을 나타냅니다. 제 생각을 완전히 뒤집어 놓을 정도였습니다.
오늘은 이 파일이 왜 이렇게 훌륭한지 분석해 보겠습니다.
1
먼저, 색상에 대해 이야기해 보겠습니다.
처음 DESIGN.md 를 작성하기 시작했을 때, 색상 부분은 사실 매우 단순했습니다. 몇 가지 색상 값을 나열하고, AI 에게 어떤 것이 기본 색상이고, 보조 색상이며, 강조 색상인지 알려주는 것이 전부였습니다.
하지만 이렇게 작성하면 AI 는 여전히 이러한 색상들이 다양한 상호작용 상태에 어떻게 대응하는지 알 수 없습니다.
예를 들어, 버튼의 경우 기본 상태는 어떤 색상이어야 할까요? 호버 상태에서는 얼마나 더 어두워져야 할까요? 클릭되는 순간에는 어떤 색상이어야 할까요? 이러한 세부 사항이 명확하게 정의되지 않으면 AI 가 생성하는 결과물은 매번 달라질 수 있습니다.
Vercel 의 접근 방식은 이 문제를 완벽하게 해결합니다.
Vercel 의 디자인 시스템에서는 각 색상 시리즈가 100부터 1000까지 10개의 그라데이션으로 나뉘며, 각 숫자는 고정된 인터페이스 상태에 해당합니다.
100은 요소의 기본 배경, 200은 호버 시 배경, 300은 클릭 시 배경입니다. 계속해서 400은 기본 테두리, 500은 호버 시 테두리, 600은 클릭 시 테두리입니다.
700은 태그나 버튼 자체와 같은 단색 블록에 사용됩니다. 800은 이러한 블록의 호버 상태입니다. 900은 보조 텍스트와 아이콘에 사용되고, 1000은 주요 텍스트와 아이콘에 사용됩니다.
단순한 숫자 나열처럼 보이지만, 그 뒤에는 완전한 상호작용 로직이 숨어 있습니다.
100에서 300은 배경 상태를 관리합니다. 400에서 600은 테두리 상태를 관리합니다. 700과 800은 단색 블록 상태를 관리합니다. 900과 1000은 정보 계층 구조를 관리합니다.
즉, Vercel 은 사실 AI 에게 여기에 여러 상태가 있으며, 색상은 이러한 상태의 표현일 뿐이라고 알려주는 것입니다.
이 방식의 장점은 매우 직접적입니다.
AI 가 코드를 작성할 때, 버튼이 호버될 때 얼마나 더 어두워져야 하는지, 테두리가 어떻게 변경되어야 하는지 추측할 필요가 없습니다. 기본 상태는 100, 호버는 200, 클릭은 300에 해당합니다. 규칙이 미리 정의되어 있습니다.
또한, 이를 기반으로 Vercel 은 라이트 테마와 다크 테마를 모두 제공하지만, 정확히 동일한 Token 이름을 사용합니다.
예를 들어, gray-1000 입니다. 라이트 테마에서는 #171717 로, 순수한 검정색에 가깝습니다. 다크 테마에서는 #ededed 가 되어 순수한 흰색에 가까워집니다.
디자인 시스템의 관점에서 이 두 색상은 사실상 동일한 것입니다.
둘 다 페이지에서 가장 중요한 정보를 나타냅니다. 개발자와 AI 는 인터페이스를 생성할 때 gray-1000 뒤에 있는 특정 헥스 값보다는 gray-1000 의 의미론적 의미에 집중합니다. 테마가 전환되면 시스템은 이 의미론적 의미를 해당 색상에 자동으로 매핑합니다.
2
색상 문제를 해결한 후, 또 다른 더 중요한 제약 조건은 페이지의 리듬입니다.
Vercel 의 간격 시스템은 4px 의 배수를 기반으로 하며, 총 9개의 값(4, 8, 12, 16, 24, 32, 40, 64, 96)만 제공합니다. 전체 제품의 모든 간격은 이 숫자들 중에서 선택됩니다.
처음에는 이것이 다소 제한적이라고 생각했습니다. 20px 이 필요하면 어떻게 해야 할까요? 28px 이 필요하면 어떻게 해야 할까요?
디자이너 친구에게 물어보니, 대부분의 제품에서 9가지 간격 스타일이면 기본적으로 충분하다고 했습니다.
간격 선택지가 너무 많으면 페이지의 리듬이 사라집니다. 많은 형편없는 웹사이트들은 매우 엉성한 간격 디자인을 가지고 있습니다. 이것은 사실 제품 디자인의 큰 금기 사항입니다.
훌륭한 디자인 시스템은 무한한 선택권을 주지 않습니다. 오히려 선택권을 적극적으로 제한합니다.
Vercel 은 명확한 리듬 제안 세트를 직접 제공합니다. 그룹 내 요소 간에는 8px, 그룹 간에는 16px, 섹션 간에는 32~40px 을 유지하세요. 이것은 확실히 페이지의 숨쉬는 리듬을 정의하는 것입니다.
사용자는 이러한 간격을 인지하지 못할 수도 있지만, 어떤 부분이 같은 전체에 속하고 새로운 콘텐츠 영역이 어디에서 시작되는지 자연스럽게 감지할 것입니다.
종종 페이지가 편안해 보이는 이유는 디자이너가 고급 기술을 사용했기 때문이 아니라, 이 리듬이 전체적으로 일관되게 유지되기 때문입니다.
타이포그래피도 같은 논리를 따릅니다.
Vercel 의 폰트 시스템은 색상 및 간격의 논리와 동일합니다.
모든 텍스트는 heading, label, copy, button 과 같은 몇 가지 고정된 역할로 분류됩니다.
각 역할 아래에는 다양한 크기의 Token 이 제공되며, 각 Token 에는 미리 정의된 폰트, 크기, 두께, 줄 높이, 자간이 있습니다.
이전에는 텍스트를 마주했을 때 디자이너가 14px 을 사용할지 15px 을 사용할지, 어떤 줄 높이가 적절한지 고민했을 수도 있습니다.
디자인 시스템을 사용하면 사고 방식이 바뀝니다. AI 는 먼저 이 텍스트가 어떤 역할을 하는지 결정합니다. 제목인지, 본문인지, 보조 정보인지. 역할이 결정되면 해당 스타일도 결정됩니다.
폰트 크기 중심의 사고에서 역할 중심의 사고로 이동합니다. 시각적 의사 결정에서 의미론적 의사 결정으로 이동합니다. 이것이 디자인 시스템의 진정한 가치가 있는 곳입니다. 훌륭합니다.
이쯤 되면 간격이든 폰트든 Vercel 이 동일한 작업을 수행하고 있음을 알 수 있습니다. 실행 단계에서의 자유로운 선택을 최대한 줄이고, 규칙을 미리 결정하여 실행은 단순히 역할을 선택하는 것만으로 충분하도록 하는 것입니다.
이는 디자이너에게도, 개발자에게도, AI 에게도 마찬가지입니다.
3
또한, 카피라이팅도 Vercel 디자인 명세서의 중요한 부분으로 취급됩니다. 이것은 대부분의 DESIGN.md 파일에서 가장 쉽게 누락되는 부분입니다.
Vercel 은 이러한 세부 사항을 매우 구체적으로 정의합니다.
예를 들어, 버튼 카피는 동작과 대상이 결합된 형태여야 합니다. "Deploy Project" 또는 "Delete Member" 와 같이 말이죠. "Deploy," "OK," 또는 "Delete" 와 같은 모호한 단어만 사용할 수 없습니다.
이유는 간단합니다. "Delete" 라는 단어만 보면 사용자는 정확히 무엇이 삭제되는지 생각해야 합니다. 동작과 대상이 함께 있으면 사용자는 즉시 완전한 이해를 형성할 수 있습니다.
오류 메시지도 비슷합니다. Vercel 의 규칙은 명확합니다. 먼저 사용자에게 무슨 일이 일어났는지 알려줍니다. 그런 다음, 사용자에게 다음에 무엇을 해야 하는지 알려줍니다.
예를 들어, 패키지 파일이 크기 제한을 초과하여 빌드가 실패한 경우, 해결 방법은 크기를 줄이거나 제한을 조정하는 것입니다. 세 문장을 읽은 후 사용자는 문제가 어디에 있는지, 다음에 무엇을 해야 하는지 즉시 알 수 있습니다.
많은 제품의 오류 프롬프트는 "작업이 실패했습니다. 나중에 다시 시도하세요." 와 같습니다. 이러한 프롬프트의 정보량은 거의 0에 가깝습니다. 사용자가 읽고 나서 얻는 유일한 정보는 실패했다는 것뿐입니다. 왜 실패했는지, 다음에 무엇을 해야 하는지는 여전히 추측해야 합니다.
디자인 시스템의 카피라이팅 명세서는 본질적으로 이러한 추측을 줄이는 것입니다.
Vercel 은 또한 작업 완료 후 알림 메시지를 표준화하여, 어떤 변경이 발생했는지만 명시하도록 합니다. 예를 들어, "Project deleted" 이지 "Project deleted successfully" 가 아닙니다.
프롬프트 상자가 나타날 수 있다는 사실 자체가 이미 작업이 완료되었음을 나타내기 때문입니다. "successfully" 라는 단어는 중복 정보입니다.
다음은 모션입니다.
이 부분은 특히 흥미로운데, 제 직관과 정반대이기 때문입니다. 저는 애니메이션이 많을수록 제품이 더 정교해진다고 생각했습니다.
따라서 버튼 호버나 메뉴 팝업에 약간의 애니메이션을 추가하면 고급스러워 보이는 것 같습니다. 현재 많은 Vibe Coding 제품들이 이 방향으로 나아가고 있는 것 같습니다.
하지만 Vercel 의 태도는 완전히 다릅니다. 그들은 많은 상호작용 시나리오에서 0 밀리초가 종종 최선의 선택이라고 명시적으로 적어 놓았습니다. 즉, 애니메이션 없이 즉시 완료하는 것입니다.
버튼이 기본 상태에서 호버 상태로 변경되는 경우, 이 변경 자체로 이미 충분히 명확합니다. 최고의 피드백은 즉시 발생하는 것입니다. 추가 애니메이션 레이어를 추가하면 오히려 인터페이스가 느리게 느껴질 수 있습니다.
물론 모션이 필요한 시나리오도 있습니다.
예를 들어, 팝업이 갑자기 나타나는 경우입니다. 전환 효과가 전혀 없으면 사용자는 그것이 어디서 왔는지 알 수 없습니다. 이것이 애니메이션이 가치를 가지는 경우입니다.
Vercel 은 다양한 시나리오에 대한 지속 시간까지 지정합니다. 일반적인 상태 변경은 약 150 밀리초, 팝오버는 약 200 밀리초, 모달은 약 300 밀리초입니다.
변경 사항이 클수록 더 많은 반응 시간이 주어집니다. 변경 사항이 작을수록 피드백은 더 직접적입니다.
그 뒤에 있는 논리는 항상 동일합니다. 필요하지 않으면 움직이지 말고, 움직여야 한다면 빠르고 가볍게, 절제된 움직임을 유지하라는 것입니다.
마지막으로 깊은 인상을 남긴 부분은 접근성입니다.
솔직히 말해서, 저는 이 부분에 특별히 신경을 거의 쓰지 않았습니다. 대부분의 경우 제품의 인터페이스가 보기 좋고 기능이 작동하면 충분해 보이기 때문입니다. 하지만 Vercel 은 이 부분을 매우 진지하게 작성했습니다.
Vercel 은 텍스트와 배경 사이에 충분한 대비를 요구합니다. 상태 변경은 색상에만 의존할 수 없으며, 아이콘이나 텍스트 설명과 함께 제공되어야 합니다.
모든 상호작용 요소는 명확한 포커스 상태를 가져야 하며, 시각적 깔끔함을 위해 제거되어서는 안 됩니다.
이러한 규칙은 디자인 시스템이 모든 사람, 즉 색상 민감도가 낮은 사람, 키보드로 탐색하는 사람, 밝은 빛에서 휴대폰을 보는 사람을 포함하여 모두를 위한 것임을 의미합니다.
이 DESIGN.md 는 너무 전문적입니다. 앞으로 새로운 제품을 만들 때마다 이 두 MD 파일의 아이디어를 기반으로 자신만의 DESIGN.md 를 작성할 수 있을 것 같습니다.
