▲

터미널 UI 구축이 이제 쉬워졌다

 (hatchet.run)
4P by GN⁺ 6시간전 | ★ favorite | 댓글 1개
  • Claude Code를 활용해 Hatchet 팀이 터미널 기반 UI(TUI) 를 빠르게 개발한 사례를 소개
  • Charm 스택(Bubble Tea, Lip Gloss, Huh) 을 이용해 React 수준의 구성요소 기반 개발과 일관된 스타일링을 구현
  • 기존 웹 UI와 동일한 API를 사용하면서도 텍스트 중심·정보 밀집형 인터페이스로 개발자 효율을 높임
  • Claude Code가 tmux 세션을 구동하며 테스트를 자동화해, 반복 개발과 안정성 확보에 큰 역할을 함
  • 단 2일 만에 완성된 Hatchet TUI는 LLM 기반 개발의 실질적 생산성 향상을 보여주는 사례라고 평가

TUI 개발의 동기

  • Hatchet 팀은 k9s와 유사한 형태의 TUI를 원했으며, 사용자는 이를 웹 UI보다 빠르고 직관적이라 평가
    • 사용자 피드백 중 “CLI와 TUI가 훨씬 성능이 좋다”는 의견이 있었음
  • TUI는 코드와 동일한 환경에서 워크플로를 시각화·실행할 수 있어 탭 전환이 불필요함
  • Hatchet의 주요 사용자가 IDE 내에서 작업하는 개발자이므로, 터미널 내 워크플로 관리 경험을 제공하는 것이 목표였음

기술 스택

  • 일반적인 프런트엔드 스택(React, Tailwind 등)에 대응하는 Charm 스택을 사용
    • 주요 라이브러리: Bubble Tea, Lip Gloss, Huh
    • Charm 팀이 유지보수하며, 문서화와 예제가 풍부함
  • Lip Gloss와 Huh 테마를 이용해 TUI 전반에 일관된 스타일을 적용
    • Hatchet CLI 명령어에도 동일한 테마를 재사용해 통합된 사용자 경험을 제공
  • Bubble Tea 외의 커스텀 구성은 다소 어렵지만, React 기반 렌더링 엔진을 직접 구현하는 것보다 훨씬 단순함

테스트 접근법

  • Claude Code가 터미널 기반 도구를 직접 구동하며 테스트를 수행
    • tmux capture-pane을 이용해 렌더링된 뷰를 캡처하고 올바른 출력 여부를 검증
  • 이 방식은 첫 번째 테스트 패스 자동화에 매우 효과적이었으며, 뷰가 많아져도 안정적으로 렌더링 확인 가능
  • 이후 수동 테스트와 단위 테스트를 병행해 안정적인 반복 개발 루프를 형성
  • Claude Code는 ASCII 환경에서 반복 작업에 최적화되어 있어, 테스트 피드백 루프가 빠르게 수렴함

효율적 개발 환경 구성

  • Claude Code는 기존 Hatchet 프런트엔드 구현체를 참조해 개발 효율을 높임
    • React 기반의 단순한 컴포넌트 구조와 OpenAPI 스펙을 활용해 명확한 경계 설정
    • 자동 생성된 REST API 클라이언트를 통해 명세 기반 개발이 가능
  • DAG 기반 렌더러 구현은 가장 어려운 부분이었으나,
    • mermaid-ascii를 참고해 ASCII 그래프 렌더러를 성공적으로 구현
    • 완벽하지는 않지만 작동 가능한 DAG 시각화 기능 확보

결과와 교훈

  • 전체 개발 기간은 약 2일로, 이전 프런트엔드 리팩터링보다 훨씬 빠르고 안정적
  • Claude Code를 통한 개발이 비임의적이고 실질적인 생산성 향상을 보여준 첫 사례로 평가
  • Hatchet 팀은 앞으로도 비핵심 경로 기능에 LLM 기반 개발을 점진적으로 확대할 계획
  • 핵심 교훈은 짧은 피드백 루프, 모듈화, 명세 기반 설계, 지속적 테스트의 중요성
  • 완성된 Hatchet TUI는 https://tui.hatchet.run에서 공개되어 있으며, 사용자 피드백을 수집 중임
▲
GN⁺ 6시간전  [-]
Hacker News 의견들

  • 웹페이지가 터미널 UI 성능을 다루면서도, 정작 CSS 마스크 합성이나 큐빅 그라디언트 같은 복잡한 효과 때문에 내 고성능 Dell XPS 노트북에서도 스크롤이 끊기는 아이러니가 있음
    Gemini에 따르면 이건 “Scrim 또는 Easing Gradient”로, 16개의 색상 스톱을 사용해 부드러운 페이드를 만드는 대신, 스크롤할 때마다 수백만 픽셀의 색상 계산을 다시 하게 됨
    Firefox에서는 대부분의 페이지가 부드럽게 스크롤되므로, Mac이 아닌 iGPU 기반 hiDPI 노트북에서도 테스트해보길 권함
    참고로 그라디언트를 비활성화한 이미지도 있음 — 링크

    • 맞는 말임. 일단 그 효과를 제거하고 성능을 개선하거나 아예 없애는 방향으로 검토하겠음. 피드백 고마움
    • “Commodore 64 수준”이라니, 그건 너무함. C64는 사실 부드러운 스크롤링이 가능했음
    • Firefox나 다른 브라우저에서 CSS나 JS 없이 읽는 법을 공유함. busybox ssl_client와 grep을 이용해 HTML을 추출하고 Firefox로 여는 간단한 스크립트를 제시함
    • 블로그 글에서 Claude Code가 얼마나 자주 언급되는지 눈에 띄게 많았음
    • 내 Commodore 64를 탓하지 말길. 프로그램이 로드되면 50~60Hz로 아주 부드럽게 동작함

  • TUI가 GUI처럼 보이려는 시도는 좀 슬프다고 생각함. 접근성이 떨어지고, 구조가 납작해져서 사용자가 정해진 방식 외에는 쓸 수 없음. 반면 현대 GUI는 OS와 구조적으로 연결되어 훨씬 자유로움

    • 동의하지 않음. 어떤 문제 영역에서는 TUI가 훨씬 적합함. 예를 들어 Debian 패키지 설정 대화상자는 단순 텍스트보다 훨씬 편하고, SSH나 시리얼 콘솔에서도 잘 작동함. CPU 그래프를 보여주는 도구처럼 시각적 정보가 필요한 경우에도 유용함
    • 나는 Electron 앱을 또 설치하지 않아도 되는 점이 좋아서 TUI를 씀. 가볍고, 브라우저를 내장하지 않아 리소스 낭비가 적음
    • TUI의 제약이 오히려 UI 디자이너의 집중력을 높여준다고 느낌. 요즘 앱들은 메뉴가 숨겨져서 불편한데, TUI는 명확함
    • 터미널 안에서 모든 게 돌아가는 게 좋음. 내 워크플로우는 tmux 같은 멀티플렉서 중심이라, 별도 창이 뜨면 흐름이 깨짐. 제약이 오히려 단순함과 일관성을 줌
    • Emacs, Vim, mc, htop, mutt 같은 예시를 보면 TUI가 충분히 강력함. 모든 UI가 열려 있을 필요는 없음

  • 예전보다 TUI 개발이 훨씬 쉬워짐. BubbleTea, Textualize, Ratatui 같은 프레임워크 덕분임.
    LLM 덕분에 이런 툴을 빠르게 만들 수 있게 되었고, 나는 NTCharts라는 TUI 차트 라이브러리를 유지보수 중임
    Gemini의 공간 이해 덕분에 버그를 해결했고, 현재는 BubbleTea로 로컬 LLM 대화 뷰어를 만드는 중임
    관련 링크: NTCharts 이슈, thinkt 프로젝트

  • LLM 앱에서의 TUI 집착을 이해하지 못하겠음. VS2026의 Copilot을 보면, GUI가 훨씬 많은 정보를 빠르게 보여줌. 실시간으로 diff를 클릭해 확인할 수 있어 효율적임

    • 나는 VSCode를 쓰는데, AI 에이전트 사이드바를 별도 창으로 띄울 수 있게 되면서 Claude Code보다 훨씬 편해졌음. 시각적 정보 밀도와 정밀도가 TUI보다 훨씬 높음
    • 이유는 단순함. TUI는 파일 시스템 위에 UI를 빠르게 얹을 수 있는 가장 간단한 방법임. 웹 기술로 하려면 브라우저와 서버가 필요함
    • Claude Code의 기능은 좋지만, VSCode의 AI diff 미리보기 UI가 훨씬 낫다고 느낌. 다만 새 통합 버전은 아직 버그가 많음
    • 사실 이건 일종의 LARP(역할놀이) 같음. “진짜 해커”처럼 보이려는 상징적 행위일 뿐, 실제로는 React/CSS로 만든 웹앱임

  • LLM이 컴퓨팅 자원을 잠식하는 시대에, 오히려 가벼운 스택의 도구를 만드는 계기가 되었음.
    C로 작성해 CPU 성능을 수천 배 높이고 RAM을 절반으로 줄였음. TUI는 이런 효율성의 좋은 예임

    • 그래도 네이티브 GUI나 Flutter 같은 프레임워크가 TUI보다 성능이 더 좋을 수도 있음
    • LLM 학습에 쓴 에너지를 최적화로 얼마나 상쇄할 수 있을지 의문임
    • TUI는 의존성 감소에도 좋음. 예전엔 npm 패키지 100개가 필요했는데, 이제는 200줄짜리 JS로 충분함

  • Midnight Commander(mc) 는 여전히 최고의 TUI 중 하나라고 생각함. GUI 버전(Double Commander)과 거의 비슷한 기능을 제공하면서 원격에서도 실행 가능함.
    지금은 새 스킨을 작업 중이며, 다음 릴리스에 포함되길 바람

    • 개인적으로는 Far Manager나 Dos Navigator가 더 안정적이라고 느낌
    • mc 개발자들에게 감사함

  • Gemini가 내 DHT 스크레이퍼 프로젝트를 위한 TUI를 만들어줬음 — 이미지
    첫 버전은 CJK 문자 문제로 수정이 필요했지만, 전체적으로 인상적이었음. 덕분에 알고리즘에 집중할 수 있었음

    • 어떤 라이브러리를 사용했는지 궁금함
    • DHT 관련 프로젝트에 관심 있음. 검색 엔진 등에서 어떻게 활용되는지 알고 싶음
    • “DHT”가 Distributed Hash Table을 의미하는지 확인함. 멋진 TUI라고 평가함

  • TUI가 웹폼이나 GUI보다 나은 점을 잘 모르겠음. 대신 CLI 파이프라인 조합은 매우 강력하다고 생각함

    • 일부 기관(NSA, CSE, GCHQ 등)은 보안상 웹 관리 UI를 금지함. 그래서 우리 제품은 로컬 콘솔이나 SSH 기반 TUI로 관리함. 매우 제한된 SELinux MAC 설정을 사용함
    • CLI와 나란히 실행할 수 있는 앱에는 TUI가 편함. tmux/zellij로 창을 나누기 쉽고, OS 간 UI 차이도 적음
    • TUI는 SSH 환경에서 특히 유용함. 스마트폰 SSH 클라이언트에서도 잘 작동함
    • Gemini가 내 C# 프로젝트용 TUI를 만들었지만, 나중에 Kestrel 웹서버 내장이 더 낫다고 제안했음. 그 말이 맞았음
    • TUI는 좋은 키바인딩을 제공하고, 명령 실행 위치에서 바로 접근 가능해 빠른 작업에 적합함

  • Claude Code를 좋아하지만, React 기반 TUI 구조는 정말 비효율적이라고 느낌

    • 특히 긴 텍스트를 스크롤할 때 성능 저하가 심함. 처음부터 이런 구조였던 것 같고, 왜 고치기 어려운지 궁금함
    • 이미 렌더링이 JS로 되어 있다면, React를 재활용 엔진으로 쓰는 게 합리적일 수도 있음

  • Cursor CLI를 기반으로 나만의 프롬프트 프론트엔드를 만들었음 — 이미지
    git, diff, 채팅 히스토리를 통합했고, Tailscale을 통해 폰에서도 쉽게 접근 가능함.
    내 규칙을 인식하고 프로젝트를 grep할 수 있어 사용성이 매우 높음

답변달기