TUI 좀 그만 만드세요

• 에이전트 덕분에 네이티브 UI를 직접 작성하지 않고도 개인용 도구를 만들 수 있게 됨

  • 몇 달 전 첫 본격적인 Mac 앱을 만든 뒤, 이전 경력 전체보다 더 많은 네이티브 UI를 짧은 기간에 구현함

  • 좋은 UI 코드는 지루하고 반복적이며 정밀한 데다 플랫폼 개념까지 알아야 해서 숙련에 오랜 시간이 걸리지만, 이제는 그 작업을 에이전트에게 맡길 수 있음

• MDV.app은 에이전트가 구현한 네이티브 Markdown 뷰어임

  • UI 자체는 새로운 문제를 풀지 않지만 손으로 작성하기에는 번거로운 작업이어서 거의 전부 생성했으며, 기능과 배경은 MDV에 관해 쓴 글에 정리해 둠

• SageMath도 계산기 형태의 SwiftUI 앱으로 바꿔 사용 중임

  • Math Academy의 Foundations I부터 Machine Learning까지 1년간 공부한 뒤, 암호학자들이 기본 수학 시스템으로 쓰는 SageMath에 네이티브 프런트엔드를 붙임

  • 이 앱은 세 가지 작업을 간소화함

    • 다변수 미적분으로 갈수록 유용한 Sage 출력을 LaTeX로 자동 렌더링함

    • 벡터·행렬·수식 객체의 메서드를 클릭으로 노출해 trig_simplify 같은 명령을 반복 입력하지 않아도 됨

    • 자주 쓰는 연산을 짧게 입력하는 작은 언어를 제공하며, [1,2;3,4]처럼 행렬을 표현하거나 수식의 gradient를 빠르게 구할 수 있음

  • 배포할 생각은 없으며, 이 부분을 캡처해 Claude에 주는 것만으로도 비슷하게 쓸 만한 도구를 만들 수 있음

###

• DJ Roomba는 Apple Music 인터페이스 대부분과 LLM 에이전트를 결합한 개인용 플레이어임

  • 라이브러리·최근 재생 목록·다음 트랙을 읽는 도구 호출을 내장해 상황을 짧게 설명하면 분위기에 맞는 재생 목록을 구성함

  • 합리적인 스키마의 SQLite 데이터베이스를 백엔드로 사용하며, 오래된 MP3 리핑 시절부터 남은 장르 레이블 때문에 장르 지도는 아직 정리가 필요함

  • 오랫동안 골칫거리였던 Music.app의 인터페이스를 90%쯤 재현했지만 코드 한 줄 직접 쓰지 않았기 때문에, 이를 소프트웨어 개발로 봐야 할지 컴퓨터 설정으로 봐야 할지는 모호해짐

• LLMwiki는 자료를 넣고 질문하면 스스로 문서를 작성하는 self-driving wiki임

  • DJ Roomba가 Responses API 클라이언트를 직접 내장한 것과 달리, 이 앱은 내부에서 claude -p를 구동함

  • 에이전트가 파일시스템을 탐색할 때 더 잘 작동한다고 보고 macOS 가상 파일시스템 확장을 생성함

    • SQLite 데이터베이스의 읽기 전용 뷰를 앱 sandbox 안에 마운트된 파일시스템으로 노출함

    • 꼭 필요하지 않은 설계였고 /Applications/에서 실행해야 하는 등 설치도 더 번거로워졌지만, LLM 이전 개발에서 즐기던 yak shaving을 여전히 경험할 수 있었음

• 식사 설명을 섭취량 추정치로 바꾸는 반자동 영양소 추적기도 자주 사용함

  • GPT5를 앞에 둔 단순한 에이전트 앱으로, spitball a guess on the calories ingested tasting cake batter and cream cheese frosting (but I didn't eat any cake)처럼 짧고 모호한 설명도 칼로리와 영양소 추정치로 변환함

• 집 안의 TP-Link 센서 온도를 보여 주는 메뉴 막대 앱도 생성함

  • 클라우드와 센서 pod에 직접 접근하는 서로 다른 두 로그인 경로가 있다는 점만 알 뿐, 통신 프로토콜과 HTTP API를 조사하는 작업은 전부 에이전트가 처리해 세부 구현을 설명할 수는 없음

• Apple TV·Roku TV·Denon receiver를 제어하는 macOS 메뉴 막대 범용 리모컨도 작동함

  • Apple TV와 직접 통신하기는 까다롭지만 이미 이를 해결한 Python 라이브러리가 존재함

  • 네이티브 Swift 앱에서 그 라이브러리를 그대로 사용하지 않더라도 frontier model에는 Python으로 구현된 기능을 Swift·C#·Brainfuck으로 옮기는 일이 사실상 같은 문제임

  • 생성된 SwiftUI 화면의 시각 디자인은 비판받을 수 있지만, 오랫동안 App Store를 사용해 온 경험상 모두 최소 기준보다 낫고 5년 전 macOS UI 담당자에게 받았다면 만족했을 만한 품질임

  • 이 도구들은 배포할 “앱”이라기보다 컴퓨터가 원하는 방식으로 일하게 만든 개인용 산출물에 가까움

    • Unix 사용자로서 예전에는 명령줄 언어로만 가능했던 맞춤 작업을 이제는 그래픽 인터페이스로도 똑같이 쉽게 처리함

CLI와 TUI를 구분해야 하는 이유

• CLI는 대체하기 어려운 용도가 있지만 TUI는 대체로 터미널의 한계를 떠안음

  • CLI와 TUI는 모두 teletype과 dumb video terminal의 제약을 감싼 1970년대 산물로, 그래픽 인터페이스보다 시대에 뒤떨어지고 불친절하며 제약이 많아지는 경향이 있음

  • 이런 한계는 TUI에는 본질적이지만 CLI에는 그렇지 않으므로, CLI를 만드는 일은 거의 언제나 타당해도 TUI를 선택할 이유는 드묾

  • TUI가 컴퓨터와 운영자 사이에 특별한 유대를 만들어서 살아남은 것은 아니며, modem 환경과 Unix 개발자들이 Motif를 배우고 싶어 하지 않았던 사정이 컸음

    • 1990년대 중반의 짧은 Motif 작업만으로도 29년간 UI 개발을 멀리할 만큼 어려웠던 반면 curses는 5분이면 기본을 익힐 수 있음

    • ChatGPT에 개념 설명을 생략하고 pico 구현에 필요한 최소 사항만 요청해 받은 코드를 컴파일하면 바로 작동할 정도로 구조가 단순함

• 네이티브 프레임워크는 표준 UI 동작을 기본 제공하지만 TUI는 이를 불완전하게 재현해야 함

  • 에이전트는 Apple의 지침대로 SwiftUI를 사용해 무난한 macOS 인터페이스를 안정적으로 만들 수 있으며, 네이티브 앱에서는 다른 네이티브 앱과 비슷한 모습이 장점으로 작용함

  • Ratatui·Textual·Bubbletea처럼 좋은 TUI 프레임워크를 써도 터미널과 싸우며 네이티브 프레임워크의 기본 기능에 점근적으로 접근해야 함

    • 스크롤과 scroll target, drag and drop, in-band signaling으로 테두리를 그리는 환경의 텍스트 선택, 여러 floating window, 이미지 처리가 모두 별도 난제로 남음

    • date picker·secure text field·progress bar·text editor 같은 표준 control은 한 시간 정도면 그럴듯하게 만들 수 있지만 시스템 widget보다 못하고, 서로 조합하려면 더 많은 작업이 필요함

• 높은 정보 밀도와 키보드 효율은 TUI만의 특성이 아님

  • TUI가 적은 키 입력으로 복잡한 작업을 빠르게 처리하고 높은 정보 밀도를 제공한다는 말은 맞지만, GUI가 반드시 반대여야 한다는 뜻은 아님

  • 많은 GUI가 일반 사용자를 겨냥해 그렇게 설계되지 않았을 뿐, 조밀하고 경제적인 GUI는 이미 구현된 사례가 있음

  • Magit이나 Lazygit의 장점을 담은 네이티브 UI를 저렴하게 실험할 수 있게 됐으므로, TUI의 장점은 오히려 더 많은 그래픽 인터페이스를 시도할 근거가 됨

• 운영 서버에는 TUI보다 원격 CLI와 로컬 GUI의 조합이 더 적합할 수 있음

  • production에서 필요한 것은 보통 서버 안의 UI가 아니라 MacBook의 UI가 구동할 수 있는 CLI임

  • bpftrace 작업에서 hash mark로 막대그래프를 거듭 만드는 경험이 이 문제를 잘 보여 줌

  • Emacs TRAMP는 SSH 연결을 감춘 채 원격 파일에 네이티브 편집 경험을 제공하고, LSP와도 연동되며 Magit까지 사용할 수 있다는 선례임

• 접근성은 TUI를 GUI보다 우선할 근거가 되지 못함

  • TUI가 접근성이 좋다는 주장은 사실이 아닐 가능성이 큼

  • 직접 접근성 기능을 사용하는 입장은 아니지만, screen reader가 TUI chrome의 줄별 갱신을 hash mark, hash mark, hash mark, hash mark, dash, dash처럼 모두 읽는 사례는 분명한 문제임

  • SwiftUI 같은 현대 네이티브 프레임워크는 처음부터 시각 UI tree와 의미 기반 accessibility tree를 따로 유지하도록 설계됨

  • 접근성을 제대로 지원하려는 TUI 프레임워크의 노력도 있으므로 TUI가 접근 불가능하다는 뜻은 아니지만, 접근성 자체가 TUI를 선택할 이유는 아님

• TUI의 강한 장점은 cross-platform 일관성이지만 개인용 도구에는 비용이 더 큼

  • 에이전트가 Windows와 Linux에서도 괜찮은 네이티브 UI를 만들 수 있으리라 보지만, 해당 desktop에서 직접 확인하지 않고 배포하는 것은 별개의 문제임

    • 누군가는 곧 실제로 보거나 써 보지 않은 앱을 출시하겠지만, 그렇게 할 생각은 없음

  • TUI라면 Linux 사용자도 개발자와 거의 같은 경험을 얻는다고 기대할 수 있다는 장점은 분명함

  • 다만 지금 만드는 도구는 타인에게 배포할 앱이 아니라 개인용이므로, 원하지도 않는 Linux 배포 가능성을 위해 TUI의 큰 제약을 감수할 이유가 부족함

• 몇 년 전에는 네이티브 UI가 너무 어려워 이런 주장이 현실적이지 않았지만 전제가 바뀜

  • 지난 10년 가까이 Electron 앱을 받아들인 것도 네이티브 UI를 잘 만드는 비용이 컸기 때문임

  • 이제 에이전트가 그 비용을 크게 낮췄으므로 네이티브 UI를 더 많이 선택할 수 있음

  • 직접 확인한 범위는 macOS뿐이며, Linux의 GTK 4와 Windows의 WinUI 3도 비슷하게 쉬울 것이라는 부분은 가정임

네이티브 macOS 앱을 만드는 과정

• 몇 가지 skill과 앱을 직접 조작할 수 있는 에이전트 환경이면 충분함

  • macOS design skill, 기본 typography skill, Paul Hudson의 SwiftUI skill을 사용함

  • 생성 코드의 관용적 Swift 스타일도 신경 쓰기 때문에 Airbnb의 Swift language skill도 추가함

  • computer-use 또는 Codex의 동등한 기능을 활성화해 에이전트가 앱을 보고 조작하게 하면, 작업을 맡기고 점심을 먹은 뒤 돌아와 즐겁게 디버깅할 수 있을 정도의 결과를 얻기 쉬움

• Xcode 없이 Makefile과 템플릿만으로 반복 개발함

  • 지인이 MDV를 직접 컴파일하려다 만든 Makefile 기반 빌드 절차를 Claude가 새 프로젝트마다 복사하도록 함

  • 현재 과정은 템플릿 앱 디렉터리를 복사하고 그 안에서 Claude나 Codex에 원하는 도구를 설명하는 것이 전부임

  • 현재 템플릿이 특별히 좋지는 않으므로 더 숙련된 사람이 제대로 된 SwiftUI proto-app을 만들 필요가 있음

  • TUI도 에이전트가 tmux에서 테스트하도록 하면 비슷하게 만들 수 있지만, 다시 TUI를 만들고 싶을지는 불분명함

개발 경계를 다시 생각해야 하는 이유

• 에이전트가 frontend·backend와 web·native 사이의 기존 경계를 대부분 약화시킴

  • 개인적으로 1990년대부터 Elm·Pine·Mutt를 거쳐 그래픽 mail reader를 쓸 수 있게 되자 바로 옮겼을 만큼 TUI를 좋아하지 않았으므로, 취향이 주장에 섞여 있음

  • 그래도 핵심은 터미널 미학의 호불호가 아니라, 이제 다양한 도구에 네이티브 UI를 기본 선택해도 제법 좋은 결과를 얻는다는 변화임

  • 지난 10년 동안 네이티브로 간주돼 온 것을 포함해 기존 UI 개발 방식의 비용 구조가 달라짐

• UI 코드를 만들지 않는 systems programmer라는 자기 규정을 재조정할 시점임

  • 좋은 UI에 관심이 없거나 1970년대식 미학을 선호하는 선택 자체는 문제없음

  • 다만 NetNewsWire·Transmit·Little Snitch·Audio Hijack 같은 인터페이스를 좋아하면서도 수백 개의 일회성 CLI 중 하나조차 네이티브 앱으로 바꿔 보지 않았다면 직접 시도해 볼 가치가 큼

  • 네이티브 UI를 한 번 만들어 보면 소프트웨어와 자신의 역할을 바라보는 방식이 달라질 가능성이 높음

^{source https://sockpuppet.org/blog/2026/08/20/stop-making-tuis/}

HN에서는 TUI를 없애기보다 작업과 사용자를 기준으로 인터페이스를 선택해야 한다는 반응이 우세했다. 터미널을 개발 환경의 중심으로 쓰는 이들에게 TUI는 낡은 GUI가 아니다. 키보드로 빠르게 조작하고, 여러 화면을 터미널 패널에 나란히 띄우며, 기존 명령어와 연결해 쓰는 실무 도구다.

가장 자주 언급된 장점은 원격 작업과 이식성이다. SSH와 tmux만 있으면 서버·가상머신·컨테이너에서도 같은 도구를 실행하고, 연결이 끊긴 뒤에도 작업을 이어갈 수 있다. 여러 운영체제를 지원하기 쉽고 실행이 빠르며 자원도 적게 쓴다. 완성도 높은 크로스플랫폼 GUI를 만드는 데 드는 시간과 리눅스 데스크톱 환경의 복잡성을 경험한 개발자일수록 TUI를 현실적인 선택으로 봤다.

물론 이미지 미리보기와 수식·그래픽 표현, 세밀한 문서 편집, 드래그앤드롭, 운영체제 기능 연동이 필요한 작업에는 GUI가 낫다. TUI는 접근성과 마우스 지원이 약하고, CLI만큼 자동화하기 쉬운 것도 아니다. AI가 개인용 GUI의 제작 문턱을 낮췄다는 점에는 공감이 있었지만, 화면 캡처와 프롬프트가 검증된 코드와 유지보수를 대신할 수 있다는 주장에는 경계가 따랐다.

결국 기준은 취향이나 개발자 정체성이 아니라 배포 대상과 실제 작업 방식이다. 원격 접속, 키보드 중심 조작, 낮은 자원 사용, 명령줄 도구와의 결합이 중요하면 TUI가 알맞다. 시각 정보와 접근성, 데스크톱 통합, 일반 사용자의 편의가 핵심이면 GUI가 맞다. AI가 구현 부담을 줄여도 사용 환경과 검증, 유지보수 비용까지 없애지는 않는다.