audit

audit 스킬 개요

audit가 하는 일

audit 스킬은 페이지, 기능, 컴포넌트를 대상으로 구조화된 기술 UI 리뷰를 수행하고, 단순한 감상형 피드백이 아니라 점수화된 보고서를 반환합니다. 접근성, 성능, 테마 일관성, 반응형 동작, 프런트엔드 안티패턴처럼 측정 가능한 구현 품질에 집중한 뒤, 결과를 P0부터 P3까지 심각도로 우선순위화하고 실행 계획까지 제시합니다.

어떤 팀에 audit 스킬이 잘 맞나

이 audit 스킬은 매번 기준을 새로 만들지 않고도 반복 가능한 UX Audit 워크플로를 운영하려는 프런트엔드 팀, design engineer, UX engineer, 제품 빌더에게 특히 잘 맞습니다. 주관적인 디자인 평론이 아니라, 코드 맥락을 이해하는 리뷰가 필요할 때 더욱 유용합니다.

audit의 실제 해결 과제

대부분의 사용자는 단순히 “피드백”을 원하는 것이 아닙니다. 실제로는 이런 질문에 답하고 싶어 합니다. 이 페이지를 출시 가능한 상태로 볼 수 있는가? 가장 먼저 깨지는 부분은 어디인가? 어떤 문제는 접근성 차단 이슈이고, 어떤 문제는 나중에 정리해도 되는가? 다음으로 다른 에이전트나 엔지니어가 무엇을 고쳐야 하는가? audit는 바로 이런 트리아지 작업을 위해 만들어졌습니다.

일반 프롬프트와 다른 audit 스킬의 차이

일반 프롬프트는 폭넓은 조언을 내놓을 수 있습니다. 반면 audit는 의사결정에 더 직접적으로 도움이 되는데, 그 이유는 다음과 같습니다.

• 여러 영역을 아우르는 진단 스캔을 강제함
• 다섯 개 차원에 걸쳐 명시적인 점수 체계를 사용함
• 이슈 발견과 이슈 수정 단계를 분리함
• P0-P3 심각도로 우선순위를 출력함
• 취향 기반 평가가 아니라 구현 근거를 기대함

도입 전 반드시 알아야 할 의존 조건

audit 도입에서 가장 큰 장애물은 컨텍스트입니다. 이 스킬은 먼저 디자인 컨텍스트를 수집해야 합니다. 자체 지침에서도 /frontend-design 호출을 요구하고, 아직 디자인 컨텍스트가 없다면 audit 전에 /teach-impeccable를 실행하라고 안내합니다. 이 단계를 건너뛰면 출력 품질과 일관성이 확실히 떨어집니다.

audit 스킬 사용 방법

audit 설치 맥락

이 저장소는 SKILL.md 안에 별도의 설치 명령을 따로 노출하지 않으므로, GitHub에 호스팅된 Claude 스킬을 설치할 때 쓰는 일반적인 설치 흐름을 따르면 됩니다. 예를 들면 다음과 같습니다.

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

설치 후에는 스킬이 audit로 사용 가능한지 확인하세요. 또한 user-invocable: true로 표시되어 있으므로 직접 호출할 수 있습니다.

먼저 읽어야 할 파일

가장 먼저 .claude/skills/audit/SKILL.md를 읽는 것이 좋습니다. 이 저장소에서는 이 파일에 실제로 쓸 수 있는 로직이 거의 모두 들어 있습니다. 선행 조건, 적용 범위, 평가 차원, 점수 모델, 출력 기대 형식이 모두 여기에 있습니다. 참고할 rules/, resources/, 보조 스크립트가 따로 없기 때문에, 이 스킬을 제대로 쓰려면 스킬 파일을 꼼꼼히 읽는 것이 핵심입니다.

audit의 선행 워크플로 이해하기

audit 스킬을 사용하기 전에 아래 순서를 지키세요.

1. /frontend-design으로 디자인 및 제품 컨텍스트를 수집합니다.
2. 그 컨텍스트가 아직 없다면 /teach-impeccable를 실행합니다.
3. 그다음에야 대상 페이지, 기능, 컴포넌트에 대해 audit를 실행합니다.

이 순서가 중요한 이유는, audit가 기술 중심 평가이긴 해도 안티패턴, 테마 일관성, 구현 품질을 정확히 판단하려면 여전히 맥락 정보가 필요하기 때문입니다.

audit 입력값으로 무엇을 넘겨야 하나

이 스킬은 다음과 같은 인자 힌트를 제공합니다.

[area (feature, page, component...)]

좋은 입력 예시는 다음처럼 범위가 구체적인 감사 대상입니다.

• checkout page
• mobile navigation drawer
• pricing cards component
• settings form validation flow

반대로 the app, the UI처럼 모호한 입력은 audit 범위가 지나치게 넓어져서 결과가 얕아지기 쉽습니다.

audit 스킬이 점검하는 항목

audit 워크플로는 다섯 가지 차원을 스캔합니다.

• 접근성
• 성능
• 테마
• 반응형 디자인
• 안티패턴

그 후 각 차원을 0-4로 점수화하고 보고서를 구성합니다. UX Audit 용도로 audit를 수행한다면, 이 구조는 막연한 UX 품질 우려를 구현 근거가 있는 이슈로 바꿔준다는 점에서 특히 유용합니다.

audit 스킬이 하지 않는 일

audit는 수정이 아니라 진단을 위한 도구입니다. 문제를 고치는 것이 아니라 문제를 문서화하도록 명확히 설계되어 있습니다. 반복 가능한 품질 리뷰가 필요하다면 설치할 가치가 있습니다. 하지만 같은 단계에서 자동 코드 변경, 리팩터링, 시각적 리디자인 제안까지 기대하고 설치하면 맞지 않습니다.

어설픈 요청을 강한 audit 프롬프트로 바꾸기

약한 프롬프트:

• Run audit on my homepage

더 강한 프롬프트:

• Run audit on the homepage hero and signup flow. Focus on keyboard access, semantic structure, responsive layout between 320px and 1440px, theme token consistency, and obvious performance risks. Return scores by dimension plus P0-P3 findings and a fix order.

이 프롬프트가 더 좋은 이유:

• 범위를 명확히 정함
• 사용자 여정을 지정함
• 위험 가능성이 큰 영역을 짚어줌
• 스킬이 원래 기대하는 출력 형식을 요청함

audit 활용에 가장 좋은 워크플로

실무적으로는 다음과 같은 audit 활용 흐름이 가장 안정적입니다.

1. 한 페이지 또는 한 컴포넌트를 고릅니다
2. 먼저 제품/디자인 컨텍스트를 제공합니다
3. audit를 실행합니다
4. 점수와 심각도를 검토합니다
5. P0/P1 결과를 구현 작업으로 전환합니다
6. 수정 후 audit를 다시 실행합니다

이렇게 하면 QA, 릴리스 리뷰, 디자인 시스템 정리 과정에서 audit 스킬을 품질 게이트처럼 활용할 수 있습니다.

좋은 audit 결과물의 모습

유용한 audit 결과에는 다음이 포함되어야 합니다.

• 차원별 점수
• 구체적인 구현 이슈
• P0부터 P3까지의 심각도 순위
• 바로 이어질 수 있는 다음 조치
• 코드나 UI 동작에 연결된 근거

출력이 우선순위 없이 일반론적 모범 사례 중심으로만 나온다면, 대개 원인은 컨텍스트가 약하거나 범위가 너무 넓기 때문입니다.

audit 도입 검토 시 저장소 읽기 순서

이 audit 스킬을 설치할지 평가 중이라면, 가장 빠른 읽기 순서는 다음과 같습니다.

1. SKILL.md의 frontmatter에서 호출 방식과 목적 확인
2. MANDATORY PREPARATION
3. Diagnostic Scan
4. 각 점수 섹션
5. 최종 보고 구조

이 순서대로 보면, 이 스킬이 일반적인 audit 프롬프트보다 내 워크플로에 더 잘 맞는지 빠르게 판단할 수 있습니다.

audit 품질을 높이는 실전 팁

• 한 번에 한 영역만 audit하기
• 중요한 디바이스 구간이나 레이아웃 상태를 명시하기
• UI가 디자인 시스템이나 theme token을 쓰는지 언급하기
• sign-in, checkout, form 같은 핵심 플로를 지정하기
• 근거가 있는 결과만 요청하기
• 순수 트리아지가 목적이면 수정안은 제외하고, 필요하면 후속 remediation 단계를 별도로 요청하기

audit 스킬 FAQ

UX Audit에 audit 스킬이 잘 맞나?

그렇습니다. 단, UX Audit에 구현 레벨의 근거가 필요할 때 특히 잘 맞습니다. audit for UX Audit은 접근성 누락, 반응형 깨짐, 테마 불일치, 사용자 경험에 영향을 주는 프런트엔드 품질 이슈를 중점적으로 볼 때 가장 강합니다. 반면 브랜드 전략, 정보 구조, 정성적 사용성 조사에는 상대적으로 약합니다.

페이지 리뷰를 AI에게 맡기는 것과 audit는 어떻게 다른가?

일반적인 리뷰는 취향, 제품 조언, 코드 추측이 한데 섞이기 쉽습니다. audit 스킬은 정의된 차원, 점수, 심각도를 사용하기 때문에 기술 품질 리뷰에 더 좁고 더 안정적으로 맞춰져 있습니다. 그래서 결과를 엔지니어링 팀에 넘기기도 훨씬 쉽습니다.

audit 스킬은 초보자도 쓰기 쉬운가?

중간 정도입니다. 워크플로 자체는 단순하지만, 선행 컨텍스트 단계는 초보자가 놓치기 쉽습니다. 초보자도 사용할 수는 있지만, WCAG 이슈, semantic HTML, 반응형 동작, design token 같은 기본적인 프런트엔드 개념을 알고 있으면 결과 품질이 더 좋아집니다.

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

다음이 필요하다면 audit는 적합하지 않습니다.

• 사용자 리서치 종합
• 시각적 브랜드 비평
• 전환 카피 리뷰
• 같은 단계에서의 직접 코드 수정
• 명확한 대상 없이 전체 앱을 한 번에 감사하는 작업

이런 경우에는 다른 스킬이나 더 좁은 프롬프트가 대체로 더 적합합니다.

audit는 코드 접근이 꼭 필요한가?

에이전트가 구현을 직접 살펴볼 수 있을 때 가장 좋습니다. 이 스킬은 코드 레벨 audit를 전제로 설계되어 있기 때문입니다. 렌더링된 UI 설명만으로도 추론은 가능하지만, 신뢰도와 구체성은 떨어질 수 있습니다.

릴리스 승인 전에 audit만으로 충분한가?

대체로 그렇지 않습니다. audit는 강력한 기술 리뷰 레이어이지만, 런타임 테스트, 브라우저/디바이스 점검, 분석 데이터 검토, 사람 중심 QA를 대체하지는 못합니다. 유일한 품질 게이트가 아니라, 구조화된 audit 단계 중 하나로 보는 것이 맞습니다.

audit 스킬 개선 방법

더 좁은 범위를 주면 audit 결과가 좋아진다

가장 흔한 실패 패턴은 범위를 너무 넓게 잡는 것입니다. 제품 전체를 한 번에 audit해 달라고 하면 우선순위가 흐려지고 근거 품질도 약해지기 쉽습니다. 더 좋은 방식은 한 번에 한 플로, 한 페이지, 또는 하나의 컴포넌트 군만 audit하는 것입니다.

audit 실행 전에 컨텍스트를 먼저 제공하라

이 스킬은 /frontend-design, 경우에 따라 /teach-impeccable까지 필요하므로, 결과를 개선하는 가장 쉬운 방법은 이 의존 조건을 충분히 채우는 것입니다. 다음 정보를 함께 주면 좋습니다.

• 대상 사용자
• 페이지의 주요 과업
• 기대하는 반응형 breakpoint
• 디자인 시스템 규칙
• 이미 알고 있는 제약이나 의도된 트레이드오프

의견이 아니라 근거를 요구하라

첫 결과가 모호하게 느껴진다면, 다음 프롬프트를 더 타이트하게 조정하세요.

• Cite the element or pattern causing each issue
• Separate verified implementation issues from inferred risks
• Do not include subjective visual preferences

이렇게 해야 audit가 추상적인 감상으로 흐르지 않고, 신뢰할 수 있는 구현 근거 위에 머무릅니다.

audit 심각도 기준을 더 잘 맞추기

모든 결과가 같은 수준의 주의를 받을 필요는 없습니다. P0-P3를 더 실용적으로 만들려면, 내 맥락에서 무엇이 심각한지 스킬에 알려주세요. 예를 들면 다음과 같습니다.

• 법적 리스크 또는 WCAG 노출
• 과업 완료를 막는 문제
• 모바일에서만 발생하는 깨짐
• 공용 컴포넌트의 회귀
• checkout 또는 auth 플로에 영향을 주는 문제

audit를 2단계 패스로 운영하기

품질 좋은 패턴은 다음과 같습니다.

1. 1차 패스: 폭넓은 진단 스캔
2. 2차 패스: 가장 낮은 점수를 받은 차원 심층 분석

예를 들어 접근성 점수가 가장 낮다면, keyboard flow, semantics, forms, contrast만 집중해서 audit를 다시 돌리세요. 이렇게 하면 한 번에 모든 것을 크게 훑는 것보다, 실제 수정 계획까지 이어지기 쉬운 결과를 얻는 경우가 많습니다.

audit 뒤에 수정 단계 워크플로를 붙이기

audit는 문제를 직접 고치지 않기 때문에, 개선 효과는 보통 워크플로를 연결할 때 커집니다.

• audit 실행
• P0/P1 이슈 추출
• 각 이슈를 repair prompt, 엔지니어, 또는 코드 편집 에이전트에 할당
• 변경 후 audit 재실행

이렇게 하면 audit 스킬이 단순 보고 도구를 넘어, 실제 품질 루프의 일부가 됩니다.

반응형 및 테마 점검 입력을 더 강하게 만들기

반응형이나 테마 품질이 중요하다면, 그 점을 명시적으로 써주세요. 좋은 추가 문구는 다음과 같습니다.

• Check behavior at 320px, 768px, and 1440px
• Check dark mode and token consistency
• Flag hard-coded colors, spacing drift, and component state inconsistencies

이 정도 구체성이 없으면 audit가 해당 영역을 언급은 하더라도 깊게 파고들지 못할 수 있습니다.

엔지니어 핸드오프용으로 audit 출력 형식 맞추기

보고서를 엔지니어가 바로 활용해야 한다면, 다음 형식을 요청하세요.

• 이슈 제목
• 심각도
• 영향 범위
• 왜 중요한지
• 권장 수정 방향
• 수정 후 검증 방법

이 형식은 audit 결과를 단순 참고용이 아니라 바로 백로그에 넣을 수 있는 수준으로 바꿔주기 때문에, 실제 채택률이 높아집니다.

첫 audit 실행이 약했다는 신호

다음과 같은 모습이 보이면 audit를 다시 실행하는 편이 좋습니다.

• 예시 없는 상위 수준 조언만 있음
• 차원별 점수가 없음
• P0-P3 우선순위가 없음
• 기술 리뷰보다 디자인 평론처럼 읽힘
• 내가 지정한 대상 영역 언급이 없음

이런 경우는 대개 스킬 자체가 나빠서가 아니라, 프롬프트나 컨텍스트 설정 문제인 경우가 많습니다.

첫 보고서 이후 가장 좋은 반복 방법

첫 audit 이후에 단순히 anything else?라고 묻지는 마세요. 대신 아래처럼 구체적으로 반복하는 것이 좋습니다.

• Expand only the P0 and P1 issues
• Re-audit the form flow for accessibility only
• Convert findings into an engineering checklist
• Challenge the performance score with stronger evidence
• Rerun audit after fixes and compare score changes

이런 식의 반복이 같은 넓은 요청을 되풀이하는 것보다 audit 스킬의 가치를 훨씬 더 크게 끌어냅니다.