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

방문자 카운터

접근성 브리핑 제31호

78 min read

들어가며

지난 호에서 시작은 열려 있는데 중간 어딘가에서 끊어진 길을 따라가 보았습니다. 결제 버튼에 닿지 않는 초점, 사진을 첨부해야 접수되는 신고서, 이유를 알려 주지 않는 배차 결과. 끊어진 자리에서 당사자는 늘 누군가를 불러 사정을 설명하고 기다렸습니다.

그런데 요즘 제 책상 위에서는 조금 다른 장면이 펼쳐지고 있습니다. 누군가를 부르는 대신, 해야 할 일을 말로 맡깁니다. 화면을 하나씩 더듬어 길을 찾는 대신, 무언가(혹은 누군가?)에게 필요한 일을 맡기고 심부름할 곳을 알려 줍니다. 몇 해 전만 해도 상상 속의 이야기였던 일이 이제는 하루의 일과가 되었습니다.

이 변화는 반가운 만큼 우리에게 화두를 던집니다. 심부름을 해 주는 존재에게 우리는 무엇을 맡겨도 될까요? 그리고 그 존재가 걸어간 길을, 우리는 끝까지 확인할 수 있을까요?

이번 접근성 브리핑은 우리 집에 들어온 AI 에이전트 이야기에서 출발해, 그 에이전트가 시각장애인의 디지털 생활에 어떤 자리를 차지할 수 있는지 차례로 짚어 봅니다.

일을 맡길 수 있는 AI는 시각장애인의 접근성을 얼마나 넓혀 줄 수 있을까요?

제31호 - 2026년 9월 29일(화)

브리핑 1. 우리 집에 에르메스가 들어온 날 — AI에 손이 생기다

2025년 11월, 남들보다 먼저 인공지능 관련 제품을 사용해 보는 얼리어답터들이 술렁이기 시작합니다. 한 개발자가 취미로 끄적거려 내놓은 Clawdbot은1 광풍을 몰고 왔습니다. 2025년 2월에 출시된 Claude Code가2 개발자들이 사용하는 도구였다면 Clawdbot은 메신저와 연결해서 내 컴퓨터에 있는 파일과 폴더를 직접 조작하는 인공지능 도구입니다. 폴더를 정리하고 보고서를 작성하고 발표 자료도 만들어 내는 이 신기한 친구에게 사람들은 ‘인공지능 에이전트’(AI Agent)라는 이름을 붙여 부르기 시작합니다. 여태까지 우리가 AI에게 질문을 던지면 AI는 대답을 해 주는 ‘챗봇’3 형태였다면 ‘인공지능 에이전트’는 AI에게 손을 만든 다음 도구를 쥐여 준 셈입니다. 엄청난 성장을 지켜본 Claude Code 개발사는 ‘Clawdbot’이 ‘Claude’와 발음이 비슷하다는 이유로 이름을 바꿔 달라고 요청했고 우여곡절 끝에 Clawdbot은 “OpenClaw”라는 이름을 갖게 됩니다.4

입소문을 들은 비개발자들도 하나둘씩 OpenClaw를 사용하면서 여기저기서 보안 사고가 속출하기 시작합니다.5 사실 저도 이즈음에 AI 에이전트를 써 보고 싶었지만 내 민감한 데이터를 맡기기에 OpenClaw는 믿음직하지 못했습니다. 그러던 차에 2026년 4월 9일, 저는 “에르메스”라는 멋진 이름의 AI 에이전트를 만나게 되었습니다.6 개발자 한 사람이 취미로 만든 프로그램이 아니라 어엿한 인공지능 연구소가 처음부터 작정하고 만든 프로그램이었습니다. 사용하면 사용할수록 사용자의 선호를 기억하고 실수에서 배우며 스스로 진화하는 데다 명품의 이름까지 가졌으니, ‘Hermes’는 제 마음을 사로잡기에 충분했습니다.7

마침 알리의 접근성 연구소를 개소한 뒤 혼자 이것저것 손이 바쁜 저는 Hermes에게 조금씩 일을 맡기기 시작했습니다. 아침마다 전날 처리 못 한 이메일 정리하기, 접근성 관련 국내외 뉴스 기사 스크랩하기, 시각장애인 통신망 넓은마을의 공지사항 검토하기 등 규칙이 정해져 있고 매일 반복되는 일부터였습니다. 반년 가까이 함께 일한 지금, Hermes는 제가 좋아하는 것, 제가 하는 업무, 그리고 제가 지금까지 작업한 산출물까지 기억하고 열심히 저를 도와주는 비서가 되었습니다.

브리핑 2. 화면을 찾는 일에서 작업을 끝내는 일로 — AI 에이전트의 진가

저 알리는 지난 9월 28일 저녁, 서울 강남의 AWS Korea에서 Dev Korea가 연 ‘Accessibility, live’ 행사에 발표자로 섰습니다. 시각장애인과 저시력인이 앱과 웹, AI 도구를 실제로 어떻게 쓰는지 개발자들 앞에서 보여 주는 자리였습니다. 제 발표 제목은 「듣는 웹에서 협업하는 웹으로: 시각장애인을 위한 에이전틱 브라우징」이었습니다.8

‘듣는 웹’은 우리 화면 읽기 프로그램 사용자가 매일 겪는 웹입니다. 화면 읽기 프로그램은 접근성 트리라는 구조를 통해 웹의 내용을 한 줄씩 들려줍니다. 눈으로 보는 사람은 화면을 한눈에 훑고 필요한 곳으로 바로 갑니다. 우리는 앞에서부터 차례로 듣거나, 제목과 링크를 하나씩 건너뛰며 지금 내가 어디쯤 있는지 머릿속에 지도를 그려야 합니다. 요소가 많을수록 지도는 복잡해지고 대체 텍스트가 빈약하거나 ARIA가 잘못 쓰인 곳에서는 지도가 아예 끊어집니다. 그러다 보면 정작 하려던 일보다 사용자 인터페이스에서 길을 찾는 데 더 많은 시간을 씁니다.

이것은 비단 프로그램만의 이야기가 아닙니다. 문서도 마찬가지입니다. 양식을 작성할 때에는 복잡한 표에 내용을 채워야 하고, 어떤 공문서는 글꼴과 글자 크기, 용지 여백까지 맞춰야 합니다. 여기에는 두 겹의 수고가 있습니다. 하나는 표 안에서 어느 칸에 무엇을 채워야 하는지 찾아 셀 사이를 오가며 내용을 채우는 수고이고, 다른 하나는 눈에 보이는 모양을 규정에 맞추고 제대로 맞았는지 확인하는 수고입니다. 화면 읽기 프로그램은 글자는 읽어 주지만, 그 글자가 몇 포인트인지, 여백이 몇 센티미터인지는 단축키를 사용하거나 대화상자를 하나하나 열어 봐야 겨우 알 수 있습니다. 제22호에서 고백했듯 아래아한글의 글자 모양 대화상자는 ‘기준 크기’라는 이름만 들려주고 그 안의 값은 들려주지 않을 때가 있습니다. 그러면 결국 다른 사람에게 문서를 확인해 달라고 부탁하게 됩니다. WebAIM의 2026년 조사에서도 응답자의 85.6%가 PDF 문서가 자신에게 중대한 접근성 문제를 일으킬 가능성이 높다고 답했습니다.9

최근에 저도 이 수고를 단단히 치렀습니다. 장애인기업종합지원센터의 「1인 중증장애인기업 보조공학기기 지원사업」 신청을 검토하면서였습니다. 이 일을 웹 탐색만으로 하려면 길이 꽤 멉니다. 먼저 검색 엔진에서 기관 이름을 찾아 누리집에 들어갑니다. 메뉴를 하나씩 내려가며 공고가 있을 만한 게시판을 찾고 게시판 안에서 다시 사업 이름을 검색합니다. 목록에서 맞는 공고를 골라 본문으로 들어가 내용을 확인하고 마지막으로 첨부 파일을 하나씩 내려받습니다. 화면 읽기 프로그램으로는 단계를 넘어갈 때마다 바뀐 화면의 메뉴와 링크, 게시판 목록을 다시 들으며 지금 내가 어디에 있는지부터 확인해야 합니다. 정작 하려던 일은 사업 내용을 읽고 신청할지 판단하는 것인데, 거기까지 가는 데 힘을 다 쓰기 일쑤입니다.

이번에는 그 길을 Hermes에게 맡겼습니다. Hermes는 기관 누리집의 사업공고 게시판에서 ‘보조공학’으로 검색해 9월 18일에 올라온 2차 모집 공고를 찾았고, 첨부 파일 네 개를 모두 내려받은 뒤 공고문과 자주 묻는 질문의 자격 조건과 서류 목록을 대조해 정리해 주었습니다. 저는 메뉴를 더듬는 대신, 정리된 결과를 읽고 제가 신청 대상이 되는지, 무엇을 준비해야 하는지를 판단하는 데 집중할 수 있었습니다. 화면을 탐색하는 일은 Hermes가 맡고, 사람은 일 자체에 집중하게 된 것입니다.

그래도 남은 수고가 있었습니다. 내려받은 신청서에는 기기마다 품목, 제품명, 활용계획, 지원금과 자부담, 부가세와 총액을 표에 나눠 적어야 했고, 챙겨야 할 증빙 서류도 열 가지가 넘었습니다.10 중증장애인이 쓸 보조공학기기를 지원하는 사업인데, 신청 양식부터가 시각장애인이 작성하기에는 만만치 않아서 꽤 많은 공수가 들었습니다.

양식을 채우는 일 자체를 에이전트와 나눠 보는 실험도 해 보았습니다. 지난 8월 한국시각장애교육재활학회에서는 시각장애 교사인 김헌용 선생님과 함께, 선생님이 직접 만든 hwpx-automation 스킬로 시연을 했습니다. 학교에 도착한 공문을 읽고 그 내용을 바탕으로 겸직허가신청서를 채우는 실험이었습니다.11 저는 따로 한국어 문서를 다루는 도구인 kordoc을 이용해 ‘정보통신보조기기 지원 신청서’를 모의로 채워 보기도 했습니다.12 칸을 찾아 헤매는 일은 에이전트가 맡고, 저는 무엇을 적을지 정하고 결과를 확인하는 일을 맡는 방식입니다.

발표에서 ‘협업하는 웹’이라고 부른 것이 바로 이 장면입니다. 에이전트는 사용자 인터페이스를 탐색하고 조작합니다. 사용자는 목표를 정하고, 판단하고, 승인하고, 결과를 검토합니다. 화면 읽기 프로그램이 ‘화면을 읽어 주는 도구’였다면, 에이전트는 ‘화면을 건너뛰고 일을 끝내 주는 도구’에 가깝습니다. 시각장애인에게 이 차이는 작지 않습니다. 하루 중 길을 찾느라 쓰던 시간을 일 자체에 돌려쓸 수 있기 때문입니다.

물론 아직 한계도 분명합니다. 에이전트를 쓰려면 필요한 도구를 설치하고 설정해야 하고, 그 과정 자체가 또 하나의 문턱입니다. 에이전트가 로그인 세션과 입력 중인 정보에 닿는다는 것은 그만큼 보안 위험을 짊어진다는 뜻이기도 합니다. 무엇보다 지금의 웹은 에이전트를 고려하지 않고 만들어졌습니다. CAPTCHA와13 봇 탐지가 길을 막고, 수시로 바뀌는 화면 구조와 팝업이 에이전트를 헤매게 하며, 이름 없는 버튼과 부실한 접근성 트리는 에이전트에게도 정보를 주지 않습니다.8

그렇다고 에이전트가 접근성이 나쁜 웹을 대신해 주지는 못합니다. 에이전트도 결국 웹 페이지의 구조와 접근성 트리를 읽고 움직이기 때문입니다. 레이블 없는 입력란, 글자 대신 이미지로만 올린 공고문, 마우스로만 열리는 메뉴를 만나면 에이전트도 우리처럼 헤맵니다. 다른 점은 헤매는 방식입니다. 에이전트는 화면을 캡처해 다시 들여다보고 이 버튼일까 저 링크일까 추론합니다. 실패하면 같은 조작을 몇 번이고 되풀이합니다. 그 하나하나가 모두 토큰입니다.14 접근성이 나쁜 웹일수록 에이전트는 더 많은 토큰을 쓰고 더 오래 걸리며 그만큼 엉뚱한 곳을 누를 가능성도 커집니다. 사람의 수고가 사라지는 것이 아니라 비용과 오류의 위험으로 모양만 바꾸는 셈입니다.

이런 반복 탐색을 줄이는 방법으로 지난 블로그 글에서 소개한 WebMCP가 있습니다. 웹사이트가 수행 가능한 작업을 에이전트에게 도구로 내놓는 방식입니다.15 앞서 본 지원사업 누리집에 적용한다면, 에이전트는 공고 검색 도구에 사업 이름을 전달하고 사용자는 검색 결과를 보고 신청 조건을 판단하는 식으로 일을 나눌 수 있을 것입니다.16 OpenAI가 8월 말부터 9월 초까지 연 ‘WebMCP Challenge’도 사람과 에이전트가 함께 쓰는 웹앱을 모집했습니다. 이런 역할 분담을 실제 앱으로 만들어 보는 시도입니다.17

다만 제23호에서 짚었듯, 에이전트가 기능을 호출할 수 있어도 사용자가 결과를 직접 읽고 확인할 화면은 필요합니다.18 신청이나 결제를 승인할 때도 마찬가지입니다. 에이전트가 실행할 방법과 사람이 확인하고 조작할 방법을 함께 마련해야 합니다.

그래서 결론은 다시 접근성으로 돌아옵니다. 명확한 레이블, 의미 있는 구조, 조작할 수 있는 요소는 화면 읽기 프로그램 사용자에게도, AI 에이전트에게도 똑같이 필요합니다. 사람이 메뉴에서 덜 헤매게 하는 구조가 에이전트의 추론과 반복도 줄여 줍니다. 접근성이 높은 웹은 에이전트도 쓰기 좋은 웹입니다. 그리고 에이전트가 서식을 다 맞췄다고 보고했을 때, 그 결과가 정말 맞는지 내가 직접 확인할 길도 여전히 필요합니다.

브리핑 3. Grok Bot, Muse, dots — 성큼 다가온 ‘일을 맡기는 AI’

이제 AI 에이전트는 소수의 얼리어답터가 사용하는 신문물에서 대중으로 내려오고 있습니다. 와이파이, LTE, LLM 같은 기술 용어가 더는 기술자들만의 전유물이 아닌 것처럼, AI 기업들은 앞다투어 누구나 쓸 수 있는 AI 에이전트를 내놓고 있습니다. 지난 8월부터 세 개의 이름이 연이어 등장했습니다.

가장 먼저 나온 것은 SpaceXAI의 Grok Bot입니다. 8월 11일 베타로 공개된 Grok Bot은 스스로를 ‘항상 켜져 있는 에이전트 팀’이라고 소개합니다. 클라우드에 자기 컴퓨터를 두고 사용자가 쓰는 앱과 받은편지함, 웹사이트에 로그인해 일을 끝까지 처리한 뒤 “승인이 필요할 때만 돌아온다”고 설명합니다.19

9월 8일에는 Meta가 Muse를 미국에서 출시했습니다. 로이터는 Muse가 OpenClaw를 모델로 만들어졌다고 전했습니다. 브리핑 1에서 소개한 그 OpenClaw가 이제 수십억 명이 쓰는 메신저 회사의 제품으로 다시 태어난 셈입니다. Meta는 Muse가 사람마다 전용 클라우드 가상 컴퓨터에서 실행되고, 별도의 감시 에이전트가 승인하지 않으면 어떤 행동도 인터넷에 닿지 않으며, 이메일 발송이나 결제 같은 민감한 행동 전에는 반드시 사용자에게 확인한다고 밝혔습니다. 결제는 일회용 카드로 처리해 실제 카드 정보가 에이전트에게 노출되지 않게 한다고 합니다.20

그리고 9월 29일, OpenAI가 dots를 발표했습니다. OpenAI의 dots도 자기 클라우드 컴퓨터와 브라우저를 갖고 4,000개가 넘는 앱에 연결해 일합니다. 사용자의 노트북은 사용자가 연결을 허락할 때만 쓰고, 저장된 비밀번호는 모델에게 보여 주지 않은 채 로그인에 사용합니다. 사용자가 자리를 비운 사이에 하는 ‘선제 조사’는 읽기 전용 도구로만 하고, 계정에 영향을 주는 행동은 자동 검토를 거쳐 그대로 진행할지, 승인을 받을지, 사용자에게 넘길지 나눕니다. 사용자는 규칙을 직접 정해 특정 행동을 허용하거나 막을 수 있고 진행 상황을 활동 화면에서 확인할 수 있습니다.21

세 제품은 서로 다른 회사에서 나왔지만 닮은 점이 많습니다. 모두 사용자의 기기가 아닌 클라우드의 전용 컴퓨터에서 일하고, 메신저처럼 말을 걸어 일을 맡기며, 사용자가 자리를 비워도 일을 계속하고, 민감한 일 앞에서만 승인을 구한다고 말합니다. 이제 진정 AI는 ‘질문하는 AI’에서 ‘일을 맡기는 AI’가 되고 있습니다.

다만 일을 맡길 수 있다는 약속과 실제로 일을 마치는 것 사이에는 간격이 남아 있습니다. CNN 기자는 Muse에게 데이트 장소를 찾아 달라고 했더니 몇 년 전에 문을 닫은 식당 두 곳을 추천받았다고 전했습니다. 아마존은 Muse의 쇼핑몰 탐색을 막았고, 타깃은 결제 단계에서 자동 클릭을 차단해 기자가 개인정보를 직접 입력해야 했습니다.22 제30호에서 시각장애인을 가로막았던 결제 화면이 이번에는 AI 에이전트를 가로막은 셈입니다.

이 흐름은 시각장애인에게 두 가지 얼굴로 다가옵니다. 하나는 문턱이 낮아진다는 것입니다. 브리핑 2에서 말한 설치와 설정의 수고 없이, 이미 쓰는 메신저 앱에서 에이전트를 부를 수 있다면 더 많은 시각장애인이 ‘협업하는 웹’에 들어올 수 있습니다. 다른 하나는 새로운 화면이 생긴다는 것입니다. 승인을 구하는 알림, 활동 기록, 규칙 설정 화면, 결제 확인 창 등이 그러합니다. 에이전트가 우리 대신 화면을 건너뛰는 만큼, 이제 우리가 반드시 읽고 판단해야 하는 화면은 바로 에이전트가 제공하는 이 화면들입니다. 세 회사의 출시 발표는 하나같이 승인과 기록을 강조하지만, 그 화면을 화면 읽기 프로그램으로 읽을 수 있는지에 대해서는 말하지 않습니다.

브리핑 4. 어디까지 믿고 맡길까 — 격리, 헌법, 그리고 승인 화면

처음 Hermes를 설치할 때 저는 매우 조심스러웠습니다. 파일과 폴더를 다룬다는 말은 결국 컴퓨터 자체를 조작한다는 의미인데, 옆집 OpenClaw에서 하루가 멀다 하고 터지는 정보 유출과 보안 사고 소식을 접했기 때문에 Hermes도 처음에는 별도의 격리 공간에서 운영을 시작했습니다.23 일단 안심이 되기는 했지만 실제로 이 녀석에게 무언가 일을 시키려 했더니 막상 할 수 있는 게 없었습니다. 그래서 저는 과감하게 격리 구역에서 Hermes를 꺼낸 뒤에 이 친구에게 헌법 하나를 만들어 주었습니다.24

“파일이나 폴더를 변경하거나 삭제하거나, 외부에 무엇인가를 게시하기 전에는 반드시 나에게 허락을 받을 것”

생각해 보면 당연한 일입니다. 내 컴퓨터를 직접 제어하고 내가 가진 정보를 가장 가까운 거리에서 들여다보는 비서라면 ‘비밀 유지 계약서’부터 쓰는 게 순서입니다. 사람 비서를 들일 때도 열쇠를 건네기 전에 어떤 서랍은 열어도 되고 어떤 서랍은 안 되는지부터 정합니다. 에이전트에게 헌법을 써 준 일도 결국 같은 질문에서 시작했습니다. 나는 이 비서에게 무엇을 맡기고, 어디서부터는 내가 직접 승인할 것인가.

에이전트에게 맡긴 정보가 누구에게 전달되는지도 알아야 합니다. 로이터는 Muse의 전화 걸기 기능 일부를 사람 상담원이 대신 처리하는 시험을 보도했습니다. 직원들 사이에서는 민감한 정보가 콜센터 계약자에게 넘어갈 수 있다는 우려가 나왔습니다.25

헌법을 쓰고 나서 알게 된 것이 있습니다. 같은 약속이라도 두 겹이 필요하다는 점입니다. 하나는 에이전트가 읽고 따르겠다고 약속하는 규칙이고, 다른 하나는 에이전트가 깜빡하더라도 시스템이 강제로 멈춰 세우는 장치입니다. 앞의 것은 말로 쓴 계약서이고, 뒤의 것은 잠긴 서랍입니다. 계약서만 있으면 비서가 실수로 어길 수 있고, 잠긴 서랍만 있으면 왜 잠겼는지 서로 이해하지 못합니다. 저는 두 가지를 함께 두었고 하는 일에 따라 엄격함도 달리 정했습니다. 예를 들어 제 노트를 관리하는 에이전트에게는 제가 ‘지워’라고 말해도 곧바로 지우지 말고 먼저 보관할 방법부터 제안하라고 일러두었습니다.

반대로 묻지 않는 에이전트가 얼마나 위험한지는 옆집이 보여 주었습니다. OpenClaw에서 발견된 한 취약점은 주소창에 들어온 값만 보고 사용자에게 묻지도 않은 채 외부 서버에 연결해 인증 정보를 넘겨주는 결함이었습니다.26 외부 연결과 인증 정보 전송을 사용자에게 알리고, 거부할 기회를 주는 절차가 필요했던 대목입니다. 브리핑 3의 대형 에이전트들이 하나같이 ‘민감한 행동 전에는 승인을 구한다’고 강조하는 데에는 이런 배경이 있습니다.

그런데 시각장애인에게는 여기서 질문이 하나 더 생깁니다. 승인을 요구하는 규칙은 내가 만들 수 있습니다. 그런데 그 승인 화면을 내가 끝까지 읽을 수 없다면 어떨까요? 저는 제23호에서 이런 경험을 소개했습니다. Hermes의 터미널 승인 화면이 실행할 명령의 일부만 보여 주고 나머지는 ‘위에 있다’고 안내해 화면 읽기 프로그램으로 전문을 확인하기 어려웠습니다. 그때 제보한 문제는 아직 해결을 기다리고 있습니다.27 무엇을 승인하는지 읽지 못한 채 누르는 ‘예’는 허락이 아니라 짐작입니다. 허락을 받으라는 헌법은 그 허락의 내용을 읽을 수 있을 때라야 비로소 나를 지켜 줍니다.

승인의 횟수도 고민거리입니다. 너무 자주 묻는 에이전트는 안전하지만 피곤하고, 묻지 않는 에이전트는 편하지만 위험합니다. 승인 요청이 쌓이다 보면 사람은 내용을 확인하지 않고 습관처럼 ‘예’를 누르게 됩니다. 화면 읽기 프로그램으로 긴 승인 내용을 매번 끝까지 듣는 일은 눈으로 훑어보는 일보다 훨씬 많은 시간이 듭니다. 그래서 무엇을 승인 대상으로 둘지, 승인 화면에 무엇을 먼저 보여 줄지는 시각장애인 사용자에게 특히 중요한 설계 문제입니다.

AI 분야에서는 사람이 판단의 고리 안에 머물러야 한다는 뜻으로 ‘Human in the Loop’라는 말을 씁니다. 저는 이 말을 조금 더 구체적으로 읽고 싶습니다. 사람이 고리 안에 있다는 것은 승인 버튼 앞에 서 있다는 뜻만이 아닙니다. 무엇을 맡겼는지 알고, 에이전트가 무엇을 하려는지 읽고, 필요하면 멈추고, 끝난 뒤에 결과를 확인할 수 있어야 합니다. 그 모든 단계가 내 화면 읽기 프로그램으로 가능할 때, 저는 비로소 이 비서에게 열쇠를 맡겼다고 말할 수 있을 것 같습니다.

브리핑 5. 그래서, 얼마나 도움이 되는가 — WebAIM 제11차 조사가 말하는 AI 에이전트의 자리

그래서, AI 에이전트는 시각장애인의 접근성에 얼마나 도움이 될까요? 마침 이 질문에 숫자로 답할 실마리가 나왔습니다. 미국의 웹 접근성 기관 WebAIM이 2026년 7~8월에 실시한 제11차 화면 읽기 프로그램 사용자 조사 결과입니다. 유효 응답은 1,780건입니다.28

먼저 누가 답했는지부터 보겠습니다. 응답자의 94.8%가 장애 때문에 화면 읽기 프로그램을 쓴다고 답했습니다. 장애 유형을 복수로 고르는 문항에서는 ‘Blindness’를 선택한 응답자가 83.2%, ‘저시력·시각 손상(Low Vision/Visually-Impaired)’을 선택한 응답자가 18.0%였습니다. 절반이 넘는 54.1%가 북미 응답자였고 유럽이 27.7%였습니다. 아시아 응답자는 6.2%에 그쳤고, 한국에서 많이 쓰는 센스리더는 따로 집계되지 않았습니다. 스스로를 고급 사용자라고 답한 비율도 57.8%로 높았습니다.29 그러니 이 조사는 한국 시각장애인의 모습이라기보다, 화면 읽기 프로그램에 꽤 능숙한 서구 사용자들의 응답이라고 읽는 편이 정확합니다.

이 사용자들은 이미 AI를 생활 속에서 쓰고 있었습니다. 온라인 경험을 개선하려고 AI를 어떻게 쓰느냐는 질문에 60.1%가 이미지 설명이나 대체 텍스트 생성에, 49.7%가 복잡한 이미지 분석에 쓴다고 답했습니다. 그리고 40.6%는 온라인에서 어떤 일을 처리하는 방법을 안내받는 데 AI를 쓴다고 답했습니다.30 다만 이 문항이 물은 것은 ‘안내’입니다. 에이전트가 직접 클릭하고 제출하는 ‘대리 실행’을 얼마나 쓰는지는 이번 조사가 묻지 않았습니다. 일을 맡기는 AI는 아직 숫자로 잡히기 전 단계에 있는 셈입니다.

같은 조사에는 마음에 걸리는 숫자도 있었습니다. 지난 1년 동안 웹 콘텐츠의 접근성이 어떻게 변했느냐는 질문에 32.2%는 좋아졌다고, 44.9%는 변화가 없다고, 22.9%는 나빠졌다고 답했습니다. 여전히 좋아졌다는 응답이 더 많지만, 2024년 조사와 비교하면 좋아졌다는 응답은 줄고 나빠졌다는 응답은 늘었습니다.31

웹 접근성 평가 기술은 계속 발전하고 있는데 사용자의 체감은 왜 뒷걸음질할까요? 같은 기관의 다른 보고서가 단서를 줍니다. WebAIM은 매년 전 세계 상위 100만 개 웹사이트의 첫 화면을 자동으로 검사합니다. 2026년 2월 검사에서 페이지당 검출된 접근성 오류는 평균 56.1개로 1년 전보다 10.1% 늘었고, 오류가 하나라도 검출된 첫 화면의 비율도 95.9%로 올라 6년간 이어진 개선 흐름이 꺾였습니다. 같은 기간 첫 화면의 구성 요소는 평균 1,437개로 1년 새 14.3% 늘었습니다.32 WebAIM은 이 흐름이 외부 프레임워크와 라이브러리에 대한 의존, 그리고 자동화·AI 보조 코딩, 이른바 ‘바이브 코딩’의 확산을 반영하는 것으로 보인다고 분석했습니다.33

여기에 평가 방식의 한계도 겹칩니다. 자동 검사는 기계가 찾을 수 있는 오류만 찾고, WebAIM의 검사는 첫 화면만 봅니다. 우리 시각장애인이 실제로 막히는 곳은 대개 로그인 뒤의 결제 화면, 신청서, 회원 정보 수정 화면입니다. 국내 웹 접근성 품질인증도 1년 단위로 특정 시점의 사이트를 심사합니다.34 평가와 인증은 그 시점의 그 대상을 측정하지만, 사용자는 업데이트가 이어지는 서비스의 전체 흐름을 매일 겪습니다. 저 알리는 평가 기술의 발전과 체감의 하락이 서로 모순이라기보다, 서로 다른 것을 측정한 결과라고 봅니다. 웹이 복잡해지는 속도가 고치는 속도보다 빠르고 한 번 고친 것이 다음 업데이트에서 다시 깨지기도 하니까요.

이 대목이 이번 호에서 가장 아이러니하게 읽힙니다. AI가 웹을 더 빨리 만들수록 접근성 오류도 더 빨리 증가할 수 있고, 우리는 그 웹을 다시 AI 에이전트로 우회합니다. 그렇다면 응답자들은 무엇을 원했을까요? 웹 접근성을 개선하는 데 더 큰 영향을 줄 것이 무엇이냐는 질문에 83.9%가 ‘더 나은 보조공학’보다 ‘더 접근 가능한 웹사이트’를 골랐습니다.35 같은 조사에서 AI 활용과 웹 자체의 개선을 바라는 요구가 함께 나타난 것입니다.

WebAIM은 사용자의 보조공학과 선호를 알고 디지털 환경을 맞춰 주는 지능형 도우미를 상상하는 글에서도 이렇게 못 박았습니다. “그런 시스템이 내일 당장 나온다 해도, 디지털 콘텐츠와 서비스, 제품을 만드는 사람들은 여전히 모든 사용자에게 동등한 접근을 제공할 책임이 있다.”36

그래서 제가 내놓는 답은 이렇습니다. AI 에이전트는 시각장애인에게 분명히 큰 도움이 됩니다. 길을 찾느라 쓰던 시간을 돌려주고 혼자 채우기 어려웠던 양식을 함께 채워 주며 끊어진 길을 대신 걸어가 심부름을 해 줍니다. 하지만 에이전트가 길을 대신 걸어 주는 것과 그 길이 접근 가능해지는 것은 다른 일입니다. 도움의 크기는 ‘대신 클릭하는 능력’만으로 측정할 수 없습니다. 내가 무엇을 맡겼는지 알고, 에이전트가 하려는 일을 읽고, 승인하고, 멈추고, 결과를 확인할 수 있는지까지 함께 측정해야 합니다. 그리고 그 모든 단계는 결국 접근 가능한 화면 위에서 이루어집니다. 다시 한 번 말씀드리지만, 접근성의 토대는 ‘독립성’입니다.

마치며

지난 4월, 우리 집에 에르메스가 들어왔습니다. 처음에는 격리된 방 안에서 조심스럽게 지켜보았습니다. 방 밖에서 일을 맡기면서 지켜야 할 헌법도 하나 써 주었습니다. 지금 이 녀석은 제 이메일을 정리하고 뉴스를 모으고 이 브리핑의 자료를 함께 찾습니다. 화면에서 길을 찾느라 쓰던 시간이 줄어든 만큼, 저는 무엇을 쓸지 고민하는 데 더 많은 시간을 보냅니다.

그런데 AI 에이전트와 함께 일할수록 오히려 더 분명해지는 것이 있습니다. 에이전트가 대신 걸어 준 길 끝에는 언제나 제가 직접 읽어야 하는 화면이 남는다는 사실입니다. 승인 화면, 결과 보고, 서식이 맞았는지 확인하는 마지막 점검을 저는 결코 게을리할 수 없었습니다. 이 화면들을 읽을 수 없다면, 에이전트는 편리한 비서가 아니라 내가 통제할 수 없는 대리인이 됩니다.

그래서 저 알리는 AI 에이전트의 시대에도 접근성의 무게가 결코 가벼워질 수 없다고 생각합니다. 오히려 더 무거워집니다. 사람이 읽는 화면과 에이전트가 읽는 구조가 모두 접근 가능해야 하기 때문입니다. 접근성이 높은 웹은 사람에게도 에이전트에게도 좋은 웹입니다. 에이전트가 우리 대신 일하는 시대일수록, 그 일의 처음과 끝은 우리가 직접 확인할 수 있어야 합니다.

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

Footnotes

  1. 개발자 피터 슈타인베르거(Peter Steinberger)의 설명에 따르면 이 프로젝트는 주말에 만든 ‘WhatsApp Relay’에서 출발했고, 2025년 11월 ‘Claude’와 집게발(claw)을 합친 말장난으로 ‘Clawd’라는 이름을 얻었습니다. 이후 Clawdbot, Moltbot을 거쳐 2026년 1월 30일 OpenClaw로 이름을 확정했습니다. 공개 두 달 만에 GitHub 별 10만 개를 넘겼다고 밝혔습니다. | Peter Steinberger, 「Introducing OpenClaw」, OpenClaw Blog(2026.1.30.) ↩

  2. Anthropic은 2025년 2월 24일 Claude 3.7 Sonnet을 발표하면서 Claude Code를 첫 에이전틱 코딩 도구로 소개하고 제한된 연구용 미리보기(research preview)로 공개했습니다. Claude Code는 터미널에서 개발자의 코드를 읽고 고치는 도구로 출발했습니다. 함께 읽기: 알리의 Claude Code 사용기. | Anthropic, 「Claude 3.7 Sonnet and Claude Code」(2025.2.24.) ↩

  3. Anthropic은 미리 정해진 순서에 따라 언어 모델과 도구를 움직이는 ‘워크플로’와, 언어 모델이 스스로 과정을 정하고 도구 사용을 결정하는 ‘에이전트’를 구분합니다. 챗봇이 질문에 답을 돌려주는 데 머문다면, 에이전트는 목표를 받아 필요한 도구를 골라 쓰며 일을 끝까지 진행합니다. 함께 읽기: 제2호 ‘Agentic AI 시대의 전환’. | Anthropic, 「Building effective agents」(2024.12.19.) ↩

  4. Anthropic은 ‘Claude’ 상표, 그리고 Claude Code의 마스코트 ‘Clawd’와 이름이 비슷하다는 점을 들어 개명을 요청했습니다. 슈타인베르거는 Business Insider에 “Anthropic 때문에 계정 이름을 바꿔야 했다. 내 결정이 아니었다”고 말했고, OpenClaw 공식 블로그에는 “Anthropic 법무팀이 정중하게 재고를 요청했다”고 적었습니다. 2026년 1월 27일 Moltbot으로 바꾼 뒤, 상표 검색과 도메인 확보를 마치고 사흘 만에 OpenClaw로 다시 바꿨습니다. | Business Insider, 「Clawdbot creator says Anthropic ‘forced’ him to rename the viral AI agent」(2026.1.27.) · Peter Steinberger, 「Introducing OpenClaw」(2026.1.30.) ↩

  5. 보안 기업 SecurityScorecard는 2026년 2월 공개 인터넷에 노출된 OpenClaw 설치본 40,214개를 찾아냈고, 그중 63%가 취약하며 12,812개는 원격 코드 실행 공격으로 컴퓨터 전체를 장악당할 수 있는 상태라고 밝혔습니다. 사용자가 설정을 잘 모른 채 자기 컴퓨터를 인터넷에 열어 둔 경우가 많았습니다. | Infosecurity Magazine, 「Researchers Find 40,000+ Exposed OpenClaw Instances」(2026.2.9.) ↩

  6. ‘Hermes’를 프랑스어로 읽으면 명품 브랜드 ‘에르메스’가 됩니다. 정작 개발사 Nous Research는 그리스 신화에서 신들의 말을 전하던 전령 헤르메스에게서 이름을 따왔습니다. 이 회사의 언어 모델 ‘Hermes’ 시리즈 소개에는 “그리스 신화에서 헤르메스는 소통의 기술로 세계를 잇는 신들의 전령”이라는 설명이 실려 있습니다. 디지털 세계의 전령이 되겠다는 뜻으로 읽을 수 있습니다. | Nous Research, 「Nous-Hermes-2-Vision-Alpha」, Hugging Face · NousResearch/hermes-agent, Issue #8445 ↩

  7. Hermes Agent는 Nous Research가 MIT 라이선스로 공개한 오픈 소스 AI 에이전트입니다. ‘The agent that grows with you(당신과 함께 자라는 에이전트)‘를 내세우며, 대화와 기억을 저장해 다음 작업에 이어 쓰고, 문제를 푼 방법을 스킬로 만들어 다시 활용하며, 자연어로 예약한 보고서와 브리핑을 무인으로 실행한다고 소개합니다. 텔레그램·디스코드·슬랙·이메일 같은 메시징 서비스와 데스크톱 앱, 터미널에서 같은 에이전트를 부를 수 있습니다. 첫 공개 정식 릴리스는 2026년 3월 12일의 v0.2.0입니다. | Nous Research, 「Hermes Agent」 · NousResearch, 「Hermes Agent v0.2.0 (v2026.3.12)」 릴리스 노트(2026.3.12.) ↩

  8. 행사는 9월 28일(월) 저녁 6시 30분 AWS Korea 센터필드 이스트타워에서 열렸습니다. Dev Korea는 영어권 개발자와 국내 기술 커뮤니티를 잇는 모임으로, 이번 행사를 시각장애인과 저시력인이 앱·웹·AI 도구를 쓰는 모습을 라이브 시연으로 보여 주는 자리로 소개했습니다. 발표 자료는 에이전틱 브라우저의 한계를 설정의 어려움, 로그인 세션·쿠키·입력 정보 접근에 따른 보안 위험, 에이전트를 고려하지 않은 웹(CAPTCHA·봇 탐지·요청 제한, 동적 화면 구조와 팝업, 불명확한 레이블과 부실한 접근성 트리)의 세 갈래로 정리했습니다. 에이전틱 브라우저는 CDP(Chrome DevTools Protocol), Playwright 같은 기술로 웹 페이지의 구조와 접근성 트리를 읽고 클릭·입력·스크롤을 수행합니다. 함께 읽기: 제23호 ‘대화·탐색·통제’. | Dev Korea, 「Accessibility, live」(2026.9.28.) ↩ ↩2

  9. PDF 문서가 중대한 접근성 문제를 일으킬 가능성이 ‘매우 높다’ 46.7%, ‘어느 정도 높다’ 38.9%를 합한 값이며, 2019년 같은 질문의 75.1%에서 올랐습니다. Microsoft Word 문서는 31.1%였습니다. 스스로 고급 사용자라고 답한 사람 가운데서도 86.2%가 PDF를 문제로 꼽아, 숙련도만으로 넘기 어려운 장벽임을 보여 줍니다. 문서 파일을 직접 검사한 결과가 아니라 사용자의 경험을 물은 응답입니다. 함께 읽기: 제10호 ‘HWPX 전환과 문서 접근성’. | WebAIM, 「Screen Reader User Survey #11 Results」 ↩

  10. 2차 모집은 2026년 9월 18일부터 10월 13일 18시까지이며, 상시근로자가 없는 1인 중증장애인기업을 대상으로 기기 공급가액의 90%, 기업당 최대 500만 원을 지원합니다. 신청자는 지정 서식인 신청서·활용계획·개인정보 동의서·기업정보 동의서와 함께 중증장애인 확인서, 사업자등록증명원, 장애인기업 확인서, 견적서, 총사업자등록내역, 근로자 없음 증빙 등을 준비해야 합니다. 근로자 없음 증빙은 신청일 전날 기준으로 발급한 서류만 인정합니다. | 장애인기업종합지원센터, 「2026년 1인 중증장애인기업 보조공학기기 지원사업 모집 공고(2차)」(2026.9.18.) ↩

  11. 김헌용 선생님은 서울의 중학교 영어 교사이자 함께하는장애인교원노동조합 위원장입니다. 2026년 한겨레 휴먼테크놀로지어워드 대상을 받으며, 상근자 없는 노조 업무를 위해 AI 에이전트를 만들어 한글 파일 자동 변환과 회의록 작성에 쓰고 있다고 소개됐습니다. 한글 문서의 개방형 형식인 HWPX는 XML 기반이라 에이전트가 문서 구조를 읽고 내용을 채우기 쉽습니다. 함께 읽기: 제24호 ‘시각장애 교직원과 업무시스템’. | 한겨레, 「온라인업무 불편했던 시각장애 교사…기술소외 없는 학교 만들기 분투」(2026.6.22.) ↩

  12. kordoc은 HWP·HWPX·PDF·Office 문서를 마크다운으로 변환하고, 양식 자동 채우기와 신구 대조 기능을 갖춘 오픈 소스 도구입니다. 명령줄 프로그램과 함께 MCP 서버로도 제공되어, AI 에이전트가 한국 문서 서식을 읽고 빈칸을 채우는 데 쓸 수 있습니다. | chrisryugj/kordoc - GitHub ↩

  13. CAPTCHA(캡차)는 ‘Completely Automated Public Turing test to tell Computers and Humans Apart’의 약자로, 사람과 자동화된 프로그램을 구별하려는 검사입니다. 일그러진 글자를 읽어 입력하거나 사진에서 특정 대상을 고르는 방식이 대표적입니다. 이런 시각 과제는 화면 읽기 프로그램 사용자에게 장벽이 되고, 대안으로 제공하는 음성 문제도 왜곡된 소리와 배경 잡음, 화면 읽기 프로그램 음성과의 겹침 때문에 풀기 어려울 수 있습니다. 시청각장애인에게는 시각·음성 문제 모두 이용하기 어려울 수 있습니다. W3C는 CAPTCHA의 접근성 문제를 다룬 기술 해설에서 이러한 한계를 짚고, 사용자가 직접 문제를 풀지 않는 방식 등 대안도 검토합니다. 자동화를 막는 절차를 설계할 때 장애인의 서비스 이용 경로도 함께 보장해야 하는 이유입니다. | W3C, 「Inaccessibility of CAPTCHA」, Working Group Note(2019.12.9.) ↩

  14. 토큰은 AI 모델이 글을 처리하는 단위로, 글자 하나나 단어의 일부, 단어 전체, 문장부호가 하나의 토큰이 될 수 있습니다. 모델에 보내는 입력과 모델이 만드는 출력이 모두 토큰으로 계산되고, 추론 모델은 답을 내기 전 내부에서 추론하는 데에도 토큰을 씁니다. 이 추론 토큰은 화면에 보이지 않지만 출력 사용량과 비용에 포함됩니다. 에이전트가 읽어 들인 페이지 내용과 앞선 시도 기록은 다음 요청의 입력이 되므로, 같은 화면을 여러 번 다시 읽고 시도할수록 토큰 사용량이 늘어납니다. | OpenAI Help Center, 「Understanding and counting tokens」 ↩

  15. 오리진 트라이얼(origin trial)은 개발자가 신청한 사이트에서 일정 기간 실험적 브라우저 기능을 사용하고 이용자 피드백을 모으는 시험 배포입니다. 구글은 2026년 6월 9일 Chrome 149의 WebMCP 오리진 트라이얼을 안내했습니다. 10월 2일 확인한 공식 안내(10월 1일 갱신)에서도 WebMCP를 논의 중인 웹 표준 제안이자 오리진 트라이얼 단계로 설명합니다. 사이트가 도구를 구현하고 이를 이용할 브라우저·에이전트가 지원해야 하며, 도구를 발견하려면 해당 사이트를 방문해야 합니다. | Chrome for Developers, 「Join the WebMCP origin trial」(2026.6.9.) · Chrome for Developers, 「WebMCP」(2026.10.1. 갱신) ↩

  16. WebMCP는 웹페이지 안의 기능을 에이전트가 호출할 도구로 공개합니다. 일반적인 MCP 서버와 AI 서비스의 백엔드 연결에 비해, 사용자와 에이전트가 같은 웹 화면과 현재 상태를 공유하며 작업한다는 데 초점을 둡니다. 자바스크립트로 도구를 등록하는 명령형 API와 HTML 폼에 도구 정보를 덧붙이는 선언형 API를 제공하며, 입력값의 구조와 용도를 명시해 추측에 의존하는 조작을 줄이려 합니다. 지원사업 공고 검색은 이 방식을 설명하기 위한 적용 예시입니다. 구글의 보안 안내는 읽기 전용 여부와 중요한 결과를 낳는 행동을 도구 정보에 표시하고, 예약·송금 같은 행동에서는 사용자 확인을 요청할 수 있게 하도록 안내합니다. 이런 정보 제공과 함께 도구의 입력·출력을 통한 악성 지시 유입에도 대비해야 합니다. | WebMCP, 「Explainer」 · Chrome for Developers, 「WebMCP tool security」(2026.9.1. 갱신) ↩

  17. OpenAI 공식 일정표의 접수 기간은 2026년 8월 25일 낮 12시부터 9월 4일 오전 1시까지(미국 태평양시간)입니다. 새 앱 개발뿐 아니라 기존 앱에 WebMCP 지원을 추가하는 방식도 허용했습니다. 실제 작동하는 웹앱 주소, 사용 경험과 구현 설명, 3분 미만 시연 영상, 오픈 소스 라이선스를 갖춘 공개 코드 저장소를 제출하도록 했으며, 유용성·독창성·구현 완성도·WebMCP 활용·사람과 에이전트의 협업 경험을 평가 기준으로 제시했습니다. Google Chrome·Cloudflare·Vercel·Shopify·Netlify·Render가 지원사로 참여했습니다. OpenAI는 ChatGPT 내장 브라우저가 WebMCP를 기본 지원한다고 안내하고, Chrome에서는 실험 플래그나 오리진 트라이얼로 시험할 수 있다고 설명합니다. 이는 제품별 구현 현황이며, WebMCP 자체는 실험적 개방형 표준으로 소개하고 있습니다. | OpenAI, 「The WebMCP Challenge」 · Devpost, 「The WebMCP Challenge」 — 제출 요건·심사 기준 ↩

  18. WebMCP 설명 문서는 에이전트를 통한 접근성 지원을 목표로 제시하면서도, WebMCP 자체는 보조공학이 직접 읽어 쓰거나 페이지의 접근성 트리와 직접 상호작용하도록 설계된 것이 아니라고 밝힙니다. 에이전트용 도구 호출 통로를 추가하더라도 화면 읽기 프로그램이 읽을 레이블·구조와 사용자의 조작 경로는 계속 필요합니다. | WebMCP, 「Explainer」 — Goals ↩

  19. SpaceXAI는 2026년 2월 SpaceX에 합류한 xAI의 현재 이름입니다. 공식 소개에 따르면 Grok Bot은 클라우드의 자기 컴퓨터를 공유하며 사용자가 자리를 비워도 일을 멈추지 않고, API나 MCP 연동이 없는 웹사이트에도 로그인해 일할 수 있다고 합니다. 어떤 행동이 승인 대상인지는 공식 소개에서 구체적으로 설명하지 않았습니다. | SpaceXAI, 「Introducing Grok Bot」(2026.8.11.) · SpaceXAI, 「xAI joins SpaceX」(2026.2.2.) ↩

  20. Meta는 Muse가 이메일·캘린더·결제·쇼핑 같은 앱에 접근해 일을 처리하며, 지금까지 한 일과 앞으로 할 일의 전체 기록을 사용자에게 보여 준다고 밝혔습니다. 결제에는 Stripe의 Link 지갑이 만든 일회용 카드를 씁니다. 로이터는 Meta가 이 기술이 일을 잘못 처리할 수 있다는 내부 우려 속에서 Muse를 출시했다고 전했습니다. | Meta, 「Introducing Muse: The World’s First Personal AI Agent Built for Everyone」(2026.9.8.) · Reuters, 「Meta launches AI agent that can access other apps to send emails, make payments」(2026.9.8.) ↩

  21. OpenAI의 dots는 GPT-6 Astra 모델로 움직이며, 2026년 9월 29일부터 적격 국가의 ChatGPT Pro·Business Premium 이용자에게 순차 제공됩니다. dots에는 언제 스스로 움직이고 언제 승인을 구할지 정한 기본 규칙이 있고, 사용자는 맞춤 규칙으로 특정 행동을 허용·승인·차단할 수 있습니다. 기본 안전 요건은 맞춤 규칙과 상관없이 늘 적용됩니다. 국내 촉각 디스플레이 기업 닷(Dot)과는 다른 제품입니다. | OpenAI, 「Introducing dots」(2026.9.29.) ↩

  22. 아마존은 Muse가 쇼핑몰을 직접 탐색하지 못하게 막았지만, Muse는 검색 엔진을 통해 상품 링크를 찾아올 수는 있었습니다. 기자는 데이트 계획이나 이사 준비처럼 여러 정보를 모아 정리하는 일에서는 Muse가 쓸모 있었다고 평가했습니다. | CNN, 「Meta says its Muse AI agent can do things for you. I put it to the test」(2026.9.23.) ↩

  23. Hermes는 명령을 실행할 터미널 환경을 내 컴퓨터(local)뿐 아니라 Docker 컨테이너, 원격 서버 등으로 고를 수 있습니다. Docker는 애플리케이션 실행에 필요한 모든 것을 담아 다른 환경과 느슨하게 격리하는 ‘컨테이너’를 만드는 도구입니다. 컨테이너는 실행 환경을 분리하지만, 호스트의 파일·폴더를 연결하는 바인드 마운트(bind mount)를 설정하면 연결한 파일에 접근할 수 있습니다. 외부 서비스 이용도 네트워크와 계정 권한 설정에 따라 달라집니다. 따라서 실제 접근 범위는 연결한 자원과 부여한 권한을 함께 살펴야 합니다. | Docker, 「What is Docker?」 · Docker, 「Bind mounts」 · Hermes Agent, 「Security」 ↩

  24. 이 헌법은 실제로 두 층으로 운영합니다. 하나는 에이전트가 매번 읽는 성격·원칙 파일(SOUL.md)입니다. 여기에 “기존 파일·설정의 변경, 삭제, 롤백, 외부 반영은 계획과 영향 범위를 설명하고 승인받은 범위에서 수행한다”는 원칙을 적었고, 작업 영역별로 나눈 에이전트마다 엄격함을 달리했습니다. 노트를 관리하는 에이전트에게는 기존 노트를 허락 없이 수정·삭제·이동하지 말고, 지우라는 말을 들어도 먼저 백업·보관 방법을 제안하라고 정했습니다. 다른 하나는 Hermes의 위험 명령 승인 설정입니다. 보조 모델이 명령의 위험도를 판단해 애매하면 사람에게 묻는 ‘smart’ 모드를 쓰고, 사람이 지켜보지 않는 예약 작업에서는 위험 명령을 묻지 않고 거부하도록 했습니다. 정해진 시간 안에 승인 응답이 없으면 명령은 실행되지 않습니다. 앞의 것은 모델이 따르는 약속이고, 뒤의 것은 시스템이 강제하는 장치입니다. | Hermes Agent, 「Personality & SOUL.md」 · Hermes Agent, 「Security」 ↩

  25. 로이터가 입수한 내부 게시물에 따르면 Meta는 전화 걸기 기능 출시 직후 ‘휴먼 컨시어지(human concierge)‘라는 이름으로 일부 통화를 사람 계약자가 처리하도록 직원 절반에게 시험 적용했습니다. 자동 음성 전화를 받는 쪽이 응대를 꺼리는 문제를 넘기려는 시도였습니다. 같은 기사는 Muse가 출시 뒤 2주 동안 미국 앱 다운로드 순위 정상을 지켰다고 전했습니다. Meta 대변인은 직원 반응이 매우 긍정적이었고, 정식 공개 전에 안전·개인정보 보호 장치를 마련하려고 의견을 듣는 시험이라고 설명했습니다. | Reuters, 「Meta testing a ‘human concierge’ for its new personal AI agent, Muse」(2026.9.22.) ↩

  26. CVE-2026-25253은 2026.1.29 이전 버전의 OpenClaw가 주소의 쿼리 문자열에서 gatewayUrl 값을 가져와, 사용자에게 묻지 않고 WebSocket 연결을 맺으며 인증 토큰을 보내던 결함입니다. 공격자가 만든 링크를 한 번 누르는 것만으로 토큰이 빠져나갈 수 있었습니다. 미국 국가취약점데이터베이스(NVD)에 2026년 2월 1일 등재됐고, CNA(MITRE)는 심각도를 8.8(높음)로 평가했습니다. | NIST NVD, 「CVE-2026-25253 Detail」(2026.2.1.) · GitHub Security Advisory, 「GHSA-g8p2-7wf7-98mq」 ↩

  27. 터미널 승인 화면이 여러 줄로 된 실행 내용을 잘라 보여 전문을 확인할 수 없는 문제(#38581)와 ‘전문은 위에 있다’는 안내가 모호한 문제(#38582)는 2026년 10월 2일 현재 열려 있습니다. 함께 제보한 데스크톱 앱의 초점·ARIA·명암 대비 문제(#38072)는 10월 1일 해결 완료로 닫혔습니다. | NousResearch/hermes-agent, Issue #38581 · Issue #38582 · Issue #38072 ↩

  28. WebAIM(Web Accessibility In Mind)은 2009년부터 화면 읽기 프로그램 사용자 조사를 이어 왔습니다. 이번이 열한 번째이며 직전 조사는 2023년 12월~2024년 1월에 실시했습니다. WebAIM은 표본을 통제하지 않았으므로 결과가 전체 화면 읽기 프로그램 사용자를 대표하지 않을 수 있다고 밝힙니다. 문항마다 응답 수가 조금씩 다릅니다. | WebAIM, 「Screen Reader User Survey #11 Results」 ↩

  29. 지역 문항 응답자 1,721명 가운데 북미 931명, 유럽 477명, 아시아 106명이었습니다. 장애 유형은 복수 선택이며 청각장애 7.5%, 인지·학습장애 3.0%도 있었고, 16.9%는 둘 이상의 장애를 보고했습니다. 화면 읽기 프로그램 숙련도는 고급 57.8%, 중급 38.8%, 초급 3.4%였습니다. 주로 쓰는 데스크톱 화면 읽기 프로그램은 JAWS 55.0%, NVDA 32.9%였고, 응답자의 70.3%는 두 가지 이상의 화면 읽기 프로그램을 씁니다. 함께 읽기: 제22호 ‘화면 읽기 프로그램의 파편화’. | WebAIM, 「Screen Reader User Survey #11 Results」 ↩

  30. 복수 선택 문항이며 웹페이지·문서 요약 37.1%, 멀티미디어 대체 콘텐츠 생성 28.7%, 콘텐츠 접근성 평가 19.5%, 텍스트의 음성 대체 생성 17.9%가 뒤를 이었습니다. 제시된 방식 중 어느 것도 고르지 않은 응답자는 8.2%였습니다. 원문 질문은 “In what ways do you commonly use AI to improve your online experience?”이고, 40.6% 항목의 원문은 “To provide guidance in performing an online task”입니다. 2024년 조사에는 같은 문항이 없어 증가 폭은 비교할 수 없습니다. | WebAIM, 「Screen Reader User Survey #11 Results」 ↩

  31. 2024년 조사에서는 좋아졌다는 응답이 34.6%, 나빠졌다는 응답이 18.6%였습니다. WebAIM은 웹 접근성에 대한 인식이 2021년에서 2024년으로, 다시 2024년에서 2026년으로 조금씩 낮아졌다고 설명합니다. 장애가 있는 응답자는 31.8%만 좋아졌다고 답해, 장애가 없는 응답자(41%)보다 낮았습니다. 같은 사람을 추적한 조사가 아니며 북미 응답자 비율도 47.2%에서 54.1%로 늘었습니다. | WebAIM, 「Screen Reader User Survey #11 Results」 · WebAIM, 「Screen Reader User Survey #10 Results」(2024) ↩

  32. WebAIM Million은 WAVE 검사 엔진으로 상위 100만 개 웹사이트의 첫 화면을 분석하는 연례 보고서로, 2026년이 여덟 번째입니다. 가장 흔한 오류는 낮은 명암 대비(83.9%), 이미지 대체 텍스트 누락(53.1%), 입력 서식 레이블 누락(51%), 빈 링크(46.3%), 빈 버튼(30.6%), 문서 언어 누락(13.5%) 순이며, 이 여섯 가지가 전체 오류의 96%를 차지하고 7년째 순위가 같습니다. ARIA 속성은 1년 새 27% 늘었는데 ARIA를 쓴 페이지의 평균 오류(59.1개)가 쓰지 않은 페이지(42개)보다 많았습니다. WebAIM은 오류가 검출되지 않았다고 해서 접근 가능하거나 기준에 맞는다는 뜻은 아니라고 밝힙니다. | WebAIM, 「The WebAIM Million: The 2026 report on the accessibility of the top 1,000,000 home pages」(2026) ↩

  33. WebAIM은 첫 화면이 놀라운 속도로 커지고 복잡해져 접근성을 갖추고 유지하기가 어려워지고 있다고 진단하며, 규모 있게 접근성을 높이려면 더 나은 관행과 더 단순한 시스템이 함께 필요하다고 결론지었습니다. 인과관계를 검증한 결과가 아니라 측정 결과를 바탕으로 한 기관의 해석입니다. | WebAIM, 「The WebAIM Million: The 2026 report」 Conclusion ↩

  34. 2026년 6월 9일 제정된 「접근성 품질인증 및 시험평가 등에 관한 고시」는 「디지털포용법」 제21조에 따른 접근성 품질인증의 종류를 웹사이트와 모바일 앱으로 정합니다. 문화체육관광부 누리집 안내에 따르면 심사 기준은 한국형 웹 콘텐츠 접근성 지침 2.1(KWCAG 2.1)이고, 서면 심사·전문가 심사·사용자 심사의 3단계를 거치며, 인증서 유효기간은 1년입니다. 문체부 누리집은 2009년부터 매년 갱신해 18번째 인증을 받았습니다. 함께 읽기: 제30호 ‘온라인쇼핑의 끊긴 길’. | 과학기술정보통신부, 「접근성 품질인증 및 시험평가 등에 관한 고시」(2026.6.9.) · 문화체육관광부, 「웹 접근성 품질마크」 ↩

  35. 1,758명 가운데 1,475명이 ‘더 접근 가능한 웹사이트’를, 283명(16.1%)이 ‘더 나은 보조공학’을 골랐습니다. 이 비율은 2009년 68.6%에서 2024년 85.9%까지 꾸준히 올랐다가 이번에 처음 조금 내려갔습니다. WebAIM은 보조공학의 접근성이나 성능에 대한 관심이 다소 커졌을 수 있다고 해석했고, 자신의 화면 읽기 프로그램에 덜 만족하는 응답자일수록 보조공학을 고른 비율이 두 배 가까이 높았습니다(29.8% 대 15.2%). | WebAIM, 「Screen Reader User Survey #11 Results」 ↩

  36. 원문은 “Even were such a system available tomorrow, developers of digital content, services, and products would still be responsible for providing equal access to ALL users.”입니다. 글쓴이 조지 조켈(George Joeckel)은 이 글에서 사용자의 장애와 보조공학, 선호를 알고 디지털 환경을 맞춰 주는 적응형 지능 시스템을 사고실험으로 제안했습니다. 함께 읽기: 제16호 ‘접근권으로 읽는 인공지능’. | George Joeckel, 「A New Path for Digital Accessibility?」, WebAIM Blog(2026.2.) ↩

그래프 뷰

백링크