StyleGallery는 사이트가 아니다

이름만 보면 시각 갤러리 같지만, StyleGallery는 화면이 아니라 문서다. npm으로 배포되는 docs-as-code 지식 저장소이고, 사람은 마크다운을 읽고 에이전트는 CLI sg·sg-material과 읽기전용 MCP 두 개로 같은 지식을 먹는다. 이 저장소가 다루는 종류의 레이아웃 골격을 먼저 눈으로 보자. 아래는 Giting이 직접 만든 라이브 데모다. 폭을 드래그해 바꾸면 레이아웃이 실제로 반응하고, 체크박스로 핵심 속성을 빼면 어떻게 깨지는지 볼 수 있다. 저장소의 코드·이미지는 복제하지 않았고, 계보는 web.dev one-line-layouts다.

여섯 도메인, 각기 다른 증거 기준

지식은 여섯 도메인으로 갈라져 있고, 도메인마다 무엇을 증거로 삼고 어디까지가 자기 소유인지를 GOVERNANCE.md·DOMAINS.md가 문서로 못박는다.

패턴 문서의 해부

핵심 자산은 patterns/다. centering·containment·grid-repetition 같은 카테고리 아래 clamped-card·ram-grid·deconstructed-pancake 같은 고전 레이아웃 패턴이 한 파일당 하나씩 서술된다. 각 패턴은 정형 frontmatter와 고정 섹션을 갖는다.

# 패턴 문서의 정형 필드 (Giting이 정리한 형태)
primary_spatial_problem: 무엇을 푸는 배치인가
layout_axis: inline | block | both
content_shape: 내용의 형태 전제
responsiveness: fluid 등
scroll_ownership: 스크롤을 누가 갖나
source_lineage: 출처 URL (계보를 URL로 남긴다)
lifecycle: generated | experimental

본문은 When To Use, HTML, CSS, Properties That Break The Layout If Removed, Constraints And Change Points, Scroll Ownership, Accessibility And Source Order Notes, Anti-patterns 같은 고정 순서로 전개된다. 굵게 표시한 절이 이 저장소의 가장 곧은 발명이다. "이 선언을 제거하면 레이아웃이 깨진다"를 명시하면, 패턴 문서가 예시 모음에서 인과가 붙은 문서로 올라간다. CSS는 색·그림자·타이포를 전부 걷어낸 순수 공간 골격만 담는다.

마크다운은 손으로 쓴 게 아니다

흥미로운 건 이 패턴 문서가 생성물이라는 점이다. scripts/generate-patterns.mjs+scripts/pattern-data.mjs가 소스 데이터에서 마크다운을 찍어내고, 파일마다 'Do not hand-edit' 주석이 붙는다. 소스 데이터가 SSOT이고 마크다운은 산출물인 구조다. 용어 도메인(design-terminology)도 사전이 아니라 분류 방법론이라, "용어는 출처가 오늘 쓰는 그대로 분류하고 병합 정의를 먼저 만들지 않는다" 같은 규율을 표로 고정한다. token·component·pattern처럼 시스템마다 뜻이 갈리는 단어를 비교하는 리뷰 도구다.

에이전트 접속면

sg CLI는 모든 명령이 결정적 JSON을 stdout에 쓰고 잘못된 입력은 에러 객체와 비영 종료로 답한다. 신뢰·전송·확장을 나눈 'agent-native' 계층이 있고, @modelcontextprotocol/sdk로 읽기전용 MCP 서버 두 개를 노출한다. 런타임 의존성은 넷(@chenglou/pretext·@modelcontextprotocol/sdk·style-dictionary·zod)으로 얇다. 사람과 에이전트가 같은 지식을 다른 창구로 먹게 설계했다는 점이 이 저장소의 성격을 요약한다.

실측: 되는 것과 무른 것

되는 것은 진짜다. 전체 커밋 154회 중 147회가 90일 안에 몰려 최근 6개월 집중 개발이고, 마지막 커밋이 2026-09-09로 활발하다. 테스트 파일이 80개, CI 워크플로우 3개(validate·evidence-freshness·story-examples)가 PR·main push에서 돌며 액션은 SHA 핀·권한 최소화(contents: read)다. 공급망·거버넌스 규율이 몸에 밴 저장소다.

무른 것도 분명하다. 원격 태그가 1개뿐이라 버전 이력이 얕고, 기여자 7명 중 유사 표기가 있어 실질 주도는 소수로 보인다(개인 신상은 다루지 않는다). 오픈 이슈는 응답 기록이 없어 외부 커뮤니티 상호작용은 미검증이다. 그리고 LOC 10.7만 줄의 상당 부분이 생성 마크다운·205개 mjs·2.6만 줄짜리 Unity 스캔 JSON이라, 줄 수를 성숙도로 읽으면 안 된다. 무엇보다 라이선스가 없다(SPDX null · LICENSE 부재). npm 공개 배포가 재사용 허가를 뜻하지 않으므로, 문구·코드·표를 가져다 쓰기 전에 원저작자 허락이 필요하다. 이 리포트가 저장소의 문장·코드를 복제하지 않고 개념만 우리 말로 옮긴 이유이기도 하다.

실측 정보

HEAD 커밋

a415777 (2026-09-09)

형태

npm 배포 docs-as-code 지식 저장소. 사람은 마크다운, 에이전트는 CLI(sg·sg-material) + 읽기전용 MCP 2개

도메인

6개: Layout · Motion · Design Engineering · Game UI · Platform Guides · Design Terminology (각기 증거 기준·소유권 경계 다름)

규모

546파일 · 텍스트 106,722줄 (mjs 205파일 35,257줄 · css 7파일 1,342줄 · html 5파일 640줄)

최대 파일

game-ui/unity/…/unity-technologies-public-repositories.json: 26,655줄(Unity 리포 스캔 산출물)

개발 밀도

전체 커밋 154 중 90일 내 147 (2026-03 착수, 최근 6개월 집중)

테스트 / CI

테스트 파일 80 · CI 워크플로우 3(validate·evidence-freshness·story-examples), 액션 SHA 핀 + contents:read 최소권한

런타임 의존성

4개 (@chenglou/pretext · @modelcontextprotocol/sdk · style-dictionary · zod)

원격 태그

1개 (버전 이력 얕음)

라이선스

없음. SPDX null · LICENSE 파일 부재 → 저작권 전부 유보

적용점

• 이럴 때 유용레이아웃 패턴을 팀 지식으로 문서화하려는 조직에 서술 스키마가 참고 표준이 된다. 특히 '이 선언을 제거하면 레이아웃이 깨진다'를 절로 못박는 방식은 패턴 문서를 인과가 붙은 문서로 끌어올린다.
• 이럴 땐 과설계지식 도메인 한둘을 운영하는 소규모에겐 agent-native 계층·lifecycle disposition 같은 6도메인 거버넌스 기구가 무겁다. 서술 스키마만 얇게 참고하는 편이 맞다.
• 먼저 볼 수치LOC 10.7만 줄이 아니라 테스트 80·CI 3·90일 147커밋이 성숙도 신호다(상당수 줄은 생성 마크다운·205 mjs·2.6만 줄 스캔 JSON). 그리고 라이선스가 없다. 재사용 전 반드시 확인.

의견

판정에 대한 반론, 도입 경험, 정정 제보를 환영합니다. GitHub 계정으로 참여합니다.