TL;DR

  • 디자인 시스템은 15명 규모의 전담 팀이나 별도 저장소가 있어야만 효과를 내는 것이 아니라, 어떤 단계에서든 인터페이스를 프런트엔드와 일치시키는 도구로 구현할 수 있음.
  • zeroheight 설문에서 디자인 시스템을 전사적으로 완전히 도입했다고 답한 디자이너는 7%, 대부분 팀에서 널리 사용한다고 답한 비율은 약 30%임.
  • 기업이 디자인 시스템을 도입하고 유지하는 데 많은 노력을 들이지만, 리더십의 지원에 대한 만족도는 하락했고 기대한 도입률과 이점을 얻지 못하는 실정임.
  • AI 도구와 디자인 도구, 프런트엔드 사이의 표현이 서로 달라지면 의도한 인터페이스와 실제 사용자 경험 사이에 불일치가 생김.
  • Statecraft는 프런트엔드 구성 요소를 사용해 캔버스 기반으로 디자인하고, AI와 CLI를 제공하는 비즈니스 클래스 수준의 대안임.

디자인 시스템은 모두에게 필요한가

  • 개인 전용 비행기는 대부분에게 현실적인 이동 수단이 아니며, 비싸고 불필요한 선택일 수 있음. 비즈니스 클래스나 좋은 기차 여행, 비싼 크루즈와 비교해도 체감 차이는 크지 않을 수 있음.
  • 하지만 디자인 시스템에 대해서는 직장에서 도입을 계속 밀어붙이고, Figma 구성 요소와 프런트엔드의 동기화, 프런트엔드 변경을 따라가는 프로토타입, Claude로 여는 풀 리퀘스트(PR)의 앱 일관성을 유지하려고 애씀.
  • 모서리 반경의 상세 문서를 관리하고, 정렬을 위한 회의와 워크플로, 점검을 마련하며, 요소를 원자(atom)로 볼지 분자(molecule)로 볼지를 두고 논쟁하기도 함.
  • zeroheight의 디자인 시스템 도입 설문 수치는 낙관적이지 않음. 참고로 S&P 500 기업의 약 60%가 임원에게 개인 전용기를 제공함.
  • 설문에서 디자인 시스템이 완전히 도입됐다고 답한 디자이너는 7%에 불과하고, ‘대부분’ 팀에서 널리 사용된다고 답한 비율은 약 30%임.
  • 전년보다 리더십의 지지에 대한 만족도가 낮아졌고, 얻는 이점을 측정하는 곳은 거의 없음. 시스템이 존재하고 자신들을 위한 것이라고 믿더라도, 실무자가 기대하는 수준의 도입이나 이점을 얻지 못하고 있음.

제작 비용 하락과 불일치의 대가

  • 무언가를 처음부터 만드는 비용이 급격히 낮아진 지금은 인터페이스를 체계화하고 전략적으로 만들고 유지하는 방법을 생각하기 좋은 시점임. 기능과 제품을 만드는 일이 모두 더 저렴하고 쉬워지고 있음.
  • 그 대가로 각 도구가 저마다 다른 결과물을 나타냄. Claude Design 인스턴스는 Figma 디자인 시스템의 대략적인 재현이고, Figma 디자인 시스템은 프런트엔드의 대략적인 재현임.
  • AI 에이전트와 에이전트의 MCP, 손으로 그린 Figma UI 해석, 브라우저에서 실제로 렌더링되는 코드 사이에서 전화 게임을 하는 셈임. 최선의 결과조차 원래 원한 것에 ‘보라색 원숭이 식기세척기’를 덧붙인 모양이 될 수 있음.

디자인 시스템이 필요한 이유

  • 디자인 시스템의 목적은 규모가 커져도 의도와 경험을 일치시키는 것임. 인터페이스에서 만들고자 하는 것과 사용자가 실제로 보고 행동하는 것을 연결하는 동시에, 개인이 회사 전체의 드래그 상호작용을 일방적으로 바꾸는 권한을 가져서는 안 된다는 점을 반영함.
  • 과거에는 픽셀 위치를 지정하는 상세 주석과 레드라인이 많았고, 스테이징 서버를 검토하면서 브라우저의 양식이 Figma 프로토타입과 완전히 다르게 보이는 이유를 두고 혼란이 생기곤 했음.
  • 오늘날에는 팀이 이미 사용하는 토큰을 무시하고 특정 화면에서만 보이며 다크 모드와 호환되지 않는 새로운 민트 그린을 풀 리퀘스트에서 슬쩍 만드는 일이 그에 해당할 수 있음.
  • 시스템의 목적은 디자인의 어느 단계에서 만들든, 사용자가 사용할 때도 같은 모습과 느낌을 갖도록 하는 것임.
  • 이를 위해 모서리 반경을 설명하는 4천 단어짜리 선언문을 별도 저장소에 둘 필요는 없음. 도구가 어떤 기기에서 렌더링하든 프런트엔드의 모습을 정확히 나타내면 됨.

여행에 빗댄 선택지

  • 디자인 시스템을 여행에 비유해 생각할 수 있음.
  • 15명으로 구성된 팀이 관리하는 전용 디자인 시스템 저장소, 심층 조사, 사용률과 도입률에 대한 투자, 분기마다 회사에 절감해 주는 비용을 계산하는 일은 개인 전용기에 해당함. 꿈꾸고 계획할 수는 있지만 당장 실현되리라 기대하기 어렵고, 실현되지 않는 데에는 여러 타당한 이유가 있음.
  • 정신을 차리려고 여러 Figma 플러그인과 MCP를 억지로 이어 붙인 방식은 Ryanair나 Spirit에 가까움. 목적지까지는 가지만 편안하지 않고, 식탁은 흔들리며, 안전벨트가 제대로 작동하는지 확신하기 어렵고 주변 사람들은 계속 소리를 지름.
  • Statecraft는 비즈니스 클래스에 해당함. Figma처럼 캔버스 기반으로 디자인하되, 대략적인 재현이 아니라 프런트엔드 구성 요소를 사용함. 구성 요소가 있다면 디자인 시스템 저장소나 컴포넌트 라이브러리의 것을 사용할 수도 있음.
  • 프런트엔드를 기반으로 하므로 프런트엔드와 동기화하는 수고가 필요하지 않음. AI가 내장돼 있고 CLI도 제공하므로 PM이 기존 구성 요소와 규칙을 활용해 작업할 수 있으며, 토큰이 잘못됐다고 계속 지적할 필요가 없음. 누구와 씨름하지 않아도 작업이 작동함.
  • 직접 만드는 선택지도 있음. 자체 렌더러와 프로토타이핑 도구를 만들려는 팀을 여럿 봤지만, 그 결과물은 집에서 직접 만든 항공기와 매우 비슷한 경우가 많음.
  • A에서 B로 이동하는 데 개인 전용기는 필요하지 않음. 날씨 풍선에 잔디 의자를 묶어 직접 만드는 대신, 더 편리한 방법을 선택할 수 있음.