텍스트 모드의 거짓말: 현대 TUI가 접근성에 악몽인 이유

• 터미널 앱이 텍스트 기반이라 본질적으로 접근 가능하다는 가정은 현대 TUI에서 깨지며, Ink, Bubble Tea, tcell 같은 프레임워크가 화면 읽기 프로그램 사용자에게 더 적대적인 환경을 만들 수 있음
• CLI는 stdin/stdout의 선형 스트림으로 출력이 시간순으로 쌓이지만, TUI는 터미널을 문자 셀 기반 2D 격자로 다뤄 화면 읽기 프로그램이 흐름을 따라가기 어려워짐
• gemini-cli는 Ink가 React 컴포넌트 트리를 터미널 격자에 맞춰 다시 그리면서 스피너·타이머·대화 기록 사이로 커서를 이동시켜 Speakup과 NVDA에 반복 낭독, 크래시, 입력 지연을 유발할 수 있음
• nano, vim, menuconfig, Irssi 같은 오래된 도구는 커서 숨김, 단일 열 포커스, VT100 스크롤 영역 활용으로 좌표 갱신 소음을 줄이고 입력 줄과의 간섭을 최소화함
• 접근 가능한 터미널 도구를 만들려면 터미널을 캔버스처럼 다루는 선언형 UI 프레임워크와 공격적인 다시 그리기를 피하고, 단순하고 선형적인 CLI 스트림에 가까운 동작을 보장해야 함

---

“텍스트라서 접근 가능하다”는 오해

• 터미널에서 실행되는 애플리케이션이 본질적으로 접근 가능하다는 가정은 실제 사용 환경과 맞지 않음
• 그래픽, 복잡한 DOM, WebGL 캔버스가 없기 때문에 화면 읽기 프로그램이 원시 ASCII 텍스트를 쉽게 해석할 수 있다는 기대는 현대 TUI에서 깨짐
• Ink(JS/React), Bubble Tea(Go), tcell 같은 터미널 UI 프레임워크는 개발자 경험(DX)을 개선하려 하지만, 시각장애인 사용자에게는 더 적대적인 환경을 만들 수 있음
• 잘못 구현된 그래픽 인터페이스보다 현대 TUI가 접근성 측면에서 더 나쁜 경우가 많음

CLI와 TUI의 구조적 차이

• CLI: 선형 스트림

  • CLI는 stdin/stdout 기반으로 동작하며, 명령을 입력하면 결과가 아래에 추가되고 커서가 내려감
  • 출력이 선형적이고 시간순으로 쌓이기 때문에 Speakup 같은 커널 수준 화면 읽기 프로그램에 적합함

• TUI: 2D 격자

  • TUI는 터미널 창을 텍스트 스트림이 아니라 문자 셀 하나하나가 픽셀처럼 쓰이는 2D 격자로 다룸
  • 시간적 흐름을 포기하고 공간적 레이아웃을 우선하면서 화면 읽기 프로그램이 따라가기 어려운 구조가 됨

gemini-cli에서 드러나는 문제

• gemini-cli는 Node.js와 Ink 프레임워크로 작성된 도구이며, 겉으로는 단순한 채팅 인터페이스처럼 보임
• 내부에서는 Ink가 React 컴포넌트 트리를 터미널 격자에 맞춰 조정하려고 함
• Speakup(Linux)이나 NVDA(Windows)로 사용할 때, 애플리케이션이 단순히 실패하는 수준을 넘어 화면 읽기 프로그램에 계속 읽을 내용을 쏟아냄

• 반응형 캔버스처럼 동작하는 화면

  • 프레임워크가 화면을 반응형 캔버스로 취급하기 때문에 모든 업데이트가 다시 그리기를 유발함
  • AI가 “생각 중”일 때 타이머나 스피너를 갱신하려고 하드웨어 커서를 타이머 위치로 옮기고, 새 시간을 쓰고, 다시 원래 위치로 돌림
  • 시각 사용자에게는 즉시 지나가는 동작이지만, 화면 읽기 프로그램 사용자에게는 “Responding... Time elapsed 1s... Responding... Time elapsed 2s...”처럼 반복해서 들림
  • 커서가 상태 표시, 스피너, 대화 기록 사이를 순간적으로 이동하면서 Speakup은 그 순간 커서 아래에 있는 내용을 읽으려 함
  • 결과적으로 타이머 갱신과 대화 조각이 섞여 들려 실제로 입력 중인 내용에 집중하기 어려워짐

• NVDA와 붙여넣기에서 발생하는 불안정

  • Windows에서 NVDA를 사용해 터미널을 열고, Linux 장비에 SSH로 접속한 뒤 screen 세션에 붙어서 텍스트를 붙여넣으면 NVDA가 즉시 크래시하거나 시스템이 크게 불안정해질 수 있음
  • 문자를 입력하거나 텍스트를 붙여넣을 때마다 애플리케이션 상태가 바뀌고, 프레임워크는 인터페이스를 다시 렌더링해야 한다고 판단함
  • 대화 기록이 상태에 포함되어 있으면 수천 줄의 텍스트 레이아웃을 즉시 다시 그리거나 다시 계산하려고 함
  • 대화 메시지가 많을수록 이 문제가 더 자주 발생함
  • 동적 콘텐츠 알림을 피하기 위한 Insert+5 조합으로도 이 문제를 피할 수 없음

• 입력 지연 루프

  • Ink 같은 프레임워크가 Node.js처럼 단일 스레드 환경에서 실행되면 기록이 커질수록 성능 저하가 커짐
  • 큰 텍스트 블록을 붙여넣으면 수천 줄에 대한 차이를 계산해야 함
  • 시스템이 화면을 다시 그리는 방법을 계산하느라 바빠져 입력 처리가 늦어짐
  • 키 하나를 눌러도 문자가 다시 표시되기까지 최대 10초까지 기다릴 수 있음

오래된 도구들이 작동하는 이유

• nano, vim, menuconfig 같은 도구가 접근성에 항상 완벽해서 쓰이는 것은 아님
• 핵심은 이 도구들이 커서를 완전히 숨기거나, 커서 위치 추적에서 생기는 소음을 줄일 수 있다는 데 있음

• nano와 vim: 커서 숨기기

  • nano를 --constantshow처럼 커서 위치를 표시하는 옵션으로 실행하거나, vim을 특정 설정 없이 쓰면 사용성이 깨질 수 있음
  • 커서가 보이고 추적이 활성화되면 Speakup은 문자 에코보다 커서 위치 갱신을 우선함
  • 사용자가 “a”를 입력했을 때 “a” 대신 “Column 2”를 듣고, “b”를 입력하면 “Column 3”을 듣게 됨
  • 이 오래된 도구들은 시각적 커서나 상태 표시줄 갱신을 억제하도록 설정할 수 있기 때문에 화면 읽기 프로그램이 좌표 갱신이 아니라 문자 입력 스트림에 의존하게 만들 수 있음
  • 현대 프레임워크는 보통 “no-cursor”나 “headless” 모드를 제공하지 않고, 시각적 커서가 필수라고 가정함

• menuconfig: 단일 열 포커스

  • Linux 커널의 menuconfig는 엄격한 단일 열 포커스를 유지하기 때문에 작동함
  • 테두리와 제목이 있어도 활성 영역은 세로 목록이며, 커서는 그 목록에 고정됨
  • 커서가 시계 갱신을 위해 오른쪽 아래로 이동했다가 제목 갱신을 위해 왼쪽 위로 이동하는 식으로 움직이지 않음
  • 공간적 복잡도가 낮게 유지되어 화면 읽기 프로그램이 길을 잃지 않음

• Irssi: 스크롤 영역 활용

  • Irssi는 운 좋게 접근 가능한 것이 아니라, 20년 넘게 커스텀 렌더링 엔진을 통해 VT100 스크롤 영역을 활용해 온 채팅 도구임
  • 새 메시지가 도착하면 터미널 드라이버에 “1행부터 23행까지를 스크롤 영역으로 정의하라”고 지시함
  • 이어 “위로 스크롤하라”는 명령을 보내고, 터미널이 내용을 위로 이동시킨 뒤 해당 영역의 아래쪽에 새 텍스트를 그림
  • 이 방식은 입력 줄과의 간섭을 최소화함
  • 화면의 모든 문자를 수동으로 다시 쓰기보다 터미널의 하드웨어 기능에 의존함
  • 현대 프레임워크는 이런 하드웨어 기능을 무시하고 화면 상태 차이를 계산해 문자를 다시 쓰는 방식을 택하는데, 이는 계산 비용이 더 크고 접근성에 적대적임

gemini-cli 이슈 처리의 문제

• Google과 gemini-cli 유지보수자는 접근성을 신경 쓰는 것처럼 보이지만, 저장소에서는 중요한 접근성 회귀가 방치되어 있음
• Issue #3435와 Issue #11305 같은 접근성 회귀에는 토론, 로드맵, 수정이 없음
• Issue #1553은 이런 접근성 실패를 추적하기 위한 이슈였지만 해결되지 않았고, 봇이 자동으로 닫음
• 봇은 오래 활동이 없고 백로그를 관리하기 위해 닫는다는 일반적인 문구로 이슈를 종료함
• 유지보수자가 몇 달 동안 손대지 않았다는 이유로 접근성 보고를 닫는 것은 정리가 아니라 증거를 숨기는 것과 같음
• 버그를 충분히 오래 무시하면 존재하지 않게 된다는 신호를 주며, 실제 소프트웨어는 시각장애인 사용자에게 여전히 사용할 수 없는 상태로 남음
• 프로젝트의 “Closed Issues” 지표는 좋아질 수 있지만 접근성 문제는 해결되지 않음

접근 가능한 터미널 도구를 만들기 위한 결론

• 터미널용 애플리케이션에서 접근성을 중요하게 생각한다면 터미널을 캔버스처럼 다루는 선언형 UI 프레임워크 사용을 멈춰야 함
• “현대적” TUI 스택은 개발자가 React처럼 코드를 작성하기 쉽게 하는 쪽으로 최적화됐고, 기계가 텍스트를 효율적으로 렌더링하는 능력을 희생함
• 애플리케이션이 사용자가 커서를 숨길 수 있도록 보장하지 못하거나, 스피너와 타이머를 표시하기 위해 공격적인 다시 그리기에 의존한다면 접근 불가능한 도구가 됨
• 시각장애인 사용자에게는 지연되고, 계속 읽을 내용을 쏟아내고, 커서를 화면 전체에 흩뿌리는 “스마트” TUI보다 단순하고 선형적인 CLI 스트림이 훨씬 나음

[GN⁺]

Hacker News 의견들

• Claude Code의 렌더링 UI를 보면서 TUI가 명령줄 인터페이스라기보다 DOS나 Borland식 UI 시스템에 가깝다는 걸 처음 깨달음
  CLAUDE_CODE_NO_FLICKER=1 설정을 살펴보다가, 이 TUI가 터미널 제어 코드로 여러 레이어를 겹쳐 보여주는 구조라는 게 보였음
  React용 Ink 터미널 구현도 읽어봤음: https://github.com/vadimdemedes/ink
  픽셀 기반 그래픽이 아니라 과거 WordPerfect나 WordStar처럼 보이게 되는 과정이 흥미로웠고, 시각장애 사용자 입장에서는 사용성이 비슷함. 다만 DOS 도구용 80x25 점자 패드는 이후의 화면낭독기들보다 더 잘 동작했던 기억이 있음

• 요즘 유행하는 TUI를 들여다볼수록 더 안 좋아 보임. 프로그래밍 초기부터 쌓인 최악의 관행을 전부 모아, 다루기 어렵고 무겁고 느린 젤리 덩어리로 감싼 느낌이며 자기 무게에 무너질 것 같음

  • 그런 것들은 터미널 UI가 아니라, 터미널 안에서 Windows 같은 그래픽 UI를 흉내 내는 시도에 가까움
    Windows가 흔하지 않거나 충분히 좋지 않던 시절 DOS에서 만들던 것과 같은 부류라서, 재앙이거나 실행되는 터미널의 능력을 이해하지 못한 채 만들어졌다는 게 놀랍지 않음

• TUI가 왜 인기 있는지 늘 조금 신기했음. 터미널의 힘은 스트리밍 모델에 있고, 조합 가능한 유틸리티는 그래픽 UI에서는 훨씬 드문 장점임
  터미널의 제약이 TUI 설계를 겉치레보다 도구의 목적에 더 집중하게 만들 수 있다는 점은 이해하지만, 개인적으로는 그렇게 설득력 있는 이유는 아님

  • Claude Code, OpenCode, Crush 같은 새 흐름의 TUI는 조합성이나 텍스트 스트리밍이 핵심이 아니라, 몇 가지 순풍이 겹친 결과에 가까움
    Vim/Neovim/tmux/zellij 등을 쓰며 터미널에서 사는 엔지니어 집단이 이미 꽤 있고, 많은 개발 작업이 터미널에서 스크립트를 실행하는 방식이라 가능한 한 많은 작업을 그쪽으로 옮기려는 수요가 있음
    macOS와 Linux 같은 주요 플랫폼에서는 패키지 관리자를 통한 배포가 사실상 해결돼 있지만, 크로스플랫폼 네이티브 앱 배포는 여전히 파편화돼 있음
    이런 수요와 배포상의 이점 덕분에 Ink for React, Bubble Tea for Go 같은 TUI 구성 요소가 많이 좋아졌고, Electron은 느리고 비대한 앱과 연결되는 이미지가 있어 개발자들이 꺼리는 편임
    결국 성공한 제품은 Claude Code가 Claude Cowork로 이어지고 OpenCode가 OpenCode Web을 추가하듯 다른 형태로 넘어가기도 하지만, 개발자 도구의 제품-시장 적합성을 TUI로 빠르게 시험하기가 더 쉽고, 다른 UI를 내놓은 뒤에도 많은 사용자는 계속 터미널에 남을 것임
  • vim 같은 기본적인 것에는 잘 맞지만, 거의 대부분은 일반 명령줄 도구나 웹 인터페이스가 더 낫다고 봄. 인기의 상당 부분은 터미널 창 10개를 띄운 해커처럼 느끼고 싶지만 실제로는 그래픽 UI 같은 경험을 원하는 데서 오는 것 같음
  • 요즘은 완전히 유행이 지났지만 TN3270을 떠올릴 수 있음. 스트리밍보다는 양식 기반이고 키보드 중심이었음
    그래픽 UI로도 쉽게 흉내 낼 수 있었겠지만, 키보드 단축키는 나중 일이 되어버렸음
    지금도 그런 오래된 작업 흐름을 그리워하는 사용자를 만나는데, 그들은 이를 “오래된 텍스트 인터페이스”, 즉 TUI라고 표현함. 자세히 들어보면 정말 원하는 건 눈 깜짝할 만큼 빠르고 단축키 중심인 흐름임. 데이터 입력을 할 때 중요한 건 애니메이션이 아니라 속도임
    초보자는 눈요기를 좋아하지만, 숙련자는 더 이상 거기에 신경 쓰지 않음
  • TUI는 ssh 위에서 추가 작업 없이 동작함
    터미널이 부과하는 제약 덕분에 앱들이 대체로 비슷하게 보이고 비슷하게 동작함. 바깥 세계에서는 사용자 경험 표준이 가능하다는 이유만으로 일상적으로 무시되지만, TUI는 말하자면 놀라움이 가장 적은 최적점에 있음
  • TUI의 힘은 몇 군데에 있음: 자원 사용량이 낮고, 마우스 의존이 적으며, vi 근육 기억에 맞는 키 바인딩을 더 많은 작업에 적용할 수 있고, 더 깊은 조직화가 가능함
    TUI 도구들 덕분에 필요할 때는 보이지 않는 나만의 IDE를 만들 수 있었음. guake와 yakuake 덕분에 숨길 수 있고, zellij 덕분에 프로젝트와 탭 단위로 정리됨. 지금처럼 여러 역할이 섞인 업무에는 완벽하게 맞음
    다만 누가 봐도 세련됐다고 부르지는 않을 것 같음

• 프로젝트 유지보수자 입장에서는 다르게 볼 수 있음. 프로젝트를 소유하고 유지하는 사람들이 이슈에서 Open과 Closed의 의미를 정할 수 있고, 사용자가 꼭 동의할 필요는 없음
  예를 들어 Open을 “아직 분류되지 않았거나 적극적으로 작업 중”이라는 뜻으로 쓰고, Closed를 “이 티켓을 봤지만 지금은 팀원이 작업하지 않기로 했다”는 뜻으로 쓸 수 있음
  즉 Closed가 반드시 “거절됐고 이 결정은 최종”이라는 의미일 필요는 없으며, “현재 작업 대상이 아니다”라는 뜻일 수 있음. 모두에게 직관적이지는 않아도, 프로젝트 구성원이 작업량을 정리하는 데 도움이 된다면 정당화 가능함

  • gemini-cli는 자원봉사자가 유지하는 오픈소스 프로젝트가 아님
    Google은 일반적으로 접근성을 잘 챙기려 하고, 대부분의 제품에 대해 적합성 보고서도 공개함: https://belonging.google/accessibility-conformance-reports/

• 이 평가에 동의함. 더 나아가 개발자들이 충분히 만족스러웠던 CUA, 즉 IBM의 Common User Access 인터페이스 표준을 지키고 더 정규화했다면 훨씬 쉬웠을 것임: https://en.wikipedia.org/wiki/IBM_Common_User_Access
  개발자들이 여러 UI 구성을 실험하고 싶다면 그렇게 하게 두되, 기계와 사람 모두가 호출할 수 있는 CUA를 뒤에 유지하면 됨. 아쉽게도 인간공학은 개발자들의 강점이었던 적이 없음

• 이는 TUI와 Windows 사이에서 잘 문서화된 문제임
  90년대에 대부분의 SAP 시스템이 AS/400 터미널에서 Windows NT로 넘어갔을 때, 생산성이 크게 떨어졌다는 반응이 많았음
  SAP에서 일한 적은 없지만 어머니가 그 일을 했고, 완전히 표 형태이며 기능키 기반이던 작업 흐름에서 마우스를 잡고 움직이고 많이 클릭하는 방식으로 바뀌었음. 여러 기능에서 탭 이동과 F 키가 사라졌음
  ESC ESC F4 F3 TAB TAB만으로 시스템 전체를 엄청난 속도로 가로지르는 모습을 보여주셨는데, 그건 실제 시스템도 아니고 터미널이었음
  요약하면 Windows 기반 앱은 발견 가능성과 신규 사용자에게 좋고, 터미널 기반 앱은 더 빠르고 기억 기반인 탐색과 고급 사용자에게 좋음

  • 그건 특정 그래픽 UI의 문제이지, 그래픽 UI라는 개념 자체의 문제는 아님. 좋은 그래픽 UI 프레임워크는 예측 가능성과 키보드 중심의 빠른 경로를 기본으로 포함해야 해서, 앱마다 그런 결정을 다시 하지 않아도 되어야 함
    실제로 전문가나 고급 사용자를 위한 성공적인 앱들은 모두 빠른 경로를 염두에 두고 만들어짐. 이유 없이 미움을 많이 받는 Microsoft의 리본도 그런 예시임. 키보드로 조작 가능하고, 사용자화할 수 있으며, 동시에 발견 가능함
  • 그 기능을 그래픽 UI 버전에서 보존하지 못할 이유는 전혀 없음. 시스템을 써본 적도 없고 쓰지도 않는 사람들이 다음 버전을 설계하라는 지시를 받을 때 흔히 생기는 사용자 경험 설계 실패지만, 그래픽 UI냐 TUI냐와는 별 관련이 없음
    그래픽 UI는 제약을 느슨하게 만들 뿐이고, 그래서 사용자 경험을 망치기가 더 쉬워짐

• TUI는 원래 단순한 선택지여야 했는데, 이제는 터미널 의상을 입은 웹 앱이 되어버렸음

  • 하지만 웹의 접근성 옵션도 없고, 좋은 텍스트 편집도 없고, 사용자화 옵션도 아주 기본적이며, 샌드박스에서 동작하는 대신 신뢰된 컴퓨팅 환경을 요구함
    웹 앱과는 거리가 멀고, 대부분의 축에서 훨씬 나쁨

• “텍스트니까 접근 가능하다”는 신화에 대해 말하자면, 그건 아님. 그렇게 믿는 사람은 없음
  개발자들이 그런 말을 하는 건 텍스트 문서에 대해서이고, 조건부로는 grep, cut, ls 같은 단일 명령 터미널 앱에 대해서임. TUI에 대해 그렇게 말했다고 보기는 어려움

• 문제는 선언형 UI 프레임워크를 쓰는 것 자체가 아니라, 이 프레임워크들이 출력하는 렌더링 엔진이 접근성을 고려하지 않는 데 있음

  • 글을 보면 선언형 UI도 올바르게 구현하고 잡음을 끄는 옵션을 제공하면 가능하다는 게 분명함
    하지만 아무도 거기에 신경 쓰지 않았고, 그냥 “터미널인데 예쁘게 만들자”에 그친 것 같음
  • 터미널에 애초에 접근성 지원이 있긴 한가?

• TUI는 창 같은 요소 없이 다시 발견될 것임. 아직 깨닫는 사람이 적지만, C64 콘솔처럼 스프라이트 기반이 될 가능성이 있음. 어딘가에서 이미 누군가 하고 있을지도 모름
  창과 패널은 이제 보내줘도 됨. 차분한 텍스트 환경은 2026년에도 여전히 인류 문화적 DNA의 일부이며, 이 매체에서는 엄청나게 덜 탐구돼 있음
  현대 웹의 인지적 공격성은 사실상 더 악몽에 가깝다고 봄. 이미지, 영상, 광고가 맥락 없이 뒤섞인 매우 환각적인 의미에서 그렇음

[GN⁺]

Lobste.rs 의견들

• 이 글은 다른 블로그 글들과 마찬가지로 AI 보조 작성 냄새가 강함
  LLM이 이런 식의 제목을 좋아함: “The Architectural Flaw”, “The Lag Loop”, “Why The ‘Old Guard’ Works”, “The Lost Art of Scrolling Regions”, “The ‘Stale Bot’ excuse: A Case Study in Neglect”

  • 제목부터 AI 양산 글처럼 읽힘. 주제 자체는 새로워서 스팸 신고는 좀 과했을 수 있지만, 1) 어디서나 반복되는 같은 문체를 더는 못 견디겠고 2) 내용의 정확성까지 의심하게 됨
    훌륭한 블로그 글이 될 수 있었는데, 작성자가 개요를 ChatGPT에 던져 넣고 끝낸 듯하면 독자와 저자 모두에게 손해임
  • LLM 글쓰기에서 제일 싫은 특징 중 하나가 “The <전혀 정립된 개념이 아닌 것>”처럼 써서 마치 정식 개념인 듯 보이게 만드는 것임
    아주 특수한 일회성 문제를 “고전적인” 문제라고 부르는 것도 마찬가지임

• 정말 우울함. 요약하면 Irssi처럼 접근 가능한 TUI도 있는데, 현대 TUI 프레임워크들은 그런 선례를 무시하고 격자 차이 계산과 커서 이동에 의존함
  화면 읽기 도구는 커서가 움직일 때 그 위치의 내용을 읽기 때문에, 결과가 뒤죽박죽이 되거나 엄청난 낭독 스팸이 발생함

• 여기의 기술 설명이 완전히 정확한지는 의문임
  특히 Ink는 오랫동안 증분 렌더링을 전혀 지원하지 않았고, Ink를 쓰는 앱 대부분도 아직 활성화하지 않음. 그 증분 렌더링도 라인 기반이라 실제 타이머 위치로 커서를 옮기지는 않음
  Gemini CLI는 증분 렌더링을 켜려면 대체 버퍼 사용이 필요하고, 이는 내장 화면 읽기 도구 친화 모드가 켜지면 비활성화됨. 관련 옵션 문서는 여기에 있음
  덧붙이면 Python의 rich/textual은 더 느리고 주로 단일 스레드인 언어 위에서도 Ink보다 훨씬 빠른 경우가 많음. 수천 줄 차이 계산이 반드시 그렇게 느린 것도 아니고, 10초씩 걸릴 정도는 아님
  사용자 경험이 답답하고 망가졌다는 점은 의심하지 않지만, 제시된 정확한 원인은 LLM 환각이거나 불완전한 정보에 기반했을 가능성이 있어 보임. Ink의 증분 렌더링은 켜져 있더라도 설명처럼 동작하지 않음
  실제로는 전체 화면 다시 그리기가 화면 읽기 도구를 혼란스럽게 만들고, 라인 기반 다시 그리기가 변경과 무관한 임의의 끊어진 텍스트 조각들을 다시 읽게 만드는 식으로 나쁠 가능성이 큼

• TUI만 탓하는 건 공정하지 않음
  진짜 문제는 거의 전체 스택의 접근성 지원이 형편없다는 데 있음
  첫째, GPU 렌더링 터미널 에뮬레이터 대부분은 시스템 제공 접근성 API를 전혀 쓰지 않음. 텍스트가 GPU로 렌더링되면 접근성 도구가 “읽을” 수 없고 이미지처럼 보일 뿐임. Kitty, Alacritty, WezTerm이 여기에 해당함. 내 터미널 Ghostty는 macOS에서 접근성 API로 읽을 수 있고, iTerm2와 Terminal.app도 가능함
  둘째, TUI가 접근성 정보를 터미널 에뮬레이터에 전달할 터미널 시퀀스나 표준 움직임이 전혀 없음. 터미널 셀, 실행 구간, 영역을 위한 ARIA식 주석에 해당하는 것이 필요하지만 그런 시도는 없음. TUI가 커서를 잘 다뤄도 많은 사용 사례에서 문제가 터질 것임
  예로 Ghostty에서 OSC133과 접근성 API를 통합해 각 셸 프롬프트, 입력, 명령을 단순 텍스트 박스가 아니라 구조적으로 의미 있는 요소로 노출하는 작업을 해왔음. 이는 터미널 명세, TUI, 터미널 에뮬레이터가 함께 맞물려야 함을 보여줌
  전체 스택이 썩어 있고, 진심으로 고치려는 사람도 거의 없음. 나도 시간이 제한되어 최선을 다할 뿐인데, 이건 생태계 정치까지 필요한 거대한 주제라 감당하기 어렵다
  보너스로, 멋지면서도 끔찍한 현실은 AI가 여기서 접근성 개선을 돕고 있다는 점임. 많은 AI 도구가 접근성 API를 이용하거나 남용해 창 목록을 읽고 입력을 수행함. 그래서 더 많은 앱이 AI 사용 사례 때문에 접근성 통합을 훨씬 진지하게 다루기 시작했음

  • 터미널이 정말 작은 브라우저가 되어 가는 중임

• Claude Code와 gemini-cli가 readline 기반이 아니라서 매일 화가 남
  몇몇 비슷한 키 입력은 넣었지만, 익숙한 readline 단축키의 긴 꼬리는 빠져 있음
  Anthropic은 “웹 개발처럼 만들어야 한다”는 판단이 실수였다고 인정하고 readline으로 다시 시작해도 됨
  이런 도구를 만드는 개발자에게 익숙한 개발 경험이, 도구를 쓰는 사용자에게 익숙한 사용자 경험보다 중요하다는 생각은 틀렸음

  • 이 문제의 큰 부분은 Ink가 사실상 렌더링 백엔드에 만족하고 입력 위젯을 제공하지 않는다는 데 있다고 이해함
    실제로 잘 유지되는 유명한 서드파티 해법도 거의 없음. 유연한 입력 상자가 필요하면 처음부터 직접 만들어야 함
    Textual의 훌륭한 Input 위젯이나, JS 생태계의 다른 라이브러리인 OpenTUI와 대비됨
  • readline은 GNU 라이선스 아닌가? 누군가 드디어 GPL이 아닌 버전을 만든 건가?
    LLM을 좋아하지는 않아서 UI가 나쁜 건 개인적으로 장점이지만, readline을 쓰지 않는 데는 이유가 있을 수도 있음

• kakoune, helix 같은 터미널 편집기는 “커서 숨기기” 요령을 쓰지 않는 한 접근성 기준을 통과하기 어려울 것 같음
  그래도 VS Code만큼 접근 가능하지는 않을 가능성이 큼
  VS Code 말고 접근 가능한 크로스플랫폼 IDE-lite나 IDE가 뭐가 있을까? VS Code의 점점 적대적인 태도는 마음에 들지 않음. JetBrains IDE일 수도 있겠음

  • emacspeak가 있고, Emacs에 매우 접근성 좋은 인터페이스를 제공함
    단점은 Emacs 자체는 크로스플랫폼이지만, emacspeak는 TTS 때문에 Linux에 약한 의존성이 있을 수 있다는 점임. 아니면 아닐 수도 있음. Windows에서는 시도해 본 적이 없음
  • 누구를 위한 접근성인지가 먼저임. 청각장애인을 위한 것이라면 현지 언어의 글과 현지 수어를 제공해야 함. 미국이라면 보통 ASL임
    시각장애인을 위한 접근성이라면 emacspeak나 플랫폼의 시각장애인용 접근성 도구가 필요함
    접근성은 스펙트럼이지 체크박스가 아님

• Links에는 별도의 브라유 터미널 모드가 있는데, 가짜 GUI 요소를 더 단순한 전체 화면 메뉴로 바꾸고 방향키 탐색도 줄 단위로 바꿈
  또 다른 흥미로운 사례는 edbrowse임. 시각장애인인 Karl Dahlke가 만든 텍스트 모드 브라우저인데, 더 인기 있는 텍스트 모드 웹 브라우저들과 달리 TUI를 쓰지 않고 ed 스타일의 명령줄 인터페이스를 사용함

• Ink 프레임워크라면 CLI가 CPU 100%를 쓰고 영원히 멈춘 채 긴 채팅 기록을 계속 다시 그리는 이유일 가능성이 큼. 안타까움