README.md 한 장, LICENSE, 표지 이미지 한 장뿐이다.
alexpate/awesome-design-systems · 제작 Alex Pate · 라이선스 Unlicense(퍼블릭 도메인) · 파일 구성 README.md(약 40KB, 194행) + LICENSE + cover.png 단 3개 · 최신 커밋 4129da3 "fix markdown table"(2026-04-28) · 브랜치 1개(master))
awesome-design-systems는 "링크 모음집"이지 "프로그램"이 아니다. 저장소를 클론해도 npm install할 것도, 실행할 서버도 없다. 저장소의 실체는 단 세 파일 — README.md(194개 항목이 담긴 표), LICENSE(Unlicense), cover.png(표지 그림)뿐이다. README 맨 위에는 이 저장소가 인용하는 정의가 그대로 실려 있다.
즉 이 레포의 "산출물"은 코드가 아니라 표(table) 그 자체다. 각 행은 디자인 시스템 이름과 링크, 그리고 그 시스템이 무엇을 제공하는지를 나타내는 4개의 열(컴포넌트 / 보이스&톤 / 디자이너 키트 / 소스코드)로 구성된다. 기여 방법도 단 한 줄, "아래 없는 리소스를 아시나요? 풀 리퀘스트를 자유롭게 만들어 주세요"뿐이다.
이 레포는 도서관에 있는 책을 대신 읽어주지 않는다. 대신 어느 책장에 어떤 책이 있고, 그 책에 그림(디자이너 키트)이 있는지, 각주(소스코드)가 달려 있는지를 종이 카드 하나에 적어 목록함에 꽂아둔 것과 같다.
카드 자체는 매우 단순하지만, 194장을 손으로 정리해 한곳에 모아뒀다는 것 자체가 가치다. 구글에서 "design system"을 194번 검색하는 수고를 표 하나로 대체한다.
awesome-design-systems 자체는 오래된 형식(어썸 리스트)이지만, 이 주제가 다시 주목받는 이유는 최근 UI 생태계 변화와 맞물려 있다.
Claude·Cursor·v0 같은 AI 코딩 도구가 컴포넌트를 만들 때, 이미 검증된 디자인 시스템의 토큰 체계·네이밍·문서화 방식을 참고 자료로 쓰는 흐름이 커졌다. IBM Carbon, Shopify Polaris, Atlassian Design System처럼 실제 대기업이 공개한 원칙 문서는 "이렇게 만들면 된다"는 실물 예시가 된다. 194개를 한곳에 모아둔 이 표는 그런 벤치마킹의 출발점 역할을 한다.
이 표에는 GOV.UK, 미국 U.S. Web Design Standards, 프랑스 정부 DSFR, 이탈리아, 싱가포르 SGDS, 캐나다, 온타리오, 뉴욕주, 그리고 한국의 KRDS(Korea Design System)까지 국가·지자체 단위 디자인 시스템이 다수 포함돼 있다. 공공 디지털 서비스가 접근성·일관성을 위해 자체 디자인 시스템을 공개하는 것이 최근 세계적 흐름이 됐고, 이 저장소는 그 흐름을 비교적 잘 따라잡아 왔다.
Radix, Shadcn/ui, Chakra UI처럼 브랜드가 아니라 개발자를 위한 헤드리스·프레임워크형 라이브러리도 표에 함께 섞여 있다. README 하단의 주석에도 "'디자인 시스템'·'UI 라이브러리'·'패턴 라이브러리'는 서로 다르지만 흔히 혼용된다"고 스스로 밝히고 있어, 이 저장소가 전통적 브랜드 DS와 최신 컴포넌트 라이브러리 붐을 모두 담으려 한 흔적을 볼 수 있다.
구글 검색은 SEO에 밀려 최신 마케팅 페이지만 상위에 뜨기 쉽다. 이 저장소는 사람이 직접 골라 넣은 194개라는 점에서, "실제로 존재하고 실제로 참고할 가치가 있다"는 최소한의 필터를 거친 목록이다. 다만 뒤에서 볼 것처럼 이 필터는 인기도·최신성까지 보장하지는 않는다.
디자인 시스템을 새로 만들려는 팀, 혹은 참고 사례를 찾는 디자이너·개발자가 마주치는 첫 번째 벽은 "뭐부터 찾아봐야 할지 모른다"는 것이다. 회사마다 이름이 제각각이고("Backpack"이 Skyscanner의 DS라는 걸 어떻게 알겠는가), 검색어도 애매하다. 이 저장소는 이름 → 링크 → 무엇을 제공하는지를 한 줄에 압축해 이 벽을 낮춘다.
두 번째로 해결하는 문제는 "이 링크가 정말 쓸모 있는 자료인가"를 클릭해보기 전에 가늠하게 해주는 것이다. 회사 홈페이지의 그럴듯한 소개 페이지만 있고 실제 컴포넌트 코드나 Figma 파일은 없는 경우가 많은데, 4개 열(컴포넌트/보이스&톤/디자이너 키트/소스코드)이 이를 미리 걸러준다.
README 하단 Notes에는 이렇게 못박혀 있다: "오픈소스로 표시된 프로젝트라도 항상 자유롭게 쓸 수 있는 것은 아니다. 사용 전에 반드시 라이선스를 확인하라." 소스코드 아이콘(:octocat: 등)이 붙어 있다고 해서 그 코드를 내 제품에 그대로 가져다 써도 된다는 뜻이 아니다 — 각 프로젝트의 개별 라이선스를 따로 확인해야 한다.
구조를 파악하는 데는 5분도 걸리지 않는다. 저장소 루트에 파일이 딱 3개뿐이고, 그 중 실질적인 내용은 README.md 하나에 전부 들어 있다.
주목할 점은 없는 것들이다. 카테고리별 하위 폴더가 없고, 웹사이트 생성기(Jekyll·Docusaurus 등)가 없고, 태그별 필터링을 할 수 있는 JSON 데이터 파일도 없다. 194개 항목은 단 하나의 평평한(flat) 표 안에 전부 들어 있으며, 분류 축은 사실상 "이름의 알파벳 순서"뿐이다 — 회사별·업종별·기술스택별 그룹핑은 존재하지 않는다.
카테고리 폴더가 있는 위키가 아니라, 엑셀 시트 한 장에 가깝다. 정렬 기준은 A열(이름) 하나뿐이고, 나머지 4개 열은 체크박스(👍/공란)로만 채워져 있다. "검색"은 브라우저의 Ctrl+F에 의존한다.
이 표가 이 저장소의 전부이므로, 이 섹션이 가장 중요하다. 먼저 README가 직접 정의하는 4개 태그(열)의 의미부터 정확히 짚는다.
| 태그 | 보유 항목 수 / 194 | 비율 |
|---|---|---|
| Components | 158 | 약 81% |
| Voice & Tone | 70 | 약 36% |
| Designers Kit | 75 | 약 39% |
| Source code(모든 아이콘 합산) | 약 120 | 약 62% |
저장소 자체는 항목을 그룹으로 나누지 않지만, 실제 내용을 훑어보면 대략 이런 성격의 무리로 읽힌다. 대표 항목들을 성격별로 소개한다.
가장 오래되고 성숙한 축. IBM Carbon과 Google Material Design은 컴포넌트·보이스&톤·디자이너 키트·소스코드 4개 태그를 모두 갖춰(표에서 👍👍👍 + 옥토캣) "완전체" 디자인 시스템의 표준 예시로 자주 인용된다. Atlassian Design System은 코드가 GitHub이 아니라 Bitbucket 미러에 있어 표에서 :space_invader: 아이콘으로 구분된다.
정부기관 디자인 시스템만 따로 묶어도 10개에 가깝다. 접근성 규정을 지키면서 여러 부처가 재사용할 수 있게 만든다는 목적이 같아서, 서로 다른 나라인데도 구조가 비슷하다. Korea Design System(krds.go.kr)도 컴포넌트·보이스&톤·디자이너 키트를 모두 갖춘 항목으로 등재돼 있다.
실제 소비자 대상 제품을 만드는 회사들의 DS. GitHub Primer는 GitHub 자신의 UI를 만드는 데 쓰는 시스템이라 "메타적으로" 흥미롭고, Shopify Polaris는 전자상거래 어드민 UI의 정석으로 자주 언급된다.
브랜드 아이덴티티보다 개발자 생산성에 초점을 맞춘 항목들. README 자체가 "디자인 시스템·UI 라이브러리·패턴 라이브러리는 다르지만 혼용해서 쓴다"고 명시하는데, 바로 이 부류가 그 경계에 걸쳐 있다. Shadcn/ui는 2026년 현재 프론트엔드 생태계에서 가장 널리 쓰이는 컴포넌트 스타터 중 하나지만, 이 표에는 보이스&톤·디자이너 키트 없이 컴포넌트+소스코드만 표시돼 있다.
color-primary-500). 위 표의 "Components" 항목 대부분은 결국 이런 토큰을 기반으로 만들어진다.
이 저장소를 클론해서 살펴보면 가장 먼저 놀라는 지점이 정말로 자동화가 하나도 없다는 것이다. .github/ 폴더 자체가 없어 이슈 템플릿·PR 템플릿·GitHub Actions 워크플로가 전혀 존재하지 않는다. CONTRIBUTING.md도 없다. 링크가 살아있는지 주기적으로 검사하는 봇, 표 형식을 검증하는 린터, 알파벳 순서를 자동으로 맞춰주는 스크립트 — 이런 것도 전혀 없다.
기여 절차는 README 맨 위 한 줄이 전부다: "아래 없는 리소스를 아시나요? 풀 리퀘스트를 자유롭게 만들어 주세요." 실제로 최신 커밋(4129da3, 2026-04-28)의 메시지도 "fix markdown table"이라는 소박한 수작업 오타 수정이다 — 자동 생성 커밋의 흔적(예: chore: auto-update 같은 봇 메시지)이 전혀 없다.
표는 기본적으로 알파벳순이지만 완벽하지 않다. 예를 들어 "New York State Design System"은 알파벳상 "N-e"로 시작해 "N-o"인 Nordhealth보다 앞에 와야 하는데, 실제로는 Nordhealth 바로 다음 행에 끼워져 있다. "Vercel"과 "Ray by WeWork"도 각각 V·R로 시작하지만 표의 맨 끝 W 구간(Wix Style React, Welcome UI 근처)에 놓여 있다.
이는 새 항목이 PR로 들어올 때 기여자가 넣은 위치 그대로 병합되고, 전체 재정렬은 이뤄지지 않는다는 뜻이다. 자동화 스크립트가 있었다면 이런 구간은 존재하지 않았을 것이다.
자동화가 없다고 죽은 저장소는 아니다. 최신 커밋이 오타 수정이라는 것 자체가 관리자가 실제로 표 내용을 들여다보고 있다는 신호다. 다만 이 관리 방식이 "봇이 링크를 매일 검사하는" 방식이 아니라 "관리자 한 명이 PR을 눈으로 검토하는" 방식이라는 점을 이해하고 써야 한다.
| 항목 | 내용 |
|---|---|
| 실행 환경 | 없음. GitHub에서 README.md를 웹으로 읽거나, 로컬에 클론해 마크다운 뷰어로 열면 끝 |
| 검색 방법 | 표 안 필터 기능이 없으므로 브라우저 Ctrl+F(또는 GitHub 코드 검색)로 이름을 찾아야 함 |
| 프로그래밍적 활용 | JSON·CSV 내보내기가 없어, 표를 데이터로 쓰려면 마크다운 표 파싱(정규식 또는 pandas의 read_html류 유틸)을 직접 해야 함 |
| 각 링크의 기술 요구사항 | 레포 자체는 명시하지 않음 — React 전용인지, Vue·Web Components인지는 클릭해서 직접 확인해야 함 |
| 라이선스 확인 | README가 직접 경고하듯 각 프로젝트의 개별 라이선스를 사용 전 반드시 확인 |
이 표는 "설치 요구사항"이 없는 대신, 194개의 서로 다른 문 앞에 붙은 안내판과 같다. 안내판(표의 4개 열)은 문 안에 무엇이 있는지 미리 알려주지만, 문을 열고 들어가면 그 안의 규칙(라이선스, 프레임워크, 유지보수 상태)은 collection이 아니라 각 방(개별 프로젝트)마다 다르다.
이 표를 실제 업무에 써먹는 전형적인 흐름은 "전부 다 본다"가 아니라 목적에 맞게 좁혀 들어가는 것이다.
컴포넌트 구현 참고가 필요하면 Components 👍 항목 위주로, 브랜드 문구 가이드가 필요하면 Voice & Tone 👍 항목 위주로, Figma 킷이 필요하면 Designers Kit 👍 항목 위주로 Ctrl+F 훑는다.
공공기관이면 GOV.UK·USWDS·KRDS 같은 정부 DS 묶음을, 이커머스면 Shopify Polaris·Skyscanner Backpack을, 개발자 도구를 만든다면 Radix·Shadcn/ui·Chakra UI 같은 헤드리스 라이브러리를 우선 본다.
:octocat: 등 코드 아이콘이 있는 약 120개는 실제 구현(색상 토큰 파일, 컴포넌트 API 설계)을 코드 레벨에서 뜯어볼 수 있다. 문서 페이지만 있는 항목보다 훨씬 구체적인 참고가 된다.
여러 후보의 토큰 네이밍(예: color-brand-primary vs colorBrandPrimary), 컴포넌트 문서 구성(속성 표, 접근성 노트 유무)을 나란히 비교해 자신의 팀 DS 로드맵에 반영한다.
여러 나라의 여행 가이드북을 몽땅 사는 대신, 내가 갈 나라와 비슷한 기후·문화권의 가이드북 몇 권만 골라 정독하는 것과 같다. 194개를 전부 볼 필요는 없다 — 목적과 유사도로 좁히는 것이 핵심이다.
앞서 6번 섹션에서 확인했듯 New York State Design System·Vercel·Ray by WeWork처럼 알파벳 순서가 깨진 구간이 실제로 존재한다. 이름의 예상 위치로 스크롤해서 찾다가 못 찾으면, Ctrl+F로 이름을 직접 검색하라. 위치 기반 탐색은 이 표에서 신뢰할 수 없다.
표는 순전히 이름 알파벳순으로만 나열돼 있고, 어떤 디자인 시스템이 더 유명하거나 더 잘 관리되는지 알려주는 지표(스타 수, 최근 업데이트일, 다운로드 수 등)가 전혀 없다. "목록에 있다" = "인기 있다"가 아니다. 잘 알려지지 않았거나 유지보수가 뜸한 항목도 유명한 항목과 똑같은 한 줄로 나란히 놓여 있다.
자동 링크 검사 봇이 없으므로(6번 섹션 참고), 시간이 지나며 회사가 리브랜딩하거나 프로젝트가 정리되면 링크가 죽거나 다른 곳으로 넘어갈 수 있다. 실제로 이 문서 작성 시점 스팟체크에서는 표본 링크들이 살아있었지만, 중요한 의사결정 전에는 직접 열어 확인하는 습관이 필요하다.
위 함정들은 이 저장소가 "실시간 데이터베이스"가 아니라 사람이 손으로 쌓아온 스냅샷임을 보여줄 뿐, 가치를 없애지는 않는다. 194개를 무작위 검색보다 훨씬 빠르게 훑을 수 있다는 것만으로도 충분한 출발점이다. 다만 "이 목록이 곧 진실"이라는 태도 대신 "이 목록은 출발점, 검증은 내 몫"이라는 태도로 접근해야 한다.
"디자인 시스템 모음"이라는 같은 목적을 다른 형태로 푸는 자료들과 비교하면 이 저장소의 위치가 더 선명해진다.
| 자료 | 형태 | 강점 / 약점 |
|---|---|---|
| awesome-design-systems (이 레포) | 정적 마크다운 표, GitHub PR로만 갱신 | 가볍고 오프라인·클론 가능. 검색·필터 UI는 없음, 정렬 오류 존재 |
| Storybook Showcase | Storybook 공식 웹사이트의 실제 서비스 갤러리 | 실제 프로덕션에 Storybook을 쓰는 사례 위주로 스크린샷과 함께 소개. 검색은 되지만 "Storybook 사용" 여부로 걸러진 하위집합 |
| component.gallery류 컴포넌트 단위 갤러리 | 여러 디자인 시스템의 같은 컴포넌트(버튼·폼 등)를 나란히 비교하는 사이트 | "버튼 하나만 비교"처럼 세밀한 벤치마킹에 강함. 시스템 전체 개요를 보긴 어려움 |
| 각 회사 디자인 시스템 자체 사이트 | 개별 공식 문서(예: carbondesignsystem.com) | 가장 정확하고 최신이지만, 한 곳씩 따로 찾아야 하며 비교 관점이 없음 |
요약하면, 이 저장소의 위치는 "가장 가볍고, 가장 넓고(브랜드 DS부터 헤드리스 라이브러리까지), 대신 가장 수동적인" 큐레이션이다. 탐색 경험을 원하면 갤러리형 사이트가 낫고, 폭넓게 훑어보며 이름과 링크만 빠르게 확보하고 싶다면 이 표가 여전히 효율적이다.
· 팀에서 처음으로 디자인 시스템을 만들려는 디자이너·프론트엔드 개발자 — "다른 곳은 어떻게 했나"를 194개 사례로 빠르게 훑어볼 수 있다.
· 특정 업종(정부·이커머스·SaaS)의 동종 사례를 벤치마킹해야 하는 PM·디자이너.
· 디자인 시스템 개념을 강의·스터디로 가르치는 사람 — 실물 예시 링크 모음으로 훌륭한 부교재가 된다.
· 실시간 인기 순위나 최신성이 보장된 데이터가 필요한 경우 — 이 표는 스타 수도, 최근 업데이트일도 보여주지 않는다.
· 프로그램적으로 처리할 구조화된 데이터(API·JSON)가 필요한 경우 — 마크다운 표를 직접 파싱해야 한다.
· "이 링크는 100% 최신"이라는 보장이 필요한 중요 의사결정의 유일한 근거로 쓰는 경우 — 링크 검사 자동화가 없으므로 직접 검증이 필수다.