당근 SEED는 컴포넌트 모음이 아니라 제품 운영 방식이다

좋은 디자인 시스템은 컴포넌트 목록에서 끝나지 않습니다. 반복되는 결정을 줄이고 여러 팀이 같은 기준으로 판단하게 만들며, 제품이 커져도 브랜드의 인상을 잃지 않게 하는 운영 방식에 가깝습니다.

당근의 SEED Design System은 이 기준에서 흥미로운 사례입니다. 겉으로는 당근 제품을 위한 디자인 시스템입니다. 하지만 문서를 따라가 보면 단순히 버튼과 토큰을 공개한 사이트가 아닙니다. SEED는 브랜드, 접근성, Figma 구조, React/Lynx 구현, AI 도구 연동을 하나의 작업 흐름으로 묶으려 합니다.

SEED의 핵심은 당근다운 결정을 반복하게 만드는 것입니다

SEED 문서는 스스로를 “당근 제품을 위한 통합 디자인 언어”라고 설명합니다. 색, 타이포그래피, 간격, 아이콘 같은 파운데이션부터 버튼·리스트 같은 컴포넌트, 모션까지 제품을 이루는 결정을 하나의 체계로 정리합니다.

여기서 중요한 대목은 디자인과 코드가 같은 기준을 보게 만든다는 점입니다. 디자인 시스템을 예쁜 UI 키트가 아니라, 디자이너와 엔지니어 사이의 오해를 줄이는 공통 언어로 보는 관점입니다.

SEED는 현재 문서 기준으로 50개가 넘는 컴포넌트 레퍼런스를 갖고 있습니다. Accordion, Action Button, Bottom Sheet, Field, List, Skeleton, Snackbar처럼 모바일 제품에서 자주 쓰는 기본 단위가 있고 Manner Temp처럼 당근 서비스의 고유한 맥락을 담은 컴포넌트도 있습니다.

하지만 숫자보다 중요한 것은 구조입니다. SEED는 Foundation, Components, Patterns, React, Lynx, AI & Tools, Updates를 나눠둡니다. 이 구분은 “무엇을 그릴까”보다 “어떤 결정은 어디에서 다뤄야 할까”에 가깝습니다.

글로벌 디자인 시스템과 비교하면, SEED는 규모보다 운영 밀도가 보입니다

Material Design이나 Apple HIG는 전 세계 개발자와 디자이너가 참고하는 플랫폼 규칙에 가깝습니다. IBM Carbon, Shopify Polaris, Atlassian Design System, Microsoft Fluent는 큰 조직이 여러 제품을 일관되게 운영하려고 만든 시스템입니다.

SEED는 이들과 같은 체급의 범용 플랫폼 시스템은 아닙니다. 당근이라는 특정 제품군의 문제를 풀기 위해 만들어졌고, 한국어 문서와 당근의 사용 맥락이 강하게 남아 있습니다. 그래서 오히려 비교 지점이 선명합니다.

이 비교에서 SEED의 한계는 분명합니다. 글로벌 독자가 바로 가져다 쓰기에는 당근 맥락이 강합니다. Material이나 Fluent처럼 플랫폼 레벨의 영향력을 갖지도 않습니다. Polaris처럼 특정 업무 흐름을 끝까지 풀어낸 패턴 라이브러리도 아직 두껍지는 않습니다.

대신 SEED에는 다른 장점이 있습니다. 이 시스템은 “디자인 시스템을 어떻게 계속 고칠 수 있게 만들 것인가”라는 운영 관점이 강합니다.

V3에서 흥미로운 지점은 접근성을 취향이 아니라 구조로 다룬다는 점입니다

SEED의 V3 업데이트 글에서 가장 인상적인 부분은 접근성입니다. 기존 시스템은 색상 대비, 터치 영역, 포커스 상태, 토큰 영향도 관리에서 한계를 갖고 있었고, V3는 이 부분을 다시 세우는 개편으로 소개됩니다.

특히 색을 전경(fg), 배경(bg), 외곽선(stroke)으로 나누고 역할 기반의 의미를 부여한 점이 중요합니다. 색상을 예쁜 팔레트로 관리하는 것이 아니라, 상태와 위계와 접근성을 함께 보장하는 언어로 바꾼 것입니다.

Inclusive Design 문서도 구체적입니다. 텍스트 대비는 APCA 기준을 언급하고, 터치 영역은 44x44px 이상을 이상적인 기준으로 제시합니다. 애니메이션은 prefers-reduced-motion 같은 사용자 설정을 고려해야 한다고 말합니다.

이 기준은 글로벌 시스템과도 이어집니다. Material Design과 Apple HIG도 접근성을 기본 원칙으로 둡니다. Carbon 역시 엔터프라이즈 환경에서 접근성과 일관성을 강하게 다룹니다. SEED가 흥미로운 이유는 이 기준을 한국의 모바일 서비스 맥락, 특히 중고거래·동네생활처럼 넓은 연령대가 쓰는 제품의 UI 문제로 옮긴다는 점입니다.

SEED가 가장 당근다운 순간은 디자인 시스템에도 별도 브랜드를 붙였다는 점입니다

보통 사내 디자인 시스템은 모브랜드 로고를 그대로 가져다 씁니다. “회사 이름 + Design System”이면 충분해 보이기 때문입니다. 하지만 SEED는 별도의 이름과 얼굴을 만들었습니다.

SEED 업데이트 글은 이 결정을 꽤 중요하게 다룹니다. 디자인 시스템은 내부 도구이지만, 그 도구의 사용자는 제품을 만드는 디자이너와 엔지니어입니다. 고객이 만나는 당근 앱과 만드는 사람이 매일 보는 시스템은 같은 브랜드 안에 있어도 다른 말투가 필요합니다.

이 판단은 글로벌 디자인 시스템에서도 자주 보입니다. Shopify Polaris는 Shopify의 상인 중심 세계관을 제품 제작 언어로 바꿉니다. Atlassian은 협업과 팀워크의 언어를 디자인 원칙에 반영합니다. IBM Carbon은 IBM의 엔터프라이즈 신뢰감을 시각 언어와 개발 도구로 옮깁니다.

SEED도 같은 질문을 던집니다. “당근답다”는 인상을 로고와 앱 화면에만 남겨두지 않고, 그것을 만드는 사람들의 도구에도 어떻게 심을 것인가. 이 점에서 SEED는 단순한 내부 라이브러리가 아니라 당근이라는 조직이 제품을 만드는 방식을 보여주는 채용·브랜드 자산이 됩니다.

Figma에서 코드까지, SEED는 나열보다 조합을 선택합니다

SEED V3 글에서 실무자가 가장 눈여겨볼 부분은 Figma 구조입니다. 기존에는 가능한 경우의 수를 Variant로 펼쳐두는 방식이 많았지만, SEED는 Property 조합과 Slot을 더 적극적으로 사용한다고 설명합니다.

이 변화는 작아 보이지만 디자인 시스템 운영에서는 큽니다. Variant를 계속 늘리면 처음에는 사용하기 쉽습니다. 하지만 제품이 커질수록 관리해야 할 경우의 수가 곱으로 늘어납니다. 반대로 Property와 Slot은 처음에는 조금 더 추상적이지만, 장기적으로는 컴포넌트가 덜 부풀고 팀이 필요한 조합을 만들 수 있습니다.

이 지점은 shadcn/ui 이후의 프론트엔드 컴포넌트 흐름과도 닿아 있습니다. 닫힌 컴포넌트를 그대로 가져다 쓰는 것보다 구조를 이해하고 팀의 맥락에 맞게 조립할 수 있는 방식이 더 중요해졌습니다. SEED의 React 문서도 Compound Component와 Snippet, CLI를 함께 다루며 이 균형을 잡으려 합니다.

디자인 시스템이 오래 살아남으려면 정답 컴포넌트만 제공해서는 안 됩니다. 팀이 제품 맥락에 맞게 바꿀 수 있어야 합니다. 동시에 바꾸는 과정에서 시스템의 기준을 잃지 않아야 합니다. SEED가 Slot과 Property, Snippet을 강조하는 이유도 여기에 있습니다.

AI 시대의 디자인 시스템은 사람이 읽는 문서만으로 부족합니다

SEED에서 가장 현재적인 대목은 AI & Tools입니다. SEED는 llms.txt를 제공하고 문서용 MCP 서버와 Figma MCP, Codegen을 소개합니다. AI Agent가 React 컴포넌트, 디자인 가이드라인, Foundation, Rootage, 아이콘 정보를 직접 읽게 하려는 시도입니다.

이것은 디자인 시스템의 역할이 바뀌고 있다는 신호입니다. 과거의 디자인 시스템 문서는 사람이 검색해서 읽는 자료였습니다. 이제는 에이전트가 코드를 만들고, 컴포넌트를 고르고, 마이그레이션을 제안하는 과정에서 참조해야 하는 데이터가 됩니다.

여기서 SEED는 글로벌 시스템보다 빠르게 움직이는 면이 있습니다. Material, Carbon, Polaris도 문서는 잘 갖춰져 있지만 SEED처럼 첫 화면의 정보 구조에서 AI 도구 연동을 분명히 드러내는 시스템은 아직 흔하지 않습니다. 물론 이것이 곧 완성도를 의미하지는 않습니다. 중요한 것은 방향입니다. 디자인 시스템이 사람의 기억을 돕는 문서에서, 사람과 에이전트가 함께 쓰는 실행 가능한 지식 베이스로 이동하고 있습니다.

SEED의 한계도 분명합니다

좋은 점만 보면 과대평가하기 쉽습니다. SEED는 아직 글로벌 범용 디자인 시스템과 같은 넓이를 갖고 있지는 않습니다.

첫째, 당근 맥락이 강합니다. 이것은 장점이자 한계입니다. 당근다운 제품을 만드는 데는 강하지만 다른 조직이 바로 가져다 쓰기에는 브랜드와 제품 맥락을 분리해서 읽어야 합니다.

둘째, 패턴 레이어는 더 두꺼워질 여지가 있습니다. 컴포넌트와 파운데이션 문서는 비교적 풍부하지만 제품 문제를 어떻게 푸는지 보여주는 Patterns는 아직 Loading처럼 일부 주제에 집중되어 있습니다. Polaris나 Atlassian처럼 업무 흐름 단위의 판단 가이드가 늘어나면 SEED의 디자인 지식은 더 강해질 수 있습니다.

셋째, 공개 디자인 시스템은 꾸준한 유지보수가 곧 신뢰입니다. SEED는 업데이트와 changelog, migration 문서를 갖추고 있지만 공개 시스템으로 오래 신뢰받으려면 “계속 갱신되고 있다”는 신호가 더 중요해집니다.

crit의 관점: SEED가 보여주는 가능성과 질문

SEED를 좋게 볼 수 있는 지점은 명확합니다. 이 시스템은 예쁜 컴포넌트 사이트를 만들려는 프로젝트라기보다, 당근이라는 제품이 반복해서 내려야 하는 결정을 코드와 문서와 도구로 고정하려는 시도에 가깝습니다. 특히 접근성, 색상 토큰, Figma 구조, React 문서, AI 도구 연동을 하나의 흐름으로 묶으려는 태도는 지금 공개된 많은 디자인 시스템보다 현재적입니다.

가장 흥미로운 점은 SEED가 브랜드를 장식으로 보지 않는다는 것입니다. Rooted, Rootage, 당근다움 같은 언어는 취향 설명에 머물 수도 있었습니다. 하지만 SEED는 그 언어를 컴포넌트와 토큰, 접근성 기준 쪽으로 끌어내리려 합니다. 디자인 시스템이 브랜드 가이드와 엔지니어링 문서 사이에서 갈라지지 않고 같은 운영 구조 안에 들어갈 수 있다는 가능성을 보여줍니다.

하지만 그래서 더 까다로운 질문도 남습니다. SEED는 강하게 당근의 맥락을 가집니다. 이것은 장점이지만 공개 디자인 시스템으로 읽힐 때는 한계이기도 합니다. Material Design이나 Carbon처럼 다른 조직이 바로 빌려 쓸 수 있는 범용 언어라기보다, “당근은 이런 식으로 제품 결정을 관리한다”는 내부 운영의 공개판에 가깝습니다. SEED의 가치를 컴포넌트 수나 문서량으로 평가하면 핵심을 놓치기 쉽습니다.

아쉬운 점은 Patterns 레이어입니다. Foundation과 Component는 충분히 설득력 있지만 제품 문제를 어떤 기준으로 풀어야 하는지 보여주는 패턴 문서는 아직 더 두꺼워질 여지가 있습니다. Polaris나 Atlassian이 강한 이유는 버튼과 토큰뿐 아니라, 복잡한 업무 흐름에서 어떤 판단을 해야 하는지까지 문서화하기 때문입니다. SEED가 다음 단계로 가려면 당근다운 화면을 넘어 당근다운 문제 해결 방식을 더 많이 보여줘야 합니다.

생각할 질문은 이것입니다.

• SEED는 공개 디자인 시스템인가, 아니면 잘 공개된 내부 운영 방식인가
• 디자인 시스템의 브랜드성은 어디까지 스펙이 될 수 있나
• AI가 읽는 디자인 시스템 문서는 사람을 위한 문서와 얼마나 달라져야 하나
• 접근성과 토큰은 제품 품질을 보장하는가, 아니면 품질을 논의할 최소 조건을 만드는가
• 좋은 디자인 시스템은 컴포넌트를 많이 제공하는 시스템인가, 반복되는 판단을 줄이는 시스템인가

SEED의 강점은 “글로벌 시스템만큼 크다”가 아닙니다. 오히려 반대입니다. 특정 제품과 조직의 맥락을 깊게 품은 상태에서, 그 결정을 코드·문서·도구·AI가 읽을 수 있는 형태로 정리하려 한다는 점이 흥미롭습니다. 동시에 그 깊이가 넓이로 확장될 수 있을지는 아직 열려 있습니다. SEED를 볼 때 가장 생산적인 태도는 따라 하는 것이 아니라, 이 시스템이 어떤 판단을 고정했고 어떤 판단을 아직 문서 밖에 남겨두었는지 읽는 것입니다.

seed-design.io

seed-design.io ↗

seed-design.io

seed-design.io ↗

seed-design.io

seed-design.io ↗