# 미래의 터미널 > Clean Markdown view of GeekNews topic #24325. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=24325](https://news.hada.io/topic?id=24325) - GeekNews Markdown: [https://news.hada.io/topic/24325.md](https://news.hada.io/topic/24325.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2025-11-13T02:38:48+09:00 - Updated: 2025-11-13T02:38:48+09:00 - Original source: [jyn.dev](https://jyn.dev/the-terminal-of-the-future) - Points: 8 - Comments: 1 ## Summary 터미널을 단순한 문자 입출력 창이 아닌 **데이터플로우 기반의 상호작용형 환경**으로 재구성하려는 제안입니다. **Jupyter Notebook**의 인터랙티브 모델을 차용해 명령의 **undo/redo**, 세션 복구, 협업형 실행까지 가능하게 하는 **차세대 터미널 아키텍처**를 단계적으로 설계합니다. 핵심은 **쉘 통합과 지속 세션, 구조화된 RPC**를 통해 터미널을 “기록 가능한 시스템 인터페이스”로 확장하는 것이며, 이는 개발자 워크플로의 투명성과 재현성을 크게 높일 수 있습니다. 지금의 터미널이 답답하게 느껴졌다면, 이 구상은 “CLI의 미래는 대화형 데이터 플랫폼이다”라는 흥미로운 방향을 제시합니다. ## Topic Body - 기존 **터미널 구조의 복잡성과 한계**를 지적하며, 입력·출력·프로세스 제어를 새롭게 통합한 차세대 터미널 개념 제시 - **Jupyter Notebook**을 모델로 삼아, 이미지 렌더링·명령 재실행·편집 가능한 출력·내장 편집기 등 **상호작용형 인터페이스** 구현 가능성 탐색 - **Warp**와 **iTerm2**의 사례를 통해 쉘과 터미널 간 **심층 통합(shell integration)** , 장기 실행 프로세스 관리, 세션 분리·복구 기능을 구체적으로 설명 - **데이터플로 추적(dataflow tracking)** 과 **영속성(persistence)** 을 기반으로, 명령의 **undo/redo**, 자동 재실행, 협업형 터미널 등 확장 기능 구상 - 단계별 접근을 통해 **트랜잭션형 CLI → 지속 세션 → 구조화된 RPC → Jupyter형 프런트엔드**로 발전시키는 **점진적 구축 전략** 제시 --- ### 터미널의 기본 구조 - 터미널은 네 가지 구성요소로 이루어짐: **터미널 에뮬레이터**, **가상 터미널(PTY)** , **쉘**, **프로세스 그룹** - **터미널 에뮬레이터**는 화면에 **그리드 구조를 렌더링**하는 프로그램 - **PTY**는 커널 내부 상태로, 입력을 프로세스 그룹에 전달하고 신호(signal) 변환을 담당 - **쉘**은 입력을 읽고 파싱하며 프로세스를 생성하는 **이벤트 루프** 역할 - **프로세스들**은 입력·출력을 통해 위 구성요소들과 상호작용 - 입력은 단순한 텍스트가 아니라 **신호(signal)** 를 포함하며, 출력은 **ANSI 이스케이프 시퀀스**로 구성되어 포맷팅을 표현 ### 더 나은 터미널의 구상 - 기존 터미널은 기능적 제약이 많아 **확장성과 상호작용성**이 부족함 - **Jupyter Notebook**은 전통적인 VT100 에뮬레이터에서 불가능한 기능 제공 - 고해상도 이미지 렌더링 - 과거 출력을 추가하지 않고 교체하는 "처음부터 재실행" 버튼 - 소스 코드와 출력을 제자리에서 다시 작성 가능한 "뷰" (예: 마크다운을 소스 또는 렌더링된 HTML로 표시) - 구문 강조, 탭, 패널, 마우스 지원 등이 있는 내장 편집기 - 하지만 **셸을 커널로 사용**하는 Jupyter 노트북 개념은 여러 문제 직면 - 셸이 명령을 한 번에 받아 **탭 완성, 구문 강조, 자동 제안이 작동하지 않음** - 장시간 실행 프로세스 처리 문제: Jupyter는 기본적으로 셀이 완료될 때까지 실행하며, 취소는 가능하지만 **일시 중지, 재개, 상호작용, 실행 중 프로세스 보기 불가능** - "셀 재실행" 버튼이 컴퓨터 상태에 문제 초래 (특히 `rm -rf` 같은 명령 포함 시) - 실행 취소/재실행이 작동하지 않음 ### 이게 어떻게 동작할까? - ## 쉘 통합 (Shell Integration) - Warp 터미널은 터미널과 셸 간 **네이티브 통합** 구축 - 각 명령의 시작과 끝, 출력, 사용자 입력을 터미널이 이해 - 표준 기능(사용자 정의 DCS)을 사용하여 구현 - iTerm2도 유사한 방식으로 **OSC 133 이스케이프 코드** 사용 가능 - 단일 단축키로 명령 간 탐색 - 명령 완료 시 알림 - 출력이 화면 밖으로 나가면 현재 명령을 "오버레이"로 표시 - ## 장기 실행 프로세스 관리 - **상호작용(interacting)** : - 장시간 실행 프로세스와 상호작용하려면 **양방향 통신** 필요 - TUI 예시: `top`, `gdb`, `vim` - Jupyter는 변경 및 업데이트 가능한 **인터랙티브 출력** 설계에 강점 - 예상되는 터미널 기능: 항상 "자유 입력 셀" 제공 - 인터랙티브 프로세스가 창 상단에서 실행되고 하단에 입력 셀 제공 - **일시중단(suspending)** : - 프로세스 "일시 중지"는 "작업 제어(job control)"로 불림 - 현대 터미널은 **일시 중지 및 백그라운드 프로세스를 지속적인 시각적 표시**로 보여줄 것으로 예상 - IntelliJ가 하단 작업 표시줄에 "인덱싱 중..."을 표시하는 방식과 유사 - **연결해제(disconnecting)** : 세션 분리·복구를 위해 세 가지 접근 존재 - **Tmux / Zellij / Screen**: 터미널 에뮬레이터와 프로그램 사이에 추가 터미널 에뮬레이터 주입. 서버가 PTY를 소유하고 출력을 렌더링하며, 클라이언트가 실제 터미널 에뮬레이터에 출력 표시. 클라이언트 분리, 재연결, 다중 클라이언트 동시 연결 가능. iTerm은 tmux 클라이언트를 우회하고 서버와 직접 통신하는 자체 클라이언트로 작동 - **Mosh**: SSH 대체. 네트워크 중단 후 터미널 세션에 재연결 지원. 서버에서 상태 머신을 실행하고 뷰포트의 증분 차이를 클라이언트에 재생. 멀티플렉싱 및 스크롤백은 터미널 에뮬레이터가 처리할 것으로 예상. 클라이언트가 네트워크 측에서 실제로 실행되므로 **로컬 라인 편집이 즉각적** - **alden/shpool/dtach/abduco/diss**: 클라이언트/서버로 세션 분리/재개만 처리하며, 네트워킹이나 스크롤백은 포함하지 않고 자체 터미널 에뮬레이터도 포함하지 않음. tmux 및 mosh에 비해 **높은 분리 수준** - ## 재실행과 되돌리기 - 해결책은 **데이터 플로우 추적** - **pluto.jl**이 Julia 컴파일러에 연결하여 오늘날 구현 - 이전 셀에 의존하는 셀을 실시간으로 업데이트 - 종속성이 변경되지 않은 경우 셀을 업데이트하지 않음 - 스프레드시트와 유사한 Jupyter로, 필요할 때만 코드 재실행 - **직교 지속성(orthogonal persistence)** 을 통한 일반화 - 프로세스를 샌드박스화하고 모든 I/O를 추적하며, 샌드박스 내 다른 프로세스와 통신하지 않는 한 "너무 이상한" 것들 방지 - 프로세스를 입력의 순수 함수로 취급 가능, 입력은 "전체 파일 시스템, 모든 환경 변수, 모든 프로세스 속성" ### 파생 기능 - **Jupyter 프런트엔드 필요**: - Runbooks (실제로는 Jupyter와 PTY 프리미티브만으로 구축 가능) - 이상한 사용자 정의 언어나 ANSI 색상 코드 없이 **일반 CSS를 사용하는 터미널 커스터마이징** - 출력/타임스탬프로 명령 검색: 현재 세션의 출력 전체에서 검색하거나 모든 명령 입력 기록에서 검색할 수 있지만, 스마트 필터가 없고 출력이 세션 간 지속되지 않음 - **쉘 통합 필요**: - 각 명령의 타임스탬프 및 실행 시간 - 네트워크 경계를 넘어서도 로컬 라인 편집 - 탭을 누르지 않고도 셸 명령에 대한 IntelliSense, 터미널에 통합된 렌더링 - **샌드박스 추적 필요**: - 샌드박스 추적의 모든 기능: **협업 터미널, 명령으로 수정된 파일 쿼리, 런타임에 편집 가능한 asciinema, 빌드 시스템 추적** - 명령 실행 시점의 디스크 상태로도 검색하도록 스마트 검색 확장 - 실행 취소/재실행을 git과 유사한 분기 모델로 확장 (emacs undo-tree가 이미 지원), 프로세스 트리의 여러 "뷰" 제공 - undo-tree 모델과 샌드박싱을 통해 **LLM에게 프로젝트 액세스 권한을 부여하고 여러 개를 동시에 병렬로 실행** 가능, 서로의 상태를 덮어쓰지 않으며 작업 내용 확인, 편집, 나중에 사용할 runbook으로 저장 가능 - 프로덕션 환경에서 머신 상태에 영향을 주지 않고 **기존 상태만 검사하는 터미널** ### 단계별 구축 전략 - ## 1단계: 트랜잭션 시맨틱 (transactional semantics) - 터미널 재설계 시 터미널 에뮬레이터부터 시작하는 것이 잘못된 접근 - 사용자가 에뮬레이터에 애착을 가지며 구성, 외관, 키 바인딩 설정 - **에뮬레이터 전환 비용이 높음** - CLI 레이어에서 시작하는 것이 올바른 방법 - CLI 프로그램은 설치 및 실행이 쉽고 **전환 비용이 매우 낮음** - 전체 워크플로를 변경하지 않고 일회성으로 사용 가능 - **터미널용 트랜잭션 의미론**을 구현하는 CLI 작성 - `transaction [start|rollback|commit]` 같은 인터페이스 - `start` 후 실행된 모든 것을 실행 취소 가능 - 이것만으로도 전체 비즈니스 구축 가능 - ## 2단계: 지속 세션 (Persistent Sessions) - 트랜잭션 시맨틱 확보 후 **tmux 및 mosh에서 지속성 분리** - PTY 지속성을 얻으려면 클라이언트/서버 모델 도입 필요 - 커널이 PTY 양쪽이 항상 연결되어 있을 것으로 예상 - alden 같은 명령이나 유사 라이브러리 사용으로 터미널 에뮬레이터나 PTY 세션 내부에서 실행 중인 프로그램에 영향을 주지 않고 단순하게 구현 - 스크롤백 확보를 위해 서버가 입출력을 무기한 저장하고 클라이언트 재연결 시 재생 - 터미널 에뮬레이터가 **다른 출력처럼 처리하는 네이티브 스크롤백** 제공 - 임의의 시작점에서 재생 및 재개 가능 - ANSI 이스케이프 코드 파싱 필요하지만 충분한 작업으로 가능 - mosh와 같은 네트워크 재개를 위해 **Eternal TCP** 사용 (QUIC 위에 구축하여 효율성 향상 가능) - PTY 지속성과 네트워크 연결 지속성 분리 - Eternal TCP는 순수한 최적화: `ssh host eternal-pty attach`를 루프로 실행하는 bash 스크립트 위에 구축 가능 - 이 시점에서 tmux처럼 **단일 터미널 세션에 여러 클라이언트 연결 가능**, 창 관리는 여전히 터미널 에뮬레이터가 처리 - 통합 창 관리를 원하면 터미널 에뮬레이터가 iTerm처럼 tmux -CC 프로토콜 사용 가능 - 이 단계의 모든 부분은 트랜잭션 의미론과 독립적으로 병렬로 수행 가능하지만, 비즈니스 구축에는 충분하지 않음 - ## 3단계: 구조화된 RPC - 클라이언트/서버 모델에 의존 - 터미널 에뮬레이터와 클라이언트 사이에 서버가 개입하면 **메타데이터로 I/O 태깅** 같은 기능 구현 가능 - 모든 데이터에 타임스탬프 추가 가능 - 입력과 출력 구별 가능 - xterm.js가 이와 유사하게 작동 - 셸 통합과 결합하면 **데이터 레이어에서 셸 프롬프트와 프로그램 출력 구별** 가능 - **터미널 세션의 구조화된 로그** 확보 - asciinema처럼 로그를 녹화로 재생 - 모든 명령을 재실행하지 않고 셸 프롬프트 변환 - Jupyter Notebook 또는 Atuin Desktop으로 가져오기 - 명령을 저장하고 나중에 스크립트로 재실행 - 터미널이 데이터가 됨 - ## 4단계: Jupyter 유사 프론트엔드 - **터미널 에뮬레이터를 처음으로 건드리는 단계**이며 의도적으로 마지막 단계 - 전환 비용이 가장 높기 때문 - 구축된 모든 기능을 활용하여 좋은 UI 제공 - `transaction` CLI는 중첩 트랜잭션을 원하지 않는 한 더 이상 필요하지 않음 - 전체 터미널 세션이 기본적으로 트랜잭션으로 시작 - 모든 조각을 결합했기 때문에 위에서 언급한 모든 파생 기능 제공 ### 결론 - 이 구조는 **대담하고 야심 차며 전체 구축에 약 10년까지 소요될 것**으로 예상 - 인내심을 가지고 단계별로 진행할 것 - 이 글이 누군가에게 영감을 주어 직접 구축을 시작하기를 희망 ## Comments ### Comment 46257 - Author: neo - Created: 2025-11-13T02:38:48+09:00 - Points: 1 ###### [Hacker News 의견](https://news.ycombinator.com/item?id=45892191) - 글 전체를 읽어보니, 처음엔 단순히 **NIH식 바람 목록**처럼 보였음 이미 터미널을 대체할 수 있는 여러 대안이 있음에도 글에서는 언급이 없었음 예를 들어 **Emacs**는 Lisp 기반의 VM으로, 함수 재정의가 쉽고 명령은 주석이 달린 함수임. 출력은 버퍼로 관리되고, 여러 창과 프레임을 타일 형태로 배치할 수 있음. CLI를 그대로 사용할 수도 있고(vterm, eat 등), REPL 흐름으로 전환할 수도 있음(shell-mode, eshell 등). 그래픽도 지원하지만 완전한 2D 컨텍스트는 아님 또 다른 예로 **Acme**는 Emacs와 비슷하지만, 모든 텍스트가 명령이 될 수 있는 **인터랙티브 텍스트 환경**임. Smalltalk도 비슷한 철학을 가졌지만 IDE에 더 가까움 - Emacs에는 **Org-mode**와 org-babel이 있어서 Jupyter notebook처럼 작동할 수 있음. 심지어 Jupyter 커널과도 통신 가능함 나는 Emacs에서 GPTel을 활용해 오래된 라틴어 교재 PDF를 자동으로 잘라내고, OCR을 통해 org-mode 형식으로 변환함. 그 결과, 단어를 선택하면 즉시 사전 검색이 가능하고, 문장을 선택하면 LLM이 문법 분석을 해줌. 1970년대 텍스트 에디터가 **미래형 학습 플랫폼**이 된 셈임 - Acme에 대해 더 알고 싶음. 검색하기 어렵더라. Emacs, Jupyter, VSCode 같은 플랫폼은 강력하지만 완성된 **애플리케이션**이라기보단 커스터마이징 기반의 플랫폼임. 진짜 혁신이라면, 복잡한 설정 대신 **도커 컨테이너나 실행 파일** 형태로 쉽게 재현 가능한 형태로 배포해야 함 - 글의 핵심은 터미널의 **데이터 모델을 개방**하는 것이라 생각함. 그 위에서 다양한 기능을 구현할 수 있다는 점이 중요함 - Emacs의 독특한 점은 **UI 독립성**임. Elisp로 작성된 앱은 터미널과 GUI 모두에서 동일하게 작동함. 20년 전에도 터미널에서 Elisp를 작성했는데, GUI 사용자들은 그 차이를 전혀 느끼지 못했음. 이런 플랫폼은 다른 곳엔 없음 - 터미널의 후속 개념이 꼭 **텍스트 기반**일 필요가 있는지 의문임 미래의 터미널은 API 형태일 수도 있고, OAuth 인증을 통해 원격 호출이 가능할 수도 있음. 입력과 출력이 더 이상 CLI 텍스트가 아닐 수도 있음. 대신 **객체 기반 입력/출력**으로 전환해, 명령어와 데이터 구조를 API로 탐색 가능하게 만들 수 있음. 터미널은 70년대의 유산이며, 오늘날엔 더 나은 대안이 충분히 가능함 - 터미널은 사실 텍스트 중심이 아니라 **양방향 토큰 스트림** 기반임. 이 단순함 덕분에 Unix식 조합이 가능함. JSON 출력을 추가하면 `jq` 같은 도구로 파이프라인을 구성할 수 있음. 단순함이 장점인 “**worse is better**” 철학 덕분에 수십 년간 진화해왔음 - 나도 CLI의 **표준 입출력 한계**에 공감함. 데이터와 표현이 동일하다는 점이 조합성을 제한함. PowerShell처럼 **자기 기술적 객체**를 주고받으면 훨씬 강력한 조합이 가능함 관련 예시는 내 [블로그 글](https://www.cgl.sh/blog/posts/sh.html)에 정리했음 - PowerShell은 흥미롭지만, 점점 **프로그래밍 언어에 가까워지는** 단점이 있음. 명령어 기반의 직관적 흐름이 사라지고, API 구조를 외워야 함. AI 기반 자동완성과 객체 구조 탐색 기능이 있다면 이 약점을 보완할 수 있을 것임 - 나도 **Nushell**을 즐겨 씀. PowerShell보다 깔끔하고, Microsoft 의존성이 없음 [https://www.nushell.sh/](https://www.nushell.sh/) - 이미 비텍스트 기반 터미널 대안은 존재함. 하지만 텍스트 기반의 진화형 터미널은 여전히 **상상 가능한 구체적 제안**이 있어야 흥미로움 - 터미널이 지금까지 살아남은 이유는 **호환성과 자동화 가능성** 때문임 GUI보다 스크립트화가 쉽고, 모든 것이 **재현 가능**하며 **검색 가능**함 예전엔 Neovim의 alt-screen 전환이 불편했지만, 이런 세세한 UX도 중요함 나는 컴퓨터를 처음 접했을 때, 그리고 터미널을 배웠을 때 두 번 사랑에 빠졌음 - 관련 프로젝트로는 - [Arcan](https://arcan-fe.com/) — TUI 애플리케이션을 위한 새로운 프로토콜을 제시함 - [Shelter](https://patrick.sirref.org/shelter/index.xml) — **Git처럼 브랜치 가능한 파일시스템 셸** - Shelter는 파일시스템 스냅샷을 필요로 하지만, 정말 멋진 아이디어임 - Arcan을 언급하지 않은 글은 불완전하다고 생각함. 이미 사용 가능함 - 처음 들어봤는데 정말 흥미로움. 링크 고마움 - 18개월 전 Windows Terminal에서 비슷한 실험을 해봤음 [GitHub 코멘트](https://github.com/microsoft/terminal/issues/16495#issuecomment-1984745678)에 기록되어 있음 하지만 **Polyglot Notebooks**를 써본 후, 그쪽이 훨씬 자연스러워서 전환함 명령형 백엔드를 Jupyter 커널로 바꿔서, **노트북 스타일의 인터랙티브 문서**로 사용하는 게 훨씬 효율적임 - 나도 이런 시스템을 찾고 있었음. LLM이나 개인 작업 환경에 더 적합할 듯함 - Windows Terminal에 노트북 개념을 넣는 건 정말 멋진 아이디어임. 이런 시도가 더 많아지길 바람 - 예전에 **TopShell**이라는 프로젝트로 함수형 프로그래밍 기반의 셸+터미널을 만들었음 [https://github.com/topshell-language/topshell#readme](https://github.com/topshell-language/topshell#readme) 가능성은 있지만 완전한 대안이 되려면 아직 많은 작업이 필요함 - 이미지나 비디오를 표시할 수 있는 터미널을 찾고 있었음 단순히 브라우저처럼 동작하는 터미널이 있다면 좋겠음. 예를 들어 `browser google.com/maps`처럼 명령으로 바로 인터랙티브하게 띄우는 식임 - 하지만 이런 기능은 터미널이 아니라 **별도 프로그램(fbi, omxplayer 등)** 의 역할임 - **pseudo-terminal(PTY)** 을 확장해 **JSON-RPC 기반의 out-of-band 채널**을 추가하자는 제안임 기존의 escape sequence는 한계가 많음. 이 방식이면 점진적이고 **하위 호환적인 전환**이 가능함. LSP나 MCP처럼 기능 협상을 할 수 있고, 커널은 단순히 채널만 제공하면 됨 - JSON은 이 용도로 부적절함. **DER이나 SDSER** 같은 바이너리 포맷이 더 효율적임 - 현대적인 접근은 사용자용 메시지는 stderr로, **기계 친화적 JSON은 stdout으로** 보내는 것임 이렇게 하면 파이프라인과 리디렉션이 그대로 작동하고, 색상 출력도 유지됨