휴가 중에도 PR 52개를 머지한 방법

URL: https://www.youtube.com/watch?v=q1D90-uGvBg
원문 제목: How I Shipped 52 PR's (While On Vacation)
날짜: 2026-09-09
채널: t3dotgg
재생 시간: 49분 22초

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==회사를 운영하고 여행하는 파트타임 엔지니어가 어떻게 코딩 시간을 거의 늘리지 않고도 높은 품질과 자신감으로 PR을 대량 처리할 수 있는가?==

• 작업을 로컬 컴퓨터의 단일 세션에 묶지 않고, Linux 원격 머신과 다중 에이전트(thread)로 분산한다.
• 에이전트에게 조사·감사·리뷰·테스트·후속 조치를 맡기고, 사람이 지루해하거나 의욕을 잃는 지점을 토큰과 자동화로 제거한다.
• 원격 웹·iOS·macOS 테스트 경로, PR-스레드 연결, inbox형 사이드바, 자동 리뷰 대응, nightly 빌드라는 안전망으로 병합 버튼의 위험을 낮춘다.

발표자는 회사와 YouTube 채널 운영에 더 많은 시간을 쓰면서 코드가 나빠진 것은 아니지만 실제 코딩 시간이 줄었고, 이메일·촬영·스폰서 업무처럼 자신만 할 수 있는 일을 처리하느라 컴퓨터 앞에 앉아 있을 시간이 거의 없어졌다고 말한다. 이 생활을 좋아하고 직업·팀·회사·삶에 만족하지만, 어려운 문제를 해결하고 매일 쓰는 소프트웨어를 개선하는 코딩의 즐거움을 놓쳤다. 따라서 이 사례의 핵심은 “AI가 대신 코딩한다”가 아니라, 사람의 판단이 필요한 병목과 심리적 마찰을 시스템적으로 없애면 적은 시간에도 더 많은 코드를 안전하게 출하할 수 있다는 주장이다.

1. 출발점: 코딩을 그리워하던 CEO의 PR 생산성 급증

코딩을 포기한 것이 아니라 코딩할 수 있는 순간을 시스템의 빈틈 없이 활용하는 것이 출발점이다.

1.1. 업무 변화와 기여량의 반전

1. 회사를 운영하면서 엔지니어링 시간이 사라짐

   1. 코드 품질의 문제는 아님: 코드가 갑자기 나빠졌거나 팀을 붙잡아 두는 엔지니어가 된 것이 핵심은 아니다. 다만 직접 코딩할 시간이 크게 줄었다.
   2. 자신만 할 수 있는 업무의 압박: 이메일, 촬영, 스폰서와의 협업 등 다른 사람이 대신하기 어려운 업무가 컴퓨터 앞의 시간을 계속 잠식했다.
   3. 상실한 즐거움: 어려운 문제를 현장에서 해결하고, 멋진 것을 만들고, 매일 쓰는 소프트웨어가 변경을 통해 좋아지는 과정을 보는 일이 발표자에게 중요했다.

2. T3 Code 기여 그래프가 반전을 보여줌

   1. 초기의 낮은 빈도: 한 주에 1~3개 PR을 머지하는 수준이었다.
   2. 7월 중순 이후의 급증: 주간 기여량이 23개, 37개, 41개를 거쳐 52개까지 올라갔다.
   3. 커밋 수의 의미: 그래프에는 커밋이라고 표시되지만 T3 Code는 squash merge를 사용하므로, 실제로는 발표자가 머지한 PR의 양을 나타낸다.

1.2. 휴가 중 52개 PR이라는 검증 사례

1. 여행 중에도 생산성이 유지됨

   1. 여행 시점: 8월 7일 주간에 여행 중이었고 DEF CON에 참석했다.
   2. 불리한 조건: 비행기 이동, Uber, DEF CON 호텔의 형편없는 인터넷을 오가는 동안에도 52개 PR을 랜딩했다.
   3. 자기반성 섞인 농담: 처음에는 “그 주에는 별로 바쁘지 않았나 보다”라고 생각하게 만들었다가, 휴가 중이었다는 사실을 뒤늦게 밝히며 청중을 조금 속였다고 농담한다.

2. 파트타임 개발자의 비교 기준

   1. Potato의 처리량: Potato가 한 달에 약 1,000개 PR을 랜딩하는 수준에는 못 미친다.
   2. 역할의 차이: 발표자는 동시에 여러 회사를 운영하므로, 파트타임으로 코딩하는 CEO가 이 정도로 출하한다는 점을 강조한다.
   3. 공개 이유: 이 흐름을 숨기지 않고 그대로 보여주며, 모두가 그대로 복사해야 한다고 주장하지는 않는다. 완벽하지 않은 부분과 따라 하면 안 되는 부분도 있지만 최소한 배울 만한 아이디어를 제공하려 한다.

2. 에이전트가 웹과 실제 환경에 접근해야 하는 이유

초반 스폰서 구간은 발표자가 생각하는 에이전트의 기본 전제와 브라우저 자동화의 활용 범위를 설명한다.

2.1. Browserbase가 해결하는 에이전트의 웹 접근 한계

1. API만으로는 웹의 대부분을 사용할 수 없음

   1. 브라우저의 필요성: 모델의 지식만으로는 오늘날 원하는 일을 효과적으로 수행하기 어렵기 때문에 에이전트는 브라우저가 필요하다.
   2. 접근 가능한 웹의 비율: 기존 API를 통해 curl하거나 fetch할 수 있는 영역은 웹의 약 15~20%뿐이며, 80%가 넘는 웹은 단순 API 호출로 접근하기 어렵다고 설명한다.
   3. 생산성의 의미: 에이전트가 사용할 수 없는 웹의 80%는 데이터와 작업의 큰 부분을 잃는 것이므로, 실제 브라우저 접근이 작업 품질을 좌우한다.

2. Browserbase의 사용 범위

   1. 읽기 작업: 단순 검색을 하거나 특정 URL의 문맥을 에이전트가 읽고 활용할 수 있는 형태로 가져온다.
   2. 행동 작업: 버튼 클릭, 페이지 로그인, 실제 작업 완료 등 종단간(end-to-end) 브라우저 흐름을 실행한다.
   3. 자체 서비스 테스트: 자신의 앱에서 회귀(regression)가 다시 나타나는지, 특정 흐름이 24시간 보장되는지를 에이전트가 사용자처럼 계속 실행해 버그가 사용자에게 도달하기 전에 발견한다.

2.2. 브라우저 에이전트 운영에서 생기는 장애

1. 에이전트가 브라우저에서 자주 멈추는 원인

   1. 차단된 IP 주소에서 접근하는 경우가 있다.
   2. CAPTCHA를 통과해야 하는 경우가 있다.
   3. Browserbase는 이런 차단과 탐색 중의 문제를 대신 해결해 에이전트가 웹을 계속 탐색하게 해준다고 소개한다.

2. 스폰서가 제시한 신뢰 신호

   1. Microsoft와 DeepMind도 Browserbase를 사용한다는 사례를 든다.
   2. 서비스 주소로 https://soy.link/browserbase를 안내한다.
   3. 이 구간의 직접적인 개발 방법론은 아니지만, 발표자가 이후에도 “에이전트가 실제 환경에 접근하고 테스트해야 한다”는 원칙을 강조하기 위한 사례다.

3. 기본 실행 루프: 새 스레드, 원격 머신, 음성 입력

작업을 시작하는 절차를 짧게 만들고, 작업이 실행되는 컴퓨터를 자신이 다른 일을 하는 컴퓨터와 분리한다.

3.1. 새 작업을 독립된 스레드로 시작하기

1. 세 단계의 시작 루틴

   1. 새 스레드(new thread): 발표자는 단축키로 새 스레드를 연다.
   2. 붙여넣기(paste): 작업 설명이나 링크를 붙여넣는다.
   3. 실행 위치 선택: 실제 변경은 현재 노트북이 아니라 원격 머신에서 실행되도록 한다.

2. 로컬 컴퓨터를 병목으로 만들지 않기

   1. 노트북은 다른 일을 하는 동안 작업 완료에 필수이거나 병목이 되는 장치가 아니어야 한다.
   2. “다른 사람의 컴퓨터에서 돌리라”는 뜻이 아니라, 내가 이메일·촬영 등 다른 일을 하는 컴퓨터가 에이전트 작업 때문에 막히지 않게 하라는 뜻이다.
   3. 발표자는 방 안의 Linux 박스에 코드베이스와 T3 Code 서버를 두고, T3 Code에서 BB1이라는 머신을 실행 상자로 선택한다.

3.2. 원격 Linux와 worktree

1. 원격 상자의 준비

   1. BB1에는 자신의 코드베이스, harness, Codex, Claude Code, 클라우드 접근 권한이 준비되어 있다.
   2. T3 Code 서버를 원격 머신에서 실행하므로, 발표자는 다른 장치에서 요청을 보내고 결과를 기다릴 수 있다.
   3. 이 머신은 작업을 전담하지만 반드시 최고 사양일 필요는 없으며, 원격 개발의 분리 자체가 중요하다.

2. worktree의 역할

   1. 각 에이전트 작업을 worktree에서 실행해 여러 작업이 같은 작업 디렉터리를 서로 덮어쓰지 않게 한다.
   2. 발표자는 현재의 worktree가 많은 문제를 완벽하게 해결한 최선의 추상화라고 보지는 않는다.
   3. 그래도 파일 시스템이 잘 지원하면 여러 개를 빠르게 만들 수 있고 “충분히 좋은” 격리 계층으로 쓸 수 있다고 평가한다.

3. T3 Code 자체를 작업 방식에 맞게 개선함

   1. 지금 설명하는 흐름은 표면적인 사용법이며, 진짜 핵심은 T3 Code를 쉽게 쓰고 원격으로 기능을 빌드할 수 있도록 T3 Code 자체를 고쳐 온 과정이다.
   2. T3 Code 저장소에는 다중 스레드·다중 에이전트 환경에서 다른 프로젝트를 잘 설정하는 예시도 있다.
   3. 도구를 소비하는 데 그치지 않고, 반복해서 걸리는 문제를 도구의 기능으로 다시 구현하는 순환이 이후 모든 사례의 공통 패턴이다.

4. 음성 입력

   1. 촬영 중 한 손을 사용할 수 없는 상황에서 Whisper Flow를 이용해 음성-텍스트(voice-to-text)로 프롬프트를 입력한다.
   2. 음성 인식 결과의 포맷이 다소 엉성해도 모델이 원하는 작업 지시로 충분히 정리할 수 있을 만큼 강력하다고 본다.
   3. 입력 속도를 높여 “새 스레드를 열고 설명하는” 마찰을 줄이는 것이 목적이다.

4. 첫 번째 실제 작업: 불확실한 문제를 조사 전용 스레드로 분해하기

에이전트에게 곧바로 코드를 쓰게 하지 않고, 현상·우선순위·중단 조건을 명확히 준 조사 프롬프트를 먼저 보낸다.

4.1. 스킬 호출 버그의 맥락

1. 달러 기호와 슬래시 명령의 차이

   1. $로 스킬(skill)을 호출하면 프로젝트 안팎의 스킬에 쓸 수 있다.
   2. 단, 스킬이 수동 호출 전용(manual-only)으로 설정돼 있으면 $ 버전으로는 동작하지 않고 / 슬래시 명령으로만 호출된다.
   3. 슬래시 명령은 모델이 스스로 활성화할 수 없는 수동 전용 스킬을 앞에서 직접 활성화할 수 있지만, 달러 기호 명령은 그러지 못한다.

2. 발표자가 이 버그를 늦게 발견한 이유

   1. 많은 스킬에 manual-only 속성을 켜두지 않았고, 그 스킬들을 자주 쓰지도 않았기 때문에 문제를 만나지 못했다.
   2. 채팅에서 한 사용자가 알려주면서 처음 인지했고, 실제 사용자에게 영향을 주는 문제라고 판단한다.
   3. T3 Code가 Claude Code의 동작을 감싸는 계층이어서, Claude Code가 기대하는 입력과 T3 Code가 전달하는 입력을 함께 감사해야 했다.

4.2. 의도와 제약을 모두 담은 조사 프롬프트

1. 사용자 영향과 목표를 먼저 제공

   1. “최근 여러 사용자가 겪는 문제”라고 알려 작은 사이드 프로젝트의 문제가 아니라 실제 사용자가 영향을 받는 문제라는 맥락을 준다.
   2. 목표는 단순한 구현 속도가 아니라 “구현은 단순하고 사용자가 혼란스럽지 않은 수정”이라고 못 박는다.
   3. “내 의견으로는 composer 어디에서든 달러 기호로 스킬을 호출하고 올바르게 연결할 수 있어야 한다”고 기대 동작을 명시한다.

2. 모델이 모르는 부분을 솔직히 표시

   1. Claude Code의 내부 특성, composer에서 보이는 스킬이 모델에게 전달할 올바른 텍스트로 변환되는 방식은 확실히 모른다고 말한다.
   2. 이 고백은 모델이 발표자의 추측을 무비판적으로 믿지 않게 하고, 발표자가 모르는 부분을 더 잘 설명하게 하는 장치다.
   3. 자신이 어디까지 아는지를 알려주면 모델이 답변에서 무엇을 설명해야 하고 무엇을 생략해도 되는지 판단하기 쉽다.

3. 조사 범위와 중단 조건

   1. Claude Code의 실제 동작과 T3 Code의 구현을 철저히 감사하라고 요청한다.
   2. 단순하고 확실한 수정 경로를 찾으면 코드를 바로 쓰지 말고 멈춰서 ASAP 적용할 해결책을 알려 달라고 한다.
   3. “confident solution”을 요청해 17개 선택지 중 하나를 고르기 위해 계속 탐색하지 않도록 한다. 다만 여기서 solution은 코드 작성이 아니라 자신 있는 해결 경로를 뜻한다.
   4. 발표자는 지시를 명시하지 않으면 에이전트가 마음대로 코드를 써버릴 수 있으므로, 원하는 작업과 원하지 않는 작업을 분명히 구분해야 한다고 말한다.

4.3. 스레드를 방치하는 것이 생산성의 핵심

1. 작업이 끝날 때까지 보지 않기

   1. 스레드가 답을 내는 동안 계속 지켜보면 생산적인 것처럼 느껴지지만, 에이전트가 더 빨리 끝나는 것은 아니다.
   2. 99%의 경우 스레드에서 진행 중인 일을 보고 즉시 중단해야 할 이유도 없다.
   3. 따라서 스레드를 실행시킨 뒤 이메일이나 다른 업무로 이동하는 것이 실제 생산성을 높인다.

2. 의욕을 잃는 순간을 먼저 차단하기

   1. 발표자는 PR을 하나 더 머지하기 위해 채팅에서 PR 링크를 받아도, 현재 CLI proxy를 쓰기 때문에 Codex나 Claude Code의 일반적인 사용량 한도를 확인할 수 없었다.
   2. PR을 직접 체크아웃하고 빌드·실행·테스트했는데 명백한 문제로 실패하면, 그날의 동기가 크게 떨어질 수 있다.
   3. 그 결과 Twitter로 Alt-Tab하거나 냉장고에 음료를 가지러 가면서 머릿속의 작업 맥락을 잃게 된다.
   4. 그러므로 “더 많은 토큰을 쓰더라도 실패 가능성과 좌절 가능성을 먼저 낮춘다”는 것이 중요한 운영 원칙이다.

5. 토큰으로 실패를 줄이는 PR 감사와 모델 분업

모델 호출 비용보다 사람의 중단 비용이 훨씬 크다면, 여러 모델과 서브에이전트로 미리 검증하는 편이 낫다.

5.1. 병합 전 PR 감사를 먼저 실행함

1. 사용량 대시보드 PR의 사전 감사

   1. PR 링크를 붙이고, 직접 테스트 환경을 꾸리기 전에 변경 사항을 철저히 감사하라고 요청한다.
   2. 명백한 실패, 잠재적 문제, 지금 머지했을 때 사용자에게 악영향을 줄 수 있는 요소를 모두 찾게 한다.
   3. 핵심 관심사는 API 호출 빈도가 너무 높아 사용자가 차단되는지, 데이터가 안정적·정확하게 가져와지는지, 대시보드 숫자와 제품 안의 숫자가 다르게 보여 사용자를 혼란스럽게 하지 않는지다.
   4. Codex Bar 같은 다른 오픈소스 프로젝트의 구현과 비교해 현재 구현이 어느 수준인지도 확인하게 한다.

2. PR 작성자에게 줄 피드백으로 변환

   1. 감사 결과가 지나치게 길면 “기여자가 문제를 고치고 PR을 머지 가능 상태로 만드는 데 도움이 되는 댓글 초안”으로 다시 작성하게 한다.
   2. 실제 댓글을 바로 남기지 말고 먼저 발표자에게 보여 승인받으라고 지시한다.
   3. 모델이 작성한 간단한 설명과 댓글 초안은 발표자가 내용을 더 잘 이해하게 만들고, 동시에 기여자에게도 실행 가능한 수정 목록을 제공한다.

5.2. 사용량 대시보드 감사에서 발견한 위험

1. PR 8327의 상태

   1. 기본 구조는 괜찮고 CI도 통과했으므로 “좋은 뼈대지만 머지 전 hold”라는 평가를 받았다.
   2. 모든 봇이 찾은 문제 중 하나를 제외하면 현재 커밋에서 해결되어 있었다.
   3. 그러나 실제 사용량 측정의 정책과 데이터 소스에 중요한 결함이 남아 있었다.

2. 세 가지 핵심 결함

   1. 429 위생(429 hygiene) 부재: Cloud endpoint를 커뮤니티에서 받아들여지는 최소 간격보다 빠르게 조회한다.
   2. 존재하지 않는 기간의 조작: API가 보고하지 않는 “무제한(unlimited) 기간”을 만들어 보여준다.
   3. 로컬 데이터 소스 무시: 다른 도구가 네트워크 호출을 피하기 위해 사용하는 무료 로컬 데이터를 활용하지 않는다.

3. 현실적인 서비스 제약

   1. Claude Code 쪽에는 사용량 한도를 30분 이상 확인하지 못했다는 이슈 보고가 여럿 있어, 조회 자체를 빠르게 반복하는 설계는 실제 위험이다.
   2. 구현은 60초마다 조회하고 있었는데, 유사 도구를 만드는 커뮤니티가 합의한 바닥선은 약 180초에 가깝다고 설명한다.
   3. 따라서 기능이 있다는 이유만으로 짧은 주기의 네트워크 요청을 허용해서는 안 되고, 캐시·서버 측 캐시·실패 시 미터 미표시 같은 정책이 필요하다.

4. 발표자가 추가로 알고 있던 사실

   1. SDK 응답에는 7일 Opus나 Sonnet 제한이 더 이상 별도 한도로 나오지 않을 가능성이 높다.
   2. 반면 7일 Claude 한도는 응답에 포함되며, 이 정보를 ASAP 추가해야 하므로 해당 PR의 머지 차단 조건으로 삼는다.
   3. Codex의 rate limit 기록은 유용하지만 다른 장소에서 Codex를 쓰고 있다면 오래된 값일 수 있다.
   4. API 호출을 아예 하지 않는 것이 이상적이지만, 정확하다는 확신이 없을 때 캐시 값을 현재값처럼 표시해서는 안 된다.
   5. 모델이 이 지식을 반영해 댓글을 다시 작성한 뒤, 발표자의 포맷으로 직접 기여자에게 댓글을 남기도록 허가한다. 기여자가 채팅을 보고 있어 의도도 알고 있는 상황이었다.

5.3. 스킬 버그 감사 결과와 쉬운 설명

1. 발견된 세 층의 결함

   1. 스킬 탐색(discovery)은 front matter의 이름과 설명만 읽고 enabled: true를 하드코딩한다.
   2. disabled model invocation, user invocable, settings의 skill override를 무시한다.
   3. $는 Claude Code의 문법인데 T3 Code가 이를 번역하지 않은 채 Claude에 보내고 있었다.

2. 슬래시·달러 호출의 실제 차이

   1. 슬래시 명령은 메뉴에서 어디에서든 선택할 수 있어도 Claude Code가 기대하는 방식은 메시지 맨 앞의 명령 하나다.
   2. 모델 설명상 “달러 메뉴에 보이는 고장 났거나 꺼진 스킬을 선택하면 Claude가 실제 실행 지시를 받지 못한다”는 문제다.
   3. 해결 방향은 Claude에 메시지를 넘기기 직전의 translation layer에서 달러 스킬 invocation을 올바른 지시로 변환하는 것이다.
   4. 이를 통해 메시지 어디에든 있는 달러 스킬 chip이 실제로 실행되게 하고, 앞부분 제한은 raw slash command에만 남긴다.

3. 발표자가 이해하기 쉽게 다시 요구함

   1. 모델의 해결책 설명이 너무 복잡해지자 문제를 실제로 무엇을 해결하는지 알기 어렵다고 지적한다.
   2. “문제를 어떻게 고칠지 초등학생에게 설명하듯 쉽고 짧게 말해 달라”고 다시 요청한다.
   3. 발표자는 문제 설명은 제대로 이해했지만 해결책을 읽다가 다른 일을 하고 싶은 충동을 느꼈고, 추가 토큰으로 설명을 단순화해 ADHD가 이기지 않게 했다고 말한다.

4. 다중 스킬 동작의 불확실성

   1. 앞에 있는 slash skill만 적용되는 것인지 확인하고, 스킬이 실제로 적용된 위치와 Claude Code가 부과하는 제한을 UI에서 분명히 보여주자는 질문을 던진다.
   2. Claude Code가 한 번에 앞에 보여줄 수 있는 명령은 하나이므로, 두 번째 명령에는 “앞으로 이동해 Claude가 기대하는 방식으로 적용할 수 없다”는 표시를 넣는 아이디어를 제시한다.
   3. 목표는 Claude Code의 특수 동작 때문에 사용자가 혼란스럽지 않게 하고, 가능하면 Codex와 거의 동일한 UX를 제공하는 것이다.
   4. 이후 실제 SDK mode의 Claude Code 2.1.237에서 여러 스킬을 앞에 쌓는 기능이 동작하지 않는 것을 확인했다.
   5. Anthropic 문서가 말하는 가능성과 실제 허용되는 다중 skill invocation 사이에 간극이 있었고, Claude Code 공개 이슈를 조사해 같은 문제를 보고한 사용자가 있는지 찾아보게 했다.
   6. 발표자는 Anthropic의 공개 발언, 모호한 문서, 난독화되고 uglify된 소스, 닫힌 JavaScript SDK라는 여러 겹의 불투명성을 비꼰다. 모델이 Anthropic의 문서도 실제로는 믿기 어렵다고 느끼는 점이 아이러니하다고 말한다.
   7. 조사 에이전트는 이 현상에 해당하는 이슈를 찾아냈고 Boris가 실제 버그라고 댓글로 확인했다. 발표자는 이 댓글을 Fable 5가 발표자를 대신해 작성했다고 표시한 채 남기도록 허가한다.
   8. 해결을 기다리는 동안 스레드를 다음 주까지 snooze하고, 그때도 고쳐지지 않으면 자신의 연락처를 통해 담당자에게 수정을 재촉하기로 한다.

6. 스레드를 inbox와 to-do list로 운영하는 T3 Code 기능

스레드 수가 많아질수록 모든 기록을 기억하려 하지 말고, 현재 추가 행동이 필요한 것만 눈앞에 남긴다.

6.1. PR과 스레드 연결

1. 사이드바의 PR 연결 버튼

   1. T3 Code는 스레드와 관련 PR을 사이드바에서 연결해 보여준다.
   2. 보통 해당 스레드가 만든 PR이 연결되며, 버튼을 누르면 에디터에서 PR을 열 수 있다.
   3. 화면 공간이 부족한 상황에서는 command-click으로 브라우저에서 PR을 연다.

2. 머지와 스레드의 관계

   1. 연결된 PR을 squash merge하면 사이드바의 스레드가 사라진다.
   2. 발표자는 머지 결과를 알고 있었으므로 해당 PR을 바로 squash merge한다.
   3. 이 동작은 일이 끝난 항목이 자동으로 inbox에서 빠지는 방식이며, 원하면 나중에 unsettle해 다시 볼 수 있다.

6.2. settle·unsettle·snooze의 의미

1. settled sidebar의 설계

   1. 사이드바에 남아 있는 스레드는 “추가 작업이 필요한 일”이라는 의미가 되게 만들었다.
   2. 이 동작이 맞지 않는 사용자는 설정에서 끌 수 있다.
   3. 발표자는 방송 준비 중 테스트하던 스레드, 더는 필요하지 않은 스레드를 연달아 settle한다.

2. snooze로 미래의 행동을 예약

   1. 지금은 처리하지 않지만 다시 확인할 가치가 있는 스레드는 3시간 snooze한다.
   2. 당시 예시에서는 오후 6시 36분에 snooze해 오후 9시 36분까지 다시 나타나지 않게 했다.
   3. 실제로 다뤄야 하는 일은 남겨 두고, 중요하지 않은 일은 잠시 시야에서 치워 현재의 집중력을 보존한다.

3. 오래된 스레드를 다시 여는 기준

   1. 예전 스레드로 돌아갈 유일한 주요 이유는 다른 문제를 고치는 데 그 문맥이 필요할 때다.
   2. 하지만 모델이 처음부터 문맥을 만들 수 있었다면 나중에도 다시 만들 수 있으므로, 과거 스레드를 항상 보존해야 할 필요는 낮다.
   3. 이 규칙으로 스레드 목록을 최소화하고, 사람이 기억해야 할 작업 수를 줄인다.

6.3. 스레드 상태 버그도 즉시 새 작업으로 전환

1. 완료 표시와 원격 연결 조사

   1. 어떤 스레드가 작업을 끝내고도 done 상태로 표시되지 않는 문제를 발견한다.
   2. 동시에 프롬프트를 쓰는 중 원격 연결이 끊긴 것도 발견한다.
   3. 원인에 대한 추측으로 시간을 쓰지 않고, 현재 머신과 이력을 탐색해 완료 상태가 빠진 원인과 연결이 끊긴 원인을 조사하라고 별도 스레드를 만든다.

2. 마찰 없는 이슈 처리

   1. 이슈를 발견한 순간 바로 스레드를 만들 수 있게 해 두면, “나중에 처리해야지”라고 미루다 영원히 잊는 일이 줄어든다.
   2. 발표자는 이 습관과 자동화가 사용자 경험뿐 아니라 PR 숫자를 올리는 데도 도움이 된다고 말한다.

7. 여러 모델과 서브에이전트로 PR 목록을 복구하고 우선순위화하기

PR이 너무 많아 기억이 불가능해지면, 모델마다 잘하는 작업을 나누고 쉬운 결정부터 반환하게 한다.

7.1. 모든 열린 PR을 정리하는 프롬프트

1. PR 상태를 세 부류로 분류

   1. 지금 머지할 준비가 된 PR인지 확인한다.
   2. 닫는 편이 나은 PR인지 확인한다.
   3. 안전하게 머지하기 전에 한 번 더 검토하거나 수정해야 하는 PR인지 확인한다.
   4. 여러 서브에이전트로 작업을 쪼개고, “할 수 있는 일이 쉬운 순서”로 우선순위를 정해 쉬운 PR부터 처리하게 한다.

2. 질문 덤프(question dump)의 활용

   1. 프롬프트 마지막에 무엇을 알고 싶은지 질문을 몰아 쓰는 방식이 모델이 목표를 더 잘 이해하게 만든다고 설명한다.
   2. 단순히 “PR을 보라”가 아니라 실제 의사결정 결과(merge, close, another pass)를 명시하면 모델이 조사 범위를 맞출 수 있다.
   3. 같은 작업을 GLM 계열 Flash와 Luna에 각각 보내 서로 다른 모델의 판단을 비교한다.

7.2. 모델 비용과 선택

1. GLM 계열 Flash

   1. 자막에는 “GLM53 Flash”로 들리는 모델을 GLM Flash로 표기한다.
   2. 가격 대비 매우 인상적이고, Codex 안에서 사용하고 있으며 이 작업에 특히 잘 맞는다고 평가한다.
   3. 무료에 가까운 사용량이 있어 이 작업을 해도 비용이 사실상 없다고 말한다.

2. Luna와 고속 설정

   1. Luna도 사용량 여유가 많아 사실상 비용이 없으므로, 같은 프롬프트를 Luna에 붙여넣고 high/fast 설정으로 실행한다.
   2. 서로 다른 모델을 같은 PR 목록 감사에 투입하는 것이 한 모델의 판단에만 의존하지 않는 방법이다.
   3. 작업이 오래 걸리는 동안 발표자는 결과를 기다리지 않고 다른 스레드와 테스트로 이동한다.

3. 모델의 메모리와 계획 형식

   1. Luna는 결과를 HTML plan으로 저장했다.
   2. 발표자는 이전에 이런 형식을 여러 번 요청해 모델이 메모리에 저장한 것처럼 보이는 점에 놀랐으며, 해당 모델에 메모리가 있을 줄은 몰랐다고 말한다.
   3. 하지만 결과의 형식보다 실제 위험을 올바르게 판단하는지가 더 중요하다고 평가한다.

7.3. 잘못된 추천을 버릴 줄 아는 기준

1. Luna의 기기 제한 PR 판단

   1. T3 Code의 기기 한도를 5개로 늘리는 PR을 머지 가능하다고 판단했다.
   2. 실제로는 Cloudflare 문제와 iOS의 압축 네이티브 WebSocket 문제가 해결될 때까지 확신할 수 없었다.
   3. 특히 이 PR은 네이티브 변경이 많고 Swift 네트워크 계층을 직접 다시 작성했으므로, 겉보기보다 단순하지 않았다.

2. 낮은 신뢰도의 결과 처리

   1. 발표자는 이 유형의 작업에서 Luna의 판단을 신뢰하지 않는다고 명시한다.
   2. 이 결과가 나중에 자신을 혼란스럽게 만들지 않도록 기록에서 archive한다.
   3. 반대로 GLM Flash는 PR들을 네 개의 서브에이전트로 나누어 조사하고 후속 실행을 준비하는 등 더 나은 모습을 보였지만, 초기화만 하고 감사가 시작되지 않은 버그처럼 보이는 순간도 있었다. 발표자는 에이전트가 스스로 해결할 수 있게 그대로 두고 기다린다.

8. 자동 리뷰를 스스로 처리하는 babysit 스킬

사람이 리뷰 댓글을 복사해 다시 프롬프트로 옮기는 반복을 스킬 하나의 지속 루프로 만든다.

8.1. PR-리뷰-수정의 반복 루프

1. 기존의 비효율

   1. 자동 리뷰 봇이 PR에 댓글을 달면, 발표자는 에이전트 도구로 돌아가 댓글을 하나씩 읽었다.
   2. 동의하는 댓글을 복사해 코드 작성 스레드에 붙이고 “이것들을 고쳐라”고 다시 지시했다.
   3. 이 왕복은 지루하고 비효율적이며, 사람이 리뷰 결과가 끝날 때까지 끌려 들어가게 만든다.

2. babysit 스킬의 지시

   1. PR에 자동 리뷰 댓글이 들어오는지 계속 지켜보라고 한다.
   2. 댓글이 실제로 고칠 가치가 있는지 판단하고, 가치가 있으면 코드를 수정해 push한다.
   3. PR을 계속 모니터링해 자동 리뷰 에이전트가 댓글을 해결했다고 판단할 때까지 개선을 반복한다.
   4. 한두 문단짜리 간단한 지시만으로 “변경→PR 업데이트→봇 리뷰→댓글 판단→재수정” 루프를 만든다.

3. 실제로 확인된 반복

   1. 최초 변경 후 자동 리뷰가 12개 댓글을 남겼다.
   2. 에이전트가 12개를 모두 처리하자 네 개가 추가로 왔고, 그것도 처리했다.
   3. 다시 한 개가 왔고, 그 한 개까지 처리한 뒤 AI 리뷰 봇들의 승인을 얻었다.
   4. 발표자는 이 모든 왕복이 자신과 리뷰 에이전트, 코드 작성 에이전트 사이에서 일어날 수 있었지만, 자신이 완료 시점에만 호출됐다는 점을 가장 좋아한다.

9. 원격 환경에서 실제로 테스트할 수 있게 만들기

“에이전트가 테스트했다”는 말만 믿지 않고, 발표자가 직접 확인할 수 있는 웹·모바일·데스크톱 경로를 만든다.

9.1. 원격 웹 개발 서버와 파일 업로드 검증

1. 원격 머신의 테스트 장벽

   1. 파일 업로드 흐름 전체를 뜯어고치는 큰 PR을 실제로 검증할 필요가 있었다.
   2. PR을 실행하는 스레드가 다른 원격 머신에 있고 Tailscale로 연결되어 있어, 로컬에서 할 수 있는 것은 터미널이나 발표자가 좋아하지 않는 앱 내 미리보기 브라우저 정도였다.
   3. 따라서 자신의 컴퓨터 브라우저에서 원격 PR을 진짜로 테스트할 방법이 필요했다.

2. Tailscale 공유 개발 기능

   1. T3 Code에 내장된 Tailscale 공유 d-share dev 명령을 추가해 달라고 요청한다.
   2. 에이전트는 PR을 체크아웃하고 개발 서버를 시작한 뒤 pairing code가 들어 있는 URL을 반환한다.
   3. 발표자는 그 URL을 자신의 브라우저에서 열어 원격 PR의 동작을 직접 확인한다.

3. 느린 네트워크를 위한 번들링 변경

   1. DEF CON 호텔 Wi-Fi는 10Mbps 정도였고, 기존 방식으로 개발 서버를 로드하면 20~30분이 걸렸다.
   2. 이 흐름을 가능하게 만들기 위해 번들링 방식을 크게 손봤다.
   3. 그 결과 원격 개발 서버를 전용 포트로 빠르게 열고, 이동 중에도 실제 브라우저에서 확인할 수 있게 됐다.

4. 파일 업로드의 실제 확인

   1. 이미지 파일을 드래그 앤 드롭해 업로드한 뒤 모델에게 어떤 파일인지, 어떻게 접근할 수 있는지 묻는다.
   2. 업로드 파일은 사용자 데이터 디렉터리에 저장되고, 파일 경로가 모델과 공유되므로 모델이 원하는 도구로 파일을 읽을 수 있다.
   3. 에이전트가 파일 데이터에 올바르게 접근하는 것을 확인해 해당 코드가 실제로 동작한다는 자신감을 얻는다.

5. 스크린샷과 일반 파일의 차이

   1. 스크린샷을 붙여넣고 내용이 무엇인지 묻자, T3 Code 앱과 현재 대화를 보여주는 PNG라고 정확히 설명한다.
   2. 이미지도 같은 첨부 디렉터리에 저장되지만, 이미지의 경우 harness가 메시지 안에 픽셀을 직접 렌더링하므로 모델은 별도로 파일을 읽을 필요가 없다.
   3. 원시 바이트가 필요하면 파일 경로도 사용할 수 있다.
   4. 파일 접근과 이미지 표시를 모두 확인했지만, 별도의 감사 스레드가 변경을 더 쪼개라고 했으므로 즉시 머지하지 않고 그 판단을 기다린다.

9.2. 원격 iOS 테스트

1. Squim 활용

   1. 모바일 변경을 원격으로 검증하기 위해 Squim이라는 프로젝트를 조사했다.
   2. Mac에서 모바일 앱을 빌드·번들링하고 웹 앱을 통해 설치할 링크를 제공하므로, 원격에서 빌드한 결과를 자신의 휴대폰에 설치해 테스트하기가 훨씬 쉬워진다.
   3. VPN이나 Tailscale 없이도 쓸 수 있다는 점을 장점으로 든다.

2. 남은 제약

   1. 완벽한 해법은 아니며 몇 가지 edge case가 있다.
   2. Tailscale을 이용한 원격 iOS 빌드는 가능하지만 번거롭다.
   3. 완전히 서명된 일반 iOS 빌드와 달라 공유·AirDrop 같은 세밀한 권한이 제한된다.
   4. 그래도 이동 중 변경 사항을 빠르게 확인하는 데 충분한 수준으로 웹과 iOS 테스트 문제를 해결했다.

9.3. 원격 macOS 데스크톱 테스트

1. 기존의 지연

   1. 발표자는 데스크톱 전용 변경이 웹과 비슷하다고 생각해 한동안 직접 확인하지 않았다.
   2. 그러나 인증 리디렉션 같은 이상한 edge case가 늘어나면서, 머지→nightly 대기→확인→실패 발견이라는 흐름에 지쳤다.
   3. 그래서 데스크톱 전용 변경에도 바로 테스트할 수 있는 인프라를 추가했다.

2. 라벨 기반 macOS preview build

   1. PR에 preview-col-mac 라벨(자막상 “preview col Mac”)을 붙이면 일정 시간이 지난 뒤 스레드에 macOS preview DMG 다운로드가 나타난다.
   2. 링크를 클릭해 파일을 내려받고 직접 실행할 수 있으므로, 전체 로컬 빌드 없이 데스크톱 앱 변경을 검증한다.
   3. 다른 테스트 머신에서 vanilla MacBook을 처음 설정하는 상황을 검증하기 위해 이 기능을 만들었다.

3. 로그인 없는 다운로드

   1. 예전에 퇴사한 직원이 쓰던 MacBook Air를 초기화해 TV 등을 구동하는 집의 공용 Mac으로 사용했다.
   2. 그 장치에는 Claude Code와 Codex만 남기고 T3 Code 기록을 모두 지웠다.
   3. GitHub 계정으로 로그인하지 않은 상태에서 preview DMG를 내려받을 수 없다는 문제가 생겼다.
   4. 원래 프로젝트의 핵심 기여자에게만 로그인 없이 다운로드를 허용하는 것이 합리적이었지만, 발표자의 테스트 머신에는 맞지 않았으므로 preview 라벨 빌드는 GitHub 로그인 없이도 다운로드할 수 있도록 PR을 추가했다.

4. 빌드 시간 최적화

   1. 기존 release build 인프라를 재사용해 다운로드 경로를 포함한 두 PR을 만들었고, 빌드와 접근성 코드가 각각 수백 줄 정도 추가됐다.
   2. 이후에도 빌드가 느려 만족하지 못했고, macOS 빌드는 약 6분이 걸렸다.
   3. Windows 빌드가 8분 걸려 다른 플랫폼과 병렬 실행되던 release 상황에서는 문제가 아니었지만, preview를 순차적으로 기다리는 현재 흐름에서는 중요했다.
   4. signing 처리 방식을 정리해 서명 호출 횟수를 81% 줄였다고 표시됐지만, 전체 빌드 시간 감소는 약 1분 30초였다.
   5. 발표자는 숫자 81%가 전체 시간 절감률이 아니라 signing call 감소율임을 직접 정정한다.

10. 마찰을 발견할 때마다 도구와 프로젝트를 고치는 방식

처리량 증가는 특별한 프롬프트 하나가 아니라, 머지를 막는 각각의 마찰을 제거한 누적 효과다.

10.1. 마찰의 종류를 관찰하기

1. 머지 버튼을 누르지 못하게 하는 요인

   1. 무엇이 자신을 머지에서 멈추게 하는지 기록한다.
   2. 어떤 변경이 흥미를 잃게 하고, 어떤 위험이 검증을 막고, 어떤 정신적 부담이 확인 작업을 미루게 하는지 본다.
   3. 확인이 귀찮아져 계속 미루다가 결국 영원히 머지하지 않는 흐름도 중요한 신호다.

2. 마찰을 기능으로 바꾸기

   1. 웹은 d-share dev, iOS는 Squim, macOS는 라벨 기반 preview DMG로 테스트 경로를 만든다.
   2. PR 상태는 사이드바와 settle/snooze로 관리하고, 자동 리뷰 댓글은 babysit 스킬로 처리한다.
   3. API 사용량은 캐시·호출 간격·실패 시 표시 정책을 감사하고, Claude Code 스킬 버그는 translation layer를 개선하는 식으로 문제의 원인이 있는 계층을 직접 고친다.

3. 누적 효과

   1. 각 개선은 작거나 우스워 보일 수 있지만, 반복되는 마찰을 하나씩 없애면 출하량과 자신의 검증 자신감이 함께 커진다.
   2. 발표자는 이런 개선이 휴가 중 처리량을 두 배 이상 높였다고 말한다.
   3. 도구를 더 많이 쓰는 것이 목적이 아니라, 도구를 쓰며 발견한 병목을 다시 도구와 프로젝트의 기능으로 환류시키는 것이 목적이다.

11. 실수는 남는다: 안전망으로 병합의 위험을 낮추기

에이전트와 자동화로 코드 생산량을 높이면 실수도 생기므로, “실수하지 않기”보다 “실수가 소수 사용자에게서 빨리 드러나고 되돌려지기”를 설계한다.

11.1. 코드 읽기만으로 잡을 수 없는 버그

1. 대량 생산의 대가

   1. 모든 코드를 한 줄씩 읽지 않으면 머지하면 안 되는 변경이 들어가는 일이 여전히 생긴다.
   2. 특히 대부분의 버그는 단순히 코드를 읽는 것만으로 합리적으로 발견하기 어렵다.
   3. 따라서 실제 사용자에게 영향을 주기 전에 문제를 포착할 별도의 안전망이 필요하다.

2. T3 Code의 현재 안전망

   1. T3 Code에는 완벽하지는 않지만 독특한 사용자층 덕분에 효과가 입증된 nightly build 체계가 있다.
   2. “nightly”라는 이름과 달리 3시간마다 새 빌드가 나온다.
   3. 변경이 머지되면 보통 3시간 이내, 때로는 더 빨리 nightly에 들어간다.

11.2. nightly 사용자와 안정 버전

1. 피드백을 받을 수 있는 표본

   1. 20만 명이 넘는 전체 사용자 중 수천 명 정도가 nightly 사용자다.
   2. nightly에서 문제가 생기면 이 사용자들이 즉시 많은 리포트를 보낸다.
   3. nightly 사용자는 불안정성을 알고 참여하므로, 기능이 바뀌거나 다시 제거되거나 문제가 생기는 상황을 감수한다.

2. 안정 버전의 회귀 방지

   1. nightly 사용자는 새 기능을 먼저 받아 보므로 정식 출시 발표 때 이미 기능을 쓰고 있어 “발표 전에 알고 있었다”는 반응을 보이기도 한다.
   2. 이 테스트 창에서 문제가 집중적으로 드러나기 때문에 stable release에서는 실제 회귀가 거의 발생하지 않는다고 말한다.
   3. 대안으로 전체 사용자의 1%에만 천천히 배포하고 오류가 보이면 즉시 rollback하는 slow rollout, 또는 모든 변경을 검증하는 공식 QA 팀을 들 수 있다.

3. 안전망과 가드레일의 구분

   1. 테스트를 하지 말라는 뜻이 아니다. T3 Code에는 많은 테스트가 있고, 요즘은 기능보다 테스트를 더 많이 머지할 때도 있다고 말한다.
   2. 중요한 것은 변경이 깨졌을 때 수천 명 또는 수십만 명에게 즉시 퍼지지 않고, 빠르게 알려지고 수정되는 안전망(safety net)이다.
   3. 이를 발표자는 “guard rail이 아니라 safety net”이라는 철학으로 요약한다.

11.3. 병합 버튼을 de-risk하기

1. PR에 들어가기 전의 위험

   1. 여러 에이전트가 먼저 조사·리뷰·테스트해 높은 확률로 준비됐다고 판단한 뒤에야 사람이 PR을 보게 한다.
   2. 사람이 PR을 여는 행위 자체가 무의미하게 느껴지는 이유를 제거해야 한다.
   3. 자동 리뷰가 끝없이 사람에게 돌아오지 않게 하고, 쉬운 PR부터 우선순위를 정하며, 완료 스레드는 inbox에서 치운다.

2. 머지 직전과 머지 직후의 위험

   1. 사람이 직접 테스트할 웹·iOS·macOS 경로를 준비해 실제 동작에 대한 자신감을 얻는다.
   2. 머지 후 nightly·slow rollout·QA 중 하나로 빠르게 문제를 좁힌다.
   3. 문제가 생겨도 모두에게 영향을 줄 것이라는 공포가 없으면, 발표자는 “두려움 없이 머지하고 나중에 걱정할 수 있다”고 말한다.

주요 발언 모음

“내가 CEO이면서 파트타임 코더인데도 어떻게든 당신보다 더 많이 출하하고 있을지도 모른다.”

“스레드를 열어 둔 채 기다리는 것은 생산적이지 않다. 그 스레드는 열어 둔다고 더 빨리 끝나지 않는다.”

“사람이 의욕을 잃게 만드는 순간을 줄여라. 나쁜 결과가 일어날 가능성을 낮추기 위해 토큰을 더 써라.”

“사이드바에 스레드가 있다면, 아직 처리할 일이 남아 있다는 뜻이어야 한다.”

“마찰이 있는 곳은 프로젝트·워크플로·빌드 도구를 개선할 기회다.”

“가드레일이 아니라 안전망이다.”

“PR을 보기 전부터 여러 에이전트가 높은 확률로 준비됐다고 판단하게 만들고, 내가 merge를 누르는 행위를 위험하지 않게 만들어라.”

핵심 데이터 & 수치

• 2,962초: 영상 재생 시간이다.
• 1~3개 → 23개 → 37개 → 41개 → 52개: 7월 중순 이후 T3 Code 주간 PR 머지량이 증가한 흐름이다.
• 52개 PR: 8월 7일 주간, DEF CON 여행 중 비행기·Uber·호텔 Wi-Fi 사이에서 랜딩한 수다.
• 약 1,000개/월: Potato가 랜딩하는 것으로 언급된 비교 기준이다.
• 15~20% / 80% 이상: curl·fetch API로 접근 가능한 웹과 접근하기 어려운 웹의 발표자 측 추정치다.
• 5% 이하 CPU: BB1에서 여러 스레드와 서브에이전트를 실행할 때 사용한 CPU다.
• 40개 이상 에이전트: 발표자가 한 머신에서 동시에 실행해도 문제가 없었던 경험치다.
• 32코어: 주력 Linux 머신의 코어 수다.
• 약 600달러·16스레드: 별도의 저렴한 Linux 머신도 해당 작업에서 약 12% CPU로 처리할 수 있다고 설명한다.
• 60초 vs 약 180초: 사용량 API를 60초마다 조회하던 구현과 커뮤니티가 받아들이는 최소 간격에 가까운 값이다.
• PR 8327: 구독 사용량 한도 미터를 감사한 PR 번호다.
• SDK 2.1.237: 다중 스킬 stacking이 동작하지 않는 것으로 확인한 Claude Code SDK mode의 버전이다.
• 3시간: T3 Code nightly 빌드가 생성되는 주기이며, 머지 후 보통 이 시간 안에 변경이 배포된다.
• 수천 명 / 20만 명 이상: nightly 사용자 수와 전체 사용자 수다.
• 12개 → 4개 → 1개: babysit 스킬이 자동 리뷰 댓글을 순차적으로 처리한 수다.
• 10Mbps: DEF CON 호텔 Wi-Fi에서 측정한 대략적인 속도다.
• 20~30분: 개선 전 느린 네트워크에서 원격 개발 서버를 로드하는 데 걸린 시간이다.
• 8분 vs 6분: Windows release build와 macOS build의 대략적인 시간이다.
• 81%: 전체 빌드 시간 절감률이 아니라 signing call 감소율이다.
• 약 1분 30초: signing 정리 후 실제로 줄어든 전체 빌드 시간이다.
• 1%: nightly의 대안으로 제시한 slow rollout의 초기 배포 비율이다.

결론 및 시사점

1. 개발 머신을 분리해라: 자신이 다른 일을 하는 노트북을 에이전트 작업의 병목으로 만들지 말고, 원격 Linux 머신·서버·worktree를 준비해 작업을 계속 돌려라.
2. 새 스레드를 쉽게 만들어라: 이슈를 발견했을 때 즉시 조사 스레드를 만들 수 있어야 하며, 음성 입력·단축키·붙여넣기로 시작 비용을 낮춰라.
3. 실행과 조사를 분리해라: 모델에게 바로 코드를 쓰게 하기 전에 목표·우선순위·모르는 부분·중단 조건을 명시하고, 먼저 audit과 confident path를 받아라.
4. 토큰을 심리적 비용의 보험으로 써라: 실패한 PR을 직접 빌드해 의욕을 잃는 순간을 줄이기 위해, 멀티에이전트 감사·쉬운 설명·댓글 초안 생성에 토큰을 사용해라.
5. 스레드 목록을 inbox처럼 다뤄라: 추가 일이 있는 스레드만 남기고 settle하며, 나중에 볼 일은 snooze하고, 오래된 문맥은 필요할 때 다시 생성해라.
6. 모델을 교차 검증해라: 서로 다른 가격·속도·강점을 가진 모델을 같은 PR 목록에 투입하되, 낮은 신뢰도의 추천은 기록에서 archive할 줄 알아라.
7. 리뷰를 루프로 자동화해라: 자동 리뷰 댓글을 사람이 복사해 전달하지 말고, babysit처럼 댓글을 판단하고 수정·push·재리뷰를 반복하는 스킬로 묶어라.
8. 실제 환경을 직접 테스트해라: 원격 웹 서버와 Tailscale 공유 URL, iOS 설치 링크, macOS preview DMG처럼 플랫폼별로 사람이 확인할 경로를 만들어라.
9. 마찰을 제품 기능으로 바꿔라: 머지를 막는 네트워크·빌드·로그인·권한·상태 표시 문제를 관찰하고, 반복될 때마다 T3 Code와 개발 도구에 기능으로 흡수해라.
10. 안전망으로 병합을 평범한 행동으로 만들어라: 테스트를 충분히 하되 모든 버그를 병합 전에 완벽히 잡으려 하지 말고, nightly·slow rollout·QA·rollback으로 영향 범위를 제한해라.
11. 처리량보다 자신감이 핵심이다: 52라는 숫자는 목적이 아니라, 적은 코딩 시간에도 무엇을 머지할지 알고 실제로 검증할 수 있게 된 시스템의 부산물이다.
12. 도구를 계속 다시 만들어라: 발표자는 앞으로도 3개월마다 이런 워크플로 영상을 만들고, 시간이 지나 현재의 방법이 얼마나 우스워 보일지 돌아보고 싶다고 말한다.
13. 모든 방법을 복사할 필요는 없다: 일부 설정은 발표자의 Linux·T3 Code·CLI proxy 환경에 특화됐으며, 핵심은 자신의 마찰 지점을 찾아 같은 원리로 해결하는 것이다.
14. 시청자의 반론도 개선 입력이다: 발표자는 이 방식이 마음에 들지 않더라도 댓글로 의견을 남기고, 아직 시도하지 않은 생산성 팁을 공유해 달라고 요청한다.
15. 최종 메시지: 삶과 개발 환경이 혼란스러워도, 병렬 에이전트·원격 실행·자동 리뷰·직접 테스트·점진 배포를 결합하면 파트타임 개발자와 전업 팀 모두 더 빠르고 자신 있게 소프트웨어를 출하할 수 있다.

핵심 요약 (20줄)

1. 회사와 YouTube를 운영하면서 직접 코딩할 시간이 줄었지만 어려운 문제를 해결하는 즐거움은 여전히 중요했다.

2. T3 Code 주간 PR 머지량은 1~3개에서 23개, 37개, 41개를 거쳐 52개까지 증가했다.

3. 8월 7일 주간 DEF CON 여행 중에도 비행기와 Uber와 호텔 Wi-Fi 사이에서 PR 52개를 랜딩했다.

4. 핵심 해법은 작업을 현재 노트북에 묶지 않고 Linux 원격 머신 BB1에서 독립 스레드로 실행하는 것이다.

5. worktree는 완벽하지 않아도 여러 에이전트의 작업을 격리하는 충분히 좋은 추상화로 활용할 수 있다.

6. 새 스레드와 음성 입력을 단축키로 시작하면 문제를 발견한 순간 조사 작업을 실행하기 쉬워진다.

7. 달러 기호 스킬 호출은 manual-only 스킬에서 작동하지 않으며 Claude Code에 전달할 번역 계층이 필요했다.

8. 에이전트에게 먼저 철저한 감사와 확신할 수 있는 해결 경로를 요구하면 불필요한 구현과 좌절을 줄일 수 있다.

9. 작업을 실행한 뒤 스레드를 지켜보지 않는 것이 실제 생산성을 높이는 중요한 습관이다.

10. 실패할 가능성이 있는 PR을 바로 직접 빌드하지 않고 더 많은 토큰으로 사전 감사하면 의욕을 보존할 수 있다.

11. PR 8327 감사는 429 위험과 허구의 무제한 기간과 로컬 데이터 소스 무시를 발견했다.

12. 사용량 API는 60초 조회 대신 약 180초 간격과 캐시와 실패 시 미터 숨김 정책을 검토해야 했다.

13. settle과 snooze는 사이드바를 추가 작업이 남은 inbox 겸 to-do list로 바꿔 기억 부담을 줄인다.

14. GLM Flash와 Luna에 같은 PR 우선순위 작업을 맡겨 모델의 판단을 비교하고 낮은 신뢰도의 결과는 archive했다.

15. babysit 스킬은 자동 리뷰 댓글을 감시하며 수정과 push와 재리뷰를 반복해 사람을 완료 시점까지 부르지 않았다.

16. Tailscale 기반 d-share dev와 pairing URL은 원격 머신의 웹 변경을 로컬 브라우저에서 검증하게 했다.

17. 사용자 데이터 경로와 이미지 harness 렌더링을 직접 확인해 파일 업로드와 스크린샷 흐름의 자신감을 높였다.

18. Squim은 원격 iOS 설치를 쉽게 했고 preview 라벨과 DMG는 macOS 전용 변경을 빠르게 테스트하게 했다.

19. nightly는 3시간마다 수천 명에게 변경을 배포해 20만 명이 넘는 전체 사용자에게 도달하기 전 회귀를 발견한다.

20. 안전망으로 병합 버튼을 de-risk하면 더 빠른 출하와 더 높은 자신감을 동시에 얻을 수 있다.