디자인 시스템, 코드에서 먼저 시작하면 달라질까요?
완성된 화면을 Figma에서 그린 뒤 컴포넌트를 추출하는 기존 방식 대신, 이미 구현된 코드에서 디자인 시스템을 먼저 정의하고 워크플로의 시작점을 옮긴 실험. 여백·반응형·엣지케이스를 코드에 직접 구현해 명세를 대신하게 하자, Figma에서는 보이지 않던 레이아웃 깨짐을 먼저 마주하며 시스템을 어디까지 제어해야 하는지 감각을 얻은 기록.
실무에서 디자인 시스템을 보수하다 보면 Figma에서 분명히 정리해둔 토큰과 위계가, 코드로 넘어가는 순간 조금씩 달라져 있는 것. 컴포넌트 하나 둘일 때는 수동으로 맞추면 그만이지만, 종류와 개수가 쌓일수록 보정해야 할 지점도 같이 늘어나는 등 반복적인 업무를 수행하게 됩니다.
비슷한 업무가 반복되는 이유는 바로 디자인 시스템을 정의하고 이를 적용하여 구현하는 협업 속에서의 시스템 규칙은 흐름 밖에 있었기 때문입니다. 노션 문서와 피그마의 디자인 토큰이나 스타일 가이드는 존재했지만, 구현 작업이 진행되는 흐름 안에서 그 규칙이 단번에 지켜지는 구조는 아니었습니다. 디자이너가 Figma에서 아무리 정밀하게 잡고 정의내린 가이드라인일지라도, 코드로 넘어가면 매번 다시 손으로 확인하고 맞춰야 하는 구간이 생겼습니다.
그 반복을 보면서 자연스럽게 질문이 생겼습니다. 완성된 화면이 있어야 그 안에 들어갈 컴포넌트를 Figma에서 그리는 기존 방식 대신, 처음부터 코드에서 시스템을 만들기 시작하면 어떨까. 기준이 문서가 아니라 흐름 안에 있게 되면, 지금 반복되는 보정이 구조적으로 줄어들지 않을까.
실험은 그 질문에서 출발했습니다. 값이 어긋나는 지점을 먼저 토큰 단위로 정의하고, 워크플로우의 시작점을 이미 구현된 시스템으로 옮겼습니다. 여백과 간격은 임의의 수치 없이 시스템 규칙 안에서만 계산되도록 제한했고, 반응형 동작과 엣지케이스는 별도 문서 대신 코드에 직접 구현해 명세 역할을 대신하게 만들었습니다.
코드로 렌더링된 화면을 직접 보고 나서야 보이는 것들이 있었습니다. 텍스트 길이에 따른 레이아웃 깨짐, Flexbox 논리의 예외 케이스처럼 Figma 안에서는 미처 인지하지 못했던 문제들이었습니다. 실패를 먼저 마주하고 해결하는 과정이, 디자인 시스템을 어디까지 제어해야 하는지에 대한 감각을 실질적으로 만들어줬습니다.
이 실험에서 가장 크게 얻은 것은 기술적인 결과물만이 아닙니다. Figma 밖, 프론트엔드 환경에 직접 부딪히며 디자이너가 시스템을 어떻게 설계해야 하는지에 대한 시야를 한 단계 넓힐 수 있었습니다. 디자인 시스템은 결국 기준이 어디서 시작되고, 그 기준이 흐름 안에서 얼마나 자동으로 지켜지는가의 문제라는 것을 몸으로 확인한 경험이었습니다.