실패한 디자인 시스템의 무덤, '디자인 시스템 공동묘지'를 피하는 법

발표자 크리스토퍼 노르드스트룀은 강연을 시작하며 '디자인 시스템 공동묘지'라는 개념을 소개했습니다. 그는 이곳을 디자인 시스템이 소멸하는 신화적인 장소로 정의하며, 많은 디자인 시스템이 결국 이곳에 이르게 된다고 설명했습니다.

이 공동묘지는 단순한 비유가 아니라, 실제 프로젝트에서 실패한 디자인 시스템들이 사라지는 현실을 반영하는 공간임을 암시했습니다.

노르웨이의 대규모 공공 부문 IT 환경과 두 번째로 큰 은행에서 사용되던 여러 디자인 시스템의 이전 버전이 공동묘지에 안장되어 있다고 언급하며 실제 사례를 들었습니다. 낮은 채택률, 미래 요구를 충족하지 못하는 서드파티 라이브러리 사용, 그리고 프로젝트가 완료되었다고 오인하는 것이 디자인 시스템이 실패하는 주요 원인으로 지목되었습니다.

이러한 원인들은 디자인 시스템의 지속적인 관리와 변화하는 환경에 대한 적응이 필수적임을 시사합니다.

크리스토퍼 노르드스트룀은 디자인 시스템을 구축하는 것은 비교적 쉽지만, 조직과 함께 유지하고 성장시키는 것이 훨씬 더 어렵다고 강조했습니다. 이는 소프트웨어 개발 수명 주기 초기에 이루어진 결정들이 향후 시스템의 유지보수와 성장에 큰 영향을 미치기 때문이라고 설명했습니다.

즉, 초기 단계의 결정이 장기적인 성공의 기반이 되므로 신중한 접근이 필요함을 의미합니다.

발표자는 자신을 프런트엔드 개발자이자 두 아이의 아버지인 크리스토퍼라고 소개했습니다. 그는 육아 휴직 중 겪었던 예상치 못한 개인적인 경험을 공유했습니다. 가족 중 한 분이 돌아가시면서 100년 된 잡화점을 상속받게 되었고, 6개월 동안 그 잡화점을 정리하고 치우는 데 모든 시간을 보냈다고 언급했습니다.

이 경험은 나중에 디지털 조직의 '수집벽' 증상에 비유되어 디자인 시스템의 불필요한 복잡성을 설명하는 데 활용됩니다.

크리스토퍼는 앞서 언급한 잡화점 정리 경험을 디지털 조직의 '수집벽'(hoarding) 증상에 비유했습니다. 수집벽의 일반적인 증상은 필요 없는 물건을 모으고, 정리하지 못하며, 버리기 어려워하는 것이라고 설명했습니다. 그는 디지털 조직에서도 이와 유사하게 너무 많은 제품을 모으고, 정리하지 못하며, 제품 생산을 중단하기 어려워하는 증상을 보인다고 지적했습니다.

발표자는 '정말 36가지나 되는 다양한 유형의 버튼이 필요한가요?'라고 질문하며 불필요하게 복잡해진 디자인 시스템의 현실을 꼬집었습니다.

디자인 시스템의 비효율성을 해결하기 위해 분석으로 시작해야 한다고 강조했습니다. 그는 계획을 세워 정리하고, 분류하고, 정렬하는 과정이 필요하다고 설명했습니다.

핵심은 도구가 실제 필요를 지원해야 하며, 모든 도구는 명확한 목적을 가져야 한다는 것입니다. 불필요한 것은 제거해야 한다고 조언했습니다.

디자인 시스템 구축을 위한 실용적인 접근법으로 '부품, 제품, 사람(Parts, Products, People)' 연습을 제시했습니다. 이 연습을 통해 디자인 시스템의 핵심 이해관계자, 제품, 구성 요소를 식별할 수 있습니다. 또한 '3x3' 연습에서는 세 가지 제품에서 각각 세 페이지를 선택하고, 이 아홉 페이지에서 세 가지 핵심 구성 요소를 찾아 제품에 가장 필요한 구성 요소 세트를 얻는 방법을 설명했습니다.

이러한 과정을 통해 디자인 시스템의 좋은 기준선을 마련할 수 있다고 덧붙였습니다.

크리스토퍼는 디자인 시스템이 완료되는 '프로젝트'가 아니라는 점을 분명히 인정해야 한다고 강조했습니다. 디자인 시스템은 제품을 구축하기 위한 '인프라'이자 '플랫폼'이며, 항상 변화하고 발전해야 하는 살아있는 존재로 보아야 한다고 설명했습니다. 또한, 문서화 웹사이트를 포함해야 하며, 그렇지 않으면 시대에 뒤떨어질 것이라고 경고했습니다.

디자인 시스템은 제품 팀의 프로세스와 워크플로를 지원해야 하며, 제품 팀이 바로 시스템의 '소비자'라는 점을 명심해야 한다고 덧붙였습니다.

명명(naming)은 항상 어려운 문제였지만, 디자인 시스템 내에서 여러 분야에 걸쳐 원활한 소통을 위해서는 매우 중요하다고 강조했습니다.

명확하고 일관된 명명 규칙은 디자이너와 개발자 간의 오해를 줄이고 효율적인 협업을 가능하게 합니다.

디자인과 코드에서 동일한 명칭을 사용하는 것이 중요하다고 설명했습니다. 이를 통해 개발자는 스케치를 보고 어떤 디자인 토큰을 사용해야 할지 직관적으로 알 수 있으며, 디자이너 또한 코드를 보고 어떤 토큰이 사용되었는지 확인할 수 있게 됩니다.

이러한 명칭 통일은 디자인 토큰을 활용함으로써 더욱 효과적으로 이루어질 수 있으며, 디자이너와 개발자 간의 소통 간극을 크게 줄일 수 있습니다.

디자인 토큰은 API를 통해 디자인 스케치에서 코드로 자동 내보낼 수 있다고 설명했습니다. 이 방식은 디자이너가 개발자의 개입 없이 직접 코드를 업데이트할 수 있게 하여 작업 효율성을 크게 높입니다.

디자인 토큰 값을 변경하는 과정이 이보다 쉬웠던 적은 없을 것이라고 강조하며, 이러한 자동화가 가져올 이점을 역설했습니다.

크리스토퍼는 중앙 집중식과 커뮤니티 모델의 장점을 결합한 하이브리드 모델이 시간이 지나면서 가장 성공적인 디자인 시스템 모델임을 경험적으로 확인했다고 밝혔습니다. 이 모델에서는 핵심 팀이 디자인 시스템을 구축하되, 제품 팀의 유지보수 담당자와 옹호자들의 지원을 받습니다.

이러한 접근 방식은 중앙 집중식 거버넌스의 효율성과 제품 팀의 적극적인 참여를 동시에 확보하여 디자인 시스템의 지속적인 성공을 가능하게 합니다.

새로운 기능 구축 초기 단계에서는 디자이너, 개발자 및 QA를 위한 개발자/디자이너가 필요하다고 설명했습니다. 하지만 일단 기능 개발이 완료되면, 다음 반복 작업은 자동화될 수 있습니다. API 테스트를 추가하여 QA 개발자의 필요성을 없애고, 시각적 회귀 테스트를 통해 QA 디자이너의 필요성도 없앨 수 있다고 강조했습니다.

이를 통해 귀중한 인적 자원을 확보하고 효율성을 높일 수 있다고 덧붙였습니다.

디자인 시스템의 배포 과정은 몇몇 주요 인물에게 의존하는 병목 현상이 될 수 있다고 지적했습니다. 이를 해결하기 위해 배포 과정을 커밋 태그에 의해 트리거되는 자동화된 작업으로 전환할 것을 제안했습니다.

이러한 자동화된 워크플로우를 통해 검토 및 자동화된 테스트가 승인된 출시의 게이트키퍼 역할을 하여 수동 작업으로 인한 지연과 오류를 줄일 수 있다고 설명했습니다.

디자인 시스템에 대한 신뢰를 유지하기 위해서는 변경 사항을 명확하게 전달하는 것이 중요하다고 강조했습니다. 이를 위해 의미론적 버전 관리(Semantic Versioning)를 제안했습니다. 주요 변경(Major)은 치명적인 변경, 보조 변경(Minor)은 새 기능, 패치(Patch)는 수정 사항을 의미한다고 설명하며, 이를 통해 제품 팀에 변경 사항과 잠재적인 위험을 알릴 수 있습니다.

또한, 변경 로그(Change Log)는 실제로 무엇이 변경되었는지 자세히 소통하는 중요한 도구이며, 기계가 읽을 수 있는 방식으로 변경 세트나 커밋에서 자동 생성될 수 있다고 덧붙였습니다. 이는 개발 중 불필요한 소통을 줄이는 데 기여합니다.

문서화는 작성하고 읽기 어려울 수 있다고 지적하며, 이를 개선하기 위해 코드를 디자인 스케치에 직접 연결하는 방법을 제안했습니다. 이 방식은 팀이 구성 요소를 쉽게 사용하고 명칭과 코드를 연결함으로써 문서화를 더 쉽게 작성하고 읽을 수 있게 합니다. 피그마 코드 커넥트(Figma Code Connect)를 예시로 들며, 디자이너가 스케치에서 올바른 속성 세트로 코드 스니펫을 복사/붙여넣기 할 수 있다고 설명했습니다.

이는 또한 AI 에이전트가 피그마 MCP(Master Component Page)를 사용하여 자신만의 것을 만들지 않고 실제 디자인 시스템 구성 요소를 가져오도록 돕는다고 덧붙였습니다.

크리스토퍼는 디자인 시스템에도 '스웨덴식 정리 기술(Swedish Death Cleaning)'처럼 수명 주기를 계획해야 한다고 강조했습니다. 그는 작동하는 것은 유지하고, 작동하지 않는 것은 과감히 버리며, 실패를 통해 배운 것을 바탕으로 의미 있고 가치를 더하는 새로운 것만 구축해야 한다고 조언했습니다. 다음 반복을 더 좋게 만들고 시스템을 사용하는 인간을 돌봐야 한다고 덧붙였습니다.

마지막으로, 디자인 시스템 공동묘지에 들어가는 것이 결코 실패가 아니라는 점을 강조했습니다. 그는 이것이 소프트웨어 개발 과정의 자연스러운 순환의 일부일 뿐이라고 말하며, 실패를 통해 배우고 더 나은 시스템을 만들어나가는 것의 중요성을 역설했습니다.