AI가 구현한 UI 검수: 시각적 회귀와 접근성을 함께 확인하기

보이는 일치와 사용할 수 있는지는 다른 질문입니다

이미지와 브라우저를 다루는 코딩 에이전트가 UI 구현에 참여하면서 화면 캡처를 검수 근거로 쓰기 쉬워졌습니다. Playwright는 기준 이미지와의 비교 및 접근성 검사 연동을 문서화하지만, 자동 검사만으로 모든 접근성 문제를 발견할 수 없다고 설명합니다. 화면의 모양, 의미 구조, 실제 입력 흐름을 나눠 확인해야 한 종류의 통과 결과를 전체 품질로 오해하지 않습니다.

• Playwright · Visual comparisons
• Playwright · Accessibility testing

가상의 예약 페이지에서 에이전트가 날짜 선택 팝업을 디자인과 비슷하게 만들었다고 가정하겠습니다. 마우스로는 선택되지만 키보드 초점이 팝업 밖으로 빠지거나 닫은 뒤 원래 버튼으로 돌아가지 않을 수 있습니다. 스크린샷에는 이런 실패가 드러나지 않습니다. 반대로 접근성 속성이 맞아도 작은 화면에서 확인 버튼이 가려질 수 있어 두 검사가 함께 필요합니다.

비교 전에 흔들리는 화면 조건부터 통제합니다

기준 이미지와 검증 이미지는 운영체제, 브라우저, 폰트와 화면 크기를 맞춰 생성합니다. 날짜, 사용자명, 네트워크 응답과 애니메이션이 달라지면 실제 회귀와 무관한 차이가 늘어납니다. 필요한 폰트와 데이터가 준비된 상태를 기다리고 테스트용 시간을 고정하세요. 외부 콘텐츠를 가릴 때는 중요한 가격이나 오류 안내까지 검사에서 빠지지 않는지 검토합니다.

비교 허용 오차를 크게 늘려 실패를 없애기 전에 차이가 글꼴 렌더링인지 실제 배치 변화인지 확인합니다. 페이지 전체 이미지 외에 핵심 폼이나 대화상자를 따로 비교하면 원인 파악이 쉽습니다. 다만 작은 영역만 검사하면 고정 헤더와 본문이 겹치는 문제를 놓칠 수 있으므로 대표 전체 화면도 함께 남기는 편이 좋습니다.

사용자가 거치는 상태 전이를 검수합니다

접근성 자동 검사에서는 레이블, 식별자, 색상 대비 같은 항목을 먼저 확인할 수 있습니다. 이어서 키보드만으로 시작부터 완료까지 이동하고, 대화상자 열기·닫기와 오류 이후 초점을 살펴봅니다. 버튼에 접근 가능한 이름이 있는지만 확인하지 말고 실제 행동을 설명하는지 읽어보세요. 중요한 업무는 보조 기술을 사용하는 수동 확인까지 검수 범위에 포함합니다.

반응형 화면에는 폭만 다른 같은 데이터보다 내용이 긴 이름, 큰 글자 설정, 다국어 문장과 권한별 메뉴를 넣어야 합니다. 에이전트가 정상 데이터에 맞춰 높이를 고정하면 빈 상태나 긴 오류 설명에서 레이아웃이 무너질 수 있습니다. 모든 조합을 무한히 늘리기보다 사용 빈도와 실패 영향을 기준으로 대표 상태를 고르고 선택 이유를 기록합니다.

기준 이미지 변경도 검토해야 할 결과물입니다

에이전트가 UI와 기준 이미지를 동시에 바꾸면 검사 통과만으로는 의도한 변화인지 알 수 없습니다. 이전 화면, 새 화면, 차이 이미지와 변경 이유를 한 번에 확인하게 하세요. 승인한 디자인 변경과 예상하지 않은 주변 변화를 분리하고, 검수자가 새 기준을 채택하도록 합니다. 테스트 생성은 자동화할 수 있지만 무엇을 정상으로 인정할지는 제품의 판단으로 남습니다.

• 동일한 환경과 준비된 폰트로 이미지를 비교했는가
• 빈 상태·오류·긴 내용과 작은 화면을 포함했는가
• 키보드 초점과 대화상자 종료 흐름을 확인했는가
• 새 기준 이미지의 의도와 주변 영향을 사람이 검토했는가