AI 요약
최근 IT 업계에서는 DHH(David Heinemeier Hansson)의 Omarchy 프로젝트가 TUI를 주요 인터페이스로 채택한 것에서 볼 수 있듯이 TUI가 다시 주목받고 있습니다. 이는 과거 BBEdit, Textmate와 같은 네이티브 에디터에서 VSCode 같은 Electron 기반 앱이나 Vim, Emacs 같은 TUI 에디터로 사용자가 이동했던 흐름의 연장선에 있습니다. 윈도우 진영은 1992년 MFC를 시작으로 WPF, Silverlight, WinUI, MAUI 등 수많은 GUI API를 선보였으나 일관된 표준 정립에 실패하며 개발자들에게 혼란을 주었습니다. 리눅스 또한 GTK와 Qt의 공존 및 수많은 배포판 환경으로 인해 네이티브 앱 개발과 테스트에 막대한 비용이 소요되는 구조적 문제를 안고 있습니다. 이러한 네이티브 GUI 개발의 높은 피로도와 기술적 공백이 결국 단순하고 강력한 TUI의 재부흥을 이끌고 있습니다.
핵심 인사이트
- DHH의 Omarchy 채택: 37signals의 DHH는 즉각적인 피드백과 개발자 특유의 감성을 위해 Omarchy 프로젝트의 3가지 UI 유형 중 하나로 TUI를 선택함.
- MS의 GUI 전략 실패: 1992년 Win32를 C++로 래핑한 MFC부터 시작해 OLE, COM, ActiveX를 거쳐 최신 MAUI에 이르기까지 마이크로소프트는 일관된 GUI 표준을 구축하지 못함.
- OS 통합성 결여: 윈도우 시스템에서 시각적 통합이 가장 완벽했던 마지막 시기는 Windows 98 또는 Windows 2000 시절로 평가받을 만큼 현재의 UI 환경은 파편화되어 있음.
주요 디테일
- 에디터 시장의 변화: 과거 네이티브 에디터(Sublime, Notepad++) 중심에서 현재는 Electron 기반(VSCode)과 고난도 학습 곡선을 가진 TUI(Vim, Emacs)로 양극화됨.
- 윈도우 API의 복잡성: Jeffrey Snover는 MS의 GUI 개발이 Kierkegaard의 철학 책보다 이해하기 힘들 정도로 인지적 복잡성이 높다고 비판함.
- 리눅스의 파편화: GTK와 Qt 프레임워크의 공존과 수많은 하드웨어/디스트로 조합으로 인해 네이티브 리눅스 앱 개발 대신 Electron이나 TUI를 선택하는 경향이 강해짐.
- 기능적 공백 발생: 새로운 UI 프레임워크가 등장할 때마다 샌드박싱과 보안 정책으로 인해 이전 프레임워크에서 가능했던 '강력한 기능'들이 제한되는 간극이 발생함.
- 개발 효율성: 복잡한 GUI 라이브러리를 테스트하고 유지보수하는 대신, 터미널 환경에서 안정적으로 작동하는 TUI가 대안으로 부상함.
향후 전망
- TUI 생태계 확장: 복잡한 설정 없이도 효율적인 작업이 가능한 고성능 TUI 라이브러리와 도구들에 대한 수요가 지속적으로 증가할 것으로 보임.
- 네이티브 앱의 위기: 윈도우와 리눅스 모두에서 네이티브 GUI 개발의 난이도가 해결되지 않는 한, Electron과 TUI의 양분 체제가 더욱 고착화될 가능성이 높음.
출처:hackernews