터미널 UI도 이제 컴포넌트로 설계한다

터미널은 오랫동안 명령어를 입력하는 곳으로 취급됐습니다. 화면은 기능을 따라가는 부수적인 요소였고, 복잡한 인터페이스를 만들려면 개발자가 ANSI 코드와 키 입력, 화면 갱신을 직접 관리해야 했습니다.

AI 에이전트가 이 공간에서 코드를 읽고 파일을 바꾸고 명령을 실행하기 시작하면서 상황이 달라졌습니다. 사용자는 이제 터미널에서 답변만 읽는 것이 아니라, 에이전트가 무엇을 했고 다음에 무엇을 하려는지 판단해야 합니다.

termcn은 이 변화에 맞춰 나온 터미널 UI 컴포넌트 모음입니다. shadcn/ui처럼 컴포넌트를 프로젝트 안으로 가져와 직접 수정하는 방식을 택하고, Ink와 OpenTUI 위에서 동작합니다. 저장소는 2026년 7월 31일 기준 GitHub 별 987개를 기록하고 있습니다.

이 프로젝트를 단순한 “터미널을 예쁘게 만드는 도구”로만 보면 아쉽습니다. termcn이 보여주는 것은 터미널이 다시 제품 화면이 되는 과정, 그리고 AI 에이전트의 화면에서 무엇을 보여줘야 하는가에 대한 질문입니다.

터미널에 필요한 것은 버튼보다 작업 상태입니다

termcn의 공식 문서에는 레이아웃, 입력, 선택, 데이터, 피드백, 내비게이션 컴포넌트가 정리되어 있습니다. Data Grid, Diff View, Git Status, Command Palette, Progress Bar처럼 전통적인 업무 도구에 가까운 부품도 있고, Chat Message, Tool Approval, Streaming Text, Thinking Block처럼 AI 에이전트를 직접 겨냥한 부품도 있습니다.

목록만 보면 웹 UI 라이브러리를 터미널로 옮긴 것처럼 보입니다. 하지만 AI 에이전트에서 중요한 것은 버튼의 모양이 아닙니다. 사용자가 다음 질문에 답할 수 있어야 합니다.

지금 에이전트는 어느 단계에 있는가
어떤 파일과 시스템에 접근했는가
다음 명령은 무엇이며, 내가 승인해야 하는가
결과는 모델의 추정인가, 실행과 테스트로 확인된 사실인가
문제가 생기면 어디까지 되돌릴 수 있는가

채팅 메시지는 에이전트가 무엇을 말했는지를 보여줍니다. 반면 도구 승인, diff, Git 상태, 진행률은 에이전트가 무엇을 했는지와 무엇을 하려는지를 보여줍니다. 에이전트가 대화를 넘어 실제 작업을 수행할수록 후자의 비중이 커집니다.

termcn의 방향은 이 점에서 명확합니다. AI 화면을 별도의 특수한 화면으로 만들기보다, 작업 상태를 표현하는 일반적인 UI 부품과 한 공간에 놓습니다. 에이전트는 대화를 하면서 파일을 바꾸고, 도구를 호출하고, 구조화된 결과를 내놓기 때문입니다.

shadcn/ui의 핵심은 ‘예쁜 기본값’이 아니라 소스의 소유권입니다

termcn의 설치 방식은 shadcn/ui와 닮았습니다. 전통적인 컴포넌트 라이브러리는 패키지를 설치하고 라이브러리가 정한 API와 스타일 시스템 안에서 사용합니다. shadcn/ui는 컴포넌트 소스 코드를 프로젝트로 가져옵니다. 이후의 수정과 책임은 사용하는 팀에 있습니다.

이 차이는 터미널에서 더 중요할 수 있습니다. 터미널 앱은 불특정 다수를 위한 서비스 화면보다 내부 도구나 개인 워크플로에 가까운 경우가 많습니다. 팀마다 승인 기준이 다르고, 로그를 보여주는 방식도 다르고, 한 화면에 담아야 할 정보의 밀도도 다릅니다.

완성된 테마를 강제로 적용하는 것보다 검증된 상호작용을 부품으로 가져와 각 팀의 운영 방식에 맞게 바꾸는 편이 현실적입니다. termcn이 제공하는 여러 테마와 레지스트리는 시각적 일관성을 만드는 장치이면서, 동시에 팀이 자기 도구의 화면 언어를 소유하도록 하는 장치이기도 합니다.

다만 여기서 shadcn의 철학을 표면적인 설치 명령으로만 이해하면 안 됩니다. 소스 코드를 직접 가져온다는 것은 수정할 자유와 함께 유지보수 책임도 가져온다는 뜻입니다. 컴포넌트가 업데이트될 때 자동으로 따라가지 않을 수 있고, 접근성이나 키보드 동작의 문제를 팀이 직접 책임져야 할 수도 있습니다.

Ink와 OpenTUI는 서로 다른 진입로를 만듭니다

termcn은 Ink와 OpenTUI를 함께 다룹니다.

Ink는 React를 CLI로 가져오는 렌더러입니다. 공식 저장소는 React 컴포넌트 방식과 Yoga의 Flexbox 레이아웃을 이용해 터미널 UI를 만든다고 설명합니다. React를 이미 알고 있는 개발자라면 브라우저에서 익숙한 사고방식으로 CLI를 만들 수 있습니다. Claude Code, Gemini CLI, GitHub Copilot CLI 등 여러 도구가 Ink 사용 사례로 소개되어 있기도 합니다.

OpenTUI는 다른 층위의 기반입니다. Zig로 작성한 네이티브 터미널 UI 코어에 TypeScript 바인딩을 제공하고, React와 Solid 리컨실러를 지원합니다. 공식 저장소는 OpenCode가 OpenTUI를 실제 제품에서 사용한다고 밝히고 있습니다.

둘을 함께 놓으면 터미널 UI가 두 방향으로 확장되고 있다는 점이 보입니다. 하나는 웹 개발자가 익숙한 React 방식으로 빠르게 진입하는 방향이고, 다른 하나는 성능과 렌더링 정확성, 키 입력과 스트리밍을 더 세밀하게 제어하는 방향입니다.

termcn은 이 두 진입로 위에서 같은 컴포넌트 언어를 제안합니다. 이것은 생태계가 커지기 위해 필요한 선택이지만, 동시에 주의할 지점도 있습니다. Ink와 OpenTUI는 렌더링 방식과 성숙도, 개발 환경이 다릅니다. termcn의 컴포넌트가 두 환경에서 언제나 같은 방식으로 동작하는지, 어느 쪽이 장기적으로 더 많은 기능을 지원할지는 문서와 실제 사용으로 확인해야 합니다.

crit의 관점: 에이전트 UI는 ‘보여주기’보다 ‘검증하기’에 가까워야 합니다

termcn에서 가장 흥미로운 부분은 Tool Approval이나 Thinking Block이라는 이름 자체가 아닙니다. 에이전트의 내부 작업을 화면에 어떤 단위로 드러낼 것인지 고민하고 있다는 점입니다.

하지만 컴포넌트가 있다고 해서 판단이 쉬워지는 것은 아닙니다. 승인 버튼이 있어도 사용자가 어떤 권한을 승인하는지 모르면 형식적인 클릭에 그칩니다. Diff 화면이 있어도 변경의 위험도를 판단할 기준이 없으면 사람은 결국 전체 파일을 다시 읽어야 합니다. 멋진 Spinner는 시스템이 멈췄는지, 오래 걸리는 작업을 정상적으로 수행 중인지 알려주지 않습니다.

AI 자동화에서 화면은 장식이 아니라 판단을 돕는 운영 장치여야 합니다. 그러려면 컴포넌트보다 먼저 다음이 정리되어야 합니다.

자동 실행과 사람 승인을 나누는 기준
결과를 사실로 인정하기 위한 테스트와 증거
실패했을 때의 중단·복구 조건
에이전트가 접근할 수 있는 파일과 권한의 범위
팀이 같은 결과를 판단할 수 있도록 남겨야 할 기록

판단 기준이 없는 자동화는 빠른 생산성이 아니라 슬롯머신에 가깝습니다. termcn은 그 기준을 만들어주지는 않지만, 기준을 화면에 담을 수 있는 기본 부품을 제공할 수는 있습니다. 이 둘을 혼동하지 않는 것이 중요합니다.

좋은 시작점이지만, 제품의 완성은 컴포넌트 바깥에 있습니다

termcn은 터미널 앱을 만들 때 반복되는 UI 작업을 줄여줍니다. React 개발자에게 익숙한 구성 방식을 제공하고, shadcn/ui처럼 소스 코드를 직접 수정할 수 있게 하며, AI 에이전트에 필요한 화면 패턴을 한곳에 모으려 합니다.

그 자체로는 충분하지 않습니다. 터미널 UI는 화면 폭, 색상 테마, 키보드 입력, 스크린 리더, 로그 보존, 스트리밍 성능처럼 웹과 다른 제약을 갖습니다. 특히 AI 에이전트의 경우 화면이 정보를 많이 보여주는 것보다 사용자의 주의를 어디에 모으고 무엇을 확인하게 하는지가 중요합니다.

그래서 termcn을 도입할 때 “우리 CLI를 얼마나 예쁘게 만들 수 있는가”보다 먼저 물어야 할 질문은 이것입니다.

사용자가 에이전트의 행동을 이해하고, 필요한 순간에 개입하고, 결과를 검증할 수 있는가?

이 질문에 답할 수 있다면 컴포넌트는 좋은 출발점이 됩니다. 답할 수 없다면 더 많은 컴포넌트는 문제를 해결하기보다 화면에 더 많은 상태를 쌓을 뿐입니다.

termcn이 보여주는 가장 큰 변화는 터미널의 외형이 아닙니다. AI가 실제 업무를 수행하는 화면을 디자인해야 한다는 사실이 개발 도구 생태계의 중심으로 들어오고 있다는 점입니다.