우리 디자인 시스템 & designlang으로 실제 사이트 디자인 시스템 비교하기

소개

사내 디자인 시스템을 활용해서 클로드 디자인 활용도를 높이기 위해 시작했어요.
아주 간소한 수준의 디자인 시스템을 갖고 있는데요. 이 내용과 회사 홈페이지에서 자동 추출 도구로 초안을 뽑아 비교해보는 과정을 거쳤어요.

• 자동 추출 도구(designlang)가 실제로 얼마나 믿을 만한지, 어떤 종류의 오류를 만드는지

• Claude로 웹 컴포넌트 + PPTX 카탈로그 규칙까지 한 번에 정리하고, 그걸 Claude Design에 실제로 업로드해서 팀 디자인 시스템으로 굴릴 수 있는지

진행 방법

1단계 — 자동 추출 (designlang)

Node.js 환경에서 CLI 도구 하나로 사이트를 분석했습니다.

헤드리스 브라우저로 실제 페이지를 렌더링한 뒤, DOM 912개 요소의 getComputedStyle()을 통계 내서 색·폰트·여백·컴포넌트 패턴을 36개 포맷(마크다운, Tailwind config, Figma 변수, DTCG JSON, 모션 프리셋 등)으로 뽑아줍니다. 프롬프트는 스터디장께서 제공 :)

실행한 프롬프트: "내 컴퓨터에 Node.js가 설치돼 있는지 확인해줘 → 없으면 설치까지, 있으면 버전만 알려줘" 로 환경부터 점검하고 시작했습니다.

2단계 — 결과 검증 및 노이즈 짚어내기

뽑힌 결과를 그대로 믿지 않고, "이 도구가 뭘 하는 도구인지" + "믿으면 안 되는 값이 뭔지"를 먼저 물었습니다.

실행한 프롬프트: "방금 designlang이 뽑은 결과를 바탕으로, 이 도구가 무엇을·어떻게·왜 하는지 직관적으로 설명해줘. 그리고 추출된 핵심 토큰(색·폰트·여백·컴포넌트)을 요약하고, 믿을 수 없는 노이즈(예: 이모지가 폰트로 잡히는 것)가 있으면 짚어줘."

이 단계에서 실제로 잡아낸 오류들 (생각보다 많았어요)

• Primary 컬러 오판정 — 사용 빈도 1회짜리 색을 primary로 승격

• 유령 폰트 3종 — Arial·Times는 브라우저 폴백, WistiaPlayerInter는 삽입된 영상 플레이어의 내부 폰트였는데 이걸 근거로 "폰트 4종 → 2종으로 줄여라"는 잘못된 진단까지 생성

• `[object Object]` 직렬화 버그 — 브레이크포인트·이징·시맨틱 컬러 값이 마크다운에서 깨져 나옴

• 컴포넌트 CSS 오염 — .button{border-radius:100%}처럼 실제로는 원형 아이콘 1개의 계산값을 버튼 대표값으로 제시

3단계 — 교정·매핑·통합 (Claude로 재구성)

교정한 토큰을 실제 상세페이지 컴포넌트(히어로/가격표/CTA/카드/뱃지)와 PPTX 카탈로그 규칙에 매핑해달라고 요청했습니다.

실행한 프롬프트: "designlang이 뽑아준 토큰과 브랜드 문서를 원본 초안으로 삼아, 다음을 해줘: 1. 추출 노이즈(폰트·색 대비 등) 필요하면 교정하고 대안 제시 2. 이 토큰을 상세페이지(HTML)의 실제 컴포넌트(히어로/가격표/CTA/카드/뱃지)에 매핑한 적용 가이드 3. PPTX 카탈로그용 규칙(표지·본문 슬라이드 색/폰트/여백) 별도 정리 4. 위를 하나의 HTML로 묶어 한눈에 디자인 시스템을 살펴보게 해줘. 보고 피드백할게."

이 과정에서 Claude가 직접 Node.js로 WCAG 대비 공식(`relative luminance`)을 계산해서, "이 파랑은 실제로 흰 배경에서 텍스트로 쓰면 안 된다"는 걸 수치로 확정했습니다.

결과물은 색상/타이포/여백/모션/웹 컴포넌트 5종/PPTX 규칙/토큰 코드까지 스크롤 한 번으로 훑을 수 있는 단일 HTML 파일로 받았습니다.

4단계 — Claude Design에 실제 업로드

마지막으로 이 결과물을 팀이 재사용할 수 있는 형태로 claude.ai/design에 올렸습니다.

실행한 프롬프트: "방금 우리가 이 대화에서 함께 만든 디자인 시스템을, 클로드 디자인(claude.ai/design)의 디자인 시스템으로 업로드해줘. 컴포넌트별 @dsCard 미리보기 카드 + 토큰을 담은 업로드용 패키지로 먼저 재구성해줘(아직 없으면 지금 만들어줘). 'TL from Web 디자인 시스템'이라는 새 프로젝트를 만들어 올려줘. 도중에 디자인 권한 승인 창이 뜨면 알려줘, 내가 승인할게."

이 단계에서 한 게:

• 컴포넌트별로 @dsCard 마커가 붙은 독립 실행형 HTML 미리보기 카드 12장 제작 (색상/타이포/여백/모션/히어로/버튼/뱃지/카드/가격표/CTA/PPTX규칙/교정이력)

• tokens.css, tokens.json(DTCG), tailwind.config.js, AI 에이전트용 요약 문서까지 패키지화

• Claude Design 프로젝트를 새로 생성하고, 파일 18개 업로드 + 카드 12장 등록

권한은 이미 승인돼 있어서 별도 승인 창 없이 한 번에 진행됐습니다.

5단계 — 기존 회사 디자인 시스템과 비교해서 "언제 뭘 쓸지" 기준 세우기

실행한 프롬프트: "방금 만든 디자인시스템과 더 이전에 업로드한 회사 디자인시스템은 어떤 차이가 있어 보여?"

Claude가 두 프로젝트의 파일을 직접 열어서 비교한 결과, 소스 자체가 다르다는 게 핵심이었습니다.

핵심 브랜드 컬러 값은 두 시스템이 거의 일치했습니다 — 완전히 다른 방법(공식 자산 vs 웹 역추출)으로 도달했는데 같은 결론에 수렴한 셈이라, 오늘 교정한 primary 판단이 맞았다는 교차검증이 됐습니다.

결과와 배운 점

결과

• 팀 디자인 시스템 프로젝트가 claude.ai/design에 생성됨

• 색상 21개 조합의 WCAG 대비 실측표, 웹 컴포넌트별 스펙, 웹→PPT px/pt 변환표까지 재사용 가능한 형태로 정리됨

• 가장 중요한 결과물은 카드 자체가 아니라 "언제 이걸 쓰고 언제 기존 걸 써야 하는지" 기준이었습니다.

★ 실전에서 어떻게 쓸지 — 이번 작업에서 가장 중요했던 결론

같은 회사, 같은 이름의 디자인 시스템이 claude.ai/design에 두 개가 됐다는 걸 알았을 때 처음 든 생각은 "합쳐야 하나"였습니다. 하지만 실제로 내용을 열어서 비교해보니, 두 개를 합치는 게 아니라 용도로 나눠 쓰는 게 맞는 결론이었습니다.

그래서 실무 룰로 정리하면, 두 시스템을 억지로 병합하지 말고, claude.ai/design 프로젝트 이름에 소스를 명시하는 게 나았습니다. 이번엔 이름만으로 구분이 안 돼서 나중에 헷갈릴 뻔했습니다.

배운 점 / 꿀팁

1. 자동 추출 도구는 "초안 생성기"로만 쓰고, 반드시 검증 단계를 분리해서 요청하는 게 핵심이었습니다. "뽑아줘"와 "이 결과에서 믿으면 안 되는 걸 짚어줘"를 한 프롬프트에 섞지 않고 별도 턴으로 나누니, Claude가 도구 출력 자체를 의심하고 검토하는 모드로 훨씬 꼼꼼하게 작동했습니다.

2. 여러 디자인 시스템 프로젝트가 쌓이면, 만들기 전에 "기존에 뭐가 있는지 먼저 훑어달라"고 요청하는 습관이 필요합니다. 이번엔 업로드 다 끝난 뒤에야 기존 프로젝트 존재를 알아챘는데, 순서가 바뀌었으면 애초에 이름을 더 명확히 지었을 겁니다.