네이티브 어댑티브 인터페이스(NAI, Natively Adaptive Interfaces)는 “사용자가 기술에 맞추는 시대”를 끝내고, 기술이 사용자에게 스스로 맞춰 가도록 설계하는 AI 기반 접근성 프레임워크입니다. 핵심은 접근성을 나중에 ‘옵션으로 추가’하는 게 아니라, 제품의 기본값으로 처음부터 심어 두는 것에 있습니다.1 이 글에서는 NAI가 기존 접근성 기능과 무엇이 다른지, 어떤 방식으로 화면과 콘텐츠를 바꾸는지, 그리고 왜 이 변화가 장애 당사자뿐 아니라 우리 모두에게 이득인지까지 한 번에 정리해볼게요.
네이티브 어댑티브 인터페이스(NAI)란 무엇인가
많은 앱의 접근성은 “설정 > 접근성” 깊숙한 곳에 숨어 있곤 합니다. 글자 크게, 고대비, 스크린리더 최적화… 기능은 있어도 ‘내 상황에 맞춰 자동으로’ 바뀌지는 않죠.
NAI는 출발점이 다릅니다. 처음부터 제품이 “사람은 각자 다르게 쓰인다”는 전제를 깔고, AI가 사용자의 목표와 맥락을 이해해 인터페이스 자체를 재구성하는 방향으로 설계됩니다.1 즉, 접근성이 부가 기능이 아니라 “기본 설계 철학 + 실행 엔진(AI)”으로 붙어 있는 셈입니다.
기존 접근성 기능과의 차이: ‘설정’이 아니라 ‘적응’
기존 방식은 보통 사용자가 직접 기능을 켜고, 세부 옵션을 조절하고, 그래도 불편하면 앱을 포기하는 흐름으로 끝나는 경우가 많습니다. 반면 NAI가 지향하는 경험은 “사용자가 목적만 말하면, 화면과 콘텐츠가 알아서 정리되는” 쪽에 가깝습니다.1
예를 들어 문서를 읽는 상황을 떠올려볼까요. 기존 접근성은 글자 크기를 키우거나, 확대를 하거나, 읽기 모드를 켜는 정도입니다. NAI는 여기서 한 발 더 나아가 “이 사람이 지금 무엇을 하려는지”를 기준으로, 필요한 정보만 남기고 레이아웃을 단순화하거나, 설명 방식을 바꾸거나, 다른 감각 채널(오디오/시각 보조 등)로 전환하는 것을 목표로 합니다.1
AI 에이전트가 UI를 ‘재편집’하는 방식
NAI 설명에서 재미있는 지점은 ‘에이전트 협업’ 구조입니다. 큰 목표를 이해하는 메인 AI 에이전트가 있고, 그 아래에 UI 조정, 텍스트 스케일링, 오디오 설명 생성 같은 역할을 맡은 하위 에이전트들이 붙어 함께 작업하는 그림이죠.1
이 방식이 매력적인 이유는 단순합니다. 접근성은 체크리스트가 아니라 “상황별 편집”에 가깝기 때문입니다. 누군가는 시각 정보가 더 필요하고, 누군가는 복잡한 레이아웃이 부담이며, 또 다른 누군가는 같은 내용도 더 쉬운 문장으로 보고 싶어합니다. NAI의 AI 에이전트들은 이 변수를 ‘사람이 매번 설정으로 해결하는 것’이 아니라 ‘제품이 자동으로 조율하는 것’으로 옮겨놓으려 합니다.1
‘커브컷 효과’: 장애를 위한 기능이 모두의 편의가 되는 순간
인도 보도블록이나 경사로(커브컷)가 원래는 휠체어 이동을 위해 만들어졌지만, 유모차·캐리어·자전거에도 도움이 되듯이, 접근성 기술은 종종 모두의 생활을 편하게 만듭니다. NAI도 이 “커브컷 효과”를 중요한 가치로 봅니다.1
예컨대 손을 쓰기 어려운 사용자를 위해 설계된 음성 제어가, 아이를 안고 있는 부모에게도 유용해지는 장면이 대표적입니다.1 결국 “특정 상황을 진지하게 해결한 UX”는 생각보다 넓은 사용자에게 퍼져나가고, 제품 전체 경험의 품질을 끌어올립니다.
“우리 없이 우리를 위한 것은 없다”: 개발 프로세스의 중심이 바뀐다
NAI가 기술적으로만 흥미로운 게 아니라, 개발 문화 측면에서도 눈여겨볼 이유가 있습니다. 이 프레임워크는 장애 당사자와 커뮤니티가 설계·개발 과정에 지속적으로 참여해야 한다는 원칙, 즉 “Nothing about us, without us(우리 없이 우리를 위한 것은 없다)”를 전면에 둡니다.1
접근성에서 가장 흔한 실패는 “좋은 의도”가 아니라 “잘못된 가정”에서 시작됩니다. 당사자가 직접 써보지 않으면, 실제로는 불편한데 개발팀만 만족하는 기능이 나오기 쉽죠. NAI가 강조하는 협업 모델은 이 지점을 구조적으로 막으려는 시도입니다.1
Grammar Lab 사례: ‘맞춤형 학습’이 접근성이 되는 방법
NAI가 추상적인 개념으로만 느껴진다면, 교육 사례를 보면 훨씬 직관적입니다. RIT/NTID와 Google이 함께 만든 Grammar Lab은 AI가 학습자에게 맞춘 문제를 생성해 영어와 미국 수화(ASL)를 함께 학습하도록 돕는 튜터형 도구로 소개됩니다.1
여기서 포인트는 “모든 학생에게 같은 문제”가 아니라 “각 학생이 지금 막히는 지점에 맞는 문제”로 학습 경험을 재구성한다는 것입니다.1 누군가에게는 설명이 더 천천히, 더 시각적으로, 더 단계적으로 제공되는 게 ‘친절’ 수준을 넘어 ‘학습의 가능성’을 열어주기도 하니까요.
마찬가지로 Google.org 지원을 통해 RIT/NTID, The Arc of the United States, RNID, Team Gleason 같은 기관들이 NAI 기반 적응형 AI 도구 개발을 위한 자금을 받았다는 점도 흐름을 보여줍니다.1 “좋은 기술”을 만드는 걸 넘어, 실제 커뮤니티 문제를 해결하는 현장에 투자하는 방식입니다.
시사점: 내 앱(내 서비스)도 ‘적응형’이 될 준비가 됐을까
NAI가 던지는 질문은 의외로 단순합니다. “접근성을 체크박스로 관리할 건가, 제품의 기본 작동 방식으로 만들 건가?”입니다.1
만약 제품을 만들거나 운영하는 입장이라면, 다음을 점검해보면 좋습니다. 사용자가 불편을 겪을 때 ‘설정법’을 안내하고 끝나는지, 아니면 UI와 콘텐츠가 사용자에게 맞춰 스스로 변할 여지가 있는지 말이죠. 그리고 그 변화를 AI가 한다면, 그 적응이 왜 일어났는지 설명 가능하고(신뢰), 기준에 부합하며(준수), 당사자 피드백으로 계속 업데이트되는지(현실성)도 함께 고민해야 합니다. 최근 연구에서는 LLM을 활용해 사용자 프로필과 규칙 기반 적응을 결합하고, WCAG 같은 표준을 따라 “감사 가능한 방식”으로 UI를 개인화하려는 접근도 제안됩니다.2
결국 NAI가 보여주는 미래는 화려한 신기능이 아니라, “누구나 처음부터 쓸 수 있는 기본값”입니다. 접근성이 옵션이 아닌 기본이 되는 순간, 기술은 더 많은 사람에게 덜 스트레스 받는 도구가 됩니다. 그리고 그 변화는 장애 당사자에게서 시작해, 결국 우리 모두의 하루를 더 편하게 바꿔놓을 가능성이 큽니다.
참고
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.