"TUI 그만 만들라"는 도발, 왜 개발자들을 갈라놓았나

요즘 개발자 도구를 하나 깔면 열에 아홉은 터미널에서 돌아갑니다. 화려한 박스와 색깔 있는 프로그레스 바가 까만 창을 가득 채우죠. 그런데 보안 연구자 토마스 프탁이 여기에 대고 “제발 TUI 좀 그만 만들라"고 했습니다. 로컬 웹 앱을 만들라는 겁니다. 이 짧은 주장에 개발자 커뮤니티가 정확히 반으로 갈렸습니다.

하나 밝혀둡니다. 이번 주제는 최근 30일 커뮤니티 데이터에 새로 잡힌 스레드가 거의 없었습니다. 그래서 아래는 논쟁의 기술적 맥락과 양쪽 논거를 중심으로 정리했습니다.

TUI가 뭐길래

TUI는 Text User Interface, 우리말로 텍스트 기반 사용자 인터페이스입니다. 까만 터미널 창 안에서 마우스 없이 키보드로 조작하는 프로그램을 말합니다. 파일 목록이 왼쪽에, 미리보기가 오른쪽에 뜨는 화면을 떠올리시면 됩니다. 명령어를 한 줄씩 치고 결과를 받는 CLI와는 조금 다릅니다. TUI는 터미널 안에서 화면 전체를 그려냅니다. 말하자면 터미널 속의 앱이죠.

git을 다루는 lazygit, 도커를 관리하는 lazydocker, 시스템 모니터인 btop 같은 것들이 대표적입니다. 최근 몇 년 사이 Rust와 Go로 만든 TUI 도구가 쏟아졌습니다. Charm이라는 회사가 만든 Bubble Tea 프레임워크는 GitHub 별을 3만 개 넘게 모았고요. Rust 진영에는 Ratatui가 있습니다. 예전엔 TUI를 만들려면 저수준 터미널 제어 코드와 씨름해야 했는데, 이 도구들이 그 장벽을 크게 낮췄습니다.

그래서 프탁은 뭐가 불만인가

프탁의 주장은 단순합니다. 그 노력으로 로컬 웹 앱을 만들라는 겁니다.

논리는 이렇습니다. TUI를 만드는 사람은 결국 UI 프레임워크를 다시 발명하는 셈입니다. 레이아웃, 스크롤, 포커스 이동, 텍스트 줄바꿈, 클릭 처리를 전부 직접 짜야 하죠. 그런데 브라우저는 이걸 이미 다 갖췄습니다. 무료로요. 로컬에 작은 HTTP 서버를 띄우고 브라우저 창을 열면 CSS 몇 줄로 끝날 일을, 터미널에서는 수백 줄로 씨름합니다.

접근성 문제도 있습니다. 스크린 리더는 브라우저의 시맨틱 HTML은 잘 읽지만, 터미널 화면에 그려진 박스 그림은 제대로 해석하지 못합니다. 시각장애가 있는 개발자에게 TUI는 사실상 벽입니다. 이미지나 그래프를 띄우는 것도, 복사 붙여넣기도 웹이 훨씬 낫고요. 터미널에서 긴 텍스트를 마우스로 긁으면 박스 테두리까지 딸려오는 경험, 한 번쯤 해보셨을 겁니다.

그런데 왜 다들 터미널로 몰려갔나

반대편 논리도 만만치 않습니다. 그리고 여기엔 2026년만의 이유가 있습니다.

AI 코딩 에이전트가 결정적이었습니다. Claude Code, Codex CLI, Gemini CLI, Aider까지, 지난 2년간 등장한 주요 AI 코딩 도구는 거의 전부 터미널을 택했습니다. 이유는 뻔합니다. AI 에이전트가 하는 일 자체가 파일을 읽고, 명령을 실행하고, 출력을 파싱하는 것이거든요. 이건 터미널의 본업입니다. 에이전트가 살아야 할 곳에 인터페이스도 같이 두는 게 자연스럽습니다.

SSH도 큽니다. 원격 서버에 접속해서 일하는 개발자에게 브라우저 기반 도구는 불편합니다. 포트 포워딩을 설정하고, 로컬 브라우저를 열고, 인증을 통과해야 합니다. TUI는 SSH 세션에서 그냥 실행하면 끝입니다. tmux 안에서 세션을 유지한 채 노트북을 닫아도 그대로 살아있고요.

조합 가능성도 빼놓을 수 없습니다. 터미널 도구는 파이프로 이어붙일 수 있습니다. 출력을 grep에 넘기고, jq로 파싱하고, 다른 도구에 던집니다. 웹 앱은 이런 식으로 조립되지 않습니다.

속도와 무게 이야기도 있습니다. Electron 앱 하나가 메모리 300MB를 먹는 동안 TUI는 10MB로 돌아갑니다. 실행도 즉각적이고요.

양쪽 다 맞는 지점

논쟁이 오래 가는 건 대개 양쪽이 서로 다른 걸 이야기할 때입니다. 이 경우가 그렇습니다.

프탁이 겨냥한 건 과잉 설계된 TUI입니다. 대시보드처럼 화면을 채우고, 마우스 클릭을 받고, 탭과 팝업을 흉내 내는 것들이요. 이런 건 확실히 웹으로 만드는 게 낫습니다. 브라우저가 30년간 다듬어온 걸 터미널에서 재구현하는 셈이니까요.

반면 TUI 옹호자들이 말하는 건 터미널 워크플로에 붙는 도구입니다. git 커밋을 고르고, 로그를 훑고, 프로세스를 죽이는 작업이요. 이건 이미 터미널에 있는 사람이 터미널에서 끝내는 게 맞습니다. 브라우저로 나갔다 오는 컨텍스트 전환이 오히려 손해입니다.

절충안도 나옵니다. 같은 도구가 터미널 모드와 웹 모드를 둘 다 주는 방식입니다. Jupyter가 커널과 프론트엔드를 분리한 것처럼요. 핵심 로직은 서버에 두고, 인터페이스는 상황에 맞게 고르는 겁니다.

그래서 어느 쪽이냐면

터미널이냐 웹이냐를 고르는 문제는 아닌 것 같습니다. 도구가 사용자를 어디로 데려가느냐가 관건이죠. 개발자가 이미 터미널에 있다면 거기서 끝내는 게 맞고, 시각적 탐색이 필요하다면 브라우저가 맞습니다. 문제는 그 판단 없이 “요즘 다들 TUI 만드니까"로 결정되는 경우겠죠.

마지막으로 깔아본 개발 도구는 어느 쪽이었나요. 그게 터미널에 있어서 좋았나요, 아니면 그냥 익숙해서 참고 쓰신 건가요.