#1 내가 7onic을 만든 이유

내가 핸드오프를 포기한 순간

디자인 핸드오프를 완전히 믿지 않게 된 순간을 아직도 정확히 기억한다.

내가 디자인한 카드 컴포넌트를 개발자가 구현해둔 화면을 확인했을 때였다.

spacing은 2px 정도 어긋나 있었고, border radius는 6px이어야 했는데 8px로 들어가 있었다. 그림자도 비슷하긴 했지만 어딘가 달랐다. 아마 Tailwind 기본 shadow 값을 가져다 쓴 것 같았다.

하나하나 따지면 이슈 티켓을 만들 정도는 아니었다.

그런데 전부 합쳐 놓고 보면 결과물이 묘하게 이상했다.

딱히 틀린 건 아닌데, 정확하지 않았다.

나는 Figma에 코멘트를 남겼고, 다음 스프린트에서 수정되었다.

그리고 같은 일이 다음 컴포넌트에서도 반복됐다.
그 다음 컴포넌트에서도.
그렇게 10년 동안.

디자이너이면서 프론트엔드 개발자라는 입장

나는 디자이너다.

그리고 지난 15년 동안 프론트엔드 코드도 계속 작성해왔다.

즉, 나는 핸드오프의 양쪽 입장을 모두 경험했다.

개발자가 왜 rounded-md를 썼는지도 안다.

Tailwind에 이미 준비되어 있고, 얼추 비슷해 보이며, 일정은 촉박하다.
굳이 6px이 rounded인지 rounded-md인지 확인할 시간은 없다.

참고로 6px은 둘 중 어느 쪽에도 애매하게 걸친다.

어느 순간부터 Figma 코멘트를 남기는 일이 생산적으로 느껴지지 않았다.

그래서 그냥 내가 직접 컴포넌트를 만들기 시작했다.

이건 사람의 문제가 아니다

분명히 말하고 싶다.

내가 함께 일했던 개발자들이 대충 일해서 생긴 문제는 아니었다.
대부분 나보다 훨씬 뛰어난 엔지니어들이었다.

진짜 문제는 이것이었다.

• 디자인 값은 Figma에 있다.
• 코드 값은... 마지막 개발자가 넣어둔 어딘가에 있다.

누군가 버튼을 만든다.
Figma를 대충 보고 bg-gray-900을 넣는다. 비슷하니까.

다음 달 다른 사람이 카드 헤더를 만든다.
버튼을 보고 “이게 공식 dark 색상인가 보다” 하고 복붙한다.

그런데 실제 Figma 값은 #1a1a1a였다.

gray-900과 꽤 비슷하지만 완전히 같지는 않다.

이제 운영 중인 서비스에는 서로 조금 다른 “검정색” 두 개가 생긴다.
그리고 아무도 어떤 값이 정답인지 기억하지 못한다.

이 일이 색상, spacing, radius, shadow 전부에서 반복된다.

컴포넌트 수십 개. 몇 달, 몇 년 동안.

디자인과 코드의 차이는 천천히, 하지만 꾸준히 벌어진다.

뒤늦게 보니 문제는 명확했다

공통된 진실의 원천(Source of Truth)이 없었다.

• 디자이너에게는 Figma가 있었고
• 코드베이스에는 기존 코드가 있었다

둘을 맞추는 일은 수동 작업이었다.

수동 작업이라는 건 결국 누구의 책임도 아니라는 뜻이고,
그래서 결국 아무도 하지 않는다.

 

흔한 해결책은 다 시도해봤다

무작정 새로 만들기 전에 일반적인 방법은 다 해봤다.

1. Figma 토큰 export 후 Tailwind에 수동 반영

처음 3주는 잘 된다.

그 후 Figma 값이 수정되고, 아무도 Tailwind 설정을 업데이트하지 않는다.

다시 drift 시작.

---

2. Style Dictionary

정말 강력한 툴이다.

하지만 내가 원하는 결과물:

• CSS variables
• Tailwind v3 preset
• Tailwind v4 theme
• JS export
• TypeScript types

이걸 정확히 맞춰서 출력하도록 구성하는 데 컴포넌트 만드는 시간보다 더 오래 걸렸다.

주말 내내 transform과 formatter를 만들었는데도 마음이 놓이지 않았다.

---

3. Token Studio for Figma

좋은 플러그인이다.

하지만 export된 JSON을 실제 Tailwind 프로젝트에서 쓰려면 결국 추가 가공이 너무 많이 필요했다.

결국 커스텀 파이프라인을 만드는 건 똑같았다.

단지 내가 통제하지 못하는 레이어 하나가 더 생겼을 뿐이다.

결국 직접 만들었다

모든 방식에 공통된 빈틈이 있었다.

“Figma에서 토큰 꺼내기” 까지는 잘 해준다.
그 다음 단계인 “실제 코드베이스에 정확히 연결하기” 는 알아서 하라고 한다.

문제는 항상 그 마지막 1km에서 터진다.

그래서 직접 만들었다.

 

규칙은 단 하나

굉장히 단순하고 엄격한 규칙을 세웠다.

토큰 파일에 없는 값은 코드에 존재할 수 없다.

즉:

• bg-gray-500 금지
• p-[17px] 금지
• text-[13px] 금지

색상이 필요하면 토큰을 만든다.
spacing이 필요하면 토큰을 만든다.

처음엔 귀찮다.

하지만 바로 그 불편함이 핵심이었다.

모든 시각적 결정이 하나의 관문을 통과하게 만든다.

그 파일이 바로:

figma-tokens.json

 

한 파일, 한 명령어, 드리프트 0

 

synctokens 명령어 하나가 이 파일을 읽고 전부 생성한다.

• CSS Custom Properties
• Tailwind v3 preset
• Tailwind v4 theme
• TypeScript types
• JSON outputs
• 기타 배포 파일들

총 11개 파일.

색 하나 바꾸고 명령어 실행하면 전체 시스템이 동기화된다.

• 하드코딩된 hex 값 찾으러 코드베이스 뒤질 필요 없음
• Tailwind config 수정했는지 기억할 필요 없음
• Figma와 코드 비교할 필요 없음
  
  

그 위에 만든 디자인 시스템, 7onic

토큰 레이어 위에 7onic을 만들었다.

현재:

• 컴포넌트 42개
• Tailwind v3 / v4 동시 지원
• CLI 제공
• 3개 국어 문서화

CLI 예시:

npx 7onic add button input select

 

이 명령어는 패키지를 import 하는 방식이 아니다.

실제 .tsx 소스 파일 자체를 프로젝트 안으로 복사한다.

즉, 네 코드가 된다.

읽고, 수정하고, 원하는 대로 바꿀 수 있다.

 

왜 Radix UI를 사용했나

접근성은 내가 가장 실수하고 싶지 않았던 영역이었다.

그리고 직접 만들면 분명 실수할 영역이기도 했다.

예를 들면:

• Dialog focus trap
• Dropdown keyboard navigation
• Toast screen reader announcement

이건 생각보다 훨씬 어렵다.

Radix UI는 이걸 이미 잘 해결해두었고, 스타일은 전혀 강요하지 않는다.

즉:

• 접근성은 Radix
• 디자인은 내 토큰 시스템

역할 분리가 완벽했다.

혼자 만들었다는 것

 

이 시스템은 전부 혼자 만들었다.

팀도 없었고 리뷰어도 없었다.

나, Figma 파일, 그리고 naming convention 때문에 스스로 싸우는 markdown 문서들만 있었다.

예:

• 버튼 기본 사이즈 이름은 default인가 md인가?
• 버튼 사이즈는 3개면 충분한가, 5개가 맞는가?

참고로 최종 선택은 5개 + default 였다.

이런 고민이 혼자 만들 때는 진짜 새벽까지 이어진다.

 

 

혼자 만들면 좋은 점도 있다

“나중에 정리하지 뭐”가 통하지 않는다.

왜냐하면 나중에 정리할 사람도 나니까.

그래서 처음부터 제대로 하게 된다.

팀에서는 규칙이 이상론일 수 있다.

혼자 만들면 생존 전략이다.


아직도 미완성이다

디자인 시스템은 끝이 없다.

• 추가할 컴포넌트 하나 더
• variant 하나 더
• edge case 하나 더

계속 생긴다.

그래서 나는 불완전한 상태로 출시하는 법을 배워야 했다.

지금 7onic은 충분히 usable 하다.

그리고 아직도 부족한 부분이 있다.

괜찮다.

Ship. Iterate. Repeat.

앞으로 쓰고 싶은 이야기들

 

이 글은 Design to Code 시리즈의 첫 글이다.

앞으로는 홍보용 글이 아니라 실제로 만들면서 고민했던 의사결정을 공유하려고 한다.

예를 들면:

• 토큰 파이프라인 구조
• 왜 RGB 채널 변수를 만들었는지
• Tailwind v3 / v4 동시 지원 방식
• npm package 대신 copy-paste CLI를 택한 이유
• AI로 디자인 시스템 만드는 현실적인 방법
• 42개 컴포넌트를 만들며 배운 것들

 

결국 핵심은 하나다

디자인 시스템의 본질은 컴포넌트 개수가 아니다.

진짜 핵심은 이것이다.

디자인과 코드가 절대 어긋날 수 없는 구조를 만들었는가?

나는 그 답으로 7onic을 만들었다.

 

 

---

 

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

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

GitHub Star는 큰 힘이 됩니다.

 

 

 

7onic Design System

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