몇 주 전 저는 Cypress Cloud의 새로운 접근성 (accessibility) 기능들을 탐색하기 시작했습니다. 저는 또 다른 설정 가이드를 작성하고 싶지 않았습니다. 대신 여러분이 실제로 따라 할 수 있고 자신의 프로젝트에 직접 사용할 수 있는 실질적인 무언가를 보여주고 싶었습니다.

그래서 저는 더미 앱 (dummy app)을 만들고, 이를 대상으로 Cypress를 실행한 뒤, Cypress Cloud MCP를 통해 Claude를 연결했습니다. 그 결과, 접근성을 중요하게 생각하는 모든 팀에게 진정으로 유용할 것이라고 생각되는 '탐지(detect), 분석(analyze), 수정(fix), 검증(verify)'의 완전한 루프가 만들어졌습니다.

제가 정확히 무엇을 했고 무엇을 발견했는지 소개합니다.

더미 앱 (The Dummy App)

The dummy banking portal login page used for the demo

데모를 구체적이고 공감할 수 있게 만들기 위해, 저는 온라인 뱅킹 포털처럼 보이는 간단한 더미 앱을 구축했습니다. 이 앱은 로그인 페이지와 거래 내역 테이블이 있는 계정 대시보드라는 두 개의 페이지로 구성되어 있습니다.

이러한 종류의 앱을 선택한 이유는 대부분의 개발자가 본 적이 있는 형태이며, 접근성 (accessibility)의 중요성이 즉각적으로 드러나기 때문입니다. 사람들은 잔액 확인, 공과금 납부, 자금 관리를 위해 금융 앱에 의존합니다. 만약 앱이 접근 가능하지 않다면, 실제 사용자들은 차단됩니다. 더미 앱은 워크플로우를 명확하게 보여주기 위한 도구일 뿐입니다. 동일한 접근 방식은 어떤 프로젝트에도 적용 가능합니다.

워크플로우 (The Workflow)

전체 과정은 세 단계로 진행됩니다:

1. 탐지 (Detect): 페이지를 방문하는 Cypress 테스트를 실행하고 그 결과를 Cypress Cloud에 기록합니다. 추가적인 플러그인은 필요하지 않습니다. Cypress Cloud는 기록된 모든 실행 시 백그라운드에서 자동으로 접근성 위반 사항을 스캔합니다.
2. 분석 (Analyze): Cypress Cloud MCP를 통해 Claude에게 무엇이 왜 실패했는지 묻습니다. Claude는 Cypress Cloud에서 전체 접근성 보고서를 직접 가져와 심각도에 따라 이슈의 순위를 매깁니다.
3. 수정 및 검증 (Fix and Verify): 코드에 수정 사항을 적용하고 다시 한 번 실행을 기록합니다. Claude에게 보고서가 깨끗한지(clean) 확인하도록 요청합니다.

Cypress Cloud가 자동으로 찾아낸 것들

첫 번째 기록된 실행에서, Cypress Cloud는 별도의 플러그인이나 추가 설정 없이도 두 페이지 모두에서 4개의 실패한 접근성 규칙(accessibility rules)을 감지했습니다:

• color-contrast (serious): 텍스트가 WCAG 대비 요구 사항을 충족하지 않음
• landmark-one-main (moderate): 페이지에 main landmark가 누락됨
• page-has-heading-one (moderate): 페이지에 level one heading이 누락됨
• region (moderate): 페이지 콘텐츠가 landmark regions로 감싸져 있지 않음

Cypress Cloud showing 81% score and 4 failed rules on the first run

실행을 기록하는 것 외에 아무런 설정 없이 시작하자마자 81%의 접근성 점수를 얻었습니다.

Claude가 개입하는 지점

실행이 기록된 후, 저는 Claude Desktop을 열고 Cypress Cloud MCP를 통해 해당 실행에 대한 접근성 보고서(accessibility report)를 가져오도록 요청했습니다. Claude는 심각도(severity) 순으로 정렬된 전체 보고서를 반환하였고, 각 규칙의 의미를 설명했으며, 어떤 문제를 먼저 수정해야 하는지 알려주었습니다.

단순히 규칙 ID 목록만 받는 것이 아닙니다. 워크플로를 벗어나지 않고도 문맥(context), 우선순위 지정, 그리고 명확한 시작점을 얻게 됩니다. 이것이 이 과정이 단순한 멋진 데모를 넘어 진정으로 유용하게 느껴지게 만든 요소입니다.

수정 사항

문제가 명확히 식별된 후, 수정 작업은 간단했습니다:

• 로그인 페이지의 폼 입력(form inputs)에 적절한 레이블(labels) 추가
• 페이지 콘텐츠를 main landmark 요소로 감싸기
• 두 페이지 모두에 level one heading 추가
• WCAG AA 요구 사항을 충족하도록 텍스트 색상 대비 수정
• 이미지에 대체 텍스트(alt text) 추가
• 내비게이션(navigation) 요소에 aria-label 추가

수정 후

Cypress Cloud showing 100% accessibility score after the fixes were applied

수정 사항을 적용하고 다시 실행을 기록한 뒤, Claude에게 새로운 접근성 보고서(accessibility report)를 추출하도록 요청했습니다. 결과는 두 페이지 모두에서 실패한 규칙이 0개인, 접근성 점수 100%를 기록했습니다. Claude는 문제가 없음을 확인해 주었습니다.

인상적이었던 점은 워크플로(workflow)가 구축된 이후에는 투입되는 노력이 매우 적었다는 것입니다. Cypress Cloud는 스캐닝(scanning)을 담당하고, Claude는 분석(analysis)을 담당하며, 저는 수정(fixes)을 담당했습니다. 각 도구가 자신이 잘하는 일을 수행한 것입니다.

이번 경험을 통해 얻은 교훈

접근성 테스트(Accessibility testing)는 스프린트(sprint) 마지막에 억지로 덧붙이는 별도의 프로세스일 필요가 없습니다. Cypress Cloud가 모든 기록된 실행 시 자동으로 점검을 수행하고, Claude가 MCP를 통해 결과를 제시함으로써, 이는 정상적인 개발 루프(development loop)의 일부가 됩니다.

더미 뱅킹 앱은 이 워크플로를 구체화하기 위한 수단이었을 뿐입니다. 동일한 접근 방식은 실제 사용자들이 모든 사람을 위해 코드가 올바르게 작동하기를 기대하는 모든 애플리케이션에 적용될 수 있습니다.

여러분의 CI 파이프라인(CI pipeline)에서 접근성 테스트를 실험하고 있다면, 어떤 방식으로 접근하고 계신지 정말 궁금합니다. 아래에 댓글을 남겨주세요.