studio.soluta
← AI 화면 검사와 수정 단원 · 카드 1/1
이 단원의 카드 1개
  1. Impeccable로 기존 화면 검사하고 다듬기

실습 화면 검사와 수정

Impeccable로 기존 화면 검사하고 다듬기

연두색과 주황색을 쓴 포트폴리오 기준판과 Impeccable 적용판을 좌우에 놓은 데스크톱 비교표
왼쪽 기준판과 오른쪽 Impeccable 적용판의 데스크톱 전후 비교

기존 화면에서 시작합니다

Impeccable은 기존 화면을 검사하고 수정한 뒤 같은 조건에서 다시 확인하는 작업 흐름입니다.

단계하는 일
init누구를 위한 어떤 화면인지 기록합니다
detect코드에서 정해진 문제 모양을 찾습니다
polish기존 내용과 방향을 유지하며 다듬습니다
audit접근성·성능·반응형을 기록합니다

실제 예제에서는 기준판의 결정형 검사 2건이 적용판에서 0건으로 줄었습니다. axe-core 자동 접근성 검사와 가로 넘침 검사도 데스크톱·모바일에서 0건이었습니다.

Codex와 Claude Code 모두 /impeccable로 시작합니다. Codex가 설치한 프로젝트 훅의 승인을 요구하면 /hooks에서 내용을 확인하고 승인해야 검사 명령이 이어집니다.

이 결과는 모든 접근성과 디자인 판단을 통과했다는 뜻이 아닙니다. 사용한 명령, 검사 기록, 남은 위험은 전체 Impeccable 실습에서 확인할 수 있습니다.

예시 화면 포트폴리오 기준판과 Impeccable 적용판을 390픽셀 너비로 나란히 놓은 모바일 비교표
같은 두 화면을 390픽셀 너비에서 비교한 모바일 캡처
  1. 프로젝트 폴더에서 `npx impeccable install`을 실행하고 사용 중인 AI 도구를 다시 엽니다. Codex에서 프로젝트 훅 승인을 묻는다면 `/hooks`를 열어 내용을 확인한 뒤 승인합니다.

  2. `/impeccable init`을 실행해 화면의 대상과 디자인 기준을 기록합니다.

  3. 원본 파일을 남기고 `npx impeccable detect index.html`로 첫 검사 결과를 저장합니다.

  4. `/impeccable polish index.html`로 실행합니다. 유지할 내용과 바꾸지 말아야 할 범위를 함께 적습니다.

  5. 같은 detect 명령을 다시 실행해 정해진 문제 모양이 줄었는지 확인합니다.

  6. `/impeccable audit index.html`을 실행합니다. 1440픽셀과 390픽셀 화면, 키보드 이동, 가로 잘림도 직접 확인합니다.

    이 단계의 실제 화면
    연두색과 주황색을 쓴 포트폴리오 기준판과 Impeccable 적용판을 좌우에 놓은 데스크톱 비교표
    화면에서 확인할 것 같은 화면 크기에서 수정 전후를 비교하고 자동 검사 밖의 항목도 직접 확인합니다. Impeccable f88b283 · 2026-08-05

직접 해보기

Codex
/impeccable polish index.html
화면의 가상 내용과 섹션 순서는 유지해 주세요.
새 프로젝트나 성과를 만들지 말고, 기존 방향 안에서 고쳐 주세요.

대괄호 안은 실제 값으로 바꿔서 붙여넣습니다.

Claude Code
/impeccable audit [검사할 파일]
문제를 자동으로 고치지 말고 접근성, 성능, 반응형, 구현 상태를 보고서로 남겨 주세요.

내 화면 하나를 검사한 뒤 자동 검사 결과와 사람이 직접 판단할 항목을 두 칸으로 나눠 적습니다.

헷갈리기 쉬운 것

검사 결과가 0건이어도 좋은 디자인이나 전체 접근성을 통과했다고 말하지 않습니다. 자동 검사는 정해진 코드 모양만 찾습니다.

왜 이렇게 작동하나요

글을 맞춤법 검사한 뒤 직접 다시 읽는 것처럼, 자동 검사와 사람의 화면 확인을 함께 사용합니다.

detect는 정해진 코드 모양을 찾고 polish는 화면을 수정합니다. 같은 detect와 같은 화면 크기로 전후를 비교해야 수정 효과와 남은 위험을 구분할 수 있습니다.

더 알고 싶다면

detect 결과가 0건이면 발행해도 됩니까?
  • 0건은 자동 규칙에 걸린 코드가 없다는 뜻일 뿐이고, 정해진 코드 모양 밖의 문제는 처음부터 검사 범위에 없습니다.
  • 정보가 읽히는지, 브랜드에 맞는지, 키보드로 쓸 수 있는지는 직접 확인합니다. 이 카드의 예제에서도 자동 검사 0건 뒤에 사람 확인을 별도 단계로 뒀습니다.
  • 발행 판단은 detect 0건, audit 기록, 사람 확인 세 가지가 모였을 때 합니다.
왜 유지할 범위를 먼저 적습니까?
  • polish는 화면을 다듬는 단계라서 경계를 주지 않으면 이미 맞는 내용과 섹션까지 바꿀 수 있습니다. "텍스트 내용은 유지하고 색과 간격만"처럼 남길 것을 먼저 적습니다.
  • 가상 성과나 새 프로젝트를 만들지 않는 조건도 함께 적습니다. 다듬는 과정에서 그럴듯한 숫자나 사례가 생기면 코드 문제보다 위험한 결과가 됩니다.
  • 적어 둔 범위는 실행 뒤 diff에서 범위 밖 변경을 찾는 기준이 됩니다. 막혔을 때의 복구 절차가 이 기록을 사용합니다.

새 상황에 적용

기존 화면 한 장 검사하기

원본을 남기고 detect, polish, 같은 detect, audit 순서로 실행합니다.

확인할 결과

같은 화면 크기의 전후 캡처와 자동 검사 결과, 남은 위험 한 줄이 남습니다.

막혔을 때 확인할 순서

내용이나 섹션이 바뀌면 원본과 diff를 비교해 범위 밖 변경을 되돌리고 polish 조건을 좁힙니다.

2026-08-18 기준 · 출처 · Impeccable 공식 사이트, Impeccable 공식 저장소 · 2026-08-17 기준, 수업의 출발점이 된 Threads 게시물