Mac 성능 병목 현상: 파일 시스템이 개발 워크플로를 지연시킨다

핵심 문제는 에이전트 워크플로 중 파일 작업이 받아들일 수 없을 정도로 느리다는 것입니다.

하드웨어 자체는 훌륭하지만, 특히 개발 관련 작업에 대한 소프트웨어 성능은 뒤처져 상당한 불만을 야기하고 있습니다.

폴더 삭제 속도를 직접 비교한 결과, 현저한 성능 차이가 드러났습니다. 프로젝트에서 여러 폴더를 삭제하는 데 Mac에서는 35초 이상이 걸렸습니다. 동일한 작업이 Linux 머신에서는 7~12초 이내에 완료되었습니다.

주목할 만한 점은 이 테스트에 사용된 Linux 머신이 Mac보다 강력하지 않았으며, Mac의 스토리지 하드웨어가 Linux 드라이브보다 본질적으로 빠르다는 것입니다. 이는 Mac의 소프트웨어 또는 파일 시스템 수준의 비효율성을 나타냅니다.

개발자들은 AI가 생성하는 경우가 많은 수천 줄 이상의 pull request(PR)로 인해 점점 더 많은 어려움을 겪고 있습니다. 이 엄청난 양으로 인해 병합된 코드의 품질에 대한 신뢰를 유지하기가 어렵습니다.

CodeRabbit과 같은 도구가 검토 프로세스를 간소화하는 데 도움이 되지만, 이러한 대규모 코드 변경 사항을 걸러내는 데 필요한 인간의 감독과 어려움을 완전히 대체할 수는 없습니다.

CodeRabbit은 pull request(PR) 검토를 개선하기 위한 '변경 스택'이라는 새로운 사용자 인터페이스 기능을 도입합니다. 이 새로운 UI는 코드 변경 사항을 알파벳 순서로 표시하는 대신 논리적 범주로 구성합니다.

이러한 범주화는 특히 탐색 및 데이터 가져오기 로직과 관련된 복잡한 변경 사항에 대해 명확성을 크게 향상시켜 개발자가 코드 수정의 구조와 의도를 더 쉽게 이해할 수 있도록 합니다.

PNPM 설치가 기존 파일에 연결하여 캐시를 활용하더라도 Mac에서는 거의 35초가 걸립니다.

대조적으로, 동일한 캐시된 작업은 Linux에서 일관되게 10초 이내에 완료됩니다. 이러한 상당한 차이는 기본 파일 시스템이 관찰된 느린 속도의 주요 원인이며 개발자 생산성을 저해한다는 것을 확인시켜 줍니다.

테스트는 개발 워크플로에서 일반적인 정리 및 설치 작업에 중점을 두었습니다.

결과에 따르면 M1 Max는 정리하는 데 31초, 설치하는 데 44초가 걸렸으며, 이는 Linux 설정에 비해 삭제 시간은 5배, 설치 시간은 10배 증가한 것입니다.

가장 기본적인 수준에서 SSD는 이진 데이터(1과 0)만 저장하며 폴더나 파일과 같은 개념을 본질적으로 이해하지 못합니다. 파일 시스템은 사용자 및 응용 프로그램에 조직된 구조의 환상을 제공하는 중요한 추상화 계층 역할을 합니다.

이 프로토콜은 어떤 데이터가 저장되고, 그 의미, 관리, 재작성 및 연결되는 방법을 추적하는 데 필수적이며, 사람이 이해할 수 있는 구조를 저수준 하드웨어 작업으로 효과적으로 변환합니다.

파일 시스템은 프로그래밍 언어와 유사하게 작동하며, 여기서 고급 명령어는 궁극적으로 물리적 드라이브에 저장된 1과 0으로 매핑되어야 합니다. 파일 시스템의 효율성과 성능은 이 매핑이 처리되는 방식과 드라이브의 원시 콘텐츠와 사용자 인터페이스 간의 다양한 추상화 계층에 따라 달라집니다.

파일 시스템은 파일 복사, 이동 및 연결과 같은 복잡한 작업을 관리하고 데이터 무결성 및 접근성을 보장하는 역할을 합니다.

여기에는 임시 파일 및 프로젝트 디렉터리를 정리하기 위한 삭제 속도와 버전 제어 시스템에서 새 작업 트리를 생성하는 데 필수적인 복제 속도가 포함됩니다.

효율적인 인덱싱은 시스템 검색 및 `ripgrep`와 같은 도구가 효과적으로 작동하는 데 중요하며, 소규모 파일 관리는 대부분의 파일 시스템에서 중요한 문제로 남아 종종 성능 병목 현상을 유발합니다.

최신 스토리지 시스템의 압축은 여러 계층을 포함하며 물리적 저장 공간과 런타임 성능 모두에 영향을 미칩니다. 압축은 디스크 공간 절약에 분명한 이점을 제공하지만, 성능에 미치는 영향은 별도의 고려 사항입니다.

실제 디스크 사용량을 정확하게 측정하는 것은 데이터 연결 및 내재된 압축과 같은 고급 기능으로 인해 더욱 복잡하여 진정한 스토리지 효율성과 I/O 오버헤드를 명확하게 파악하기 어렵습니다.

발표자는 APFS를 에이전트 기반 개발 워크플로에 '쓸모없다'고 표현하며, Mac에서는 그러한 작업을 거의 수행하지 않을 정도라고 강한 불만을 표했습니다. Btrfs는 고급 기능 때문에 대안으로 고려되었지만, 대규모 소규모 파일 복사 배치에서 성능이 좋지 않아 궁극적으로 제외되었습니다.

현재는 효율적인 copy-on-write 원시 기능이 부족함에도 불구하고 원시 소규모 파일 쓰기 성능 때문에 ext4가 선호됩니다. 이러한 선호는 일반적인 목적의 설계보다 개발자별 성능 요구 사항을 우선시하는 파일 시스템의 중요한 필요성을 강조합니다.

파일이 복사될 때 파일 시스템은 일반적으로 복제된 데이터를 저장하기 위해 디스크에 새롭고 사용 가능한 블록을 할당하고, 새 파일의 위치와 이름을 반영하도록 메타데이터를 업데이트합니다.

Linux 파일 시스템 중 ext4는 단순성과 최소한의 설계로 인해 다양한 파일 크기에서 빠른 성능을 제공하지만 일부 고급 기능이 부족합니다. XFS는 높은 확장성으로 특정 엔터프라이즈 환경에 적합한 것으로 알려져 있습니다.

ZFS 및 Btrfs는 고급 데이터 무결성 및 스냅샷 기능을 제공하는 기능이 풍부한 옵션이지만, 일반적인 데스크톱 사용보다는 복잡한 RAID 구성 및 엔터프라이즈 스토리지 솔루션을 위해 주로 설계 및 최적화되었습니다.

APFS는 작업 트리에 약 240메가바이트를 소비했습니다. 대조적으로 Btrfs는 약 14메가바이트만 사용했으며, 이는 압축 기능 덕분일 가능성이 높은 상당한 감소입니다.

XFS는 VDO(가상 데이터 최적화)와 함께 사용했을 때 128메가바이트를 사용했습니다. ZFS는 약 20메가바이트를 보고했지만, 이 결과는 정확성에 대한 회의적인 시각도 있었습니다. Ext4는 APFS와 유사하게 약 250메가바이트를 사용했습니다.

대조적으로 ext4는 정리를 2.5초, 설치를 약 9초 만에 완료하여 심각한 성능 격차를 드러냈습니다.

XFS 역시 훨씬 더 나은 성능을 보였으며, 정리하는 데 7초, 설치하는 데 9.5초가 걸렸습니다. XFS와 함께 구현된 VDO는 이러한 특정 벤치마크에서 유사한 성능 지표를 보였으며, APFS보다 지속적으로 우수했습니다.

Mac에서 약 100초가 걸리는 간단한 git 작업 트리 복제는 기본적인 Ubuntu 설치에서 단 10초 만에 완료될 수 있습니다.

이는 일상적인 작업에서 상당한 효율성 향상으로 이어집니다. Mac에서 이전에 10-12초가 걸렸던 작업이 이제 Linux 환경에서는 2초 이내에 완료됩니다. 이러한 큰 시간 차이는 하루 동안 누적되어 개발자 생산성에 심각한 영향을 미치고 집중적인 작업에 대한 Mac 경험을 눈에 띄게 느리게 만듭니다.

Linux 설정에서 이러한 작업은 거의 즉시 실행되어 유연하고 반응적인 개발자 경험을 제공합니다.

그러나 MacBook에서 네트워크 홉 없이 동일한 요청을 수행하면 상당한 지연 시간과 긴 복제 시간이 발생합니다. 관찰된 지연은 macOS가 이러한 유형의 집중적인 파일 작업에 어려움을 겪고 있음을 나타내며, 에이전트 워크플로에 대한 비효율성을 강조합니다.

Mac에서 발생하는 성능 병목 현상을 해결하기 위해 발표자는 대부분의 일일 코딩 워크플로를 홈 네트워크의 전용 Linux 박스로 전환했습니다. 이 설정은 비디오 압축 기능을 갖춘 XFS를 활용하여 훨씬 향상되고 반응적인 개발 환경을 제공합니다.

이러한 최적화는 또한 1테라바이트의 원시 데이터가 360기가바이트로 압축되는 놀라운 스토리지 효율성 향상으로 이어졌습니다. XFS 및 압축 기능을 갖춘 Linux 홈 서버로의 전환은 성능과 스토리지 관리 모두를 향상시키는 매우 효과적인 솔루션임이 입증되었습니다.