TUI가 다시 돌아온 이유 — 명령줄의 복고와 현대적 재해석

TUI가 다시 돌아온 이유 — 명령줄의 복고와 현대적 재해석

터미널 기반 인터페이스(TUI)가 개발자 커뮤니티에서 다시 주목받고 있다. Electron 기반 앱의 한계, 네이티브 GUI 플랫폼의 전략적 분열, 그리고 클라우드 개발 환경의 확산이 맞물리며 텍스트 인터페이스의 가치를 재조명하고 있다.

네이티브 GUI의 전략적 실패

Windows, macOS, Linux는 각각 자신만의 GUI 문제를 안고 있다.

Windows는 일관된 GUI 라이브러리 전략 자체를 만들지 못했다. MFC에서 OLE, COM, ActiveX, WinForms, WPF, Silverlight, WinUI, MAUI에 이르기까지 Microsoft는 새로운 API를 만들 때마다 기존 것이 실패했음을 인정해왔다. Jeffrey Snover는 이를 두고 "Microsoft는 Petzold 이래로 일관된 GUI 전략이 없었다"고 평가했다. Windows가 시각적으로 통일된 모습을 보여주던 마지막 시기는 Windows 98나 Windows 2000에 가깝다.

macOS는 오랫동안 Apple의 Human Interface Guidelines가 세계적 표준으로 존중받았다. 그러나 최근 Apple은 Fitts의 법칙을 무시하고, 창 크기 조절을 사실상 불가능하게 만들며, 모든 메뉴에 아이콘을 강제로 추가하는 방향으로 나아가고 있다. 디자이너들이 "평화롭게 일할 수 있는 안전지대"로 여기던 macOS의 시대는 끝났다.

Linux의 불일치는 설계상 자연스러운 결과다. 서로 다른 팀이 서로 다른 목표를 추구하며 GTK와 Qt가 공존하는데, 이 둘은 Linux 밖에서는 널리 쓰이지 않는다. 배포판, 데스크톱 환경, 하드웨어 조합이 너무 다양해서 테스트 자체가 어렵기 때문에 많은 회사는 Linux 네이티브 앱 개발을 포기한다.

Electron의 한계

Electron 앱의 가장 큰 문제가 메모리 사용량이라는 인식이 있지만, 10년 사이에 메모리 가격은 급락했다. 더 근본적인 문제는 시각적 일관성 부족과 키보드 중심 작업 흐름의 부재다.

64GB RAM MacBook Pro의 Dock을 열어보면 네이티브 앱 8개와 Electron 앱 6개가 함께 있다. Cursor나 VSCode에서 에이전트 패널에 기능을 요청한 뒤, 키보드만으로 사이드 패널의 에이전트 목록으로 이동하거나 보관하는 작업은 자연스럽지 않다. 모든 macOS 앱에서 동일한 방식으로 가능해야 할 동작이 Electron의 샌드박스 구조 때문에 제대로 작동하지 않는다.

GPU 가속의 환상

시각적 일관성 문제를 해결하겠다고 나왔던 시도들도 희망적이지 않다. Google은 Flutter UI로 Dart 기반 크로스플랫폼 툴킷을 만들겠다고 했지만, 실제 제품 출시 전에 프로젝트를 포기했다. Zed는 Rust로 자체 GPU 렌더러(GPUI)를 만들어 속도를 추구했지만, 호스트 운영체제와의 통합이 부족하다는 한계가 있다.

결론은 명확하다. 빠른 렌더러보다 운영체제와 잘 통합되는 느린 렌더러가 낫다. 아무리 빠른 GPU 가속 텍스트 렌더링을 해도, 단축키가 운영체제 표준과 맞지 않으면 의미 없다.

TUI가 채우는 빈틈

TUI는 세 가지 핵심 강점을 바탕으로 부상하고 있다.

첫째, 원격 실행의 용이성. X forwarding은头痛를 유발하는 것으로 유명하지만, TUI는 SSH만으로 원격 머신의 앱을 자연스럽게 다룰 수 있다. iPad에서 GPU가 탑재된 클라우드 머신에 접속해서 코드를 편집하는 것도 가능하다.

둘째, 자동화 친화성. Automator의 쇠퇴를 떠올리는 맥락에서, TUI는 스크립트와 조합 가능한 자동화 인터페이스로 다시 가치를 얻고 있다.

셋째, Claude Code와 Codex의 영향. 명령줄에서 동작하는 AI 코딩 어시스턴트가 큰 성공을 거두면서, 개발자들의 시선이 다시 터미널로 향했다. Claude Code가 흐름을 백 배쯤 증폭시킨 것은 맞지만, Ratatui, Rich, fzf 같은 도구들이 Claude Code 이전부터 TUI 생태계를 확장하고 있었다.

필요한 방향

좋은 인터페이스는 사용자가 덜 생각하게 만드는 것이다. Command+C가 복사 단축키라면 어디서나 작동해야 한다. 특정 앱에서만 CTRL+Shift+C를 누르거나 우클릭 → 복사를 따로 기억해야 한다면, 그것은 인터페이스의 실패다.

John Loeber는 "체크박스도 시스템과 상호작용하기 위한 인터페이스"라고 표현했다. 인터페이스는 사용자에게 주의를 강요하는 것이 아니라, 작업을 완수한 뒤 자연스럽게 물러나야 한다. 서로 다른 외형은 예술에는 좋을 수 있지만, 목적 지향적 도구에는 적합하지 않다.

소프트웨어 개발자들은 코딩뿐 아니라 HCI(Human-Computer Interaction)의 기초를 배워야 한다. Nielsen Norman Johnson의 말을 빌리자면, UI가 이해되지 않으면 프로젝트는 실패 처리되어야 한다. 프로그래밍 자체는 이미 자동화되고 있는 시대에, 필요를 이해하는 데 대부분의 노력을 들여야 한다.

현재 TUI 생태계

Modern TUI는 과거의 curses 기반 도구와 결이 다르다. Rust의 Ratatui, Python의 Rich, Go의 tview 등이 제공한다. 이 도구들은 네이티브 GUI와 비교해 메모리 사용량이 현저히 적고, 바이너리 크기가 작으며, SSH만으로 어디서든 실행할 수 있다.

DHH의 Omarchy 프로젝트는 TUI, 웹앱, GNOME 스타일 네이티브 앱을 혼합한 구성으로, TUI를 즉각적 피드백과 "geek points"를 위한 도구로 활용한다. 대략 10년 전에도 BBEdit, TextMate, Notepad++, Sublime 같은 네이티브 편집기에서 Atom, VSCode로 이동하는 비슷한 흐름이 있었다.

Electron과 TUI 의존도가 줄어하려면,起码 하나 이상의 성공적인 범용 크로스플랫폼 UI 해법이 필요하다. 그것이 Flutter이든, 다른 것이든 상관없다. 중요한 것은 개발자들이 쓰고 싶어 하는 툴킷에 진입 장벽이 낮아야 한다는 점이다.

터미널이 다시 주목받는 이유는 단순하다. 네이티브 GUI 플랫폼들이 각각 자신만의 길을 잃고 있고, Electron은 메모리 절약 외에 해결하지 못한 문제가 많으며, 새 UI 스택은 아직 검증되지 않았다. TUI는 명쾌하고, 효율적이며, 어디서든 동작한다. 그리고 무엇보다, 사용자가 해야 할 일에 집중할 수 있게 해준다.

tags: TUI, CLI, 터미널, 개발도구, Electron, Ratatui, Claude, UX, 인테페이스

---

📚 출처

• https://news.hada.io/topic?id=29135