polish

polish 스킬 개요

polish가 하는 일

polish 스킬은 배포 직전 단계에서 UI를 최종 점검하는 워크플로입니다. 완성된 화면이 어딘가 들쭉날쭉하거나, 마무리가 덜 됐거나, 의도한 것보다 품질이 낮아 보이게 만드는 자잘한 문제를 잡아내는 데 초점이 있습니다. 이미 화면이 기능적으로는 동작하는 상태에서, 출시 전에 정렬, 간격, 인터랙션 상태, 문구 일관성, 엣지 케이스, 시각적 매끄러움까지 한 단계 더 끌어올리고 싶을 때 쓰도록 설계되어 있습니다.

polish를 써야 하는 사람

이 polish 스킬은 이미 동작하는 인터페이스를 갖고 있고, 구조화된 품질 점검이 필요한 디자이너, 프론트엔드 엔지니어, AI 기반 빌더에게 가장 잘 맞습니다. 특히 “마무리 터치를 해줘”, “뭔가 어색해”, “프로덕션 수준으로 다듬어줘”, “괜찮은 수준에서 정말 좋은 수준으로 올려줘” 같은 요청에 가장 유용합니다.

실제로 해결하는 핵심 과제

사용자가 polish를 설치하는 이유는 막연한 디자인 피드백을 받기 위해서가 아닙니다. 놓치기 쉬운 미세한 문제를 배포 전에 빠짐없이 점검하는 체계적인 프리-런치 리뷰를 돌리기 위해서입니다.

• 일관되지 않은 간격
• 그리드에서 어긋난 정렬
• 빠진 hover, focus, loading, error 상태
• 들쭉날쭉한 카피 톤과 라벨링
• 거친 전환 효과와 인터랙션 디테일

이 polish 스킬이 다른 이유

polish의 가장 큰 차별점은 이 스킬이 범용 리디자인 도구가 아니라, 명확하게 마지막 단계용 스킬이라는 점입니다. 또한 상위 디자인 맥락에 의존합니다. 이 repo에서는 polish를 쓰기 전에 먼저 /frontend-design을 호출해야 하고, 아직 디자인 컨텍스트가 없다면 /teach-impeccable을 먼저 실행하라고 안내합니다. 이 의존 관계가 중요한 이유는, polish가 이미 존재하는 디자인 방향성과 품질 기준을 전제로 평가하기 때문입니다.

polish가 특히 잘 맞는 경우

다음과 같은 상황이라면 polish가 잘 맞습니다.

• UI가 기능적으로 거의 완성되어 있다
• 출시 전에 최종 품질 점검이 필요하다
• 핵심 문제는 제품 전략이 아니라 일관성이다
• 특정 화면, 컴포넌트, 플로우를 지정해 줄 수 있다
• 목표 기준이 MVP인지 flagship인지 알고 있다

polish가 맞지 않는 경우

다음 상황에서는 polish를 첫 번째 도구로 쓰지 않는 편이 좋습니다.

• 기능 자체가 아직 정의되는 중이다
• 핵심 플로우가 깨져 있거나 미완성이다
• UX 구조를 크게 다시 짜야 한다
• 아직 디자인 컨텍스트가 없다
• 팀이 어느 정도까지 다듬을지 기준을 정하지 못했다

polish 스킬 사용 방법

스킬 설정에 polish 설치하기

이 repository는 SKILL.md 안에 별도 설치 명령을 노출하지 않으므로, 대부분의 사용자는 skills manager를 통해 소스 repo에서 스킬을 추가하게 됩니다. 흔한 패턴은 다음과 같습니다.

npx skills add pbakaus/impeccable --skill polish

환경마다 다른 설치 방식을 쓴다면, 아래 경로에서 스킬을 추가하면 됩니다.

https://github.com/pbakaus/impeccable/tree/main/.agents/skills/polish

먼저 읽어야 할 파일

가장 먼저 볼 파일은 다음입니다.

• SKILL.md

이 스킬은 자체 완결형입니다. 스킬 폴더 안에 별도의 resources/, rules/, 헬퍼 스크립트가 드러나 있지 않기 때문에, 실제로 활용 가능한 워크플로의 대부분은 이 한 파일에 들어 있습니다.

필수 의존 체인을 지키기

polish를 호출하기 전에, repo 가이드는 먼저 아래를 실행하라고 말합니다.

• /frontend-design

그리고 아직 확립된 디자인 컨텍스트가 없다면, 반드시 아래를 먼저 실행해야 합니다.

• /teach-impeccable

이게 도입 시 가장 중요한 포인트입니다. 이 컨텍스트 없이 polish를 실행하면, 실제 디자인 원칙에 근거한 자신감 있는 마감 점검이 아니라 “간격을 좀 더 일관되게 하세요” 수준의 얕은 조언으로 끝나기 쉽습니다.

polish가 필요로 하는 입력 이해하기

polish 스킬은 다음 정보를 줄 때 가장 잘 작동합니다.

• 정확한 대상: 페이지, 컴포넌트, 또는 플로우
• 현재 스크린샷이나 코드 맥락
• 원하는 품질 기준: MVP 또는 flagship
• 이미 알려진 결함을 지금 고칠지, TODO로 남길지
• polish에 쓸 수 있는 배포 일정이나 시간 예산

이 입력들은 결과를 크게 바꿉니다. 예를 들어 flagship 수준의 마케팅 페이지와 MVP 내부 도구는 전혀 다른 기준으로 점검되어야 합니다.

거친 요청을 실제로 쓸 수 있는 polish 프롬프트로 바꾸기

약한 프롬프트:

Polish this UI.

더 나은 프롬프트:

Use polish on the checkout flow. The flow is functionally complete. Quality bar is flagship. Keep the current structure, do not redesign the information architecture. Focus on alignment, spacing consistency, interaction states, error handling, and copy consistency. We have one day before ship, so prioritize high-visibility issues first.

이 프롬프트가 잘 작동하는 이유는 다음과 같습니다.

• 준비 상태를 확인해 준다
• 범위를 명확히 정한다
• 의도치 않은 리디자인을 막는다
• 현실적인 시간 제약을 알려 준다
• 어디까지 깊게 볼지 스킬에 전달한다

polish는 먼저 좁은 대상에 적용하기

인자 힌트가 [target]인 점도 중요한 단서입니다. 제품 전체 피드백을 요구하기보다, 구체적인 대상을 지정해서 넘기는 편이 좋습니다. 예를 들면:

• polish pricing page
• polish onboarding modal
• polish dashboard table states
• polish mobile settings flow

이처럼 좁은 대상은 “앱 전체를 다듬어줘” 같은 넓은 요청보다 훨씬 실행 가능한 결과를 주는 경우가 많습니다.

의도된 워크플로대로 사용하기

실무에서 쓸 만한 polish 사용 흐름은 다음과 같습니다.

1. UI가 기능적으로 완성되었는지 확인한다.
2. /frontend-design으로 디자인 컨텍스트를 수집한다.
3. 디자인 컨텍스트가 없다면 /teach-impeccable을 실행한다.
4. 품질 기준과 시간 예산을 정한다.
5. polish에 특정 대상을 리뷰하도록 요청한다.
6. 수정은 무작위로 하지 말고, 항목별 카테고리로 나눠 적용한다.
7. 반영 후 다시 polish를 돌려 최종 검증 패스를 수행한다.

이는 세부사항에 들어가기 전에 먼저 상태를 점검하라는 repo의 강조점과도 맞아떨어집니다.

polish가 주로 살펴보는 항목

소스 기준으로 보면, polish는 다음과 같은 영역을 체계적으로 점검합니다.

• 시각적 정렬
• 간격 일관성
• 인터랙션 상태 커버리지
• 카피 일관성
• 엣지 케이스와 에러 상태
• 로딩과 전환의 매끄러움

이 정보가 유용한 이유는, 어떤 증거를 제공해야 하는지 감이 잡히기 때문입니다. 정적인 UI 마크업만 붙여 넣으면 로딩, 전환, 상태 변화에 대한 피드백은 놓치기 쉽습니다.

해피 패스만 말고 상태 전반을 보여주기

polish 성능이 떨어지는 흔한 이유는 상태 맥락이 빠져 있기 때문입니다. 가능하다면 다음을 함께 포함하세요.

• 기본 상태
• hover/focus/active 상태
• 유효성 검사 에러
• 빈 상태
• 로딩 상태
• 비활성화 상태
• 성공 확인 상태

이렇게 해야 실제 프로덕션에서 사용자가 체감하는 “거의 다 됐는데 뭔가 부족한” 문제를 polish 스킬이 잘 잡아낼 수 있습니다.

결과는 가시성과 공수 기준으로 우선순위화하기

출시가 임박했다면, polish에 결과를 다음과 같이 분류해 달라고 요청하세요.

• 배포 전에 반드시 수정
• 있으면 좋은 개선
• 미뤄도 되는 항목

이렇게 하면 polish 스킬이 단순한 비평 목록보다 훨씬 실무적으로 유용해집니다. 품질 기준은 높지만 시간이 부족할 때 특히 효과적입니다.

실용적인 repository 읽기 순서

이 폴더에는 사실상 SKILL.md만 드러나 있으므로, 가장 효율적인 읽기 순서는 다음과 같습니다.

1. description과 argument-hint를 확인한다
2. MANDATORY PREPARATION을 읽는다
3. Pre-Polish Assessment를 읽는다
4. 체계적인 polish 카테고리를 체크리스트로 활용한다

이 정도면 repo를 과하게 파고들지 않아도, 스킬 적합성을 판단하고 바로 사용을 시작하기에 충분합니다.

polish 스킬 FAQ

polish가 일반 프롬프트보다 더 나은가요?

대체로 그렇습니다. 특히 문제의 성격이 배포 직전 품질 관리라면 더 그렇습니다. 일반 프롬프트는 넓은 의견이나 리디자인 제안을 내놓기 쉽습니다. 반면 polish 스킬은 범위가 더 좁고, 이미 구현된 결과물을 전제로 프로젝트 후반에 놓치기 쉬운 미세한 디테일에 집중합니다.

polish는 UI Design에만 쓰는 건가요?

대체로는 UI Design을 위한 polish와 프론트엔드 경험 품질에 맞춰져 있습니다. 소스는 정렬, 간격, 인터랙션 상태, 엣지 케이스, 매끄러움을 강조하므로, 백엔드 아키텍처나 제품 전략보다는 인터페이스 품질 점검에 훨씬 잘 맞습니다.

초보자도 polish 스킬을 쓸 수 있나요?

가능합니다. 다만 초보자는 더 많은 맥락을 제공해야 합니다. 프로젝트에서 “품질 기준”이나 “디자인 컨텍스트”가 무엇을 뜻하는지 아직 명확하지 않다면, 먼저 필수 상위 디자인 스킬을 실행하세요. 그렇지 않으면 결과가 그럴듯해 보여도 막상 추상적이고 애매하게 느껴질 수 있습니다.

polish를 쓰려면 코드가 완성되어 있어야 하나요?

완전한 수준에 가까운 구현물이나 프로토타입은 있어야 합니다. repo는 polish가 첫 단계가 아니라 마지막 단계라고 분명히 말합니다. 핵심 동작이 아직 계속 바뀌고 있다면, 피드백은 쉽게 흔들리고 가치도 떨어집니다.

도입 시 가장 큰 장애물은 무엇인가요?

가장 큰 장애물은 필수 준비 단계를 건너뛰는 것입니다. polish를 설치해 놓고 /frontend-design 컨텍스트 없이 바로 호출하면, 이 스킬이 신뢰도 높은 결과를 내는 핵심 조건을 놓치게 됩니다.

MVP 작업에도 polish를 써야 하나요?

네. 다만 품질 기준이 MVP라고 분명히 알려줘야 합니다. 그러면 기대되는 리뷰 깊이가 달라집니다. MVP에서 polish를 가장 잘 활용하는 방법은, 완벽주의에 시간을 쓰기보다 눈에 잘 띄는 불일치와 상태 누락을 빠르게 잡는 것입니다.

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

다음이 필요하다면 polish는 건너뛰는 편이 낫습니다.

• 전면 리디자인
• 제품 탐색
• 사용자 리서치 종합
• 아키텍처 변경
• 미완성 핵심 기능

이런 경우에는 다른 스킬이나 직접적인 디자인/엔지니어링 워크플로가 더 적절한 첫 단계입니다.

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

더 좋은 대상 지정하기

polish 결과를 가장 빨리 개선하는 방법은 대상을 구체적으로 적는 것입니다. 예를 들어:

약한 예:
Use polish on my app.

더 나은 예:
Use polish on the mobile checkout summary card and payment error state.

대상이 구체적일수록 뻔한 조언은 줄고, 바로 수정에 들어갈 수 있는 발견이 늘어납니다.

품질 기준을 명시하기

소스가 MVP vs flagship을 굳이 짚는 데에는 이유가 있습니다. 이를 지정하지 않으면, polish가 단순한 내부 도구를 과하게 리뷰하거나, 반대로 출시가 중요한 화면을 너무 얕게 볼 수 있습니다. 어떤 기준을 원하는지 항상 명시하세요.

바뀌면 안 되는 것을 미리 말하기

구조, 레이아웃, 브랜딩을 건드리면 안 된다면 먼저 말하세요. 예를 들면:

Polish this settings page without changing the information architecture or component library.

이렇게 해야 스킬이 리디자인 쪽으로 새지 않고, 마감 품질 향상에 집중할 수 있습니다.

TODO로 남겨야 할 알려진 문제 포함하기

이 스킬은 유지해야 할 알려진 이슈가 있는지도 묻습니다. 실무 팀에서는 이게 중요합니다. 일부 결함을 의도적으로 뒤로 미뤄둔 상태라면, 검토 사이클을 낭비하지 않도록 처음부터 밝혀 두세요.

결과를 카테고리별로 요청하기

강한 프롬프트 형식의 예시는 다음과 같습니다.

Use polish on [target]. Group findings into spacing/alignment, interaction states, copy consistency, edge cases, and motion/loading. For each item, say why it matters and whether it is must-fix or nice-to-have.

이 방식은 repo의 체계적인 접근과 잘 맞고, 실제 구현 단계에서도 훨씬 다루기 쉽습니다.

추상적인 목표만 말고 스크린샷이나 UI 상태를 제공하기

polish로 실제 배포 경험까지 개선하고 싶다면, 눈으로 확인 가능한 자료를 주는 편이 좋습니다. 좋은 입력 자료는 다음과 같습니다.

• 스크린샷
• 컴포넌트 코드
• 상태 설명
• acceptance criteria
• 브랜드 또는 디자인 시스템 제약

눈에 보이는 근거가 많을수록, 스킬은 일반론적 추정보다 실제 증거에 기반해 리뷰할 수 있습니다.

흔한 실패 패턴을 경계하기

다음 상황에서는 polish 결과 품질이 떨어지기 쉽습니다.

• 기능이 실제로는 아직 완성되지 않았다
• 대상 범위가 너무 넓다
• 디자인 컨텍스트가 없다
• 해피 패스만 보여준다
• 팀이 “완료”의 기준을 정의하지 않았다

많은 경우 “polish 결과가 별로였다”는 문제는 사실 출력 문제가 아니라 입력이나 타이밍 문제입니다.

수정 후 polish를 다시 실행하기

좋은 워크플로는 한 번으로 끝나지 않고 두 번 도는 방식입니다.

1. 첫 번째 패스에서 문제를 찾는다
2. 구현으로 반영한다
3. 두 번째 패스에서 회귀와 새로 드러난 불일치를 잡는다

특히 여러 화면에 걸쳐 간격 스케일, 컴포넌트 상태, 카피 패턴을 수정한 뒤에는 이 방식이 매우 유용합니다.

polish를 비평 도구가 아니라 출시 체크리스트로 쓰기

가장 좋은 결과를 원한다면, 배포 전에 실제로 따라갈 수 있는 짧고 실행 가능한 체크리스트를 만들어 달라고 요청하세요. 그러면 polish는 주관적인 피드백 도구를 넘어 실행 보조 도구가 됩니다. 바로 이 지점에서 이 polish 스킬의 가치가 가장 크게 드러납니다.