distill

distill 스킬 개요

distill가 하는 일

distill 스킬은 디자인을 본질적인 역할만 남기도록 덜어내는 UI 단순화 워크플로입니다. 인터페이스가 복잡하고, 시끄럽고, 장식이 과하고, 기능이 과도하게 늘어났거나, 한눈에 파악하기 어려울 때 쓰기 좋습니다. 더 많은 UI를 덧붙이는 대신, distill는 반대로 접근합니다. 메인 사용자 목표가 분명해질 때까지 제거하고, 합치고, 숨기고, 명확하게 다듬습니다.

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

이미 화면, 컴포넌트, 또는 플로우가 있고, 기능은 유지하면서 더 깔끔하게 정리하고 싶다면 distill for UI Design이 잘 맞습니다. 특히 다음 문제를 다루는 디자이너, 프론트엔드 엔지니어, 프로덕트 빌더에게 적합합니다.

• 복잡하게 얽힌 대시보드
• 선택지가 너무 많은 폼
• 서로 경쟁하는 CTA
• 약한 시각적 위계
• 과도한 색상, 스타일, 표면 처리
• 핵심 작업을 가리는 기능 비대화

실제로 해결하는 핵심 과제

distill 스킬의 실무적 목적은 “더 예쁘게 만들기”가 아닙니다. UI의 단 하나의 핵심 목표를 찾아내고, 그 목표를 흐리는 요소를 줄여 나가는 데 있습니다. 실제로는 무엇을 완전히 제거할지, 무엇을 점진적 공개 뒤로 숨길지, 무엇을 합칠지, 무엇을 더 강조할지를 결정하는 과정입니다.

일반적인 프롬프트와 distill가 다른 점

그냥 “이 UI를 단순하게 해줘”라고 하면 대개 두루뭉술한 조언만 나오기 쉽습니다. distill가 더 실용적인 이유는 단순화를 의도적인 감사(audit) 과정으로 다루기 때문입니다.

1. 복잡성이 어디서 생기는지 평가한다
2. 핵심 작업을 찾는다
3. 불필요한 요소와 변형을 제거한다
4. 유용성은 유지하면서 명확성은 높인다

즉흥적인 프롬프트에 의존하지 않고 설치할 만한 이유는 바로 이 구조에 있습니다.

도입 전에 꼭 알아둘 제약

가장 큰 제약은 distill가 독립형이 아니라는 점입니다. 스킬 지침 자체에서 먼저 /frontend-design을 호출해야 하며, 아직 디자인 컨텍스트가 없다면 진행 전에 /teach-impeccable도 실행하라고 요구합니다. 단독으로 바로 꽂아 넣어 쓸 수 있는 스킬을 원한다면, 이 의존 체인이 가장 큰 도입 장벽입니다.

distill 스킬 사용 방법

distill 설치 맥락

이 스킬은 pbakaus/impeccable 저장소의 .agents/skills/distill에 들어 있습니다. 일반적인 설치 방식은 다음과 같습니다.

npx skills add pbakaus/impeccable --skill distill

현재 저장소 발췌본에는 SKILL.md만 공개되어 있으므로, 실제 사용 기준 문서는 이 파일이라고 보는 것이 맞습니다. 또한 같은 저장소 안의 보조 스킬에 의존할 가능성을 전제로 두는 편이 좋습니다.

먼저 읽어야 할 파일

먼저 확인할 파일:

• SKILL.md

distill 사용법을 파악할 때는 README보다 이 파일이 더 중요합니다. 실제 호출 계약, 워크플로, 선행 단계가 여기에 들어 있기 때문입니다.

필수 의존성 순서를 지켜야 합니다

distill를 쓰기 전에 아래 순서를 따르세요.

1. /frontend-design 호출
2. 해당 스킬의 컨텍스트 수집 절차 진행
3. 아직 디자인 컨텍스트가 없다면 /teach-impeccable 실행
4. 그다음에야 distill 실행

이건 있으면 좋은 권장사항이 아닙니다. 스킬이 명시적으로 선행 디자인 컨텍스트에 의존하므로, 이 단계를 건너뛰면 피상적이거나 임의적인 단순화로 흐를 가능성이 커집니다.

distill에 필요한 입력

distill 스킬은 구체적인 대상과, 무엇이 본질인지 판단할 수 있을 만큼의 컨텍스트가 함께 주어질 때 가장 잘 작동합니다. 좋은 입력에는 보통 다음이 포함됩니다.

• 구체적인 화면, 컴포넌트, 또는 플로우
• 핵심 사용자 작업
• 복잡함, 과도한 액션 수, 약한 위계, 시각적 노이즈 같은 현재의 문제점
• 필수 필드, 법적 문구, 플랫폼 제약, 기존 디자인 시스템 규칙 같은 제약 조건

최소한의 대상 예시:

• distill checkout sidebar
• distill onboarding modal
• distill analytics dashboard header

막연한 목표를 강한 distill 프롬프트로 바꾸는 법

약한 프롬프트:

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

더 나은 distill 가이드 스타일 프롬프트:

• “Use distill on the settings screen. The main goal is helping users change notification preferences quickly. Current issues: too many card sections, repeated labels, three competing save actions, and decorative borders everywhere. Keep required compliance copy and email/SMS toggles. Recommend what to remove, combine, hide, or restyle.”

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

• 핵심 목표를 하나로 명확히 지정한다
• 복잡성의 원인을 드러낸다
• 제거할 수 없는 요소를 표시한다
• 일반적인 비평이 아니라 실행 가능한 단순화 결정을 요청한다

distill가 실제로 찾는 것

소스 기준으로 distill는 다음 항목을 적극적으로 점검합니다.

• 요소가 너무 많은지
• 스타일 변형이 과도한지
• 정보 과부하가 있는지
• 시각적 노이즈가 많은지
• 위계가 혼란스러운지
• 기능 비대화가 일어났는지

이 중 어떤 문제가 해당하는지 이미 알고 있다면 명시하는 것이 좋습니다. 제한된 컨텍스트만으로 전부 추론할 필요가 없을수록 스킬이 더 단호한 결론을 내립니다.

실무에서 쓰기 좋은 distill 워크플로

현실적인 워크플로는 보통 다음과 같습니다.

1. /frontend-design으로 화면 컨텍스트를 수집한다
2. 핵심 사용자 목표를 한 가지로 정리한다
3. 구체적인 대상을 지정해 distill를 실행한다
4. 제거 및 통합 제안을 검토한다
5. 수정된 레이아웃 근거나 구현 계획을 추가로 요청한다
6. 단순화된 버전이 필수적인 예외 케이스까지 여전히 지원하는지 검증한다

이 과정이 중요한 이유는, 단순화는 과하게 하기 쉽기 때문입니다. distill는 보통 한 번은 노이즈를 덜어내는 데 쓰고, 한 번은 핵심 작업이 여전히 살아 있는지 검증하는 데 쓰는 방식이 가장 효과적입니다.

기대할 수 있는 출력

대체로 다음과 같은 추천을 기대할 수 있습니다.

• 무엇을 완전히 제거할지
• 무엇을 점진적 공개 뒤로 숨길지
• 무엇을 하나의 컨트롤이나 섹션으로 합칠지
• 어떤 시각적 처리를 줄일지
• 메인 액션 중심의 위계를 어떻게 강화할지

다만 후속 질문 없이 스킬만으로 픽셀 단위 구현 디테일까지 기대하진 않는 편이 좋습니다.

결과 품질을 바꾸는 실전 팁

더 나은 distill 사용법을 위해서는:

• 제품 전체가 아니라 한 번에 한 화면씩 다룬다
• 핵심 작업을 한 문장으로 적는다
• 필수 요소와 선택 요소를 구분한다
• 반드시 눈에 보여야 하는 비즈니스 핵심 액션을 명시한다
• 가능하면 스크린샷, 컴포넌트 목록, 코드 구조를 함께 제공한다

이 스킬의 핵심 로직은 “핵심 목표를 해치지 않으면서 무엇을 제거할 수 있는가”이므로, 필수 요소가 불명확하면 추천 품질이 가장 빠르게 떨어집니다.

distill가 특히 강력한 상황

distill 스킬은 이미 작동은 하지만 답답하고 빽빽하게 느껴지는 UI에서 특히 강합니다. 예를 들면 다음과 같습니다.

• 수년간 컨트롤이 누적된 내부 도구
• 너무 많은 데이터가 노출되는 엔터프라이즈 화면
• 밀도가 높아 가독성과 훑어보기가 무너지는 모바일 뷰
• 제품 범위는 고정돼 있지만 명확성이 떨어지는 리디자인 단계

distill 스킬 FAQ

distill는 입문자에게도 괜찮을까?

네. 이미 단순화할 구체적인 대상이 있다면 충분히 유용합니다. 열린 형태의 디자인 비평보다 더 명확한 단순화 관점을 제공해 줍니다. 다만 입문자가 가장 많이 막히는 지점은 선행 워크플로입니다. distill를 한 줄짜리 마법 명령처럼 쓰기보다는, 저장소가 요구하는 디자인 컨텍스트 설정 절차를 따라야 합니다.

distill는 시각적 정리용인가?

아니요. distill 스킬은 구조적 복잡성도 함께 다룹니다. 예를 들어 액션이 너무 많거나, 정보가 한 번에 너무 많이 보이거나, 우선순위가 불분명하거나, 기능이 과하게 늘어난 경우까지 포함합니다. 표면 스타일링만이 아니라 상호작용과 위계까지 보는 스킬입니다.

언제 distill를 쓰지 말아야 할까?

핵심 문제가 기능 부족, 요구사항 불명확, 또는 작업 흐름 정의 자체의 부실함에 있다면 distill는 맞지 않습니다. 실제 사용자 목표를 모른 채 UI만 단순화하면 잘못된 요소를 제거할 수 있습니다. 또한 축소보다 폭넓은 아이데이션이 필요한 상황에도 적합하지 않습니다.

distill vs 일반 프롬프트

그냥 “더 깔끔하게 만들어줘”라는 프롬프트보다 distill가 유리한 이유는 판단 모델이 더 좁고 명확하기 때문입니다. 무엇이 꼭 필요한지, 무엇이 있으면 좋지만 필수는 아닌지, 무엇을 제거·숨김·통합할 수 있는지를 분명하게 묻습니다. 그래서 자유로운 시각 탐색보다는, 군더더기 제거와 구조 정리에 더 적합합니다.

distill는 impeccable 없이도 작동할까?

깔끔하게는 어렵습니다. 소스 기준으로 distill는 먼저 /frontend-design이, 경우에 따라 /teach-impeccable이 실행되어 있기를 기대합니다. 환경상 이런 보조 스킬을 호출할 수 없다면 워크플로를 수동으로 흉내 낼 수는 있지만, 의도된 컨텍스트 설정의 이점은 줄어듭니다.

distill는 코드 중심 팀에도 맞을까?

네. 특히 프론트엔드 비중이 큰 팀이라면 distill 설치를 검토할 만합니다. 실제로 무엇이 필요한지는 코드와 제품 로직을 이해해야 판단되는 경우가 많기 때문입니다. 배포된 UI에 컨트롤 수, 상태 수, 시각 처리 수가 과도하게 늘어난 디자인 부채가 드러날 때 특히 도움이 됩니다.

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

distill에 핵심 목표를 하나만 주기

가장 큰 개선 포인트는 대상 UI의 메인 작업을 하나로 못 박는 것입니다. 소스에서도 핵심 사용자 목표는 ONE이어야 한다고 강조합니다. 목표를 여러 개를 동등하게 두면, distill 스킬은 무엇을 우선 줄여야 할지 결정을 내리기 어려워지고 결국 모든 것이 필수처럼 보이게 됩니다.

제거 가능 요소, 반드시 유지할 요소, 미정 요소를 구분하기

좋은 distill 프롬프트는 다음을 분리해서 제시합니다.

• 반드시 유지해야 하는 것
• 안전하게 제거 가능한 것
• 불확실하거나 협의 가능한 것

이렇게 해야 두 가지 흔한 실패를 막을 수 있습니다. 아무것도 제거하지 못하는 소극적인 결과, 혹은 필요한 요소까지 잘라내는 과감한 결과입니다.

복잡성의 실제 원인을 정확히 말하기

그저 “복잡해 보여요”라고만 하지 마세요. distill에 복잡함의 원인이 무엇인지 알려주는 편이 좋습니다.

• 버튼이 너무 많은지
• 정보가 반복되는지
• 시각 스타일이 너무 많은지
• 불필요한 테두리나 그림자가 많은지
• 그룹핑이 나쁜지
• 한 번에 보이는 선택지가 너무 많은지

스킬이 원래도 이런 범주로 사고하기 때문에, 이렇게 말해주면 추천의 정밀도가 올라갑니다.

일반적인 비평이 아니라 제거 결정을 요청하기

더 좋은 프롬프트 예시:

• “Use distill and list what should be removed, combined, hidden, or visually softened.”

더 약한 프롬프트 예시:

• “Thoughts on this design?”

첫 번째는 실제로 구현 가능한 결과를 만들어 줍니다. 반면 두 번째는 넓고 모호한 코멘트를 유도해 distill 가이드 워크플로의 가치가 떨어집니다.

한 번은 단순화, 한 번은 검증에 쓰기

첫 번째 패스 이후에는 다음을 물어보세요.

• 이 단순화가 어떤 사용성 리스크를 만드는지
• 어떤 예외 케이스가 너무 깊숙이 숨겨졌는지
• 메인 CTA가 더 명확해졌는지
• 중요한 보조 액션이 여전히 발견 가능한지

이 두 번째 패스가 distill 사용법을 더 좋게 만드는 이유는, 단순화의 품질이 단지 줄였느냐가 아니라 필요한 기능을 제대로 남겼느냐에 달려 있기 때문입니다.

설명만 하지 말고 실제 산출물을 제공하기

가능하다면 다음 자료를 함께 주세요.

• 스크린샷
• 와이어프레임
• 컴포넌트 인벤토리
• 현재 정보 위계
• 조건부 UI와 관련된 코드 스니펫

대상이 구체적일수록 distill는 무엇이 장식적인지, 중복인지, 구조적으로 불필요한지 더 자신 있게 판단할 수 있습니다.

흔한 실패 패턴을 주의하기

결과가 약해지는 전형적인 경우는 다음과 같습니다.

• 화면의 핵심 목적이 불분명할 때
• 모든 이해관계자의 요청을 똑같이 중요하게 다룰 때
• 필수 제약이 빠져 있을 때
• 제품 전체를 한 번에 단순화해 달라고 할 때
• /frontend-design의 컨텍스트 수집을 건너뛰었을 때

distill 결과가 지나치게 일반적으로 느껴진다면, 대개 원인은 스킬 자체보다 입력이 지나치게 덜 구체적이기 때문입니다.

distill에 트레이드오프 설명도 요구하기

출력에 대한 신뢰를 높이는 가장 좋은 방법 중 하나는 다음을 함께 묻는 것입니다.

• 각 제거로 어떤 사용자 이점이 생기는지
• 기능을 숨겼을 때 어떤 발견 가능성 비용이 따르는지
• 분리된 컨트롤보다 통합된 컨트롤이 왜 더 나은지

이렇게 하면 distill 스킬은 단순한 정리 도구를 넘어, 팀 내 도입 가치가 더 큰 의사결정 지원 도구로 바뀝니다.

distill 이후 구현 후속 작업과 연결하기

distill가 단순화 방향을 잡아준 뒤에는 다음을 요청하는 두 번째 단계로 이어가세요.

• 수정된 레이아웃 구조
• 디자인 시스템에 맞는 컴포넌트 선택
• 프론트엔드 구현 메모
• 단순화된 화면의 acceptance criteria

실무에서는 바로 이 연결 지점에서 스킬이 “개념상 맞는 조언”을 넘어서 “실제로 쓸 수 있는 결과물”이 됩니다.