TUI를 더 이상 만들지 말자 (번역)
원문: https://sockpuppet.org/blog/2026/08/20/stop-making-tuis/
우리 업계는 터미널과 커맨드라인 인터페이스에 대해 이상한 관계를 가지고 있다. 이제 이를 재평가할 때가 왔다.
최근에 주변 친구들에게 네이티브 유저 인터페이스를 만들어보라고 권하고 있다. 몇 달 전 처음으로 진지한 Mac 애플리케이션을 만들었는데, 그 이후로 내 경력 전체에서 이전에 만든 것보다 더 많은 네이티브 UI를 만들어냈다. 간단히 둘러보자.
[MDV.app, 네이티브 macOS 마크다운 뷰어]
이게 MDV.app이다. 누군가 진지한 마크다운 뷰어를 만들기 전까지는 세상에서 가장 위대한 마크다운 뷰어다. 나는 이 UI 코드를 거의 직접 작성하지 않았다. 왜 그래야 하나? 대부분의 유저 인터페이스처럼 MDV도 새로운 지평을 열지 않는다. 어려운 문제가 아니다. 하지만 좋은 UI를 만드는 것은 매우 어렵다: 이 코드는 지루하고, 반복적이고, 까다롭고, 플랫폼 개념 지식이 필요하다. 이런 작업에 능숙해지려면 수년이 걸린다. 그래서 나는 절대 이 프로그램을 직접 작성하지 않을 것이다. 대신, 나는 그것을 소환(summoned)했다.
[SageMath용 네이티브 계산기 스타일 프론트엔드]
지난 1년 동안 Math Academy에서 Foundations I부터 Machine Learning까지 공부했다, 짧게 말하면 “나는 스스로 미적분학을 가르쳤다”. 이건 암호학자들의 기본 수학 시스템인 SageMath용 네이티브 계산기 스타일 프론트엔드다. 세 가지 큰 기능: Sage 출력을 자동으로 LaTeX 렌더링, 포인트앤클릭으로 Sage 메서드 노출, “작은 언어” 단축 입력. “이 앱을 패키징하지 않는다. 가지고 싶다면 이 부분을 스크린샷 찍어서 Claude에 던져라.”
[DJ Roomba, Apple Music 플레이어]
내장 LLM 에이전트가 라이브러리/최근 재생/다가오는 트랙을 읽는 툴 콜을 가진다. “지하실에 액자 만들러 가는데 노스킵 플레이리스트 만들어줘” → “Kurt Vile과 Tom Petty 많이”. SQLite 백엔드. “Music.app을 쓰러뜨렸다. 하지만 한 줄의 코드도 작성하지 않았다. 나는 소프트웨어를 개발하는 건가, 아니면 내 컴퓨터를 설정(setting up)하는 건가?”
[Self Driving Wiki.app]
LLMwiki. 소스 자료를 먹이고 질문하면 위키를 직접 작성한다. 내부에서 claude -p를 구동하며, macOS 가상 파일시스템 확장을 소환해서 SQLite DB를 마운트된 파일시스템으로 노출시킨다. “불필요했을까? 그렇다. 하지만 이런 잡부 짓거리(yak-shaving)가 LLM 이전 시대 개발의 즐거움이었고, 아직도 가능하다는 게 기쁘다.”
[반자동 식품 매크로 트래커, 메뉴바 온도계, 메뉴바 Apple TV 리모컨]
Apple TV 리모컨 이야기: “Apple TV에 직접 말 거는 건 골치 아프다. 하지만 사람들이 이미 Python 라이브러리를 만들어놓았다. 나는 그 라이브러리를 ‘사용’하지 않는다, 이건 네이티브 Swift 앱이니까. 하지만 그건 중요하지 않다: Python으로 작성된 모든 것은 Swift, C#, Brainfuck으로도 구현된 것이나 마찬가지다. 프론티어 모델에게는 전부 똑같다.”
❦
우리는 해야 하니까 터미널 인터페이스를 만든다. 그래야만 하니까 만드는 게 아니다.
CLI와 TUI는 둘 다 1970년대의 산물이며, 텔레타이프와 덤프 비디오 터미널의 제약에 맞춰 포장되어 있다. CLI는 대체불가능한 목적이 있다, CLI를 만드는 것은 거의 항상 좋은 생각이다. TUI를 만드는 것은 거의 절대 그렇지 않다.
Neal Stephenson이 1999년에 쓴 “In The Beginning Was The Command Line”은 Unix 너드들을 Morlock으로, GUI 사용자를 Eloi로 묘사하며 업계를 20년 뒤로 물렸다. 현실에서 TUI가 존재하는 이유는 단 두 가지다: 모뎀(modems), 그리고 Unix 너드들이 Motif를 배우기 싫었기 때문이다.
TUI의 본질적 문제: Ratatui, Textual, Bubbletea 같은 좋은 프레임워크로도 네이티브 프레임워크가 기본으로 해주는 것에 점근적으로 접근하기 위해 터미널과 싸우고 있다. 스크롤, 드래그앤드롭, 텍스트 선택, 플로팅 윈도우, 이미지, 이 모든 것이 네이티브 UI에서는 기본으로 잘 작동한다.
❦
예상되는 반론들:
-
“TUI는 경제적이고 정보 밀도가 높다”, GUI도 밀도 높게 디자인할 수 있다. Magit이나 Lazygit의 훌륭함을 포착한 네이티브 UI를 보고 싶다(내가 직접 만들지 않아도).
-
“TUI는 SSH에서 작동한다”, 프로덕션에서 유저 인터페이스가 필요하지 않다. CLI가 필요하고, 그 CLI를 MacBook의 UI가 구동하면 된다. Emacs TRAMP을 확인하라.
-
“TUI는 접근성이 좋다”, 아마 거짓이다. 스크린 리더가 TUI 크롬을 라인별로 읽는 경험: “해시 마크, 해시 마크, 해시 마크, 대시, 대시”. SwiftUI는 처음부터 시각적 트리와 의미론적 접근성 트리를 분리해서 유지한다.
-
“TUI는 크로스플랫폼이다”, 에이전트가 Windows/Linux용 네이티브 UI도 만들어준다. 나는 출시하고 싶지도 않은 프로그램의 Linux 사용자를 위해 TUI의 어포던스를 감수할 필요가 없다.
2년 전만 해도 이 주장들은 어리석었을 것이다, 네이티브 UI가 합리적 요구사항이 아니었기 때문이다(그래서 Electron이 있었다). 하지만 더 이상 그렇지 않다.
❦
macOS 네이티브 앱 개발, Ptacek의 실제 워크플로우:
템플릿 앱 디렉토리를 복사하고 → Claude나 Codex를 열고 → 무엇을 만들지 말한다. Makefile 기반 빌드(Xcode 불필요). computer-use 활성화 → 실행하고 점심 먹으러 가면 → 돌아올 때쯤 디버깅하기 좋은 앱이 완성되어 있다.
“UI 자체를 혐오하거나 1970년대 미학을 고집하는 건 한 가지다. 하지만 NetNewsWire, Transmit, Little Snitch 같은 인터페이스를 좋아했던 Unix Morlock이라면, 아니, 비밀리에 Eloi 동조자였다면, 500개의 쓰레기 CLI 중 하나를 네이티브 앱으로 바꿔봐라. 생각하는 방식을 바꿀 것이다.”
❦
핵심 논점: 수십 년간 소프트웨어 개발을 프론트엔드/백엔드, 웹/네이티브로 나누어 온 경계를 에이전트가 대부분 해체했다. 이제 합리적인 기본값은 네이티브 유저 인터페이스를 만드는 것이고, 그 결과물은 꽤 괜찮을(good enough) 것이다.