터미널을 버리고 멀티 에이전트 GUI로 옮긴 진짜 이유

자연스러운 한국어 제목: 터미널의 시대를 지나, 멀티 에이전트 개발을 위한 GUI로

URL: https://www.youtube.com/watch?v=ggOlrPsT5_c
날짜: 2026-08-19
채널: Tech Bridge

---

📌 핵심 질문 / 터미널에서 GUI로 옮긴 이유

==터미널은 한두 개의 작업을 빠르고 단순하게 처리하는 데는 뛰어나지만, 여러 AI 에이전트와 프로젝트를 병렬로 운영하는 현재의 개발 방식에는 GUI가 더 적합하다.==

• 13살 때부터 GNU screen과 tmux를 사용해 온 터미널 중심 개발자도 병렬 에이전트가 늘어나자 작업 위치와 상태를 기억하는 데 과도한 인지 부하를 겪었다.
• GUI는 프로젝트·worktree·에이전트 thread를 한 화면에서 찾아 이동하게 하고, 이미지 붙여넣기·스크롤·원격 제어를 기본 동작으로 제공한다.
• SSH와 모바일 터미널은 연결이 끊기거나 입력이 지연되면 작업이 사라지지만, 원격으로 지속되는 GUI는 노트북을 닫아도 작업을 계속한다.
• 터미널에서 GUI로 옮긴 뒤 병렬 작업을 실제로 끝내는 양이 주 3~4개 PR에서 바쁜 날 하루 최대 20개 PR로 늘었다.

터미널의 장점이 사라진 것이 아니라 작업의 모양이 바뀌었다. 프로젝트 수와 에이전트 수가 계속 변하고, 이미지와 장시간 원격 작업이 일상화된 환경에서는 고정된 pane·hotkey 체계가 유연한 작업 목록과 시각적 상태 관리보다 불리하다. 따라서 목표는 터미널을 폐기하는 것이 아니라 GUI를 주 표면으로 삼고 필요할 때 터미널을 내부 도구로 호출하는 것이다.

1. 터미널을 삶의 기본 환경으로 삼았던 개발자의 전환

터미널을 싫어해서가 아니라, 터미널을 누구보다 사랑했던 사람이 작업의 중심을 옮겼다는 점이 전환의 의미를 만든다.

1.1. 13살부터 이어진 터미널 우선 습관

1. 코드를 쓰기 전부터 터미널을 사용했다
   1. Minecraft 서버를 호스팅하고 세계 곳곳의 컴퓨터에 SSH로 접속하는 데 터미널을 썼다.
   2. 각종 실험과 시스템 관리, 일상적인 작업 대부분을 터미널 안에서 처리했다.
2. 도구를 자기 손에 맞게 개조했다
   1. GNU screen이 표준이던 시절에 깊이 수정한 설정을 직접 만들었고, 이후 tmux로 옮겨 갔다.
   2. 올해 초 새 컴퓨터에서 개인 도전으로 terminal tab을 사용하며 tmux를 벗어나려 했지만 결국 실패했다.
3. GUI를 쓸 줄 몰라서 터미널을 고집한 것이 아니다
   1. VS Code에서 코드를 스크롤하고 trackpad나 mouse로 클릭·선택하는 경험은 좋아했다.
   2. 다만 실제 일상 업무와 Git 작업은 거의 늘 터미널에서 진행했다.

1.2. 터미널이 사라진 것을 알아챈 순간

1. 재부팅 뒤 터미널을 여덟 시간 넘게 열지 않았다
   1. 여러 일을 처리하던 중 터미널을 찾으려고 Command-Tab을 눌렀지만, 재부팅 이후 터미널 앱을 한 번도 실행하지 않았다는 사실을 깨달았다.
   2. 터미널이 필요하지 않은 상태로 8시간 이상 일했다는 사실이 “더 이상 터미널에서 일하지 않는다”는 자각으로 이어졌다.
2. 변화의 원인은 취향보다 작업 구조였다
   1. 멀티 에이전트 개발에서는 한 세션에 명령을 입력하는 능력보다 어떤 프로젝트의 어떤 thread가 어디에서 무슨 일을 하는지 추적하는 능력이 중요해졌다.
   2. 터미널에 익숙한 사람조차 이 상태 추적을 위해 실제 작업보다 더 많은 시간을 쓰게 됐다.

2. GUI로 향한 단계별 여정

전환은 한 번의 제품 출시로 일어난 것이 아니라 Antigravity, Cursor, Codex를 거치며 “터미널이 미래의 작업량을 감당할 수 있는가”를 재평가하는 과정이었다.

2.1. Antigravity가 보여 준 agent manager

1. 처음에는 제품 전체에 크게 감탄하지 않았다
   1. Antigravity를 처음 써 봤을 때 대부분은 인상적이지 않았고, 화면에 남겨 두는 것조차 민망하다고 농담했다.
   2. 그래도 한 가지 기능은 강하게 남았다.
2. 여러 프로젝트의 에이전트를 한 외부 화면에서 봤다
   1. 단축키로 agent manager를 열면 서로 다른 Antigravity 창에서 실행 중인 에이전트의 상태를 한 번에 확인할 수 있었다.
   2. 세 프로젝트를 각각 다른 창에서 열어도 왼쪽 sidebar의 프로젝트와 thread 목록으로 각 작업을 한 외부 시야에서 추적할 수 있었다.
3. 복수 작업을 하나의 목록으로 보는 경험이 전환의 첫 계단이 됐다
   1. “프로젝트 안의 thread를 외부에서 보는” 구조는 이후 Codex와 T3 Code에서 더 완성도 높게 구현할 핵심 패턴이 됐다.
   2. Antigravity가 엉망이 아니었다면 이 기능만으로 더 오래 사용했을 것이라고 평가했다.

2.2. Cursor에서 얻은 hybrid workflow

1. Cursor는 prompt 표면, 터미널은 실행 표면이었다
   1. Cursor sidebar에서 작업을 지시하고 결과를 받은 뒤, worktree 경로를 찾아 터미널에서 cd해야 실행·설치·검증을 할 수 있었다.
   2. 내장 터미널은 당시 사용하기 어려워서 Cursor 팀에 worktree 경로를 한 번에 복사하는 버튼을 만들어 달라고 강하게 요구했다.
2. Git과 검증은 stock CLI에 남겼다
   1. Cursor에서 prompt를 보내고, 터미널에서 diff 검토·Git history 읽기·변경 조사·코드 실행을 했다.
   2. 사용 비중은 prompt용 Cursor와 나머지 작업용 터미널이 대략 50 대 50이었다.
   3. Git은 기본 명령을 거의 그대로 사용했고, commit·push를 한 줄로 처리하는 작은 helper만 가끔 덧붙였다.
3. 이 구조는 작업이 늘기 전까지는 합리적이었다
   1. 하나의 prompt 결과를 한 worktree에서 확인하는 흐름에는 터미널이 충분했다.
   2. 그러나 여러 에이전트의 상태를 동시에 보고, 이미지와 원격 작업을 섞고, 프로젝트가 새로 생겼다 사라지는 상황에는 두 표면을 계속 오가는 비용이 커졌다.

2.3. Codex 앱이 제공한 첫 번째 완성형 경험

1. 모델 성능 개선과 Codex 앱 출시가 결합됐다
   1. Antigravity를 보며 “끔찍하지만 미래의 모습일 수 있다”고 느꼈던 판단이 Codex 앱을 만나면서 현실적인 기대가 됐다.
   2. 작업을 프로젝트별로 나누고, 각 프로젝트의 상태를 분명하게 보고, 서로 다른 worktree에서 여러 작업을 병렬로 실행할 수 있었다.
2. GUI의 기본 동작이 실제 시간을 줄였다
   1. 필요하면 앱 안에서 터미널을 즉시 열 수 있었다.
   2. 화면을 캡처해 붙여 넣고, 텍스트를 선택해 복사하고, 서식이 깨지지 않은 채 스크롤할 수 있었다.
   3. 작업 사이를 hotkey 조합이 아니라 클릭으로 이동할 수 있었다.
3. Codex 앱 안에서도 터미널을 보조 도구로 썼다
   1. 초기에는 Codex 인스턴스 안의 터미널로 Git history를 확인할 만큼 CLI의 역할을 유지했다.
   2. GUI는 터미널을 없애는 대신, 터미널을 필요할 때 호출하는 주 표면으로 바꿨다.
4. 닫힌 소스의 한계도 분명했다
   1. Codex 앱이 regression을 일으키거나 원하는 기능이 빠져도 직접 고치기 어려웠다.
   2. Codex 앱이 ChatGPT 앱으로 통합되면서 개발자용 앱이 비개발자에게도 열렸지만, 제품 이름과 표면이 바뀌고 provider별 기능이 분산됐다.

3. tmux와 cmux가 드러낸 병렬 작업의 인지 부하

터미널은 역사적으로 초기 설정 비용을 지불하면 이후 정신적 비용이 낮아지는 도구였다. AI 에이전트 시대에는 프로젝트 수와 작업 상태가 계속 바뀌어 그 전제가 무너진다.

3.1. pane와 hotkey가 작업 수를 따라가지 못했다

1. 세 개까지는 머릿속 배치가 가능했다
   1. tmux의 특정 hotkey를 특정 pane 또는 프로젝트와 연결해 “이 세 panel은 이 세 작업”이라는 내부 지도를 만들었다.
   2. 네 번째 panel은 임시 작업, 다섯 번째는 여분 작업처럼 규칙을 추가하면서 시스템을 유지했다.
2. 여섯 번째 작업이 들어오면 모델이 붕괴했다
   1. 새로운 작업이 기존 pane 배치에 들어오지 않으면 hotkey와 위치를 다시 기억해야 했다.
   2. 어떤 hotkey가 어떤 작업인지, 어느 Linux box의 어느 session인지 추적하는 일이 실제 코딩보다 더 커졌다.
3. 재부팅은 상태 기억을 모두 없앴다
   1. 한 Linux box에 Claude Code와 Codex 작업을 위한 tmux terminal을 약 30개 열어 두고, 다른 Linux box에도 장시간 실험 session을 유지했다.
   2. 재부팅으로 session이 사라지면 각 terminal이 무엇이었는지 다시 찾아야 했다.
   3. 이름을 바꾸거나 정리할 수는 있지만, 그렇게 유지하는 수고 자체가 mental overhead가 됐다.

3.2. cmux가 가장 가까이 간 절충안

1. cmux는 terminal에 sidebar를 붙였다
   1. cmux는 Codex 앱과 비슷한 sidebar로 작업을 분류하면서 한쪽에는 익숙한 terminal을 제공했다.
   2. SSH로 접속하는 모든 컴퓨터를 SSH라는 작은 folder에 넣어 두면 원하는 장비로 빠르게 이동할 수 있었다.
2. 그래도 작업을 더 많이 하게 만든 것은 UI였다
   1. 읽기 편한 text, 쉬운 탐색, 의미 있는 category, 컴퓨터의 실제 위치에 기반한 project가 작업을 찾는 비용을 낮췄다.
   2. terminal 자체를 버리지 않은 상태에서도 실제로 코딩하는 양이 늘었다.
3. 핵심은 terminal 대 GUI의 이분법이 아니다
   1. terminal은 명령 실행과 Linux 환경에서 여전히 강력하다.
   2. 여러 agent thread를 분류·탐색·전환하는 outer surface로는 sidebar와 project 목록이 더 적합하다.

4. 이미지와 SSH가 만든 숨은 비용

이미지 입력과 원격 지속성은 AI 코딩에서 부가 기능이 아니라 핵심 작업 조건이다.

4.1. screenshot을 보내는 일은 GUI에서 기본, terminal에서 프로젝트였다

1. 대략 절반의 prompt에 이미지가 들어갔다
   1. 앱 화면의 이상한 상태나 명령 실행 뒤 예상하지 못한 error는 말로 설명하는 것보다 screenshot을 찍어 “고쳐 달라”고 보내는 편이 빠르다.
   2. 모델이 screenshot을 읽는 능력은 효과적이지만, terminal에서는 이미지가 무엇인지 확인하고 전송하는 과정 자체가 불안정했다.
2. SSH 위 tmux에 이미지 붙여넣기를 직접 구현했다
   1. 원격 T3 Code/Codex 인스턴스에 Command-V로 이미지를 전달하려고 tmux·SSH·터미널 계층을 거치는 기능을 만들었다.
   2. 오랫동안 buggy했고 나중에야 상대적으로 안정됐지만, screenshot 하나를 agent에 보내는 기본 동작에 별도의 시간과 노력이 필요했다.
3. GUI에서는 같은 동작이 즉시 끝난다
   1. 캡처, paste, 미리보기, 전송이 같은 표면 안에서 이어진다.
   2. 이 차이는 prompt 수가 많아질수록 누적된다.

4.2. SSH는 강력하지만 취약한 연결 계층이다

1. 좋은 네트워크에서도 입력이 끈적거렸다
   1. Wi-Fi 7과 기가비트에서 10Gbps 수준의 네트워크를 쓰고, 책상에서는 10Gbps Ethernet으로 연결했는데도 Claude Code over SSH 입력에 sticky key가 나타났다.
   2. 원인을 추적한 뒤 Wi-Fi에 묶여 있었다는 사실을 알았지만, 개발자가 이런 연결 상태까지 신경 써야 한다는 것 자체가 부조리했다.
2. 모바일 terminal은 실전 작업 표면이 되기 어렵다
   1. Termius를 유료로 구매해 지원하고 실제 debugging에도 사용하지만, 취약성 때문에 기본 도구로 삼지는 않는다.
   2. SSH3와 Mosh가 더 나은 선택일 수 있어도 marginal improvement를 위해 여러 계층을 설정하고 휴대폰에서 terminal로 진짜 일을 하는 부담은 너무 크다.
   3. 휴대폰에서 terminal로 Claude Code를 돌리는 것이 완전히 괜찮다는 주장에는 현실적인 의문이 남는다.
3. 연결이 끊기면 장시간 작업도 함께 끊겼다
   1. 이동·약속·행사 중 Wi-Fi가 사라지면 실행 중인 agent가 죽었다.
   2. 노트북을 닫는 순간 작업이 끝나므로 작업 시간을 노트북을 열어 둘 수 있는 구간에 맞춰야 했다.

5. GUI에 요구한 조건과 터미널이 채우지 못한 영역

새 도구의 조건은 특정 provider의 취향이 아니라 병렬 에이전트 개발을 지속 가능하게 만드는 운영 요구였다.

5.1. 필요한 기능 목록

1. 입력과 모델 선택
   1. screenshot을 쉽게 붙여 넣을 수 있어야 한다.
   2. Claude Code subscription과 Codex subscription을 모두 연결해 공식 요금제에 포함된 모델을 활용해야 한다.
   3. 8,000~14,000달러 상당의 사용량을 200달러 요금제로 쓰는 subsidization을 잃지 않아야 한다.
2. 운영 환경
   1. 원격 제어가 좋아야 한다.
   2. Linux 지원이 최고 수준이어야 한다. Linux에서는 worktree 생성이 약 2초로, 30초에서 2분이 걸리는 환경보다 빠르다.
   3. 성능과 battery impact가 좋아야 한다.
3. 병렬성
   1. 많은 작업을 한꺼번에 관리하고, 어떤 agent가 어떤 project에서 무엇을 하는지 빠르게 찾아야 한다.
   2. 한두 개를 넘어서는 순간에도 작업 상태를 기억하는 정신적 장치를 새로 만들지 않아야 한다.

5.2. 터미널이 유일하게 확실히 제공한 것

1. Linux 지원은 터미널의 강점이다
   1. Ryzen AI Max 기반 Framework desktop Linux box에는 32 cores가 있고, agent를 무겁게 돌려도 utilization이 3분의 1을 넘기 어렵다.
   2. Linux는 macOS처럼 Codex 동작을 모두 스캔하는 복잡한 보안 처리 부담이 적어 agentic work에 유리하다.
2. 나머지 조건은 terminal이 해결하지 못했다
   1. terminal은 원격 제어, 모바일 지속성, 이미지 전송, 프로젝트 분류, 상태 탐색, battery 효율을 자동으로 보장하지 않는다.
   2. 따라서 terminal은 최고의 실행 환경일 수 있지만, 현재의 agent 작업을 관리하는 최고의 interface는 아니다.

6. T3 Code가 탄생한 이유와 구현 방향

T3 Code는 terminal을 싫어하는 개발자와 terminal의 한계를 체감한 개발자가 같은 문제를 서로 다른 각도에서 해결한 결과다.

6.1. Theo와 Julius의 출발점 차이

1. Theo에게 T3 Code는 open-source 대안이었다
   1. Codex 앱을 사랑하면서도 닫힌 소스와 성능 문제를 해결하고 싶었다.
   2. SwiftUI와 AppKit으로 Codex용 native GUI를 만들려다 큰 text를 스크롤하는 성능 지옥을 겪었고, Chrome이 이 문제를 잘 해결한다는 점을 인정해 Electron으로 방향을 틀었다.
2. Julius에게 T3 Code는 terminal 탈출구였다
   1. Julius는 Git을 VS Code extension으로만 다루고, dev server를 띄울 때 외에는 terminal을 거의 열지 않는다.
   2. terminal 명령을 많이 아는 뛰어난 개발자이면서도 terminal을 싫어하는 사람으로, 여러 provider의 agent를 GUI 하나에서 같은 방식으로 쓰고 싶어 했다.
3. 반복 개선이 Codex 앱을 추월했다
   1. 초기 몇 달 동안 Theo는 T3 Code와 Codex 앱을 오갔지만 Codex 앱을 더 많이 사용했다.
   2. Julius는 T3 Code를 계속 개선해 worktree와 여러 agent harness의 신뢰성·안정성·통합 품질을 끌어올렸다.

6.2. 여러 provider를 같은 표면으로 통합했다

1. 지원 범위가 확장됐다
   1. Claude Code, Codex, OpenCode, Grok을 같은 GUI에서 사용할 수 있게 했다.
   2. Cursor 통합도 진행 중이며, 추가 업데이트가 예정돼 있다.
2. 구독과 공식 harness를 유지했다
   1. -p 같은 우회 hack이 아니라 Anthropic이 승인한 공식 Agent SDK를 사용한다.
   2. Claude Code와 Codex subscription을 사용자의 컴퓨터에서 그대로 연결해 provider별 subsidized rate를 유지한다.
   3. 각 lab과 정책을 조율해 구독을 앱에서 제공하는 방식이 차단되지 않도록 했다.
3. 모든 도구의 동작을 동일하게 만들었다
   1. provider마다 terminal app과 hotkey를 새로 외울 필요 없이 하나의 project·thread·archive·settle 흐름을 쓴다.
   2. provider별로 기능이 분리되던 문제를 한 화면의 일관된 탐색 방식으로 완화한다.

6.3. Electron과 WebSocket이 원격 제어의 기반이 됐다

1. 첫 구현은 성능 문제에서 시작됐다
   1. native GUI를 버린 뒤 Electron에서 remote control을 쉽게 만들 수 있도록 모든 연결을 Electron RPC가 아니라 WebSocket 중심으로 설계했다.
   2. 초기 T3 Code는 매우 못생겼지만 시스템 성능을 덜 잡아먹는 open-source GUI로서 쓸 만한 결과를 냈다.
2. 어디서든 같은 작업을 이어 간다
   1. 한 컴퓨터에 T3 Code를 설치하면 다른 컴퓨터의 앱, app.t3.codes 웹사이트, iOS·Android mobile app에서 그 머신을 제어할 수 있다.
   2. 현재 앱과 mobile app 모두 open source라서 직접 빌드할 수 있다.
   3. thread를 계속 보고, prompt를 추가하고, history를 스크롤하고, 이미지를 붙여 넣고, 필요하면 terminal도 열 수 있다.

6.4. 노트북을 닫아도 agent가 살아 있는 workflow

1. 작업 장소가 agent 실행 시간표를 결정하지 않게 됐다
   1. 노트북 발열과 fan noise가 회의 microphone을 방해할까 봐 agent 실행을 회의 전후로 미루던 문제가 사라졌다.
   2. 약속·여행·행사로 Wi-Fi가 끊길 예정이면 agent를 시작하지 않던 습관도 없어졌다.
2. Uber에서 작업을 잃던 경험이 바뀌었다
   1. Theo는 여러 행사에 이동하는 Uber 안에서 조용히 코딩하는 시간을 확보했지만, Opus 4.5로 몇 시간 걸리는 작업을 돌린 뒤 나쁜 mobile data 때문에 노트북을 닫으면 agent가 죽었다.
   2. 이제 원하는 컴퓨터를 선택해 prompt를 보내고 노트북을 닫으면 된다.
3. 앱이 완전히 종료돼도 상태가 유지된다
   1. deep audit 같은 장시간 task를 시작한 뒤 T3 Code를 Command-Q로 종료해도 작업은 remote machine에서 계속 진행된다.
   2. 다시 열거나 웹·mobile app으로 접속하면 여러 컴퓨터에서 같은 thread를 확인하고 이어서 prompt를 보낼 수 있다.
4. 간단한 연결 경로도 제공한다
   1. Tailscale 사용자는 npx t3 nightly pair-tailscale로 pairing code 또는 web 연결 URL을 받을 수 있다.
   2. t3 nightly serve로 instance를 호스팅하거나, npx t3 connect로 GitHub·Google 등으로 로그인해 Linux machine의 background instance에 계속 연결할 수 있다.
   3. 당시 connect 방식은 Linux를 우선 지원하고 Mac 지원은 예정돼 있었다.

7. 닫힌 도구에서 열린 개발 표면으로

AI가 코드를 만들고 AI가 개발 도구를 커스터마이즈할 수 있게 된 시기에, 개발자의 도구를 다시 닫힌 소스에 묶는 흐름은 역설적이다.

7.1. Atom과 VS Code가 보여 준 개방의 역사

1. 과거 편집기는 닫혀 있었다
   1. Visual Studio와 Sublime Text 같은 편집기는 extension 개념이 제한적이어서 사용자가 원하는 방식으로 깊게 고치기 어려웠다.
   2. GitHub Atom이 Electron 위에 만들어지면서 편집기 자체를 수정할 수 있는 길이 넓어졌다.
2. VS Code가 커스터마이즈를 표준으로 만들었다
   1. Microsoft의 VS Code는 open-source Electron editor로 성장했고, 개발자의 80% 이상이 사용하는 업계 표준이 됐다.
   2. 개발자는 자신이 쓰는 도구를 확장하고 workflow에 맞게 바꿀 수 있었다.
3. AI 시대에 다시 닫히고 있다
   1. Cursor는 closed-source fork, Claude Code는 closed-source terminal, Codex desktop app은 closed-source desktop app으로 제공된다.
   2. AI 도구가 더 쉽게 커스터마이즈될 수 있는 시기에, 오히려 사용자가 regression을 직접 고치거나 필요한 기능을 추가할 권한을 잃었다.

7.2. T3 Code의 목표

1. 수익보다 counter-source에 가까운 도구를 만든다
   1. Theo는 돈을 벌 목적이었다면 OpenAI나 Anthropic에 제품을 팔 수도 있었지만, 지금은 게임과 개발 경험에 대한 frustration과 love 때문에 독립적인 open-source 표면을 택했다고 밝혔다.
   2. 장기적인 수익 가능성을 부정하지는 않지만, 당장의 목표는 AI 코딩을 위한 최고의 open-source solution을 만드는 것이다.
2. 사람이 실제 결과를 완성하도록 돕는다
   1. 목표는 모델에게 prompt를 던지는 terminal이 아니라, 작업이 실제로 landed되도록 project·thread·worktree·remote 상태를 관리하는 graphical interface다.
   2. 새 세대 개발자가 닫힌 도구에 적응하는 대신, agent가 도구 자체를 커스터마이즈할 수 있는 환경을 갖게 하려 한다.

8. 결론과 실전 적용 포인트

1. 터미널의 역할을 실행 계층으로 재정의한다
   1. 명령 실행, Git의 세밀한 조작, Linux 작업, 긴급한 debugging은 terminal에 남겨 둔다.
   2. project 분류, agent 상태 확인, thread 전환, 이미지 입력, 원격 지속성은 GUI에 맡긴다.
2. 작업 수가 늘어날수록 GUI 전환을 실험한다
   1. 한두 개 작업에서는 tmux pane과 hotkey가 빠를 수 있다.
   2. 세 개를 넘어 여러 worktree와 장시간 agent가 동시에 돌아가면 sidebar·category·click navigation이 인지 부하를 줄이는지 직접 비교한다.
3. GUI 선택 기준을 제품 이름보다 기능으로 세운다
   1. Codex, T3 Code, Cursor의 새 GUI, Conductor 등 어떤 제품이든 provider 구독, Linux, mobile, remote, 이미지, 성능, open-source 범위를 점검한다.
   2. 특정 GUI를 강제할 필요는 없지만, Claude Code desktop처럼 terminal 중심 표면을 그대로 감싼 제품과 실제 agent manager를 구분한다.
4. 원격 workflow를 먼저 안정화한다
   1. Linux box에 agent를 실행하고, 노트북·휴대폰은 상태 확인과 prompt 전달 표면으로 사용한다.
   2. 작업을 시작하기 전 laptop을 계속 열어 둘 수 있는지 계산하는 방식에서 벗어나, 연결이 끊겨도 작업이 살아 있는지 확인한다.
5. 터미널 숙련도를 새로운 interface 숙련도로 옮긴다
   1. terminal wizard가 될 수 있었던 사람은 agent wizard가 될 잠재력이 있다.
   2. 익숙한 hotkey를 지키는 것보다 오늘의 작업량과 작업 형태에 맞는 interface를 선택하는 것이 중요하다.

주요 발언 모음

“저는 터미널을 사랑하지만, 오늘날 우리가 하는 일에는 터미널이 더 이상 올바른 모양이 아닙니다.”

“터미널이 당신을 붙잡지 않는 유일한 경우는 충분히 크게 만들고 있지 않을 때일지도 모릅니다.”

“저는 작업을 실행할 컴퓨터를 고르고 prompt를 보낸 다음, 그 일에 대해 생각하는 것을 멈출 수 있게 됐습니다.”

“GUI는 터미널을 없애는 것이 아니라, 여러 에이전트와 프로젝트를 관리하는 더 나은 표면을 제공합니다.”

“이것은 돈을 벌기 위한 비밀 계획이 아니라 frustration과 게임에 대한 사랑에서 시작했습니다.”

“터미널에서 진짜 graphical interface로 옮긴 것이 주 3~4개 PR에서 바쁜 날 하루 20개 PR로 바뀐 중요한 이유 중 하나였습니다.”

“AI 개발 도구도 과거의 편집기처럼 사용자가 고칠 수 있고 커스터마이즈할 수 있어야 합니다.”

핵심 데이터 & 수치

• 터미널 사용 기간: 13살부터 대부분의 삶 동안 terminal을 주력으로 사용했다.
• 터미널 미사용 시간: 재부팅 뒤 8시간 이상 terminal을 열지 않고 일했다.
• 동시 session 수: 한 Linux box의 tmux에 Claude Code·Codex 작업용 terminal 약 30개를 유지했다.
• 이미지 prompt 비중: prompt의 대략 절반에 screenshot 또는 다른 이미지가 들어갔다.
• 네트워크 환경: Wi-Fi 7과 1~10Gbps급 유선 환경에서도 SSH 입력 지연과 sticky key를 겪었다.
• Linux worktree 생성 시간: Linux에서는 약 2초, 다른 환경에서는 30초~2분이 걸릴 수 있다고 비교했다.
• Linux machine 자원: 32-core Ryzen AI Max Framework desktop에서도 agent 작업으로 utilization 3분의 1을 넘기기 어려웠다.
• 구독의 경제성: 8,000~14,000달러 상당의 모델 사용량을 약 200달러 구독으로 활용하는 subsidization을 유지하고 싶어 했다.
• PR 처리량 변화: 주 3~4개에서 바쁜 날 하루 최대 20개로 늘었다.
• VS Code 보급률: 개발자의 80% 이상이 사용하는 업계 표준으로 언급됐다.

최종 결론

터미널은 사라질 도구가 아니라 내부 실행 계층으로 남는다. 그러나 AI agent가 여러 project와 worktree에서 동시에 장시간 작업하고, screenshot을 입력으로 받고, remote machine에서 지속적으로 실행되는 시대에는 terminal의 선형적·기억 의존적 구조가 작업 전체를 관리하기에 좁다. GUI는 project와 thread를 발견하고, 상태를 분류하고, 클릭으로 전환하고, 이미지와 원격 작업을 연결하는 outer surface가 된다. 가장 현실적인 변화는 terminal을 버리는 선언이 아니라 GUI를 기본 화면으로 올리고 terminal을 필요할 때 호출하는 workflow를 직접 시험하는 것이다.