맥이 개발자의 발목을 잡는 이유 — 에이전트 시대 파일 시스템 성능에 대한 분노

URL: https://www.youtube.com/watch?v=4wVNFaFDIn8 날짜: 2026-08-22 채널: t3dotgg 원문 제목: Your Mac Isn't Actually Slow, It's MacOS Fault 실제 업로드일: 2026-08-20

---

📌 핵심 질문 / 핵심 논점

==Mac의 고가 하드웨어가 느린 것이 아니라, APFS가 작은 파일을 대량으로 복제·삭제·링크하는 에이전틱 개발 작업에 맞지 않는 것이 핵심 원인이다.==

• 캐시된 PNPM 설치조차 Mac에서는 35초가량 걸리고 Linux에서는 10초 이하로 끝난다.
• M1 Max와 AMD Ryzen 시스템의 디스크 성능 차이는 하드웨어보다 파일 시스템 동작에서 크게 벌어진다.
• XFS에 VDO 압축과 LZ4 계열의 가벼운 압축을 결합하면 작업 트리 생성 속도와 저장 공간을 동시에 개선할 수 있다.
• 기본 Ubuntu의 ext4도 APFS보다 훨씬 빠르지만, XFS+VDO는 125개 작업 트리에서 75GB를 24GB로 줄이는 식으로 공간 효율까지 개선한다.

에이전트(agent)가 하나의 대형 저장소를 여러 작업 트리(worktree)로 복제하고, 수많은 작은 파일로 구성된 node_modules를 설치·삭제·검색하는 흐름에서는 순차적인 일반 데스크톱 작업을 기준으로 한 파일 시스템의 절충이 병목이 된다. 해결책은 새 파일 시스템을 처음부터 만드는 것이 아니라, Linux 호스트에 작업용 파티션을 마련하고 목적에 맞는 파일 시스템·링크·압축 조합을 고르는 것이다.

1. 문제의 출발점: 비싼 MacBook에서 에이전트를 돌릴 때 생기는 지연

1.1. 반복되는 에이전틱 개발의 불편

1. 에이전트 작업이 기존 문제를 확대한다

   1. 에이전트를 많이 사용할수록 예전부터 있던 파일 조작 문제가 더 자주 발생한다.
   2. 고가의 MacBook은 하드웨어 자체가 매우 좋고 사용감도 훌륭하지만, 에이전트를 실행할 때 작업 트리와 의존성을 다루는 과정이 답답해진다.
   3. Linux로 옮긴 과정과 개발 환경은 이전에 별도로 이야기했지만, 이번에는 반복적으로 나타난 파일 시스템 문제 하나에 집중한다.
   4. 확정적인 연구 자료를 찾지 못해 직접 벤치마크를 설계하고 측정하기로 했다.

2. 첫 번째 비교는 단순한 폴더 삭제다

   1. 프로젝트에서 폴더 여러 개를 지우는 실행이 Mac에서는 35초를 넘겼다.
   2. 같은 실행은 Linux 장비에서 7초 미만 또는 12초 미만으로 끝났다.
   3. Linux 장비가 훨씬 강력해서 생긴 결과라는 추측은 틀렸다.
   4. Mac의 저장 장치가 오히려 훨씬 빠르며, 순수한 SSD 속도 비교가 아니기 때문이다.
   5. Linux 시스템이 MacOS보다 전반적으로 더 나은가라는 질문에는 “어느 정도 그렇다”고 답하지만, 측정한 것은 운영체제의 모든 성능이 아니라 파일 시스템이 파일을 관리하는 방식이다.

1.2. PNPM 설치로 드러난 차이

1. 네트워크가 아닌 로컬 파일 조작에서 격차가 난다

   1. 같은 프로젝트에서 Mac과 Linux의 PNPM 설치를 각각 타이머로 측정했다.
   2. Linux 장비는 설치와 각종 post-install 작업까지 10초 안에 끝냈다.
   3. Mac은 Linux가 끝난 시점에도 절반도 진행하지 못했고, 실행을 기다리는 동안 파일 시스템 주제를 설명해야 했다.
   4. 설치 파일은 네트워크에서 새로 내려받은 것이 아니라 두 컴퓨터의 캐시를 사용했다.
   5. 캐시된 기존 파일과 폴더를 연결하는 작업인데도 Mac은 약 35초를 소비했고, 시간의 대부분은 설치 자체보다 post-install script 실행에 들어갔다.

2. AI 코드의 병목과 파일 시스템 병목이 연결된다

   1. AI는 코드를 매우 잘 작성하지만, 실제로 코드를 merge하는 과정은 오히려 괴로워졌다.
   2. AI가 만든 Pull Request(PR)가 1,000줄을 넘는 일이 흔해졌고, 거대한 변경에서 중요한 부분을 찾고 제대로 작동하는지 확인하기가 어렵다.
   3. Code Rabbit 같은 AI code review 도구가 일부 도움을 주지만, 사람이 코드를 직접 읽고 배포 결과에 확신을 가져야 한다는 인간의 문제까지 해결하지는 못한다.
   4. 수백 개의 bot이 PR 설명을 계속 갱신하면 현재 PR의 상태를 파악하는 것 자체가 인간에게 불친절한 화면이 된다.

1.3. 스폰서 구간: CodeRabbit Change Stacks

1. Overview와 Timeline이 PR의 상태를 정리한다

   1. CodeRabbit의 Change Stacks는 Pull Request를 다루는 새 UI다.
   2. Overview는 현재 상황과 사람이 신경 써야 할 항목을 보여준다.
   3. 예시 PR은 “사람의 review가 아직 완료되지 않음”이 blocker로 표시되었고, 실제 review하려는 사람이 그 자리에 있다는 농담이 붙는다.
   4. Timeline은 변경이 시간순으로 어떻게 쌓였는지, 무엇이 왜 바뀌었는지, 어떤 작업이 동시에 진행되었는지를 보여준다.
   5. 예시에는 Vercel bot의 deploy도 timeline에 함께 표시되어 변경 맥락을 파악하는 데 도움이 된다.

2. Agent와 논리적 스택으로 거대한 PR을 분해한다

   1. 이해되지 않는 부분을 작은 agent 버튼으로 열리는 chat에 질문할 수 있다.
   2. 기존 목록처럼 코드를 알파벳순으로 나열하지 않고, PR이 바꾼 구체적인 기능에 따라 논리적 stack으로 나눈다.
   3. T3 Chat의 navigation을 크게 바꾸는 PR을 한 번에 읽는 일은 뒷단(back end), 앞단(front end), UI를 연결하는 부분이 뒤섞여 고통스럽다.
   4. Change Stacks는 API와 pagination, rail 쪽 UI navigation, data fetching 방식의 loading 변경을 각각 분리한다.
   5. 이런 분할은 죄책감에 밀려 코드를 merge하는 대신 변경을 이해하게 만든다는 메시지로 연결된다.
   6. 스폰서 안내 링크는 https://soydev.link/coderabbit 이다.

2. 파일 시스템을 이해하는 데 필요한 기본 모델

2.1. 폴더는 저장 장치에 실제로 존재하지 않는다

1. SSD가 아는 것은 0과 1뿐이다

   1. SSD에는 폴더나 작업 디렉터리라는 물리적 구역이 없다.
   2. 드라이브를 채우는 것은 데이터 블록과, 어느 데이터가 어디에 있는지를 추적하는 메타데이터다.
   3. 파일 시스템(file system)은 저장된 데이터의 의미, 위치, 재작성, 연결 관계를 관리하는 프로토콜이다.
   4. 사용자가 보는 폴더와 파일은 이 메타데이터 계층이 제공하는 편리한 환상이다.

2. 파일 시스템은 프로그래밍 언어와 비슷한 절충을 가진다

   1. 프로그래밍 언어가 runtime이나 compiler를 거쳐 결국 assembly 명령으로 변환되듯, 파일 시스템도 최종적으로 드라이브의 0과 1을 배치하는 방식으로 귀결된다.
   2. 같은 파일 조작을 하더라도 실제 내용과 저장 장치 사이에 놓인 계층과 규칙이 다르면 결과 속도가 달라진다.
   3. 파일 삭제, 복사, 이동, 여러 위치에 연결된 파일 중 하나만 남기기 같은 작업은 모두 파일 시스템이 처리해야 하는 복잡한 문제다.
   4. RAID를 사용하면 여러 드라이브에 데이터를 중복 저장해 하나가 고장 나도 복구하거나, 성능·용량 확장을 위해 저장소를 묶을 수 있으며, 파일 시스템별 절충이 더 늘어난다.

2.2. 운영체제별 선택지

1. Windows와 Apple의 계보

   1. Windows는 일반적으로 NTFS를 사용한다.
   2. MacOS는 과거 Journal 계열을 사용했으며, 기술적 이름은 HFS Plus였다.
   3. Apple은 한때 Mac에 ZFS를 쓰는 방안도 고려했지만 최종적으로 채택하지 않았다.
   4. 이후 APFS(Apple File System)를 만들었고, APFS는 이전 시스템보다 의미 있는 개선을 제공했다.
   5. Apple은 iOS 업데이트 한 번으로 모든 iPhone의 기존 파일 시스템을 APFS로 옮겼다.
   6. 이 과정은 한 파티션에서 다른 파티션으로 데이터를 조금씩 옮기며 안전하게 부분 기록했고, 사용자 파일이 손상되거나 사용자가 변화를 알아차리지 않도록 조용히 진행되었다.
   7. 이 사례는 Apple 파일 시스템 팀의 기술력이 뛰어나다는 증거지만, 현재 에이전틱 개발 작업의 우선순위가 그 강점을 그대로 활용하지는 못한다.

2. Linux의 넓은 선택지

   1. Linux에는 ext4, XFS, ZFS, Btrfs 등 매우 많은 파일 시스템이 있다.
   2. ext4는 Ubuntu의 표준 선택지로 작고 빠르며 단순하다.
   3. XFS는 더 확장 가능한 대안이다.
   4. ZFS와 Btrfs는 기능이 풍부하고 자주 비교·논쟁되는 기술이며, 특히 RAID와 대형 저장소를 염두에 둔 설계가 강하다.
   5. 서로 다른 파일 시스템은 결국 같은 저장 장치를 다루지만, 메타데이터·링크·복사·압축을 배치하는 방법이 다르다.

2.3. 블록, 포인터, 삭제, 복사

1. 4KB 블록과 빈 공간

   1. 대부분의 파일 시스템은 4KB 정도의 블록 크기를 사용한다.
   2. 12KB 파일은 세 블록에 나누어 담을 수 있다.
   3. 중간 데이터가 삭제되면 드라이브 중간에 빈 블록이 남는다.
   4. defrag는 빈 블록을 찾아 데이터를 앞으로 밀어 관련 데이터와 빈 공간을 다시 모으는 작업이다.
   5. 4KB보다 작은 두 파일인 index.ts와 something.ts를 어떻게 한 블록에 배치할지, 같은 파일 두 사본을 어떤 포인터로 표현할지가 파일 시스템의 설계 문제가 된다.

2. 복제와 링크의 비용

   1. 운영체제는 파일 이름과 데이터 블록의 위치를 별도로 기억해야 하므로, 파일명과 포인터를 갖는 메타데이터 계층이 필요하다.
   2. index.ts를 복사하는 단순한 파일 시스템은 빈 블록에 실제 데이터를 또 쓸 수 있다.
   3. 작업 트리가 여러 개이고 node_modules처럼 동일한 내용이 반복되면, 진짜 복제는 저장 공간과 쓰기 시간을 크게 낭비한다.
   4. copy-on-write(CoW)는 처음에는 새 파일을 만들지 않고 기존 파일을 가리키다가, 복제본이 수정될 때만 새 데이터를 만든다.
   5. reflink나 hard link 같은 기능은 파일을 여러 위치에서 공유하게 만들 수 있지만, 구현 방식에 따라 연결 생성과 삭제 자체에 큰 overhead가 발생한다.

3. 에이전틱 개발에 필요한 파일 시스템의 평가 기준

3.1. 속도와 작은 파일

1. 측정해야 할 속도는 하나가 아니다

   1. 삭제 속도는 작업물을 정리하거나 get clean을 실행할 때 중요하다.
   2. clone 속도는 새 작업 트리를 만들 때 중요하다.
   3. indexing 속도는 system search, ripgrep 같은 도구가 파일 위치를 아는 데 필요하다.
   4. 빠른 lookup과 일반적인 메타데이터 처리 속도도 반복적인 agent 실행에 영향을 준다.
   5. 수많은 작은 파일을 한꺼번에 처리하는 능력이 핵심이며, 이 지점에서 여러 시스템이 병목을 보인다.

2. 에이전트 작업 흐름에 맞춰야 한다

   1. 좋은 파일 시스템은 빠른 worktree 생성, 빠른 PNPM install, 빠른 cleanup을 제공해야 한다.
   2. 여러 작업 트리에서 한두 파일만 수정한다면 전체 코드베이스를 매번 물리적으로 복제하지 않아야 한다.
   3. 대규모 저장소를 agent가 병렬로 다루는 환경에서는 단일 파일의 순차 읽기 속도보다 메타데이터·링크·삭제의 집단 처리 비용이 더 중요하다.

3.2. 기능과 호환성

1. 메타데이터와 CoW

   1. 파일에 tag를 달고 생성 시점을 확인하며, 어떤 파일을 덮어써도 되는지 판단하는 메타데이터 기능이 유용하다.
   2. deep link와 copy-on-write는 작업 트리 clone을 즉시 만들고 실제 수정이 발생할 때만 공간을 쓰게 한다.
   3. 이런 기능은 단순한 파일 복사보다 공간을 아끼지만, 구현에 따라 CPU와 메타데이터 처리 비용을 추가한다.

2. 지원 운영체제의 제약

   1. 파일 시스템이 Linux kernel에 포함되는지, 어떤 운영체제가 공식 지원하는지가 실제 선택을 제한한다.
   2. 드라이브를 Windows·Mac·Linux에 번갈아 꽂아야 한다면 exFAT가 사실상 가장 넓은 호환성을 제공한다.
   3. 여러 플랫폼을 지원해야 하는 USB나 flash drive에는 exFAT가 실용적이지만, 에이전틱 개발용 내부 드라이브에서는 원하는 성능·링크·압축 기능을 얻기 어렵다.
   4. Mac 파티션의 일부를 다른 파일 시스템으로 포맷해 쓰려는 구상은 Apple이 다른 파일 시스템을 충분히 지원하지 않아 현실성이 낮다.

3.3. 압축과 실제 공간

1. 압축은 용량과 성능을 동시에 결정한다

   1. 파일을 얼마나 줄이는지가 space saving의 첫 번째 기준이다.
   2. 읽고 쓸 때 압축·해제를 수행하는 CPU 비용이 실제 작업 속도를 떨어뜨리지 않는지도 따로 측정해야 한다.
   3. 파일의 논리적 크기를 합산하는 명령은 실제 드라이브 사용량과 다를 수 있다.
   4. 같은 파일이 네 곳에 표시되지만 SSD에는 한 번만 저장되어 있다면, 파일 크기 합계는 물리적 사용 공간을 의미하지 않는다.
   5. 실제 시스템 파일을 측정했을 때 논리적 데이터는 약 3,000GB였지만 드라이브가 차지한 공간은 수백 GB에 불과했다.
   6. 좋은 압축과 linking 기능이 논리적 데이터 크기와 실제 저장 공간의 차이를 만든다.

2. 현실적인 목표

   1. 빠른 작업 트리, 빠른 PNPM 설치, 빠른 cleanup, clone에 낭비되는 공간 최소화가 목표다.
   2. 한두 파일만 건드리는 worktree가 코드 전체를 드라이브에 다시 복제하면 큰 공간 낭비가 된다.
   3. 압축이 CPU 부담 때문에 성능 이득을 상쇄할 것이라는 우려가 있었지만, 실제 측정에서는 가벼운 압축 계층이 오히려 빠른 결과를 냈다.

4. XFS+LZ4/VDO를 찾기까지

4.1. Wendell에게서 얻은 가설

1. 커뮤니티 질문

   1. 홈 시스템과 home lab을 운영하는 다른 creator들의 group chat에 질문을 올렸다.
   2. Level One Tech의 Wendell에게 개인적으로 물어보려던 참에 같은 채팅방에 있어 공개적으로 물었다.
   3. 질문의 조건은 병렬로 실행되는 agent 개발 장비, 대형 저장소의 많은 worktree, 많은 node_modules, 작은 파일 batch copy였다.
   4. APFS는 너무 나빠 Mac에서 code agent를 거의 돌리지 않는다고 적었다.
   5. Btrfs는 유망하지만 작은 파일을 대량 복사할 때 느렸고, ext4는 작은 파일 쓰기 성능은 좋지만 copy-on-write primitive가 부족하다고 정리했다.
   6. Anomaly의 Rift도 언급하며 나중에 이야기하겠다고 했다.

2. 한 줄의 답

   1. Wendell은 거의 즉시 “XFS plus LZ4”라고 답했다.
   2. 아직 압축을 평가 항목으로 깊게 설명하지도 않았는데 LZ4를 함께 제안한 것이 출발점이었다.
   3. XFS 파일 시스템과 실제 드라이브 사이에 VDO 같은 계층을 두고 LZ4 계열의 가벼운 압축을 사용하는 구성이 모든 요구를 연결했다.

4.2. VDO와 LZ4의 작동 방식

1. 드라이브 아래에 압축 계층을 둔다

   1. XFS가 파일 이름과 블록 포인터를 관리하고, VDO가 실제 드라이브에 쓰기 전에 데이터를 압축하는 계층이 된다.
   2. 여러 데이터 조각을 하나의 블록에 넣을 수 있어 4KB 블록 단위의 낭비를 줄인다.
   3. 서로 다른 clone이 같은 블록을 공유하도록 표현할 수 있으므로 실제 내용을 매번 복제하지 않아도 된다.
   4. 중복 데이터와 블록보다 작은 파일을 효율적으로 저장할 수 있다는 장점이 생긴다.

2. LZ4가 필요한 이유

   1. 압축 계층은 저장·읽기 때 processor가 추가 작업을 하게 하므로 일반적인 압축은 성능 overhead를 만들 수 있다.
   2. LZ4는 매우 가벼운 compressor라서 read와 write 비용이 낮다.
   3. 낮은 CPU 비용으로 의미 있는 공간 절약을 제공하기 때문에 작은 파일이 많은 에이전트 작업에 적합하다.
   4. 실제 결과는 압축 overhead가 속도 이득을 취소할 것이라는 예상과 달리 매우 빨랐다.

5. 후보 파일 시스템 벤치마크

5.1. 기본 특성 비교

1. ext4

   1. 구조가 단순하고 minimal해서 파일 크기와 무관하게 빠른 편이다.
   2. 메타데이터 기능이 많지 않고 copy-on-write를 제공하지 않는다.
   3. 새 디렉터리를 만들 때마다 그 디렉터리가 실제 공간을 차지한다.
   4. 작은 파일의 쓰기·삭제 성능은 좋지만 반복 clone과 공유 저장에는 불리하다.

2. XFS

   1. ext4보다 확장 가능한 대안이다.
   2. XFS 자체는 copy·link·압축을 VDO와 조합할 여지가 있다.
   3. XFS+VDO는 기본 XFS의 파일 조작 성능을 유지하면서 실제 저장 공간을 줄이는 구성을 제공한다.

3. ZFS와 Btrfs

   1. 두 시스템 모두 강력하고 멋진 기능이 많으며 자주 비교되는 기술이다.
   2. RAID와 저장소 풀을 염두에 둔 성격이 강해 단일 개발용 작업 파티션의 작은 파일 처리에는 최적이 아닐 수 있다.
   3. Btrfs는 NAS와 파일 저장 용도로 여전히 유용하고, 실제 영상 파일도 Btrfs에 저장했다가 Dropbox로 editor에게 전달했다.
   4. 이번 결론은 모든 용도에서 이 둘을 폐기하라는 뜻이 아니라, 에이전틱 개발용 worktree·PNPM·hard link 조합에서 우선순위를 낮춘다는 뜻이다.

5.2. T3 Code worktree 생성 및 공간

1. 작업 트리 하나의 생성 시간

   1. T3 Code 저장소에서 APFS는 약 1.26초가 걸렸다.
   2. Btrfs는 0.7초 미만이었다.
   3. ext4는 약 0.63초로 가장 빨랐고, XFS도 비슷했다.
   4. ZFS는 거의 8초로 의미 있게 느렸다.

2. 여러 작업 트리를 동시에 만들 때

   1. MacOS는 순차 생성에서 1.26초가 걸리고 8개를 병렬 생성하면 7.1초가 걸려 병렬 처리의 개선을 거의 얻지 못했다.
   2. ext4와 XFS는 병렬 생성에서 증가 폭이 약 5%에 그쳤다.
   3. ZFS는 병렬화에서 큰 손해를 보며 생성당 1초를 넘기는 수준으로 악화되었다.
   4. Btrfs도 0.6초대에서 2.1초로 급격히 느려지는 brutal한 병렬 penalty를 보였다.
   5. 에이전트가 여러 prompt를 동시에 처리하며 다수 worktree를 만드는 실제 상황에서는 Mac의 순차화 비용이 매번 대기 시간으로 전환된다.

3. 설치 전 작업 트리의 공간

   1. 깨끗한 T3 Code worktree에서 APFS는 약 240MB를 사용했다.
   2. Btrfs는 약 14MB만 사용해 큰 차이를 보였다.
   3. ext4와 XFS는 약 250MB로 APFS와 비슷했다.
   4. XFS+VDO는 약 128MB로 APFS보다도 적게 사용했다.
   5. ZFS는 약 20MB라고 표시되었지만 측정값이 너무 좋아 그대로 믿기 어렵다는 판단이 붙었다.

4. node_modules 설치 후 공간

   1. ext4는 linking 기능이 거의 없어 모듈을 실제로 복제해야 했고, T3 Code에서 반 GB를 훌쩍 넘어 거의 1GB에 가까워졌다.
   2. APFS는 일부를 공유해 약 150MB 정도만 증가했다.
   3. Btrfs도 설치 후 사용량이 크게 증가했다.
   4. XFS+VDO는 설치 후에도 APFS의 설치 전 clean worktree보다 적은 공간만 차지했다.
   5. 이 결과는 단순히 설치 전 숫자만 볼 것이 아니라, 실제 PNPM 의존성까지 설치한 뒤의 공간을 봐야 한다는 점을 보여준다.

5.3. Novox 벤치와 hard link

1. git clean과 PNPM install

   1. Novox의 bench는 여러 웹 프레임워크 boilerplate를 담은 monorepo에서 모든 npm module을 설치한 뒤 git clean으로 모두 삭제하는 시간까지 측정한다.
   2. 대상에는 MJS, Classic, Ember, Gatsby, Next, T3 등의 boilerplate가 포함된다.
   3. 왼쪽 숫자는 삭제(clean) 시간이고 오른쪽 숫자는 캐시에서 모듈을 설치하는 시간이다.
   4. 12코어 24스레드급 AMD Ryzen과 Ubuntu의 ext4는 clean 약 6초, install 약 4.5초였다.
   5. M1 Max와 APFS는 clean 약 31초, install 약 44초였다.
   6. 삭제는 약 5배, 설치는 약 10배 느린 결과다.
   7. Linux 시스템을 550MHz까지 throttle해도 install 결과가 M1 Max와 거의 비슷한 수준까지 떨어졌으며, 이는 CPU가 아니라 파일 시스템 병목임을 강하게 시사한다.

2. 후속 비교

   1. APFS는 Novox bench에서 install과 cleanup이 합쳐 약 39초 수준이었다.
   2. ext4는 cleanup 약 2.5초, install 약 9초였다.
   3. XFS는 cleanup 약 7초, install 약 9.5초였다.
   4. XFS+VDO는 해당 테스트에서 기본 XFS보다 약간 느렸다.
   5. ZFS도 이 테스트에서 좋은 결과를 보이지 않았다.

3. hard link를 켰을 때 나타난 APFS의 약점

   1. APFS는 link를 지원하지만 연결을 만드는 비용이 매우 커서 PNPM 설치가 약 40초에서 약 100초로 늘었다.
   2. Bun 설치 최적화를 시도하던 Bun creator Jared Sumner와 이 문제를 여러 차례 이야기했던 이유도 같은 APFS overhead다.
   3. XFS+VDO는 hard link cleanup이 3초 미만으로 끝났지만 ZFS는 5초를 넘겼다.
   4. 이 조합에서는 APFS, ZFS, Btrfs를 에이전트 개발용 우선 후보에서 제외하게 되었다.
   5. Mac에서 Linux 기본 Ubuntu로 옮기는 것만 해도 같은 작업이 100초에서 8초로 줄어드는 경우가 있었다.

6. 실제 작업에서 확인한 XFS+VDO의 효과

6.1. 저장 공간 절약

1. 파티션 교체의 상위 결과

   1. Linux 머신에서 XFS+VDO 파티션으로 바꾸자 사용 저장 공간이 44% 줄었다.
   2. 사실상 파일 시스템만 바꿔 드라이브 용량이 약 50% 늘어난 셈이다.
   3. plain XFS만 사용해도 약 10%의 개선이 있었다.
   4. 압축 계층의 CPU 비용이 전체 이득을 없앨 것이라는 예상은 실제 측정에서 틀렸다.

2. 125개 작업 트리 비교

   1. PNPM install이 완료된 worktree 125개를 만들면 stock ext4는 약 75GB를 사용했다.
   2. ext4는 동일한 내용을 파일 시스템 차원에서 공유하거나 압축할 방법이 부족해 모든 모듈을 반복 저장했다.
   3. plain XFS는 linking으로 ext4보다 나았지만 worktree별 파일을 여전히 복제해야 했다.
   4. Mac APFS는 약 43GB를 사용해 ext4의 75.5GB보다 의미 있게 적었다.
   5. XFS+VDO는 약 24GB만 사용해 ext4 대비 약 3분의 1로 줄였다.
   6. 많은 작업을 동시에 진행할수록 파일 단위 복사보다 CoW·link·압축의 누적 효과가 커진다.

6.2. 속도 개선

1. hard link PNPM에서 차이가 커진다

   1. Novox bench에서 ext4와 XFS 사이에 있던 삭제·재생성 성능 차이는 PNPM이 hard link를 사용할 때 거의 사라졌다.
   2. 해당 작업은 약 7초에서 2.85초로 줄었다.
   3. XFS+VDO가 공간을 절약하면서도 ext4에 가까운 성능을 낸다는 점이 핵심이다.

2. 매일 사용하는 T3 Code에서의 비교

   1. T3 Code에서 Command+Shift+O를 누르고 프로젝트를 고른 뒤 새 worktree를 생성하면, prompt가 즉시 네트워크로 전송되지 않는다.
   2. 먼저 저장소를 다른 디렉터리에 clone하고, PNPM install을 실행하고, 관련 스크립트를 끝낸 뒤에야 prompt가 실제 agent에게 전달된다.
   3. Linux의 XFS+VDO 환경에서는 이 과정이 사실상 즉시 끝났다.
   4. 같은 요청을 MacBook에서 실행하면 네트워크 hop이 전혀 없는데도 “waiting”이 반복되고 “still cloning” 상태가 오래 지속되었다.
   5. 개인 T3 Code 작업에서는 Mac의 10~12초가 Linux에서 2초 미만으로 줄었다.
   6. 매 prompt마다 발생하는 차이라서 한 번의 벤치마크 숫자보다 체감 영향이 훨씬 크다.

6.3. Wendell의 조언이 검증되다

1. 예상과 측정의 일치

   1. Wendell은 측정값을 보고 추천한 것이 아니라 파일 시스템 동작에 대한 경험으로 XFS+LZ4를 제안했다.
   2. 수많은 benchmark를 수행한 결과 그의 방향이 맞았고, 조언을 거의 그대로 따라도 될 정도라는 결론이 나왔다.
   3. Linux의 ext4만으로도 MacOS보다 훨씬 좋았지만, XFS+VDO로 옮기자 공간·속도·병렬 작업이 동시에 개선되었다.

2. 현재 개발 환경

   1. 에이전틱 개발 코드는 OS 드라이브와 분리된 Linux 머신의 XFS+VDO 포맷 드라이브에서 실행한다.
   2. 3.5TB 드라이브 중 약 10%만 사용한다.
   3. 파일 시스템을 옮기기 전 논리적으로 1TB가 넘던 데이터는 실제 이동 후 약 360GB로 줄었다.
   4. 이전 드라이브에 남겨둔 압축 백업 약 490GB는 충분히 검증한 뒤 삭제할 수 있을 정도로 여유가 생겼다.
   5. 일상적인 agent 개발 경험이 Linux 이동과 파일 시스템 변경을 통해 크게 좋아졌다.

7. Mac 사용자를 위한 대안: Rift by Anomaly

7.1. Rift의 아이디어

1. Mac에서 더 나은 worktree를 제공한다

   1. Rift는 Anomaly가 만든 git worktree 대안이며, T3 stack 초창기 creator 중 한 명인 Nexel에 대한 의리 때문에 따로 언급한다.
   2. 파일을 가상화해 agent가 일반 파일처럼 작업하게 한다.
   3. 새 파일을 즉시 실제 저장하지 않고, 다시 쓰기 작업이 발생할 때만 persist하는 copy-on-write 방식이다.
   4. 그래서 MacOS에서도 worktree clone이 즉시 끝나고 CLI가 매우 빠르게 반응한다.
   5. Bun이나 Node에서 직접 사용할 수 있다.

2. 지원 범위와 현재 상태

   1. 마지막으로 확인했을 때는 Mac 지원이 중심이었다.
   2. 현재는 Btrfs를 사용하는 Linux에서도 작동하는 것으로 보인다.
   3. 좋은 방향의 프로젝트라서 비슷한 도구가 앞으로 기본값이 되기를 기대한다.
   4. 다만 마지막 commit이 두 달 전이고 그 뒤로 수정이 없어 프로젝트가 사실상 멈췄을 가능성이 있다.
   5. 당장 쓸 수 있는 임시 해법으로는 의미가 있지만, 장기적으로는 활발히 유지되는 구현이 필요하다.

8. 결론과 실용적 시사점

8.1. 새 파일 시스템보다 목적에 맞는 조합

1. 에이전트 전용 파일 시스템은 아직 필요하지 않다

   1. 에이전트를 위해 파일 시스템을 처음부터 새로 만들 필요는 없다.
   2. 현재 기술도 각각 장점과 단점이 있으며, 조합을 잘 고르면 충분한 성능과 공간 효율을 얻는다.
   3. XFS+VDO와 가벼운 압축은 작은 파일·대량 clone·PNPM·hard link가 많은 개발 흐름에 실용적인 균형점이다.

2. 용도별 선택

   1. 일반적인 작은 파일 속도와 단순함이 우선이면 ext4가 APFS보다 훌륭한 출발점이다.
   2. worktree 공유, PNPM link, 공간 절약까지 원하면 XFS+VDO를 우선 검토한다.
   3. NAS·RAID·일반 파일 저장에는 Btrfs나 ZFS가 여전히 적합할 수 있다.
   4. 여러 운영체제에 번갈아 연결하는 이동식 드라이브에는 exFAT가 현실적이다.
   5. Mac을 계속 사용하면서 즉시적인 worktree를 원하면 Rift 같은 CoW 도구를 시험할 수 있지만 유지보수 상태를 먼저 확인해야 한다.

8.2. 개발자에게 권하는 운영 방식

1. 집에 남는 컴퓨터를 Linux 개발 호스트로 바꾼다

   1. AI 도구 활용을 극대화하려는 개발자는 집에 있는 오래된 컴퓨터 하나에 Linux를 설치하는 방법을 고려할 만하다.
   2. 별도 고성능 장비를 새로 살 필요 없이, T3 Code나 Claude의 remote 기능 등으로 Mac에서 Linux 개발 호스트에 접속할 수 있다.
   3. agent가 실제로 파일을 clone하고 install하는 곳을 Linux의 적합한 파일 시스템으로 옮기면 prompt 대기 시간이 줄어든다.
   4. 결과는 단순한 benchmark 개선이 아니라 매일 반복되는 개발 흐름 전체의 체감 개선이다.

2. 최종 판단

   1. MacBook의 CPU·SSD가 무조건 느린 것이 아니라 APFS가 현재의 에이전틱 개발 패턴에 불리한 절충을 갖는다.
   2. M1 Max와 550MHz로 제한한 Linux 장비가 비슷한 install 결과를 낸 것은 파일 시스템 병목의 강력한 증거다.
   3. XFS+VDO는 44%의 공간 절약, 125개 worktree에서 75GB에서 24GB로의 감소, 10~12초에서 2초 미만으로의 작업 단축을 함께 보여주었다.
   4. 여러 benchmark와 실제 T3 Code 사용 경험이 같은 방향을 가리키므로, 에이전트 개발을 많이 한다면 Linux 파일 시스템을 직접 시험해볼 가치가 충분하다.
   5. 파일 시스템이라는 주제가 평소에는 지루해 보이지만, agent가 충분히 강력해진 지금은 저장 장치 내부 구조가 개발 생산성의 직접적인 변수가 되었다.
   6. 오랜 시간 benchmark에 투자한 이유는 필요한 정보가 기존 자료에서 원하는 형태로 정리되어 있지 않았기 때문이며, 이 측정이 다른 개발자의 Linux·오픈소스 기반 agent 활용에 도움이 되기를 바란다는 결론으로 마무리된다.

주요 발언 모음

“Mac의 하드웨어가 느린 게 아니라, 우리가 하는 작업에 맞지 않는 파일 시스템 절충이 문제다.”

“550MHz로 제한한 Linux와 M1 Max의 설치 속도가 거의 같다는 것은 끔찍하지만, 동시에 병목이 어디 있는지를 아주 분명히 보여준다.”

“Wendell은 측정하지 않고도 XFS plus LZ4라고 말했다. 결국 Wendell이 맞았다.”

“새 파일 시스템을 에이전트만을 위해 처음부터 만들 필요는 없지만, 그런 시도가 나온다면 반대하지 않겠다.”

“Mac에서 100초를 기다리는 대신 Linux에서는 10초 만에 일을 시작할 수 있다.”

“파일 시스템에 대해 이야기할 구실로 에이전트를 써먹었다. 드디어 컴퓨터에 파일이 어떻게 저장되는지 이야기할 수 있게 됐다.”

핵심 데이터 & 수치

• 프로젝트 폴더 삭제: Mac 35초 초과, Linux 7초 또는 12초 미만.
• PNPM 캐시 설치: Mac 약 35초, Linux 설치·post-install 포함 10초 미만.
• Novox monorepo bench: AMD Ryzen의 ext4 clean 약 6초·install 약 4.5초, M1 Max의 APFS clean 약 31초·install 약 44초.
• 상대 격차: APFS는 삭제 약 5배, 설치 약 10배 느리다.
• CPU 제한 실험: Linux를 550MHz까지 낮춰도 M1 Max와 비슷한 install 속도가 나왔다.
• 단일 worktree 생성: APFS 약 1.26초, Btrfs 0.7초 미만, ext4 약 0.63초, ZFS 거의 8초.
• 8개 병렬 worktree: APFS 1.26초에서 7.1초로 증가, ext4·XFS는 약 5% 증가, Btrfs는 약 0.6초대에서 2.1초로 악화.
• 깨끗한 worktree 공간: APFS 약 240MB, Btrfs 약 14MB, ext4·XFS 약 250MB, XFS+VDO 약 128MB, ZFS 표시값 약 20MB.
• 125개 PNPM worktree 공간: ext4 약 75GB, APFS 약 43GB 또는 75.5GB 비교값, XFS+VDO 약 24GB.
• 파티션 교체 효과: XFS+VDO 사용 공간 44% 감소, plain XFS 약 10% 개선.
• hard link PNPM cleanup: 약 7초에서 2.85초로 단축.
• 개인 T3 Code 경험: Mac 10~12초에서 Linux 2초 미만으로 감소.
• 최종 저장소 상태: 3.5TB 드라이브의 약 10% 사용, 논리적 1TB 이상 데이터가 실제 약 360GB로 이동, 남겨둔 압축 백업 약 490GB.

결론 및 시사점

1. Mac의 하드웨어를 먼저 의심하지 말고 파일 시스템을 분리해 측정해야 한다.

   1. 캐시된 작은 파일 조작에서 APFS와 ext4·XFS의 차이를 직접 비교한다.
   2. network latency와 CPU 성능을 제거한 상태에서 cleanup, clone, install을 따로 잰다.

2. 에이전틱 개발의 핵심 벤치 항목은 작은 파일의 집단 작업이다.

   1. PNPM 설치, node_modules 삭제, git clean, 다중 worktree 생성, hard link를 같은 조건으로 반복한다.
   2. 단일 대형 파일의 sequential throughput만 보고 개발 환경을 선택하면 실제 agent 대기 시간을 놓친다.

3. Linux의 ext4는 간단하고 빠른 기본 해법이다.

   1. Mac에서 매번 수십 초가 걸리는 작업을 Ubuntu 기본 설치에서 몇 초로 줄일 수 있다.
   2. CoW와 압축이 필요하지 않은 경우에도 ext4만으로 큰 개선을 얻을 수 있다.

4. XFS+VDO는 속도와 공간의 균형을 제공한다.

   1. XFS의 파일 조작 기반 위에 VDO와 가벼운 압축을 더해 clone·link·중복 데이터의 실제 저장을 줄인다.
   2. 125개 worktree에서 수십 GB를 절약하면서 hard link cleanup도 빠르게 유지한다.

5. Mac을 포기하지 않아도 CoW 도구를 시험할 수 있다.

   1. Rift는 Mac에서 가상 파일과 지연 persist를 이용해 즉시적인 worktree를 제공한다.
   2. 프로젝트가 두 달째 업데이트되지 않은 상태라면 유지보수 위험을 평가한 뒤 사용해야 한다.

6. 오래된 PC 하나를 Linux remote 개발 호스트로 쓰는 전략이 실용적이다.

   1. T3 Code나 Claude remote 기능으로 Mac의 편의성과 Linux 파일 시스템의 작업 성능을 결합한다.
   2. AI agent를 많이 사용하는 개발자일수록 매 prompt마다 반복되는 clone·install 대기 시간을 줄이는 효과가 커진다.

핵심 요약 (20줄)

MacBook의 고가 CPU와 SSD가 느린 것이 아니라 APFS의 파일 처리 방식이 에이전틱 개발의 병목이 된다.

캐시된 PNPM 설치도 Mac에서는 약 35초가 걸리고 Linux에서는 post-install까지 10초 안에 끝난다.

프로젝트 폴더 삭제는 Mac에서 35초를 넘겼지만 Linux에서는 7초 또는 12초 미만으로 완료된다.

M1 Max의 APFS는 AMD Ryzen의 Ubuntu ext4보다 clean에서 약 5배, install에서 약 10배 느렸다.

Linux를 550MHz로 제한해도 M1 Max와 비슷한 설치 속도가 나와 CPU보다 파일 시스템이 원인임을 보였다.

SSD에는 폴더가 없고 데이터 블록과 위치를 기록하는 메타데이터가 폴더라는 환상을 만든다.

에이전트 개발은 작은 파일, node_modules, worktree, hard link를 대량으로 다뤄 일반 작업보다 파일 시스템 차이를 키운다.

좋은 개발용 파일 시스템은 삭제, clone, indexing, lookup, PNPM install을 모두 빠르게 처리해야 한다.

ext4는 단순하고 빠르지만 CoW와 풍부한 linking이 부족해 반복되는 의존성을 많이 복제한다.

XFS는 확장성이 높고 VDO 압축 계층과 결합해 링크와 중복 데이터의 저장 비용을 줄인다.

LZ4는 압축 해제와 저장에 드는 CPU 비용이 낮아 공간 절약과 성능을 함께 얻는 데 적합하다.

단일 T3 Code worktree는 APFS 약 1.26초, ext4 약 0.63초, Btrfs 0.7초 미만, ZFS 거의 8초였다.

125개 PNPM worktree는 ext4에서 약 75GB, APFS에서 약 43GB, XFS+VDO에서 약 24GB를 사용했다.

XFS+VDO 파티션으로 옮긴 뒤 전체 사용 공간이 44% 줄고 plain XFS도 약 10% 개선되었다.

개인 T3 Code 작업의 worktree 준비 시간은 Mac의 10~12초에서 Linux의 2초 미만으로 줄었다.

Btrfs와 ZFS는 NAS·RAID에는 유용하지만 이번 작은 파일 에이전트 작업에서는 우선순위가 낮았다.

Rift는 Mac에서 CoW 방식으로 즉시 worktree를 만들지만 최근 두 달 동안 commit이 없어 유지보수 위험이 있다.

AI 도구를 많이 쓰는 개발자는 집의 오래된 PC에 Linux를 설치해 원격 개발 호스트로 활용할 수 있다.

파일 시스템을 직접 벤치마크하면 하드웨어 교체보다 큰 생산성 개선과 저장 공간 절약을 발견할 수 있다.

상세 원고는 /Users/flowkater/Obsidian/flowkater/flowkater/Study/YouTube다이제스트/2026-08-22-t3dotgg-MacOS가느린게아니라파일시스템문제.md에 저장했다.