#3 혼자 만드는 디자인 시스템

혼자 디자인 시스템 만들면 어떤 일이 생길까

7onic을 만들기 전에 이런 검색을 해봤다.

> solo design system

뭔가 현실적인 경험담이 나올 줄 알았다.

하지만 실제로 나온 건 대부분 이런 콘텐츠였다.

- 수십 명 규모 팀의 디자인 시스템 운영 사례
- 컴포넌트 라이브러리 확장 전략
- 조직 문화와 협업 프로세스 이야기
- “토큰 담당자”, “플랫폼 팀”, “리뷰 체계”를 전제로 한 글들

즉, 동료가 있다는 전제의 이야기들 이었다.

나는 그런 팀이 없었다.

혼자였다.

그래서 혼자 디자인 시스템을 만든다는 게 실제로 어떤 일인지, 직접 겪으면서 배울 수밖에 없었다.

지금 되돌아보니, 시작 전에 누가 알려줬다면 좋았을 것들이 있다.

 

 

매일 모든 결정을 혼자 내려야 한다

팀에서는 결정이 분산된다.

- 누군가는 토큰을 담당하고
- 누군가는 컴포넌트를 만들고
- 누군가는 문서를 관리하고
- 누군가는 접근성을 챙긴다

회의는 느릴 수 있다.

하지만 적어도 생각해야 할 양은 나눠진다.

혼자 만들면 다르다.

모든 질문이 전부 나에게 온다.

- border radius는 6px이 맞을까, 8px이 맞을까?
- 브랜드 메인 컬러는 어떤 색이어야 할까?
- RTL은 지금 지원해야 할까?
- `variant`와 `className`을 동시에 넘기면 어떻게 처리해야 할까?
- 기본값은 엄격해야 할까, 유연해야 할까?

질문 하나하나는 어렵지 않다.

문제는 이런 결정을 하루에 수십 번 하면서 동시에:

- 코드 작성
- 문서 정리
- CLI 개발
- 버전 배포
- 버그 수정

까지 해야 한다는 점이다.

생각보다 피로도가 높다.

처음 한 달은 결정 로그도 적었다.

그런데 곧 멈췄다.

왜냐하면 또 다른 결정이 생겼기 때문이다.

> 이 결정은 기록할 가치가 있는가?

결국 가장 효과적이었던 방식은 단순했다.

한 번 정하고, 짧게 기록하고, 넘어간다.

모든 선택이 깊은 토론을 필요로 하진 않는다.

대부분은 10초 고민과 코드 주석 하나면 충분하다.

 

 

내 실수를 아무도 잡아주지 않는다

이건 세 번째 컴포넌트쯤 만들 때 체감했다.

Button 컴포넌트에 사이즈 variant를 다섯 개 넣었다.

- `xs`
- `sm`
- `md`
- `default`
- `lg`

API도 깔끔했고, 타입도 잘 잡혀 있었고, 보기에도 만족스러웠다.

그런데 2주 뒤 깨달았다.

`md`와 `default`가 시각적으로 완전히 같았다.

둘 다 높이 36px이었다.

토큰 값을 복붙하다가 실수로 중복 넣은 것이다.

즉 나는:

- 버그를 만들었고
- 버그를 리뷰했고
- 버그를 승인했고
- 버그를 배포했다

전부 혼자.

팀이었다면 누군가는 물었을 것이다.

> 잠깐만, 이 두 사이즈 왜 똑같아요?

혼자 만들면 리뷰어는 미래의 나 자신이다.

그리고 미래의 나는 생각보다 자주 놓친다.

실제로 이런 일들이 있었다.

- 중복 variant 배포
- displayName 잘못 export
- 다크모드 테스트 안 하고 배포
- 문서 예제 코드 깨진 채 공개

완벽한 해결책은 아직도 없다.

대신 조금 도움이 되는 습관은 생겼다.

- 배포 전 체크리스트 만들기
- changelog 먼저 작성해보기
- 신규 사용자처럼 docs 다시 읽기
- 피곤할 때 한 번 더 보기

화려하진 않다.

하지만 혼자 만들 때는 이런 게 꽤 중요하다.

 

범위 확장은 막아줄 사람이 없다

팀에서는 언젠가 누군가 말해준다.

> 그건 지금 범위 밖입니다.

PM이 말하기도 하고,
동료가 말하기도 하고,
마감일이 대신 말해주기도 한다.

혼자 만들면 그런 사람이 없다.

떠오른 아이디어는 곧바로 실행 가능한 일이 된다.

나는 원래 단순히 컴포넌트를 설치해주는 기능을 만들려고 했다.

그런데 어느 순간 이런 기능들이 추가됐다.

- 오타 입력 시 유사 명령어 추천
- lockfile 기반 패키지 매니저 자동 감지
- Tailwind v4 자동 주입
- config 자동완성을 위한 JSON schema

각각은 다 좋은 기능이었다.

문제는 전부 합치면 출시가 두 달 늦어졌다는 점이다.

혼자 만들 때 범위 확장은 범위 확장처럼 느껴지지 않는다.

그냥 제품을 더 좋게 만드는 일처럼 느껴진다.

그리고 실제로 더 좋아진다.

하지만 항상 “더 좋은 것”이 목표는 아니다.

어떤 순간엔 **출시하는 것 자체가 목표**다.

그래서 요즘은 기능 추가 전에 한 문장을 먼저 쓴다.

> 이 기능은 지금 7onic을 설치하는 사람에게 어떤 문제를 해결해주는가?

답을 억지로 만들어야 한다면, 일단 보류한다.

 

 

오픈소스는 모멘텀이 다르게 온다

회사 안에서 무언가 배포하면 반응이 빠르다.

- 누군가 내일 바로 쓰고
- 누군가 오후에 피드백하고
- 누군가 다음 주에 개선 요청한다

루프가 짧다.

오픈소스는 다르다.

3주 동안 만든 기능을 배포해도 다음 날 세상은 똑같다.

- 사용자 수치 변화 없음
- 반응 없음
- 당장 쓰는 사람 보이지 않음

가끔 GitHub star가 하나씩 늘어난다.

그 하나하나가 정말 감사하다.

하지만 초반 오픈소스 특유의 정적은 분명히 있다.

그래서 다른 피드백 구조가 필요했다.

나에게는 글쓰기가 그 역할을 했다.

트래픽 때문은 아니었다.

오히려 거의 없었다.

하지만 어떤 결정을 글로 설명하려고 하면 생각이 선명해진다.

왜 이렇게 만들었는지 설명이 안 된다면, 보통 설계도 흔들리고 있었다.

그래서 이 블로그는 콘텐츠가 아니라 개발 도구이기도 하다.

 

 

사람들이 잘 말하지 않는 숨은 시간

사람들은 컴포넌트만 본다.

하지만 실제 작업 시간의 절반은 다른 곳에 들어간다.

예를 들면:

- TypeScript 타입 파일이 왜 이상하게 생성되는지 찾기
- 로컬에서는 되는데 CI에서만 깨지는 문제 디버깅
- API 바뀔 때마다 docs 다시 쓰기
- smoke test 환경 구성
- changelog 관리
- issue 응답
- 배포 스크립트 정리

어려운 일은 아닐 수 있다.

하지만 전부 시간을 먹는다.

그리고 혼자라면 그 시간도 전부 내 시간이다.

어떤 주는 컴포넌트는 거의 못 만들고 주변 인프라만 손보다 끝난다.

예전엔 그게 답답했다.

지금은 그냥 현실이라고 생각한다.

제품도 관리해야 하고,
도구도 관리해야 한다.

둘 다 나를 필요로 한다.

 

 

그런데도 혼자 만드는 장점이 있다

지금까지 단점만 말했지만, 이것만으로는 절반짜리 이야기다.

혼자 만들 때 얻는 가장 큰 장점은 의외로 다른 곳에 있다.

일관성이다.

자유도 아니고,
속도도 아니고,
“내 마음대로 할 수 있음”도 아니다.

일관성이다.

시스템 전체가 머릿속에 들어온다.

- 다크모드 구조를 바꾸고 싶으면 어디를 수정해야 하는지 안다
- 토큰 하나 추가하면 어디까지 영향 가는지 안다
- 어색한 부분이 있으면 왜 어색한지도 대체로 안다

누구에게 물어볼 필요도 없고,
담당자를 찾을 필요도 없고,
회의를 잡을 필요도 없다.

그냥 고치면 된다.

팀은 협업 최적화를 한다.

혼자 만드는 사람은 정합성 최적화 를 할 수 있다.

디자인 시스템처럼 내부 일관성이 중요한 제품에서는 이 차이가 꽤 크다.

 

 

나도 이렇게까지 좋아할 줄은 몰랐다

혼자 만드는 일은 분명 피곤하다.

반복적이고, 외롭고, 느리고, 정신없을 때도 많다.

그런데 예상하지 못했던 만족감도 있다.

내가 만진 모든 레이어가 조금씩 정돈되면서 하나의 시스템이 되어가는 느낌.

그건 꽤 좋다.

혼자 만드는 걸 낭만적으로 포장하고 싶진 않다.

하지만 과소평가하고 싶지도 않다.

가끔은 충분히 집요한 한 사람이, 생각보다 단단한 시스템을 만들기도 한다.

 

 

---

 

7onic은 디자인과 코드가 어긋나지 않도록 설계된 오픈소스 디자인 시스템입니다.
무료로 사용할 수 있으며, **MIT License**로 제공됩니다.

- 공식 사이트 & 인터랙티브 플레이그라운드: https://7onic.design
- GitHub: 공개 레포 
- 공식 영문 블로그
- X 업데이트: @7onicHQ 

GitHub Star는 큰 힘이 됩니다.

 

 

 

 

7onic Design System

본 글은 본인의 7onic 디자인 시스템 영문 원문 블로그에서 가져 왔습니다.