extract

extract 스킬 개요

extract가 하는 일

extract 스킬은 반복되는 UI 코드를 재사용 가능한 디자인 시스템 자산으로 바꾸는 데 도움을 줍니다. 실제로는 중복 컴포넌트, 하드코딩된 디자인 값, 일관성 없는 패턴을 찾아낸 뒤, 공용 컴포넌트와 토큰으로 제안하거나 추출해 주는 역할을 합니다.

extract가 잘 맞는 사용자

이 extract 스킬은 제품 UI, 컴포넌트 라이브러리, 디자인 시스템을 다루는 팀에 특히 잘 맞습니다. 이미 어느 정도 코드 중복이 있고, 이를 더 체계적으로 정리·통합하고 싶을 때 효과적입니다. 특히 프론트엔드 엔지니어, 디자인 시스템 유지보수 담당자, AI 보조 리팩터링 워크플로를 쓰는 팀에 유용합니다.

실제로 해결하려는 핵심 문제

대부분의 사용자는 단순한 범용 리팩터링을 원하는 것이 아닙니다. 실제로는 “무엇을 공용 컴포넌트로 빼야 할까?”, “어떤 값들을 토큰으로 만들어야 할까?”, “앱을 깨뜨리지 않고 어떻게 마이그레이션할까?” 같은 질문에 답하고 싶어 합니다. extract 스킬은 단순 코드 정리가 아니라, 이런 의사결정 흐름에 맞춰 설계되어 있습니다.

이 extract 스킬이 다른 점

보통의 프롬프트가 “이걸 재사용 가능하게 만들어”라고 끝나는 것과 달리, extract는 발견 단계부터 시작합니다. 현재 디자인 시스템을 찾고, 네이밍과 토큰 규칙을 살펴보고, 반복 패턴을 식별하고, 실제로 추출할 가치가 있는지 평가한 다음, 마지막으로 마이그레이션 계획까지 세웁니다. 그래서 즉흥적인 컴포넌트 생성보다 디자인 시스템 작업에 더 잘 맞습니다.

이 스킬이 특히 잘 맞는 경우

다음이 필요할 때 extract를 쓰면 좋습니다:

• 반복되는 UI 패턴을 공용 컴포넌트로 통합해야 할 때
• 색상, 간격, 타이포그래피 값 같은 토큰 후보를 찾아야 할 때
• 같은 개념의 서로 다른 구현을 표준화해야 할 때
• 처음부터 새 디자인 시스템을 만드는 것이 아니라, 기존 시스템을 보강해야 할 때
• 많은 파일을 수정하기 전에 먼저 추출 계획을 세워야 할 때

설치 전에 꼭 알아둘 경계 조건

가장 큰 도입 제약은 extract가 이미 확장할 수 있는 디자인 시스템이나 공용 UI 구조가 있을 가능성을 전제한다는 점입니다. 그런 기반이 없다면, 이 스킬은 진행 전에 “어디에, 어떤 방식으로 새 구조를 만들어야 하는가”를 먼저 따지도록 유도합니다. 완전히 제로 상태에서 그린필드 디자인 시스템 아키텍처를 세우려는 목적이라면, 이 스킬은 부분적으로만 맞습니다.

extract 스킬 사용 방법

extract 스킬 설치

다음 명령으로 저장소에서 스킬을 설치하세요:

npx skills add pbakaus/impeccable --skill extract

설치 후에는 일회성 화면을 만드는 작업이 아니라, 재사용 가능한 UI 패턴이나 토큰을 추출하는 작업일 때 호출하는 것이 좋습니다.

extract 호출 전에 준비하면 좋은 입력

extract 스킬은 다음 정보를 주었을 때 가장 잘 작동합니다:

• 대상 영역, 기능 폴더, 또는 중복된 파일 묶음
• 현재 디자인 시스템 또는 공용 UI 라이브러리의 위치
• 사용 중인 프레임워크와 스타일링 스택
• 해결하고 싶은 재사용 문제의 구체적 내용
• 예: “공개 export 이름은 바꾸지 말 것” 같은 마이그레이션 제약

“이거 좀 정리해줘” 같은 모호한 요청은 추측의 여지가 너무 큽니다. 더 좋은 요청은 반복되는 패턴이 무엇인지, 그리고 어디로 옮길지를 분명히 적습니다.

두루뭉술한 요청을 강한 extract 프롬프트로 바꾸기

약한 프롬프트:

• “Refactor these components.”

더 나은 extract 사용 예:

• “Use the extract skill on src/features/billing and src/features/settings to find repeated form-row and card patterns. Our shared components live in src/ui. We use React, TypeScript, and CSS modules. Prefer extracting tokens for spacing and colors only if they appear in 3+ places. Propose a migration plan before editing.”

이런 프롬프트는 스킬이 필요한 발견, 가치 판단, 과도한 추출 방지까지 제대로 수행할 수 있게 해줍니다.

extract가 먼저 살펴봐야 하는 것

시작할 때는 스킬이 다음 위치를 보도록 지정하세요:

• 중복 UI가 있을 것으로 보이는 영역
• 공용 컴포넌트 디렉터리
• 토큰 또는 테마 파일
• 있다면 기존 문서나 스토리 파일

원본 스킬은 먼저 디자인 시스템을 찾는 것을 강조합니다. 이는 추출 품질이 기존 네이밍, 구조, import 규칙, 문서화 패턴에 얼마나 잘 맞추는지에 크게 좌우되기 때문입니다.

디자인 시스템 작업을 위한 extract 권장 워크플로

실무적으로는 다음 순서가 좋습니다:

1. 현재 디자인 시스템 또는 공용 UI 폴더를 찾는다
2. 대상 영역에서 반복되는 컴포넌트와 하드코딩된 값을 스캔한다
3. 시각적으로 비슷해 보인다고 전부 추출하지 말고, 유사 패턴을 묶어 본다
4. 무엇을 공용 primitive, 조합형 컴포넌트, 토큰으로 만들지 결정한다
5. 추출 계획을 제안한다
6. 사용하는 파일들을 신중하게 마이그레이션한다

이 순서야말로 이 스킬의 핵심 가치입니다. 너무 이른 추상화를 줄여 줍니다.

저장소에서 먼저 읽어야 할 것

이 스킬은 가볍고 구조가 단순합니다. 먼저 SKILL.md를 읽고, 이를 기본 운영 가이드로 삼는 것이 좋습니다. 특히 다음 섹션에 집중하세요:

• Discover
• Plan Extraction
• Extract & Enrich
• Migrate

이 스킬 폴더에는 별도 helper script나 참고 자료가 거의 없기 때문에, 실제 가치는 이 의사결정 순서를 정확히 따르는 데 있습니다.

extract가 재사용 여부를 판단하는 기준

extract 도입 여부를 잘 판단하려면, “모든 것을 추출해야 하는 것은 아니다”라는 이 스킬의 기본 관점에 동의하는지가 중요합니다. 이 스킬은 패턴이 여러 번 쓰이고, 앞으로도 반복될 가능성이 높고, 의미적으로 안정적이며, 중앙에서 유지할 가치가 있을 때 가장 강력합니다. 반대로 일회성 마케팅 레이아웃이 많은 코드베이스라면 효용이 떨어집니다.

어떤 출력이 나오길 기대해야 하나

extract 스킬이 잘 실행되면 보통 다음 중 일부 또는 여러 가지가 나옵니다:

• 컴포넌트 후보 식별
• 토큰 후보 식별
• 통합이 필요한 이유에 대한 근거
• 제안된 대상 API 또는 네이밍 체계
• 마이그레이션 순서

반대로, 공용 자산이 어디에 속해야 하는지 확인도 없이 곧바로 코드 작성으로 들어간다면, 프롬프트에 컨텍스트가 충분히 들어가지 않았다는 신호입니다.

extract 활용도를 높이는 실전 팁

더 좋은 결과를 얻으려면:

• “3회 이상 사용될 때만 추출”처럼 재사용 기준을 명시하세요
• 정식 대상 폴더를 분명히 적으세요
• 현재 공개 API를 유지해야 하는지 밝혀 두세요
• 수정 전에 먼저 계획을 요청하세요
• 코드베이스가 지저분하다면 토큰 추출과 컴포넌트 추출을 분리하세요

이런 조건은 추출 계획의 품질을 실제로 크게 바꿉니다.

extract 스킬의 흔한 오용

다음 용도로는 extract를 피하는 편이 좋습니다:

• 반복되는 원본 패턴 없이 완전히 새 컴포넌트를 발명하는 작업
• 폭넓은 비주얼 리디자인
• 이해관계자 가이드 없이 처음부터 디자인 시스템 전체 아키텍처를 세우는 작업
• 공용 추상화가 전혀 필요 없는 아주 작은 단일 파일 정리

이런 경우에는 일반 구현 프롬프트가 extract 스킬보다 더 빠를 수 있습니다.

extract 스킬 FAQ

extract가 일반 프롬프트보다 낫나요?

디자인 시스템 작업이라면 대체로 그렇습니다. 일반 프롬프트는 너무 빨리 과도한 추상화로 가거나, 기존 시스템 구조를 놓치기 쉽습니다. 실제 과제가 “무엇을 중앙화해야 하는지 발견하고, 이미 있는 UI 시스템으로 어떻게 옮길지 정하는 것”이라면 extract 스킬이 더 적합합니다.

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

보통 수준입니다. 워크플로 자체는 명확하지만, 디자인 시스템 위치, 토큰 파일, 네이밍 규칙을 스스로 파악하지 못하면 초보자는 어려움을 겪을 수 있습니다. 프론트엔드 아키텍처 경험이 많지 않다면, 경로를 명시해 주고 변경 전에 트레이드오프를 설명해 달라고 요청하는 것이 좋습니다.

기존 디자인 시스템이 꼭 필요한가요?

반드시 그렇지는 않습니다. 다만 extract 스킬은 기존 시스템이 있을 수 있다는 전제를 분명히 두고, 새 시스템을 만들기 전에 먼저 이를 확인하도록 안내합니다. 저장소에 공용 UI 레이어가 없다면, extract는 자율적인 아키텍처 결정 도구라기보다 발견과 계획 수립 중심으로 사용하는 편이 맞습니다.

extract가 가장 잘 다루는 패턴은 무엇인가요?

반복되는 컴포넌트, 하드코딩된 디자인 값, 같은 UI 개념의 일관성 없는 구현, 재사용 가능한 조합 패턴을 잘 다룹니다. 반대로 재사용 가능한 UI 구조와 연결되지 않은 비즈니스 로직 리팩터링에는 매력이 덜합니다.

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

중복 코드가 겉보기만 비슷할 뿐 실질적으로 다르거나, 재사용하려다 오히려 API가 더 나빠지거나, 패턴이 너무 불안정해서 중앙화하기 어려운 경우에는 extract를 건너뛰는 편이 낫습니다. 추출에는 유지보수 비용이 따르므로, 재사용성이 오래 유지될 곳에서 가장 큰 가치를 냅니다.

extract는 컴포넌트에만 쓰는 건가요?

아닙니다. 원본 가이드는 컴포넌트뿐 아니라 디자인 토큰과 재사용 가능한 패턴도 명시적으로 포함합니다. 그래서 단순히 JSX 중복만 찾는 프롬프트보다, 디자인 시스템을 위한 extract가 더 실용적입니다.

extract 스킬을 더 잘 쓰는 방법

extract에 더 강한 아키텍처 컨텍스트 제공하기

extract 출력 품질을 가장 빨리 높이는 방법은 다음 정보를 제공하는 것입니다:

• 컴포넌트 라이브러리 경로
• 토큰/테마 경로
• 프레임워크와 스타일링 스택
• 유지해야 할 네이밍 규칙
• 마이그레이션 제약사항

이런 맥락이 없더라도 스킬이 중복 자체는 감지할 수 있지만, 결과를 현재 시스템에 깔끔하게 안착시키기는 어렵습니다.

구현 전에 먼저 발견 단계를 요청하기

더 높은 품질의 결과를 원한다면, 모델에 extract를 두 단계로 사용하라고 명확히 지시하세요:

1. 발견 및 추천
2. 승인 후 구현

이렇게 하면 가장 흔한 실패, 즉 잘못된 추상화로 너무 빨리 추출해 버리는 문제를 줄일 수 있습니다.

재사용 기준을 명시적으로 정하기

가장 효과적인 개선 중 하나는 다음과 같은 규칙을 추가하는 것입니다:

• “Only extract patterns used in 3 or more places”
• “Only create tokens for values repeated across features”
• “Do not centralize one-off layout wrappers”

이런 기준이 있어야 extract가 단순한 DRY 원칙이 아니라, 유지보수성 중심으로 판단하게 됩니다.

컴포넌트 추출과 토큰 추출을 분리하기

둘은 관련은 있지만 같은 작업은 아닙니다. 코드베이스가 복잡한데 extract에 둘 다 한 번에 시키면 결과가 뒤섞이기 쉽습니다. 더 좋은 프롬프트는 이렇게 나눕니다:

• 먼저 공용 컴포넌트를 식별하고
• 다음으로 토큰 후보를 찾고
• 마지막으로 마이그레이션을 계획한다

이 방식이 대체로 더 깔끔한 출력과 더 적은 churn으로 이어집니다.

과하게 일반화된 API를 경계하기

extract 사용에서 흔한 실패는, 여러 개의 얼추 비슷한 구현을 하나로 묶겠다고 props가 지나치게 많은 공용 컴포넌트를 만드는 것입니다. 제안된 API가 중복된 원본 코드보다 더 복잡해 보인다면, 범위를 좁히거나 변형들을 분리해 달라고 요청하세요.

첫 번째 결과 이후 마이그레이션 품질 높이기

첫 결과를 받은 뒤에는 다음과 같은 후속 질문이 좋습니다:

• “Which consumers should migrate first?”
• “What breaks if we replace the old implementations?”
• “Which props or styles should stay local?”
• “Can you propose a compatibility layer?”

바로 이 지점에서 extract는 단순 패턴 탐지기를 넘어, 도입 리스크까지 함께 다루는 도구가 됩니다.

extract를 구체적인 대상 폴더와 함께 사용하기

“앱 전체를 스캔해”라고 하지 말고, 다음처럼 말하세요:

• “Use extract on src/features/checkout against src/components”
• “Review apps/web/src/account for token extraction into packages/ui/tokens”

범위를 구체적으로 잡으면 신호 대 잡음비가 좋아지고, 분석 비용도 줄며, 최종 extract 계획도 훨씬 실행 가능해집니다.

추출이 실제로 도움이 되는지 검증하기

어떤 extract 워크플로에서든 가장 좋은 개선은, 제안된 각 추상화에 대해 근거를 설명하게 하는 것입니다:

• 어떤 중복을 줄이는지
• 얼마나 자주 등장하는지
• 왜 공용 API가 안정적인지
• 왜 로컬 코드로 두는 편이 더 나쁜지

이 단순한 점검만으로도 그럴듯하지만 실익이 낮은 추출을 많이 걸러낼 수 있습니다.