사용 가이드로 건너뛰기
Design System Governance작성자 owl-listener

Design System Governance 스킬.

팀이 공용 디자인 시스템에 기여하고 발전시키는 방식을 정의합니다.

  • 디자인 시스템
  • 거버넌스
소스 검토 · design-system-governanceSKILL.md
작업 팀이 공용 디자인 시스템에 기여하고 발전시키는 방식을 정의합니다. 결과물 참여 팀에 맞는 책임 및 기여 모델. 시작 전 확인 스킬은 모델 초안을 만들 수 있지만 권한과 책임은 실제 조직을 반영해야 합니다.
편집 요약 · 소스 검토일 2026-11-02 · 생성된 예제가 아닙니다

01 기능 소개

팀이 공용 디자인 시스템에 기여하고 발전시키는 방식을 정의합니다

여러 제품 팀이 사용하는 디자인 시스템의 책임, 기여 검토, 버전 관리와 사용 중단 규칙을 정하세요.

소스 기반 워크플로실행 벤치마크 아님

작업 방식

Design System Governance는 여러 팀이 기여할 때 공용 컴포넌트 시스템의 일관성을 유지하는 절차를 정의합니다. 책임, 제안, 검토, 릴리스, 호환성을 깨는 변경과 사용 중단을 다룹니다. 누가 시스템을 변경할 수 있고 사용 팀은 그 변경을 어떻게 알게 되는지 정해야 할 때 유용합니다.

원문은 중앙 집중형, 연합형과 혼합형 책임 모델을 비교한 뒤 요청부터 공지까지의 기여 생애주기를 설명합니다. 릴리스 유형도 사용 팀에 미치는 영향과 연결합니다. 결과물은 명확한 품질 기준과 마이그레이션 기대 사항을 갖춘 시스템 운영 합의안입니다.

예상 산출물

  • 참여 팀에 맞는 책임 및 기여 모델.
  • 검토와 품질 요구 사항을 갖춘 제안부터 릴리스까지의 절차.
  • 사용 팀을 위한 버전 관리, 사용 중단 및 호환성을 깨는 변경 정책.
예시 브리프 보기

브리프에서 검토까지

  1. 01
    책임 경계 선택

    누가 기반 요소를 관리하고 누가 도메인별 컴포넌트에 기여하는지 정합니다. 팀의 실제 역량에 맞춰 중앙 집중형, 연합형과 혼합형 모델을 비교합니다.

  2. 02
    기여 생애주기 정의

    요청, 분류, 디자인, 검토, 구현, 릴리스와 공지 단계를 명시합니다. 새 컴포넌트를 받아들이기 전에 재사용 가능성 확인과 접근성 검토를 포함합니다.

  3. 03
    사용 팀 대상 변경 규칙 설정

    패치, 마이너, 메이저 릴리스와 변경 이력 작성 기준, 마이그레이션 지침을 정합니다. 전환 기간에 사용 중단 예정 컴포넌트를 계속 사용할 수 있는 방식을 설명합니다.

  4. 04
    합의안 공개 및 유지

    품질 요구 사항과 참여 경로를 문서화합니다. 기여자 피드백과 컴포넌트 도입 정보를 바탕으로 절차를 재검토합니다.

02 활용 상황

언제 사용하면 좋을까요

스킬은 모델 초안을 만들 수 있지만 권한과 책임은 실제 조직을 반영해야 합니다.

적합한 경우

  • 여러 팀이 컴포넌트를 공유할 때기여자에게 명확한 책임과 일관된 변경 경로가 필요합니다.
  • 호환성을 깨는 변경이 혼란을 일으킬 때사용 팀에게 예측 가능한 릴리스 공지와 마이그레이션 기대 사항이 필요합니다.

확인할 한계

  • 조직 차원의 결정스킬은 모델 초안을 만들 수 있지만 권한과 책임은 실제 조직을 반영해야 합니다.
  • 별도의 도입 작업원문은 도입 확대 전략을 design-system-adoption으로 안내합니다.
  • 정책은 구현이 아닙니다문서화된 릴리스 절차 자체가 컴포넌트를 게시하거나 검사를 강제하지는 않습니다.

준비할 입력

  • 팀 구조유지관리자, 기여자와 사용 팀을 명시합니다.
  • 현재 시스템컴포넌트 책임, 릴리스 관행과 문서의 빈틈을 제공합니다.
  • 변경 제약호환성 요구, 마이그레이션 수행 역량과 기대 검토 기준을 포함합니다.

03 핵심 결정

중요한 판단 기준

  1. 명확한 참여

    팀은 제안한 컴포넌트가 검토를 거치는 방식을 알 수 있습니다.

  2. 예측 가능한 변경

    버전과 사용 중단 규칙이 사용 팀이 해야 할 일을 설명합니다.

  3. 공통 품질 기준

    문서, 토큰 사용과 접근성에 대한 기대를 명확히 합니다.

04 예시 브리프

목적을 좁힌 요청으로 시작하세요

아래 예시 브리프는 테스트되지 않았습니다. 사용하기 전에 스킬의 설정을 확인하세요.

소스와 설정 확인

유지관리자, 기여자와 사용 팀을 명시합니다.

업스트림 소스 파일
https://github.com/owl-listener/designer-skills/blob/9a6930cf84a822eb458624bd11c61aac5bbdf224/design-systems/skills/design-system-governance/SKILL.md

아래 참고 링크에서 원본 사용 지침을 확인할 수 있습니다. 사용 전에 리포지터리의 설정 요건을 확인하세요. 설치 명령어가 아닙니다.

결과물 하나부터 시작

스킬을 실행하기 전에 이 브리프의 범위, 소스 자료, 제약 조건을 상황에 맞게 조정하세요.

예시 브리프
design-system-governance로 공용 UI 라이브러리의 운영 모델 초안을 작성해 주세요. 작은 핵심 팀과 도메인별 컴포넌트가 필요한 제품 팀 세 곳이 있습니다. 책임 모델을 비교하고 기반 요소와 확장 요소의 경계를 명확히 제안하세요. 접근성과 토큰 요구 사항을 포함해 요청, 검토와 릴리스 생애주기를 정의하세요. 사용 팀의 마이그레이션 기대 사항을 담은 시맨틱 버전 관리 및 사용 중단 규칙을 제안하세요. 담당자나 날짜를 지어내지 말고 팀 합의가 필요한 결정을 식별하세요. 실용적인 기여 가이드와 미해결 정책 선택 목록을 따로 제공하세요.

결과 확인

실제 출력을 다음의 관찰 가능한 기준과 비교해 확인하세요.

  • 책임과 결정 권한이 가상의 역할이 아니라 실제 팀에 맞습니다.
  • 릴리스와 사용 중단 규칙이 사용 팀의 기대 가능 사항을 설명합니다.
  • 품질 요구 사항에 대해 기여 절차 내 검토 지점이 정해져 있습니다.

OpenDesign은 코딩 에이전트를 위한 로컬 디자인 작업 공간을 제공합니다. 이 목록은 스킬이 번들로 포함되어 있거나 외부 도구, 자격 증명, 소프트웨어 의존성이 포함되어 있다는 뜻이 아닙니다.

05 출처 및 라이선스

소스와 라이선스

이 페이지는 아래에 링크된 고정 소스 리비전을 설명합니다. 업스트림의 동작과 요구 사항은 바뀔 수 있습니다.

소스 소유자
owl-listener
스킬 파일
SKILL.md
라이선스
MIT
검토한 스냅샷
2026-11-02 · 9a6930cf84a8
편집 소스 요약
팀이 공용 디자인 시스템에 기여하고 발전시키는 방식을 정의합니다.

링크된 소스를 바탕으로 OpenDesign이 작성한 원본 요약입니다. 저장소 스타 수는 특정 시점의 인기 지표일 뿐 스킬 사용량이나 품질 점수가 아닙니다.

06 시작 전 질문

시작 전 궁금한 점

중앙 팀 하나가 모든 것을 책임져야 하나요?

아니요. 원문은 중앙 집중형, 연합형과 혼합형 모델을 비교합니다.

호환성을 깨는 변경에는 무엇이 필요하나요?

원문은 마이그레이션 경로, 변경 이력 설명과 마이그레이션 문서를 요구하고 필요에 따라 호환성 지원을 고려합니다.

컴포넌트 품질도 다루나요?

네. 상태와 props 문서화, 접근성 검토, 반응형 동작, 토큰 사용, 디자인 파일과 코드의 일치를 포함합니다.

OpenDesign

작업 요청과 디자인 결과물을 한곳에 모으세요.

브리프, 소스 자료, 디자인 작업을 로컬 작업 공간에 함께 보관하세요. 워크플로에 추가하기 전에 스킬 자체의 설정을 확인하세요.

업스트림 소스 파일
https://github.com/owl-listener/designer-skills/blob/9a6930cf84a822eb458624bd11c61aac5bbdf224/design-systems/skills/design-system-governance/SKILL.md