Superlogical: Ghostty 개발자가 만드는 모든 작업을 위한 멀티플렉서

tmux나 Zellij를 쓰다 보면 한 번쯤 아쉬운 순간이 옵니다. 노트북을 덮고 나왔는데 서버에서 돌려둔 작업이 어떻게 됐는지 폰으로 슬쩍 보고 싶을 때가 있죠. 동료에게 지금 내 터미널 화면을 그대로 보여주고 싶을 때도 있고요. 요즘 부쩍 늘어난 상황도 하나 있는데, 코딩 에이전트가 세션을 열 개씩 열어놓고 돌아가는 걸 지켜봐야 할 때입니다. 어느 쪽이든 결국 SSH로 다시 붙거나 화면을 캡처해서 보내는 우회로를 타게 됩니다.

Superlogical은 이 지점을 정면으로 겨냥한 회사입니다. GPU 가속 터미널 Ghostty를 만들고 HashiCorp를 공동 창업했던 Mitchell Hashimoto가 2026년 7월에 세운 회사인데요, 첫 제품이 터미널 멀티플렉서(terminal multiplexer)입니다. 다만 tmux를 조금 더 예쁘게 다듬은 게 아니라, 서버가 터미널 상태를 갖고 macOS 앱과 웹, iOS, CLI가 모두 같은 세션에 붙는 구조라서 이야기가 꽤 달라져요.

이 글에서는 Superlogical이 어떤 문제의식에서 출발했는지, 기존 멀티플렉서와 구조가 어떻게 다른지, 공개된 데모에서 드러난 세션과 원격 접속, CLI 기능은 무엇인지, 에이전트 규모를 염두에 둔 서버 최적화는 어떻게 했는지 차례로 살펴보겠습니다. 아직 비공개 베타 전 단계라 직접 설치해볼 수는 없지만, 지금까지 나온 자료만으로도 방향은 충분히 읽힙니다.

왜 또 멀티플렉서인가요?

Hashimoto는 2023년 HashiCorp를 떠난 뒤 Ghostty를 만들었고 2025년에는 프로젝트를 비영리 단체로 넘겼습니다. 그 과정에서 사람들이 왜 여전히 터미널을 쓰는지, 터미널 에뮬레이터 다음에는 무엇이 오는지를 계속 파고들다가 혼자서는 풀 수 없는 문제를 발견했다고 해요. 그래서 HashiCorp의 첫 직원이자 엔지니어링 부사장이었던 Jack Pearkes, Vercel과 Poolside에서 디자인을 이끈 Alasdair Monk, Heroku와 Vercel에서 개발자 제품을 만들어온 Hector Simpson과 함께 회사를 세웠습니다. Notable Capital과 Amplify Partners가 투자했고, Patrick Collison, Guillermo Rauch, Tobias Lütke 같은 개인 투자자도 이름을 올렸습니다.

공식 발표문이 짚는 문제는 작업의 파편화입니다. 소프트웨어를 만들고 운영하는 일은 로컬 머신, 원격 호스트, 샌드박스, 프로덕션 시스템에 걸쳐 있고, 사람이 직접 하기도 하고 CI가 자동으로 돌리기도 하고 이제는 에이전트 여러 개가 병렬로 처리하기도 합니다. 전부 이어진 일인데 도구는 따로따로죠. 대화형 도구는 사람이 화면 앞에 있다고 가정하고 자동 작업은 잡과 로그 속으로 사라지며, 프로덕션으로 넘어가면 또 다른 시스템과 권한 뒤에 숨습니다. 발표문은 AI가 이 파편화를 만든 게 아니라 더 눈에 띄고 비싸게 만들었을 뿐이라고 말합니다. 시스템 관리, CI, 원격 개발, 협업이 수십 년 동안 같은 경계에서 삐걱대고 있었다는 거죠.

그래서 내놓은 답이 지속 세션(durable session)입니다. 애플리케이션과 환경을 가로지르고 문맥을 기본으로 제공하며, 구조화된 데이터와 동작을 노출하고 이력을 보존하되, 소프트웨어가 조작하더라도 사람이 계속 들여다보고 통제할 수 있는 세션이요. 이걸 만드는 계획은 세 단계입니다. 우선 훌륭한 멀티플렉서를 만들고 그 안의 모든 것을 조합 가능하게 만든 다음, 마지막으로 프로덕션에서 안전하게 운영할 수 있게 하는 것입니다. 회사 이름 옆에 붙은 구호가 “모든 작업을 위한 멀티플렉서(the multiplexer for all work)“인 이유예요.

시작점이 터미널인 이유도 분명합니다. 터미널은 개발자, 에이전트, 도구, 인프라가 전부 만나는 자리니까요. 다만 Hashimoto가 덧붙인 문제의식이 하나 더 있습니다. 경력 내내 “tmux를 배워보려 했다”는 말을 수없이 들었는데, 배워야 한다는 것 자체가 첫 번째 문제라는 거예요. 세계 최고의 멀티플렉서는 배울 필요가 없는 멀티플렉서라는 게 이 팀의 기준입니다.

서버가 터미널 상태를 갖는 구조

tmux도 서버와 클라이언트로 나뉘어 있습니다. 다만 둘 다 같은 머신에서 유닉스 소켓으로 붙고, 클라이언트는 서버가 그려준 화면을 받아 보여주는 역할에 가깝죠. Superlogical은 이 구조를 네트워크 규모로 다시 설계했습니다.

가장 큰 차이는 서버가 실제 터미널 세션을 소유한다는 점입니다. 의사 터미널(pseudo terminal, 이하 PTY)과 자식 프로세스는 서버에 있고 클라이언트는 SSH처럼 입력만 보냅니다. 서버는 자체 바이너리 프로토콜로 복제된 터미널 상태 머신 여러 개를 유지하고, 각 클라이언트는 이 상태를 받아 libghostty로 화면을 그립니다. Ghostty에서 떼어낸 터미널 에뮬레이션 라이브러리를 macOS, iOS, 웹 클라이언트가 똑같이 쓰는 거예요.

여기서 서버라는 말에 오해가 없어야 합니다. 호스팅 서비스가 아니에요. macOS 앱을 처음 실행하면 앱이 내 머신에 서버를 하나 띄우는데 사용자는 그 존재를 의식할 일이 없습니다. 같은 서버 바이너리를 Linux에 따로 올려 돌릴 수도 있고 NixOS 모듈도 준비되어 있습니다. Hashimoto는 지금 보이는 어떤 기능도 외부 서비스를 요구하지 않고, 호스팅 서비스를 출시할 계획도 없다고 못 박았어요. 대신 서버에는 Tailscale과 Headscale 지원이 내장되어 있어 서버 자체가 테일넷의 노드처럼 동작합니다. 암호화된 사설 네트워크를 따로 구성하지 않아도 어디서든 내 서버에 붙을 수 있다는 뜻이죠.

flowchart TB
    accTitle: Superlogical의 서버 중심 구조
    accDescr: macOS 앱, 웹, iOS, CLI 클라이언트가 바이너리 프로토콜로 내 머신의 Superlogical 서버에 붙고, 서버가 PTY와 프로세스를 소유하며 세션 상태를 유지한다. 원격 Linux 호스트의 서버에는 Tailscale로 연결하며 그 서버도 자기 머신의 PTY와 프로세스를 소유한다.

    clients["클라이언트<br/>macOS 앱, 웹, iOS, CLI"]
    server["내 머신의<br/>Superlogical 서버<br/>세션, 윈도우, 블록"]
    pty["내 머신의<br/>PTY와 프로세스"]
    rserver["원격 Linux 호스트의<br/>Superlogical 서버"]
    rpty["원격 호스트의<br/>PTY와 프로세스"]
    clients -- "바이너리 프로토콜" --> server --> pty
    clients -- "Tailscale" --> rserver --> rpty

세션, 윈도우, 블록

용어부터 정리할게요. 세션(session)은 모든 것을 담는 그릇입니다. 세션 안에는 윈도우(window)가 여러 개 있고 앱에서는 탭으로 보입니다. 윈도우 안에서 화면을 나눈 단위는 블록(block)이라고 부르는데, 지금은 블록의 종류가 터미널 하나뿐입니다. tmux의 세션, 윈도우, 페인에 그대로 대응하지만 페인 대신 블록이라는 이름을 고른 데는 이유가 있어요. 뒤에서 다시 다루겠지만, 앞으로 터미널이 아닌 블록이 들어올 자리를 미리 비워둔 셈입니다.

첫 데모에서 Hashimoto가 가장 먼저 보여준 건 앱이 뜨는 속도입니다. Dock 아이콘이 한 번 튀어 오르기도 전에 화면이 나오고 세션 여러 개를 서버에서 받아 동기화한 뒤 다시 열어도 그 속도가 유지됩니다. 그다음 강조한 건 평범한 터미널처럼 느껴진다는 점이에요. 여러 머신에 걸쳐 세션을 유지한다고 해서 다른 모드에 들어간 느낌을 주면 안 된다는 게 설계 원칙입니다. 그래서 스크롤바가 네이티브 스크롤로 움직이고 텍스트 선택도 운영체제 방식 그대로예요. tmux에서 스크롤백(scrollback)을 보려고 복사 모드에 들어갔다 나오던 분들이 반가워할 대목입니다. 사람들이 하도 물어봐서 세로 탭도 넣었다고 하네요.

물론 멀티플렉서니까 앱을 끄면 프로세스는 계속 돕니다. 데모에서는 숫자를 세는 루프를 50 근처에서 끄고 다시 열었더니 80을 지나고 있었죠. 세션은 이름을 붙여 여러 개 만들 수 있고 새 세션에는 “drifting cedar”처럼 형용사와 명사를 조합한 이름이 자동으로 붙습니다. 원하는 이름으로 바꾸는 것도 한 번이면 되고요. 앱을 종료했다가 다시 열면 마지막에 보던 세션으로 바로 돌아갑니다.

SSH를 대체하는 원격 세션

로컬 세션이 살아남는 것만으로는 부족합니다. 원격 서버의 세션도 같은 방식으로 다뤄야 로컬과 원격의 경계가 사라지죠. 두 번째 데모는 명령 팔레트(command palette)에서 원격 호스트를 추가하고 테일넷에 붙어 있는 VPS로 접속하는 장면으로 시작합니다. 겉보기엔 SSH 세션과 다를 게 없지만, 같은 연결 위에서 화면을 나누면 두 번째 터미널이 바로 열립니다.

눈여겨볼 점은 이게 진짜 시스템 로그인이라는 겁니다. 서버가 터미널 프로세스만 띄워주는 게 아니라 SSH와 같은 방식으로 로그인 절차를 밟기 때문에 who에 접속이 잡히고, 로그인 셸 설정이 전부 로드되며, 사용자별 자원 제한도 그대로 적용됩니다. 그래서 Hashimoto는 Superlogical을 SSH의 완전한 대체재라고 부릅니다. 데모에 쓴 서버에는 아예 SSH가 설치되어 있지 않고 이 경로로만 들어간다고 해요. 서버 쪽에는 누가 누구로 행동할 수 있는지, 어떻게 인증하는지를 정하는 매핑이 있고 기존 SSH 키도 그대로 존중합니다. CLI에서 whoami를 치면 Tailscale 신원으로 접속했다는 사실과 어떤 경로를 거쳤는지가 나오고, 권한이 있으면 root로도 들어갈 수 있습니다.

반응성 이야기도 빠지지 않습니다. 미국 반대편에 있는 서버인데 타이핑이 로컬처럼 느껴진다면서, Mosh의 설계를 상당 부분 가져왔다고 밝혔어요. Mosh가 하는 걸 전부 하지는 않지만 프로토콜과 전송 계층에 비슷한 고민이 들어가 있고, 세부는 나중에 공개하겠다고 합니다. 세션을 죽이는 명령이 다른 클라이언트에 전파되는 속도도 거의 즉각적입니다.

자잘하지만 방향을 잘 보여주는 기능이 하나 있습니다. Cmd+Shift+G를 누르면 디렉터리 목록이 뜨고 고른 폴더에서 새 터미널이 열립니다. 이게 원격 세션에서도 똑같이 동작해요. /proc이나 /home 같은 원격 디렉터리를 훑어 내려가며 원하는 위치에서 터미널을 여는 겁니다. 로컬에서 되는 건 원격에서도 되고, 원격에서 되는 건 로컬에서도 되어야 한다는 원칙이 작은 기능 하나에도 배어 있습니다.

CLI로 전부 조작하기

세 번째 데모의 주인공은 CLI입니다. 데모에서 Hashimoto는 이 멀티플렉서를 Rex라고 부르고 명령도 rex block close처럼 rex로 시작하는데, 정식 제품명인지 내부 이름인지는 아직 공식 사이트에 나오지 않습니다. 앱과 서버가 여는 모든 터미널에 CLI가 자동으로 주입되어 있어서 로컬이든 원격이든 어디서나 바로 쓸 수 있고, CLI로 바꾼 내용은 연결된 모든 클라이언트에 즉시 반영돼요. 터미널에서 명령을 치면 옆에 열린 macOS 앱의 화면이 실시간으로 바뀌는 식입니다.

할 수 있는 일은 GUI와 같거나 그 이상입니다. 세션을 만들면서 htop을 바로 띄우고, 같은 세션에 nvim이라는 라벨을 붙인 블록을 추가하면 오른쪽에 분할 화면이 생깁니다. 오른쪽이 아니라 아래에 두고 싶다면 블록을 셸 블록 아래로 옮기라고 명령하면 되고요. 스크립트를 짤 때 유용한 기능도 있는데, 특정 블록의 프로세스가 끝날 때까지 기다리는 명령이 있어서 다운로드나 빌드가 끝난 뒤 다음 단계를 이어가기 좋습니다. 원래는 프로세스가 끝나면 블록이 사라지지만 옵션을 주면 열어둘 수도 있어요.

조회 기능도 촘촘합니다. 세션을 조사하면 ID와 라벨, 현재 포커스된 윈도우, 윈도우 개수, 연결된 클라이언트 목록이 나옵니다. 데모에서는 CLI와 macOS 앱, 두 클라이언트가 잡혔죠. 블록 목록을 뽑으면 어떤 윈도우에 어떤 타입의 블록이 어떤 라벨로 있는지 보이고, 블록 하나를 파고들면 메타데이터와 함께 그 블록이 제공하는 메서드(method)와 내보내는 이벤트(event) 목록이 나옵니다.

이 부분이 Superlogical의 다음 단계를 가장 잘 보여줍니다. 모든 블록이 자기만의 API를 노출한다는 점이요. 터미널 블록에는 process라는 메서드가 있는데, 호출하면 자식 프로세스와 포그라운드 프로세스 정보가 JSON으로 돌아옵니다. 자식은 대개 셸이고 포그라운드는 그 안에서 돌고 있는 Neovim 같은 프로그램이라 둘이 다를 수 있죠. 이벤트 스트림(event stream)을 열어두면 클라이언트 접속, 블록 크기 변경, 블록 닫힘, 레이아웃 변경 같은 이벤트가 비동기로 흘러나오고, 터미널 블록 구현이 내보내는 자식 프로세스 종료 이벤트도 여기에 섞여 들어옵니다.

그 밖에 키 입력과 마우스 움직임을 시뮬레이션하고 화면을 텍스트나 HTML로 캡처하는 명령도 있습니다. 이쯤 되면 상상이 갑니다. Claude Code 같은 코딩 에이전트에게 이 CLI를 쥐여주면 스스로 블록을 열어 테스트를 돌리고, 종료 이벤트를 기다렸다가 화면을 캡처해 읽는 흐름을 만들 수 있어요. 반대로 에이전트가 돌아가는 블록의 포그라운드 프로세스를 주기적으로 물어봐서 사람 쪽에 상태를 띄울 수도 있고요. Herdr나 cmux가 에이전트 상태 추적을 앱 기능으로 넣었다면, Superlogical은 그걸 만들 재료를 API로 내놓는 쪽에 가깝습니다.

에이전트 규모에 맞춘 서버

서버 쪽 이야기로 넘어가 볼게요. Hashimoto는 이 서버가 내가 가진 모든 머신, 회사의 모든 서버, 필요하다면 모든 Kubernetes 파드에서 돌아가는 그림을 그리고 있습니다. 원격 접속이 필요한 곳이라면 어디든요. 그래서 안전하면서도 자원을 아끼고 규모를 감당하는 서버여야 합니다.

규모를 이렇게 크게 잡는 이유는 역시 AI입니다. 에이전트는 코드를 실행할 자리를 원해서 전에 없던 수의 터미널 세션을 만들고, 그 세션마다 클라이언트로 붙습니다. 한 사람이 서버 하나에 터미널 열 개를 여는 규모가 아니라 수백 명의 사람과 수십만 개의 에이전트가 그보다 많은 터미널을 여는 규모를 상정하는 거죠. 지나치다 싶을 만큼 큰 규모로 설계하면 작은 규모는 저절로 잘 돌아간다는 게 그의 논리입니다.

2026년 9월에 공개한 메모리 비교에서 흥미로운 숫자가 나왔습니다. 빈 터미널의 메모리는 tmux가 더 적게 씁니다. Hashimoto도 tmux의 빈 상태는 훌륭하다고 인정했고요. 하지만 내용이 찬 터미널로 가면 터미널당 약 400KB 대 5MB 수준으로 자릿수가 바뀌고, 연결된 클라이언트당 비용도 Superlogical이 낮습니다. Zellij는 기본 설정의 탭 바와 상태 바가 WebAssembly 플러그인이라 탭마다 런타임이 하나씩 뜨는 바람에 클라이언트가 늘수록 메모리가 크게 불어난다고 지적했습니다.

이 차이를 만드는 기법을 Hashimoto는 파킹(parking)이라고 부릅니다. 세 층위가 있어요.

우선 터미널 파킹입니다. 대부분의 터미널은 어느 시점부터 아무것도 출력하지 않는 유휴 상태가 됩니다. PTY에서 60초 동안 읽을 바이트가 없으면 서버는 터미널 에뮬레이터 상태 전체를 바이너리 스냅샷(binary snapshot)으로 떠서 디스크에 내려놓습니다. 스크롤백에는 비밀 정보가 섞이기 마련이라 암호화도 함께 들어가고요. 파킹된 터미널이 차지하는 메모리는 파일 디스크립터(file descriptor)를 감시하는 최소한의 자원뿐입니다. 재미있는 건 파킹을 푸는 조건이 PTY 읽기뿐이라는 점이에요. 키를 눌러 PTY에 쓰는 건 화면 상태를 바꾸지 않으니 굳이 깨울 필요가 없습니다. 그래서 앱을 열어둔 채 터미널 열 개가 전부 유휴 셸에 멈춰 있으면 열 개가 모두 파킹됩니다. 64MB 압축 스크롤백을 다시 올리는 데 디스크 속도를 빼면 수백 마이크로초면 되고, 스트리밍 바이너리 형식이라 전부 읽어 들이기 전에 복원을 시작할 수 있습니다.

두 번째는 PTY 파킹입니다. Ghostty에서 확인한 사실인데, PTY 입출력 성능을 최대로 끌어내는 방법은 PTY마다 전용 OS 스레드를 두고 read 시스템 호출에 묶어두는 것입니다. PTY 여러 개를 kqueue나 epoll, io_uring 같은 이벤트 루프에 몰아넣으면 지연과 처리량이 눈에 띄게 나빠진다고 해요. 문제는 OS 스레드가 비싸다는 점입니다. 데스크톱에서 터미널 몇 개 열 때는 상관없지만 서버에서 수천, 수만 개를 열면 스택과 커널 쪽 부담이 커지죠. 그래서 터미널이 파킹됐거나 지켜보는 클라이언트가 없으면 파일 디스크립터를 전용 스레드에서 빼내 kqueue와 epoll을 쓰는 단일 폴러 스레드로 옮깁니다. 입출력 처리량이 5~10% 떨어지지만 사람이 보고 있지 않은 터미널이라면 아무도 그 차이를 느끼지 못하니까요.

세 번째는 클라이언트 파킹입니다. 클라이언트가 붙으면 데이터를 빠르게 밀어주려고 킬로바이트 단위의 버퍼를 여러 겹 잡아두는데, 초기 동기화가 끝나고 클라이언트가 한동안 조용하면 이 버퍼를 해제했다가 활동이 생기면 다시 잡습니다.

세 가지가 맞물리는 지점이 하나 더 있습니다. 클라이언트가 접속하면 서버는 바이너리 스냅샷을 보내 화면을 채우는데, 터미널이 파킹 상태라면 디스크의 스냅샷을 그대로 클라이언트에 흘려보냅니다. 접속과 해제를 반복하는 클라이언트가 있어도 서버 메모리에 터미널을 다시 올리지 않는다는 뜻이죠. Hashimoto는 이런 최적화가 가능한 이유를 libghostty에서 찾습니다. 멀티플렉서 안에 들어간 터미널 기술 중 바이너리 스냅샷을 지원하는 건 libghostty가 유일하다는 거예요. 게다가 터미널에 관한 작업은 전부 libghostty에 업스트림하겠다고 약속했으니, Ghostty를 쓰는 사람에게도 이 성과가 돌아옵니다.

지금 어디까지 왔나요?

정리하면 2026년 9월 현재 Superlogical은 알파 전 단계입니다. 공식 사이트에는 베타 대기 목록과 채용 공고만 있고 매주 올라오는 데모 영상으로 진행 상황을 보여주고 있어요. 데모는 전부 macOS 앱으로 진행됐지만 macOS 전용은 아니라고 여러 번 강조했습니다. 웹 인터페이스는 이미 상당히 동작하고 iOS 앱도 계획에 있으며, 서버와 CLI는 Linux에서 돌아갑니다. 다만 첫 공개 릴리스에 어떤 플랫폼을 포함할지는 아직 정리 중이라고 해요.

가격과 라이선스는 발표되지 않았습니다. 발표문은 개발 과정에서 일부를 오픈소스로 공개하겠다고만 했지 어떤 부분인지는 밝히지 않았어요. 대신 libghostty와의 관계는 분명합니다. Superlogical은 누구나 쓸 수 있는 MIT 라이선스 libghostty를 똑같은 조건으로 가져다 쓰고 터미널 관련 개선은 업스트림으로 돌려보냅니다. Ghostty 프로젝트의 사명과 거버넌스, 라이선스, 로드맵은 바뀌지 않는다고도 못 박았습니다.

로드맵의 2단계와 3단계는 아직 윤곽만 있습니다. 블록마다 메서드와 이벤트를 노출하는 구조가 이미 들어가 있으니, 2단계인 조합 가능성은 터미널이 아닌 블록이 세션에 들어오는 모습일 가능성이 큽니다. 배경 작업이나 서비스, 에이전트가 터미널 바이트 스트림이 아니라 구조화된 데이터와 동작으로 세션에 참여하는 거죠. 3단계는 신원과 승인, 감사 이력 같은 프로덕션 운영 요건입니다. 이건 발표문의 방향에서 읽어낸 추측이니 실제 모습은 다음 발표를 기다려야 합니다.

마치며

Superlogical은 아직 써볼 수 없는 도구입니다. 그런데도 소개할 가치가 있다고 본 이유는, 터미널 멀티플렉서라는 오래된 물건을 서버가 상태를 갖는 네트워크 시스템으로 다시 정의하고 있기 때문이에요. 세션이 머신과 기기를 가로질러 살아남고 SSH 없이 원격 서버에 로그인하며, 모든 조작이 CLI와 이벤트로 열려 있고 에이전트가 터미널을 수만 개 열어도 버티도록 설계한 멀티플렉서는 지금까지 없었습니다.

당장은 tmux나 Zellij로 세션을 지키면서 공식 사이트의 대기 목록에 이메일을 넣어두는 게 할 수 있는 전부입니다. 그사이 클라이언트가 어떤 느낌일지 미리 맛보고 싶다면 같은 렌더링 엔진을 쓰는 Ghostty를 써보는 것도 좋겠네요.

더 자세한 내용은 Superlogical 공식 사이트를 참고하세요.