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

> Clean Markdown view of GeekNews topic #26694. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=26694](https://news.hada.io/topic?id=26694)
- GeekNews Markdown: [https://news.hada.io/topic/26694.md](https://news.hada.io/topic/26694.md)
- Type: GN+
- Author: [xguru](https://news.hada.io/@xguru)
- Published: 2026-02-15T09:06:16+09:00
- Updated: 2026-02-15T09:06:16+09:00
- Original source: [hatchet.run](https://hatchet.run/blog/tuis-are-easy-now)
- Points: 22
- Comments: 1

## Summary

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

Hatchet 팀은 **Claude Code**와 **Charm 스택(Bubble Tea, Lip Gloss, Huh)** 을 결합해 단 2일 만에 React 수준의 구성요소 기반 **터미널 UI(TUI)** 를 완성했습니다. Claude Code가 tmux 세션을 구동하며 테스트를 자동화해 반복 개발 속도를 높였고, 동일한 API로 웹 UI와 TUI를 병행함으로써 **텍스트 중심·정보 밀집형 인터페이스**를 효율적으로 구현했습니다. 이 사례는 LLM이 실제 개발 생산성 향상에 기여할 수 있음을 구체적으로 보여줍니다.

## Topic Body

- **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](https://github.com/AlexanderGrooff/mermaid-ascii)를 참고해 **ASCII 그래프 렌더러**를 성공적으로 구현  
  - 완벽하지는 않지만 **작동 가능한 DAG 시각화 기능** 확보  
  
### 결과와 교훈  
- 전체 개발 기간은 **약 2일**로, 이전 프런트엔드 리팩터링보다 훨씬 빠르고 안정적  
- Claude Code를 통한 개발이 **비임의적이고 실질적인 생산성 향상**을 보여준 첫 사례로 평가  
- Hatchet 팀은 앞으로도 **비핵심 경로 기능**에 LLM 기반 개발을 점진적으로 확대할 계획  
- 핵심 교훈은 **짧은 피드백 루프, 모듈화, 명세 기반 설계, 지속적 테스트**의 중요성  
- 완성된 Hatchet TUI는 [https://tui.hatchet.run](https://tui.hatchet.run)에서 공개되어 있으며, 사용자 피드백을 수집 중임

## Comments



### Comment 51188

- Author: neo
- Created: 2026-02-15T09:06:16+09:00
- Points: 1

###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47005509) 
- 웹페이지가 **터미널 UI 성능**을 다루면서도, 정작 CSS 마스크 합성이나 큐빅 그라디언트 같은 복잡한 효과 때문에 내 고성능 Dell XPS 노트북에서도 스크롤이 끊기는 아이러니가 있음  
  Gemini에 따르면 이건 “Scrim 또는 Easing Gradient”로, 16개의 색상 스톱을 사용해 부드러운 페이드를 만드는 대신, 스크롤할 때마다 수백만 픽셀의 색상 계산을 다시 하게 됨  
  Firefox에서는 대부분의 페이지가 부드럽게 스크롤되므로, Mac이 아닌 **iGPU 기반 hiDPI 노트북**에서도 테스트해보길 권함  
  참고로 그라디언트를 비활성화한 이미지도 있음 — [링크](https://i.imgur.com/He3RkEu.jpeg)
  - 맞는 말임. 일단 그 효과를 제거하고 성능을 개선하거나 아예 없애는 방향으로 검토하겠음. 피드백 고마움
  - “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 이슈](https://github.com/NimbleMarkets/ntcharts/issues/7#issuecomment-3732895279), [thinkt 프로젝트](https://github.com/wethinkt/go-thinkt/blob/main/PROMPTS.md#2026-01-25t043612z)

- 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를 만들어줬음 — [이미지](https://imgur.com/a/u3KHbDT)  
  첫 버전은 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**를 기반으로 나만의 프롬프트 프론트엔드를 만들었음 — [이미지](https://imgur.com/a/HZOEvr7)  
  git, diff, 채팅 히스토리를 통합했고, **Tailscale**을 통해 폰에서도 쉽게 접근 가능함.  
  내 규칙을 인식하고 프로젝트를 grep할 수 있어 사용성이 매우 높음