이 글은 다른 블로그 글들과 마찬가지로 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%를 쓰고 영원히 멈춘 채 긴 채팅 기록을 계속 다시 그리는 이유일 가능성이 큼. 안타까움
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”
훌륭한 블로그 글이 될 수 있었는데, 작성자가 개요를 ChatGPT에 던져 넣고 끝낸 듯하면 독자와 저자 모두에게 손해임
아주 특수한 일회성 문제를 “고전적인” 문제라고 부르는 것도 마찬가지임
정말 우울함. 요약하면 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으로 다시 시작해도 됨
이런 도구를 만드는 개발자에게 익숙한 개발 경험이, 도구를 쓰는 사용자에게 익숙한 사용자 경험보다 중요하다는 생각은 틀렸음
실제로 잘 유지되는 유명한 서드파티 해법도 거의 없음. 유연한 입력 상자가 필요하면 처음부터 직접 만들어야 함
Textual의 훌륭한 Input 위젯이나, JS 생태계의 다른 라이브러리인 OpenTUI와 대비됨
LLM을 좋아하지는 않아서 UI가 나쁜 건 개인적으로 장점이지만, readline을 쓰지 않는 데는 이유가 있을 수도 있음
kakoune, helix 같은 터미널 편집기는 “커서 숨기기” 요령을 쓰지 않는 한 접근성 기준을 통과하기 어려울 것 같음
그래도 VS Code만큼 접근 가능하지는 않을 가능성이 큼
VS Code 말고 접근 가능한 크로스플랫폼 IDE-lite나 IDE가 뭐가 있을까? VS Code의 점점 적대적인 태도는 마음에 들지 않음. JetBrains IDE일 수도 있겠음
단점은 Emacs 자체는 크로스플랫폼이지만, emacspeak는 TTS 때문에 Linux에 약한 의존성이 있을 수 있다는 점임. 아니면 아닐 수도 있음. Windows에서는 시도해 본 적이 없음
시각장애인을 위한 접근성이라면 emacspeak나 플랫폼의 시각장애인용 접근성 도구가 필요함
접근성은 스펙트럼이지 체크박스가 아님
Links에는 별도의 브라유 터미널 모드가 있는데, 가짜 GUI 요소를 더 단순한 전체 화면 메뉴로 바꾸고 방향키 탐색도 줄 단위로 바꿈
또 다른 흥미로운 사례는 edbrowse임. 시각장애인인 Karl Dahlke가 만든 텍스트 모드 브라우저인데, 더 인기 있는 텍스트 모드 웹 브라우저들과 달리 TUI를 쓰지 않고 ed 스타일의 명령줄 인터페이스를 사용함
Ink 프레임워크라면 CLI가 CPU 100%를 쓰고 영원히 멈춘 채 긴 채팅 기록을 계속 다시 그리는 이유일 가능성이 큼. 안타까움