▲

Term.everything - 터미널에서 모든 GUI 앱 실행하기

 (github.com/mmulet)
43P by GN⁺ 2일전 | ★ favorite | 댓글 8개
  • Linux용 CLI 프로그램으로, GUI 애플리케이션을 터미널에서 직접 실행할 수 있게 해줌
  • 자체 제작한 Wayland 컴포지터를 사용해 모니터 대신 터미널로 GUI 출력을 전달하는 방식
  • ssh 환경에서도 실행 가능하며, 웹 브라우저, 파일 매니저, 심지어 Doom 게임까지 터미널 안에서 실행 가능
  • 터미널 해상도(행·열 수)에 따라 출력 품질이 달라지며, iTerm2·kitty 같은 이미지 지원 터미널에서는 풀 해상도 렌더링도 지원
  • Typescript와 bun 기반으로 개발되었고 일부 C++ 코드가 포함되어 있으며, 현재는 일부 앱만 지원하지만 “Term everything❗” 을 목표로 확장 중임

프로젝트 중요성 및 비교 우위

  • Term.everything은 기존 터미널 파일 뷰어나 단순 이미지 출력 도구와 달리, “모든” GUI 애플리케이션을 터미널 안에서 실행할 수 있음
  • SSH를 포함한 네트워크 환경에서도 GUI 인터페이스를 사용할 수 있어 서버 관리, 원격 개발에 강점이 있음
  • kitty, iterm2 등 최신 터미널의 이미지 기능을 최대한 활용하며, 해상도·프레임레이트 향상 옵션 제공

개요

  • Term.everything은 Linux CLI 프로그램이며, 터미널에서 GUI 창을 직접 실행 가능하게 하는 것이 특징임
  • 자체 개발한 Wayland 기반 컴포지터가 핵심이며, 일반 모니터 대신 터미널로 GUI를 렌더링함
  • x11, Wayland 기반 모두 지원하고 ssh를 통해 원격에서도 사용 가능함
  • 한정된 터미널 행/열이 윈도우 품질에 영향을 미치며, 터미널 해상도를 늘리면 품질 향상이 가능함(단, 성능 저하 발생 가능성 존재)

주요 사용 예시

  • 게임 실행: 터미널 안에서 Fontemon 같은 게임이나 Doom(쉐어웨어 에피소드) 실행 가능
  • 동영상 재생: Wing It! 영화 재생, 해상도 조절을 통해 프레임레이트와 화질 균형 설정 가능
  • 브라우저 실행: iTerm2 + ssh 환경에서 Ubuntu에 접속해 Firefox 실행 가능
  • 파일 뷰어 대체: 굳이 터미널 전용 파일 뷰어를 만들지 않고, 기존 GUI 파일 매니저를 터미널에서 직접 사용 가능
  • 재귀 실행: 터미널 안에 또 다른 터미널을 실행하는 "terminal in a terminal"

작동 원리 및 개발 정보

  • 기본 개념

    • 과거에는 프로그램이 화면에 무언가를 그리려면 RAM의 특정 영역에 직접 기록할 수 있었음
    • 현대 시스템에서는 디스플레이 서버(Display Server) 가 입출력을 관리하며, 마우스/키보드 같은 입력과 그래픽/이미지 출력을 조율함
    • 리눅스 환경에서는 주로 Wayland 프로토콜 또는 X11이 사용되며, Term.everything은 Wayland를 기반으로 동작

  • Wayland 프로토콜

    • Wayland는 디스플레이 서버 자체가 아니라, 서버와 프로그램 간 통신을 정의한 프로토콜
    • 프로그램은 직접 렌더링한 결과물을 디스플레이 서버에 전달하고, 서버는 이를 화면에 출력
    • 중요한 점은 렌더링 모델이 강제되지 않음 → 프로그램이 원하는 방식으로 그림을 그릴 수 있음
    • 덕분에, 출력 결과를 화면 대신 다른 곳(예: 터미널)으로 보낼 수 있음

  • Term.everything의 출력 처리

    • Wayland 클라이언트(실행된 GUI 앱)가 그린 이미지를 받아서 터미널 문자 출력으로 변환
    • 변환 과정:
      • 1. 클라이언트가 전달한 이미지 데이터를 수신
      • 2. 이를 UTF-8 문자 + ANSI 이스케이프 코드로 변환
      • 3. 변환에는 chafa 라이브러리를 활용하여 픽셀을 터미널 문자로 매핑
    • 입력은 stdin을 통해 전달된 키보드, 마우스 이벤트를 Wayland 클라이언트에 전달

  • 실제 구현

    • 핵심 아이디어는 간단하지만, 실제 구현에는 약 만여 줄의 코드가 필요
    • Typescript(bun 기반)와 일부 C++로 작성되어 있으며, 커스텀 Wayland 디스플레이 서버 역할을 수행
    • 소스 코드는 src/ 디렉토리에서 확인 가능

  • 확장 가능성

    • Term.everything은 단순히 터미널로 GUI를 실행하는 것 이상을 지향
    • Wayland 기반 커스텀 디스플레이 서버를 이용해 다른 실험적 아이디어도 구현 가능성이 있음
    • 예: 출력 장치를 터미널이 아닌 전혀 다른 매체(예: 프린터, 물리적 아트워크 등)로 연결하는 활용
▲
ifmkl 2일전  [-]

이런게 진짜 geek한거죠 ㅎ

답변달기
▲
hybridego 2일전  [-]

전 왜 로고만 뜨고 안될까요??

답변달기
▲
bus710 2일전  [-]

저는 회사 맥으로 개인 맥을 제어하는데 시너지를 썼거든요. 이제는 개인 맥을 처분하고 리눅스만 쓰는지라 워크플로우가 번거로워졌습니다.

그런데 이 툴을 쓰면 회사 맥의 터미널에서 개인 리눅스 데스크탑으로 접속해서 마음껏 이런저런 작업을 할 수 있다는거네요?

아무래도 보안팀은 싫어할 것 같습니다.

답변달기
▲
coremaker 2일전  [-]

저도 고인물이라 그렇겠지만, 이게 필요한가요?

답변달기
▲
cgl00 2일전  [-]

서버에서 웹 관련 실험(via 로컬호스트) 진행할 때 유용할 것 같습니다

답변달기
▲
coremaker 2일전  [-]

로컬에서 해결하고 배포 전에 테스트 하고 싶을 때를 말씀하시는거죠?
원격지에서 작업하기, 내부망 접속이 어려워 제한된 환경이었을때...

답변달기
▲
t7vonn 2일전  [-]

iterm 안에서 term.everything으로 iterm을 열면.. 되나요?

답변달기
▲
GN⁺ 2일전  [-]
Hacker News 의견
  • 정말 쓸모없으면서도 멋진 프로젝트라 생각함, 프로그래밍과 예술의 경계에 서 있음, 이 프로젝트가 아주 즐거운 학습 경험이었을 것이라 믿음, 정말 잘했다고 말하고 싶음
    • 100% 쓸모없는 건 아닌 것 같음, Docker 컨테이너 안에서 실행되는 앱에 유용할 수 있다고 생각함, 보통 컨테이너 안에서 GUI 앱을 띄우는 방법이 있지만 이게 더 쉬울 수도 있음, 다만 Docker에서 GUI 앱 실행하는 방법이 생각보다 쉬움, 이 가이드를 참고해서 내일 테스트해볼 예정이고 Windows에서도 먹히는지 궁금함
    • 이 프로젝트가 왜 이렇게 나를 행복하게 만드는지 설명하기 어렵지만, 실제로 쓸 일은 많지 않을 것 같으면서도 이걸 생각하면 입가에 바보 같은 미소가 번짐
  • 이건 한계라는 것이 어디 있는지 알 수 없게 만드는 프로젝트임, 정말 멋지고 무한히 자랑하고 싶은 결과물임, 대단하다고 느끼고 팀에서 vdi를 앞으로 어떻게 구현해야 할지 고민하게 됨, ghost in the shell이라는 말에 새로운 의미를 부여해주는 느낌임, 그나저나 doom도 실행 가능할까 궁금함
    • 궁금하다면 doom 실행 모습을 확인해볼 수 있음, term.everything이 입력을 stdin에서만 받아서 몇 줄 수정해서 작동시킴, ssh를 통해 다양한 터미널에서 호환성이 높음
      1. Control 키를 다른 키로 매핑함(원래는 시그널 전송용임)
      2. 입력 타임아웃을 조정해야 했음. stdin 기반 입력은 keydown 이벤트만 받고 keyup 이벤트는 발생하지 않음, 그래서 사용자가 어떤 시점에 손을 뗐는지 추측해야 하고 보통 바로 keyup을 보내도 되지만 doom에서는 키 디바운스 처리 때문에 50~100ms 정도 기다려야 했음, 게임에서 앞으로 이동하려면 보통 위쪽 화살표를 누르고 있으면 되는데 지금 방식에선 반복해서 눌러줘야 해서 약간 불편하지만 실행 가능하고 플레이할 수 있음
    • aaquake는 이런 프로젝트 전에 이미 ASCII 터미널 환경에서 실행됐던 게임임
  • 이 프로젝트는 정말 멋지다고 생각함, 개인적으로 Wayland 기반으로 이런 흥미로운 활용사례들이 더 많아질 것 같음, greenfield 프로젝트 같은 것도 관심 있음
  • 예전에 carbonyl 프로젝트에서 chromium을 터미널에서 실행하는 걸 봤을 때 정말 흥분됐었음(여기 참고), 하지만 현재는 유지보수가 안 되고 있음, 이번 프로젝트는 그 아이디어보다 한 단계 업그레이드된 느낌임, 진심으로 멋진 결과라고 생각함
  • bash_completion이 정말 쉽게 쓸 수 있도록 만들어야 한다고 생각함, 실제로는 생각보다 작성이 어려움, 단순 복붙조차도 번거로움, 똑똑한 개발자들은 처음부터 bash_completion과 잘 어울리는 앱을 만듦, 예를 들어 첫 번째 핵심 아규먼트가 bash 친화적이면 mycli myfunc ... 이런 구조만으로 탭 키 한번에 모든 기능을 바로 알 수 있음, 새 기능도 광고할 필요 없음, completion에서만 빼면 기존 스크립트는 깨지지 않으면서 기능을 자연스럽게 폐기 가능함, 결국 누군가 이미 해둔 덕분에 CLI에 모든 것이 담기는 셈임
  • 나처럼 빌드 머신에서 가끔 데스크톱이나 브라우저에 직접 접근해 작업해야 할 때, vnc나 기타 데스크톱 공유 방식은 실용적이지 않거나 보안상 문제가 있음, 이 프로젝트가 그런 상황에 큰 도움이 될 것이라 생각함
  • 정말 쓸만한 프로젝트라 생각함, 원격에서 단발성 작업을 해야 할 때 괜찮을 것 같음, 실행 중인 프로그램에 원격으로 붙었다가 다시 분리하거나 화면 미러링 부분은 잘 모르겠음, SSH로 데스크톱에 접속해서 실행 중인 Discord 같은 클라이언트를 조작해볼 수도 있다면 편리할 것 같음, 참고로 원격 앱 실행 관련 RDP 기능도 살펴보고 싶음
    • 그냥 CLI용 Discord 클라이언트를 쓰거나, Bitlbee 서버로 연결되는 IRC 클라이언트를 실행해봐도 좋을 것 같음
  • <i>터미널에서</i> 라는 점을 메모해 둬야겠음, 이건 텍스트 모드에선 작동하지 않을 것 같다는 점을 스스로 상기함
    • 근데 첫 번째 예시(만화 예제)가 텍스트 모드 아니었나 싶음
  • 프로젝트의 지속적인 발전을 기원함, 절대 멈추지 않았으면 함
  • 정말 대단하다고 생각함! 저마다 독특한 활용 사례가 있을 텐데, 나에게는 VSCode를 iPad에서 돌리는 용도로 기대가 큼, 언젠가 iPadOS도 지원될 수 있기를 바람
    • 나는 원격 개발에는 보통 code-server를 사용해서 충분하다고 느낌
    • iPad용 ssh 클라이언트가 있으니 가능하다고 생각함, 지금 바로 시도해볼 계획임
답변달기