이번 주 개발자 커뮤니티의 화면 구성에서 낯익은 검은 창이 다시 보인다. 화려한 그래픽 대신 텍스트와 기호로 이루어진 TUI(텍스트 기반 사용자 인터페이스)가 작업 환경의 중심을 차지하고 있다. 개발자들은 마우스 클릭보다 키보드 입력의 즉각적인 피드백에 다시 반응한다. Claude(앤스로픽의 AI 모델)나 Codex(코드 생성 AI) 같은 도구들이 명령줄 인터페이스에서 큰 성공을 거둔 장면이 이를 증명한다.

OS별 GUI 전략의 붕괴와 파편화

Microsoft는 일관된 GUI 라이브러리 전략을 세우지 못했다. MFC(마이크로소프트 파운데이션 클래스), OLE(객체 연결 및 포함), COM(구성 요소 개체 모델), ActiveX(소프트웨어 구성 요소 표준)가 얽히며 개발 복잡성을 키웠다. 이후 WinForms(윈도우 폼), WPF(윈도우 프레젠테이션 파운데이션), Silverlight(실버라이트), WinUI(윈도우 UI 라이브러리), MAUI(멀티 플랫폼 앱 UI)를 차례로 내놓았으나 시장을 통합하지 못했다. 현재 많은 데스크톱 앱은 OS 네이티브 방식 대신 Electron(웹 기술로 데스크톱 앱을 만드는 프레임워크)에 의존한다.

Linux(오픈 소스 운영체제)의 UI 불일치는 설계 철학의 결과다. GTK(리눅스용 UI 툴킷)와 Qt(크로스플랫폼 UI 프레임워크)라는 두 거대 진영이 공존하며 각기 다른 목표를 추구했다. 배포판과 데스크톱 환경의 조합이 너무 다양해 기업들이 네이티브 앱 개발을 포기하고 Electron으로 선회하는 결과로 이어졌다.

Apple은 HIG(인간 인터페이스 가이드라인)라는 강력한 기준을 가졌으나 최근 이 일관성을 스스로 깨고 있다. Fitts의 법칙(대상 크기와 거리에 따라 이동 시간이 결정된다는 법칙)을 무시하는 창 조절 방식과 무분별한 아이콘 추가가 대표적이다. macOS(애플의 데스크톱 운영체제)는 더 이상 디자이너가 신뢰할 수 있는 안전지대가 아니다.

렌더링 속도보다 중요한 OS 통합의 가치

예전에는 메모리 점유율이 Electron 앱의 최대 약점으로 꼽혔다. 하지만 최근의 진짜 문제는 시각적 일관성 부족과 키보드 중심 작업 흐름의 단절이다. 64GB RAM을 탑재한 MacBook Pro 환경에서도 사용자는 네이티브 앱과 Electron 앱을 섞어 쓴다. VSCode(비주얼 스튜디오 코드)나 Cursor(AI 기반 코드 편집기) 같은 도구에서 에이전트 패널과 사이드바를 키보드만으로 오가는 경험은 여전히 부자연스럽다. 앱 내부의 동작이 시스템 메뉴에 통합되지 않는 샌드박스형 HTML 구조의 한계다.

새로운 UI 스택을 구축하려는 시도도 있었다. Google은 Dart(구글의 프로그래밍 언어)를 기반으로 Flutter UI(구글의 UI 툴킷)를 통해 새로운 기기용 인터페이스를 만들려 했으나 결국 포기했다. Zed(고성능 코드 편집기)는 Rust(시스템 프로그래밍 언어)로 GPUI(GPU 기반 UI 렌더러)를 개발해 빠른 속도를 구현했다. 그러나 빠른 렌더러보다 중요한 것은 운영체제와의 깊은 통합이다. 호스트 OS와의 바인딩이 부족한 빠른 렌더러는 개발자가 직접 연결 고리를 만들어야 하는 수고를 강요한다.

개발자가 체감하는 TUI의 가치는 자동화와 원격 실행의 용이성에서 나온다. TUI는 X forwarding(원격 서버의 GUI 창을 로컬로 전송하는 기술) 같은 복잡한 설정 없이도 클라우드 머신이나 iPad에서 GPU 서버로 접속해 즉각적으로 작동한다. 네이티브 UI 툴킷이 제 역할을 못 하는 빈틈을 TUI가 메우고 있는 셈이다. 인터페이스가 화려한 예술품이 아니라 사용자가 업무에 집중하게 만드는 도구로 돌아가려는 흐름이다.

인터페이스의 본질은 화려한 껍데기가 아니라 사용자의 사고 과정을 방해하지 않는 투명함에 있다.