KDS 사이트 제작

문제

디자인 시스템의 결정은 늘 어딘가에 기록되어 있습니다. 문제는 그 "어딘가"가 흩어져 있거나 누군가의 머리속에 있다는 점입니다. KDS의 정책 대부분은 Teams 대화, Figma 코멘트, Confluence 문서, 사외 및 사내 메일 등에 나뉘어 남았습니다. List 상단 패딩이 spacing-sem-100으로 정해진 이유를 찾으려면 여러 문서를 뒤져야 했고, 대개는 기록이 아닌 기억을 더듬게 되었습니다.

제품 목적에 따라 가이드 또한 Framer, Figma, Notion, Confluence에 나뉘어져 있었는데요. 그 중 더 이상 사용하지 않게 된 솔루션의 기록들은 모두 손으로 옮겨야만 했습니다. 옮기는 동안 기록의 일부가 항상 유실되기도 했구요.

요건은 구두나 메신저로 받았습니다. 그래서 우선순위가 바뀌었을 때 요청자에게 알림이 가지 않았고, 요건이 변경되어도 무엇이 언제 어떻게 바뀌었는지 추적할 수 없었습니다. 요청자도, 설계자도 모두 모르는 사이 개발자는 필요없는 요구사항을 구체화하고 있는 경우도 생겼어요.

접근

Guideline 생성

기록을 문서가 아니라 Database로 다루기로 했습니다.

• Strapi를 도입했습니다. 헤드리스 CMS라 화면과 데이터가 분리되어, 나중에 프론트엔드를 바꿔도 합의 자산은 그대로 남습니다. 오픈소스이며, 무료입니다. 기본 DB 지원유형인 sqlight를 사용해서, 파일 기반 백업도 간편하게 구성하였습니다.
• 각 단위 파운데이션과 컴포넌트를 콜렉션으로 구현해 DB 스키마를 만들었습니다. "Color 파운데이션", "Button 컴포넌트"가 문서 한 장이 아니라 각각의 구체화된 필드에 기록합니다. 특정 속성이 언제 어떻게 바뀌었는지는 로그 콜렉션을 구성, related field로 연결하여 수정사항을 추적 관리합니다.
• vite로 사이트 프론트엔드를 구현하고, 사내 임직원이 접근할 수 있는 도메인으로 배포했습니다. 디자이너·개발자·기획자가 각자 다른 곳을 보지 않고 같은 웹 사이트를 보도록 구성했습니다.

Figma 연동

• 컴포넌트 콜렉션 이름과 동일한 Figma 라이브러리 페이지를 REST API로 호출해 컴포넌트 구성 요소를 불러옵니다. 콜렉션 이름을 규칙으로 삼았기 때문에 별도의 매핑 테이블이 필요 없습니다. Figma에서 컴포넌트가 갱신되면 사이트도 따라 갱신됩니다.
• 매시 확정 디자인 파일을 호출해 작성된 댓글 일체를 수집합니다. 요구사항이 메신저가 아니라 디자인 파일 위에 남고, 수집과 알림이 실시간으로 이루어집니다. 구두로 들어오던 요건이 이제는 추적 가능한 Figma 댓글로 치환합니다.

수집된 요청은 로그 테이블에 쌓입니다. 요청이 들어온 시점부터 반영과 배포까지 한 줄로 이어지기 때문에, 우선순위가 바뀌면 그 변경 자체가 기록으로 남고, 또 figma 댓글 쓰레드로 변경사항을 지속적으로 업데이트합니다.

결과

• 이해관계자 전체가 실시간으로 최신 디자인 시스템 정보를 확인할 수 있는 가이드라인을 웹사이트 형태로 제공했습니다.
• 로그 테이블로 요청 수집부터 배포까지 추적 관리가 가능해졌습니다.
• 합의 자산을 DB로 옮겨, 특정 솔루션에 귀속되지 않는 형태로 남겼습니다. 어떤 솔루션을 사용하던 합의된 자산은 아주 작은 파일 1개로 유지됩니다.

금융회사에서 모두가 소통할 수 있는 단일 자산은 소통의 유연함과 간편한 내부통제를 모두 달성하게 해주었습니다. 하나 하나의 기록이 당행 전체 디자인의 지지가 될 수 있도록, 모두의 그릇을 만드는데 집중한 프로젝트입니다.