팀 프로젝트에서 프론트엔드 개발을 하다 보면 디자인 시스템의 필요성을 느끼는 순간이 옵니다. 일회용 컴포넌트 하나하나를 처음부터 만드는 것도 비생산적이지만, 여러 사람이 함께 작업하면서 색상, 간격, 타이포그래피 같은 디자인 원칙을 일관되게 유지하는 게 더 어렵거든요. 해외에는 예전부터 Bootstrap, Material UI, Chakra UI, Mantine, Ant Design 같은 오픈 소스 디자인 시스템을 통해서 이러한 문제를 체계적으로 해결했습니다.

그런데 국내에서는 쓸 만한 오픈 소스 디자인 시스템을 찾기가 쉽지 않습니다. 회사의 보안 정책 상 어느 특정 시점의 코드만 공개된 후 전혀 유지보수가 되지 않거나, 반대로 디자인만 Figma나 별도 웹사이트를 통해 공개되고 소스 코드는 공개하지 않는 경우가 대부분이거든요. 그나마 범정부 디자인 시스템(KRDS)이 디자인과 코드가 모두 공개되어 있었지만 아무래도 관공서를 위해 만들어진 것이라 일반 서비스에 쓰기에는 너무 경직된 느낌이 있습니다.

해외 디자인 시스템을 그대로 쓸 수도 있지만 한국어 최적화가 아쉽다고 말씀하시는 디자이너와 개발자 분들이 많습니다. 영어에서는 자연스럽게 보이다가 한국어를 넣는 순간 어딘가 어색해지는 경우 한 번쯤 겪어보셨을 겁니다. 서체, 자간, 줄 간격, 텍스트와 아이콘과의 비율 등 한글 타이포그래피는 영문과 특성이 다른데, 해외 디자인 시스템이 그 미묘한 차이를 섬세하게 고려하기가 쉽지 않습니다. 그래서 설사 해외 디자인 시스템을 도입한다고 하더라도 커스터마이징을 하고 디자인 시스템의 버전이 올라갈 때마다 유지보수하느라 배보다 배꼽이 더 커지는 경우도 생깁니다.

한국에서 일 하시는 프론트엔드 개발자 분들과 대화를 나누면서 접근성에 대한 고민도 많이 들었습니다. 접근성을 경시하는 업계의 관행과 부족한 인식, 그리고 늘 빡빡한 일정에 쫓기다 보니 시각적인 부분만 챙기기도 급급하고, 접근성이 중요한 걸 알면서도 항상 우선순위에 밀리게 됩니다. 관련된 내용으로 링크드인에 글을 쓴 적이 있는데, 300개가 넘는 좋아요가 달릴 정도로 많은 분들이 공감해 주셨어요.

🔗 LinkedIn 원문 보기

한국어 사용자 경험을 최우선하면서도 접근성 문제를 개발자에게 의존하지 않고 최대한 컴포넌트 수준에서 해결해줄 수 있는 국산 디자인 시스템이 있었으면 좋겠다는 생각이 들기 시작했습니다.

---

무모한 도전

이러한 디자인 시스템에 대한 갈증은 온라인 커뮤니티인 달레 스터디에도 일어나고 있었습니다. 커뮤니티에서는 웹사이트부터 학습 관리 도구, AI 챗봇까지 다양한 프로젝트가 진행되고 있습니다. 그런데 멤버들이 대부분 취업 준비생이거나 주니어 개발자인 데다가 제대로 된 디자이너 없이 프로젝트를 진행하다 보니, 원래 목표한 주요 기능보다 UI 구현에 너무 많은 시간을 쏟게 되었습니다. 그렇다고 아무 컴포넌트 라이브러리를 쓰자니 그마저도 새롭게 학습해야 하는 부담이었고, 프로젝트마다 다른 라이브러리를 쓰면 유지보수가 어려워질 게 뻔했습니다. 같은 커뮤니티에서 만든 도구와 서비스인데 느낌이 너무 달라 디자인 일관성 문제도 나타났습니다. 자연스럽게 커뮤니티 안에서 다 같이 사용할 디자인 시스템에 대한 니즈가 생기게 되었습니다.

이런 고민들이 머릿속에 조용히 쌓여가던 2025년 2월, 마침내 결심을 굳히고 링크드인에 글을 올렸습니다.

🔗 LinkedIn 원문 보기

솔직히 반신반의했거든요. "좋은 라이브러리 많은데 뭐하러 직접 만들려고 하냐", "한국에서는 오픈 소스 프로젝트 안 된다." 이런 우려가 나올 거라 생각했는데, 의외로 170개의 좋아요와 34개의 댓글이 달렸습니다. 공감해주시는 분들이 많아서 정말 큰 용기가 되었어요. 응원에 힘입어 그동안 품고 있던 생각을 좀 더 구체화하기 시작했습니다.

물론 처음부터 거창한 목표를 세운 건 아니었어요. 해외 디자인 시스템들은 규모가 워낙 크고, 기업들이 후원을 받고 있고 기여자가 수백, 수천 명에 달하거든요. 그런 디자인 시스템과 경쟁한다는 것은 현실적인 목표로 느껴지지 않았습니다. 그래서 처음 목표는 소박했어요. 한국에서도 오픈 소스로 디자인 시스템도 만들 수 있다는 걸 보여주는 레퍼런스, 이러한 일에 가치를 느끼는 디자이너와 개발자들이 모여서 성장할 수 있는 팀, 그 정도면 충분하다고 생각했습니다.

---

드림팀 완성

디자인 시스템을 만들기로 결심은 했지만 절대 혼자할 수 없는 일이라는 것은 과거 두 번이 도전을 통해서 알고 있었습니다. 그래서 팀원을 모집해야했는데 아직 스스로를 설득할 수 있는 검증 과정이 필요했어요. 그래서 저의 생각에 가장 먼저 공감해주신 세환 님과 둘이서 먼저 PoC(Proof of Concept)를 시작했습니다. 약 6개월 동안 다양한 기술 스택을 검토하고 프로토타입을 만들어 보면서 방향성을 잡아갔어요. 어떤 UI 프레임워크와 라이브러리를 사용할지, 스타일링은 런타임이냐 빌드 타임이냐, 접근성은 어떻게 보장할 것이냐. 수많은 선택지 앞에서 하나씩 답을 찾아가는 과정이었고, 이 과정에서 얻은 결론들은 테크 스택 선정 과정 A to Z 블로그에 자세히 정리해 두었습니다. PoC를 통해 기술적 방향에 확신이 생기니 슬슬 팀을 꾸려도 되겠다는 생각이 들었습니다.

저는 이전에 회사 두 곳에서 디자인 시스템 프로젝트를 해본 경험이 있는데, 하나는 실패했고 하나는 성공했어요. 그래서 디자인 시스템을 만드는 데 얼마나 많은 시간과 노력이 들어가는지, 실력있고 성실한 디자이너와 개발자를 모시는 게 얼마나 중요한지 잘 알고 있었습니다.

🔗 LinkedIn 원문 보기

모집 글을 올리자 정말 많은 분들이 연락을 주셨어요. 개발자만 수십 명이 지원해 주셨는데, 링크드인을 통해 연락을 주신 분들뿐 아니라 달레 스터디 커뮤니티에서 이미 다른 프로젝트를 진행하던 분들도 디자인 시스템에 대한 니즈가 있었기에 자연스럽게 합류하셨습니다.

디자이너 쪽은 사정이 좀 달랐어요. 열 명 이상 지원해 주셨지만 디자인 시스템 경험이 있는 분을 찾기가 쉽지 않았거든요. 커피챗을 해보면 디자인 시스템에 대한 개념도 확실하지 않은데 지원하신 분들도 계셨습니다. 그런데 정말 운이 좋게도 영국, 캐나다, 한국에서 각각 한 분씩 디자인 시스템을 직접 구축해 본 경험이 있는 디자이너분들이 관심 있다고 연락을 주셨어요. 심지어 그중 한 분은 디자인 시스템 관련 강의까지 하고 계신 분도 있었습니다. 세 분이 동시에 합류하셨을 때 솔직히 "이건 어벤져스 아닌가?" 싶었어요. 개발자 쪽도 마찬가지였습니다. 프론트엔드 경험이 풍부한 분들, 오픈 소스 기여 경험이 있는 분들이 하나둘 모이면서 정말 강력한 팀이 만들어졌어요.

이렇게 팀이 꾸려지고 가장 먼저 한 일은 비전 워크숍이었습니다. 개발자와 디자이너가 한자리에 모여 "우리는 무엇을 위해 모였는가?"라는 질문에 대한 답을 함께 만들어갔어요. 그 결과물이 달레 UI의 Charter입니다.

미션: 한국어 환경에 맞는 오픈소스 디자인 시스템을 만들어 디자이너와 개발자가 접근성 높은 프로덕트를 쉽고 빠르게 함께 만들도록 돕습니다.

핵심가치도 세 가지를 도출했는데요. 우선 한국어 타이포그래피의 특성과 국내 사용 패턴을 깊이 이해하고 반영하는 한국어 사용자 중심 설계, 그리고 접근성(WCAG) 준수와 피그마-코드 일치, 예측 가능한 API로 믿고 쓸 수 있는 경험을 만드는 신뢰할 수 있는 시스템, 마지막으로 모든 설계 결정의 근거를 공개하고 누구나 같은 방향으로 기여할 수 있도록 문서화와 기여 가이드를 꾸준히 관리하는 커뮤니티 중심 발전입니다. 이 Charter가 있었기에 이후 모든 기술적 선택과 디자인 결정에서 "이게 우리 미션에 맞는가?"라는 기준을 세울 수 있었어요.

---

함께 일하는 법

팀이 꾸려지고 비전이 정해지자 이제 실제로 함께 일하는 구조를 만들어야 했습니다. 다들 본업이 있는 상태에서 팀원들이 전세계에 흩어져 있으니 이 부분이 특히 중요했어요.

2주 단위의 스프린트로 운영했는데, 매주 주말에 디스코드에서 화상 회의를 했습니다. 시차 때문에 낮 시간은 불가능해서 주로 아침 일찍이나 저녁 늦게, 모두가 겨우 맞출 수 있는 시간에 모였어요. 첫째 주에는 스프린트 중간 점검을, 둘째 주에는 스프린트를 마무리하며 회고를 진행했고, 회의 시간에는 각자 작업한 내용을 데모하고 안건이 있으면 함께 논의했습니다.

팀원들이 얼굴을 보고 소통할 수 있는 시간이 매우 제한적이었기 때문에 비동기 소통에 크게 의존해야 했습니다. 그런데 예상 못한 문제가 생겼어요. 개발자들은 주로 GitHub에서 일하고 디자이너들은 주로 Figma에서 일하다 보니 처음에는 소통이 원활하지 않았습니다. 개발자들은 Figma의 UI가 익숙치 않아 댓글을 다는 게 불편했고, 디자이너들은 개발자들이 기대하는 만큼 GitHub의 PR이나 이슈에 피드백을 주지 않았습니다. 처음에는 가급적 Figma에서 대화를 모으기로 했다가 나중에는 모두 GitHub에서 대화하자로 바꾸기도 했습니다. 그래서 Storybook과 Figma 간에 쌍방 연동을 강화하고, Chromatic과 같은 디자이너와 개발자 간에 협업을 돕는 도구도 활용하였습니다.

프로젝트 관리는 GitHub Projects를 마치 Jira처럼 사용했어요. 이슈를 티켓처럼 활용하고 PR과 연결해서 프로젝트의 진행 상황을 추적했습니다. 일반적인 제품 개발처럼 디자이너가 목업을 개발자에게 핸드오프하면 끝이 아닌 디자인 토큰 설계 단계부터 디자이너와 개발자가 밀접하게 소통해야 했거든요. 개발자들은 이 디자인 시스템을 실제로 UI를 구현할 엔지니어의 입장에서 "API가 직관적인가? 사용하기 쉬운가?"를 고민했고, 디자이너들은 이 디자인 시스템으로 디자인할 디자이너의 입장에서 "디자인하기 쉬운가? 유연한가?"를 고민했습니다. 같은 컴포넌트를 두고 서로 다른 직군의 관점에서 바라보는 것, 여기서 발생하는 간극을 최소화하고 오해를 줄이기 위해서 디자이너와 개발자가 서로의 입장을 이해하면서 소통해야 했습니다.

"우리는 어떻게 함께 일하는가?"에 대한 팀 규범(Norms)도 문서화했습니다. 100% 원격에 시차까지 있는 환경에서 건강한 협업 문화를 만들려면 꼭 필요한 작업이었어요. 코어 팀(내부 기여자)과 외부 기여자의 역할을 명확히 구분했는데, 코어 팀은 GitHub, Figma, Discord, Chromatic 등 주요 도구에 수정 권한을 갖고 외부 기여자의 기여를 검토하고 승인하는 역할을 맡았습니다. 권한이 큰 만큼 더 높은 주인의식과 책임감이 필요했고요.

코어 팀에게는 몇 가지 기본 기대치를 세웠어요. 주당 최소 5시간은 프로젝트에 참여하고, 전체 회의는 2회 연속으로 빠지지 않기로 했습니다. 2주 스프린트에서 회의를 두 번 빠지면 6주간의 소통 공백이 생겨서 현실적으로 프로젝트를 따라가기 어렵거든요. 비동기 질의에는 48시간 안에 응답하기로 했는데, 비동기 소통에서 병목이 발생하면 팀 전체의 속도뿐 아니라 팀원 간 신뢰에도 영향을 주기 때문이었어요. 그리고 하나의 원칙을 특별히 강조했습니다. "Under-communicate보다 Over-communicate가 낫다." PM이 따로 없었기에 "모두가 PM"이라는 마음가짐으로 좀 더 적극적인 자세로 프로젝트에 임해야 했어요. 스스로 티켓을 만들고 요구사항을 작성하고 서로의 이름을 멘션하는 것을 미안해하지 않는 문화를 지향했습니다.

원활한 의사소통을 위해서 화상 회의에서는 카메라를 켜고, 화면 공유 시에는 라이트 모드를 사용하자는 에티켓도 정했어요. 사소해 보이지만 원격 환경에서 서로에 대한 배려를 보여주는 작은 약속들이었습니다. 무엇보다 인상적이었던 건 커피챗 문화인데요. 2주마다 랜덤으로 팀원을 매칭해서 1:1 커피챗을 했어요. 일 얘기에서 벗어나 서로를 알아가는 시간이었는데, 100% 원격 팀에서 유대감을 만드는 데 큰 역할을 했습니다.

---

시행착오와 배움

되돌아보면 잘한 것도 있지만 시행착오도 적지 않았어요. 특히 두 가지가 프로젝트에 큰 영향을 미쳤습니다.

가장 큰 패착은 프로젝트 초반에 디자이너 회의와 개발자 회의를 따로 운영한 것이었어요. 사실 디자인 시스템 프로젝트의 초반에는 개발자들이 할 일이 많지 않거든요. 디자이너들이 기초적인 시각 언어를 구성하고 디자인 토큰을 정의하는 단계니까요. 그래서 디자이너들끼리 2~3개월간 집중적으로 작업을 했고, 그 과정이 개발자들에게 제대로 공유되지 못했습니다. 디자이너들은 Figma 링크를 공유해 놓으면 충분할 거라 생각했지만, 개발자들은 그 사이 프로젝트 초기 설정과 학습에 몰두하고 있었죠. 그러다가 디자이너들이 막상 컴포넌트 디자인을 시작하려는 시점에 개발자들이 그동안 쌓아두었던 질문과 피드백을 한꺼번에 쏟아내기 시작했어요. 디자이너들 입장에서는 "이런 피드백을 이제서야 주면 어떡하냐"는 반응이 나올 수밖에 없었고 개발자들은 그 동안 이렇게 진행되고 있는지 몰랐다고 하는 참 안타까운 상황이 벌어졌습니다. 디자인 토큰 같은 기초적인 결정은 나중에 바꾸면 그 위에 쌓인 모든 것을 다 바꿔야 하니까요. 괴로운 재작업들이 이어졌습니다. 결국 세 분의 디자이너가 한 분씩 팀을 떠나셨습니다. 디자인 시스템에 전문성이 있는 디자이너 분들이 팀을 떠나면서 프로젝트는 큰 위기에 빠졌습니다. 정말 다행히도 중간에 합류하신 주니어 디자이너 분들께서 빈 자리를 잘 채워주셨지만 개인적으로 프로젝트 포기를 고려했을 정도로 뼈아팠던 손실이었습니다.

또 다른 큰 실수는 PM의 역할을 너무 과소평가하고 프로젝트 매니저 없이 프로젝트를 운영했다는 것입니다. 티켓을 만들고, 백로그를 관리하고, 회의를 주최하고, 회의록을 정리하고, 프로젝트 진척 상황을 관리하고, 마일스톤과 목표를 관리하고. PM이 해야 하는 일이 정말 많더라고요. 그 일들을 팀원이 공동으로 나눌 수 있다고 생각했지만 제대로 역할 분담이 되지 못하면서 프로젝트가 지연되거나 마일스톤 관리가 허술해지는 일들이 생겼습니다. 이건 개인적으로 큰 깨달음이었어요. 엔지니어로서 PM의 역할을 과소평가하고 있었다는 것을 오픈 소스 프로젝트를 직접 운영하면서 뼈저리게 느꼈습니다. 그런데 디자인 시스템에 대한 도메인 지식이 있는 PM을 찾기가 현실적으로 너무 어렵다는 것도 알게 되었어요. 이 문제는 앞으로도 풀어가야 할 숙제로 남아 있습니다.

이런 시행착오를 겪으면서 최근에 회의 방식 자체를 근본적으로 바꾸기로 했어요. 기존에는 중간 회의와 종료 회의가 비슷한 흐름으로 진행되다 보니 매주 같은 회의를 반복하는 느낌이었고, 60~90분에 너무 많은 활동을 넣다 보니 정작 중요한 논의에 충분한 시간을 쓰지 못하고 있었거든요. 복잡한 설계 논의를 디스코드 스레드에서 비동기로 하려니 참여율도 낮았고요. 그래서 중간 회의는 데모와 안건 중심의 협업 세션으로, 종료 회의는 플래닝과 회고에 집중하는 스프린트 회의로 성격을 완전히 분리했습니다. 주니어 개발자나 비개발 직군 팀원이 페어 프로그래밍을 통해 코딩을 자연스럽게 배울 수 있는 기회가 되기도 하고, 사무적인 분위기에서 벗어나 팀원 간에 인간적인 교류가 생기기도 합니다. 단순 공유는 비동기 주간 스탠드업으로 빼고, 실시간 대화가 필요한 논의만 회의에서 다루니까 시간 낭비도 훨씬 줄었어요.

---

앞으로의 계획

2026年04月30日 at 22 05 31 2026年04月30日 at 22 00 47

v1.0의 범위는 실제 서비스에서 가장 자주 쓰이는 컴포넌트들로 시작했습니다. daleui.com 웹사이트 자체가 달레 UI로 만들어져 있어서, 위에 보고 계신 스크린샷이 곧 v1.0의 결과물이기도 합니다.

v1.0은 달레 UI의 끝이 아니라 새로운 시작이에요. 최근 팀 안에서 레트로 워크샵을 진행하면서 지금까지의 여정을 돌아보고 앞으로의 방향에 대해 깊이 있는 논의를 했습니다. 솔직히 프로젝트를 시작할 때만 해도 "레퍼런스 디자인 시스템" 정도로 생각했어요. 오픈 소스 디자인 시스템을 함께 만들어보는 경험 자체에 의미를 두었고, 실제로 널리 쓰일 거라고는 기대하지 않았어요. 하지만 AI의 발달로 소규모 팀으로는 엄두도 못 냈던 일들이 가능해지고 있고, 그래서 더 큰 꿈을 꾸기 시작했습니다.

기술적으로도 흥미로운 변화가 있습니다. 처음에는 웹 컴포넌트로 만들고 싶었는데 생태계가 성숙하지 않아서 React로 시작할 수밖에 없었어요. 그런데 이제 AI를 통한 프레임워크 간 포팅이 훨씬 수월해졌기 때문에 Vue나 Svelte, 그리고 그때 포기했던 웹 컴포넌트까지 지원하는 것을 고려하고 있습니다. "AI가 사용하기 좋은 디자인 시스템"도 새로운 화두예요. 개발자들이 AI 에이전트를 활용해서 코딩하는 시대가 오고 있으니, 에이전트가 우리 디자인 시스템을 더 잘 이해하고 활용할 수 있도록 MCP나 에이전트 전용 문서 같은 것들도 검토하고 있습니다.

하지만 어떤 기술적 야망보다 중요한 건, 이 프로젝트가 계속 커뮤니티와 함께 만들어가는 프로젝트로 남는 거예요. 달레 UI는 처음부터 커뮤니티에서 시작했고, 커뮤니티의 필요에 의해 만들어졌습니다. v2.0부터는 달레 스터디 커뮤니티의 프로젝트들에 달레 UI를 실제로 적용하면서 실사용 피드백을 수집하고, 외부 기여자를 위한 가이드라인도 정비할 계획이에요. 지금까지는 팀 안에서 "이게 좋겠다"고 결정하는 경우가 많았는데, 앞으로는 실제로 디자인 시스템을 써보는 분들의 목소리에 더 귀를 기울이려고 합니다. 정기적인 피드백 세션도 운영해서 사용자와 만드는 사람 사이의 거리를 좁혀가고 싶어요.

---

감사 인사

마지막으로, 이 무모한 도전을 함께해 주신 분들께 감사의 마음을 전하고 싶습니다.

먼저 세환 님. PoC를 함께해 주신 덕분에 이 프로젝트를 구상할 수 있었어요. 혼자였다면 "오픈 소스 디자인 시스템을 만들어 보자"는 생각 자체를 하지 못했을 겁니다. 무려 6개월간 함께 여러 라이브러리와 프레임워크를 조사하고 프로토타입을 만들면서 방향을 잡아준 그 시간이 달레 UI의 진짜 출발점이었어요.

초대 디자이너이셨던 MK 님, 비케이 님, Chuck 님께도 감사드립니다. 세 분이 디자인 토큰부터 시각 언어까지 달레 UI의 디자인 기틀을 닦아주셨어요. 비록 여러 사정으로 팀을 떠나셨지만, 지금의 달레 UI는 그 토대 위에 서 있습니다.

Evan 님, Helena 님, 효성 님, 윤섭 님, 리아 님에게는 특별한 감사를 드려요. 프로젝트 초기부터 지금까지 함께해 주신 창립 멤버들인데, 회사도 아닌 오픈 소스 프로젝트에서 이렇게 오랫동안 한결같이 함께한다는 건 절대 쉬운 일이 아니라고 생각합니다. 오랜 시간 쌓인 두터운 신뢰를 바탕으로 제가 가장 자신있게 주변에 추천할 수 있는 엔지니어들입니다.

디자이너로 기여하고 계신 승현 님과 자혜 님께도 감사드려요. 처음부터 직접 만든 디자인 시스템이 아닌 만큼 아쉬운 부분도 있으셨을 텐데, 더 좋은 디자인을 위해 항상 고민해 주시는 모습에 감사합니다. v1.0 이후부터는 두 분의 철학이 더 깊이 담긴 디자인 시스템을 함께 만들어갈 수 있기를 기대합니다.

그리고 이 글에서 일일이 이름을 언급하지 못한 19분의 모든 기여자분들께도 감사드려요. 짧게든 길게든 달레 UI에 시간과 노력을 보태주신 모든 분들 덕분에 v1.0이 나올 수 있었습니다. 모두 축하드리고, 정말 고생 많으셨습니다 🎉

달레 UI가 궁금하시다면 daleui.com에서 직접 살펴보실 수 있어요. 깃허브 스타, 이슈, PR, 후원 등 어떤 형태의 관심이든 큰 힘이 됩니다.