디자인 시스템 거버넌스 — 누가 언제 바꿀 수 있나

디자인 시스템 거버넌스는 디자인 시스템이 어느 정도 자리를 잡으면 반드시 나오는 질문에서 시작합니다. “이 컴포넌트, 제가 그냥 수정해도 되나요.” 누구나 수정할 수 있게 열어두면 금방 일관성이 깨지고, 반대로 한 사람만 승인권을 쥐고 있으면 병목이 생깁니다.

1. 거버넌스 모델의 세 가지 유형

일반적으로 중앙집중형, 연합형, 오픈소스형 세 가지로 나뉩니다. 팀 규모가 작다면 중앙집중형에서 시작해 커지면서 연합형으로 옮겨가는 흐름이 자연스럽습니다.

중앙집중형

전담팀이 모든 변경을 검토·배포. 일관성은 높지만 요청이 몰리면 느려짐

연합형

각 제품팀에 기여자를 두고 정기적으로 모여 변경을 조율

오픈소스형

누구나 제안 가능하되 코드 리뷰처럼 승인 과정을 거침

2. 변경 요청의 처리 흐름 만들기

거버넌스가 없으면 변경 요청이 슬랙 DM이나 구두로 오가다가 기록이 남지 않습니다. 최소한의 흐름을 정해두고, 요청은 반드시 기록으로 남게 해야 합니다.

요청 등록

영향 범위 검토

승인 또는 반려

배포

사용자 공지

컴포넌트 네이밍 규칙 같은 세부 표준도 이 흐름 안에서 논의되고 확정되어야 나중에 왜 이렇게 정했는지를 추적할 수 있습니다.

3. 깨는 변경은 따로 다루기

기존 컴포넌트의 구조를 바꾸는 변경은 일반 업데이트와 다르게 다뤄야 합니다. 이 절차를 건너뛰면 시스템 업데이트가 프로덕트팀 입장에서는 예고 없는 사고로 느껴집니다.

일반 업데이트

기존 구조를 유지한 채 값이나 스타일만 조정, 즉시 반영 가능

깨는 변경

영향받는 화면 파악 → 마이그레이션 기간 공지 → 구버전·신버전 병행 지원

AI 도구가 들어오면서 달라지는 것

최근에는 AI가 컴포넌트 변형을 자동 제안하거나 사용 패턴을 분석해주는 사례도 늘고 있습니다. 디자인 시스템에 AI를 넣는 방법에서 다룬 것처럼, AI는 검토 속도를 높이는 도구로 쓰고 거버넌스 구조 자체를 대체하게 두지 않는 것이 중요합니다.

• 팀 규모에 맞는 거버넌스 모델 선택하기
• 변경 요청 처리 흐름을 기록 가능한 형태로 만들기
• 깨는 변경에 대한 마이그레이션 절차 별도 마련하기
• 승인 권한자와 책임 범위 명확히 하기
• AI 도구 도입 시에도 최종 승인은 사람이 하도록 유지하기

4. 모델을 바꿔야 하는 신호

거버넌스 모델은 한 번 정하면 고정되는 것이 아니라 팀 규모와 제품 수가 늘어나면서 자연스럽게 바뀌어야 합니다. 중앙집중형으로 시작한 팀이라도 제품 라인이 늘고 변경 요청이 몰리기 시작하면, 전담팀 혼자 모든 검토를 감당하기 어려워지는 시점이 옵니다. 이때는 각 제품팀에 기여자를 지정하는 연합형으로 옮겨가는 것이 자연스러운 다음 단계입니다.

변경 요청 대기열이 지속적으로 쌓이는지 확인한다

특정 제품팀의 요구가 반복적으로 거절당하고 있는지 살핀다

전담팀 인원 대비 검토해야 할 컴포넌트 수가 감당 가능한지 점검한다

반대로 모델을 필요 이상으로 빨리 바꾸는 것도 흔한 실수입니다. 팀이 작을 때부터 연합형이나 오픈소스형을 도입하면 합의에 드는 시간이 오히려 늘어나므로, 지금 팀 규모에 실제로 병목이 있는지부터 확인하는 것이 우선입니다.

모델을 전환할 때는 한 번에 모든 컴포넌트를 옮기려 하지 말고, 변경 요청이 가장 많이 몰리는 영역부터 시범적으로 새 모델을 적용해보는 편이 안전합니다. 새 모델에서 병목이 실제로 해소되는지 확인한 뒤에 나머지 영역으로 확장하면, 전환 과정에서 생길 수 있는 혼란을 최소화할 수 있습니다.

전면 전환

모든 컴포넌트를 한 번에 새 모델로 이전 · 혼란과 저항이 커짐

단계적 전환

병목이 큰 영역부터 시범 적용 후 점차 확장 · 리스크가 작음

모델을 바꾸는 결정 자체도 거버넌스 절차를 따라야 합니다. 특정 리더 한 명의 판단만으로 조용히 바뀌면, 나머지 팀원들은 왜 갑자기 절차가 달라졌는지 알지 못한 채 혼란을 겪게 됩니다. 전환 배경과 새 절차를 공지로 명확히 알리는 것만으로도 불필요한 저항을 크게 줄일 수 있습니다. 전환 이후 일정 기간은 예전 방식과 새 방식을 함께 안내해, 팀원들이 자연스럽게 새 절차에 적응할 시간을 주는 것도 도움이 됩니다.

5. 마치며

디자인 시스템 거버넌스는 통제를 위한 규칙이 아니라, 시스템이 오래 살아남게 하는 최소한의 안전장치입니다. 지금 팀에 승인 흐름이 전혀 없다면, 가장 간단한 요청 등록 절차 하나부터 만들어보는 것이 시작입니다.