distill

distill 스킬 개요

distill가 하는 일

distill 스킬은 화면을 본질적인 역할만 남기도록 덜어내는 데 초점을 둔 UI 디자인 단순화 워크플로입니다. 인터페이스가 복잡하고, 산만하고, 장식이 과하거나, 선택지가 지나치게 많다고 느껴질 때 유용합니다. 기능을 더 얹기보다 더 깔끔하고 더 강한 방향으로 정리하고 싶을 때 쓰는 스킬입니다.

UI 디자인용 distill가 특히 잘 맞는 경우

이미 화면, 플로우, 컴포넌트가 존재하고 그것을 더 차분하고 더 명확하게 다듬어야 한다면 UI 디자인용 distill가 잘 맞습니다. 다음과 같은 작업을 하는 디자이너, 프론트엔드 엔지니어, 프로덕트 팀, AI 에이전트에 적합합니다.

• 대시보드, 폼, 설정 화면, 상세 페이지의 군더더기 제거
• 서로 경쟁하는 액션 축소
• 시각적 위계 단순화
• 장식성 노이즈 제거
• “기능이 많아 보이는” 레이아웃을 과업 우선 레이아웃으로 전환

실제로 해결하는 핵심 문제

사용자가 distill 스킬을 설치하는 이유는 단순히 “더 심플한 디자인”을 얻기 위해서가 아닙니다. 실제로는 더 어려운 질문에 답하려고 설치합니다.

• 무엇을 남겨야 하는가?
• 무엇을 제거해야 하는가?
• 무엇을 숨기고, 합치고, 뒤로 미뤄야 하는가?
• 이 화면에서 사용자의 단 하나의 핵심 목표는 무엇인가?

이 점 때문에 distill는 단순한 “이거 좀 더 깔끔하게 만들어줘” 프롬프트보다 더 유용합니다. 재설계 전에 우선순위 정리를 강제한다는 데 가치가 있습니다.

핵심 차별점

가장 큰 차별점은 distill가 독립형 스타일 프롬프트가 아니라는 점입니다. 이 스킬은 상위 디자인 맥락을 명시적으로 전제로 합니다.

• 먼저 /frontend-design 실행
• 아직 디자인 맥락이 없다면 먼저 /teach-impeccable 실행
• 핵심 목표나 제약이 불명확하면 멈추고 уточ 질문하기

이 의존성은 도입 여부를 판단할 때 중요합니다. distill는 단발성 프롬프트로 따로 쓰는 것보다, 더 넓은 impeccable 디자인 시스템 안에서 훨씬 강하게 작동합니다.

설치 전에 알아둘 점

이 스킬은 메인 파일이 SKILL.md 하나인 가벼운 구성이고, 함께 제공되는 스크립트, 예제, 레퍼런스 에셋은 없습니다. 그래서 빠르게 살펴보긴 쉽지만, 결과물 품질은 사용자가 제공하는 맥락에 크게 좌우됩니다. 자체 완결형이고 가이드가 촘촘한 distill 가이드를 기대한다면, 이 저장소 경로는 도구 중심이라기보다 원칙 중심에 가깝습니다.

distill 스킬 사용 방법

distill 설치 맥락

상위 SKILL.md에는 설치 명령이 따로 없으므로, 저장소를 기준으로 평소 사용하는 Claude Skills 설치 흐름을 따르면 되고 pbakaus/impeccable 안의 distill 스킬을 대상으로 지정하면 됩니다. 저장소에서 직접 설치한다면 관련 경로는 다음과 같습니다.

https://github.com/pbakaus/impeccable/tree/main/.claude/skills/distill

이 스킬은 사용자가 직접 호출할 수 있고 인자 힌트가 [target] 형태이므로, 실제 사용 패턴은 제품 전체를 막연히 요청하는 방식보다 특정 화면, 플로우, 컴포넌트에 대해 distill를 호출하는 쪽이 맞습니다.

먼저 읽어야 할 파일

다음 파일부터 보세요.

• SKILL.md

이 스킬 폴더에는 함께 보는 README.md, metadata.json, rules/, references/ 파일이 없습니다. 즉, 유의미한 동작 대부분이 이 단일 파일에 정의되어 있습니다. 설치 검토 관점에서는 오히려 장점입니다. distill 스킬 전체를 빠르게 판단할 수 있기 때문입니다.

많은 사용자가 놓치는 필수 의존성

distill를 사용하기 전에, 스킬 설명은 /frontend-design을 먼저 호출하라고 안내합니다. 이 상위 단계에는 디자인 원칙, 안티패턴, 그리고 “Context Gathering Protocol”이 들어 있습니다. 아직 디자인 맥락이 없다면 /teach-impeccable을 먼저 실행해야 합니다.

이 부분은 중요합니다. 약한 결과는 대개 이 준비 단계를 건너뛰었을 때 나옵니다. 스크린샷 하나나 막연한 불만만 던진 채 distill를 바로 호출하면, 모델이 잘못된 요소를 제거할 수 있습니다.

distill에 필요한 입력

좋은 distill 사용의 출발점은 구체적인 대상과, UI의 핵심 역할을 식별할 수 있을 만큼의 맥락입니다. 다음 같은 입력이 좋습니다.

• 정확히 어떤 화면 또는 컴포넌트인지
• 사용자의 핵심 과업이 무엇인지
• 액션 과다, 위계 약함 같은 현재 문제
• 컴플라이언스, 반드시 유지해야 하는 컨트롤, 엔지니어링 한계 같은 강한 제약
• 단순화 시 제거할지, 합칠지, 숨길지, 점진적으로 드러낼지에 대한 방향

약한 입력 예:

• “이 페이지를 단순하게 해줘.”

더 강한 입력 예:

• “Use distill on our analytics dashboard. The primary user goal is to spot traffic changes in under 10 seconds. Keep the date range picker and export action. We can remove secondary filters from the default view if needed. Current issues: too many cards, repeated metrics, heavy borders, and three competing CTAs.”

막연한 목표를 완성도 있는 프롬프트로 바꾸는 법

실무적으로 쓸 수 있는 distill 가이드 프롬프트 구조는 다음과 같습니다.

1. 대상을 명시한다.
2. 단 하나의 핵심 사용자 목표를 적는다.
3. 반드시 유지해야 할 요소를 나열한다.
4. 제거 또는 숨김 후보를 나열한다.
5. 무엇이 복잡하게 느껴지는지 짚는다.
6. 최종 재설계 전에 먼저 단순화 계획을 요청한다.

예시:

“Apply distill to the onboarding modal for first-time team admins. The one goal is helping them invite teammates. Must keep: email entry, role selector, skip option. Nice-to-have elements that can be deferred: tips carousel, template preview, feature badges. The current design feels crowded because it mixes setup, education, and marketing. First identify complexity sources, then propose what to remove, combine, or hide.”

권장 워크플로

신호 대비 잡음이 적은 distill 사용 워크플로는 다음과 같습니다.

1. /frontend-design으로 맥락을 수집한다.
2. 핵심 사용자 목표가 하나인지 확인한다.
3. 제품 전체가 아니라 하나의 화면에 대해 distill를 실행한다.
4. 제거, 통합, 숨김 제안을 검토한다.
5. “제거” 대상으로 나온 요소 중 정책, 지원, 비즈니스 로직상 실제로 필수인 것이 없는지 확인한다.
6. 더 날카로운 제약을 넣어 반복한다.
7. 그다음에야 시각적 디테일 보정이나 구현 단계로 넘어간다.

이 순서가 중요한 이유는 distill가 최종 마감용 폴리싱 도구라기보다 우선순위 정리 도구에 가깝기 때문입니다.

distill가 주로 분석하는 대상

스킬 설명을 보면 distill는 다음을 중점적으로 봅니다.

• 요소가 지나치게 많은 상태
• 과도한 시각적 변주
• 정보 과부하
• 시각적 노이즈
• 혼란스러운 위계
• 기능 비대화

또한 “가치의 80%를 만드는 20%”를 식별하도록 명시적으로 유도합니다. 팀이 범위를 줄이는 데 늘 어려움을 겪는다면, 이 프레이밍 자체가 이 스킬을 써볼 만한 강한 이유입니다.

밀어붙이지 말고 멈춰서 명확히 해야 하는 시점

원문 가이드는 코드베이스나 프롬프트만으로 다음이 분명하지 않다면 멈추고 질문하라고 말합니다.

• 핵심 사용자 목표
• 필수와 있으면 좋은 것의 구분
• 제거, 숨김, 통합 가능한 대상

이건 의미 있는 경계선입니다. 팀이 화면의 핵심 과업에 합의하지 못한 상태라면, distill는 그 제품적 모호함을 드러낼 수는 있어도 마법처럼 해결해주지는 못합니다.

distill를 처음 쓸 때 가장 적합한 대상

처음 시도하기 좋은 대상:

• 복잡한 설정 페이지
• 카드가 너무 많은 대시보드
• 선택 필드가 한꺼번에 너무 많이 보이는 폼
• 여러 역할을 동시에 수행하는 모달
• 여러 CTA가 서로 경쟁하는 랜딩 섹션

처음부터 피하는 편이 좋은 대상:

• 제거 제약이 매우 강한 고규제 워크플로
• 구체적인 화면 없이 진행하는 디자인 시스템 작업
• 이미 충분히 미니멀하지만 상호작용 문제가 핵심인 화면

출력에서 기대할 수 있는 것

distill 스킬이 가장 유용한 결과를 내는 경우는 보통 다음과 같습니다.

• 복잡성의 원인 진단
• 더 선명한 콘텐츠 및 액션 위계
• 제거, 통합, 점진적 공개에 대한 제안
• 더 집중된 사용자 경로

반대로, 이 스킬 하나만으로 코드 변환, 자동 감사, 구현 가능한 수준의 컴포넌트 diff까지 기대하긴 어렵습니다.

distill 스킬 FAQ

distill는 일반적인 단순화 프롬프트보다 더 나은가

대체로 그렇습니다. 막연한 정리보다 구조화된 단순화가 필요할 때 특히 그렇습니다. 이 스킬은 복잡성의 원인을 찾는 반복 가능한 관점을 제공하고, 핵심 목표를 하나로 강제합니다. 일반 프롬프트도 “더 깔끔하게 해줘”라고 말할 수는 있지만, distill는 실제로 무엇이 사라져야 하는지를 더 집요하게 묻습니다.

distill는 초보자도 쓰기 쉬운가

네. 다만 단서가 있습니다. 문구 자체는 이해하기 쉽고, 저장소도 사실상 파일 하나라 살펴보기 쉽습니다. 더 어려운 부분은 설치가 아니라, 이 스킬을 제대로 쓸 만큼 충분한 UI 맥락을 갖추는 일입니다. 초보자라면 화면 하나와 명시적인 제약부터 시작하는 것이 좋습니다.

impeccable 저장소의 나머지 부분도 꼭 필요한가

distill 설치를 시도하기 전에 저장소 전체를 다 읽을 필요는 없습니다. 하지만 문서에 적힌 /frontend-design 의존성은 반드시 존중해야 하고, 필요하다면 /teach-impeccable도 따라야 합니다. 이 스킬은 그 생태계 안에서 작동하도록 설계되었지, 그것을 완전히 대체하도록 만들어진 것은 아닙니다.

언제 distill를 쓰지 말아야 하나

주요 문제가 다음과 같다면 distill는 건너뛰는 편이 낫습니다.

• 복잡함보다 상호작용 로직 파손이 문제일 때
• 사용자 리서치가 부족할 때
• 여러 화면에 걸친 제품 전략이 불명확할 때
• 제거가 아니라 추가 조치가 필요한 접근성 또는 컴플라이언스 이슈일 때

이런 경우에는 단순화만으로 접근하면 오히려 방향을 잘못 잡을 수 있습니다.

distill는 UI 이외의 작업에도 통하나

저장소 근거만 보면 UI와 프론트엔드 디자인 용도에 가깝습니다. 표현 방식, /frontend-design 의존성, 분석 범주 모두 인터페이스 단순화에 초점이 맞춰져 있습니다. 카피, 시스템, 아키텍처를 단순화하고 싶다면 보장된 적합성보다는 참고용 발상으로 받아들이는 편이 맞습니다.

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

distill에는 화면 하나와 목표 하나만 주기

distill 결과를 가장 빠르게 개선하는 방법은 범위를 좁히는 것입니다. “우리 앱을 단순화해줘”는 너무 넓습니다. “결제 설정 페이지를 distill해서 사용자가 더 빨리 결제 수단을 변경할 수 있게 해줘” 정도는 실행 가능합니다. 이 스킬은 대상에 지배적인 과업이 하나 있을 때 가장 잘 작동합니다.

반드시 유지할 요소와 조정 가능한 요소를 분리하기

좋은 프롬프트는 다음을 구분해야 합니다.

• 반드시 필요한 콘텐츠 또는 액션
• 숨기거나 제거해도 되는 선택 요소
• 가장 먼저 덜어낼 수 있는 장식 요소

이 구분이 없으면 distill가 정치적으로나 기능적으로 절대 건드릴 수 없는 항목을 잘라내라고 제안할 수 있고, 그러면 리뷰 사이클만 낭비하게 됩니다.

어떤 방식의 단순화를 원하는지 distill에 알려주기

모든 단순화가 제거를 의미하는 것은 아닙니다. 다음 중 어떤 레버를 선호하는지 명시하면 결과가 더 좋아집니다.

• 제거
• 통합
• 점진적 공개 뒤로 숨기기
• 시각적 강조 낮추기
• 한 번에 다 보여주지 말고 단계로 나누기

이렇게 해야 distill 사용이 “더 단순하게 해줘”에서 끝나지 않고, 더 날카로운 디자인 작업으로 바뀝니다.

실제 복잡성 증상을 구체적으로 포함하기

화면이 복잡해 보인다고만 하지 말고, 무엇이 복잡한지 말해야 합니다.

• 첫 화면에 버튼이 다섯 개 있음
• 중복된 지표가 있음
• 의미 없이 텍스트 스타일이 세 종류임
• 카드에 그림자, 테두리, 틴트 배경이 동시에 들어감
• 핵심 완료 전에 보조 설정이 먼저 노출됨

이런 구체적 증상은 모델이 스킬이 정의한 복잡성 범주와 더 정확하게 연결되도록 도와줍니다.

가장 흔한 실패 패턴을 경계하기

UI 디자인용 distill의 가장 큰 실패 패턴은 잘못된 대상을 과도하게 단순화하는 것입니다. 화면은 더 깔끔해졌는데, 중요한 맥락이나 신뢰 신호, 예외 상황용 제어가 사라져 오히려 사용성이 떨어질 수 있습니다. 첫 번째 결과를 받은 뒤에는, 제거 제안 하나하나를 실제 사용자 과업 기준으로 반드시 검토해야 합니다.

단계별 응답을 요청하기

더 강한 프롬프트는 출력을 단계로 나누어 요청합니다.

1. 복잡성 원인 식별
2. 본질적 과업 정의
3. 제거, 통합, 숨김 항목 나열
4. 단순화된 구조 제안

이 단계적 접근은 즉시 재설계를 요구하는 방식보다 distill 가이드를 더 감사 가능하게 만들고, 수정도 더 쉽게 해줍니다.

첫 번째 결과 뒤에는 제약을 추가해 반복하기

첫 결과가 너무 과격하거나 너무 소극적이라면, 구체적인 제약을 추가해 다듬으세요.

• “Keep all legal disclosures visible.”
• “Do not add more steps.”
• “We can hide advanced filters behind an accordion.”
• “The primary CTA must remain above the fold.”

이 방식이 전체 브리프를 다시 쓰지 않고도 distill 스킬 결과를 개선하는 가장 실용적인 방법입니다.

distill 결과는 구현 검토와 함께 보기

distill가 무엇을 줄이거나 약화할지 식별한 뒤에는, 평소의 프론트엔드 및 프로덕트 리뷰 절차로 이어가세요. 이 스킬은 의사결정의 틀을 잡아주는 데 특히 강합니다. 하지만 실제 출시 전에는 여전히 팀이 상태 처리, 접근성, 콘텐츠 명확성, 엣지 케이스를 검증해야 합니다.