타이핑 없이 코딩하는 법: 손 하나 없이 생산성을 유지하는 작업 방식

URL: https://www.youtube.com/watch?v=NvVbCqDgfCs 날짜: 2026-09-16 채널: t3dotgg 원문 제목: How I Code Without Typing

---

📌 핵심 질문 / 핵심 논점

==손을 거의 쓰지 못하는 상황에서도 컴퓨터 작업의 마찰을 없애고, AI 에이전트가 일하는 범위를 앞뒤로 넓혀 생산성을 유지하려면 작업 흐름을 어떻게 다시 설계해야 하는가?==

• 손 부상으로 타이핑·앱 전환·터미널·복사와 붙여넣기가 모두 큰 비용이 됐다.
• 음성 입력은 코드를 직접 받아쓰는 도구라기보다, 의도를 전달하는 입력 수단과 컴퓨터 사용 에이전트를 움직이는 인터페이스로 써야 한다.
• 에이전트를 작업 중간에 조금씩 끼워 넣는 방식에서 벗어나, 문제를 설명하는 단계부터 맡기고 검증·리뷰·머지까지 더 오래 자율적으로 수행하게 해야 한다.
• 휴대전화, 작은 지향성 마이크, Fleet, 여러 대의 컴퓨터, T3 Code의 병렬 스레드와 PR 도구를 조합하면 타이핑이 생산성의 병목이 되지 않는다.

한 손을 잃은 경험은 단순한 접근성 문제를 넘어 작업에 대한 정신 모델을 바꾸는 강제 장치가 됐다. 직접 컴퓨터를 빠르게 조작하는 능력 대신, AI가 컴퓨터를 조작하고 여러 작업을 병렬로 진행하도록 설계하면 작업의 길이가 하루 일정에 묶이지 않는다. 이 방식은 손이 멀쩡하고 타이핑이 빠른 개발자에게도 유용한 일반적인 생산성 원칙이 된다.

1. 손 부상으로 드러난 타이핑 중심 작업의 한계

1.1. 개인적 상황과 생산성의 충격

1. 머리카락 농담으로 시작하는 손 부상 이야기

   1. 최근 달라진 점을 알아챈 사람들에게서 말하는 변화는 길어진 머리카락이지, 한 달 넘게 깁스를 했다 풀었다 하는 손이 아니라고 농담한다.
   2. 손은 앞으로 한 달에서 최대 6개월까지 깁스를 해야 할 수 있고, 이 일은 유쾌하지 않기 때문에 평소보다 훨씬 개인적인 이야기를 꺼낸다.

2. 한 손으로 컴퓨터를 쓰는 불편

   1. 일을 타이핑하고 코딩하며 컴퓨터로 처리하는 사람에게 한 손만 쓸 수 있다는 것은 근본적인 제약이다.
   2. 앱 사이를 Command-Tab으로 오가거나 원하는 내용을 입력하는 평범한 동작조차 할 수 없게 됐다.
   3. 그럼에도 8월 8일 손을 묶기 시작한 시점 이후 GitHub 기여 그래프에서 보이듯, 이전보다 더 많은 것을 출시했다.
   4. 커리어에서 가장 크고 범위가 넓은 변경 작업 중 일부를 예상보다 빠르게 출하할 수 있었다.

1.2. 손가락을 잃은 대신 작업 방식을 바꾸다

1. AI만으로 설명할 수 없는 변화

   1. AI가 중요한 역할을 했지만, 핵심은 손 하나가 없는 상황을 우회하려고 일하는 방식을 의미 있게 바꾼 데 있다.
   2. 과거에는 분당 160단어를 꾸준히 입력할 만큼 빠른 타이퍼였기 때문에, 타이핑 능력 상실은 특히 큰 타격이었다.
   3. 손이 빠른 사람도 적용할 수 있는 조정이 많았고, 팀원들에게 공유한 결과 생산성과 실제 컴퓨터 작업의 즐거움이 모두 좋아졌다.

2. 개인 일기와 실전 팁의 결합

   1. 손이 작동하지 않는 지옥 같은 상황을 견디는 개인적인 기록이면서, 직접 타이핑하지 않고도 실제 AI 엔지니어링 도구로 생산성을 유지하는 팁 모음이다.
   2. 미국에서 발생한 의료비를 감당해야 하므로 잠깐 스폰서 광고를 넣겠다고 말하며, 언젠가 깁스에 로고를 붙일 스폰서가 있다면 연락해 달라고 농담한다.

2. 코딩 없이 타이핑하기가 아니라, 타이핑 없이 생산성 유지하기

2.1. 음성으로 코드를 직접 받아쓰는 방식의 한계

1. 제목을 더 정확하게 다시 붙이기

   1. 핵심은 “타이핑 없이 코딩(coding without typing)”보다 “타이핑 없이 PC에서 생산성 유지하기(staying productive on a PC without typing)”에 가깝다.
   2. 손 부상으로 어려워진 것은 코드 작성만이 아니라 앱 전환, 창 이동, 파일 처리, 터미널 조작 같은 컴퓨터 전체의 상호작용이다.

2. 음성으로 함수 정의를 받아쓰는 실험

   1. let x = 4, let y = 12, while x is less than y, x++ 같은 코드를 말로 입력해 보지만 실제 코드 작성 방식으로는 쓸 수 없다.
   2. 음성 텍스트 도구가 말한 내용을 번역하는 데는 훌륭해도, 직접 코드 문법을 정확히 받아쓰는 용도로는 현실적이지 않다.
   3. 수년, 수십 년 동안 실제 음성 코딩을 해 온 사람들에게는 존경을 표한다. 일반적인 개발자가 그대로 따라 할 방법은 아니다.

3. AI가 맡아야 하는 세 가지 역할

   1. 사용자의 말을 자연스러운 의도와 텍스트로 번역한다.
   2. 그 의도를 실제 코드로 작성한다.
   3. 가장 중요하게는 컴퓨터를 직접 사용하고, 필요한 앱·파일·브라우저·PR을 조작한다.

2.2. Vibe coding과 인터페이스 마찰

1. 손 부상이 강제한 Vibe coding

   1. 손을 다친 뒤 Vibe coding을 더 적극적으로 받아들이게 됐다.
   2. 타이핑이 어려운 것뿐 아니라 앱 전환 자체가 어렵기 때문에, 직접 세부 조작하는 대신 에이전트가 컴퓨터를 움직이게 해야 했다.

2. 앱 전환을 줄이는 물리적 배치

   1. 엄지가 제대로 작동하지 않아 검지로 Command 키를 누르고 약지로 Tab을 누르는 자세를 취해야 한다.
   2. Command-Tab을 할 수는 있지만 불편해서 앱 전환 자체를 덜 하게 된다.
   3. 촬영 중이 아니고 더 큰 화면을 쓸 때는 앱을 대부분 전체 화면으로 열지 않는다.
   4. 두 앱의 가장자리가 조금씩 보이도록 배치하면 오른손 마우스로 원하는 앱을 바로 클릭할 수 있어 키보드 전환을 피할 수 있다.
   5. 문제의 중심은 “얼마나 적게 타이핑할까”뿐 아니라 “마우스가 더 많은 일을 하게 하려면 무엇을 바꿀까”가 된다.

3. 손을 덜 쓰고 컴퓨터를 탐색하는 기본 도구

3.1. 휴대전화와 한 손 입력

1. 휴대전화는 한 손 컴퓨팅에 더 친화적이다

   1. 컴퓨터는 두 손을 전제로 설계된 반면, 휴대전화는 한 손으로도 덜 비참하게 사용할 수 있다.
   2. 오랫동안 슬라이드 타이핑(slide typing)을 써 왔고, 2000년대 후반과 2010년대 초 Android의 Swype 시절부터 한 손 입력에 익숙했다.
   3. 슬라이드 타이핑은 한 손만 필요하므로 손 부상 중에도 비교적 편하게 입력할 수 있다.

2. 휴대전화와 에이전트의 조합

   1. 처음 같은 문제가 생겼을 때는 휴대전화와 에이전트로 거의 모든 일을 옮겼다.
   2. 당시 에이전트가 지금처럼 유용하지 않아 Mark와 Julius에게 소리쳐 일을 대신 시키는 식이었다.
   3. iOS에서 자주 쓰는 앱과 표면적(surface area)을 정비하고, 휴식하며 휴대전화로 더 많은 것을 보기 위해 자체 Plex 클론도 만들었다.
   4. T3 Code를 계속 개선해 휴대전화에서 컴퓨터와 실행 중인 에이전트를 제어하기 쉽게 만들고 있다.

3.2. 조용한 음성 입력을 가능하게 한 작은 마이크

1. 음성 입력을 꺼리게 만든 사무실 환경

   1. Whisper Flow 같은 음성 텍스트 도구가 생각을 화면에 나타내 주는 경험은 여전히 마법처럼 느껴진다.
   2. 그러나 팀 전체가 주변에 있는 사무실에서 노트북을 향해 계속 크게 말하는 것은 불쾌하고 배려 없는 일처럼 느껴졌다.
   3. 카메라를 켜고 혼자 말하는 것과 팀 옆에서 계속 컴퓨터에 대고 말하는 것은 전혀 달랐다.

2. 약 70달러짜리 작은 탁상용 마이크

   1. 절대 쓰지 않을 것 같았던 작은 포디엄 마이크(podium mic)를 손 부상 때문에 시도했다.
   2. 정상 음량으로 말하면 예상대로 작동하지만, 진짜 변화는 거의 속삭이는 음성도 인식한다는 점이다.
   3. 녹음에 쓰는 전문 마이크는 500달러이고 800달러짜리 인터페이스에 연결돼 매우 민감하지만, 이 작은 마이크는 모니터 옆에 USB 케이블 하나로 연결해 사용한다.
   4. 전문 마이크의 모니터링 레벨이 약 -4dB일 때, 속삭임은 약 -40dB까지 떨어져도 인식된다. 합리적이라고 생각하는 음량보다 네 배 더 작게 말할 수 있다.
   5. 처음에는 MacBook 내장 마이크를 정상 음량으로 써 보기를 권한다. 다만 시연처럼 실제 속삭임을 하려면 작은 마이크가 유리하다.

3. 배경 소음과 심리적 장벽

   1. 옆에서 팀원이 이야기해도 속삭이는 목소리를 잘 분리한다.
   2. 휴대전화로 재생한 Primogen 영상의 소리가 자신의 목소리보다 컸는데도, 마이크는 말한 내용만 잡아냈다.
   3. Ben Davis는 비슷한 성능이 다른 음성 텍스트 도구에도 가능한지 모른다고 하면서도, Whisper Flow를 로컬에서 구현해 잘 쓰고 있다고 언급한다.
   4. 작은 마이크 덕분에 팀 옆에서 음성 입력을 하는 부끄러움이 사라졌고, 조용한 회의실이나 개인 사무실로 도망가야 한다는 부담도 없어졌다.
   5. 손 부상 이후 생계와 작업 방식에 가장 큰 영향을 준 팁이 작은 마이크였다고 평가한다.

4. 터미널을 버리고 컴퓨터 사용 에이전트로 이동하기

4.1. 음성으로 조작하는 터미널은 지옥이다

1. 터미널에 대한 기존 입장의 강화

   1. 터미널에서 타이핑하지 않는 것은 끔찍하다. 음성으로 터미널을 다루는 경험은 어떤 비유로도 실제 고통을 낮춰 표현하게 된다.
   2. 원래도 에이전트 기반 개발에 터미널이 맞는 장소가 아니라는 입장이었지만, 손 부상 이후 확신이 100배 강해졌다.
   3. 몇 주 동안 터미널을 연 일은 CLI를 실행하거나 특정 실험을 한 경우뿐이었다.
   4. 예외는 Astra로 TypeScript를 Rust로 다시 만들려는 TS Rust 실험을 한쪽 구석에서 YOLO 실행한 일이다. T3 Code의 개념적 공간을 차지하지 않도록 따로 돌렸다.

2. 터미널 대신 에이전트가 명령의 맥락을 갖게 하기

   1. 터미널에 명령을 말로 받아쓰는 대신, 에이전트에게 목표·컴퓨터·파일 위치·완료 조건을 설명한다.
   2. 에이전트는 SSH, 파일 복사, 다운로드 대기, 압축 해제, 앱 빌드처럼 여러 단계가 이어지는 작업을 한 번에 수행할 수 있다.
   3. 작업을 직접 이어 붙이지 않고 더 일찍 AI를 불러 필요한 다음 단계까지 맡기는 것이 핵심이다.

4.2. Fleet로 여러 컴퓨터를 하나의 작업 공간처럼 관리하기

1. Fleet 프로젝트의 역할

   1. Fleet는 실제 업무와 Vibe coding에 사용하는 모든 컴퓨터를 관리하는 프로젝트다.
   2. 각 컴퓨터의 용도, 연결 방법, SSH 정보, 설치된 소프트웨어와 환경을 문서화한다.
   3. 과거에는 어떤 컴퓨터에 무언가 설치하거나 인증을 설정하려면 직접 SSH로 들어가야 했지만, 이제 Fleet 스레드에 요청한다.
   4. 이 방식은 손 부상과 무관하게 여러 컴퓨터를 관리할 때도 맥락을 잃지 않게 해 준다.

2. Super Smash Bros. Melee 파일 전송 사례

   1. Super Smash Bros. Melee가 디컴파일된 것을 보고 게임 소프트웨어 개발 역사에서 엄청난 성취라며 크게 반긴다.
   2. 촬영을 방해하지 않도록 다른 컴퓨터에서 실행하고 싶었지만, 현재 컴퓨터에 합법적으로 보유한 게임 ISO를 다운로드한 뒤 다른 컴퓨터로 옮겨야 했다.
   3. 기존 방식은 다운로드가 끝날 때까지 기다렸다가 압축을 풀고, 터미널로 가서 SCP 명령을 작성하는 것이었다.
   4. 대신 Fleet 스레드에 “다운로드가 끝나면 Downloads 디렉터리에 있는, 여러 장을 이미 소유한 게임의 ISO를 다른 컴퓨터의 같은 디렉터리로 옮겨 달라”고 지시했다.
   5. Whisper Flow가 Leftbook을 lake bed로 잘못 인식해 빠르게 정정했으며, MacBook 마이크로 말했을 때보다 작은 마이크가 더 명확하다는 것도 확인했다.
   6. 파일이 아직 내려받아지지도 않은 시점에 지시하고 자리를 떠났고, 완료 알림을 받은 뒤 확인하니 실제로 작업이 끝나 있었다.
   7. 파일을 옮기는 시스템이 이미 있어도 다운로드 완료를 기다리고 다음 명령을 실행하는 추가 단계는 번거롭다. 에이전트는 그 대기 시간을 대신 흡수한다.

4.3. Orchestrator v2와 격리된 T3 Code 빌드

1. T3 Code의 오케스트레이션 개편

   1. T3 Code의 Orchestrator v2는 스레드가 에이전트에 노출되고 관리되는 방식을 크게 바꾼다.
   2. 한 에이전트가 다른 모델을 사용하는 새 스레드를 만들고, 하나를 서브 에이전트로 삼아 피드백을 얻으며, 코드로 여러 Claude 서브 에이전트를 띄우는 구성이 가능해진다.
   3. 변경 범위가 커서 병합에 신중하며, 매일 밤 사용하는 T3 Code 설치본을 망가뜨리고 싶지 않아 안정적인 nightly가 나올 때까지 기다리고 있다.
   4. 최근에는 T3 Code를 하루 평균 10시간 정도 사용하므로, 주력 설치본의 안정성이 특히 중요하다.

2. 데이터베이스를 기능 플래그로 감쌀 수 없는 이유

   1. Orchestrator v2를 지금 써 보기 위해 브랜치를 내려받아 로컬 개발 빌드를 만들거나 기존 설치를 백업하고 DMG를 교체하는 방법도 있었다.
   2. 새 데이터베이스가 계속 바뀌고 언제든 초기화될 수 있기 때문에 단순한 feature flag로 숨기는 것은 적절하지 않다.
   3. 기능 플래그는 오히려 출시를 더 어렵게 만들며, 언젠가 별도의 nightly 빌드로 제공할 계획이니 기다려 달라고 한다.

3. Fleet에 맡긴 T3 Code v2 제작

   1. 욕실에서 머리를 손질하는 동안 iPhone 음성 입력으로 Fleet에 새 스레드를 만들고, 스트리밍을 시작할 때 시연할 수 있도록 요청을 미리 넣었다.
   2. 현재 컴퓨터의 맥락까지 알고 있는 Fleet에 Orchestrator v2 브랜치를 사용하는 커스텀 T3 Code 앱을 만들라고 지시했다.
   3. 앱 이름은 T3 Code v2, 홈 디렉터리는 T3v2 전용으로 지정하고 기존 T3 Code 설치본과 겹치지 않게 했다.
   4. 일반 앱을 설치하는 방식으로 설치해 nightly와 v2를 자유롭게 번갈아 쓰게 했다.
   5. 머리를 마치고 스트림을 준비한 뒤 확인하니, 에이전트가 PR을 찾고 브랜치를 가져오고 빌드하고 설치하는 앞뒤 과정을 모두 끝내 놓았다.
   6. 과거에는 저장소 복제, worktree 생성, GitHub에서 PR과 브랜치 찾기, 로컬 빌드 지시를 직접 나눠 했지만 이제는 “어디에서 무엇을 가져와 어떻게 빌드할지”까지 에이전트에게 맡긴다.

5. 컴퓨터 사용 에이전트로 생활 업무까지 병렬화하기

5.1. 의료 기록 다운로드와 업로드

1. 불편한 병원 웹 앱을 에이전트에게 맡기기

   1. 손 문제와 관련해 주치의를 옮기는 과정에서 병원 대시보드에 저장된 여러 기록을 이전해야 했다.
   2. 병원 웹 앱은 많은 사람이 겪어 본 것처럼 사용하기 불편했고, 직접 하면 한 손으로 몇 시간이 걸릴 작업이었다.
   3. Astra 컴퓨터 사용 기능의 얼리 액세스 테스트에서, 이미 열어 둔 의료 기록 사이트에 들어가 모든 기록을 다운로드하라고 요청했다.

2. 49개 의료 PDF 처리

   1. 처음에는 40분쯤 걸렸다고 생각했지만 실제로는 약 20분 정도였다.
   2. 에이전트는 49개의 의료 PDF와 대량의 스캔 파일을 처리했다.
   3. 각 파일마다 여러 대시보드와 스레드를 이동하고, 로딩을 기다리고, 스크롤하고, 첨부파일 영역을 찾고, 다운로드하고, 검증하고, 정리하는 과정을 반복했다.
   4. ChatGPT를 열어 두면 T3 Code에서도 같은 작업을 할 수 있지만, 개인적으로는 코드 업무는 T3 Code에, 생활 업무는 ChatGPT에 나누어 맡긴다.
   5. 의사가 보낸 업로드 링크를 받은 뒤에는 다른 스레드에 기록을 모두 업로드하라고 지시했고, 컴퓨터 앞에서 직접 처리하지 않아도 완료됐다.

5.2. 일의 길이가 일정표를 더 이상 결정하지 않게 하기

1. 빠른 사용자도 한 손으로는 한 번에 한 일만 할 수 있다

   1. 오랫동안 컴퓨터를 써 왔고 단축키와 맞춤형 작업 흐름으로 빠르게 탐색하는 사람에게, 속도가 떨어지는 것은 사기를 꺾는다.
   2. 하지만 한 손으로 한 번에 하나의 동작만 할 수 있게 되면서, 여러 T3 Code 스레드가 동시에 일하도록 만드는 새로운 정신 모델이 열렸다.

2. 예정된 한 시간과 실제 한 시간이 분리되다

   1. 과거에는 한 시간 걸릴 것 같은 작업이 있는데 40분 뒤 촬영이나 회의가 있다면 시작하지 않았다.
   2. 그 작업은 계속 미뤄져 결국 일어나지 않기 쉽다.
   3. 이제 음성 입력, 컴퓨터 사용, Fleet의 여러 컴퓨터를 조합해 시작 시점과 완료 시점에만 확인한다.
   4. 노트북을 닫아 둔 채로도 네트워크의 전용 MacBook이 일을 계속한다.
   5. Leftbook은 남은 MacBook을 뜻하는 이름이며, 현재는 Melee 디컴파일을 돌린다. 물론 합법적으로 돌리는 것이라고 다시 농담한다.
   6. 한 시간짜리 작업을 하기 위해 하루에서 정확히 한 시간을 비워야 한다는 제약이 사라진다. 시작하고 끝날 때 확인하면 된다.

6. 에이전트가 들어오는 시점과 나가는 시점을 양쪽으로 확장하기

6.1. 작업 흐름에 에이전트를 배치하는 세 단계

1. 초기의 중간중간 개입 방식

   1. 한쪽에는 머릿속의 작업 아이디어가 있고 다른 쪽에는 결과가 완성되어 만족하는 상태가 있는 스펙트럼으로 작업을 생각할 수 있다.
   2. 초기에는 아이디어를 모델에 물어보고, 피드백을 받은 뒤 다른 에이전트가 구현하게 하고, 직접 만져 본 다음 또 다른 에이전트가 수정하게 했다.
   3. 에이전트는 작업 중간의 작은 구간에만 들어왔다.

2. 장시간 에이전트 실행 방식

   1. 모델이 강해지자 아이디어를 충분히 생각하고 원하는 방향을 정한 다음, 긴 에이전트 실행을 시작해 전체를 만들게 했다.
   2. 결과를 직접 테스트하고 마음에 들지 않는 부분을 찾은 뒤, 수정·리뷰 코멘트 대응을 다시 에이전트에게 맡겼다.
   3. 그 후 머지하는 지점까지 에이전트가 도달하는 방식으로 바뀌었다.

3. 손 부상 이후의 양방향 확장

   1. 문제와 아이디어를 정리하는 더 이른 단계부터 에이전트를 부른다.
   2. 에이전트가 코드를 만든 뒤 사용자가 직접 한 손으로 실행·검증하는 중간 구간은 줄인다.
   3. 컴퓨터 사용으로 스스로 변경 사항을 검증하고, 저장소의 AI 코드 리뷰 봇을 사용해 피드백을 받게 한다.
   4. 서브 에이전트가 코드를 한 번 더 검토해 사용자에게 돌아오기 전에 회귀(regression) 가능성을 낮추게 한다.

6.2. 해결책이 아니라 문제를 전달하기

1. 모호함을 에이전트의 탐색 공간으로 활용하기

   1. 어떤 해결책을 원하는지 모를 때는 문제 상황만 설명하고, 여러 해결책을 제안하라고 한다.
   2. 경우에 따라 전체 구현을 진행해 PR까지 올리라고 지시한다.
   3. 사용자가 정답을 미리 고정하지 않으면 에이전트가 문제를 조사하고 적절한 해결 방향을 선택할 여지가 커진다.

2. 검증을 포함한 장기 실행

   1. “변경 사항을 컴퓨터 사용으로 검증하고 확인하라”고 명시한다.
   2. AI 코드 리뷰 봇과 서브 에이전트를 함께 사용해 구현·테스트·리뷰를 작업 내부에 포함한다.
   3. 사용자에게 돌아오기 전에 “사용자에게 보이는 회귀가 없을 것이라는 확신이 생길 때까지 나를 귀찮게 하지 말라”고 요구한다.

6.3. 머지 구멍(merge hole)을 없애기

1. 사용자가 마지막으로 머지 버튼을 누르던 경계

   1. 과거에는 모델이 코드에 도달해도 사용자가 확인한 뒤 머지하는 선이 있었다.
   2. 그 마지막 구간을 ‘머지 구멍(merge hole)’이라고 부른다.
   3. 이제는 모델이 코드가 안전하게 머지 가능한지 판단하고 스스로 머지하도록 맡기는 경우가 많다.

2. 자율 머지의 실제 결과

   1. Astra가 여러 프로젝트에서 100개가 넘는 PR을 머지했고, Fable도 최소 50개를 머지했다.
   2. 두 에이전트가 작성부터 머지까지 완전 자율적으로 처리한 약 150개의 PR 중 회귀는 두 건뿐이었다.
   3. 한 건은 앱에서 애니메이션이 사라졌고, 다른 한 건은 마케팅 사이트에서 애니메이션이 사라졌다.
   4. 나머지는 모두 정상적으로 작동했고 앱에 실제로 큰 개선을 만들었다.

3. 자율주행 자동차와의 비교

   1. 자율주행차 사고 한 건을 보면 모두가 놀라지만, 주행 거리까지 비교하면 사고 한 건이 발생할 때까지 사람이 운전하는 거리의 다섯 배를 주행하는지 알 수 있다.
   2. 사고가 덜 위험할 수도 있다는 점까지 고려하면 단순히 사고 건수만 보는 것은 공정하지 않다.
   3. “YOLO merge”가 나오자 이것이 Whiskers인지 코드인지 모르겠다는 농담을 하고, Dan Ben의 농담에 진짜 웃음이 나왔다며 11점 만점에 10점을 준다.

7. 속도보다 병렬성·검증·마찰 제거를 우선하기

7.1. 모든 에이전트 스레드가 빠를 필요는 없다

1. 속도를 중요하게 보는 예외

   1. 긴급 버그 수정, 빠른 피드백이 필요한 작업, 미세한 디자인 반복에서는 모델 속도가 중요하다.
   2. Swift iOS 앱 스레드는 예외적으로 속도를 신경 쓴다.
   3. T3 Code 모바일 앱의 SwiftUI 버전 95% 이상을 하나의 스레드에서 실험적으로 만들었고, 여러 모델과 수개월의 작업이 쌓여 스레드 데이터가 8GB를 넘었다.
   4. 이 ‘지옥 스레드(hell thread)’에서는 한 번에 두세 가지를 연속으로 시도해야 하므로 빠른 반복이 유리하다.

2. 속도가 상관없는 장기 작업

   1. Lakebed 단일 서버 용량 제한 증가는 하루나 이틀에 한 번 확인하면 되므로 빠를 필요가 없다.
   2. Melee 디컴파일은 무기한 백그라운드로 돌며 세 배 느려도 삶에 의미 있는 차이가 없다.
   3. 성능 개선 측정, T3 Code 성능 향상 쇼케이스, 엔지니어 성능 평가, 이미지 미리보기와 렌더링 수정, 안정 버전 변경 사항 분류도 완료 시간보다 병렬 실행이 중요하다.
   4. Twitter 게시물용 작업처럼 목적을 달성한 스레드는 보관하면 된다.

7.2. 한 번의 입력으로 여러 스레드를 병렬 시작하기

1. 프롬프트 화면을 떠나지 않는 새 스레드

   1. 일반적으로 Enter를 누르면 현재 프롬프트가 전송되고 새 작업이 시작된다.
   2. Command-Enter를 누르면 현재 화면을 유지한 채 새 스레드가 열린다.
   3. 첫 번째 작업을 시작한 뒤 두 번째, 세 번째, 마음이 내키면 네 번째 작업까지 이어서 띄울 수 있다.
   4. Whisper Flow가 part job이 아니라 fourth job으로 인식했다는 점을 가지고 스스로 농담한다.

2. 마인드 덤프와 병렬 처리

   1. 하고 싶은 일을 머릿속에서 무작위로 꺼내는 마인드 덤프를 그대로 여러 스레드로 보낼 수 있다.
   2. 사용자가 다음 작업을 고민하며 기다리는 대신, 에이전트들이 각자 진행하는 동안 다른 일을 한다.

7.3. 문법과 오타에 대한 집착 내려놓기

1. 문장 품질을 중시하는 사람의 마찰

   1. 문법, 텍스트 형식, 문장 길이의 변화, 정확한 단어와 간결한 표현을 중요하게 여긴다.
   2. YouTube를 하는 이유 중 하나도 글의 품질과 명확성을 중요하게 여기기 때문이다.
   3. 음성 입력 결과에서 세 문장 내지 다섯 문장마다 단어 하나가 잘못 나오는 일이 처음에는 미치게 만들었다.

2. AI의 교정 능력을 신뢰하기

   1. 음성을 텍스트로 바꾸는 시스템 자체도 AI이므로 잘못 말한 단어와 오타를 문맥으로 처리하는 능력이 꽤 뛰어나다.
   2. 실제 스레드의 오타를 찾으려 했지만 평소에 모두 직접 고쳐 두어 생각보다 사례가 적었다는 자기반성도 한다.
   3. 모델이 혼란스러워하면 그때 고치면 되므로, 일단 오타가 있는 메시지를 보내고 너무 신경 쓰지 않는 편이 낫다.

8. GitHub 탐색을 에이전트와 T3 Code 안으로 옮기기

8.1. 직접 브라우징에서 질문 기반 탐색으로

1. GitHub가 가장 큰 마찰 지점이 되다

   1. 과거에는 주 작업 브라우저의 한 구역이 GitHub 탭으로 가득했고, 30~50개 탭을 열어 두곤 했다.
   2. 지금은 스트림 전에 탭을 정리한 영향도 있지만, 핵심 이유는 GitHub와 직접 상호작용하지 않기 때문이다.
   3. 손을 키보드에 이상하게 올려야 하는 상황에서 Command-Tab과 브라우저 이동은 특히 큰 비용이다.

2. 최근 PR을 에이전트에게 요약시키기

   1. 최근 3일 정도 동안 생성되거나 닫힌 PR 중 주의를 기울여야 할 것을 찾아 달라고 한다.
   2. 관심 있는 표면 영역(surface area)을 기준으로 필터링한다.
   3. 각 변경 사항을 두세 문장으로 요약하고, 마지막에 왜 자신이 특히 관심을 가져야 하는지 한 문장을 추가하게 한다.
   4. 직접 GitHub를 돌아다니며 읽었다면 오래 걸렸을 내용을 짧은 시간 안에 읽기 쉬운 목록으로 얻는다.

8.2. T3 Code 내장 PR 뷰어

1. 앱 안에서 PR을 읽고 머지하기

   1. Bal이 만든 T3 Code용 PR 뷰어가 앱 안에서 PR의 내용과 상태를 보여 준다.
   2. PR을 클릭해 T3 Code 안에서 열고, 필요하면 앱을 떠나지 않고 머지할 수 있다.
   3. 에이전트가 직접 머지할 수 있는 PR이라도 사람이 확인할 수 있는 내장 뷰어가 있다는 것은 편리하다.

2. GitHub 탭을 없앤 효과

   1. 실제 PR의 상태와 요약을 한곳에서 읽고, 필요한 경우 바로 열어 볼 수 있다.
   2. GitHub를 직접 탐색해야 한다는 부담이 줄어들어 컴퓨터를 한 손으로 쓰는 상황이 훨씬 덜 괴롭다.
   3. 작업 대상과 코드 변경을 한 앱에 모으는 것은 손 부상과 무관하게도 인터페이스 마찰을 줄이는 설계가 된다.

9. 복사·붙여넣기 대신 에이전트가 맥락을 찾게 하기

9.1. 복사와 붙여넣기를 덜 하는 우회법

1. 단축키의 물리적 비용

   1. Command-C와 Command-V는 손을 특정 방식으로 키보드에 올려야 해서 지금은 불쾌하고 어렵다.
   2. 원래도 에이전트 사이에 맥락을 복사해 옮기는 일이 많았지만, 손 부상으로 이 작업이 더 큰 장애물이 됐다.
   3. 작은 복사 버튼을 마우스로 누르는 것은 가능하지만 붙여넣기는 여전히 번거롭다.

2. 수동 복사·붙여넣기 예시

   1. PR 목록을 복사한 뒤 “어떤 PR을 먼저 볼지 우선순위를 정하고, 단순하면 머지해 달라”고 새 프롬프트에 넣는다.
   2. 스트리밍 중에는 실수로 YOLO 머지가 일어나지 않도록 머지 지시 부분을 삭제한다.
   3. 왼손으로 Command를 누르고 오른손으로 붙여넣는 두 손 동작을 시도하지만, 붙여넣어야 할 목록을 잊는 작은 실수도 생긴다.

9.2. 스레드 간 맥락 전달도 에이전트에게 맡기기

1. 더 느리고 더 비싸도 직접 전달하지 않기

   1. 이전 T3 Code 스레드에서 Codex에 최근 PR을 표면 영역별로 검토하게 한 뒤, 가장 우선순위가 높은 세 개를 골라 달라고 새 스레드에 요청한다.
   2. 이것은 복사·붙여넣기보다 효율적이지 않고, 요청이 느리며 토큰 비용도 더 든다.
   3. 하지만 어차피 그 시간에 다른 일을 하므로, 직접 맥락을 옮기는 시간을 아끼는 편이 낫다.

2. 게으름은 효율의 한 형태다

   1. 에이전트가 도구를 사용해 필요한 맥락을 스스로 찾을 만큼 좋아졌으므로, 사람이 브라우저를 열어 직접 조사할 필요가 항상 있는 것은 아니다.
   2. “내가 직접 할 수 있었는데 게으른 것 아닌가?”라는 질문에는 “그렇다, 그리고 게으름은 좋다”고 답한다.
   3. 게으름은 AI의 능력을 더 직접적으로 활용하고 사람이 해야 할 조정 작업을 줄이는 효율이다.
   4. 월 200달러 수준의 프론티어 모델 구독을 사용하며 토큰을 조금 낭비해도 괜찮다면, 이 방식의 순비용은 큰 문제가 되지 않는다.
   5. 더 저렴한 모델인 Terra나 Kim K3에서도 잘 될지는 모르지만, 프론티어 모델에서는 충분히 실용적이다.

9.3. 직접 맥락을 주지 않는 실험

1. 다음 버그에서 할 도전

   1. 다음에 버그를 발견하거나 기능을 만들고 싶을 때, 계획을 쓰거나 브라우저를 조사하기 전에 머릿속의 내용을 그대로 에이전트에 전달한다.
   2. 힌트를 주지 말고, 어디를 보라고 지시하지 말고, 사람이 수동으로 맥락을 끌어오지도 않는다.
   3. 에이전트가 실행되는 동안 평소 하던 일을 계속한다.

2. 결과 비교

   1. 작업이 끝나면 에이전트가 해결한 방식과 평소 수동으로 하던 방식을 비교한다.
   2. 그 후에도 모든 수동 준비 작업을 계속 자신이 해야 한다고 정직하게 말할 수 있는지 확인한다.
   3. 문제의 양쪽 경계에서 에이전트를 더 일찍 부르고 더 오래 실행하게 하면, 기존 프로세스의 상당 부분이 사라진다는 사실을 발견하게 된다.

주요 발언 모음

“타이핑 없이 코딩한다기보다, 타이핑 없이 PC에서 생산성을 유지한다고 말하는 편이 더 정확하다.”

“터미널을 음성으로 쓰는 것은 지옥이다. 손을 쓰지 않고는 다시는 키보드 없이 터미널을 사용하고 싶지 않다.”

“내가 얼마나 적게 타이핑할지를 묻는 것뿐 아니라, 마우스가 더 많은 일을 하게 하려면 무엇을 바꿀지를 묻고 있다.”

“게으른 것은 좋다. 게으름은 이 도구들의 능력을 더 직접적으로 이용한다는 뜻이다.”

“에이전트는 내 프로세스의 양쪽 경계를 너무 빠르게 허물었고, 나는 다시 돌아가지 않을 것 같다.”

“작업에 한 시간이 걸린다는 사실이 더 이상 내 하루에서 한 시간을 정해야 한다는 뜻이 아니다.”

“나를 덜 귀찮게 하려면, 사용자에게 보이는 회귀가 없다고 비교적 확신할 때까지 변경 사항을 검증하라.”

“문제가 생기면 그때 오타를 고치면 된다. 처음부터 그렇게 신경 쓸 필요는 없다.”

핵심 데이터 & 수치

• 손 부상 기간: 한 달 넘게 깁스를 했다 풀었다 했고, 앞으로 한 달에서 최대 6개월까지 깁스를 해야 할 가능성이 있다.
• 기존 타이핑 속도: 분당 최대 160단어를 꾸준히 입력했다.
• T3 Code 사용량: 최근 하루 평균 약 10시간 T3 Code를 사용한다.
• 전문 마이크: 녹음용 마이크 약 500달러, 오디오 인터페이스 약 800달러.
• 작은 마이크: 약 70달러이며 모니터 옆에 USB로 연결한다.
• 음성 레벨 시연: 정상 음성 약 -4dB, 속삭임 약 -40dB까지 내려가도 인식됐다.
• Orchestrator v2: 에이전트가 다른 모델의 새 스레드와 서브 에이전트를 만들 수 있도록 T3 Code 오케스트레이션을 개편한다.
• 의료 기록: 컴퓨터 사용 에이전트가 의료 PDF 49개를 약 20분 동안 다운로드·검증·정리했다.
• SwiftUI 스레드: T3 Code 모바일 앱의 SwiftUI 버전을 하나의 스레드에서 95% 이상 만들었고, 스레드 데이터가 8GB를 넘었다.
• 자율 머지: Astra가 100개 초과, Fable이 최소 50개의 PR을 머지했다.
• 회귀 비율: 약 150개의 완전 자율 PR 중 앱 애니메이션과 마케팅 사이트 애니메이션이 사라진 두 건의 회귀가 발생했다.
• GitHub 사용 변화: 과거에는 GitHub 탭 30~50개를 열었지만 현재 주 작업 브라우저에는 사실상 한 개만 남겼다.
• 병렬 스레드: Command-Enter로 프롬프트 화면을 유지한 채 두 번째·세 번째·네 번째 작업을 연속 시작할 수 있다.

결론 및 시사점

1. 손 부상은 타이핑을 대체할 단일 도구를 찾는 문제가 아니라, 컴퓨터와 일하는 모든 단계의 마찰을 찾아 없애는 문제로 바꿔야 한다.
2. 휴대전화의 한 손 입력과 조용한 탁상용 마이크는 음성 입력을 실제 사무실 환경에서 쓸 수 있게 만든다.
3. 코드를 말로 직접 받아쓰지 말고, 자연어로 의도·문제·완료 조건을 설명해 에이전트가 코드와 컴퓨터 조작을 맡게 해야 한다.
4. 터미널 명령, SSH, 파일 이동, 다운로드 대기, 앱 빌드처럼 여러 단계로 이어지는 일은 Fleet 같은 맥락 저장소와 컴퓨터 사용 에이전트로 위임한다.
5. 작업 시작 전의 아이디어 정리와 작업 완료 직전의 검증·리뷰·머지를 모두 에이전트의 범위에 넣어야 한다.
6. 에이전트가 직접 테스트하고 리뷰하고 머지하게 만들면, 사람이 한 손으로 여러 앱과 단축키를 오가며 수행하는 중간 작업이 크게 줄어든다.
7. 모든 스레드의 속도가 중요한 것은 아니다. 긴급 수정과 디자인 반복만 빠르게 하고, 나머지는 여러 스레드를 병렬로 오래 실행하는 편이 낫다.
8. 문법과 오타에 대한 과도한 집착을 내려놓고, 모델이 문맥으로 복원하지 못하는 경우에만 수정하면 음성 입력의 마찰이 줄어든다.
9. GitHub를 직접 브라우징하는 대신 PR을 요약·우선순위화하고 앱 안에서 확인하는 흐름을 만들면 탐색 비용이 사라진다.
10. 에이전트에 맥락을 직접 복사해 주는 대신 스스로 필요한 정보를 찾으라고 요청하는 실험을 해 보면, 사람이 하던 준비 작업의 상당 부분이 불필요했음을 확인할 수 있다.

핵심 요약 (20줄)

1. 손 부상으로 한 손만 쓸 수 있게 되면서 타이핑과 앱 전환이 작업의 가장 큰 병목으로 드러났다.
2. 분당 160단어를 입력하던 빠른 타이퍼도 손을 다치면 직접 조작보다 작업 설계가 중요해진다.
3. 핵심 목표는 코드를 음성으로 받아쓰는 것이 아니라 타이핑 없이 컴퓨터 생산성을 유지하는 것이다.
4. 음성 입력은 의도를 전달하고 AI가 코드와 컴퓨터 조작을 맡게 하는 인터페이스로 활용해야 한다.
5. 한 손 슬라이드 타이핑이 가능한 휴대전화는 두 손을 전제로 만든 컴퓨터보다 손 부상에 친화적이다.
6. 약 70달러짜리 작은 마이크는 사무실에서 속삭이듯 말해도 음성 입력을 가능하게 만들었다.
7. 작은 마이크는 약 -40dB의 속삭임과 주변 대화를 구분해 음성 입력에 대한 심리적 부담을 낮췄다.
8. 음성으로 직접 코드를 쓰는 일은 현실적이지 않으므로 자연어 설명과 컴퓨터 사용 에이전트를 조합해야 한다.
9. 터미널을 음성으로 조작하는 일은 고통스럽기 때문에 Fleet가 SSH와 파일 작업의 맥락을 대신 관리하게 했다.
10. Fleet 스레드는 아직 끝나지 않은 다운로드를 기다렸다가 다른 컴퓨터로 파일을 옮기는 일까지 자동으로 처리했다.
11. Orchestrator v2용 별도 T3 Code 빌드는 브랜치 탐색부터 빌드와 설치까지 에이전트가 수행했다.
12. 병원 대시보드의 의료 PDF 49개도 컴퓨터 사용 에이전트가 약 20분 만에 다운로드하고 정리했다.
13. 음성 입력과 여러 컴퓨터를 사용하면 작업의 시작과 끝만 확인하고 중간 과정은 병렬로 실행할 수 있다.
14. 에이전트는 아이디어 단계에서 더 일찍 들어오고 검증과 머지 단계에서 더 오래 남아야 한다.
15. Astra와 Fable은 약 150개의 PR을 자율적으로 머지했고 회귀는 애니메이션이 사라진 두 건뿐이었다.
16. 자율 머지의 품질은 개별 사고보다 전체 처리량과 실제 개선을 함께 평가해야 한다.
17. 긴급 수정과 디자인 반복을 제외하면 에이전트 스레드 속도보다 병렬 실행이 더 중요하다.
18. GitHub PR을 에이전트가 요약하고 T3 Code 내장 뷰어에서 확인하면 수십 개의 브라우저 탭이 필요 없다.
19. 복사와 붙여넣기 대신 에이전트가 다른 스레드에서 필요한 맥락을 직접 찾게 하면 느려도 수동 작업이 줄어든다.
20. 손 부상은 에이전트를 더 일찍 부르고 더 오래 실행하는 생산성 모델을 실험하게 한 강력한 강제 장치가 됐다.