알리의 접근성 연구소 로고알리의 접근성 연구소

방문자 카운터

접근성 브리핑 제23호

71 min read

들어가며

30년 전 8월 어느 날, 컴퓨터에 메모리(RAM)를 추가 설치한 뒤 빼놓은 선들을 하나하나 다시 연결합니다. 시각장애인인 저는 늘 그랬듯 손으로 더듬어 가며 단자를 찾고 선들을 연결합니다. 절연도 잘 안 된 케이스인 탓인지 찌릿찌릿 전류가 느껴져서 움찔거리기를 몇 번 반복한 뒤 전원을 켭니다. 별문제가 없다면 컴퓨터가 돌고 화면이 켜지고 반가운 Windows 시동음이 들립니다. 지금도 변함없이 장치를 연결할 때면 매번 단자를 더듬습니다. 저는 늘 ‘인터페이스’(interface)와 함께해 왔습니다.

인터페이스는 ‘만나는 자리’입니다. 컴퓨터와 온갖 장치를 만나게 하는 자리는 USB 인터페이스이고, 컴퓨터의 영상과 소리를 모니터와 스피커에 이어 주는 자리는 HDMI입니다. 그런데 장치와 선이 만나는 자리만 ‘인터페이스’가 아닙니다. 사람과 컴퓨터가 만나는 자리가 있으니 바로 UI, 사용자 인터페이스입니다.

그런데 만남은 양쪽이 서로를 알아볼 수 있을 때 비로소 시작됩니다. 화면에 버튼이 있어도 그 이름을 들을 수 없고, 문서에 제목이 보여도 그 구조를 건너뛸 수 없다면 시각장애인은 그 자리에 와 있으면서도 컴퓨터를 만나지 못합니다.

지난 제22호에서는 왜 화면 읽기 프로그램 하나만 배워서는 부족한지를 살펴봤습니다. 프로그램과 운영체제, 브라우저에 따라 호환성과 탐색법이 달라지는 현실을 짚었습니다. 이번에는 그 질문을 인터페이스의 역사 전체로 넓혀 보겠습니다.

컴퓨터도 UI도 결국 사람을 편하게 하려고 발전해 왔다면, 그 진화는 실제로 시각장애인에게 어떤 편리를 주었을까요?

명령줄에서 그래픽 화면으로, 터치로, 웹과 문서로, 그리고 이제 AI 에이전트로. 인터페이스가 바뀔 때마다 화면 읽기 프로그램이 읽어야 할 대상도 함께 바뀌었습니다. 처음에는 글자였고, 다음에는 객체와 상태였으며, 웹과 PDF에서는 구조와 관계였습니다. 그 변화는 새로운 문을 열어 주기도 했지만, 그때마다 새로운 탐색 문법을 다시 배우라고 사용자를 다그치기도 했습니다.

시각장애인의 컴퓨터 이용 방식은 하나가 아닙니다. 저시력 사용자는 화면 확대와 글자 크기·색상·대비 조절을 주된 수단으로 쓰거나 화면 읽기 프로그램과 함께 사용합니다. 이번 글은 그 여러 방식 가운데 화면 읽기 프로그램을 중심으로 UI의 변화를 따라가 봅니다.

제23호 - 2026년 8월 4일(화)

브리핑 1. 만나는 자리의 재구성 — 화면 읽기 프로그램은 왜 ‘또 하나의 UI’인가

인터페이스의 역사를 화면이 화려해진 역사로 읽으면 절반만 보입니다. 조금 다르게 보면 이것은 컴퓨터가 자기 상태와 지금 할 수 있는 행동을 사람에게 어떤 방식으로 드러내 왔는가의 변천사입니다. 화면 읽기 프로그램의 역사도 마찬가지입니다. 이 프로그램은 화면에 보이는 문장을 음성으로 바꾸는 데서 끝나지 않고 무엇이 글자이고 무엇이 버튼인지, 지금 내가 어디에 있는지, 무엇을 누를 수 있는지, 누른 뒤에 무엇이 달라졌는지를 읽어 내는 쪽으로 역할이 계속 확대되어 왔습니다.

그래서 화면 읽기 프로그램은 원래 있던 UI에 나중에 덧붙인 낭독 기능이 아닙니다. 앱이 운영체제의 접근성 API와 문서 구조를 통해 내놓은 정보를 받아, 현재 위치와 가능한 행동과 객체의 상태와 이동 경로를 사용자 앞에 다시 구성하는 또 하나의 UI입니다. W3C의 접근성 API 매핑 규격은 이 연결 고리를 분명히 설명합니다. 사용자 에이전트가 문서에서 접근성 트리를 만들고, 그 정보를 운영체제의 접근성 API에 노출하며, 보조공학기술이 그것을 읽어 갑니다.1 시각장애인이 실제로 만나는 인터페이스는 앱의 UI와 접근성 정보, 화면 읽기 프로그램의 탐색 체계가 한데 모여 만들어지는 셈입니다.

출력도 음성 하나가 아닙니다. 점자 표시 장치로 글자와 기호를 손끝으로 확인하는 경로가 함께 있습니다. 음성은 흐름을 빠르게 훑는 데 강하고, 점자는 철자와 기호, 코드와 숫자를 정확히 확인하는 데 강합니다.2 이 구분은 뒤에서 다룰 AI 시대의 ‘검증’ 이야기에서 다시 다루겠습니다.

비장애인이 화면을 ‘척’ 본다는 말에는 속도 이상의 차이가 들어 있습니다. 화면의 전체 모양과 정보의 밀도, 구역 사이의 관계, 방금 달라진 부분과 다음에 할 수 있는 행동을 한꺼번에 짐작합니다. 화면 읽기 프로그램 사용자는 제목과 객체, 상태와 관계를 차례로 따라가며 그 전체를 머릿속에서 다시 조립합니다. 같은 정보가 제공되더라도 동시에 훑어보는 일과 순서대로 탐색하는 일에 드는 시간과 인지 비용은 같지 않습니다.3

그래서 UI의 역사를 이야기할 때 저는 질문 하나를 더 얹고 싶습니다. 화면과 마우스는 많은 사람에게 더 빠르고 직관적인 조작을 제공했습니다. 그러나 시각장애인에게는 화면 속 구조를 해석하기 위한 단축키와 제스처, 탐색 모드와 우회 경로를 새로 요구했습니다. 주류 UI가 감춘 복잡성을 사용자가 학습으로 떠안았다면, 그것을 모두 기술 발전의 혜택이라고만 부르기는 어렵습니다. 누구의 편리함을 위해 누구의 학습 비용이 늘어났는지 따져봐야 합니다.

화면 읽기 프로그램을 처음 익히는 사람은 필수 명령과 제스처와 제품별 차이를 함께 살펴볼 수 있습니다. 하지만 사용자가 감당해야 했던 어려움은 여기서 끝나지 않았습니다.

브리핑 2. 글자의 시대 — 명령줄과 텍스트 화면은 정말 친절했나

CLI, 즉 명령줄 인터페이스는 오늘날까지 살아남은 가장 오래된 축의 인터페이스입니다. 펀치카드와 전신타자기, 초기 콘솔을 생각하면 ‘최초’라고 부르기는 조심스럽지만, 사람이 글자로 명령을 적고 컴퓨터가 글자로 답하는 방식이 지금까지 이어진다는 점은 분명합니다.

컴퓨터를 일찍부터 사용한 제 주위의 시각장애인들 가운데에는 초기 화면 읽기 프로그램을 쓰던 때를 조작이 비교적 편안했던 시절로 기억하는 사람도 있습니다. 그 기억에는 근거가 있습니다. 화면이 곧 글자였으니 화면 읽기 프로그램이 읽어야 할 대상도 어느 정도 분명했습니다. 입력한 명령과 컴퓨터가 돌려준 텍스트가 한 줄씩 쌓이는 구조는 순차적으로 읽어 나가는 방식과 잘 맞았습니다.

하지만 그 기억만으로 당시 환경을 다 설명할 수는 없습니다. 출력이 빠르게 쌓이면 앞의 내용은 화면 밖으로 밀려 올라갔고, 놓친 오류 한 줄을 다시 찾으려면 출력 기록을 거슬러 올라가야 했습니다. 커서가 지금 어디에 있는지, 명령이 끝났는지, 화면의 어느 부분만 다시 그려졌는지는 음성만으로 곧바로 알기 어려웠습니다.

접근성 전문가 칼 그로브스는 명령줄 도구의 접근성을 정리하면서 이 문제를 구체적으로 지목했습니다. 화면을 다시 그리는 일부 TUI는 ANSI/VT 계열 터미널 제어 시퀀스를 사용합니다.4 이런 방식은 보조공학기술 환경에서 제대로 전달되지 않거나 음성 출력이 같은 내용을 되풀이하는 상태로 이어질 수 있습니다. 아스키 아트와 표, 테두리, 색으로만 표시한 상태도 마찬가지입니다.5

그가 제시한 해법은 어렵지 않습니다. 장식 요소와 애니메이션을 끄는 선택지를 주고, 색상·애니메이션에 관한 사용자 설정과 단말이 알려 주는 기능 범위를 존중해야 합니다.6 구조화된 출력 형식을 함께 제공하고 그 사실을 도움말에 분명히 적어야 합니다.5 이런 평범한 선택지 하나가 장벽을 크게 줄이기도 합니다.

TUI는 이 경계를 다시 흐립니다. 겉으로는 글자로만 이루어졌지만 그 글자들이 표와 대화상자, 탭과 진행 막대, 목록과 편집기와 여러 구획을 그립니다. 비장애인에게 구역을 나누어 주는 선과 테두리는 화면 읽기 프로그램에 의미 없는 기호나 낯선 문자 코드로 전달됩니다. ‘선, 선, 선’처럼 같은 기호를 되풀이해 읽으면 구조를 알려 주기는커녕 정작 중요한 내용을 가리는 잡음이 됩니다.

눈으로 보면 GUI처럼 분명한 화면도 음성으로 들으면 낱글자와 기호가 이어질 때가 있습니다. 글자가 모였다고 저절로 의미 있는 객체가 되는 것은 아닙니다. 개발자가 시각적 배치를 만들었더라도 역할과 이름, 상태와 읽기 순서, 초점 이동을 함께 전달하지 않으면 시각장애인은 화면을 읽고도 구조를 파악할 수 없습니다. 같은 문제는 AI 에이전트에서도 되풀이됩니다.

명령줄과 텍스트 화면도 시각장애인에게 저절로 친절한 환경은 아니었습니다.

브리핑 3. 객체와 구조의 시대 — GUI와 터치, 그리고 다시 앱이 된 웹

GUI가 등장하면서 화면은 글자의 줄이 아니라 창과 메뉴, 버튼과 체크 상자, 그림과 선택 상태와 초점이 얽힌 공간이 됐습니다. 이제 화면 읽기 프로그램은 글자를 읽는 프로그램이 아니라 객체와 상태, 관계와 이동 경로를 해석하는 인터페이스가 되어야 했습니다.

이 해석이 가능한 이유는 운영체제가 접근성 API를 제공하기 때문입니다. Windows의 UI Automation, macOS와 iOS의 접근성 API, Android의 접근성 서비스가 앱의 객체 정보를 보조기술에 전달합니다.1 반대로 말하면, 앱이 접근성 관련 정보를 내놓지 않으면 화면 읽기 프로그램은 아무리 성능이 좋아도 이름 없는 버튼을 ‘버튼’이라고밖에 말할 수 없습니다.7

접근성 API가 자리 잡기 전에는 화면 읽기 프로그램 개발자가 앱과 운영체제가 전달하지 않은 정보를 직접 메워야 했습니다. 그 대가로 초기 Windows 화면 읽기 프로그램은 꽤 불안정했습니다.8

스마트폰의 터치 UI는 여기에 또 다른 사용법을 보탰습니다. 사용자들은 손가락으로 화면을 훑어 객체를 직접 찾는 방식과 좌우로 쓸어 항목을 차례로 옮기는 방식은 물론이고 탐색 단위를 바꾸는 로터와 읽기 제어도 새로 배워야 했습니다.9 보이는 위치를 손가락으로 만지는 일과 화면 읽기 프로그램의 접근성 초점을 옮기는 일이 언제나 같지도 않았습니다. 같은 VoiceOver라도 Mac의 키보드·그룹 탐색과 iPhone의 터치 제스처는 서로 다른 숙련도를 요구합니다.

웹과 PDF에서는 문서 구조가 중요해졌습니다. 제목과 문단, 목록과 표, 링크와 폼 같은 구조가 제대로 들어 있으면 화면 읽기 프로그램은 사용자가 원하는 단위로 건너뛰고 관계를 파악하도록 돕습니다.10 반대로 화면에 글자가 보인다는 이유만으로 문서 구조가 생기지는 않습니다. 태그 없는 PDF, 제목처럼 크게 보이지만 실제로는 일반 문단인 웹페이지, 셀 관계를 알 수 없는 표는 읽히면서도 길을 잃게 합니다.11 여기에서도 문제는 소리가 나느냐가 아니라 문서 안에서 내가 어디에 있고 어디로 갈 수 있느냐입니다.

그런데 오늘날의 웹은 문서에 머물지 않습니다. 제22호에서 다룬 것처럼, Notion과 Slack 같은 협업 도구, Obsidian과 Visual Studio Code 같은 Electron 데스크톱 앱은 웹 기술로 편집기와 대화상자, 탭과 실시간 알림과 여러 작업 영역을 구현합니다.12 문서의 제목과 랜드마크를 따라가던 탐색법 위에 데스크톱 앱의 초점 이동과 명령 체계까지 겹칩니다. 문서였던 웹이 다시 복잡한 앱이 되면서 화면 읽기 프로그램이 읽어야 할 대상도 덩달아 늘어났습니다. 뒤에서 다룰 AI 채팅과 에이전트 인터페이스도 이 동적 웹 앱의 연장선 위에 놓여 있습니다.

UI의 변화는 시각장애인에게 기능의 증가만을 뜻하지 않았습니다. 인터페이스가 바뀔 때마다 새로운 탐색법과 또 하나의 사용법을 배워야 했습니다. 같은 버튼도 운영체제와 앱, 브라우저, 화면 읽기 프로그램에 따라 다르게 읽어 주었습니다. 눈으로는 한꺼번에 파악하는 화면을 키보드와 음성으로는 항목마다 훑어야 했습니다. 개발자가 접근성 정보를 빠뜨리면 사용자는 다른 화면 읽기 프로그램을 켜거나, 가상커서와 포커스 모드를 바꾸거나, 기억해 둔 단축키와 우회 경로를 동원해야 했습니다. WebAIM 조사에서 데스크톱·노트북 응답자의 71.6%가 둘 이상의 화면 읽기 프로그램을 쓴다고 답한 배경에도 이런 사정이 있습니다.13

그러나 이 역사가 장벽만 남긴 것은 아닙니다. 접근성 API와 시맨틱 구조, 키보드 인터페이스와 ARIA, 태그가 지정된 PDF, 운영체제에 내장된 화면 읽기 프로그램은 닫힌 화면에 계속 문을 내 온 노력입니다. 장애인 당사자와 보조공학 개발자, 표준을 만드는 사람들, 접근성을 구현하고 시험한 개발자들이 컴퓨터가 자기 구조와 상태를 더 잘 말하도록 만들었습니다. 완전하지는 않았지만 그 꾸준한 노력이 있었기에 화면 읽기 프로그램은 글자를 소리 내는 도구를 넘어 사람이 컴퓨터를 조작하는 인터페이스가 될 수 있었습니다.

브리핑 4. 터미널로 돌아온 AI 에이전트 — 아비규환과 승인 화면

AI 에이전트는 이 흐름에서 또 다른 전환점일 수 있습니다. 사용자가 화면에 놓인 모든 버튼과 메뉴를 직접 찾아다니는 대신, 하고 싶은 일을 자연어로 말하면 에이전트가 앱과 웹을 넘나들며 작업을 수행합니다. 이때 사용자가 만나는 첫 인터페이스는 개별 프로그램의 GUI가 아니라 컴퓨터를 다루는 AI와의 대화가 됩니다.

그런데 지금의 AI 에이전트 상당수는 다시 터미널로 돌아와 TUI의 기술을 한계까지 끌어냅니다. 애니메이션과 경과 시간, 추론 과정과 도구 실행 기록, 질문과 오류와 최종 결과가 한 화면에서 계속 갱신됩니다. 눈으로는 색과 위치를 단서 삼아 구역을 나눌 수 있지만, 화면 읽기 프로그램에는 같은 기호와 숫자가 되풀이되고 새 출력이 이전 내용을 밀어내는 아비규환이 펼쳐집니다. 무엇이 진행 상태이고 무엇이 읽어야 할 결과인지 가르는 일부터 사용자의 몫이 됩니다.

저도 Hermes Agent의 현대적인 TUI를 쓰며 이 차이를 겪었습니다.14 시각적으로 정돈된 대체 화면과 실시간 패널, 모달 창이 화면 읽기 프로그램의 선형적인 읽기 흐름을 자주 끊었습니다. 그래서 현대적인 TUI보다 스크롤백이 남는 기존 CLI가 더 쓰기 쉬웠다는 경험과 함께, 애니메이션과 잦은 다시 그리기를 끄고 출력을 안정된 덩어리로 전달하는 화면 읽기 프로그램 모드를 제안했습니다.15

다른 에이전트 도구에서도 비슷한 요구가 이어졌고, 같은 방향의 기능도 등장했습니다. Claude Code의 화면 읽기 프로그램 모드는 시각적 터미널을 평평한 선형 텍스트로 바꿉니다. 화면을 그리는 문자와 반복 갱신을 줄이고, 메시지의 역할을 이름표로 밝히며, 스크롤백과 번호 목록으로 대화와 승인 과정을 다시 찾아가게 합니다.16 핵심은 화면을 단순하게 보이게 만드는 데 있지 않습니다. 터미널 안에서 역할과 이름과 상태와 읽기 순서를 되살리는 데 있습니다. Gemini CLI에서도 같은 방향의 요구와 작업이 이어졌습니다.17

에이전트가 일을 할 때 사용자에게 권한을 묻는 승인 화면에서는 새로 나타난 질문을 찾고 버튼에 초점을 옮길 수 있다는 것만으로는 충분하지 않습니다. 무엇을 하려는지, 왜 권한이 필요한지, 대상과 범위는 어디까지인지, 허용하거나 거부하면 무엇이 달라지는지, 되돌릴 수 있는지를 사용자는 알아야 합니다. 그렇지 않으면 권한 승인은 사용자의 통제권을 지키는 절차가 아니라, 내용을 모른 채 ‘허용’을 눌러야 다음으로 넘어갈 수 있는 또 하나의 장벽이 됩니다. 저는 Hermes Agent의 승인 화면에서도 이 문제를 확인했습니다. 승인 내용의 일부만 보이고 나머지는 ‘위에 있다’고 안내됐지만, 그 ‘위’를 안정적으로 찾아갈 수 없었습니다. 복잡한 TUI에서 무엇을 승인하는지 읽을 수 있어야 동의도 거부도 할 수 있다는 점을 별도 이슈로 남겼습니다.15

그렇다면 터미널을 떠나 웹 앱으로 옮겨가면 그나마 편해질까요? 메시지와 입력창, 진행 상태와 결과가 구조적으로 나뉜 웹 앱은 터미널의 아비규환보다 나을 수는 있습니다. 그러나 제목과 랜드마크, 초점 이동과 상태 알림이 제대로 구현되지 않으면 새 메시지를 반복해서 읽거나 응답 완료를 알지 못하는 문제가 생깁니다.18 웹 앱은 해답이라기보다 접근성이 지켜졌을 때에만 터미널형 TUI보다 덜 힘들 수 있는 차선입니다. 웹 앱 역시 사용자에게 고유한 탐색법을 다시 요구한다는 한계가 있습니다.

한 가지는 분명히 확인됩니다. 터미널이 언제나 웹보다 접근하기 쉽다는 말도, 웹이 언제나 터미널보다 낫다는 말도 사실이 아닙니다. 어느 쪽이든 구조와 상태와 초점을 설계한 만큼만 접근 가능해집니다.

브리핑 5. 대화·탐색·통제 — AI 에이전트는 시각장애인의 UI가 될 수 있을까

음성 대화형 UI는 여기에서 한 걸음 더 나아갑니다. 화면에서 입력창과 버튼을 찾아 명령을 구성하는 대신 사람에게 말하듯 요청하고 답변이 끝나기 전에 끼어들어 질문을 고치거나 방향을 바꿀 수 있습니다.

저도 최근 ChatGPT의 새 음성 대화를 쓰면서 그 편리함을 느꼈습니다. 응답 도중에 끼어들고, 생각을 정리하는 동안 기다리게 하면서 정해진 명령 문법보다 말의 흐름으로 컴퓨터를 만날 수 있었습니다.19

그러나 음성이 모든 상황과 모든 사용자에게 정답은 아닙니다. 공공장소에서 개인정보와 업무 내용을 소리 내어 말하기 어렵고, 소음이나 장애 특성 때문에 음성 사용이 맞지 않을 수도 있습니다. 철자와 수치, 코드와 표를 확인할 때에는 키보드와 점자, 구조화된 화면 탐색도 필요합니다. 음성은 선택지를 넓혀야지 또 하나의 유일한 문이 되어서는 안 됩니다.

무엇보다 말로 시켰다고 일이 끝나지 않습니다. 에이전트가 만든 문서와 코드, 표와 조사 결과를 검수하려면 사용자는 다시 결과물 안으로 들어가야 합니다. 필요한 부분을 찾고 변경 전후를 비교하는 탐색, 원문과 생성물을 대조하고 출처를 확인하는 검증이 이어집니다. 음성은 명령과 대화의 부담을 낮출 수 있지만, 결과를 검토하고 수정하고 책임지는 과정까지 대신하지는 못합니다.

따라서 음성 대화와 구조화된 탐색은 어느 하나를 고르는 대안이 아닙니다. 말로 요청하고 진행 상황을 들을 수 있으면서도, 대화 기록과 생성 결과를 제목과 목록, 표와 코드, 변경 사항 같은 단위로 다시 찾아갈 수 있어야 합니다. 편리한 AI의 기준은 ‘말만 하면 해 준다’가 아니라 말로 시작한 작업을 사용자가 끝까지 확인할 수 있게 하는가에 있습니다.

에이전트가 컴퓨터에 닿는 방식도 중요합니다. 화면의 픽셀이나 문서 구조를 읽는 대신 앱이 내놓은 도구와 API를 직접 부를 수도 있습니다. MCP와 에이전트 스킬은 이런 연결과 절차를 구조화합니다.20 WebMCP는 웹사이트의 기능을 에이전트가 호출할 수 있는 도구로 내놓게 합니다.21

지난 3월에 쓴 글에서 저는 WebMCP가 보조공학기술에도 곧바로 도움이 될 것이라 기대했습니다. 그러나 현재 WebMCP 설명 문서(Explainer)는 보조공학기술이나 접근성 트리를 위해 설계된 것은 아니며, 에이전트가 중간자로 행동하게 하는 기술이라고 설명합니다.21 기대는 남아 있지만 접근성이 덤으로 따라오는 길은 아니었습니다.

‘DOM에서 COM으로’는 이와 별개의 개념입니다. 4월 23일 세미나에서 가현욱 KAIST 교수가 제안한 ‘맥락 오브젝트 모델’로, 문서 기반 DOM이 아니라 맥락을 조직한 COM 트리를 보조공학기술이 순회하는 미래상을 가리킵니다.21

저도 에이전트가 웹 탐색의 부담을 덜 수 있는지 실제 작업에서 시험해 봤습니다. 지난 5월 9일 Hermes Agent Community Meetup @ Seoul에서 자연어로 브라우저 탐색을 요청하고 결과를 받아보는 과정을 시연했습니다.22 원하는 일에 더 빨리 닿을 수 있었지만 설정과 보안, 통제라는 새로운 장벽도 함께 확인했습니다.

다른 시각장애인의 기록에서도 비슷한 가능성과 한계가 보입니다. 대럴 힐리커는 Gemini로 접근성이 나쁜 날짜 선택기를 채우는 데 성공했지만, 대화상자가 닫히면서 초점이 흐트러졌다고 적었습니다. 작업 성공만으로는 충분하지 않고, 과정 내내 사용자가 초점과 통제권을 유지해야 한다는 사례입니다.23

그래서 AI가 접근성 없는 화면을 대신 조작하는 것과 그 화면 자체가 접근 가능해지는 것은 구분해야 합니다. AI 에이전트를 직접 다룬 자료는 아니지만, 비슷한 약속을 검증한 선례가 있습니다. 웹 접근성 오버레이도 코드를 고치지 않고 문제를 해결한다고 약속했지만, 장애인 당사자와 전문가들은 실제 장벽을 없애지 못한다고 지적해 왔습니다.24 에이전트가 잘못 읽거나 눌러도 사용자가 과정을 살필 수 없다면 장벽은 사라진 것이 아니라 보이지 않게 가려졌을 뿐입니다.

따라서 “AI 에이전트가 시각장애인의 UI가 될 수 있을까”라는 질문은 “AI가 화면을 대신 눌러 줄 수 있는가”보다 훨씬 넓습니다. 저는 이 여섯 가지를 기준으로 삼고 싶습니다.

  • 사용자의 의도를 정확히 이해하는가.
  • 하려는 행동과 그 결과를 사용자가 이해할 수 있게 설명하는가.
  • 실행 전 확인과 실행 중 진행 상황, 실행 뒤 결과를 분명히 돌려주는가.
  • 사용자가 작업의 일부를 직접 살피고 수정하고 되돌릴 수 있는가.
  • AI 없이도 원래 인터페이스에 접근할 수 있는가.
  • 잘못된 판단과 보안·개인정보 위험의 책임을 사용자에게만 떠넘기지 않는가.

이 조건을 갖춘다면 AI 에이전트는 화면 읽기 프로그램을 대체하기보다 그 위에 놓이는 새로운 층위의 인터페이스가 될 수 있습니다. 화면 읽기 프로그램이 컴퓨터의 구조를 사람에게 전달하고, 에이전트가 사람의 의도를 컴퓨터에 전달하며, 사용자는 그 사이에서 과정과 결과를 확인합니다. 중요한 것은 자동화의 화려함이 아니라 사용자가 통제권을 잃지 않은 채 일을 끝낼 수 있느냐입니다.

대화는 시작을 편하게 하고, 탐색은 결과를 확인하게 하며, 통제는 수정과 취소와 되돌리기를 가능하게 합니다. 셋 중 하나라도 끊기면 그것은 새로운 UI가 아니라 새로운 의존입니다.

마치며

화면 읽기 프로그램이 읽어야 했던 것은 시대마다 달라져 왔습니다. 처음에는 글자였다가 이후 객체와 상태, 문서의 구조와 관계를 거쳐 이제는 에이전트의 행동과 과정, 결과까지 그 범위가 실로 넓어졌습니다. 인터페이스가 바뀔 때마다 시각장애인은 새로운 탐색법을 배우고, 전달되지 않은 정보를 추측하고, 막힌 길을 우회해야 했습니다.

그 흐름의 끝에서 남는 감정은 기술에 대한 두려움이 아닙니다. 컴퓨터와 만나는 자리에서 나는 언제나 한 번 더 배우고, 추측하고, 확인해야 했다는 피로입니다. 명령줄에서는 밀려 올라간 출력을 되짚었고, GUI에서는 눌러도 되는 버튼인지 알 수 없었으며, TUI에서는 선과 기호가 길게 이어졌고, 태그 없는 PDF에서는 문단 순서를 머릿속에서 다시 조립했습니다. 이제 터미널에 들어온 AI 에이전트 앞에서는 무엇이 진행 표시이고 무엇이 결과인지부터 걸러내야 합니다.

그러나 이런 어려움 속에서 희망도 보았습니다. 닫힌 화면에 문을 내려고 표준을 세우고 API를 만들고 사용법을 익혀 온 사람들이 있었습니다. 저 알리도 같은 문제를 이슈에 남겼고, 다른 당사자들도 각자의 환경에서 문제를 기록하고 개선을 요구해 왔습니다. 이러한 제안이 실제 기능 개선으로 이어졌다고 단정할 수는 없으나 그렇게 쌓인 요구는 무엇을 고쳐야 하는지 드러내고, 닫힌 화면에 문을 낼 근거가 됩니다.

AI 에이전트가 시각장애인의 새로운 UI가 될 수 있을지는 아직 알 수 없습니다. 다만 기준은 분명합니다. AI 에이전트가 장벽을 보이지 않게 가리는 중간자에 머물지 않으려면, 사용자가 구조와 상태, 과정과 결과를 직접 확인할 수 있어야 합니다. 무엇을 하려는지 묻고, 무엇을 했는지 설명하며, 잘못했을 때 돌아갈 길도 열어 두어야 합니다. 무엇보다 사용자의 통제권을 지켜야 합니다.

접근성은 컴퓨터와 사용자가 만나는 자리에 나중에 덧붙이는 뒷문이 아닙니다. 누구나 자신에게 필요한 방식으로 일을 시작하고, 확인하고, 멈추고, 되돌아올 수 있게 하는 조건입니다. 저희 알리의 접근성 연구소는 에이전트 도구와 음성 인터페이스에서 반복되는 문제를 계속 기록하고 제보하겠습니다.

다음 주 화요일에 뵙겠습니다.

집필 아이디어를 주신 분들께 감사드립니다.

지난 22호가 화면 읽기 프로그램의 파편화를 서술하려다 보니 각 프로그램의 기능 설명을 위주로 글이 흘러 전체적으로 논지에 깊이가 부족한 감이 있었습니다. 그래서 실제 장애인 당사자가 어떤 점에서 불편함을 겪게 되는지를 좀 더 심도 있게 다루면 좋겠다는 피드백을 주신 분들이 계셨습니다. 아울러 본 원고의 집필 방향과 소재를 제공해 주신 고마운 분들도 계십니다. 앞으로도 여러분의 소중한 피드백을 경청하여 여러분에게 도움이 되는 글을 작성하도록 노력하겠습니다. 다시 한 번 피드백 주신 모든 분들께 감사드립니다.

Footnotes

  1. W3C의 Core Accessibility API Mappings 1.2는 사용자 에이전트가 웹 콘텐츠의 의미를 접근성 API에 어떻게 노출해야 하는지 규정합니다. 문서 요소에서 접근성 트리의 접근 가능 객체를 만들고 여기에 접근성 API별 상태와 속성을 채워 보조기술이 읽어 가게 하는 구조입니다. MSAA·UI Automation·ATK/AT-SPI·Android 접근성 API가 대상으로 명시돼 있습니다. 2026년 7월 2일 자 후보 권고 초안이며 갱신될 수 있습니다. ‘화면 읽기 프로그램이 DOM을 그대로 읽는다’는 단순화를 피하기 위한 근거로 인용했습니다. 함께 읽기: 제13호 ‘Android 접근성과 개발자 책임’. | W3C. Core Accessibility API Mappings 1.2., Microsoft. UI Automation. ↩ ↩2

  2. Apple은 VoiceOver를 음성과 점자로 화면을 설명하는 기능으로 소개하고, NVDA 사용자 안내도 점자 출력 설정을 별도로 다룹니다. 음성과 점자가 각각 흐름 파악과 정확한 표기 확인에 갖는 강점 비교는 이 문서들이 정량적으로 비교한 내용이 아니라, 필자를 포함한 사용자들의 일반적인 사용 방식에 대한 서술입니다. 함께 읽기: 제16호 ‘정보는 문자와 음성만으로 충분한가’, 제19호 ‘점사랑 7.0과 한소네 7’. | Apple. Accessibility Features: Vision., NV Access. NVDA User Guide. ↩

  3. W3C의 ‘장애인은 웹을 어떻게 이용하는가’는 시각장애인이 화면 읽기 프로그램으로 콘텐츠를 순차적으로 듣고 제목·링크 목록 등으로 탐색한다고 설명합니다. 이 문서는 이용 방식을 설명하는 자료이며 동시적 조망과 순차 탐색의 인지 비용 차이를 수치로 비교한 연구는 아닙니다. 본문의 비교는 그 차이를 설명하기 위한 필자의 서술입니다. | W3C WAI. How People with Disabilities Use the Web. ↩

  4. ECMA-48은 문자 코드 데이터 안에 삽입해 커서 이동·화면 지우기·표시 속성 등을 제어하는 기능과 그 표현을 정의합니다. DEC의 VT100은 이와 같은 ANSI 모드와 별도의 VT52 호환 모드를 지원한 비디오 터미널이므로, VT100과 ANSI·ECMA-48을 같은 규격으로 볼 수는 없습니다. 오늘날의 terminfo도 단말 기능을 기술하며 ANSI X3.64와 이를 계승한 ECMA-48의 이름과 의미를 따릅니다. 회전 표시기와 진행 막대는 이 계열의 제어 시퀀스뿐 아니라 캐리지 리턴·백스페이스·반복 출력으로도 구현할 수 있으므로, 본문은 ‘일부 TUI’로 범위를 한정했습니다. | Ecma International. ECMA-48., Digital Equipment Corporation. VT100 User Guide, Chapter 3., ncurses. terminfo(5). ↩

  5. 접근성 전문가 칼 그로브스는 2025년 9월 명령줄 인터페이스의 접근성을 다룬 글에서 회전 표시기·진행 막대·커서 이동 애니메이션이 VT100/ANSI 제어 시퀀스를 사용하며 보조기술 환경에서 제대로 표현되지 않고 음성 출력이 되풀이되는 상태로 이어질 수 있다고 지적했습니다. 아스키 아트와 표·테두리·색상 표시도 화면 읽기 프로그램의 해석을 방해한다고 봤습니다. 해법으로는 장식 요소를 끄는 플래그, 애니메이션 비활성화 옵션, NO_COLOR와 TERM=dumb 존중, JSON 등 구조화된 출력 제공, 이를 도움말에 명시할 것을 제시했습니다. 개인 전문가의 권고이며 공식 표준은 아닙니다. | Groves, K. (2025). Accessible by Design: Improving Command Line Interfaces for All Users., NO_COLOR. ↩ ↩2

  6. NO_COLOR는 지원하는 명령줄 프로그램에 기본 ANSI 색상 출력을 넣지 말라고 알리는 비공식 관례입니다. 굵게·밑줄·기울임이나 화면 갱신 전체를 끄는 설정은 아닙니다. TERM=dumb는 단말 기능이 매우 제한적임을 프로그램에 알리는 단말 유형입니다. TERM 값은 화면 지향 프로그램의 동작에 중요한 정보이므로 실제 단말과 맞아야 합니다. 두 설정 모두 프로그램이 인식할 때에만 효과가 있고, 모든 TUI를 자동으로 정적 출력으로 바꾸는 접근성 모드는 아닙니다. | NO_COLOR., ncurses. term(7)., ncurses. terminfo(5). ↩

  7. 화면 읽기 프로그램에는 앱이 접근성 API로 내놓지 않은 정보를 보완하는 수단이 있기는 합니다. NVDA는 접근하기 어려운 앱이나 작성자가 충분한 정보를 제공하지 않은 이미지에 Windows OCR을 사용할 수 있다고 안내하고, JAWS는 응용 프로그램별 스크립트로 특정 앱의 정보를 별도로 처리합니다. 그러나 OCR·이미지 설명·앱별 스크립트는 화면을 추정하거나 별도 처리를 덧붙이는 우회 수단입니다. Apple은 VoiceOver가 기본으로 인식하지 못하는 사용자 정의 요소에 접근성 정보와 accessibilityLabel을 추가하라고 안내하고, Android도 각 UI 요소의 목적을 contentDescription과 역할 정보로 제공하라고 권고합니다. 이런 정보를 앱이 직접 제공하는 것이 객체의 이름·역할·상태를 안정적으로 전달하는 기본 경로입니다. | NV Access. NVDA User Guide: Content Recognition., Freedom Scientific. JAWS Scripts and Script Files., Apple. Supporting VoiceOver in your app., Android Developers. Make apps more accessible. ↩

  8. Windows 3.0·3.1 시기 outSPOKEN 개발진은 Windows의 텍스트 렌더링 호출을 패치하고 화면 내용을 별도의 오프스크린 모델로 재구성했습니다. T. V. Raman도 GUI 음성 접근 시스템 개발 노력의 상당 부분이 견고한 오프스크린 모델 구축에 들어갔다고 설명했습니다. 당시 제품의 안정성 문제도 컸습니다. JAWS 개발자 Ted Henter는 1995년 무렵 ‘두어 시간보다 오래 버티는 버전’이라고 릴리스 노트에 적을 정도로 충돌이 잦았다고 회고했습니다. 국내에서도 센스리더 공식 업그레이드 기록에 비디오 드라이버 메모리 문제, 디스플레이 드라이버 설치 문제, 사용자 전환 시 블루스크린과 프로그램 멈춤 수정 내역이 남아 있습니다. 제작사는 2025년 센스리더 8.7부터 읽기커서용 Windows 커널 보조디스플레이 드라이버를 소프트웨어 방식으로 바꿨다고 밝혔습니다. 필자는 실로암보이스와 EVE for Windows를 사용할 때에도 잦은 불안정성을 겪었습니다. MSAA는 Windows 95용 플랫폼 추가 기능으로 도입됐고, 이후 UI Automation이 그 한계를 보완했습니다. | Korn, P. (2022). Reflections on 30 years in the Accessibility Field., Raman, T. V. (1995). Emacspeak—A Speech Interface., American Foundation for the Blind. Interview with Ted Henter, Part 4., Microsoft. Accessibility and automation for Windows developers., 엑스비전테크놀로지. 센스리더 업그레이드 정보., 엑스비전테크놀로지. 센스리더 8.7 보조디스플레이 지원 변경 안내. ↩

  9. Apple 안내에 따르면 iPhone에서는 화면을 손가락으로 훑어 닿은 항목을 읽고, 좌우로 쓸어 항목을 순차 이동하며, 두 번 탭해 실행합니다. 로터로 탐색 단위와 말하기 속도를 바꿉니다. Google도 TalkBack의 읽기 제어로 탐색 단위를 바꾸는 방법을 안내합니다. 같은 VoiceOver라도 Mac의 키보드·그룹 탐색과 모바일의 터치 제스처는 서로 다른 숙련을 요구합니다. 함께 읽기: 제13호 ‘삼성 One UI와 TalkBack’, 제22호 ‘운영체제에 들어온 접근성’. | Apple Support. Use VoiceOver gestures on iPhone., Apple Support. VoiceOver rotor., Google. Use TalkBack reading controls. ↩

  10. NVDA 사용자 안내는 브라우즈 모드에서 제목·랜드마크·폼 요소로 빠르게 이동하고 요소 목록을 여는 기능을 설명합니다. W3C의 ARIA Authoring Practices Guide는 ARIA가 역할·이름·상태·관계를 접근성 API로 전달하는 약속이며 잘못 쓴 ARIA는 없는 것보다 나쁠 수 있다고 밝힙니다. 문서에 기능이 있다는 사실과 모든 조합에서의 상호운용성은 구분해야 합니다. 함께 읽기: 제3호 ‘단순 TTS와 접근성 뷰어의 차이’. | NV Access. NVDA User Guide., W3C WAI. ARIA Authoring Practices Guide: Read Me First. ↩

  11. W3C의 WCAG 2.2 PDF 기술은 PDF 문서에서 제목을 구조 트리의 제목 요소로 표시해야 보조기술이 인식하고, 사용자가 제목 목록에 접근해 원하는 제목으로 바로 이동할 수 있다고 설명합니다. 읽기 순서와 표·목록에 관한 기술도 함께 제공됩니다. 화면에 글자가 크게 보이는 것과 구조 태그가 있는 것은 다른 상태라는 근거로 인용했습니다. 함께 읽기: 제10호 ‘PDF를 태그 PDF로 바꾸는 AI’. | W3C WAI. WCAG 2.2 Techniques for PDF., W3C WAI. PDF9: Providing headings by marking content with heading tags. ↩

  12. Electron 공식 문서는 Electron이 웹과 같은 접근성 원칙을 따르며 Chromium의 접근성 트리를 운영체제 API에 노출한다고 설명합니다. VS Code는 NVDA·JAWS·VoiceOver를 시험 조합으로 명시하고 편집기·터미널·채팅이 서로 다른 표면임을 전제로 안내합니다. 이는 기반 기술과 개별 앱의 안내에 관한 자료이며 각 앱의 접근성을 보증하지 않습니다. 이번 호에서도 이들 앱을 직접 시험하지 않았습니다. 함께 읽기: 제22호 ‘하나만 배워서는 부족한 세계’. | Electron. Accessibility., Visual Studio Code. Accessibility. ↩

  13. WebAIM의 열 번째 화면 읽기 프로그램 사용자 조사는 1,539명의 유효 응답을 분석했고, 데스크톱·노트북 사용자 중 71.6%가 둘 이상의 화면 읽기 프로그램을 쓴다고 답했습니다. 비통제 표본이며 북미·유럽 응답 비중이 높고 아시아 응답은 6.4%입니다. 한국 사용자 통계로 일반화하지 않습니다. | WebAIM. (2024). Screen Reader User Survey #10 Results. ↩

  14. Hermes Agent는 Nous Research가 개발하고 공개 저장소에서 배포하는 오픈소스 자율형 AI 에이전트입니다. 공식 문서는 경험을 기억과 스킬로 축적하는 학습 루프를 주요 특징으로 소개합니다. 터미널에서는 기본 hermes 명령으로 실행하는 고전적인 prompt_toolkit CLI와 hermes --tui로 실행하는 현대적인 TUI를 제공합니다. 후자는 모달 오버레이, 마우스 선택, 비차단 입력 등을 갖춘 별도의 인터페이스입니다. | Hermes Agent 공식 문서., Hermes Agent CLI Interface., NousResearch/hermes-agent. ↩

  15. 필자는 2026년 6월 Hermes Agent의 화면 읽기 프로그램 접근성 논의인 26689에 저시력 당사자이자 macOS 화면 읽기 프로그램 사용자 관점의 의견을 보탰습니다. 기존 CLI보다 현대적인 TUI에서 대체 화면, 실시간 패널, 모달 창, 상태 표시줄 갱신과 애니메이션이 더 큰 잡음을 만들 수 있다고 설명하고, 안정적이고 선형적이며 스크롤백을 보존하는 화면 읽기 프로그램 모드를 제안했습니다. 이어 Desktop/Electron UI의 DOM·접근성 트리·axe-core 점검 결과를 38072에, 승인 내용의 일부가 가려지고 전문을 승인 화면에서 확인할 수 없는 문제를 38581과 38582에 직접 제보했습니다. Claude Code와 Gemini CLI 저장소에도 화면 읽기 프로그램 모드, ANSI 서식 제거, 상태 안내를 요구하는 이슈가 공개돼 있습니다. 이슈 트래커의 글은 당사자의 사용 경험과 요구를 보여 주지만 제조사의 공식 시험 결과는 아닙니다. | NousResearch/hermes-agent. Issue #26689., Issue #38072., Issue #38581., Issue #38582., anthropics/claude-code. Issue #11002., Issue #15509., Issue #70425., google-gemini/gemini-cli. Issue #5148. ↩ ↩2

  16. Claude Code 공식 문서는 화면 읽기 프로그램 모드가 시각적 터미널 인터페이스를 평평한 선형 텍스트로 바꾼다고 설명합니다. --ax-screen-reader 플래그, CLAUDE_AX_SCREEN_READER 환경 변수, axScreenReader 설정으로 켤 수 있고 v2.1.181 이상이 필요합니다. 상자 문자와 색상만의 단서를 쓰지 않고, 바뀌지 않은 내용을 다시 그리지 않으며, 회전 표시기를 정적 텍스트로 표시하고, 표를 ‘머리글: 값’ 문장으로 읽습니다. 각 메시지에는 you:·claude:·tool:·tool error:·error:·Permission Required:·Cost: 이름표가 붙고 스크롤백 검색으로 찾아갈 수 있습니다. 화살표 키로 움직이던 메뉴와 권한 승인 창은 번호가 붙은 목록이 되며 유효한 범위를 안내합니다. OSC 133 셸 통합 표시로 턴 사이를 건너뛸 수 있고, 답변 완료·권한 요청·5초 이상 걸린 도구 완료 시 터미널 알림음이 울립니다. 문서가 밝힌 한계도 함께 봐야 합니다. 이 모드는 화면 읽기 프로그램이 실행 중이어도 자동으로 켜지지 않고, Shift+Tab 이외의 방법으로 바꾼 권한 모드 변경은 안내하지 않으며, 배경 세션에 붙으면 스크롤백이 없는 대체 화면으로 들어갑니다. 이번 호에서는 이 문서의 내용을 인용했을 뿐 각 항목을 국내 환경에서 직접 시험하지는 않았습니다. | Claude Code. Use Claude Code with a screen reader. ↩

  17. Gemini CLI 저장소에는 아스키 아트를 제거해 화면 읽기 프로그램 잡음을 줄이는 모드를 추가한 풀 리퀘스트와, 화면 읽기 프로그램 사용자를 위한 접근성 개선 요구 및 피드백 이슈가 공개돼 있습니다. 다만 이번 조사에서 확인한 것은 저장소의 이슈와 변경 제안이며 현재 배포판의 기본 동작이나 완성도를 확인한 것은 아닙니다. | google-gemini/gemini-cli. Issue #5148., google-gemini/gemini-cli. Issue #4155., google-gemini/gemini-cli. PR #3424. ↩

  18. W3C는 사용자의 초점을 옮기지 않고 진행·성공·오류 같은 상태 변화를 보조기술에 전달해야 한다고 설명하며 role="status"와 live region 사용 예를 제시합니다. 다만 AI 응답 스트리밍의 적절한 낭독 빈도를 정한 문서는 아니므로 과잉 낭독과 완료 미고지 사이의 균형은 실제 사용자 시험으로 확인해야 합니다. 본문에서 언급한 웹 앱형 에이전트의 문제들은 이번 호에서 특정 서비스를 계정별로 시험해 확인한 결과가 아니라, 제22호까지의 조사와 필자의 사용 경험에 근거한 서술입니다. 함께 읽기: 제22호 ‘화면을 읽는다는 것’. | W3C WAI. Understanding Success Criterion 4.1.3: Status Messages. ↩

  19. OpenAI는 2026년 7월 GPT-Live를 소개하며 듣기와 말하기를 동시에 수행하는 전이중형 음성 대화를 설명했습니다. 응답 도중 끼어들거나 사용자가 잠시 생각을 정리하는 동안 기다릴 수 있으며, 겹치는 발화와 주변 소음·네트워크·마이크 설정은 인식에 영향을 줄 수 있다고 안내합니다. 이번 검토에서 OpenAI 공식 발표와 도움말을 직접 확인했습니다. 다만 기능 제공 범위는 요금제와 배포 상태에 따라 달라질 수 있습니다. 본문의 ‘편했다’는 평가는 필자의 사용 경험이며 화면 읽기 프로그램 접근성에 대한 시험 결과가 아닙니다. | OpenAI. Introducing GPT-Live., OpenAI Help Center. ChatGPT Voice. ↩

  20. MCP는 AI 애플리케이션을 외부 도구·데이터와 연결하는 공개 표준으로, 공식 문서는 이를 ‘AI 애플리케이션을 위한 USB-C 포트’에 비유합니다. 에이전트 스킬은 지시문·스크립트·참고 자료를 담은 폴더를 필요할 때만 불러 쓰게 하는 방식으로, 최소한 이름과 설명을 담은 SKILL.md 파일을 중심으로 구성됩니다. 두 방식 모두 에이전트가 할 수 있는 일을 넓히지만, 그만큼 어떤 권한이 어디까지 열리는지도 함께 봐야 합니다. | Model Context Protocol. Introduction., anthropics/skills. Public repository for Agent Skills. ↩

  21. WebMCP 설명 문서는 웹 개발자가 JavaScript 함수나 HTML <form> 요소를 자연어 설명과 구조화된 스키마를 갖춘 ‘도구’로 노출하게 하는 기술이라고 밝힙니다. API는 document.modelContext이며 registerTool()로 도구를 등록합니다. 접근성에 대해서는 다음과 같이 명시합니다. “WebMCP 자체는 보조기술이 읽어 가도록 설계되지 않았고, 페이지의 접근성 트리와 직접 상호작용하도록 설계되지도 않았다. 다만 에이전트가 매우 유능한 중간자로 행동할 수 있게 한다.” Chrome은 이 기능을 사전 체험판 참가자에게 제공하고 있다고 안내합니다. 한편 ‘DOM에서 COM으로’와 ‘맥락 오브젝트 모델’은 2026년 4월 23일 ‘모두를 위한 AI Accessibility 추진 방안 마련을 위한 세미나’에서 가현욱 KAIST 교수가 발표한 개념입니다. 여기서 COM은 Microsoft의 Component Object Model이나 WebMCP의 공식 용어가 아닙니다. 세부 설명은 필자의 현장 메모에 근거하며, 이번 검토에서는 공개 표준이나 구현 API를 확인하지 못했습니다. 필자가 2026년 3월 블로그 글에서 인용했던 WebMCP 문장은 초기 저장소의 다른 표현이었으며, 현재 설명 문서의 서술과 함께 읽어야 합니다. 함께 읽기: WebMCP - 웹 접근성의 판도를 바꿀 기술. | webmachinelearning/webmcp. WebMCP Explainer., Chrome for Developers. WebMCP를 사전 체험판으로 이용할 수 있습니다., 모두를 위한 AI Accessibility 추진 방안 마련을 위한 세미나., 에이블뉴스. ‘모두를 위한 AI Accessibility 추진 방안 마련 세미나’ 23일 개최. ↩ ↩2 ↩3

  22. Hermes Agent Community Meetup @ Seoul은 2026년 5월 9일 서울에서 열린 커뮤니티 행사입니다. 필자는 ‘듣는 웹에서 협업하는 웹으로: 시각장애인의 Hermes Agentic Browsing 활용’을 발표했습니다. 행사 후기는 화면 읽기 프로그램으로 웹 요소를 하나씩 찾는 과정과 Hermes Agent를 이용한 쿠팡 선물 탐색 시연을 기록했고, 공개 영상 자막을 바탕으로 한 별도 현장 정리는 CDP와 브라우저 자동화를 이용한 흐름, macOS와 Windows·WSL의 설정 차이, 연결과 보안 문제를 정리했습니다. 함께 읽기: 제2호 ‘Agentic AI 시대의 인터페이스 전환’. | Hermes Agent Community Meetup @ Seoul., 행사 전체 영상., Automata. (2026.5.14.). ‘듣는 웹에서 협업하는 웹으로’., Hermes Agent Seoul Meetup 현장 정리. ↩

  23. Blind Access Journal의 대럴 힐리커는 2026년 3월 10일 글에서 Gemini의 자동 탐색 기능으로 접근성이 나쁜 날짜 선택기를 채우는 과정을 기록했습니다. 에이전트가 실시간으로 진행 상황을 알려 주고 ‘작업 넘겨받기’ 버튼으로 사용자 통제권을 유지한 점을 긍정적으로 평가했지만, 대화상자가 예기치 않게 닫히면서 페이지를 다시 불러와야 했고 그 맥락 전환이 초점 관리에 의존하는 화면 읽기 프로그램 사용자에게 혼란스러웠다고 적었습니다. 그는 “작업을 올바르게 끝내는 것만으로는 충분하지 않고, AI는 그 과정 내내 일관된 초점 환경을 유지해야 한다”고 썼습니다. 한 사람의 사용 기록이므로 모든 사용자와 모든 사이트로 일반화하지 않습니다. 함께 읽기: 제16호 ‘AI는 벽이 아니라 문일지도’. | Hilliker, D. (2026). Beyond the Screen Reader: Can Gemini’s AI Agent “Accessify” the Web? ↩

  24. Overlay Fact Sheet는 접근성 전문가와 장애 당사자, 관련 단체가 함께 서명해 온 문서로, 웹 접근성 오버레이가 사이트의 접근성 문제를 실제로 고치지 못한다는 점을 정리합니다. 이 문서는 오버레이에 관한 것이며 AI 에이전트를 직접 다루지 않습니다. 본문에서는 ‘코드를 고치지 않고 사후에 해결해 준다’는 약속을 어떻게 검증해야 하는지에 관한 선례로 인용했습니다. 함께 읽기: 제13호 ‘AI는 접근성 만능 해결사인가’, 제16호 ‘당사자 없이 설계된 기술의 위험’. | Overlay Fact Sheet. ↩

그래프 뷰

백링크