터미널과 작별하다

URL: https://www.youtube.com/watch?v=dLhcLqoff6k
날짜: 2026-08-18
채널: t3dotgg
원문 제목: I'm done with terminals
VIDEO_ID: dLhcLqoff6k
원본 발행일: 2026-08-18

---

📌 핵심 질문 / 터미널 중심 개발의 핵심 논점

==AI 에이전트를 여러 프로젝트에서 동시에 운용하는 현재의 개발 방식에는 터미널보다 작업을 시각적으로 관리하고 원격으로 이어가는 GUI가 더 잘 맞는다.== 터미널은 여전히 강력하고 Linux 지원도 뛰어나지만, 에이전트·워크트리·이미지·원격 작업이 늘어난 환경에서 세션을 찾고 상태를 유지하는 비용이 생산성의 핵심 병목이 된다.

• 13살부터 터미널을 써 온 터미널 애호가조차 재부팅 뒤 8시간 넘게 터미널을 열 필요가 없었다는 사실로 변화를 깨달았다.
• Codex 앱 같은 GUI는 여러 프로젝트와 에이전트 작업을 클릭으로 오가고, 텍스트·이미지·Git 상태를 한 화면에서 확인하게 해 정신적 오버헤드를 낮춘다.
• T3 Code는 Claude Code·Codex·OpenCode·Grok·Cursor를 하나의 오픈소스 표면에서 쓰고, 다른 컴퓨터나 웹·모바일에서 같은 작업을 이어가도록 만든다.

핵심 변화는 터미널의 성능이 부족해서가 아니라 작업의 형태가 바뀌었기 때문에 일어난다. 예전 터미널은 약간의 초기 설정만 감수하면 늘 같은 방식으로 낮은 정신적 비용을 제공했지만, 오늘의 작업은 새 프로젝트와 오래된 프로젝트를 오가며 한두 개에서 열 개까지 병렬 수가 크게 변한다. 이때 고정된 창·단축키·SSH 세션으로 상태를 관리하는 방식보다, 프로젝트·스레드·워크트리·기기를 직접 보여 주고 클릭으로 이동하는 GUI가 실제 작업을 더 잘 담아낸다.

1. 터미널 중심 개발자에게 일어난 전환

터미널을 싫어해서가 아니라 터미널을 너무 오래 사랑해 온 사람이 작업 방식의 한계를 인정하게 된 과정이다.

1.1. 터미널 애호가의 자기고백

1. 겉모습과 실제 취향의 차이

   1. 밈과 자기소개: VS Code 포크에 투자하고 JavaScript로 바이브 코딩(vibe coding)을 하는 사람처럼 보이지만, 스스로를 “터미널 우선(terminal first)” 개발자라고 규정한다. GUI에서 코드를 스크롤하고 트랙패드나 마우스로 클릭·선택하는 일은 좋아하지만, 일상 업무 대부분은 오랫동안 터미널에서 처리했다.
   2. 코딩 전부터 이어진 사용 경험: 코드를 쓰기 전부터 터미널로 Minecraft 서버를 호스팅하고 전 세계 컴퓨터에 SSH로 접속하며 여러 실험을 했다. GNU screen이 표준이던 시절에는 설정을 깊게 개조했고, 나중에 tmux로 옮겼다.

2. 변화를 알아차린 순간

   1. 8시간의 공백: 며칠 전 많은 일을 처리하던 중 터미널을 찾으려고 ⌘ 명령을 시도했지만, 재부팅 후 터미널을 한 번도 열지 않았다는 사실을 발견했다. 8시간 이상 터미널이 필요하지 않았던 것이다.
   2. 결론: 13살 이후 삶의 대부분을 실행·작업·감사(audit)·일상 업무에 터미널을 써 온 사람도 더 이상 터미널에서 일하지 않았다. 이 개인적 변화의 이유를 정면으로 설명해야 한다는 문제의식이 출발점이다.

1.2. 후원 구간: CI 도구 Blacksmith

1. GitHub Actions에서의 이탈

   1. 배포 흐름: 새 프로젝트를 출시할 때마다 먼저 GitHub에 올리고, 실제 CI가 필요해지는 즉시 Blacksmith를 사용한다. GitHub Actions는 더 이상 다루고 싶지 않은 선택지가 됐다.
   2. 비용·속도 이점: 속도만 좋아도 쓸 가치가 있고, 가격만 저렴해도 가치가 있으며, 캐시 다운로드가 4배 빨라도 가치가 있다고 평가한다.

2. 관측성과 실행 환경

   1. CI 관측성: 어떤 작업이 성공·실패했는지, 어디에서 왔는지, 시간이 어디에 쓰였는지를 보여 주는 관측성이 특히 유용하다. T3 Code 같은 프로젝트의 CI가 느린 원인을 파악하고 수정하기 쉬워진다.
   2. 고급 실행 옵션: 기본적으로 빠르고, SSH로 실행 머신에 들어가 상태를 확인하거나 iOS·Mac 앱 빌드에 필요한 네이티브 Mac 러너(native Mac runner)를 쓸 수 있다. GitHub Actions를 몇 달째 선택하지 않아 시간 비교 자체가 어려워졌다는 농담도 덧붙인다.
   3. 안내: 스트레스·시간·비용을 줄이는 CI를 soy.link/blacksmith에서 확인하라고 권한다.

2. GUI로 기울게 된 계기

터미널의 단순한 입력 능력보다 여러 에이전트의 상태를 한눈에 파악하는 능력이 중요해졌다.

2.1. T3 Code 홍보라는 비판과 Antigravity

1. 예상한 반발

   1. 이해상충 의혹: “자기 제품 T3 Code를 홍보하려고 터미널을 싫어한다고 말한다”는 댓글이 쏟아질 것을 예상한다. 자신의 믿음 때문에 오픈소스 제품에 막대한 시간과 돈을 썼다는 점을 들어, 제품을 만들었기 때문에 믿음을 거짓으로 말한다는 추론은 말이 되지 않는다고 반박한다.
   2. 독설 섞인 농담: 이미 Obsidian 관련 댓글을 스크롤하면 자기 홍보라는 비난이 백 개쯤 있을 것이라며, 그런 댓글을 쓰기 전에 조금 더 생각하라고 강하게 말한다. 당장은 이해상충 의혹을 피하려고 ChatGPT 앱에서 사례를 이어간다.

2. Antigravity의 작은 발견

   1. 첫인상과 예외: Antigravity를 처음 써 봤을 때 대부분은 인상적이지 않았고, 엉망인 제품이라 조금 써 보고 말았을 것이라고 평가했다. 다만 단축키로 여는 에이전트 관리자(agent manager) 화면은 특별했다.
   2. 외부 통합 보기: 세 프로젝트를 각각의 창에서 실행할 때 한 창의 왼쪽 사이드바에 프로젝트와 스레드를 모아, 다른 창에서 에이전트가 무엇을 하는지 볼 수 있었다. 이 경험이 여러 작업을 외부 화면에서 관리하는 발상의 첫 단계가 됐다.
   3. 자기 제품과의 닮음: “어디서 본 듯한” 구조라는 농담을 하며, 인정하기 싫지만 Antigravity의 agent manager가 처음으로 그 경험을 줬다고 말한다. Antigravity의 새 agent manager workflow는 좋은 아이디어이며 작은 구성 요소들이 기대된다고 평가한다.

2.2. Cursor에서의 50 대 50 분할

1. 워크트리 경로의 마찰

   1. Cursor 사무실에서의 불만: Cursor v2 agent view의 새 통합 기능이 오히려 터미널 사용을 어렵게 만들었다. 사이드바에서 에이전트에게 일을 시킨 뒤 결과를 확인하고, 실제 실행·설치·검토를 위해 해당 worktree 경로를 알아내 cd해야 했기 때문이다.
   2. 내장 터미널 거부: 당시 내장 터미널은 실사용하기 어렵다고 판단했고, 필요한 경로를 한 번에 복사하는 버튼을 추가해 달라고 강하게 요구했다. 그 결과 한 번의 클릭으로 경로를 복사할 수 있게 됐다.

2. 프롬프트와 실제 작업의 분리

   1. 역할 분담: Cursor는 프롬프트를 보내는 공간으로, 터미널은 diff 검토·Git history 읽기·변경 조사·코드 실행의 공간으로 사용했다. 두 환경에 시간을 거의 50 대 50으로 나눴다.
   2. Git 습관: Git은 기본 CLI 명령을 사용했고, commit과 push를 한 줄로 묶는 작은 helper를 가끔 추가했을 뿐 대부분은 표준 Git CLI를 고수했다.

3. Codex 앱이 보여 준 GUI의 장점

모델 품질이 좋아진 시점에 Codex 앱이 등장하면서, 터미널의 초기 설정 비용보다 GUI의 탐색성과 상태 관리가 더 중요하다는 판단이 굳어졌다.

3.1. 프로젝트·워크트리·텍스트의 가시성

1. 다중 프로젝트 작업

   1. 분리된 작업 공간: 일을 여러 프로젝트로 나누고 각각의 상태를 명확히 볼 수 있으며, 서로 다른 worktree에서 여러 작업을 동시에 실행할 수 있다.
   2. 필요할 때만 터미널: Codex 인스턴스 안에서 필요하면 터미널을 바로 열어 명령을 입력할 수 있고, Git history도 그 안의 터미널로 확인할 수 있다. 터미널 기능을 버리는 것이 아니라 적절한 위치에 배치하는 방식이다.

2. 클릭·복사·스크린샷의 차이

   1. 정보 손실 감소: 화면을 캡처해 붙여 넣고, 텍스트를 선택해 복사해도 서식이 망가지지 않는다. 스크롤도 크게 버벅이지 않는다.
   2. 전환 비용 감소: tmux에서 세 작업 이상을 동시에 관리할 때 필요한 단축키가 너무 많고, 어떤 단축키가 어떤 작업인지 기억해야 한다. 세 패널은 세 작업, 네 번째는 다른 작업, 다섯 번째는 임시 패널이라는 식으로 머릿속 규칙을 만들다가 여섯 번째 작업이 생기면 체계가 무너진다. 클릭으로 작업 사이를 오가는 방식은 이 기억 부담을 없앤다.

3.2. tmux의 장점과 한계

1. 여전히 좋은 도구

   1. 가장 가까운 해법: tmux는 사이드바와 반대편 터미널을 결합한 구조에 가장 가까이 다가간 도구로 평가한다. 기본 터미널로 계속 쓰고, SSH로 접속하는 모든 머신은 SSH라는 폴더에 정리해 빠르게 들어간다.
   2. 개인 도전: 올해 초 새 컴퓨터에서 tmux를 벗어나 보려고 터미널 탭만 쓰는 도전을 했지만 실패했다. “스포일러: 안 됐다”라는 식으로 tmux 애호를 인정한다.

2. GUI가 더 잘한 것

   1. 읽기와 탐색: 더 읽기 좋은 텍스트, 쉬운 탐색과 검색, 이해 가능한 카테고리, 컴퓨터 위치에 기반한 실제 프로젝트가 코딩량을 늘렸다.
   2. 닫힌 소스의 문제: Codex 앱에 회귀(regression)나 문제가 생기면 고칠 수 없었다. OpenAI 팀이 피드백을 빠르고 의미 있게 반영해 준 점은 고맙지만, 무작위 회귀와 변경은 여전히 남았다.
   3. ChatGPT로의 통합: Codex 앱이 개발자가 아닌 사람도 사용할 만큼 좋아지자 기능이 ChatGPT 앱으로 넘어갔다. 기존 아이콘을 쓸 수 있게 해 줬지만, 더 이상 순수한 Codex 앱이 아니라는 점이 아쉽다고 말한다.

4. 여러 모델을 쓰는 개발자의 선택 문제

최고의 모델·가격·공식 기능을 동시에 원하면 제공자별 앱과 CLI 사이에서 갈라져야 했고, 그 갈라짐이 터미널의 정신적 비용을 키웠다.

4.1. 오픈소스 GUI 공백

1. 터미널에 몰린 선택지

   1. 좋은 터미널 도구: OpenCode와 Pi를 AI 코딩용 harness이자 터미널 도구로 높이 평가한다. 터미널에는 Codex 외에도 훌륭한 오픈소스 선택지가 많다.
   2. GUI의 종속성: Codex와 비슷한 GUI를 원하면 Claude Code 앱은 Claude 구독에, Codex 앱은 Codex 구독에 묶인다. Codex 앱을 다른 제공자와 쓰는 해킹은 어느 정도 가능하지만 정식 방식이 아니고, Claude Code 앱을 억지로 바꾸는 방식은 권하지 않는다.

2. 공식 harness와 가격의 트레이드오프

   1. OpenCode의 손실: 한곳에서 모든 것을 다루려면 OpenCode가 사실상 유일했지만, 공식 harness를 쓰지 않으므로 구독 보조금(subsidization)을 잃고 Claude Code나 Codex에 추가되는 최신 기능도 받지 못한다.
   2. 앱과 CLI의 분리: Claude는 CLI에, Codex는 데스크톱 앱에 새 기능을 더 많이 넣는 식으로 서로 반대편 지원이 약해졌다. Claude 모델이 필요하면 CLI, Codex·GPT 모델이 필요하면 GUI에 들어가야 했다.
   3. 나쁜 모델도 GUI 때문에 선택: 실제 능력이 더 좋은 모델이 있어도 좋은 앱을 쓰고 싶어서 OpenAI 모델을 기본값으로 선택하는 상황이 생겼다. 작은 불편들이 합쳐져 모델 선택까지 왜곡했다.

4.2. 상태를 잃어버리는 30개 터미널

1. 혼란의 규모

   1. 세션 추적: 터미널 세션을 잃어버릴 때마다 Claude Code를 열어 자신이 어디서 작업했는지, 어떤 worktree에서 시작했는지 다시 찾게 했다.
   2. 실제 환경: 당일 컴퓨터를 재부팅해 모든 세션을 잃었고, Linux 박스 한 대의 tmux에 Claude Code와 Codex 작업용 터미널 약 30개를 띄워 두고 있었다. 다른 Linux 박스에도 여러 세션이 남아 TypeScript를 Rust로 포팅하는 실험, 토큰이 바닥나 중단한 작업, 끝없이 실행해 결과를 보려던 작업이 뒤섞였다.

2. 역사적 장점이 현재의 단점으로 변함

   1. 예전의 터미널: 전통적으로 터미널은 초기에 조금 설정하면 이후에는 늘 같은 방식으로 작동해 정신적 비용이 낮은 대신 초기 비용이 있는 도구였다.
   2. 오늘의 유동성: 지금은 새 프로젝트·몇 달 된 프로젝트·몇 년 된 프로젝트를 오가고, 병렬 작업 수가 한 개에서 열 개까지 바뀐다. 과거에 만들어 둔 고정된 창·이름·단축키 체계가 이런 변화를 따라가지 못한다.
   3. 핵심 진단: 터미널 자체가 나빠진 것이 아니라, 자신이 만든 터미널 시스템의 경직성이 현재 작업 형태에 맞지 않게 됐다. 이를 고치려고 막대한 시간을 투자했지만, 그 시간 자체가 정신적 오버헤드의 증거가 됐다.

5. 이미지·SSH·모바일에서 드러난 취약성

터미널은 명령 실행에는 강하지만, 이미지가 포함된 에이전트 작업을 여러 기기에서 지속하는 인터페이스로는 취약했다.

5.1. 이미지 입력의 장벽

1. 억지로 만든 기능

   1. 원격 붙여넣기: tmux 계층을 통과해 SSH로 접속한 원격 tmux 인스턴스에 이미지를 ⌘V로 붙여 넣으려고 cmux와 설정을 조합했다. 한동안 매우 불안정했고, 비교적 안정화되기까지 많은 시간을 썼다.
   2. 기본 동작을 위한 비용: 스크린샷을 찍어 에이전트에게 보내는 기본 작업을 가능하게 하려고 별도 시스템을 구축해야 했다. GUI에서는 스크린샷을 바로 붙여 넣으면 된다.

2. 이미지가 주는 실용적 효과

   1. 프롬프트의 절반: 오류나 마음에 들지 않는 화면을 말로 설명하는 것보다 캡처해 “고쳐”라고 보내는 편이 쉽다. 프롬프트의 대략 절반에 이미지가 포함된다.
   2. 터미널의 맹점: 앱 화면의 스크린샷이든 명령 실행 중 나온 낯선 오류든 이미지를 모델에 보내는 것은 효과적이지만, 터미널에서 이미지를 직접 볼 수 없으면 그 효과를 온전히 활용하기 어렵다.

5.2. SSH가 만드는 지속성 문제

1. 강력하지만 연결에 의존하는 구조

   1. 세 글자의 문제: 가장 큰 불만은 터미널이나 에이전트 그 자체가 아니라 SSH다. 30년 넘게 쓰인 표준 SSH가 놀라울 만큼 강력하고 잘 작동하지만, 연결이 완벽하지 않은 순간 문제가 연쇄적으로 발생한다.
   2. 로컬 네트워크 사례: Wi-Fi 7과 유선 기준 기가비트에서 10Gbps급 네트워크를 쓰고, 아래층 책상에는 10Gbps로 연결된 컴퓨터가 있었다. 그런데 Claude Code를 SSH로 실행하던 중 입력이 끈적하게 지연됐다. 원인은 Ethernet이 아니라 Wi-Fi에 묶여 있었기 때문이었다. 무엇에 바인딩됐는지까지 신경 써야 한다는 사실 자체가 부조리하다고 평가한다.

2. 모바일 터미널의 한계

   1. 대안의 인정: SSH3가 더 낫고 mosh가 멋지다는 점을 알고 있으며, 모바일 SSH 도구인 Termius를 정가로 구매하고 개발자도 지원했다. Termius가 당일 디버깅에 도움을 주기도 했다.
   2. 기본값이 될 수 없는 이유: 그래도 이런 도구들은 연결이 깨지기 쉬워 기본 선택이 되지 않는다. 마진 수준의 개선을 위해 SSH3나 mosh를 모두 설정할 여유가 없고, 휴대폰에서 터미널로 실제 작업을 하는 것은 정신 건강과 안정성을 의심하게 만든다고 말한다.
   3. 휴대폰으로의 과장된 기대 비판: 휴대폰 터미널로 Claude Code를 쓰는 것이 완전히 괜찮다고 말하는 사람들의 신뢰성까지 의심할 정도로, 이동 중 장시간 에이전트 작업을 터미널로 유지하는 방식은 현실적이지 않다고 단언한다.

6. 원격 GUI와 T3 Code가 만든 작업 방식

작업을 실행하는 컴퓨터와 조작하는 기기를 분리하고, 연결이 끊겨도 에이전트가 계속 살아 있게 만드는 것이 핵심 해결책이다.

6.1. Codex 원격 제어에서 얻은 힌트

1. 기기 사이의 작업 연속성

   1. 더 나은 원격 경험: Codex 앱, 현재는 ChatGPT 앱을 휴대폰의 ChatGPT 앱으로 원격 제어하는 기능은 터미널보다 훨씬 나았다. 컴퓨터에서 작업을 시작하고 외출 후 휴대폰에서 같은 스레드를 끝낼 수 있었다.
   2. 생활의 변화: 컴퓨터 앞에 붙어 있는 시간이 줄었고, 집안일을 하거나 심부름을 하면서 작업 상태를 확인하는 일이 가능해졌다. 다만 버그가 많았고 Mac의 Codex 데스크톱 앱에만 제한됐다.

2. Codex 데스크톱 앱의 비용

   1. Mac 성능 문제: macOS 보안 정책과 구현 방식 때문에 스레드와 하위 에이전트마다 다섯 개가 넘는 프로세스가 생성될 수 있고, 성능을 크게 갉아먹었다.
   2. 요구사항의 정리: 이미지 붙여넣기, 모든 모델과 구독의 보조금 활용, 제대로 된 원격 제어, 최고 수준의 Linux 지원, 모바일 지원, 낮은 배터리 영향, 많은 작업을 한 번에 관리하는 기능이 필요했다.

6.2. Linux가 알려 준 기준

1. 에이전트 작업에 맞는 운영체제

   1. 파일시스템 차이: Linux는 에이전트 작업에 특히 유리하다. 파일시스템이 덜 방해하고 worktree 생성이 30초~2분이 아니라 약 2초에 끝난다.
   2. 낮은 자원 사용: Ryzen AI Max 기반 Framework Desktop의 32코어 머신에서 무거운 작업을 해도 사용률이 3분의 1까지 치솟는 일이 드물다. Codex가 하는 모든 것을 일일이 스캔하는 운영체제의 복잡성이 Linux에는 상대적으로 적기 때문이다.

2. 터미널이 충족하지 못한 목록

   1. 요구 조건: 최고의 Linux 지원, 좋은 모바일 지원, 좋은 성능, 낮은 배터리 소비, 다수 작업 관리가 모두 필요했다.
   2. 터미널의 유일한 강점: 터미널이 이 목록에서 제공하는 것은 최고의 Linux 지원뿐이다. 나머지 범주에는 직접적인 해답을 주지 못한다.

6.3. T3 Code의 탄생과 Julius의 역할

1. 실패한 네이티브 GUI 실험

   1. 공통 불만: Julius와 함께 Codex를 좋아하면서도 기존 선택지에는 불만이 많았다. 괜찮은 도구에는 피드백을 보내 일부 수정했지만 일부 문제는 남아 다시 답답해졌다.
   2. 성능 실험: 성능에 화가 나 직접 Codex용 네이티브 GUI를 만들었다. SwiftUI와 AppKit이 큰 스크롤 텍스트에 약해 스크롤 지옥에 빠졌고, Chrome을 만든 Google이 이 문제에 훨씬 더 많은 투자를 했다는 사실을 인정하며 프로젝트를 버렸다.

2. Electron과 WebSocket으로의 전환

   1. 재시작: 호기심으로 Electron에서 프로젝트를 다시 시작했다. 원격 제어를 쉽게 하려고 Electron RPC에 묶지 않고 모든 것을 WebSocket 위에 올리는 구조를 택했다.
   2. 초기 결과: 처음 T3 Code는 지금처럼 보이지 않았고 “죄스럽게 못생겼다”고 표현할 정도였지만, 시스템 성능을 덜 잡아먹는 오픈소스 GUI에서 Codex를 쓸 수 있었다.
   3. 초기의 선택: 처음 몇 달 동안에는 T3 Code보다 Codex 앱을 더 많이 썼다. 둘 사이를 오갔지만 대부분 Codex로 돌아갔다.

3. 터미널을 싫어하는 Julius

   1. 극단적인 편집기 중심 습관: Julius는 Git을 전부 VS Code 확장으로 처리하고, 터미널에서 Git 명령을 거의 쓰지 않는다. VS Code나 Cursor 안의 터미널은 개발 서버를 띄울 때만 열고 나머지는 편집기에서 처리한다.
   2. 서로 다른 동기: 터미널 우선인 사람에게 T3 Code는 문제 몇 가지를 해결할 오픈소스 수단이었지만, Julius에게는 터미널에서 탈출할 방법이었다. 최고의 개발자 중 터미널을 가장 싫어하는 사람이라는 평가를 받는 Julius가 해결에 집착했다.
   3. 품질의 도약: Julius는 worktree와 Claude Code를 안정적으로 통합했고, OpenCode와 Grok도 붙였다. Cursor 통합은 더 다듬을 부분이 있지만 큰 업데이트가 예정돼 있다. 여러 제공자의 모델을 각 구독의 보조금 가격으로 쓰되, 제공자마다 다른 터미널과 단축키를 외우지 않게 하려는 목적이었다.

6.4. 공식 지원과 통합 표면

1. 정식 SDK 사용

   1. 비공식 해킹 회피: T3 Code는 여러 머신에 설치된 Claude Code와 Codex를 사용하며 -p 같은 해킹을 쓰지 않는다. Anthropic이 승인한 공식 Agent SDK를 사용한다.
   2. 정책 변화: Anthropic이 정책을 바꾸려 했지만 당시에는 일시 보류된 상태였고, 무기한 보류될지는 기다려야 했다. 두 제공자의 공식 지원 범위 안에서 구독을 계속 쓸 수 있게 연구소들과 사용 방식을 협의했다.
   3. 상호 영향: Codex 팀이 T3 Code를 새로운 Codex 기능의 영감으로 공개적으로 언급할 정도로 기능적 영향도 생겼다.

2. 동일한 사용 표면

   1. 한곳에서의 일관성: Claude Code·Codex·OpenCode·Grok·Cursor를 하나의 화면에서 관리하고, 어떤 모델을 선택해도 작업 동작이 동일하게 느껴지도록 했다.
   2. 오픈소스 모바일: T3 Code는 다른 컴퓨터의 앱, 웹(app.t3.codes), iOS·Android 모바일 앱에서 같은 머신을 제어할 수 있다. 모바일 앱까지 완전한 오픈소스로 공개해 직접 빌드할 수 있다.

7. 원격 지속성이 바꾼 일과 생활

에이전트를 실행할 시간과 장소를 먼저 확보해야 했던 삶이, 작업을 원하는 머신에 보내고 잊어도 되는 삶으로 바뀐다.

7.1. 노트북을 닫아도 살아 있는 작업

1. 노트북 중심 일정의 문제

   1. 발열과 회의: 에이전트를 돌리면 노트북이 뜨거워지고 팬 소리가 커져 회의 중 마이크를 쓸 수 없었다. 다음 회의가 없을 때까지 작업 실행을 미루는 식으로 하루를 조정했다.
   2. Wi-Fi 의존성: 약속·여행·행사가 있거나 Wi-Fi를 잃으면 에이전트가 죽었기 때문에 장시간 작업을 시작할 수 없었다.

2. Uber 코딩의 역설

   1. 이동 시간을 코딩 시간으로 전환: 여러 행사에 이동해야 하는 날이 많아 Uber를 타면 앉아서 코드를 쓸 수 있다는 이유로 일부러 Uber를 선택했다. 사무실에서 밀린 일이 많아 Uber가 평온한 코딩 시간이 됐고, 그 이동 중 성능 개선과 변경을 기록한 글도 많았다.
   2. Claude Opus 4.5 사례: Claude Code와 Opus 4.5(자막상 “Opus 45”)를 쓰기 시작한 뒤 작업이 분 단위가 아니라 시간 단위로 길어졌다. Uber 안에서 작업하다 연결 불량으로 중단됐고, 도착해 노트북을 닫는 순간 에이전트가 죽어 나중에 다시 실행해야 했다.
   3. 생산성의 역전: 이후 “노트북을 열어 둘 시간이 충분한가”를 먼저 계산하며 하루를 구성하게 됐고, Uber에서 코딩하는 것조차 피하게 됐다.

7.2. T3 Code의 원격 흐름

1. 작업을 보내고 잊기

   1. 머신 선택: 작업을 실행할 컴퓨터를 고르고 프롬프트를 보낸 뒤 노트북을 닫는다. 코드베이스 심층 감사를 시킨 뒤 ⌘Q로 T3 Code를 완전히 종료해도 에이전트 작업은 계속된다.
   2. 어디서든 재개: 같은 앱을 다시 열거나, 머신에서 강제 종료한 뒤 app.t3.codes에 접속해 다른 컴퓨터의 같은 작업을 볼 수 있다. 프롬프트 추가, 상태 확인, 이미지 붙여넣기, history 스크롤, 필요할 때 터미널 열기까지 가능하다.
   3. 기술적 기반: 머신에서 T3 Code를 실행할 때 만들어지는 WebSocket 연결 위에서 이 흐름이 작동한다.

2. 연결 방법

   1. Tailscale 페어링: Tailscale 사용자라면 npx t3@nightly pair --tailscale로 페어링 코드를 받아 휴대폰으로 스캔하거나 웹에서 쓸 URL을 얻는다. t3@nightly serve로 서비스를 호스팅하면 전체 T3 Code 인스턴스를 제어할 수 있다.
   2. 간편 연결: 더 쉬운 방법으로 npx t3 connect를 실행하면 GitHub·Google 등으로 로그인할 URL이 열리고, 현재 머신에 백그라운드 인스턴스가 만들어진다. 당시 Linux에서 사용할 수 있고 Mac 지원은 곧 추가될 예정이라고 안내한다.
   3. 활용 예시: 집에 있는 오래된 노트북이나 자주 켜지 않는 PC, 이미 사용 중인 Linux 머신에 Linux와 Claude Code·Codex를 설치하고 명령 하나를 실행하면, SSH·터미널·연결 끊김의 결과를 감수하지 않고 다른 기기에서 에이전트를 관리할 수 있다.

8. 오픈소스 도구에 대한 장기적 주장

T3 Code의 동기는 단기 수익보다, 에이전트가 강력해지는 시대에 개발 도구의 통제권을 다시 사용자에게 돌려주는 데 있다.

8.1. 닫힌 개발 도구의 반복

1. 과거의 폐쇄 생태계와 전환

   1. 초기 환경: 코딩을 시작했을 때 Visual Studio와 Sublime Text 같은 편집기는 대부분 닫힌 소스였고 확장 기능도 제한적이었다.
   2. Atom과 VS Code: GitHub가 Electron 기반 Atom을 출시했고, Microsoft가 오픈소스 Electron 편집기인 VS Code로 대응했다. VS Code는 개발자의 80% 이상이 사용하는 업계 표준이 됐고, 도구를 직접 커스터마이즈할 수 있는 시대를 열었다.

2. AI 시대의 역행

   1. 다시 닫힌 선택지: AI가 커지자 사람들은 닫힌 소스 포크인 Cursor, 닫힌 소스 터미널인 Claude Code, 닫힌 소스 데스크톱 앱인 Codex로 이동했다.
   2. 아이러니: 소스 코드에 접근하면 도구를 어느 때보다 쉽게 커스터마이즈할 수 있는 시대인데, 실제 사용하는 도구는 오히려 닫혀 갔다.
   3. 사용자 통제권 상실: 도구가 무작위로 나빠져도 직접 고칠 수 없고, 필요한 기능을 추가할 수도 없었다. 에이전트가 코드를 수정할 수 있을 정도로 강력해진 시대에 개발자가 자신의 도구를 수정하지 못하는 상황이 특히 답답했다.

8.2. 돈보다 통제권을 택한 이유

1. T3 Code의 목표

   1. 반대 방향의 소프트웨어: 여러 서비스를 결합해 소프트웨어를 만드는 도구를, 다시 사용자와 커뮤니티가 고칠 수 있는 오픈소스로 만들고자 했다. 이 제품을 OpenAI나 Anthropic에 팔았다면 돈을 벌 수 있었지만, 그 선택은 목표와 달랐다고 말한다.
   2. 투자: 최고의 AI 코딩 오픈소스 해법을 만들기 위해 시간·돈·자원을 투입했다. 미래의 수익 가능성을 부정하지는 않지만 현재의 주된 동기는 수익이 아니다.

2. 터미널은 최종 해답이 아니라는 결론

   1. 그래픽 인터페이스: 실제 일을 완수하려는 사람을 우선하고 작업이 끝까지 도달하도록 돕는 시스템에는 GUI가 더 적합하다.
   2. 선택의 자유: 특정 GUI 하나를 강요하지 않는다. T3 Code·Codex, 성능 문제를 감수할 수 있다면 새 Cursor 버전, 직접 만든 도구, Gene·Conductor 같은 다른 GUI도 괜찮다. 핵심은 한두 개를 넘는 작업을 관리하는 GUI를 직접 써 보는 것이다.

9. 최종 결론: 터미널의 시대착오를 넘어

터미널은 버려야 할 유물이 아니라, 오늘의 에이전트 작업을 담기에는 형태가 고정돼 있는 훌륭한 과거의 도구다.

9.1. GUI가 제공하는 작은 차이의 누적

1. 작업 전환과 정리

   1. 시각적 매핑: 작업 사이를 빠르게 오가고, 단축키를 누른 채 어떤 스레드가 어떤 버튼에 대응하는지 확인하고, ⌘ 클릭으로 작업 간을 이동할 수 있다.
   2. 정리 동작: 우클릭으로 보관(archive)하거나 클릭으로 완료(settle)하는 작은 동작이 세션을 찾는 시간을 없앤다.
   3. 이미지와 원격의 결합: 이미지 사용이 자연스럽고 다른 컴퓨터의 작업이 지속되므로, 에이전트가 끝날 때까지 노트북과 SSH를 붙잡고 있을 필요가 없다.

2. 측정된 변화

   1. PR 처리량: 원격 지속성과 GUI가 갖춰진 뒤 주당 3~4개 PR을 머지하던 방식에서, 코딩을 많이 하는 날에는 하루 최대 20개 PR을 머지하는 수준으로 바뀌었다.
   2. 인과 관계: 모든 성과를 GUI 하나의 공으로 돌리지는 않지만, 터미널에서 실제 GUI로 이동한 일이 그 전환의 중요한 부분이었다고 판단한다.

9.2. 스큐어모피즘 비유와 도전

1. 익숙한 모양에 묶인 인터페이스

   1. iPhone의 스큐어모피즘(skeuomorphism): 초기 iPhone은 사용자가 달력을 알아보도록 실제 달력처럼 보이는 앱을 만들었다. 생소한 디지털 기능을 받아들이게 하려면 익숙한 물건의 모양이 필요했기 때문이다.
   2. AI 개발 도구의 현재: AI 개발 도구도 아직 터미널이라는 익숙한 형태를 유지한다. 한꺼번에 너무 많은 변화가 오면 사용자가 받아들이기 어렵기 때문이다.

2. 터미널 마법사의 다음 과제

   1. 재정의: 터미널의 마법사였던 개발자는 에이전트의 마법사가 될 사람과 같다. 하지만 현재의 작업 구조에 터미널이 이상적인 인터페이스라고 계속 가장할 필요는 없다.
   2. 실험 권유: 터미널이 자신을 방해하지 않는 유일한 경우는 충분히 큰 것을 만들고 있지 않을 때일 수 있다고 도발한다. 여러 GUI를 직접 시도하면 예상보다 큰 차이를 느낄 가능성이 높다고 권한다.
   3. 애정과 결별의 공존: 터미널을 사랑하고 예전만큼 쓰지 못해 아쉬워하지만, 오늘날 우리가 만드는 것의 형태에는 더 이상 맞지 않는다. 결론은 “터미널을 싫어하라”가 아니라 “터미널이 유일한 기본 인터페이스라는 믿음에 도전하라”이다.

주요 발언 모음

“나는 13살부터 삶의 대부분을 터미널 안에서 보냈지만, 이제는 터미널에서 일하지 않는다.”

“터미널은 예전에는 정신적 오버헤드가 적고 초기 설정 비용이 조금 있는 선택지였지만, 오늘의 작업에는 내가 만든 시스템의 경직성이 맞지 않았다.”

“SSH는 매우 유용하고 강력하지만, 연결이 완벽하지 않은 순간 모든 종류의 문제가 생긴다.”

“작업을 실행할 컴퓨터를 고르고 프롬프트를 보낸 뒤 노트북을 닫을 수 있다는 점이 내가 일하는 방식을 근본적으로 바꿨다.”

“나는 터미널을 사랑하지만, 터미널은 우리가 오늘 만드는 것의 형태에 맞는 인터페이스가 아니다.”

“터미널의 마법사였던 개발자는 에이전트의 마법사가 되어야 한다.”

핵심 데이터 & 수치

• 13살 이후: 대부분의 실행·작업·감사·일상 업무를 터미널에서 처리했다.
• 8시간 이상: 재부팅 후 터미널을 열지 않고도 작업을 이어 간 시간이다.
• 약 30개: 한 Linux 머신의 tmux에 띄워 둔 Claude Code·Codex 관련 터미널 세션 수다.
• 2초 대 30초~2분: Linux에서 worktree를 만드는 시간과 다른 환경에서 걸리는 시간의 비교다.
• 32코어: Framework Desktop의 Ryzen AI Max 머신이 가진 코어 수다.
• 4배: Blacksmith가 강조한 캐시 다운로드 속도다.
• 80% 이상: VS Code를 사용하는 개발자의 비율로 제시됐다.
• 주 3~4개 대 하루 최대 20개: GUI와 원격 지속성을 적용하기 전후의 PR 처리량 변화다.
• 5개 이상: macOS Codex 구현에서 스레드·하위 에이전트마다 생성될 수 있다고 언급한 프로세스 수다.
• 8천~1만4천 달러 대 200달러: 여러 구독의 모델 사용 가치를 구독 보조금으로 얻는다는 과장 섞인 비교다.
• Wi-Fi 7·기가비트~10Gbps: SSH 입력 지연 사례가 발생한 네트워크 환경이다.

결론 및 시사점

1. 터미널은 명령 실행과 Linux 환경에서 여전히 뛰어나지만, 여러 에이전트·워크트리·이미지·기기를 동시에 다루는 작업의 기본 화면으로는 상태 추적 비용이 커진다.
2. GUI의 핵심 가치는 예쁜 화면이 아니라 프로젝트·스레드·워크트리·기기·세션의 관계를 보이고 클릭·검색·보관으로 관리하게 하는 데 있다.
3. 에이전트는 노트북이 아니라 별도의 Linux 머신에서 실행하고, 웹·데스크톱·모바일에서 원격 제어하면 발열·회의·이동·Wi-Fi 단절이 작업을 중단시키지 않는다.
4. 모델 제공자별 공식 harness를 유지하면서 한 GUI에서 관리하면 좋은 모델·좋은 가격·최신 기능을 동시에 얻는 선택지가 넓어진다.
5. T3 Code의 오픈소스 전략은 AI가 코드를 수정하는 시대에 개발자도 자신의 개발 도구를 수정할 수 있어야 한다는 통제권의 주장이다.
6. 특정 제품보다 GUI라는 작업 형태를 직접 시험해 보고, 터미널을 유일한 정답으로 취급하는 습관이 현재의 병렬 개발 규모를 제한하는지 확인해야 한다.