자동화 검사를 통과했다고? 그게 정말 좋은 alt 텍스트일까

수치로 드러난 문제: 4명 중 1명이 마주하는 현실

오늘 이 소식을 살펴보니, GitHub 블로그의 최신 글에서 흥미로운 통계가 눈에 띕니다. WebAIM의 2026년 보고서(WebAIM Million report)를 근거로, 웹의 가장 인기 있는 홈페이지 중 4명 중 1명이 마주치는 alt 텍스트 문제를 다루고 있습니다.

구체적으로 보면, 상위 백만 개 홈페이지를 조사한 결과 이미지의 16.2%에서 alt 텍스트가 완전히 빠져 있었습니다. 더 흥미로운 부분은 여기가 아닙니다. alt 텍스트가 있는 이미지 중 10.8%는 실제로는 무용지물인 텍스트로 채워졌다는 것입니다. alt="image"처럼 의미 없는 문자열, 파일명 그대로, 혹은 옆에 있는 다른 이미지의 설명을 그대로 복사한 경우들입니다.

이것이 왜 중요할까요? 제가 35년간 교육 현장에서 봐온 기술 진화 과정에서, 이 문제는 ‘도구의 한계’라는 오래된 질문을 다시 던집니다. 우리가 자동화로 뭘 검증할 수 있고, 뭘 할 수 없는가 하는 문제 말입니다.

기계가 증명할 수 있는 것, 못 하는 것의 경계

원문을 확인해본 결과, GitHub이 제시하는 핵심 통찰은 이렇습니다. 존재 여부는 객관적 사실이지만, 품질은 판단의 영역이라는 것입니다.

alt 속성이 있는지 없는지는 마크업만 봐도 알 수 있습니다. 참(true) 또는 거짓(false)의 이진 결과입니다. 하지만 어떤 alt 텍스트가 실제로 이미지를 잘 설명하는지는 다릅니다. 화면 낭독기(screen reader)를 사용하는 사람의 입장에서 그 텍스트가 충분한 문맥 정보를 주는가 하는 질문에 기계가 이미지를 직접 보지 않고 답할 수 없다는 뜻입니다.

그래서 현재 대부분의 alt 텍스트 검사 도구는 “접근 가능한 이름(accessible name)이 존재하는가”만 확인합니다. 그것이 실제로 의미 있는지는 묻지 않습니다. 원문에서 명시한 것처럼, 이것은 ‘의도적인 설계 선택(deliberate design choice)’입니다.

왜일까요? 품질 기준이 너무 엄격하면(false positive가 많으면) 팀들이 그 규칙 자체를 꺼버린다는 것입니다. 완벽한 기준이 쓰이지 않는 것보다 차라리 느슨하지만 실행되는 기준이 나을 수 있다는 판단입니다.

이런 절충은 자동화 인프라를 직접 구축해본 사람이라면 누구나 마주치는 딜레마입니다. n8n 같은 자동화 도구로 워크플로우를 만들 때도, 검증(validation) 규칙을 얼마나 엄격하게 잡을지 끊임없이 고민하게 됩니다.

GitHub의 새로운 시도: 모델을 루프에 넣다

흥미로운 부분은 GitHub이 이 문제를 단순히 지적하는 데 그치지 않았다는 것입니다. GitHub Accessibility Scanner에 새로운 alt 텍스트 플러그인을 추가했다고 합니다.

원문에서 언급된 것처럼, 이들이 고민한 지점은 다음과 같습니다: “어디서 기계가 증명할 수 있는 영역과 단지 의심(suspect)할 수만 있는 영역의 선을 그을 것인가.” 그리고 “모델을 루프에 넣었을 때 무엇이 달라졌는가(what changed once we let a model into the loop).”

이것은 단순 텍스트 분석을 넘어 이미지 인식 모델을 함께 활용하겠다는 신호로 보입니다. 프로그래밍이 선택지의 문제에서 확률의 문제로 진화하고 있는 시점을 보는 것입니다.

저는 35년 교육 현장에서 여러 번의 기술 거품과 탈거품 사이클을 겪었습니다. 규칙 기반 시스템(rule-based system)의 한계에 부딪혀 통계 모델로 옮겨갔고, 다시 그 모델의 설명 불가능성 때문에 하이브리드 접근을 고민하는 과정들을 봐왔습니다. 오늘 GitHub의 이 움직임은 그 맥락 속에서 자연스러운 진화로 느껴집니다.

1인 자동화 운영자에게 던지는 질문

여기서 시니어 창작자나 1인 자동화 운영자에게 실질적인 질문이 생깁니다.

여러분이 어떤 콘텐츠 자동화 파이프라인을 구축할 때, 검증 규칙을 몇 단계로 나눌 것인가 하는 문제입니다. 첫 번째 관문으로 “필드가 빈 값인가”만 체크할 것인가(현재의 대부분 도구), 아니면 처음부터 품질 평가까지 포함할 것인가. 만약 후자라면 false positive를 어느 수준까지 감수할 것인가.

또 다른 각도에서, 자동화 검사를 통과했다는 신호(signal)를 너무 믿어도 안 되고, 너무 의심해도 안 된다는 것입니다. 원문의 예시처럼 alt="IMG_2847.png"는 기술적으로는 alt 속성이 있으니 규칙을 만족하지만, 실제 사용자 경험은 완전히 다릅니다.

계속 지켜봐야 할 지점

이미지 인식 모델을 자동화 파이프라인의 필터로 쓸 때, 거짓 긍정(false positive)과 거짓 부정(false negative)의 균형은 어디가 적정선일까요? 특히 규정 준수(compliance) 환경에서는 이 기준이 법적, 윤리적으로 어떻게 정의되어야 할지가 아직 명확하지 않습니다. 이 부분은 계속 지켜봐야 할 지점입니다.

이 이슈는 다음 편에서 GitHub의 새로운 플러그인이 실제로 얼마나 효과적인지, 그리고 자동화와 인간 검토의 경계가 어디로 이동했는지를 이어서 다뤄보겠습니다.