왜 터미널 UI가 다시 뜨고 있나

네이티브 데스크톱 UI가 믿을 만한 선택지가 아니게 됨

• 글의 출발점은 꽤 단순함. 터미널 사용자 인터페이스(TUI)가 다시 뜨는 이유는 개발자들이 갑자기 옛날 감성에 빠져서가 아니라, 데스크톱 GUI 생태계가 너무 많이 흔들렸기 때문임.

  • DHH의 Omarchy도 TUI, 웹앱, GNOME 스타일 네이티브 앱이 섞여 있는 형태로 언급됨.
  • 저자는 이 흐름이 10년 전 코드 에디터 시장과 비슷하다고 봄. BBEdit, TextMate, Notepad++, Sublime 같은 네이티브 앱에서 Atom, VSCode 같은 Electron 앱으로 넘어갔고, 더 하드코어한 쪽은 Vim이나 Emacs로 갔다는 얘기임.

• 윈도우 쪽 비판은 꽤 세다. 마이크로소프트가 일관된 GUI 전략을 오래 유지하지 못했다는 것.

  • MFC, OLE, COM, ActiveX를 거쳐 WinForms, WPF, Silverlight, WinUI, MAUI까지 계속 새 레이어가 나왔지만, 개발자 입장에서는 “이번엔 뭘 써야 하지?”가 반복됐다는 주장임.
  • 새 프레임워크가 나올 때마다 이전에 가능하던 기능이 빠지거나 샌드박싱, 권한 제한, 지원 중단 이슈가 생기면서 앱 개발 난이도가 올라갔다고 봄.

• 리눅스는 애초에 다양성이 장점이자 문제였다는 쪽임.

  • GTK와 Qt가 양대 축이 됐고, 서로 다른 데스크톱 환경과 배포판, 하드웨어 조합을 다 테스트하기가 너무 빡셈.
  • 그래서 많은 회사가 네이티브 리눅스 앱을 만들기보다 Electron으로 감싸거나, 오픈 API만 열어두고 오픈소스 커뮤니티가 알아서 클라이언트를 만들게 둔다고 지적함.

• 맥도 예전만큼 “UI 일관성의 성지”가 아니라는 게 저자의 불만임.

  • Apple Human Interface Guidelines는 한때 UI 수업에서 교과서처럼 인용됐지만, 요즘 macOS는 창 크기 조절, 메뉴 아이콘, 피츠의 법칙(Fitts’ law) 같은 기본 원칙에서도 흔들린다고 봄.
  • 디자이너와 개발자가 “맥이면 그래도 괜찮겠지”라고 믿기 어려워졌다는 분위기임.

Electron은 이겼지만, 경험은 애매함

• Electron 앱은 현실적으로 엄청 많이 쓰임. 저자 본인도 피하고 싶다면서도 Dock에 네이티브 앱 8개, Electron 앱 6개가 있다고 씀.

  • 예시로 Slack, Discord, Mattermost, VSCode, Cursor, Plexamp가 언급됨.
  • 흔히 Electron 비판은 메모리 사용량으로 가지만, 저자는 64GB 램 맥북 프로를 쓰는 입장이라 메모리보다 UI 일관성과 키보드 워크플로가 더 큰 문제라고 봄.

• Cursor나 VSCode 같은 앱에서 OS 네이티브 앱이라면 자연스러워야 할 조작이 어색하다는 지적이 나옴.

  • 예를 들어 에이전트 패널에서 작업을 요청한 뒤, 키보드만으로 옆의 에이전트 목록으로 이동하거나 아카이브할 수 있느냐는 질문을 던짐.
  • 단축키가 있어도 메뉴에 드러나지 않거나, 앱 내부 HTML 샌드박스 안에서만 동작하는 식이면 macOS 앱다운 일관성이 깨진다는 것.

• Slack은 그나마 낫다고 평가하지만, 완벽하진 않다고 봄.

  • 핵심은 “웹앱을 데스크톱 창에 넣었다”가 사용자의 운영체제 습관까지 자동으로 가져오진 않는다는 얘기임.
  • 복사, 이동, 메뉴, 포커스 전환 같은 작은 조작들이 앱마다 달라지면 사용자는 계속 생각해야 하고, 그게 곧 나쁜 인터페이스라는 주장으로 이어짐.

새 UI 툴킷을 만드는 것도 만만치 않음

• 구글은 Dart와 함께 레거시 없는 새 운영체제와 Flutter UI를 꿈꿨지만, 실제 제품이 나오기 전에 접혔다고 언급됨.

  • 저자는 이런 시도는 기술만으로는 부족하고, 사실상 독점에 가까운 시장 지분이나 충분히 큰 생태계가 있어야 성공한다고 봄.
  • UI 플랫폼은 “좋은 아이디어”보다 “모두가 실제로 쓰는가”가 훨씬 중요하다는 얘기임.

• Zed는 Rust로 자체 GPU 렌더러인 GPUI를 만들었고, 이건 반대로 속도에 강한 접근임.

  • 다만 저자는 빠른 렌더링보다 운영체제와의 통합을 더 선호한다고 밝힘.
  • GPU로 직접 그리면 성능은 좋을 수 있지만, 각 OS의 메뉴, 접근성, 키보드 관습, 네이티브 동작을 개발자가 다시 붙여야 하는 부담이 생김.

그래서 TUI가 다시 설득력을 얻음

• TUI의 장점은 개발자 입장에서 너무 실용적임. 빠르고, 자동화하기 쉽고, 운영체제 차이를 상대적으로 덜 탐.

  • 원격 머신에서도 X forwarding 같은 골치 아픈 설정 없이 바로 쓸 수 있음.
  • GPU가 달린 원격 머신에 접속하거나, 아이패드에서 클라우드 개발 환경을 다루는 식의 워크플로와도 잘 맞음.

• Claude와 Codex 같은 AI 코딩 도구가 명령줄에서 성공한 것도 이 흐름 안에 있다고 봄.

  • 사용자는 운영체제 주변 장식보다 “무엇을 요청하고, 어떤 결과를 받고, 어떻게 반복할지”에 집중함.
  • TUI는 화려하진 않지만, 개발자 작업에서는 오히려 방해물을 줄여주는 인터페이스가 될 수 있음.

• 저자는 TUI가 예술적 UI나 게임 UI를 대체한다고 말하진 않음. 대신 업무용 도구에서는 일관성과 예측 가능성이 더 중요하다고 봄.

  • 애플리케이션마다 다르게 생기고 다르게 조작되는 세상에서는, 차라리 터미널의 단순한 규칙이 더 안정적인 기반이 될 수 있다는 것.
  • 특히 개발자 도구처럼 반복 조작, 자동화, 원격 실행이 중요한 영역에서는 이 장점이 꽤 큼.

결국 UI 기본기로 돌아가야 한다는 주장

• 마지막 메시지는 “개발자들이 UI 이론을 다시 배워야 한다”에 가깝다.

  • Nielsen, Norman, Johnson 같은 인간-컴퓨터 상호작용(HCI) 고전 이론을 소프트웨어 공학 교육에서 가볍게 보면 안 된다는 주장임.
  • UI가 말이 안 되는 프로젝트는 실패 처리해야 하고, HCI 수업에서는 완성도 높은 UI를 목표로 해야 한다고까지 말함.

• 운영체제와 툴킷 제작자도 책임이 크다고 봄.

  • 개발자가 쓰고 싶어 하는 접근성 좋은 툴킷을 만들고, 진입장벽을 낮추고, 오래 지속되는 플랫폼을 제공해야 한다는 것.
  • 꼭 모든 플랫폼을 하나로 통합해야 한다는 주장은 아니지만, 제대로 된 선택지가 있다면 Electron과 TUI 의존을 줄일 수 있다고 봄.

• 이 글이 한국 개발자에게 재밌는 이유는 내부 도구 설계와 바로 연결되기 때문임.

  • 사내 어드민, 배포 도구, AI 코딩 워크플로, 원격 개발 환경을 만들 때 “웹으로 대충 감싸면 끝”이 아닐 수 있음.
  • 반대로 모든 걸 예쁜 GUI로 만들 필요도 없음. 빠른 피드백, 키보드 흐름, 자동화, 원격 실행이 중요하면 TUI가 꽤 합리적인 답이 될 수 있음.

---

기술 맥락

• 이 글에서 말하는 선택지는 단순히 GUI냐 터미널이냐가 아니에요. 개발자 도구가 어떤 환경에서 반복적으로 쓰이는지 보고, 운영체제 네이티브 UI, Electron, TUI 중 어디에 무게를 둘지 정하는 문제에 가까워요.

• Electron은 배포 범위가 넓고 웹 개발자가 만들기 쉬워서 많이 선택돼요. 그런데 OS 메뉴, 키보드 포커스, 접근성, 네이티브 단축키 같은 부분은 자동으로 좋아지지 않거든요. 저자가 Cursor와 VSCode를 예로 든 이유도 여기에 있어요.

• TUI는 화면 표현력은 제한적이지만, 원격 실행과 자동화에서는 강해요. SSH로 접속한 서버, 클라우드 개발 환경, GPU 머신, 아이패드에서 붙는 터미널까지 같은 방식으로 다룰 수 있으니까 개발자 워크플로에서는 꽤 큰 장점이에요.

• Zed의 GPUI 사례는 “직접 렌더링하면 빠르다”와 “운영체제와 자연스럽게 붙는다”가 별개의 문제라는 걸 보여줘요. 렌더링 성능을 얻는 대신 메뉴, 접근성, 키보드 관습 같은 통합 작업을 앱 쪽에서 더 책임져야 하거든요.

• 그래서 내부 도구를 만들 때도 먼저 물어봐야 해요. 사용자가 자주 반복하는 작업인지, 원격에서 돌려야 하는지, 키보드만으로 끝내야 하는지, OS 네이티브 관습이 중요한지요. 답이 자동화와 반복 작업 쪽이면 TUI가 촌스러운 선택이 아니라 꽤 실용적인 선택이 될 수 있어요.