# TUI가 다시 돌아온 이유 > Clean Markdown view of GeekNews topic #29135. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=29135](https://news.hada.io/topic?id=29135) - GeekNews Markdown: [https://news.hada.io/topic/29135.md](https://news.hada.io/topic/29135.md) - Type: GN+ - Author: [xguru](https://news.hada.io/@xguru) - Published: 2026-05-04T09:06:39+09:00 - Updated: 2026-05-04T09:06:39+09:00 - Original source: [wiki.alcidesfonseca.com](https://wiki.alcidesfonseca.com/blog/why-tuis-are-back/) - Points: 1 - Comments: 3 ## Topic Body - **TUI**는 즉각적인 피드백, 자동화 용이성, 운영체제 간 동작 가능성 때문에 다시 주목받고 있으며, Claude와 Codex 같은 도구도 명령줄에서 큰 성공을 거둠 - Windows, Linux, macOS의 **네이티브 GUI**는 각각 불안정한 API 전략, 툴킷·환경 분산, 과거 가이드라인과의 일관성 약화로 개발자와 사용자 모두에게 부담을 키움 - **Electron** 앱은 메모리 사용량보다 시각적 일관성 부족과 키보드 중심 작업 흐름의 빈틈이 더 큰 문제이며, 메뉴와 단축키 통합도 약해짐 - Google의 Flutter UI 시도와 Zed의 **GPUI**처럼 새 UI 스택을 만들려는 움직임이 있었지만, 운영체제 통합이 부족하면 빠른 렌더러만으로는 충분하지 않음 - 좋은 인터페이스는 사용자가 덜 생각하게 만드는 **일관성**이 핵심이며, 개발자와 운영체제·툴킷 제작자는 UI 이론과 접근성 높은 툴킷에 더 투자해야 함 --- ### TUI가 다시 주목받는 배경 - DHH의 [Omarchy](https://omarchy.org)는 TUI, 웹앱, gnome 스타일 네이티브 앱이 섞인 형태로 구성되어 있으며, TUI는 즉각적인 피드백과 “geek points”를 위해 쓰임 - 약 10년 전 코드 편집기에서도 비슷한 흐름이 있었음 - BBEdit, Textmate, Notepad++, Sublime 같은 네이티브 편집기에서 Atom, VSCode와 그 파생 앱 같은 Electron 기반 앱으로 이동함 - 강한 선호를 가진 사용자들은 vim이나 emacs로 이동했고, 즉각적인 피드백과 높은 사용성을 얻는 대신 매우 가파른 학습 곡선을 감수해야 했음 ### 네이티브 GUI가 약해진 이유 - ## Windows - Windows는 일관된 GUI 라이브러리 전략을 만들지 못했고, 하나의 API가 성공하지 못하면 또 다른 API를 만드는 흐름을 반복함 - [Jeffrey Snover](http://www.jsnover.com)는 [Microsoft hasn’t had a coherent GUI strategy since Petzold](https://www.jsnover.com/blog/2026/03/13/microsoft-hasnt-had-a-coherent-gui-strategy-since-petzold/)에서 MFC, OLE, COM, ActiveX가 Windows 개발 전반에 복잡성을 퍼뜨렸다고 표현함 - Microsoft는 이후 WinForms, WPF, Silverlight, WinUI, MAUI를 거쳤지만 성공하지 못했고, 많은 엔터프라이즈·개인용 데스크톱 앱은 여전히 Electron 앱에 의존함 - Windows 전체가 시각적으로 일관되게 통합되어 있던 마지막 시기는 Windows 98 또는 Windows 2000에 가까움 - Domenic Denicola는 [Windows Native App Development Is a Mess](https://domenic.me/windows-native-dev/)에서 몇 년마다 OS와 UI API를 다시 만드는 비용이 크고, 샌드박싱과 기능 폐기 시도가 겹치면서 새 계층마다 이전 프레임워크에서 가능했던 일을 못 하는 빈틈이 생긴다고 봄 - ## Linux - Linux의 UI 불일치는 설계상 생긴 결과에 가까우며, 서로 다른 팀이 서로 다른 목표를 추구할 자유를 가졌음 - GTK와 Qt가 주요 프레임워크가 되었고, 둘 다 크로스플랫폼 네이티브 개발을 지향했지만 널리 쓰이는 영역은 주로 Linux임 - 서로 다른 툴킷으로 만든 Linux 앱은 나란히 놓아도 어느 정도 괜찮아 보일 수 있지만, Windows의 여러 프레임워크는 그런 수준의 조화를 이루지 못함 - 배포판, 데스크톱 환경, 하드웨어 조합이 너무 많아 테스트가 어렵기 때문에 많은 회사는 네이티브 Linux 앱을 만들지 않음 - 회사들은 보통 Electron으로 Linux를 지원하거나, 공개 API가 있을 때 오픈소스 커뮤니티가 직접 해결하도록 둠 - ## macOS - Apple의 [Human Interface Guidelines](https://developer.apple.com/design/human-interface-guidelines/)는 전 세계 사용자 인터페이스 수업에서 인용될 정도로 강한 기준이었음 - Xerox PARC와 Apple은 좋은 인간 인터페이스가 무엇인지 연구한 대표적 기관으로 꼽힘 - 최근 Apple은 과거의 가이드라인과 일관성을 깨는 방향으로 움직이고 있음 - macOS는 [Fitts의 법칙을 무시](https://news.ycombinator.com/item?id=45288997)하고, [창 크기 조절을 거의 불가능하게 만들며](https://noheger.at/blog/2026/01/11/the-struggle-of-resizing-windows-on-macos-tahoe/), [수정을 시도한 뒤에도 문제가 이어지고](https://noheger.at/blog/2026/02/12/resizing-windows-on-macos-tahoe-the-saga-continues/), [모든 메뉴에 아이콘을 추가](https://tonsky.me/blog/tahoe-icons/)하는 방향으로 가고 있음 - macOS는 더 이상 디자이너가 평화롭게 일할 수 있는 안전지대로 보기 어려워짐 ### Electron 앱의 한계 - 가장 많이 거론되는 문제는 **메모리 사용량**이지만, 지난 10년 동안 메모리 사용량은 줄어드는 추세였음 - 더 큰 문제는 **시각적 일관성 부족**과 키보드 중심 작업 흐름의 부족임 - 64GB RAM MacBook Pro를 쓰는 환경에서도 Dock에는 네이티브 앱 8개와 Electron 앱 6개가 함께 있음 - 네이티브 앱: TextMate와 macOS 시스템 유틸리티 - Electron 앱: Slack, Discord, Mattermost, VSCode, Cursor, Plexamp - Cursor와 VSCode 같은 앱에서는 에이전트 패널에서 기능을 요청한 뒤 키보드만으로 사이드 패널의 에이전트 목록으로 이동하거나 보관하는 작업이 자연스럽지 않음 - 이런 동작은 모든 macOS 앱에서 같은 방식으로 가능해야 하지만, 단축키가 있더라도 메뉴에 표시되지 않는 경우가 있음 - 지난 10년 동안 개발자들은 앱에서 가능한 동작을 메뉴에도 추가하는 일을 잊는 경향이 생겼고, 이는 애플리케이션이 샌드박스 안의 HTML로 구현되는 구조와 연결됨 - Slack은 다른 Electron 앱보다 이런 부분을 더 잘 처리하지만 완벽하지는 않음 ### 새 UI 스택을 다시 만드는 시도 - Google은 Dart와 함께 Android의 유산이 없는 새 운영체제와 새 기기용 UI 툴킷을 만들고자 했음 - Google은 [Flutter UI](https://docs.flutter.dev/ui)라는 새로운 UI 툴킷을 원했지만, 실제 제품이 출시되기 전에 프로젝트를 포기함 - 이런 시도는 독점적 지위나 충분히 큰 시장 점유율이 있어야 성공할 수 있음 - [Zed](https://zed.dev)는 Rust로 비슷한 방향을 택해 자체 GPU 렌더러 라이브러리인 [GPUI](https://crates.io/crates/gpui)를 만들었고, 이 라이브러리는 크로스플랫폼을 지향함 - GPUI는 속도가 빠르지만 호스트 운영체제와의 통합이 자체적으로 충분하지 않아 개발자가 필요한 바인딩을 직접 추가해야 함 - 빠른 렌더러보다 운영체제와 잘 통합되는 느린 렌더러가 더 나음 ### TUI가 채우는 빈틈 - Apple Automator의 쇠퇴를 떠올리게 하는 맥락에서, TUI는 자동화 가능한 인터페이스로 다시 중요해짐 - TUI는 원격 실행도 비교적 쉽고, 두통을 유발하는 [X forwarding](https://www.tomshardware.com/how-to/forward-x-session-ssh)에 의존하지 않아도 됨 - 네이티브 UI 툴킷이 실패하면 기본으로 돌아가게 되고, 그 결과 TUI가 선택지로 부상함 - Claude와 Codex는 명령줄에서 큰 성공을 거뒀고, 사용자는 주변 운영체제를 신경 쓰기보다 상호작용 자체에 집중할 수 있음 - TUI를 통해 클라우드 머신에서 코드와 앱을 다루거나, iPad에서 GPU가 탑재된 머신으로 원격 접속할 수도 있음 - TUI는 모든 애플리케이션이 서로 다르게 보이는 환경에서 Apple과 Microsoft가 남긴 빈틈을 채우고 있음 - 서로 다른 외형은 예술이나 컴퓨터 게임에는 좋을 수 있지만, 사용자가 자기 일을 하도록 인터페이스가 물러나야 하는 목적에는 적합하지 않음 ### 앞으로 필요한 방향 - John Loeber는 [Bring Back Idiomatic Design](https://essays.johnloeber.com/p/4-bring-back-idiomatic-design)에서 체크박스도 시스템과 상호작용하기 위한 인터페이스이며, 좋은 인터페이스는 사용자가 덜 생각하게 만드는 것이라고 봄 - 사용자는 많은 것과 상호작용하므로, 일관된 경험을 주는 동질적인 인터페이스가 필요함 - Command+C가 복사 단축키라면 어디서나 작동해야 하며, 특정 상황에서 CTRL+Shift+C나 우클릭 → 복사를 따로 기억해야 하는 방식은 불편함 - 모든 개발자는 소프트웨어뿐 아니라 일반적인 사용자 인터페이스를 좋게 만드는 이론을 배워야 함 - [Nielsen](https://www.nngroup.com/books/usability-engineering/) - [Norman](https://www.amazon.com/dp/0465050654/) - [Johnson](https://www.amazon.com/Designing-Mind-Understanding-Interface-Guidelines-dp-0128182024/dp/0128182024) - 사용자 디자인을 소프트웨어 공학 교육과정에서 중요하지 않은 소프트 스킬처럼 다루는 태도는 멈춰야 함 - 어떤 과정에서든 UI가 이해되지 않으면 프로젝트는 실패 처리되어야 하며, HCI 과정에서는 완벽한 UI를 목표로 해야 함 - 좋은 UI를 만드는 작업은 필요를 이해하는 데 대부분의 노력이 들어가며, 프로그래밍 자체는 이미 자동화되고 있음 - 운영체제와 툴킷 제작자는 개발자가 쓰고 싶어 하는 접근성 높은 툴킷을 만들고 진입 장벽을 낮추는 투자를 이끌어야 함 - 반드시 크로스플랫폼 지원을 주장하는 것은 아니지만, 그런 해법이 하나라도 있다면 Electron과 TUI 의존도를 줄이는 데 도움이 될 수 있음 ## Comments ### Comment 56791 - Author: colus001 - Created: 2026-05-04T10:55:16+09:00 - Points: 2 저도 그렇지만, 개발씬은 과도하게 유행에 민감하다고 생각합니다. TUI 는 그저 GUI 를 제대로 만들 능력 혹은 의지가 없는 회사들이 주도하고 있을 뿐, 얼마나 많은 사람들이 TUI 를 쓰고 있는건지 모르겠네요. ### Comment 56798 - Author: savvykang - Created: 2026-05-04T12:39:39+09:00 - Points: 1 어떤 빅테크도 브라우저를 버리지 않는 상황이 잘못된거 아닌가요 ### Comment 56781 - Author: neo - Created: 2026-05-04T09:06:40+09:00 - Points: 1 ###### [Lobste.rs 의견들](https://lobste.rs/s/quulrs/why_tuis_are_back) - 사람들이 차라리 **네이티브 앱**을 만들었으면 좋겠음. TUI는 명령줄 인터페이스와 진짜 GUI의 단점을 합친 형태처럼 보임 모든 TUI 프로그램은 스크롤을 직접 다시 구현해야 해서, 터미널이 픽셀 단위 스크롤을 지원해도 TUI 프로그램은 줄 단위 스크롤만 지원하고 동작도 제각각임. [senpai](https://sr.ht/~delthas/senpai/)의 스크롤백은 내가 쓰는 다른 프로그램들과 방식이 달라 자꾸 길을 잃게 됨 인터페이스가 단일 텍스트 패널 이상이라는 정보를 터미널에 드러낼 방법도 없어서 텍스트 선택이 자주 망가짐. 마우스 이벤트를 가로채면 가능하긴 하지만 그건 또 나름 별로임. TUI IRC 클라이언트에서는 텍스트 선택을 하려고 양옆의 잡다한 패널을 숨기는 단축키를 눌러야 했고, 꽤 바보 같은 절차였음 그리드에 맞춰야 한다는 제약은 레이아웃과 디자인 가능성을 크게 제한함. 클릭 가능한 버튼처럼 보이게 스타일링하던 방식, 컨텍스트 메뉴 같은 것들이 떠오름. 예전에 [이 문제를 불평한 적도 있음](https://tilde.town/~dzwdz/blog/tui.html) TUI가 늘어나는 건 **전통적 GUI 프레임워크** 상태가 좋지 않은 데서 온 안타까운 결과라고 봄. TUI 프레임워크는 비교적 안정적인 편이고, 아주 오래된 걸 써도 크게 거슬리지 않음. ncurses 프로그램은 지금도 자주 쓰지만 Motif 프로그램을 쓰는 모습은 잘 상상되지 않음 반면 GUI 프레임워크는 선택지가 많지 않고 유지보수가 훨씬 더 필요함. 데스크톱 환경은 바뀌고, GUI에 대한 기대도 커짐. TUI 접근성은 정말 별로라고 보지만 확신까지는 못 하겠음. 변화도 심해서 GTK2로 만들었더니 폐기 예정, GTK3로 올렸더니 GTK4로 가라는 식이 반복됨 냉소적으로 보면 Omarchy 같은 것에는 다른 요인도 있음. 일반 GUI인 xfce4-taskmanager는 지루하지만 TUI인 btop은 엄청 해커스러워 보임. 사람들은 터미널 미학을 좋아하고(/r/unixporn 참고), **분위기**를 위해 사용성을 희생할 의향도 있어 보임. [btop이 프로세스 목록을 실제로 페이드아웃시키는 모습](https://i.imgur.com/9ijtirR.png)을 보면 그렇다 - 웹 개발을 오래 하다가 **네이티브 애플리케이션 개발**을 해보고 싶었음. GNOME 앱을 만들려고 살펴봤는데 C++ 중심이라 꽤 낙담함 이제는 진입 장벽이 더 낮아졌기를 바랐음. 대부분의 개발자가 고수준 언어로 훈련받는 상황에서는 설득력이 약해 보이고, C++의 복잡성이 나를 겁먹게 하는 것 같기도 함 - 곁가지지만 왜 많은 채팅 클라이언트는 기록을 복사해 붙여넣으면 형식이 엉망이 되게 만드는지 모르겠음. Discord에서는 예를 들면 이렇게 나옴 [ 20:41 ] username1 : message1 [ 20:42 ] username2 : message2 Matrix 클라이언트인 **Nheko**는 한 번에 한 줄 넘게 선택도 못 하게 함 반면 IRC 클라이언트들은 기본적으로 이런 형태를 제공함 20:41 <username1> message1 20:42 <username2> message2 - 명령줄 인터페이스를 좋아하지만 TUI는 나도 별로임. 쓸 곳은 있지만 사실상 **거칠고 못생긴 GUI**에 가깝고, 터미널 공간을 낭비하는 경우도 많음 가끔은 말이 되지만 이상적으로는 작고 짧게 쓰는 앱이나 텍스트 편집 같은 예외에만 쓰는 편이 좋다고 봄 - TUI가 좀 약하다고 느끼지만, gtk 같은 UI 도구모음과 비교하면 그나마 덜 나쁜 선택임. 내가 좋아하는 TUI 앱들은 확장성이 좋고 빠릿하며 Linux 명령줄과 잘 통합됨 예를 들어 **lf, tig, kakoune**은 셸 스크립트와 잘 맞아서 같은 스크립트를 재사용하고 세 앱 모두에서 기능을 확장할 수 있음. 모두 alacritty에서 실행되기 때문에 세 앱과 셸 전반에서 동작하는 하이퍼링크도 만들 수 있음 꿈을 꿀 수 있다면 Emacs나 acme 스타일 통합을 허용하는 **단색 미니멀 GUI 도구모음**이 있었으면 함 - 대체로 동의하지만 **Tk**가 조용히 계속 굴러가며 지금도 유용하다는 점은 짚고 싶음. gitk 같은 예가 있음 - TUI가 어떻게 “자동화하기 쉽다”는 건지 모르겠음. 콘솔에 표시되는 GUI와 같은 것 아닌가? - 여러 TUI는 프로그램을 열 때 **스크립트 언어처럼 동작하는 플래그**를 제공함. 게다가 LLM이 제대로 된 네이티브 GUI나 JavaScript 성향의 Electron 앱보다 텍스트 기반 인터페이스와 상호작용하는 쪽이 더 쉽고 비용도 낮음 - 이 글은 TUI가 “돌아온” 핵심 이유를 놓쳤음. 그 주장 자체도 의심스럽지만, Claude 같은 코딩 에이전트가 대량으로 바이브 코딩되면서 최근 인기가 오른 건 맞아 보임 개발자들은 쉬운 선택을 좋아함. **크로스플랫폼 TUI**를 만드는 것이 GUI를 만드는 것보다 쉽기 때문임 웹 앱이 인기를 얻은 이유도 같음. 브라우저 도구로 크로스플랫폼 앱을 만들기 쉬웠기 때문이고, Electron이 뜬 이유도 크로스브라우저 지원 부담을 뺀 같은 맥락임. 반응형 UI를 만드는 일, UI를 크로스플랫폼으로 렌더링하는 일, 사용자 입력을 특히 접근성까지 고려해 처리하는 일은 모두 어려움. 그래서 개발자들은 이런 걸 쉽게 만들어주는 무언가에 바로 뛰어듦 최근에는 TUI 제작을 더 쉽게 만든 변화도 있었음. 고급 기능의 크로스플랫폼 지원이 나아지고, 복잡한 세부사항을 추상화한 유명 라이브러리들이 나왔고, 이런 것들이 최근 TUI 르네상스로 이어진 듯함 그 밖에 글의 논점들은 좀 의심스러움. 예를 들어 저자는 Electron 앱의 약점으로 일관성을 들지만, 인기 있는 TUI에도 관례를 제외하면 일관성은 거의 없음. 코딩 에이전트들은 비슷한 단축키를 채택했지만 대부분 같은 출처인 Claude를 베꼈기 때문임. 그 단축키는 코딩 에이전트 바깥으로는 잘 확장되지 않고, 내가 쓰는 대부분의 TUI는 단축키와 시각 언어가 꽤 다름 - “반응형 UI를 만드는 게 어렵다”는 말이 무슨 뜻인지 잘 모르겠음. 웹 쪽 이야기처럼 들리는데, 웹의 아이디어 일부가 관련될 수는 있어도 네이티브 GUI 이야기에서는 주제에서 벗어난 것 같음. 그냥 “좋은 UI를 만드는 것”이나 “UI 도구모음을 만드는 것”을 말한 건가? “UI를 크로스플랫폼 방식으로 렌더링하는 게 어렵다”는 말도 의문임. 호환 계층이 필요하고 플랫폼 수만큼 구현이 필요하긴 하지만, 단일 플랫폼 지원보다 그렇게 더 어렵지는 않아 보임. 물론 대상 플랫폼들의 렌더링 방식이 너무 달라 공통 API를 설계하기 어려운 경우라면 다르겠지만, 화면에 픽셀을 찍는 수준에서는 그렇지 않을 것 같음. 배율 같은 요소는 처리해야겠지만 그 이상은 꽤 직선적이어야 하고, 아니면 SDL도 있음 아마 모든 플랫폼에서 UI가 “네이티브처럼 보이게” 만드는 이야기를 한 것 같음. 그건 각 플랫폼의 선호 네이티브 GUI 도구모음을 써야 할 수 있고, 서로 매우 다를 뿐 아니라 저수준 렌더링 API보다 훨씬 크고 덜 안정적일 수 있음. 그런 건 인생이 너무 짧음. 색상 테마나 그래픽 스타일 일부를 바꿀 여지는 두겠지만 앱 수준 설정으로 둘 것임. 각 운영체제의 그래픽 설정을 읽느라 시간을 낭비하고 싶지 않음 “사용자 입력, 특히 접근성 처리가 어렵다”는 말도 이상함. 키보드와 마우스 이벤트를 듣는 건 **사소한 일**임. 접근성 측면에서는 제대로 된 키보드 탐색이 필요하고 전반적 사용성에도 중요하며, 표준 및 사용자 지정 단축키 지원도 필요하겠지만 전체적으로는 나머지보다 훨씬 쉬워 보임 **스크린 리더 지원**은 관련 플랫폼의 API와 플랫폼 간 차이에 따라 어려울 수 있지만, 그건 입력 문제라기보다 렌더링 문제에 더 가까움 - TUI는 “컴백”이라기보다 **네이티브 GUI 프로그래밍 지식**을 잃어버려서 가진 도구로 최선을 다하는 모습에 가까움. 일관된 개발과 투자가 부족했던 결과임 Qt 같은 몇몇 밝은 예외를 빼면 UI 문명이 붕괴했고 우리는 종말 이후를 사는 느낌임 [Preventing the Collapse of Civilization](https://www.youtube.com/watch?v=ZSRHeXYDLko) 강연과 운율이 맞는 것처럼 느껴지고, 이제 AI가 많은 코드를 쓰는 상황이라 이런 지식 붕괴가 더 확산될까 걱정됨 - lobste.rs에서 이 주제가 나올 때마다 끼어들었으니 여기서도 끼어들어야 할 것 같음. 모든 GUI “제국”이 눈앞에서 무너지고 있음. Windows, macOS, GTK, Mozilla 제품들 모두 그렇다 컴퓨터 과학판 **After Virtue**가 필요한 느낌이고, 어쩌면 Blow의 온라인 존재감이 그 역할을 하고 있는지도 모름. 어쨌든 일관성을 보여주고, 사용자를 존중하며, 학습과 정성을 보상하던 컴퓨터 인터페이스의 시절이 그리움 - 이 글은 실질적인 내용이 별로 없고, 저자가 다른 모든 것이 형편없다고 생각한다는 정도만 말하는 것 같음 한 가지 말하자면 **Emacs**는 텍스트, 키보드, 버튼, 리치 미디어 인터페이스를 위한 훌륭한 플랫폼임 - 사람들이 Go, Rust, 이제는 Zig로 ncurses가 아닌 **TUI 라이브러리**를 쓰기 시작했기 때문일 가능성이 큼. 그래도 ncurses가 필요했던 끔찍한 이식성 문제는 해결해줬음 그러고 나서 사람들은 새 터미널을 만들고 그쪽 기술도 밀어붙이기 시작함. 부분적으로는 C 대신 Go, Rust, Zig로 만들 수 있게 됐기 때문임 C와 C++보다 재미있고 덜 짜증 나는 좋은 선택지를 주면, 당연히 사람들은 더 새롭고 유용한 코드를 쓰기 시작함 - TUI가 돌아온 진짜 이유는 2026년에 **서명되고 공증된 GUI**를 배포하려면 Apple에 돈을 내고 Windows용으로는 인증기관에도 돈을 내야 하기 때문임 - 네이티브 TUI 바이너리도 같은 문제가 있지 않나? - 세부 정정: Zed의 GPU 가속 UI 라이브러리는 크로스플랫폼 API인 wgpu가 아니라 [gpui](https://crates.io/crates/gpui)임 - 글이 논지를 제대로 입증했는지는 잘 모르겠지만, MS-DOS 시대를 겪었고 TUI를 늘 좋아했던 사람으로서 끼어들어 봄. afl-fuzz를 써봤다면 아마 알 수 있을 것임 이론적으로 Linux에서 TUI는 훨씬 더 성공했어야 함. 텍스트 기반 미학을 좋아하는 기술 사용자층이 있었고, 투박하고 일관성 없는 GUI 환경이라는 “이점”도 있었음. 비디오 카드가 X 서버에서 제대로 동작하게 만드는 것부터가 문제였던 시절도 있었음 동시에 수십 년 동안 *nix 소프트웨어 개발자들은 오래되고 이국적인 터미널 유형까지 지원해야 한다는 의무감을 느꼈음. 애플리케이션이 DECwriter에서 제대로 렌더링되지 않으면 큰일이라도 나는 식이었고, 그런 제약 아래서는 좋은 TUI를 만들기 어려웠음 MS-DOS 시대에는 Microsoft, Borland, Norton 같은 업체들이 기능적이고 반응 빠른 텍스트 기반 인터페이스를 완성했음. Linux에서는 오랫동안 TUI 설계의 “정점”이 menuconfig라는 괴물이었고, 눈을 가늘게 뜨면 vim도 TUI라고 부를 수 있을 정도였음. 사람들이 실제로 텍스트 모드 콘솔을 쓰던 시절에 기억나는 좋은 Linux TUI는 Norton Commander에서 영감을 받은 파일 관리자 **Midnight Commander** 정도였음