Hacker News 의견
  • 요즘 Rust로 만든 TUI가 많다는 게 흥미로움
    내가 아는 곳은 Awesome TUIs, terminaltrove, 그리고 Ratatui의 awesome 리스트 정도임

    • 요즘은 좋은 데스크톱 GUI 플랫폼이 거의 없어서 터미널이 오히려 더 매력적인 환경이 됨
      Qt나 GTK는 너무 크고, Windows는 자주 바뀌며, Electron은 다루기 싫음
      터미널은 최근에 품질이 좋아져서 작은 앱을 만들기엔 훨씬 쉬움
      LEGO로 멋진 걸 만드는 게 점토로 조각하는 것보다 쉽다는 비유가 딱 맞음
    • TUI 라이브러리들이 터미널 렌더링의 저수준 복잡성을 잘 추상화해서, 이제 터미널이 IDE 안의 캔버스처럼 느껴짐
      데이터 상태를 시각화할 때 브라우저 렌더링 파이프라인을 만들 필요가 없음
      참고로 이 예시 이미지가 있음
    • TUI는 대부분 크로스플랫폼이고, 터미널 안에서 바로 쓸 수 있어서 컨텍스트 전환이 적음
      Ghostty, WezTerm, Kitty, iTerm, Alacritty 같은 최신 터미널은 GPU 가속과 24비트 컬러를 지원함
      게다가 요즘 개발자들은 IDE보다 터미널에서 Claude Code, Gemini CLI, Codex 같은 도구를 더 많이 씀
    • 오랫동안 나쁜 웹 인터페이스에 시달려온 개발자들에게 TUI는 신선한 대안임
      제약이 많지만, 그 덕분에 엉망인 UI를 만들기도 어려움
      단순~중간 복잡도의 소프트웨어에는 정말 잘 맞음. 예로 Midnight Commander를 추천함
    • 나에게 TUI는 요즘의 과잉 디자인된 GUI 세계에서 벗어나는 탈출구임
      디자이너와 협업이 점점 관료적이고 비효율적으로 느껴짐
      TUI는 정보 밀도가 높고, 불필요한 여백이 적은 깔끔한 인터페이스를 강제함
  • Rust에서 TUI가 유행하는 이유는 GUI 상황이 너무 열악하기 때문임
    Rust GUI 라이브러리 설문을 보면 알 수 있음
    나는 Qt를 Rust에서 쓰고 싶지만 QML, Slint, GTK, 즉시 모드 UI 등은 원하지 않음
    Rust에서 Qt 같은 게 안 생긴다면 정말 아쉬운 일일 것 같음

    • 사실 Rust로 TUI를 만드는 사람들은 단순히 TUI를 좋아해서 만드는 것임
      Ratatui가 워낙 즐겁게 쓸 수 있는 프레임워크라서 GUI의 부재와는 상관없음
    • GUI는 어떤 언어로든 테스트, 접근성, i18n 같은 부담이 큼
      CLI로는 부족하지만 완전한 GUI는 과한 경우에, TUI가 그 중간 지점을 잘 채움
    • Rust에서 전통적인 GUI 프레임워크가 어려운 이유는 순환 참조 구조 때문임
      윈도우-컨테이너-버튼 간의 부모/자식 참조가 Rust의 소유권 모델과 충돌함
      Qt의 signal-slot 메커니즘도 Rust에서는 구현이 까다로움
    • 나도 Rust의 GUI 생태계가 힘들다고 느낌
      필요한 crate 대부분이 WIP나 방치 상태였음
      인기 있는 몇몇 대형 crate를 제외하면, 문서도 “C++ 문서 참고하라” 수준임
      Rust가 아직 젊은 언어라 그렇지만, 커뮤니티의 패키지 유지 열정이 부족한 게 더 큰 문제 같음
    • 참고로 Zed는 Rust로 만든 GUI 에디터임
      다만 GUI 부분이 Rust만으로 구현된 건지는 확실치 않음
  • 나는 완전히 터미널 안에서 살 수 있게 해줄 TUI 웹 브라우저를 기다리고 있음
    sixel이나 shader 같은 기술로 그래픽도 지원되니, 영상만 제외하면 충분히 가능할 듯함
    광고 차단이 쉬워서 기업들이 싫어할 수도 있지만, LLM용 브라우저로 포장하면 설득 가능할지도 모름

    • 하지만 굳이 왜 그렇게 해야 하는지 모르겠음
      터미널은 저해상도 문자 버퍼라서, 그냥 GPU 가속된 픽셀 렌더링이 훨씬 효율적임
    • Browsh라는 프로젝트가 있음
      Firefox를 headless로 돌리고, 결과를 ASCII로 터미널에 렌더링함. 꽤 멋짐
    • 나는 Chawan을 자주 씀. 꽤 괜찮음
    • 사실 90년대부터 이미 가능했음
      Lynxw3m이 대표적임
    • Rust는 아니지만 nimwave도 참고할 만함
  • 내가 만든 Markdown 뷰어 mdfried를 소개함
    Markdown의 원문 가독성은 좋지만, 브라우저에서 보는 게 더 편해서 헤더를 이미지로 렌더링하는 뷰어를 만듦
    폰트를 한 번 설정해야 하고, 인라인 이미지도 지원함
    이제는 Kitty의 text-sizing 프로토콜을 활용해 이미지 변환 없이 바로 렌더링 가능함

    • 정말 멋진 프로젝트임. 다만 Ghostty는 아직 그 프로토콜을 구현하지 않은 듯함
  • 네덜란드의 Teletekst가 SSH 인터페이스를 제공함
    이 기사에 따르면 Ratatui로 만들어졌고, ssh teletekst.nl로 접속 가능함

  • Ratatui로 만든 작은 앱을 테스트했는데, 단순한 텍스트 입력만으로 CPU 사용률이 8%까지 올라서 놀랐음
    공식 예제를 그대로 썼는데도 그랬음

    • 혹시 debug 빌드로 실행한 건 아닌지 물어봄. cargo run은 기본적으로 디버그 모드임
  • 내 오픈소스 프로젝트 TironCalc를 메인 저장소 ironcalc에 통합하고 싶음
    Rust와 Ratatui로 작업하기 좋은 프로젝트라고 생각함
    다만 Microsoft의 edit 프로젝트를 보고 나니 Ratatui가 최선인지 확신은 없음

  • 내가 만든 Ratatui 기반 TUI 게임 rebels-in-the-sky를 소개함

    • 게임을 실행해봤는데 정말 마음에 듦. Hattrick 같은 고전 축구 시뮬레이터 느낌에 더 세련된 감성이 있음
      다만 리포지토리의 비디오가 내 기기에서는 열리지 않음
    • 아트워크가 멋짐. GitHub에서는 비디오가 렌더링되지 않아 직접 mp4를 다운로드해야 했음
    • “은하계를 무대로 한 우주 해적 농구 P2P 게임”이라는 설명이 정말 인상적임
  • 게시물 제목이 좀 이상하다고 느낌
    Rust의 TUI 혁명에 대한 글일 줄 알았는데, 사실은 Ratatui로 만든 앱 모음이었음

    • 사실 이 crate 자체가 Rust의 TUI 붐의 원인이라는 뜻이었을 것 같음
      Go 진영의 Charm도 비슷한 역할을 함
    • 제목은 수정되었음. HN 가이드라인에 따라 원제목을 유지하되, 오해의 소지가 있을 때만 바꾸는 게 원칙임
    • Ratatui는 꽤 오래된 프로젝트로, 복잡한 TUI를 만들 때 내가 가장 먼저 찾는 도구임
    • 나도 이제 다른 대안이나 차별점을 찾아보고 싶어짐
  • 터미널에서 CLI 기반 에이전트를 폴더 단위로 실행할 수 있는 유틸리티가 점점 더 필요하다고 느낌
    예를 들어 법적 컴플라이언스 검사를 자동화하는 데 쓸 수 있을 것 같음

    • 이미 주요 코딩 에이전트들은 CLI 모드를 지원함
      Cline CLI, Opencode CLI, Codex CLI, Gemini CLI, Claude Code CLI 등 다양함