GN⁺ 5달전 | parent | ★ favorite | on: 미래의 터미널(jyn.dev)
Hacker News 의견
  • 글 전체를 읽어보니, 처음엔 단순히 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처럼 자기 기술적 객체를 주고받으면 훨씬 강력한 조합이 가능함
      관련 예시는 내 블로그 글에 정리했음
    • PowerShell은 흥미롭지만, 점점 프로그래밍 언어에 가까워지는 단점이 있음.
      명령어 기반의 직관적 흐름이 사라지고, API 구조를 외워야 함.
      AI 기반 자동완성과 객체 구조 탐색 기능이 있다면 이 약점을 보완할 수 있을 것임
    • 나도 Nushell을 즐겨 씀. PowerShell보다 깔끔하고, Microsoft 의존성이 없음
      https://www.nushell.sh/
    • 이미 비텍스트 기반 터미널 대안은 존재함.
      하지만 텍스트 기반의 진화형 터미널은 여전히 상상 가능한 구체적 제안이 있어야 흥미로움
  • 터미널이 지금까지 살아남은 이유는 호환성과 자동화 가능성 때문임
    GUI보다 스크립트화가 쉽고, 모든 것이 재현 가능하며 검색 가능
    예전엔 Neovim의 alt-screen 전환이 불편했지만, 이런 세세한 UX도 중요함
    나는 컴퓨터를 처음 접했을 때, 그리고 터미널을 배웠을 때 두 번 사랑에 빠졌음

  • 관련 프로젝트로는

    • Arcan — TUI 애플리케이션을 위한 새로운 프로토콜을 제시함
    • ShelterGit처럼 브랜치 가능한 파일시스템 셸
    • Shelter는 파일시스템 스냅샷을 필요로 하지만, 정말 멋진 아이디어임
    • Arcan을 언급하지 않은 글은 불완전하다고 생각함. 이미 사용 가능함
      • 처음 들어봤는데 정말 흥미로움. 링크 고마움
  • 18개월 전 Windows Terminal에서 비슷한 실험을 해봤음
    GitHub 코멘트에 기록되어 있음
    하지만 Polyglot Notebooks를 써본 후, 그쪽이 훨씬 자연스러워서 전환함
    명령형 백엔드를 Jupyter 커널로 바꿔서, 노트북 스타일의 인터랙티브 문서로 사용하는 게 훨씬 효율적임

    • 나도 이런 시스템을 찾고 있었음. LLM이나 개인 작업 환경에 더 적합할 듯함
    • Windows Terminal에 노트북 개념을 넣는 건 정말 멋진 아이디어임. 이런 시도가 더 많아지길 바람
  • 예전에 TopShell이라는 프로젝트로 함수형 프로그래밍 기반의 셸+터미널을 만들었음
    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으로 보내는 것임
      이렇게 하면 파이프라인과 리디렉션이 그대로 작동하고, 색상 출력도 유지됨