Claude 구독이 있다면 꼭 보라: 에이전트 토큰을 끝까지 활용하는 법

URL: https://www.youtube.com/watch?v=D8PikZ1KhUo 날짜: 2026-10-02 채널: t3dotgg (Theo - t3․gg) 원문 제목: If you have a Claude sub, watch this

---

📌 핵심 질문 / 에이전트 시대에 구독 토큰을 어떻게 일과 생산성으로 바꿀 것인가

==구독형 AI의 보조금(subsidy)을 단순한 채팅 사용량이 아니라, 여러 에이전트가 문제 발견부터 구현·검증·배포까지 맡는 병렬 개발 시스템으로 바꿔야 한다.==

• API는 넣은 돈과 거의 같은 액수의 토큰을 주지만, Claude·Codex의 상위 구독은 월 구독료보다 훨씬 큰 추론량을 제공한다.
• 값싼 계정 여러 개를 무작정 늘리는 것보다, 거주지 IP를 중심으로 인증·라우팅·세션 친화도(session affinity)를 관리하는 인프라가 중요하다.
• 사람은 한 번에 한 가지에 집중하는 단일 스레드이고 에이전트는 여러 작업을 병렬로 처리하므로, 사람의 역할은 각 작업을 감시하는 것이 아니라 도움이 필요한 순간에만 판단하는 병목으로 바뀐다.

Theo가 말하는 핵심은 특정 도구나 설정을 그대로 복사하라는 뜻이 아니다. 문제를 발견했을 때부터 에이전트를 투입하고, 검증·리뷰·실행·정리까지 맡겨 사람이 다음 문제로 이동하는 사고방식을 익히라는 뜻이다. 토큰이 남는 것을 아까워하며 프롬프트를 줄이는 대신, 생각해야 할 문제인지조차 에이전트에게 먼저 확인하고, 사람이 직접 풀어야 하는 어려운 문제에만 집중해야 한다.

1. 출발점: 에이전트를 몇 개나 동시에 돌리고 있는가

지금 이 글을 읽는 순간 백그라운드에서 실행 중인 에이전트 스레드(agent thread)가 다섯 개보다 적다면 병렬 에이전트의 기회를 충분히 활용하지 못하고 있을 가능성이 크다. 다섯 개보다 많더라도 작업을 관리하고 우선순위를 정하는 방법을 얻을 수 있다.

1.1. 토큰 맥시밍(token-maxing)의 목적

1. 사용량 자체가 목표는 아니다

   1. 구독 한도를 다 태우는 행동은 넷플릭스 영화를 무제한으로 보는 것과 다르다. 토큰은 실제 제품·코드·조사·검증에 쓰여야 하며, 단순히 소모하는 행위는 가치가 없다.
   2. 사용하지 않은 한도는 주기적으로 사라지므로, 남은 추론량을 유용한 자동화와 실험으로 바꾸는 방법을 찾아야 한다.

2. 구체적인 공식보다 사고방식이 중요하다

   1. 100개가 넘는 PR을 하루에 처리하는 운영 방식은 그대로 복제할 레시피가 아니라, 에이전트를 어떻게 배치하고 어떤 결정을 넘길지 보여 주는 사례다.
   2. 최선의 결과는 다른 사람이 자신의 문제를 더 잘 풀 수 있는 새로운 조합을 만들고, 다시 더 나은 운영법을 공유하는 것이다.

1.2. “사이드 프로젝트에서만 된다”는 반론에 대한 답

1. 규모가 커져도 적용된다

   1. 전략은 작은 프로젝트와 큰 프로젝트 모두에서 작동한다. AWS 규모로 확장되는 회사와 Microsoft, 일부 Fortune 500 기업에서도 직원들이 개인형 구독을 사용하며 비슷한 교훈을 얻고 있다고 말한다.
   2. 다만 고객의 공개 요청을 개인 구독 추론으로 처리하는 것은 구독의 사용 목적이 아니다. 내부 코드, 이슈, PR, 데이터가 허용된 범위에서 개발하는 것과 외부 사용자를 위한 서비스 API를 운영하는 것은 구분해야 한다.

2. 비싸다는 반론에도 경제적 이점이 있다

   1. 수십만 달러를 쓴다는 인상을 주는 숫자도 실제로는 약 5만 토큰을 얻는 데 최악의 경우 1,000달러를 넣는 식의 계산이라고 설명한다.
   2. API 가격을 이미 지불하고 있다면, 같은 추론을 훨씬 비싸게 사는 셈이 될 수 있다. 그러나 개발자가 감당할 수 없는 금액을 무리하게 구독하라는 뜻은 아니며, 수익이 생기기 전에는 구독을 쌓지 말라는 단서도 붙인다.

3. 후원 검색 도구 Parallel이 보여 주는 보조 사례

   1. 검색 없는 에이전트는 최신 정보를 얻지 못해 실용성이 크게 떨어지며, 빠르고 정확한 검색이 에이전트 활용의 전제다.
   2. Parallel의 실시간 검색 시연은 1초 남짓 걸렸고, 비교 대상 OpenAI 엔드포인트는 6초 넘게 계속 실행됐다.
   3. Parallel은 검색 외에도 페이지 변경을 알리는 모니터, 검색 결과를 합성하는 response API, URL에서 필요한 데이터를 뽑는 extract 엔드포인트, JavaScript-heavy 페이지 파싱, MCP 연동을 제공한다고 소개된다.
   4. 월 5,000회 요청이 무료이고 가입 시 80달러 크레딧을 제공하며, 안내 주소는 https://soydev.link/parallel 이다.

2. 구독 토큰의 경제학

2.1. API보다 구독이 유리하다는 계산

1. API는 입력 금액만큼만 돌려준다

   1. Cloud API에 200달러를 넣으면 약 200달러어치 토큰을 받고, Codex API도 같은 구조다.
   2. 따라서 구독형 서비스가 제공하는 사용량 제한과 API 사용량을 같은 단위로 비교해야 한다. 사용자 트래픽을 처리하는 제품에는 API를 써야 하지만, 개인 개발 작업에는 계산이 달라진다.

2. Claude 상위 구독의 추론량

   1. 월 200달러 Claude 구독은 약 8,000달러어치 토큰에 해당하는 추론량을 제공한다고 설명한다.
   2. 주력 모델인 Fable로 사용할 수 있는 몫에는 50% 제한이 있어 약 4,000달러어치만 해당 모델에 쓸 수 있지만, 200달러를 넣고 4,000달러의 추론을 얻는 것만으로도 큰 보조금이다.
   3. 100달러 요금제는 총량이 절반인 대신 5시간 제한이 4분의 1 수준으로 더 엄격해 실제로 한도를 태우기 어렵다. 그래서 100달러 요금제보다 200달러 요금제를 선택하고, 그 사용량으로 돈을 벌거나 비용을 절감한 뒤 다시 투자하는 방식을 권한다.

3. Codex 상위 구독의 추론량

   1. 월 200달러 Codex 구독은 약 12,000달러어치 추론량으로 계산되며, Astra와 더 저렴한 모델인 Soul 사이에 별도 몫을 나누지 않고 토큰을 제공한다고 설명한다.
   2. Codex의 주간 한도는 약 4,000달러 규모로 보이지만, 30일에 14회 정도 리셋을 받은 사례를 기준으로 하면 2~3일마다 한 번씩 추가 리셋이 발생한다.
   3. 한도를 적극적으로 태우면 200달러 구독을 24,000달러 규모로 볼 수도 있다. 수요가 급증해 200달러 신규 구독이 일시 중단된 사례도 언급한다.

2.2. 공개 API 가격과 내부 원가의 간극

1. 상위 모델 가격 차이

   1. Fable은 공개 가격이 입력 100만 토큰당 10달러, 출력 100만 토큰당 50달러라고 설명한다.
   2. Anthropic이 기업용 내부 프로젝트인 Glass Wing에서 비슷한 모델을 계속 사용하게 할 때 제시한 가격은 입력 25달러, 출력 125달러였다고 말한다.
   3. 공개 구독 가격은 내부 기업용 가격보다 거의 70% 낮고, 구독에서 토큰을 얻는 비율까지 곱하면 API 가격 대비 매우 큰 할인이 된다.

2. 마진과 가격 전략

   1. 전력·컴퓨트 교체 비용을 감안한 토큰 사업의 이익률을 약 95%로 추산하는 업계 지인들의 계산을 소개한다. 100달러를 받으면 95달러가 남고 5달러가 전기와 고장 난 컴퓨트 교체에 들어가는 식의 단순화된 계산이다.
   2. Anthropic은 경쟁사보다 앞선 위치를 유지하고 경쟁 모델로 옮길 이유를 줄이기 위해 마진 일부를 포기하고 가격을 낮췄다는 해석을 제시한다.
   3. OpenAI는 가격을 그대로 두거나 20~80% 낮추거나 두 배로 올리는 식으로 움직이는 경향이 있고, Astra의 가격이 낮은 이유도 Fable이 시장 가격을 끌어내렸기 때문이라고 설명한다. 이 부분은 발표자의 시장 해석이며 공식 가격 정책의 보장은 아니다.

2.3. 데이터 설정과 사용 경계

1. 개인 구독의 데이터 제어

   1. Codex 설정에서 Settings → Data Controls → Improve the model for everyone을 끄면 개인 구독의 데이터 사용 조건이 팀 계정과 사실상 비슷해진다고 설명한다.
   2. 학습에 사용되지 않을까 걱정해 API 가격을 내는 것이라면, 설정을 확인하지 않은 채 API를 쓰는 것은 비용의 80~90%를 버리는 행동일 수 있다.
   3. Claude Code에도 비슷한 데이터 공유 설정이 있으므로, 계정을 구성할 때 먼저 확인해야 한다.

2. 허용되는 개발과 금지해야 할 운영을 분리한다

   1. GitHub 이슈, 코드베이스, 내부 프롬프트, 허용된 사내 작업을 에이전트에 맡기는 것은 구독의 취지에 맞는다.
   2. 공개 사용자가 요청을 보내면 개인 구독 추론이 실행되는 서비스를 만드는 것은 약관 위반에 해당할 수 있으며, 적발과 정지 위험을 감수할 이유가 없다.
   3. 구독 보조금은 사용자 트래픽을 되팔아 마진을 남기라고 제공되는 것이 아니다. 내부 개발을 빠르게 하고 더 좋은 제품을 만드는 데 사용해야 한다.

3. 여러 계정의 토큰을 안전하게 연결하기

3.1. 계정·IP·약관 위험

1. 정지는 현실적인 위험이다

   1. 30개가 넘는 계정을 여러 사람이 오가며 사용하는 사례에서, VPN으로 가입하고 본인 소유가 아닌 사업체의 카드로 결제한 사람의 계정 두 개가 일시 정지됐다가 거의 즉시 복구된 경험을 소개한다.
   2. 이런 방식이 회사가 원하는 사용법은 아니며 약관에 어긋날 수 있다. 소개된 설정은 개인 경험일 뿐이며, 계정 정지를 보장하거나 책임지지 않는다는 경고가 반복된다.

2. 서버 IP가 특히 위험하다

   1. AWS, Hetzner 등 클라우드 사업자 IP는 서버로 알려져 있어 Claude Code 구독을 재판매하거나 다른 사람에게 트래픽을 제공하는 행동으로 오해받기 쉽다.
   2. VPS나 VPN에서 직접 로그인하지 말고, 여러 컴퓨터가 서로 다른 IP에서 동시에 같은 계정을 쓰지 않는 편이 정지 가능성을 낮춘다.
   3. Google 계정은 정지되면 복구 비용이 크므로 같은 실험을 Google 계정으로 하지 말라는 농담 섞인 경고도 덧붙인다.

3.2. CLI Proxy와 단일 거주지 IP

1. 프록시의 역할

   1. CLI Proxy에 Claude와 Codex의 OAuth를 한 번씩 로그인하면 프록시가 인증 상태를 유지하고, Claude Code나 Codex가 전통적인 OAuth 서버 대신 프록시 엔드포인트를 바라보도록 만들 수 있다.
   2. 여러 계정의 요청을 프록시가 라우팅하므로, 각 장치에서 계정을 수동으로 바꾸는 방식보다 확장성이 높다.
   3. 프록시는 가정의 단일 거주지 IP에서 실행하고, 다른 장치의 작업은 그 엔드포인트를 통해 보내는 구성을 권한다. 이것은 약관과 계정 정지를 피한다는 보장이 아니라, 서버 트래픽처럼 보이는 흔적을 줄이려는 운영상의 조언이다.

2. 다른 프록시·구독과의 비교

   1. Cursor, OpenCode, T3 Chat의 구독도 보조금을 제공하지만, Cursor가 Anthropic과 30~50% 수준의 거래를 한다고 해도 95~98% 할인에 가까운 Claude·Codex 구독과는 비교하기 어렵다.
   2. Grok 4.7이 좋은 모델로 나오더라도 긴 작업에서 일관성을 유지하지 못하면 토큰을 끝까지 태우기 어렵다고 본다.

3.3. CLI Proxy의 라우팅과 캐시

1. 리셋이 가까운 계정을 먼저 태운다

   1. 기본 CLI Proxy는 계정 전체에 요청을 균등 분배하지만, 어떤 계정은 다음날 오후에 리셋되고 다른 계정은 4일 뒤에 리셋된다면 곧 사라질 한도를 먼저 쓰는 편이 합리적이다.
   2. 계정별 5시간 한도에 계속 부딪히는 경우에는 속도를 낮춰야 한다. 발표자는 5시간 한도가 7일 Fable 한도의 약 40%에 해당한다고 계산하지만, 화면의 다른 Opus 버킷은 제외해야 한다고 강조한다.

2. 모델별 버킷을 구분한다

   1. Opus 버킷은 당시 사용성 때문에 사실상 피하고 싶은 영역으로 설명되며, Fable 7일 한도가 핵심 관리 대상이다.
   2. 후일 추가된 Opus 5.5는 Fable 5.1과 비슷하게 안정적이고 한 계정에서 한도에 도달하기 어려울 수 있으므로, 예전처럼 Claude 구독 5~10개나 프록시가 필요하지 않을 수도 있다.
   3. Opus 5.5가 추가된 뒤에도 계정 우선순위, 세션 유지, 병렬화라는 원칙은 그대로 적용된다.

3. WebSocket과 affinity

   1. Codex 구독 트래픽이 기본적으로 WebSocket을 사용하지 않으면 요청과 응답을 주고받는 시간이 크게 늘어날 수 있으므로 WebSocket 설정을 활성화해야 한다.
   2. 하나의 스레드에 다음 프롬프트를 보낼 때 같은 계정을 계속 사용하도록 session affinity와 account affinity를 유지해야 한다.
   3. 80만 토큰까지 쌓은 스레드가 다른 계정으로 바뀌면 API가 캐시 엔티티를 다시 만들어야 한다. 계정 전환마다 한 번이면 괜찮지만, 프롬프트나 도구 호출마다 바뀌면 불필요한 캐시 읽기·쓰기가 폭증한다.
   4. CLI Proxy의 affinity는 기본적으로 잘 작동하고 캐시는 약 5분간 유지된다. 사용량 대시보드에서 캐시 읽기·쓰기 비율이 비정상적으로 커지지 않는지 확인하고, 에이전트에게 라우팅 방식을 직접 설명하게 할 수도 있다.

3.4. Tailscale과 fleet 관리

1. 가정 네트워크를 작업의 중심으로 둔다

   1. Tailscale로 프록시 호스트와 다른 컴퓨터를 연결하면, API 키 없이도 Tailscale 네트워크 안에서만 엔드포인트를 노출할 수 있다.
   2. 외부 인터넷에 공개하지 않고, 자신의 Tailscale 계정에 들어온 장치만 접근하게 하면 별도의 인증 키가 없어도 위험 범위를 제한할 수 있다.

2. fleet management 저장소를 자동화의 기준으로 삼는다

   1. 저장소에는 새 컴퓨터에 필요한 ripgrep, fd, jq, tmux, top, Node, Python, 빌드 도구, Claude Code, Codex, 프록시, Tailscale 설정이 기록돼 있다.
   2. 새 장치를 받으면 SSH를 설정하고, 에이전트에게 SSH 키와 저장소를 건네 “내 방식대로 새 박스를 설정하라”고 요청한다.
   3. 에이전트가 Tailscale 승인 페이지를 띄우면 승인한 뒤, 새 장치가 집의 프록시를 통해 추론을 사용할 수 있게 한다.
   4. 실제 구성에서는 집의 한 머신이 거주지 IP에서 Claude 계정 다섯 개와 Codex 계정 네 개의 요청을 받고, 세계 각지의 작업 머신이 Tailscale로 연결된다.

3. 서비스별 사용 범위를 지킨다

   1. Claude Code와 Codex는 Bedrock처럼 외부 API 엔드포인트를 지정해야 하는 기업용 환경이 많기 때문에 프록시 URL을 설정할 수 있다.
   2. 일반 OAuth 설치를 유지하고 싶으면 별도의 home directory를 가진 두 번째 인스턴스를 만들어 프록시 설정과 일반 설정을 나눌 수 있다.
   3. Claude 구독의 Claude 모델은 Claude Code 안에서만 사용해야 한다. 다른 앱이나 사용자 트래픽으로 모델을 노출하면 정지 가능성이 매우 높다.

3.5. Claude와 Codex의 리셋 차이

1. Codex 리셋

   1. Codex 리셋은 주간 한도 전체를 다시 7일 뒤로 밀어 버린다. 원래 10분 뒤 만료될 한도라도 리셋을 누르면 새 주기가 시작된다.
   2. 즉시 리셋과 banked reset이 있으며, banked reset은 사용자가 원하는 때에 누를 수 있다.
   3. 금요일 밤이나 토요일처럼 기업 사용량이 적은 시간에 리셋을 제공하면 유휴 컴퓨트를 활용할 수 있다. 화요일 아침에는 API 가격을 내는 기업 사용량과 경쟁하므로 같은 혜택을 제공하기 어렵다.

2. Claude 리셋

   1. Claude 리셋은 날짜와 시간을 옮기지 않고 한도 퍼센트만 100%로 만든다.
   2. 실제 리셋 날짜가 하루 뒤라면, 지금 받은 리셋으로 채워진 토큰도 하루 뒤에 사라진다. 따라서 리셋 직후 바로 추론량을 태워야 한다.
   3. 월 200달러를 내고 4,000달러어치 혜택을 받는다고 생각하지 말고, 매주 4,000달러가 선물되며 쓰지 않은 분량은 영원히 사라진다고 생각해야 한다.

3. 한도 관리의 심리

   1. API 사용자는 적은 토큰으로 많은 결과를 얻으려 하지만, 보조금 구독 사용자는 리셋 전 남은 한도를 쓰지 않으면 손실이 발생한다.
   2. 한도를 태우기 위해 무의미한 일감을 만들라는 뜻은 아니다. PR 정리, 문서화, 테스트, 오래된 아이디어 조사처럼 실제 가치를 얻는 작업을 미리 쌓아 두어야 한다.

4. 토큰을 잘 쓰는 법: 사람이 감시자가 아니라 병목이 되지 않도록

4.1. “더 많은 토큰으로 덜 신경 쓰기”

1. 컴퓨터 앞에 머무는 시간을 줄인다

   1. 손 수술 이후 타이핑을 줄여야 했던 경험 때문에, 음성 입력뿐 아니라 앱 전환과 생성 화면을 계속 바라보는 습관까지 줄이는 전략을 실험했다.
   2. 핵심 질문은 “더 많은 토큰을 써서 이 작업을 얼마나 덜 신경 쓸 수 있는가”다. 문제를 발견한 즉시 에이전트를 부르고, 다음 확인까지 오래 실행하도록 만든다.

2. Merge 전후의 위험을 동시에 줄인다

   1. Merge 버튼을 누를 때 코드가 안전할 가능성을 높이려면 테스트, 코드 리뷰, 타입 검사, 실행 환경, 회귀 검증을 에이전트에게 맡겨야 한다.
   2. Merge 뒤에 문제가 생겨도 자동 탐지와 빠른 되돌리기가 가능해야 한다. 잘못된 변경을 되돌리는 데 15초 이상 걸린다면 병렬 바이브 코딩보다 먼저 시스템을 고쳐야 한다.
   3. 전체 토큰 사용량에서 실제 코드 작성은 약 10~15%이고, 80~90%는 코드 검증에 쓴다는 체감치를 제시한다. PR이 5% 확률로 나쁜 상태에서 1%로 줄어들면 각 PR을 직접 붙잡는 시간이 크게 줄어든다.

4.2. 해답이 아니라 문제를 먼저 건넨다

1. 생각이 끝난 뒤가 아니라 생각이 시작될 때 부른다

   1. 몇 주 동안 문제를 꽤 적극적으로 생각한 뒤 에이전트에게 “내가 놓친 단순한 해법이 있는가”라고 물었더니, 몇 주를 절약할 수 있는 간단한 해법을 제시한 사례가 있다.
   2. 반대로 아주 쉬워 보이는 문제가 에이전트에게 계속 실패하면, 그 문제는 실제로 새롭거나 어려운 것이므로 사람이 깊이 생각해야 할 신호다.

2. 구체적인 해결책을 강요하지 않는다

   1. T3 Code의 버그 제보를 받았을 때 예전에는 원인을 추정해 “이 파일을 이렇게 바꿔라”라고 지시했지만, 결과가 원하는 문제를 해결하지 못하는 일이 있었다.
   2. 이제는 스크린샷과 증상을 건네고 “고쳐라”라고 한다. 성공하면 생각할 시간을 줄이고, 실패하면 사람이 개입해야 할 문제인지 빠르게 알 수 있다.

3. 관리자처럼 문제를 배분한다

   1. 팀원에게 해답을 미리 주는 대신 흥미로운 문제를 주고 결과를 보듯, 에이전트에도 문제를 건네고 첫 결과가 어긋날 때만 방향을 잡는다.
   2. 이는 생각을 멈추라는 뜻이 아니다. 에이전트가 풀 수 있는 문제에 사고 에너지를 쓰지 말고, 에이전트가 풀지 못하는 문제와 그 해결 결과를 읽는 데 사고를 집중하라는 뜻이다.
   3. “생각을 외주화하지 말고 생각을 확장하라”가 핵심이다. 에이전트가 무엇을 먼저 해결할 수 있는지 판단하게 하여, 사람이 더 중요한 문제를 생각하도록 만든다.

4.3. 문제 발견부터 PR Merge까지 한 흐름으로 맡긴다

1. 작업의 전체 경로

   1. 사용자의 문제나 버그를 발견한다.
   2. 에이전트에게 증상·맥락·제약을 주고 해결책을 스스로 탐색하게 한다.
   3. 구현, 테스트, PR 생성, 환경 배포, AI 리뷰 요청, 리뷰 반영까지 계속 실행하게 한다.
   4. 조건이 충족되면 PR을 Merge하고, 실패하면 원인을 기록하고 다시 수정하도록 지시한다.

2. 사람이 기다리지 않는 운영

   1. 에이전트가 30분 동안 구현·테스트하고, 15분 동안 리뷰를 기다리고, 10분 동안 수정한 뒤 재리뷰를 받으면 한 작업이 한 시간 넘게 걸릴 수 있다.
   2. 그 시간에 사람은 다른 스레드에 프롬프트를 보내고, 사용자를 만나고, 다음 문제를 수집한다.
   3. 에이전트가 PR을 스스로 Merge해도 되는 조건을 명시하면 사람이 최종 메시지를 읽지 않아도 되며, 실제로 절반 정도의 스레드는 마지막 메시지를 보기 전에 아카이브할 수 있다고 말한다.

5. T3 Code로 병렬 스레드를 관리하는 법

5.1. 스레드는 대화 기록이 아니라 할 일이다

1. 상태로 우선순위를 관리한다

   1. 여러 스레드를 과거 대화 목록으로 보면 모두 다시 읽어야 하지만, 스레드를 작업·할 일(todo)로 보면 현재 상태만 보면 된다.
   2. 실행 중인 스레드는 내 문제가 아니며, Done 또는 Input 상태가 되어야 확인한다.
   3. 작업이 끝나면 settle을 눌러 사이드바에서 없앤다. 목표는 하루를 끝낼 때 모든 스레드가 실행 중이거나 사라져 있고, 아침에 확인할 완료 작업만 남는 inbox zero다.

2. 집중할 대상을 UI가 알려 주게 한다

   1. 실행 중인 스레드를 반투명하게 표시하면 시선이 필요한 작업과 그렇지 않은 작업을 구분하기 쉽다.
   2. 기본 자동 settle은 3일간 손대지 않은 스레드이며, 발표자는 자신의 습관에 맞춰 7일로 늘렸다.
   3. 나중에 볼 작업은 snooze로 미루고, 가치가 없어진 작업은 settle이나 archive로 닫는다. ADHD 성향이 있다면 “스레드를 띄웠으니 이제 내 문제가 아니다”라는 전환이 오히려 장점이 될 수 있다.

5.2. 여러 머신과 백그라운드 실행

1. 실행 머신을 작업마다 고른다

   1. 같은 저장소 origin을 쓰는 컴퓨터는 T3 Code 안에서 묶여 보이며, Linux 박스·Mac·클라우드 서버 중 원하는 위치를 선택할 수 있다.
   2. 일반 개발은 Linux 서버에 보내고, 모바일·컴퓨터 사용(computer use)이 필요하면 Mac을 선택한다.
   3. 컴퓨터를 닫아야 하는 작업은 현재 MacBook에 두지 않고, 계속 켜 둔 서버에 보낸다.

2. 프롬프트를 백그라운드로 보낸다

   1. Command+Enter를 누르면 스레드가 백그라운드로 시작되고 현재 위치를 유지한다.
   2. 다음 문제를 발견하면 즉시 새 스레드에 던지고, Done 또는 Input 알림이 올 때까지 열어 보지 않는다.
   3. 연결된 여러 서버에 자동 load balancing을 설정하면 어떤 머신에 보낼지 직접 고르지 않아도 작업이 분산된다.

3. 사람은 멀티스레드가 아니다

   1. 에이전트는 여러 스레드를 병렬로 실행하지만 사람은 두 가지에 동시에 집중할 수 없다.
   2. 따라서 사람의 일이 에이전트를 계속 깨우는 것이 되면 병목이 된다. 에이전트가 스스로 막힘을 해소하고 필요한 때에만 사람을 부르도록 맥락과 도구를 충분히 제공해야 한다.

5.3. 문제를 설명하고 대안을 열어 둔다

1. 연결 장치 UI 개선 사례

   1. T3 Connect 설정 화면에서 update와 disconnect만 있고 remove가 없으며, disconnect가 일시적인지 영구적인지 명확하지 않은 문제를 스크린샷으로 전달한다.
   2. 에이전트가 확신하면 직접 수정하고 스크린샷을 보내게 하고, 확신하지 못하면 HTML skill로 몇 가지 목업을 만들어 선택하게 한다.
   3. 문제와 원하는 사용자 경험은 설명하되 해법을 고정하지 않으면, 에이전트가 직접 구현하거나 의사결정을 위한 목업을 만드는 두 경로를 모두 활용할 수 있다.

2. 대략적인 타당성 확인부터 시작한다

   1. 스트리밍 UI를 문단 단위로 나누는 기능을 바로 만들지 않고 먼저 “얼마나 어려운가”를 물었다.
   2. 에이전트가 어렵지 않다고 답하면 구현, PR, Tailscale 환경 배포, 사용자를 위한 확인, PR 감시까지 한 번에 요청한다.
   3. “작업해 줘”만 말하면 배포나 PR 후속을 다시 지시해야 하므로, 다음 확인 시점에 Merge할 수 있도록 필요한 환경과 검증 조건을 처음부터 넣는다.

5.4. Worktree·리뷰·감시

1. 동시 작업의 충돌을 자동으로 다룬다

   1. T3 Code의 새 스레드는 기본적으로 새 Git worktree에서 시작하므로 에이전트끼리 파일을 덮어쓰는 위험을 줄인다.
   2. 같은 머신에서 같은 브랜치를 두 worktree가 사용하면 Git이 충돌할 수 있지만, 최신 모델은 새 브랜치, 별도 clone, 다른 checkout 같은 우회 방법을 찾는다.
   3. 같은 PR을 다른 모델에게 리뷰하게 해도 브랜치가 이미 다른 worktree에 있다는 사실을 처리할 수 있으므로, 사람이 Git 내부 문제를 미리 해결하려고 시간을 쓰지 않아도 된다.

2. 작업 중인 에이전트를 바라보지 않는다

   1. 성공하면 Merge하고, 실패하면 trace를 읽거나 에이전트에게 실패 이유를 물으면 된다.
   2. 생성 중인 화면을 계속 바라보는 것은 최악의 시간 사용 중 하나다. 작업을 시작한 뒤 다음 문제를 처리하고, 상태가 바뀔 때만 돌아온다.

6. 토큰을 “나쁘게” 쓰는 법: 질문과 정리를 에이전트에게 넘기기

6.1. 사람이 할 수 있지만 귀찮은 조사

1. 코드와 PR을 읽게 한다

   1. 이해하기 어려운 팀원의 PR은 변경 내용을 요약하고 위험한 부분을 찾아 달라고 한다.
   2. 오래된 PR 목록을 전부 훑어 오늘 집중할 가치가 있는 작업과 Merge를 놓친 작업을 찾아 달라고 한다.
   3. 다른 사람이 Orchestrator V2를 작업 중인데 바쁠 때는 직접 묻지 않고, 에이전트가 저장소의 변경 사항을 조사하게 한다.

2. 개인 정보와 문서도 정리한다

   1. 다섯 개 이메일 수신함에서 특정 메일을 찾는 일은 에이전트에게 키워드와 맥락을 주고 검색하게 한다.
   2. 수술 관련 의료 기록을 직접 다운로드하지 않고, 브라우저의 의료 대시보드와 이메일을 순회해 필요한 기록을 모으게 한다.
   3. 이처럼 30분 이상 걸리는 수집 작업을 실행하는 동안 T3 Code에서 네 개의 개발 스레드를 추가로 시작한다.

3. 에이전트에게 어리석은 질문도 한다

   1. “열쇠를 어디에 두었는지 찾아라”처럼 에이전트가 알 수 없을 질문을 던져 보는 것이 기준점이다.
   2. 질문이 너무 당연하거나 어리석어 보여도, 에이전트에게 물어볼 수 있는 범위를 넓히면 검색·분류·기억 부담을 줄일 수 있다.

6.2. 남은 한도를 실제 탐색에 쓴다

1. 잊힌 프로젝트를 재발견한다

   1. GitHub의 모든 프로젝트와 현재 머신의 미완성 작업을 여러 subagent로 조사하게 한다.
   2. 수요가 다시 커졌거나, 오래 버려졌지만 부활할 가치가 있는 아이디어를 찾고 우선순위를 제안하게 한다.
   3. 이런 요청은 당장 사업적으로 중요하지 않을 수 있지만, 리셋 전에 남은 사용량을 의미 있게 쓰고 자신이 잊은 작업을 발견하는 데 도움이 된다.

2. 결과를 다시 인간의 큐에 넣는다

   1. 이미 무엇을 할지 결정한 프로젝트는 다시 띄우지 않고 settle한다.
   2. 진행 중인 작업은 현재 상태, Tailscale 개발 서버가 살아 있는지, PR을 만들고 계속 감시할 수 있는지를 묻는다.
   3. 오래된 PR은 “지금 어디까지 왔고 왜 Merge해야 하는가”를 물어 의사결정에 필요한 요약만 받은 뒤 Merge·추가 지시·폐기 중 하나를 고른다.

3. 하루의 작업을 이메일 받은편지함처럼 처리한다

   1. 실제 운영에서는 10개가 넘는 작업과 모니터 스레드를 동시에 실행하고, 다음날 하나씩 Merge·후속 작업·폐기를 결정한다.
   2. 일부 작업은 18시간 걸리고 일부는 18분 만에 끝나므로, 실행 시간이 짧다고 스레드를 성급히 닫지 않는다.
   3. 이 방식으로 5개의 Claude Code 구독을 사용하면서도 한도가 조금 남는 상태로 많은 작업을 처리할 수 있다고 설명한다.

7. 잠자는 동안에도 토큰을 쓰는 개발 환경

7.1. 항상 켜진 Linux 박스

1. 원격 개발을 기본값으로 만든다

   1. 회의나 외출 때문에 노트북을 닫아야 해도 작업이 계속되려면, 오래된 컴퓨터에 Ubuntu를 설치하고 Tailscale과 CLI Proxy를 구성한다.
   2. T3 Code로 그 박스에 작업을 보내면 노트북을 닫고 잠든 동안에도 에이전트가 구현·테스트·PR 작업을 계속한다.
   3. 가장 싼 선택은 가족이나 친구에게서 8GB RAM과 4코어 이상인 오래된 노트북이나 데스크톱을 얻는 것이다.

2. VPS보다 집의 컴퓨터를 선호한다

   1. 클라우드 VPS는 계정 정지 위험이 있는 서버 IP에서 Claude를 실행하게 만들 수 있으므로, 계정에 연결된 개인 거주지 네트워크가 낫다.
   2. 32GB RAM과 16스레드 장비를 Hetzner에서 월 275달러에 빌릴 수 있고 700달러짜리 32GB·1TB 장비를 살 수도 있지만, IP 때문에 정지될 수 있는 클라우드 장비에 돈을 쓰는 것은 비효율적이라는 식으로 풍자한다.
   3. 하드웨어를 사든 무료로 얻든, 추론 자체가 아니라 코드 실행을 담당하므로 고사양 GPU는 필요하지 않다.

7.2. Linux·전력·CI

1. 작업량에 맞는 사양이면 충분하다

   1. 여섯 개 스레드를 돌리는 32코어 서버도 CPU 사용률이 0%에 가까울 때가 있으므로, 대부분의 에이전트 작업에 코어를 많이 살 필요가 없다.
   2. 일반적으로 60~80W를 쓰는 컴퓨터에서 에이전트는 한두 스레드만 사용하는 경우가 많아 전기료 부담도 제한적이다.
   3. MacBook에서 세 에이전트만 돌려도 과열된다면, 파일 시스템과 보안 정책이 병렬 작업을 막고 있을 가능성이 있다. Linux에서 같은 작업을 하면 병목이 줄어든다고 설명한다.

2. CI가 CPU·RAM을 잠식할 때

   1. Rust 프로젝트를 여러 스레드가 동시에 컴파일하면 오래된 박스의 코어와 RAM을 모두 점유할 수 있다.
   2. CI를 GitHub에서만 실행하거나 Blacksmith·Depot 같은 CI 제공자로 옮기고, 별도 서버에서 빌드하거나 작업을 순차 큐로 묶을 수 있다.
   3. 문제마다 해법이 다르므로 에이전트에게 시스템을 조사하고 가장 싼 해결책을 설계하게 해야 한다. 실제로 Blacksmith CLI로 CI를 원격 실행해 RAM 제약을 줄인 사례가 있다.

8. 엔지니어링의 재미를 되찾는 방식

8.1. 에이전트의 실수를 보지 않고 다음 일을 한다

1. 프롬프트를 보낸 뒤 실수를 지켜보면 예전처럼 직접 작성하는 편이 더 빠르게 느껴진다.
2. 세 개의 스레드를 띄우고 저녁을 먹거나, 일곱 개를 실행하고 게임 대기나 스케이트를 하며, 쉬는 시간에 휴대폰으로 두 개만 확인하는 식으로 관찰 비용을 없앤다.
3. 재미는 휴대폰으로 프롬프트를 보내는 데 있지 않고, CI를 언제 실행할지, 코어를 어떻게 나눌지, 한 박스에서 여덟 작업을 어떻게 굴릴지 설계하는 새로운 엔지니어링 문제에 있다.

8.2. 결론: 에이전트 시대의 생산성은 병렬화와 판단 설계다

1. 토큰을 일로 바꾼다

   1. Claude·Codex의 구독은 API보다 큰 추론 보조금을 제공할 수 있지만, 그 혜택은 실제 문제를 풀고 검증하는 데 쓸 때만 가치가 있다.
   2. 리셋 전에 남은 한도를 태우되, PR 정리·테스트·문서·조사·오래된 아이디어 탐색처럼 결과가 남는 작업을 선택한다.

2. 사람의 역할을 재설계한다

   1. 사람은 모든 스레드를 감시하는 오퍼레이터가 아니라, 문제를 발견하고 맥락을 제공하며 에이전트가 풀지 못하는 어려운 판단을 맡는 존재가 된다.
   2. 에이전트가 필요할 때만 사람을 부르게 하고, 사람은 다음 문제와 사용자에게 이동해야 한다.

3. 장기적으로 약관과 지속 가능성을 지킨다

   1. 계정 여러 개, 프록시, 리셋, 서버 구성은 정지와 약관 위반 위험을 동반한다. 개인 개발을 위한 합법적이고 허용된 범위 안에서 사용해야 한다.
   2. 외부 사용자 트래픽을 구독 계정으로 처리하거나 계정을 재판매하면 보조금을 악용하는 것이므로 피해야 한다.
   3. 에이전트가 코드를 대신 작성하는 시대에도 재미는 사라지지 않는다. 반복 구현을 넘겨 주고 시스템·검증·컴퓨트·사용자 문제에 더 많은 시간을 쓰면, 오히려 엔지니어링을 더 깊게 설계할 수 있다.

주요 발언 모음

“에이전트가 풀 수 있는 문제에 생각을 쓰지 말고, 에이전트가 풀 수 없는 문제에 생각을 최적화하라.”

“생각을 외주화하지 말고, 생각을 확장하라.”

“에이전트는 멀티스레드일 수 있지만 인간은 싱글스레드다. 이제 병목은 우리다.”

“다음에 스레드를 열었을 때 바로 Merge할 수 있는 확률을 최대화하라.”

“작업을 띄웠다면 지금은 내 문제가 아니다. Done이나 Input이 될 때 돌아오면 된다.”

“토큰이 남았을 때 죄책감을 느끼지 않으려면, 의미 있는 일을 찾아 한도를 0으로 만들어라.”

핵심 데이터 & 수치

• 5개 스레드: 현재 동시에 실행하는 에이전트가 이보다 적다면 병렬 활용 여지가 크다는 출발점이다.
• 월 200달러 Claude 구독: 약 8,000달러어치 추론량으로 계산하며, Fable 몫은 약 4,000달러로 제한된다.
• 월 100달러 Claude 구독: 총량은 절반이지만 5시간 제한이 4분의 1 수준이라 한도를 태우기 어렵다고 설명한다.
• 월 200달러 Codex 구독: 약 12,000달러어치 추론량으로 계산한다.
• 14회/30일 리셋: Codex 사용자 사례에서 평균 2~3일마다 리셋이 발생했다.
• 입력 10달러·출력 50달러: Fable 공개 API의 100만 토큰당 가격으로 소개된다.
• 입력 25달러·출력 125달러: Glass Wing 기업용 사용 가격으로 언급된 수치다.
• 1초 대 6초: Parallel과 OpenAI 검색 엔드포인트의 시연 시간 차이다.
• 월 5,000회·80달러: Parallel 무료 요청량과 가입 크레딧이다.
• 5분: CLI Proxy 캐시가 유지되는 시간으로 언급된다.
• 15초: 나쁜 변경을 되돌리는 데 이보다 오래 걸리면 시스템을 먼저 고쳐야 한다는 기준이다.
• 8GB RAM·4코어: 원격 에이전트용으로도 충분하다고 제안하는 오래된 PC의 최소 사양이다.
• 60~80W: 코드 실행 중심의 원격 박스가 소비하는 전력의 대략적인 범위다.
• 3일·7일: T3 Code의 기본 자동 settle 기간과 발표자가 조정한 기간이다.
• 10개 이상: 실제 작업 중 동시에 실행되는 스레드 규모다.

결론 및 시사점

1. Claude나 Codex 구독을 단순 대화 도구로 사용하지 말고, 문제 발견·구현·테스트·리뷰·배포·정리로 이어지는 작업 파이프라인에 연결한다.
2. API와 구독의 비용 구조를 비교하되, 외부 사용자 트래픽은 반드시 허용된 API로 처리하고 개인 구독은 내부 개발에 한정한다.
3. 계정 수를 늘리기 전에 데이터 공유 설정, 약관, IP, OAuth, 계정 정지 위험을 확인한다.
4. 거주지 네트워크의 프록시와 Tailscale을 사용해 원격 머신을 연결하고, 세션·계정 affinity와 캐시 사용량을 관찰한다.
5. 리셋 직전에 남은 한도를 소모할 작업 목록을 만들고, 문서화·테스트·PR 분류·오래된 프로젝트 조사처럼 결과가 남는 일에 쓴다.
6. 문제의 해답을 미리 정해 에이전트를 조종하기보다 증상과 제약을 주고, 에이전트가 풀 수 있는지 먼저 시험한다.
7. Merge 전에는 자동 검증으로 위험을 낮추고, Merge 후에는 모니터링과 15초 이내의 되돌리기로 실패 비용을 낮춘다.
8. 스레드를 대화 기록이 아니라 할 일로 취급하고, Done과 Input만 확인하며 실행 중인 작업을 감시하지 않는다.
9. Linux 원격 박스와 Tailscale을 사용해 노트북이 닫힌 뒤에도 작업을 진행시키고, CI가 로컬 자원을 독점하면 원격 CI나 큐를 사용한다.
10. 인간의 사고를 없애지 말고, 에이전트가 풀 수 없는 문제와 더 중요한 제품·사용자 판단에 인간의 사고를 집중한다.

---

메타데이터

• source: YouTube
• channel: t3dotgg / Theo - t3․gg
• video_id: D8PikZ1KhUo
• title_original: If you have a Claude sub, watch this
• published: 2026-10-02
• processed: 2026-10-02
• category: ai-llm
• tags: #YouTube #t3dotgg #Claude #Codex #AgenticCoding #TokenMaxing #T3Code #Tailscale
• transcript: English auto-generated captions; Korean deep digest