extract

extract 스킬 개요

extract가 하는 일

extract 스킬은 반복되는 UI 코드를 재사용 가능한 디자인 시스템 자산으로 정리하도록 돕습니다. 예를 들어 공용 컴포넌트, design token, 표준화된 패턴으로 추출하는 작업에 적합합니다. 이미 제품 UI가 존재하고, 여기저기 중복된 구현을 더 체계적인 구조로 통합하려는 팀에 맞춰져 있으며, 막연한 아이디어 발상용 프롬프트를 찾는 경우에는 적합하지 않습니다.

extract가 가장 잘 맞는 대상

extract는 프런트엔드 엔지니어, 디자인 시스템 관리자, 그리고 화면이나 기능 간 드리프트를 정리하려는 제품 팀에 특히 유용합니다. 특히 동일한 버튼, 카드, 폼 패턴, spacing scale, 색상 사용 방식이 여러 곳에 반복되고 있고, 이를 하나로 통일해야 한다고 이미 느끼고 있을 때 잘 맞습니다.

extract의 실제 해결 과제

extract 스킬의 진짜 가치는 단순히 “중복 찾기”에 있지 않습니다. 이 스킬은 에이전트가 다음을 수행하도록 유도합니다.

• 먼저 기존 디자인 시스템 또는 shared UI 레이어를 찾기
• 추출할 가치가 있는 패턴 식별하기
• 성급한 추상화 피하기
• 반복 코드를 재사용 가능한 시스템으로 옮기되, 마이그레이션 계획까지 세우기

이 점 때문에 일반적인 “이 UI를 리팩터링해줘” 프롬프트보다 실무적입니다. 특히 extract for Design Systems처럼 이름짓기, 구조 설계, 마이그레이션 리스크가 중요한 작업에서 차이가 큽니다.

이 extract 스킬이 다른 점

이 스킬은 워크플로가 분명합니다. 현재 시스템을 파악하고, 추출 후보를 찾고, 정말 시스템화할 가치가 있는지 판단한 뒤, 신중하게 추출하고 마이그레이션합니다. 가장 강력한 차별점 중 하나는 명확한 가드레일입니다. 디자인 시스템이 없으면, 멋대로 새로 만들지 말고 먼저 물어보도록 에이전트에 지시합니다. 덕분에 AI가 저장소 구조에 맞지 않는 임의의 컴포넌트 아키텍처를 만들어내는 흔한 실패를 줄일 수 있습니다.

extract를 설치해야 하는 경우

주요 목적이 반복되는 UI 패턴을 기존 또는 도입 예정인 디자인 시스템으로 통합하는 것이라면 extract를 설치할 만합니다. 반대로 일회성 컴포넌트를 빠르게 하나 만드는 정도라면 직접 프롬프트를 쓰는 것으로 충분할 수 있습니다. 속도보다 일관성, 재사용성, 마이그레이션 품질이 더 중요할 때 extract 설치 판단이 특히 타당합니다.

extract 스킬 사용 방법

extract 스킬 설치

실용적인 설치 명령은 다음과 같습니다.

npx skills add https://github.com/pbakaus/impeccable --skill extract

이 스킬은 .claude/skills/extract에 들어 있으므로, 시작할 때 저장소 전체를 훑을 필요는 없습니다.

먼저 읽을 파일

다음 파일부터 확인하세요.

• SKILL.md

이 경우 SKILL.md가 단일 진실 소스(source of truth)입니다. 저장소 근거상 별도의 스크립트, 규칙, 참조 폴더가 드러나 있지 않으므로, 실질적으로 활용할 수 있는 가이드는 대부분 여기에 모여 있습니다.

예상 호출 형태를 이해하기

이 스킬은 user-invocable로 표시되어 있으며, 인자 힌트는 다음과 같습니다.

[target]

실제로는 요청할 때 구체적인 대상 영역을 지정해야 한다는 뜻입니다. 예를 들면:

• 기능 폴더
• 페이지
• 컴포넌트 집합
• 반복 패턴이 보이는 UI surface

예를 들어 “우리 디자인 시스템을 개선해줘”처럼 막연한 요청보다, “src/features/billing에 extract를 실행해서 재사용 가능한 form 패턴과 card 패턴을 식별해줘”처럼 말하는 편이 훨씬 강합니다.

extract에는 큰 포부보다 구체적 대상을 주기

extract 스킬은 대상 범위가 적절히 한정될 때 가장 잘 작동합니다. 좋은 대상은 보통 다음 중 하나에 해당합니다.

• 중복 UI가 있는 디렉터리
• 눈에 띄는 비일관성이 있는 제품 영역
• 하드코딩된 스타일을 token으로 옮기려는 마이그레이션
• variant로 정리되어야 할 유사 컴포넌트 묶음

이렇게 해야 신호가 좋아집니다. extract는 추상화를 막연하게 발명하는 도구가 아니라, 실제 재사용 기회를 평가하도록 설계되어 있기 때문입니다.

거친 목표를 강한 extract 프롬프트로 바꾸기

약한 프롬프트:

• “Use extract on our app.”

더 강한 프롬프트:

• “Use extract on src/app/settings and src/components/settings. Find repeated controls, hard-coded spacing and color values, and any patterns already close to our shared UI conventions. Propose what should become a shared component or token, what should stay local, and a safe migration order.”

이 프롬프트가 잘 작동하는 이유:

• 대상을 명확히 지정합니다
• 컴포넌트 추출과 token 추출을 구분해서 요청합니다
• 로컬에 남길지 판단하게 해 과도한 추상화를 줄입니다
• 실제 저장소에서 핵심인 마이그레이션 순서를 요구합니다

어떤 입력이 출력 품질을 실질적으로 높이는가

더 나은 extract usage를 원한다면 다음 정보를 함께 주세요.

• 기존 디자인 시스템 또는 shared UI 폴더 위치
• React, Tailwind, CSS Modules, styled-components 같은 프레임워크 및 스타일링 스택
• 현재 사용 중인 네이밍 규칙
• token source, theme file, 또는 style dictionary
• 제안만 원하는지, 실제 코드 수정까지 원하는지

이 맥락이 없어도 에이전트는 반복을 찾아낼 수는 있지만, 추출 계획이 현재 아키텍처와 충돌할 가능성이 높아집니다.

저장소가 의도한 워크플로를 따르기

이 스킬의 워크플로는 단순하지만 중요합니다.

1. 디자인 시스템 찾기
2. 반복 패턴과 하드코딩된 값 식별하기
3. 추출이 정당한지 평가하기
4. 시스템으로 추출하고 보강하기
5. 사용처 마이그레이션하기

특히 “추출 전에 가치 평가하기” 단계가 중요합니다. 이 스킬은 모든 것을 추출하면 안 된다고 명시적으로 경고합니다. 한두 번만 쓰인 패턴은 아직 공용 시스템에 들어갈 대상이 아닐 수 있습니다.

extract는 단순 중복 제거가 아니라 Design Systems 작업에 쓰기

extract for Design Systems의 가장 좋은 활용법은 중복 코드를 기계적으로 지우는 것이 아닙니다. 무엇을 시스템 레이어에 넣고, 무엇을 기능 로컬 코드로 남겨야 하는지 결정하는 데 있습니다. 다음 범주로 분류해 달라고 요청해 보세요.

• 재사용 가능한 컴포넌트
• design token
• composition pattern
• 현재 위치에 남겨야 하는 로컬 전용 코드

이렇게 해야 실제로 검토하고 도입할 수 있는 결과가 나옵니다.

수정 요청 전에 먼저 제안을 받기

도입 시 실무적으로 안전한 흐름은 다음과 같습니다.

1. extract에 분석 결과와 후보를 요청하기
2. 네이밍, 소유권, 마이그레이션 범위를 검토하기
3. 추출 구현을 요청하기
4. 작은 배치 단위로 마이그레이션하기

특히 현재 디자인 시스템이 아직 덜 갖춰진 상태라면, 앱 전체를 즉시 수정하게 하는 것보다 이 방식이 훨씬 안전합니다.

extract에서 보통 잘 먹히는 프롬프트 패턴

다음과 같은 요청이 대체로 잘 작동합니다.

“Use extract on [target]. First locate our existing design system or shared UI directory and summarize its conventions. Then identify repeated components, inconsistent variants, and hard-coded visual values worth turning into tokens. For each candidate, say whether it should be extracted now, deferred, or kept local. After that, propose a migration plan with the lowest-risk order.”

이 패턴은 스킬의 기본 워크플로와 매우 잘 맞고, 일반적인 리팩터링 요청보다 대체로 더 높은 품질의 결과를 냅니다.

extract 실행 전에 먼저 정할 제약 조건

extract 스킬을 쓰기 전에 다음을 먼저 결정해 두세요.

• 에이전트가 새 shared component를 만들어도 되는가, 아니면 제안만 해야 하는가?
• 지금 token까지 도입할 것인가, 아니면 컴포넌트 통합만 할 것인가?
• 엄격한 하위 호환성이 필요한가?
• import와 파일 위치를 바꿔도 되는가?

이 제약들은 추천 결과를 실질적으로 바꿉니다. 이 스킬은 계획 단계인지, 구현 단계인지, 마이그레이션 단계인지 알고 있을 때 훨씬 유용합니다.

extract 스킬 FAQ

extract는 일반 리팩터링 프롬프트보다 나은가?

대체로 그렇습니다. 문제가 개별 정리가 아니라 시스템화라면 특히 그렇습니다. 일반 프롬프트는 곧바로 코드 수정으로 뛰어드는 경우가 많습니다. 반면 extract는 기존 디자인 시스템 구조를 먼저 살펴보고, 무엇이 진짜 재사용 가능한지 판단하며, 저장소가 감당할 수 없는 추상화를 만들지 않도록 유도할 때 더 강합니다.

extract는 초보자도 쓰기 쉬운가?

네, 범위가 한정되어 있다면 그렇습니다. 초보자도 하나의 기능 영역을 지정하고 먼저 제안을 요청하는 방식으로 extract 스킬을 충분히 효과적으로 사용할 수 있습니다. 반대로 규칙이나 경계 없이 전체 UI 아키텍처를 재구성해 달라고 하면 난도가 크게 올라갑니다.

extract를 쓰려면 기존 디자인 시스템이 꼭 필요한가?

아니요. 다만 결정은 필요합니다. 디자인 시스템이 없을 경우, 새 디자인 시스템을 만들기 전에 먼저 사용자에게 물어보라고 이 스킬이 명시적으로 지시합니다. 이는 조용히 아키텍처를 지어내는 일을 막아 주기 때문에, 실제 도입 관점에서 오히려 긍정적인 신호입니다.

언제 extract를 쓰지 말아야 하나?

다음 상황에서는 extract를 쓰지 않는 편이 낫습니다.

• 일회성 컴포넌트 하나만 필요할 때
• UI가 아직 너무 초기라 추상화할 시점이 아닐 때
• 패턴이 한 번만 등장할 때
• 재사용성보다 픽셀 단위 polish가 목표일 때
• shared UI를 어디에 둘지 합의가 없을 때

이런 경우에는 더 단순한 프롬프트를 쓰거나, 먼저 디자인 결정을 하는 편이 시간을 아낍니다.

extract는 어떤 종류의 패턴을 찾는가?

이 스킬은 다음 유형에 초점을 둡니다.

• 반복되는 컴포넌트
• 같은 개념인데 구현이 제각각인 경우
• 하드코딩된 색상, spacing, typography, shadow
• 재사용 가능한 레이아웃 또는 인터랙션 패턴

즉, 단순한 JSX 중복 제거를 넘어 token 추출과 shared component 작업에 실용적입니다.

extract는 다양한 프런트엔드 스택에 어떻게 맞는가?

핵심 로직은 재사용성과 시스템 경계를 식별하는 것이므로 스택에 종속되지 않습니다. 다만 출력 품질은 사용자가 스택과 규칙을 얼마나 명확히 알려주느냐에 크게 좌우됩니다. 앱이 Tailwind, CSS variables, 또는 컴포넌트 라이브러리 래퍼를 사용한다면 처음부터 밝혀야, 추출 계획이 실제 코드베이스 방식과 맞아떨어집니다.

extract 스킬을 더 잘 활용하는 방법

생각보다 더 좁은 대상부터 시작하기

가장 흔한 실수는 범위를 너무 넓게 잡는 것입니다. 먼저 하나의 기능, 하나의 route group, 혹은 하나의 컴포넌트 계열에 extract를 실행할 때 결과가 더 좋습니다. 그래야 에이전트가 충분한 반복 사례를 분석하면서도, 너무 이른 전사적 아키텍처 추상화로 치우치지 않습니다.

디자인 시스템 위치를 extract에 명확히 알려주기

shared UI 위치를 알고 있다면 명시적으로 적어주세요.

• src/components/ui
• packages/design-system
• app/shared/components

이렇게 하면 추측이 줄어들고, 기존 import 방식, 네이밍, 소유권 패턴을 존중하는 추천을 받을 가능성이 높아집니다.

추출 후보만이 아니라 추출 기준도 설명하게 하기

효과적인 개선 프롬프트 예시는 다음과 같습니다.

• “Use extract, but explain why each candidate should be shared now, later, or never.”

이렇게 하면 재사용 결정을 내리는 기준선이 드러납니다. 덕분에 약한 추상화가 잔뜩 쌓인 비대한 디자인 시스템을 피하는 데 도움이 됩니다.

요청에서 token과 component를 분리하기

사용자는 종종 모든 재사용 작업을 한 덩어리로 요청합니다. 하지만 다음처럼 나눌수록 결과가 좋아집니다.

• token 기회: colors, spacing, type, shadows
• component 기회: buttons, cards, inputs, banners
• composition 기회: layouts, form sections, 반복 조립 패턴

이렇게 구분하면 구현과 리뷰가 훨씬 수월해집니다.

마이그레이션 리스크와 영향 범위를 함께 물어보기

광범위한 회귀(regression)에 대한 두려움은 도입을 막는 가장 큰 요인 중 하나입니다. extract usage를 개선하려면 다음을 함께 요청하세요.

• 영향받는 파일 또는 영역
• 예상되는 breaking change
• 쉽게 얻을 수 있는 성과와 위험한 추출 작업
• 마이그레이션 순서

그러면 첫 결과물부터 유지보수자가 승인 가능한 형태에 가까워집니다.

로컬에 남겨야 할 예시를 함께 주기

유용한 프롬프트 추가 문구:

• “Keep product-specific or one-off logic local unless reuse is clearly justified.”

이는 AI의 전형적인 실패를 막아줍니다. 겉보기에 비슷하다는 이유만으로 전부 추출해 버려, 의미 차이와 장기 유지보수성을 오히려 해치는 일을 줄일 수 있습니다.

첫 번째 결과 이후 다시 좁혀서 반복하기

첫 번째 extract guide 결과를 받은 뒤에는 다음과 같이 후속 요청해 보세요.

• “Narrow this to only token extraction.”
• “Rework the plan to fit our existing component naming.”
• “Only include patterns used 3+ times.”
• “Convert this proposal into a phased migration checklist.”

초기 분석을 본 뒤 추출 기준을 더 엄격히 잡아 주면, 이 스킬의 결과 품질이 눈에 띄게 좋아집니다.

과도한 추상화를 경계하기

흔한 실패 유형 중 하나는, 더 단순한 shared primitive나 token이면 충분한데도 지나치게 설정 가능한 컴포넌트를 만들어내는 것입니다. props나 variant가 너무 많은 제안이 보인다면, 에이전트에게 다음을 우선하라고 요청하세요.

• 더 적은 수의 shared component
• 더 많은 token화
• 더 작은 composition 단위
• 제품 의미가 다를 때는 로컬 wrapper 유지

대체로 이런 방향이 더 건강한 디자인 시스템으로 이어집니다.

구현 전에 판단 보조 도구로 extract 쓰기

많은 팀에게 extract 스킬의 최적 사용 방식은 먼저 진단하고, 그 다음 구현하는 것입니다. 코드를 쓰기 전에 기회와 tradeoff를 맵핑하게 하세요. 특히 레거시 코드베이스에서는 잘못된 추상화가 절약보다 더 많은 마이그레이션 작업을 만들 수 있으므로, 이 접근이 특히 가치 있습니다.

저장소 고유 용어를 주면 extract 결과가 더 좋아진다

팀에서 “primitives”, “recipes”, “slots”, “tokens”, “foundations” 같은 용어를 쓴다면 프롬프트에 그대로 포함하세요. extract 스킬은 유지보수자가 이미 쓰는 어휘와 구조를 따라갈 수 있을 때 훨씬 유용합니다. 그래야 추천안이 병합하기 쉽고, 이후에도 지속적으로 유지하기 쉬워집니다.