터미널 사용자 인터페이스(TUI)와 명령줄 인터페이스(CLI)는 유닉스 문화의 상징처럼 여겨져 왔다. 그러나 보안 연구자이자 개발자인 저자는 최근 발표한 글에서, LLM으로 네이티브 그래픽 인터페이스를 손쉽게 만들 수 있게 된 지금이야말로 이 관계를 다시 따져볼 때라고 주장한다. 그는 몇 달 전 처음으로 진지한 맥 애플리케이션을 만든 이후, 그 이전 경력 전체를 합친 것보다 더 많은 네이티브 UI를 찍어냈다고 말한다. 흥미로운 점은 이 코드의 대부분을 직접 손으로 쓰지 않았다는 것이다. 그의 표현을 빌리면 코드를 '작성한' 것이 아니라 '소환했다'.
손으로 쓰지 않고 소환한 앱들
저자가 만든 결과물의 목록은 그 자체로 논지의 근거다. 마크다운 뷰어 MDV.app, SageMath(암호학자들이 쓰는 수학 시스템)의 계산기형 프런트엔드, 애플 뮤직 플레이어 'DJ Roomba', 자료를 넣으면 위키를 스스로 채우는 'Self Driving Wiki.app', GPT5를 감싼 식단 칼로리 추적기, TP-Link 센서로 집안 온도를 보는 메뉴바 앱, 그리고 애플 TV·Roku·Denon을 아우르는 통합 리모컨까지. 그는 이 앱들을 배포할 생각이 없으며, 심지어 SageMath 프런트엔드는 "이 글의 해당 부분을 캡처해 Claude에게 주면 알아서 쓸 만한 것을 만들어줄 것"이라고 적는다.
UI 코드가 새로운 영역을 개척하는 경우는 드물다. 대부분의 인터페이스는 어렵다기보다 지루하고, 반복적이며, 세밀하고, 플랫폼에 대한 개념적 지식을 요구한다. 잘하려면 수년이 걸리는 종류의 일이다. 바로 그렇기 때문에 저자는 이런 프로그램을 직접 손으로 쓰지 않겠다고 말한다. 그는 스스로 묻는다. 단 한 줄도 쓰지 않고 Music.app 인터페이스의 90%를 재현한 이것을, 나는 소프트웨어를 개발한 것인가 아니면 그냥 내 컴퓨터를 설정한 것인가.
CLI는 남기되 TUI는 그만
저자의 핵심 구분은 CLI와 TUI를 분리하는 데 있다. 둘 다 1970년대 텔레타이프와 단순 비디오 터미널의 제약에 맞춰 만들어졌지만, 시대에 뒤떨어지고 적대적이며 제약이 많은 성질은 TUI에 본질적으로 붙어 있고 CLI에는 그렇지 않다는 것이다. 그의 결론은 단호하다. CLI를 만드는 것은 거의 항상 좋은 생각이고, TUI를 만드는 것은 거의 항상 나쁜 생각이다. 그는 닐 스티븐슨의 1999년 에세이 'In The Beginning Was The Command Line'이 유닉스 문화의 성전이 되었지만 25년이 지난 지금 거의 유효하지 않다고 비판하며, 터미널이 존재하는 이유는 특별한 기계적 친화성이 아니라 단지 모뎀과 "유닉스 괴짜들이 Motif를 배우기 싫어했기 때문"이라고 꼬집는다.
기술적 논거도 제시한다. 에이전트는 애플이 권장하는 방식대로 SwiftUI를 사용해 합리적인 네이티브 인터페이스를 안정적으로 만들어낸다. 네이티브 앱은 서로 닮아야 하므로 이 '똑같음'이 오히려 장점이 된다. 반면 Ratatui, Textual, Bubbletea 같은 좋은 프레임워크를 쓰더라도 TUI는 스크롤, 드래그 앤 드롭, 텍스트 선택, 여러 개의 떠 있는 창, 이미지 처리 같은 기본기를 두고 터미널과 싸우며 네이티브가 기본 제공하는 수준에 점근적으로 다가갈 뿐이다. 날짜 선택기나 진행 표시줄 같은 컨트롤을 한 시간이면 그럴듯하게 만들 수 있지만, 시스템 위젯만큼 좋지도 않고 서로 잘 조합되지도 않는다.
반론에 대한 선제 방어
저자는 TUI 옹호론을 미리 반박한다. 정보 밀도가 높고 빠르며 키보드 친화적이라는 장점은 사실이지만, 이는 '오직 TUI만' 그렇다고 말할 때만 설득력이 있으며 그것은 거짓이라는 것이다. 밀도 높고 경제적인 GUI를 못 만들 이유는 없고 이미 만들어진 적도 있다. SSH를 통해 프로덕션에서 써야 한다는 논거에 대해서는, 프로덕션에 필요한 것은 UI가 아니라 맥북의 UI가 구동할 수 있는 CLI라고 답하며 Emacs TRAMP를 선례로 든다. 접근성 논거에 대해서는 자신이 당사자가 아님을 전제하면서도, 스크린 리더가 TUI의 테두리 장식을 '해시, 해시, 대시'처럼 한 줄씩 읽어버린다는 접근성 전문가의 증언을 인용해 오히려 반대일 수 있다고 지적한다. SwiftUI가 시각용 트리와 의미론적 접근성 트리를 별도로 유지하는 점도 대조적으로 언급된다.
한국 실무자 입장에서 이 글의 실용적 함의는 분명하다. 사내 도구나 개인용 유틸리티를 만들 때 관성적으로 터미널을 택하던 습관을 재고할 여지가 생겼다는 점이다. LLM이 UI 코드의 진입 장벽을 크게 낮추면서, '괴짜용으로 조밀하게 설계된 GUI'라는 그동안 방치되던 선택지의 비용이 급감했기 때문이다. 다만 저자 스스로 인정하듯 이 논의는 배포하지 않는 개인용 아티팩트를 전제로 한 것이며, 생성된 인터페이스의 시각 디자인은 "대체 선수 수준보다 한 발 앞선" 정도라는 겸손한 평가에 머문다. 유지보수, 팀 협업, 배포와 설치의 번거로움처럼 실제 제품화 단계에서 부딪히는 문제들은 이 글이 다루는 범위 밖에 있다는 점은 감안해서 읽을 필요가 있다.