DevAlly AI Agent — User journeys captured with natural language
DevAlly AI Agent — 자연어로 사용자 여정을 기록하는 접근성 검사 도구
DevAlly AI Agent는 자연어로 설명한 사용자 여정을 실제 브라우저에서 실행하고, 각 단계의 접근성을 WCAG 기준으로 검사합니다. 기록된 여정은 사람이 확인한 뒤 반복 점검에 쓰며, 자동화가 다루지 못하는 항목은 별도 수동 감사가 필요합니다.
- 주제
AI 요약
페이지별 검사만으로는 가입, 결제, 예약처럼 여러 화면을 거치는 과정에서 생기는 접근성 문제를 놓치기 쉽습니다. DevAlly AI Agent는 사용자가 자연어로 설명한 여정을 실제 브라우저에서 따라가며 각 단계를 기록합니다. 팀은 기록을 검토하고 재생 화면을 확인한 뒤 워크플로로 저장합니다. 저장한 여정은 WCAG 기준에 따라 반복 검사할 수 있습니다.
자연어로 여정 작성
사용자는 “문의 페이지에서 양식을 작성하고 제출하세요”처럼 원하는 경로를 문장으로 입력합니다. 에이전트는 쿠키 배너를 처리하고, 인증이 필요하면 로그인 정보를 요청하며, 사이트에서 실제로 작업을 진행합니다. 별도의 시스템 프롬프트를 수정하는 방식은 아닙니다. 여정 설명 자체가 에이전트에 주는 지시입니다.
에이전트가 기록한 여정은 사람이 먼저 검토합니다. 제품 담당자가 경로를 확인한 뒤 워크플로로 저장해야 검사에 사용됩니다. DevAlly 측은 이 절차로 에이전트가 접근성 문제를 피해 다른 경로로 이동하는 경우를 검토 단계에서 걸러낸다고 설명합니다. 에이전트 역할은 여정을 기록하는 데 있으며, 접근성 적합성을 스스로 판정하지 않습니다.
검사 결과와 반복 점검
워크플로 검사에서 문제가 발견되면 실패한 WCAG 성공 기준, 문제가 발생한 요소, 스크린샷, 수정 제안을 확인할 수 있습니다. 수정 사항은 DevAlly MCP를 통해 편집기로 보낼 수 있습니다. 실행 기록을 누적해 새로 발견된 문제와 회귀한 문제, 해결된 문제도 구분합니다. 제품을 출시할 때마다 같은 여정을 다시 검사해 결제 등 주요 흐름의 변화를 확인하는 방식입니다.
현재 베타 버전이며 무료 플랜을 포함한 모든 DevAlly 사용자가 이용할 수 있습니다. 모달, 드롭다운, 오류 상태처럼 사용자 상호작용 뒤에 나타나는 화면도 기록합니다. 다만 호버 전용 메뉴, 드래그 앤 드롭, iframe은 아직 지원하지 않습니다. 해당 기능이 필요한 여정은 기록이 조용히 잘못되는 대신 지원하지 않는다고 알립니다.
자동 검사의 범위와 한계
에이전트는 현재 마우스로 클릭하고 입력하는 시각 사용자 방식으로 여정을 수행합니다. 키보드만으로 이동하거나 스크린 리더가 읽는 내용을 확인하지는 않습니다. DevAlly 측은 WCAG 성공 기준 가운데 자동화로 완전히 평가할 수 있는 항목이 약 3분의 1이라고 설명합니다. 포커스 순서와 동작 뒤 포커스 위치, 시간 제한, 스크린 리더 안내의 적절성 등은 사람이 직접 확인해야 합니다.
따라서 이 도구는 사람의 접근성 감사를 대체하지 않습니다. 반복 가능한 자동 검사를 실행하고, 실제 사용 흐름을 감사의 출발점으로 제공하는 역할을 합니다. 감사자는 기록된 동일한 여정을 키보드와 스크린 리더로 확인하며 자동 검사 결과도 함께 참고합니다.
Product Hunt 반응
- @cormacchisholm — 안녕하세요, Product Hunt 여러분. DevAlly 공동 창업자이자 CEO인 Cormac입니다. 페이지 스캔은 유용하지만 사용자는 여정을 수행합니다. 가입하고 결제하고 예약하고 비밀번호를 재설정합니다. 장애가 있는 사용자가 작업을 끝내지 못하게 하는 장벽은 페이지 사이에 놓이는 경우가 많습니다. 키보드 포커스를 가두는 모달, 스크린 리더가 읽지 않는 오류 메시지, 연장할 수 없는 세션 만료, 마우스로만 작동하는 결제 단계가 그런 사례입니다. WCAG도 프로세스에 포함된 페이지라면 모든 단계가 적합해야 한다고 봅니다. 접근성이 90%인 결제 과정도 누군가에게는 끝낼 수 없는 과정입니다. 그래서 자연어로 여정을 설명하면 에이전트가 사이트를 살펴보고 기록합니다. 사용자가 단계를 검토하고 재생 화면을 확인한 뒤 저장합니다. 이후 WCAG 기준에 따라 검사하고, MCP로 편집기에 수정 사항을 보낼 수 있습니다. 매 출시 때마다 다시 점검할 수 있습니다. 에이전트 채팅도 스크린 리더로 이용할 수 있습니다. 베타이며 무료 플랜을 포함한 모든 DevAlly 사용자가 쓸 수 있습니다.
- @oliver_graf1 — 대부분의 팀은 홈페이지와 템플릿 몇 개만 검사하고 결제는 괜찮기를 바랍니다. 접근성이 90%인 결제 과정도 사용자를 막습니다. 전체 여정을 검사하는 접근이 타당합니다. 사람이 단계도 검토한다니 좋습니다.
- @aisling_conlon2 — 정확히 저희가 생각한 부분입니다. 에이전트 워크플로가 기존 시스템을 크게 바꾸겠지만, 실제 사람의 경험과 사람의 검토가 중요합니다. 그래야 실제 사용자를 제대로 이해할 수 있습니다.
- @sara_ford_goog — 안녕하세요, DevAlly 팀. 예전에 접근성과 Section 508 관련 업무를 많이 했습니다. 대상은 WCAG 기준으로 웹사이트를 검증하려는 사람들인가요? 에이전트가 문제를 만나면 어떤 흐름으로 처리하나요? 제품 화면은 여기 올라온 이미지밖에 보지 못했습니다. 테스트하는 사람이 시스템 프롬프트를 바꾸거나 에이전트에 맞춤 지시를 할 수 있나요? 제가 AI 엔지니어링을 할 때는 “이 기능을 배포해”가 아니라 “새 배포 방식을 테스트해”라고 의도를 분명히 말해야 했습니다. 에이전트가 WCAG 문제를 보고하는 대신 무리하게 해결하려고 한 적은 없나요? 출시를 축하합니다.
- @bruno_walraven — WCAG는 검사 기준이고, 사용자는 보통 EAA, ADA, Section 508 등 적용되는 규정의 준수 여부를 확인하려 합니다. 저희는 개별 페이지가 아니라 전체 여정을 검사합니다. 사용자가 자연어로 여정을 설명하면 에이전트가 실제 브라우저에서 진행합니다. 기록된 단계와 재생 화면을 검토하고 확인한 뒤 워크플로로 저장합니다. 문제가 발견되면 성공 기준, 요소, 스크린샷, 수정 제안을 보고합니다. 지시는 별도 시스템 프롬프트가 아니라 여정 설명입니다. “가격 페이지로 가서 Pro 플랜을 열고 장바구니에 담은 뒤 게스트로 결제하세요”처럼 구체적으로 쓸 수 있습니다. 우려하신 우회 문제는 실제 위험입니다. 에이전트가 접근성에 문제가 있는 버튼을 건너뛰고 다음 URL로 이동하면 버그를 놓칠 수 있습니다. 그래서 에이전트는 여정만 기록하고, 저장 전에 제품 담당자가 모든 워크플로를 확인합니다. 사람의 감사도 같은 워크플로에서 시작해 실제 검사 경로를 확인합니다.
- @charlotte_mattu1 — 출시를 축하합니다. 사람의 감사를 대체하나요? 아니면 에이전트가 사용자와 어떤 방식으로 함께 작동하나요?
- @darrenbritton — 대체하지 않습니다. 대체한다고 주장하는 도구는 경계해야 합니다. 워크플로는 감사 범위를 정하고 반복 검사를 자동화하는 단계로 보는 편이 좋습니다. 제품 담당자가 실제 사용자 여정을 만들면 해당 여정에서 접근성 문제를 검사하고, 이후 사람이 감사를 할 때도 그 경로를 기준으로 삼습니다. 자동화로 많은 항목을 잡을 수 있지만 대체 텍스트가 실제로 의미 있는지, 스크린 리더로 흐름이 자연스러운지 같은 질문은 사람이 확인해야 합니다.
- @jharkhandi_chora1 — 팝업, 드롭다운, 사용자 상호작용 뒤에 나타나는 콘텐츠가 포함된 여정은 어떻게 처리하나요?
- @sean_dowdall — 모달, 드롭다운, 오류 상태처럼 상호작용 뒤에 나타나는 내용도 단계마다 기록합니다. 실제 브라우저에서 제품을 사용하므로 사람이 접근할 수 있는 곳에는 에이전트도 갈 수 있습니다. 다만 호버 전용 메뉴, 드래그 앤 드롭, iframe은 아직 지원하지 않습니다. 여정에 그런 요소가 필요하면 잘못된 결과를 조용히 기록하는 대신 미리 알려줍니다.
- @galdayan — 페이지가 아니라 여정을 본다는 방향은 문제에 맞습니다. 다만 에이전트가 DOM이나 비전 모델로 클릭하며 이동해도, 여정을 키보드와 스크린 리더로 실제 완료할 수 있는지는 별개입니다. 실패 원인은 요소 하나의 부적합보다 포커스 순서나 타이밍에 있는 경우가 많습니다. 에이전트는 마우스 사용자 방식으로 이동하나요, 아니면 키보드만 사용하고 각 단계에서 스크린 리더 안내를 읽나요?
- @bruno_walraven — 현재 에이전트는 시각 사용자처럼 클릭하고 입력합니다. 키보드로 탭 이동하거나 스크린 리더가 각 단계에서 읽는 내용을 확인하지 않습니다. 에이전트의 역할은 앱에서 작업을 수행하는 방법을 찾아 행동을 기록하고, 반복 실행할 수 있는 결정적 단계로 만드는 것입니다. 이를 바탕으로 여정의 각 상태를 자동 검사하고 새 문제나 회귀, 해결을 계속 추적합니다. 하지만 WCAG 성공 기준의 약 3분의 1만 자동화로 완전히 평가할 수 있습니다. 포커스 순서, 동작 뒤 포커스 위치, 타이밍, 안내 문구가 적절한지는 사람의 감사가 필요합니다. 감사자는 에이전트가 기록한 같은 여정을 키보드와 스크린 리더로 검사하고 자동 발견 사항도 확인합니다.
- @harshyadav — 까다로운 접근성 문제는 전체 여정에서 드러나는 경우가 많습니다. 이 접근 방식이 마음에 듭니다.
- @oleksii_sekundant — 검사 전에 사람이 기록된 여정을 검토하는 점이 좋습니다. 잘못된 경로가 의존하게 될 테스트로 굳어지기 전에 잡아낼 수 있습니다.
원문: Product Hunt / 번역·요약: Trawling