[심층분석] 사람과 AI가 같은 터미널을 쓰는 시대 — '모든 작업의 멀티플렉서'를 만들겠다는 Superlogical

혹시 오늘 하루 동안 몇 개의 창을 오가며 일하셨는지 세어보신 적 있으세요? 로컬 터미널에서 코드를 돌리다가, SSH로 원격 서버에 들어가고, CI가 왜 깨졌는지 보려고 웹 대시보드를 열고, 프로덕션 로그는 또 다른 모니터링 도구에서 확인하고요. 요즘은 여기에 하나가 더 늘었죠. 백그라운드에서 돌아가는 코딩 에이전트요. AI 에이전트한테 일을 시켜놓고 '얘가 지금 뭘 하고 있지?' 하고 들여다볼 곳이 마땅치 않아 답답했던 경험, 다들 있으실 거예요.

Superlogical이라는 새 회사가 바로 이 문제를 정면으로 겨냥하고 나섰는데요. 선언이 꽤 대담해요. '모든 작업(all work)을 위한 멀티플렉서를 만들겠다'는 거거든요. 로컬 개발, 원격 접속, 코딩 에이전트, 백그라운드 작업, 프로덕션 애플리케이션, 라이브 디버깅, 장애 대응까지 — 지금은 전부 따로 노는 이 작업들을 하나의 시스템 위에 올리겠다는 거죠. 그런데 그 출발점으로 선택한 게 의외로 '터미널 멀티플렉서'예요. 개발자 도구 중에서도 가장 오래된 장르 중 하나를요. 왜 하필 여기서 시작하는지, 그 안에 담긴 그림이 뭔지 차근차근 풀어볼게요.

멀티플렉서가 뭐냐면요

먼저 용어부터 짚고 갈게요. 멀티플렉서(multiplexer)라는 건, 쉽게 말해서 여러 개의 독립적인 흐름을 하나의 창구로 모아주는 장치예요. 터미널 멀티플렉서라고 하면 tmux나 GNU screen을 떠올리시면 되는데요, 하나의 터미널 안에서 여러 셸 세션을 띄워놓고 자유롭게 오가게 해주는 도구예요.

그런데 진짜 중요한 기능은 화면 분할이 아니라 '세션 유지'거든요. 비유하자면 퇴근할 때 책상 위 서류를 하나도 안 치우고 그대로 두고 가는 거예요. 다음 날 출근하면, 혹은 집에서 원격으로 접속하면, 어제 펼쳐놓은 그대로 이어서 일할 수 있는 거죠. tmux에서는 SSH 연결이 끊겨도 서버 안의 세션은 살아있어서, 다시 접속해 tmux attach 한 줄이면 돌아가던 빌드도, 열어둔 로그 화면도 그대로 만날 수 있어요. 이게 detach/attach라는 개념이에요.

'작업을 감싸는 지속 세션'이라는 설계 철학

Superlogical의 문제의식은 이래요. 소프트웨어를 만들고 운영하는 일은 이제 로컬 머신, 원격 호스트, 샌드박스(격리된 실험 환경이라고 생각하시면 돼요), 프로덕션 시스템에 걸쳐 있고, 일하는 방식도 세 갈래로 나뉘어 있다는 거예요.

• 인터랙티브 작업: 사람이 직접 키보드를 두드리는 개발
• 자동 작업: CI 파이프라인이나 배치 잡처럼 알아서 돌아가는 것들
• 프로덕션 작업: 실제 서비스 운영과 장애 대응

문제는 이 세 가지가 사실 하나로 이어진 '같은 일'인데, 도구는 전부 따로 논다는 거죠. 인터랙티브 도구는 화면 앞에 사람이 앉아 있다고 가정하고, 자동 작업은 잡 큐와 로그 파일 속으로 사라져버리고, 프로덕션으로 넘어가면 별도의 시스템과 권한 체계 뒤에 숨어버려요. 여기에 흥미로운 진단을 하나 덧붙이는데요. AI가 이 분절을 만든 게 아니라, 원래 있던 분절을 더 잘 보이게, 더 비싸게 만들었을 뿐이라는 거예요. 에이전트 여러 개가 병렬로 일하기 시작하니까 수십 년 묵은 균열이 갑자기 눈에 확 들어오게 된 거죠.

그래서 이들이 제안하는 해법이 '작업 그 자체를 감싸는 지속 세션(durable session)'이에요. 이 세션은 이런 성질을 가져야 한다고 해요.

• 애플리케이션과 환경의 경계를 넘나들 수 있고
• 관련 컨텍스트를 기본으로 제공하며
• 구조화된 데이터와 액션을 노출하고 (사람 눈에만 보이는 텍스트가 아니라, 프로그램이 읽고 조작할 수 있는 형태라는 뜻이에요)
• 히스토리를 보존하고
• 소프트웨어(에이전트)가 구동하되, 사람이 언제든 들여다보고 제어할 수 있어야 한다

로드맵은 세 단계로 명확해요. 첫째, 정말 잘 만든 멀티플렉서를 만든다. 둘째, 그 안의 모든 것을 조합 가능(composable)하게 만든다. 셋째, 프로덕션에서도 안전하게 운영할 수 있게 만든다.

첫 제품인 터미널 멀티플렉서만 봐도 방향이 보이는데요. 세션을 웹과 macOS/iOS 네이티브 앱으로 접근할 수 있고, 라이브 세션 공유가 처음부터 내장돼 있어요. 그리고 기존 도구들의 고질적인 잔가시들 — 스크롤백, 텍스트 선택, 스크롤이 어색하게 동작하는 문제 — 을 네이티브로 자연스럽게 만들겠다고 해요. tmux 써보신 분들은 아실 거예요. 마우스 휠을 굴렸는데 스크롤 대신 명령 히스토리가 넘어간다든가, 텍스트 하나 복사하려면 copy-mode라는 별도 모드에 들어가 키보드로 범위를 잡아야 한다든가 하는 것들요. 사소해 보여도 매일 수십 번 부딪히면 꽤 큰 마찰이거든요.

tmux, Zellij, Warp와는 뭐가 다를까요

기존 도구들과 비교해보면 포지셔닝이 선명해져요.

• tmux / GNU screen: 수십 년간 검증된 표준이지만, 기본적으로 한 대의 머신 안에서만 동작해요. 원격에서 쓰려면 SSH와 조합해야 하고, 설정 파일을 한참 다듬어야 쓸 만해지죠. 수동 기어 자동차 같은 느낌이에요. 익숙해지면 강력하지만 진입장벽이 있어요.
• Zellij: Rust로 만든 모던 멀티플렉서로, 기본 설정만으로도 친절해요. 다만 여전히 '터미널 화면 관리'라는 전통적인 역할에 충실한 도구예요.
• Warp: 터미널 앱 자체를 현대화하고 AI를 붙이는 접근이에요. 블록 단위 UI 같은 아이디어는 겹치지만, 축이 '내 앞의 터미널을 좋게 만들기'에 가까워요.
• VS Code Remote / Codespaces: 에디터를 중심에 두고 원격 환경을 붙이는 방식이라, 터미널과 운영 작업은 부수적이에요.
• mosh: 불안정한 네트워크에서 연결을 유지하는 데 특화돼 있지만, 세션의 내용이나 히스토리를 다루진 않아요.

핵심 차이를 한 문장으로 하면, 기존 도구들은 '화면'을 관리하고 Superlogical은 '작업'을 관리하려 한다는 거예요. tmux 세션에서 무슨 일이 있었는지는 스크롤백 버퍼 속 텍스트 덩어리로만 남지만, Superlogical이 그리는 세션은 어떤 명령이 언제 실행됐고 결과가 뭐였는지가 구조화된 데이터로 남고, 그 위에 액션을 걸 수 있는 형태예요. 이게 왜 중요하냐면, 에이전트 때문이에요. 에이전트한테 '아까 그 빌드 에러 다시 봐줘'라고 하려면, 세션이 사람 눈에만 보이는 그림이 아니라 프로그램이 읽을 수 있는 기록이어야 하거든요. 사람과 기계가 같은 작업공간을 공유한다는 비전은 이 지점에서 출발해요.

팀도 개발자 도구, 인프라 소프트웨어, AI 시스템을 오래 만들어온 사람들이라고 밝히고 있는데요. '터미널 멀티플렉서는 회사를 시작하기엔 좁아 보일 수 있지만, 터미널이야말로 개발자·에이전트·도구·인프라가 만나는 접점이라 이후 모든 것의 기반이 된다'는 논리는 꽤 설득력이 있어요.

한국 개발자에게 주는 시사점

그럼 우리 입장에서 뭘 얻어갈 수 있을까요? 구체적인 장면으로 상상해볼게요.

장애 대응 시나리오. 새벽에 프로덕션 장애가 나면 지금은 보통 화상회의를 켜고 화면 공유를 하죠. 선배가 '거기서 그 명령 말고...' 하며 말로 조종하는 답답한 원격 운전이 벌어지고요. 라이브 세션 공유가 기본이라면 같은 터미널에 바로 들어와 직접 명령을 치고, 그 과정 전체가 히스토리로 남아요. 사후 회고를 쓸 때 '그때 무슨 명령 쳤더라?'를 복기할 필요가 없어지는 거죠.

에이전트 감독 시나리오. 퇴근 전에 코딩 에이전트한테 리팩터링을 맡겨두고, 다음 날 아침 세션 히스토리로 밤사이 무슨 일이 있었는지 훑어보는 거예요. 출근길 지하철에서 iOS 앱으로 진행 상황을 확인하고, 이상하면 그 자리에서 개입하고요. '에이전트가 일하는 모습을 지켜볼 수 있는 창'이 생기는 셈이에요.

멀티 디바이스 시나리오. 사무실 데스크톱에서 하던 작업을 그대로 두고 퇴근한 뒤, 집 노트북에서 같은 세션에 붙어 이어서 하는 거죠. 지금도 서버에 tmux를 깔면 비슷하게 되지만, 로컬 개발 환경까지 포함해 웹과 네이티브 앱으로 자연스럽게 이어지는 건 다른 차원의 경험이에요.

다만 고려할 점도 분명해요. 아직 비전 발표 단계라 제품 성숙도는 지켜봐야 하고요. 특히 '프로덕션 접근'을 다루는 도구인 만큼, 팀에 도입하려면 권한 관리와 감사 로그, 보안 검토가 필수예요. 터미널 세션에는 환경변수나 시크릿 같은 민감 정보가 흘러다니니까요. 워크플로우의 중심을 특정 회사 제품에 두는 벤더 종속 리스크도 생각해봐야 하고요.

학습 로드맵을 제안해보면 이래요. 이 흐름을 따라가려면 결국 '세션'이라는 개념을 몸으로 익히는 게 먼저거든요.

1. tmux 기초부터: 세션, 윈도우, 페인 개념과 detach/attach를 익히세요. 반나절이면 충분해요.
2. SSH + tmux 조합 실습: 원격 서버에서 세션을 유지하며 일해보세요. 연결이 끊겨도 작업이 살아있는 경험을 해보면 이 글의 문제의식이 확 와닿을 거예요.
3. 모던 도구 체험: Zellij 같은 최신 멀티플렉서를 써보며 기존 도구의 어디가 불편했는지 비교해보세요.
4. Superlogical 출시 관찰: 실제 제품이 나오면, 위 경험을 기준 삼아 뭐가 정말 달라졌는지 평가해보세요.

터미널의 재발견, 그리고 남은 질문들

재미있는 흐름이에요. 최근 몇 년 사이 Warp, Ghostty 같은 새 터미널들이 연이어 나오더니, 이제는 터미널 멀티플렉서를 기반으로 '모든 작업'을 담겠다는 회사까지 등장했으니까요. GUI와 웹의 시대에 밀려나는 듯했던 가장 오래된 인터페이스가, 에이전트 시대가 열리자 오히려 사람과 기계가 만나는 최적의 접점으로 재조명받고 있는 거죠. 텍스트 기반이라 기계가 다루기 쉽고, 수십 년간 쌓인 도구 생태계가 그대로 살아있으니까요.

물론 '멀티플렉서에서 시작해 프로덕션 운영까지'라는 길은 멀고, 그 사이에는 강력한 기존 강자들이 즐비해요. 하지만 문제 정의만큼은 정확하다고 봐요. 우리 모두가 매일 겪는 분절이니까요.

여러분은 어떠세요? 하루 워크플로우에서 가장 조각나 있다고 느끼는 지점은 어디인가요? 그리고 에이전트와 터미널 세션을 실시간으로 공유하게 된다면, 가장 먼저 맡기고 싶은 일은 뭔가요? 댓글로 이야기 나눠봐요.

---

🔗 출처: Hacker News