왜 디자인 시스템을 신경 쓰게 되었나

이전에 프로젝트 경험에서 컴포넌트를 만들때마다 버튼 스타일, 폰트 크기, 라운드 값이 조금씩 달라지는 걸 보았습니다. 화면마다 미묘하게 다른 UI는 사용자 경험에도 영향을 주고, 코드 관리에도 불필요한 비용을 발생시켰습니다. 이러한 문제를 줄이기 위해 디자인 시스템을 구축하고 준수해야 한다는 필요성을 절실히 느꼈습니다.

내가 한 시도들

당시 프로젝트는 7일간의 기획 기간 동안 와이어프레임과 디자인까지 동시에 진행해야 했습니다. 짧은 시간 안에 처음부터 디자인 시스템을 구축하는 것은 현실적으로 어려웠기 때문에, 이미 존재하던 FinesseUI를 수정해 빠르게 적용하기로 했습니다.

• 버튼은 BUTTON_VARIANTS, BUTTON_SIZES 상수로 관리
• Figma Tokens를 사용하고 @theme에 color 전역 토큰 정의
• radius, 메인 색상, 폰트 크기 등은 Tailwind 유틸리티(rounded-lg, text-lg)로 통일
• 접근성 지키기
• UX 통일(useEscapeKey, useOutsideClick 훅 사용 등)

디자인 시스템 전체를 새로 만든 것은 아니었지만, 프로젝트 차원에서 정해진 규칙을 따르려는 노력은 분명히 있었습니다.

지금 돌아보니 아쉬운 점

지금 와서 보니 “디자인 시스템 준수”라고 말하기엔 부족한 점이 많았습니다.

• 공통 컴포넌트를 맡아 작업했지만, 나머지는 각자 맡은 화면에서 필요할 때마다 따로 만들다 보니 팀원별 스타일 차이가 발생했습니다.
• 텍스트 관련 스타일 정의 이슈는 등록했지만, 개발일정에 쫓겨 도입하지 못했습니다.
• 가볍게 전역 토큰을 정의해서 text-body, rounded-card처럼 의미 기반 클래스를 쓰는 방법이 있었는데, 쓰지 못했습니다.
• 컴포넌트 API도 디자인 시스템 원칙을 강제하기보다는, 그냥 코드 작성자가 잘 쓰길 기대하는 수준에 머물렀습니다.

결국 당시에는 디자인 규칙을 의식만 한 단계였지, 시스템화 하거나 코드 차원에서 일관성을 강제할 수준에는 도달하지 못했습니다.

그래서...

이번 경험을 통해 크게 두 가지를 배웠습니다. 우선 디자인 시스템은 단순히 화면을 예쁘게 만드는 방법이 아니라, 팀 전체가 같은 언어를 쓰도록 강제하는 일종의 체계라는 점입니다. 그리고 Tailwind에서 제공하는 @apply 기능으로 의미 기반 클래스를 정의하거나, v4부터 권장되는 @theme에 전역 토큰을 선언하는 방식이 훨씬 더 바람직했다는 사실도 알게 되었습니다.

여기에 더해, 컴포넌트 단위의 일관성을 검증하고 팀원들이 같은 규칙을 공유하기 위해서는 스토리북(Storybook) 같은 도구의 필요성도 크게 느꼈습니다. 당시에는 시간이 부족해 도입하지 못했지만, 지금 돌아보면 버튼·드롭다운 같은 컴포넌트를 Storybook에 문서화해두었더라면, 팀원 누구나 동일한 스타일과 인터랙션을 참고하며 개발할 수 있었을 것입니다. 또한 팀원들과 실제 UI를 미리 확인하면서 피드백을 줄 수 있었을 테고, 이는 결과적으로 코드 리뷰 과정에서의 불필요한 반복과 UI 불일치를 줄였을 거라 생각합니다.

즉, 이번 프로젝트에서는 “디자인 시스템을 어떻게 설계했어야 했는지”를 몸소 배웠고, 그 과정을 통해 다음에는 더 잘할 수 있는 기반을 마련했다고 생각합니다.

앞으로는 색상, radius, 폰트 크기 같은 요소들을 전역 토큰으로 정의해 CSS 변수나 Tailwind의 theme 확장에서 관리하려 합니다. 그리고 text-lg 같은 단순한 크기 클래스 대신 text-body, text-heading처럼 의미가 드러나는 네이밍을 도입해 더 직관적인 규칙을 만들고 싶습니다. 또 Button이나 Dropdown 같은 공통 컴포넌트는 variant와 size를 강제로 선택하게 설계해 일관성을 보장할 예정입니다. 마지막으로, 단순히 개인이 규칙을 잘 지키는 데 그치지 않고, 문서화와 코드리뷰 체크포인트를 통해 팀 전체 프로세스 안에서 자연스럽게 규칙이 준수되도록 개선하고 싶습니다.