Mac에서 외장 SSD가 느려진 이유: Trim 문제

지난봄만 해도 40GB짜리 프로젝트 폴더를 900MB/s로 복사하던 외장 SSD가, 지금은 같은 작업에 11분이 걸립니다. 달라진 것은 아무것도 없습니다. 같은 케이블, 같은 포트, 같은 Mac, 같은 드라이브입니다. 그런데 그 폴더를 드라이브에서 다시 꺼내오면 여전히 순식간에 끝납니다. 읽기 속도는 예전 그대로입니다. 오직 쓰기만 무너졌습니다.

이 비대칭이 이야기의 전부입니다. 케이블 문제는 읽기와 쓰기를 함께 느리게 만듭니다. 포트 불량도 읽기와 쓰기를 함께 느리게 만듭니다. 발열로 인한 스로틀링은 모든 것을 느리게 만들었다가 인클로저가 식으면 회복됩니다. 읽기 속도는 멀쩡한데 쓰기 속도만 붕괴한 드라이브는, 잘 알려진 특정 고장을 보여주고 있는 것입니다. 미리 지워둔(pre-erased) 블록이 바닥났고, 어떤 블록을 지워도 되는지 아무도 알려주지 않는 상태입니다. 그것이 Trim 문제입니다.

답답한 것은 그다음입니다. Mac에서 Trim 상태를 확인하는 방법을 검색하면, 우리가 직접 게시했던 글을 포함해 수십 개의 사이트에서 똑같은 두 가지 조언이 반복됩니다. 확인하려면 system_profiler SPSerialATADataType | grep TRIM을 실행하라. 고치려면 sudo trimforce enable을 실행하라. 그런데 최신 Mac에서 첫 번째 명령은 아무것도 출력하지 않고, 두 번째 명령은 USB 드라이브에 아무런 영향도 주지 않습니다. 오타도 아니고, 폐기된 명령도 아니며, 적용되지 않았다는 오류 메시지조차 나오지 않습니다. 그저 조용히 무의미해질 뿐입니다.

이 가이드는 그 문제를 바로잡습니다. Trim이 실제로 하는 일과 그것이 없을 때 왜 쓰기만 벌을 받는지 설명하고, Trim 문제와 그것처럼 보이는 네 가지 다른 원인을 구분하는 방법을 보여주며, 두 가지 표준 확인 방법이 실패하는 이유를 (직접 실행해 실패를 확인할 수 있는 명령과 함께) 실증한 다음, Apple Silicon Mac에서 진짜로 작동하는 두 가지 확인 방법을 제시합니다. 이 글에서 테스트했다고 명시한 내용은 모두 macOS 26.5.2, 빌드 25F84를 실행하는 Apple Silicon Mac에서 확인한 것입니다.

핵심 요약

• 읽기와 쓰기의 비대칭이 곧 진단입니다 — The Eclectic Light Company의 Howard Oakley는 여기에 숫자를 붙입니다. “쓰기 속도가 읽기 속도의 20% 이하로 떨어졌다면, Trim 문제라고 확신해도 좋습니다.”
• sudo trimforce enable은 외장 드라이브의 해결책이 아닙니다 — 자체 man 페이지가 “AHCI 컨트롤러에 연결된 서드파티 드라이브”에 Trim을 활성화한다고 명시합니다. 즉 SATA 인터페이스를 말하는 것이므로 USB나 NVMe 드라이브에는 아무런 효과가 없습니다.
• system_profiler SPSerialATADataType은 Apple Silicon에서 아무것도 출력하지 않습니다 — 해당 데이터 타입 자체가 그 기기에 존재하지 않기 때문에, 인터넷에서 가장 많이 복사된 Trim 확인 명령은 빈 결과를 돌려주고 사람들은 그것을 마음대로 해석합니다.
• 실제로 작동하는 확인 방법은 system_profiler SPNVMeDataType과 마운트 시점의 통합 로그입니다 — APFS는 볼륨이 마운트될 때 Trim 스캔을 기록하므로, 드라이브를 뽑고 시간을 적어두고 다시 꽂은 뒤 즉시 로그를 읽어야 합니다.
• 유일한 치료법은 전체 지우기와 다시 포맷하기입니다 — 드라이브를 원할 때 트림하는 사용자용 명령은 없으며, 구매 전에 어떤 인클로저가 Trim을 통과시키는지 알려주는 호환성 목록을 Apple은 공개하지 않습니다.

Trim이 실제로 하는 일, 그리고 왜 쓰기만 피해를 보는가

소거 블록 문제

플래시 메모리에는 실리콘 단계에서부터 새겨진 비대칭이 있습니다. 어떤 페이지든 자유롭게 읽을 수 있습니다. 현재 지워져 있는 페이지에는 쓸 수 있습니다. 하지만 이미 데이터가 들어 있는 페이지에 덮어쓸 수는 없습니다. 재사용하려면 드라이브가 먼저 그것을 지워야 하는데, 소거는 페이지 단위로 일어나지 않습니다. 여러 페이지를 포함하는 훨씬 큰 단위인 소거 블록(erase block) 전체에 걸쳐 일어납니다.

Howard Oakley는 그 결과를 이렇게 잘라 말합니다. “SSD가 이미 사용 중이던 메모리 블록에 쓰려면 먼저 그것을 지워야 하는데, 소거-쓰기 사이클 시간은 형편없이 느립니다.”

메커니즘은 이것이 전부입니다. 이미 지워진 블록이 넉넉히 대기 중인 드라이브에서는 들어오는 쓰기가 단순한 프로그램 동작이 되어 드라이브의 정격 속도로 완료됩니다. 그런 블록이 하나도 없으면, 들어오는 모든 쓰기가 일련의 작업으로 바뀝니다. 낡은 페이지가 섞여 있는 블록을 찾고, 아직 유효한 페이지를 읽어내고, 그 유효한 페이지를 다른 곳에 쓰고, 블록 전체를 지운 다음, 마침내 새 데이터를 씁니다. 이 연쇄를 읽기-수정-쓰기(read-modify-write)라고 부르며, 깨끗한 쓰기보다 한 자릿수 이상 더 많은 시간을 잡아먹을 수 있습니다.

드라이브가 스스로 알아낼 수 없는 이유

여기서 사람들이 놀랍니다. 파일을 삭제해도 드라이브는 그 사실을 모릅니다. 파일 시스템은 자기 메타데이터를 갱신해 해당 논리 블록을 비어 있는 것으로 표시하지만, 드라이브 컨트롤러의 관점에서는 지금까지 쓰라고 지시받은 모든 논리 블록에 여전히 유효한 데이터가 들어 있습니다. 지난달에 지운 동영상이 담긴 블록과 지금 작업 중인 프로젝트 파일이 담긴 블록을 구분할 방법이 없습니다. 둘 다 보존해야 합니다.

Trim은 그 간극을 메우는 메시지입니다. 파일 시스템이 공간을 해제하면, 운영 체제가 더 이상 신경 쓰지 않는 논리 블록 주소를 나열한 Trim 명령을 보낼 수 있습니다. 드라이브는 그것들을 무효로 표시하고, 이후 백그라운드 가비지 컬렉션이 자유롭게 통합하고 지워서, 쓰기를 빠르게 유지해주는 미리 지워진 블록 풀을 쌓습니다.

Trim이 없으면 그 풀은 드라이브가 차오를수록 0을 향해 줄어들고, 그 뒤로는 영원히 0에 머뭅니다. 드라이브가 고장 난 것도 아니고 플래시 수명이 다한 것도 아닙니다. 몇 시간 전에 백그라운드에서 처리할 수 있었던 소거 사이클에 대부분의 시간을 쓰고 있을 뿐입니다.

읽기가 완벽하게 빠른 상태로 남는 이유

읽기에는 소거가 전혀 필요 없습니다. 읽기는 플래시 변환 계층에서의 조회 후 페이지에 대한 감지 동작일 뿐입니다. 드라이브가 진짜 살아 있는 데이터 100기가바이트를 담고 있든, 여섯 달 전에 논리적으로 삭제된 데이터 100기가바이트를 담고 있든, 요청한 페이지를 돌려주는 속도에는 아무 차이가 없습니다.

그래서 이 증상이 그토록 특징적이고, 또 믿을 만합니다. Trim 문제를 겪는 드라이브는 아픈 것이 아닙니다. 그 밖에 측정할 수 있는 모든 값은 정상으로 보입니다. S.M.A.R.T. 상태는 양호하고, 볼륨은 즉시 마운트되며, Disk Utility의 First Aid는 통과하고, 순차 읽기는 첫날과 같은 수치를 냅니다. 오직 쓰기 경로만 저하되어 있습니다. 지워진 블록을 손에 쥐고 있어야 하는 것은 쓰기 경로뿐이기 때문입니다.

한 번도 트림되지 않은 드라이브가 시간이 지나며 보이는 모습

이 열화는 선형적이지도, 즉각적이지도 않습니다. 사람들이 몇 달이 지나서야 알아채는 이유가 그것입니다.

새것이거나 방금 지운 SSD는 모든 블록이 소거 상태이므로 쓰기가 곧바로 통과합니다. 그 상태는 드라이브 전체 용량만큼 최소 한 번 쓰기가 이루어질 때까지 유지됩니다. 지금 Finder에서 얼마나 차 있어 보이는지보다 총 기록 바이트 수가 더 중요합니다. 어느 순간에도 400GB 이상을 담아본 적 없는 2TB 드라이브라도, 400GB 분량의 촬영 소스를 스무 번 돌렸다면 모든 물리 블록이 이미 손을 탄 상태일 수 있습니다.

그 지점을 넘어서면, Trim을 받는 드라이브는 삭제할 때마다 깔끔하게 회복합니다. 받지 못하는 드라이브는 결코 회복하지 않습니다. 컨트롤러는 지금껏 기록한 모든 블록을 유효한 것으로 표시해 두고, 오버프로비저닝 여유분(제조사가 따로 떼어둔 작은 예비 공간으로 보통 한 자릿수 퍼센트)만이 남은 유일한 자유 영역이 되며, 들어오는 모든 쓰기마다 읽기-수정-쓰기를 갈아냅니다.

그래서 드라이브는 6개월에서 18개월 동안 멀쩡해 보이다가, 몇 주 사이에 고통스러워집니다. 그 몇 주 동안 무슨 일이 벌어진 것이 아닙니다. 임계점을 넘은 것입니다.

증상의 지문: Trim 문제와 네 가지 유사 증상 구분하기

Mac에서 외장 드라이브가 느려지는 원인은 여러 가지이고, 드라이브를 쓴 지 1년 이내라면 그중 셋은 Trim보다 훨씬 흔합니다. 무엇이든 지우기 전에, 지금 보고 있는 것이 정말 그 고장인지 확인하십시오.

이 증상은 Apple 자체 지원 포럼에도 반복해서 스레드가 올라올 만큼 흔합니다. 토론 254727504 “Why is my external SSD so slow at writing?”과 토론 255040461 “Slow external SSD”가 그 예입니다. 테스트를 시작하기 전에 다른 사람들이 같은 문제를 어떻게 설명했는지 보고 싶다면 그쪽이 괜찮은 출발점입니다.

비율 테스트

최소 8GB짜리 큰 파일 하나를 양방향으로 각각 복사하면서 시간을 재십시오. 작은 파일이 잔뜩 들어 있는 폴더는 안 됩니다. 그것은 순수 처리량이 아니라 파일 시스템 오버헤드를 측정합니다. 큰 파일 하나입니다.

그런 다음 비교하십시오. 읽기와 쓰기가 둘 다 느리고 서로 비슷한 수준이라면 문제는 플래시가 아니라 연결에 있습니다. 읽기는 정상인데 쓰기가 그 일부에 불과하다면 Trim 영역에 들어선 것입니다. 붙잡아 둘 만한 기준은 Oakley의 임계값입니다. 읽기 속도의 20% 이하라면 확신하십시오.

증상 비교표

관찰되는 현상	가장 유력한 원인	확인 방법
쓰기는 느리고 읽기는 정상, 작년까지는 둘 다 멀쩡했음	Trim이 드라이브에 도달하지 못함	비율 테스트, 이어서 아래의 마운트 시점 로그 확인
읽기와 쓰기가 비슷한 배율로 함께 느림	케이블, 포트, 또는 정격 이하로 협상된 링크	케이블 교체, 다른 포트 시도, System Information에서 협상된 속도 확인
처음엔 빠르다가 20~60초 후 급락, 잠시 멈추면 회복	SLC 쓰기 캐시 소진 또는 발열 스로틀링	3분 이상의 단일 전송을 실행해 곡선을 관찰하고, 인클로저를 만져 보기
작은 파일이 많은 폴더에서만 느림	파일 시스템·메타데이터 오버헤드, Spotlight 인덱싱, 보안 소프트웨어	큰 파일 하나로 다시 시도, 그것이 빠르면 드라이브 문제가 아님
무작위 연결 끊김, “디스크가 올바르게 추출되지 않았습니다”, 복사 도중 드라이브 사라짐	버스 전원 또는 인클로저 전원 관리	연결 끊김부터 해결, 그전까지 모든 속도 측정은 신뢰할 수 없음
Disk Utility에는 보이는데 Finder에는 없거나, 두 번 표시됨	성능 문제가 아니라 마운트 계층 버그	속도 결함이 전혀 아니며, 지운다고 해결되지 않음
한 Mac에서는 느리고 다른 Mac에서는 빠름, 케이블은 동일	그 Mac의 포트, 허브, 또는 독	중간에 허브 없이 두 기기에 드라이브를 직접 연결해 테스트
첫날부터 늘 이 정도로 느렸음	Trim 문제가 아님. 실제로 SSD가 맞는지, 링크가 어떤 속도로 협상되는지 확인	새 드라이브는 모든 블록이 지워져 있어 아직 Trim 문제가 있을 수 없음

마지막 행은 강조할 가치가 있습니다. 이유 없이 드라이브를 지우는 일을 막아주기 때문입니다. 줄곧 느렸던 드라이브에는 Trim 문제가 존재할 수 없습니다. Trim 열화에는 이력이 필요합니다. 드라이브가 개봉 직후부터 느렸다면, 인클로저와 케이블, 그리고 링크가 값을 치른 만큼의 속도로 올라왔는지를 보십시오.

연결부터 배제하기

여기서 2분만 쓰면 불필요한 지우기를 피할 수 있습니다.

System Information을 열고(Option 키를 누른 채 Apple 메뉴를 클릭한 뒤 System Information 선택), USB 또는 Thunderbolt/USB4 항목에서 해당 드라이브를 찾으십시오. 상자에 인쇄된 속도가 아니라 링크가 실제로 협상한 속도를 확인하십시오. 10Gb/s를 낼 수 있는 드라이브가 충전용 케이블 탓에 480Mb/s 링크로 올라왔다면 양방향 모두 참담하게 느릴 것입니다.

system_profiler SPUSBHostDataType

이 명령은 각 연결 장치의 링크 속도를 포함해 같은 USB 트리를 텍스트로 덤프합니다. Thunderbolt를 쓰고 있다면 SPThunderboltDataType을 대신 사용하십시오. 두 데이터 타입 모두 Apple Silicon에 존재합니다. 다음 절에서 설명하듯이, 모두가 쓰라고 하는 그 데이터 타입에 대해서는 그렇게 말할 수 없습니다.

또한 결론을 내리기 전에 케이블을 바꿔 보십시오. USB-C 케이블은 실제로 지원하는 범위가 천차만별이며, 충전은 완벽하게 되는 케이블이 데이터는 USB 2.0 속도로 제한될 수 있습니다. 이 변수를 제거하는 데에는 비용이 들지 않고, “내 SSD가 느려졌다”는 제보의 상당수가 여기서 설명됩니다.

인터넷의 두 가지 표준 확인법이 최신 Mac에서 실패하는 이유

이 절이 가장 중요합니다. 여기서의 잘못된 조언은 단지 도움이 안 되는 정도가 아니기 때문입니다. 조용하고 비어 있고 오류도 없는 결과를 내놓아, 사람들이 그것을 답으로 착각하게 만들며 적극적으로 오도합니다.

trimforce는 거의 모두가 말하는 그 일을 하지 않습니다

직접 자기 Mac에서 man trimforce를 실행해 보십시오. man 페이지는 Apple Silicon의 macOS 26.5.2에도 여전히 존재하며, 이 조언이 사라지지 않는 이유 중 하나가 그것입니다. 내용은 다음과 같습니다.

NAME 줄은 이렇게 적혀 있습니다. “trimforce – enable TRIM commands on third-party drives.”

DESCRIPTION은 이렇습니다. “trimforce enables sending TRIM commands to third-party drives attached to an AHCI controller. By default, TRIM commands are not sent to third-party drives. Use extreme caution when enabling TRIM, as some drives may not correctly handle the commands. trimforce must be run by the system administrator.”

enable 동사는 이렇게 문서화되어 있습니다. “Start sending TRIM commands to AHCI-attached third-party drives. Requires a reboot to take effect.”

그리고 HISTORY 절은 이렇습니다. “The trimforce utility first appeared in OS X 10.10.4.”

DESCRIPTION을 다시 읽고 이 네 단어에서 멈추십시오. attached to an AHCI controller. AHCI, 즉 Advanced Host Controller Interface는 SATA 스토리지를 위한 표준 호스트 인터페이스입니다. USB가 아닙니다. NVMe도 아닙니다. Thunderbolt도 아닙니다.

trimforce가 2015년 OS X 10.10.4 시절에 만들어진 목적은 지금은 대체로 역사가 된 특정 상황입니다. 하드디스크나 Apple의 SATA SSD를 달고 출하된 Mac을 열어 서드파티 SATA SSD를 안에 설치했더니, macOS가 Apple이 인증하지 않은 드라이브에는 기본적으로 Trim 전송을 거부한다는 사실을 발견하는 경우입니다. trimforce는 그 거부를 무시하도록 합니다. 그것이 목적의 전부이며, “명령을 올바르게 처리하지 못할 수도 있는” 드라이브에 대한 경고가 있는 이유는 2015년에 트림 시 데이터를 잃을 수 있는 펌웨어 버그를 가진 SATA SSD가 실제로 있었기 때문입니다.

USB 인클로저에 든 외장 SSD에게 trimforce는 무관합니다. 경로에 AHCI 컨트롤러가 없습니다. 드라이브는 USB 대용량 저장장치 또는 UASP 브리지 뒤에 있고, Trim이 플래시에 도달하는지는 macOS의 스위치가 아니라 그 브리지 칩이 결정합니다. NVMe 드라이브라면 내장이든 Thunderbolt 인클로저에 있든 마찬가지로 무관합니다. NVMe 역시 AHCI가 아니기 때문입니다.

이 부분은 우리도 틀렸습니다. 우리가 앞서 쓴 macOS 외장 SSD 문제 해결 가이드는 외장 드라이브 성능을 다루는 절의 “Enable TRIM for Third-Party SSDs” 항목 아래에 sudo trimforce enable을 적어 두었습니다. 그 권고는 외장 드라이브에 대해 틀렸고, 이 글이 그것을 대체합니다. man 페이지는 2015년부터 지금 내용 그대로였는데, 우리가 충분히 꼼꼼히 읽지 않았습니다. 그 조언을 믿고 명령을 실행했더라도 나쁜 일은 일어나지 않았고, 좋은 일도 일어나지 않았습니다.

반사적으로 손대지 말아야 할 이유가 하나 더 있습니다. man 페이지가 스스로 “극도로 주의하라”고 한 것은 실재하는 실패 모드에 관한 이야기이고, 이 명령은 적용을 위해 재부팅을 요구합니다. 데이터 손실 경고가 문서화된 시스템 전역 스토리지 설정을 바꾸는 일을, 명시적으로 해당되지 않는 드라이브에 혹시 영향을 줄까 하는 기대로 감행하는 것은 어떤 확률로 따져도 나쁜 거래입니다.

system_profiler SPSerialATADataType은 빈 결과를 돌려줍니다

또 하나 보편적으로 반복되는 확인 방법은 이것입니다.

system_profiler SPSerialATADataType | grep TRIM

Apple Silicon Mac에서 이 명령은 아무것도 출력하지 않습니다. “TRIM Support: No”도 아닙니다. 정말 아무것도 없습니다. 그 이유는 Trim이 꺼져 있어서가 아닙니다. 해당 데이터 타입이 그 기기에 존재하지 않기 때문입니다.

명령 하나로 직접 확인할 수 있습니다.

system_profiler -listDataTypes | grep -i sata

Apple Silicon Mac에서는 일치하는 항목이 하나도 나오지 않습니다. 필터 없이 system_profiler -listDataTypes를 실행하면 그 기기가 실제로 가진 것이 보이며, 우리가 테스트한 Mac(macOS 26.5.2, 빌드 25F84)에서 스토리지 관련 항목에는 그중에서도 SPNVMeDataType, SPStorageDataType, SPThunderboltDataType, SPUSBHostDataType이 포함되어 있었습니다. SPSerialATADataType은 없습니다. Apple Silicon Mac에는 SATA 컨트롤러 자체가 아예 없기 때문입니다. 내장 SSD는 SoC에 연결된 NVMe이고, 기기 어디에도 사용자가 접근할 수 있는 SATA 버스는 없습니다.

그러니까 인터넷에서 가장 널리 복사된 Trim 확인 명령은, 최신 Mac에게 그 Mac이 갖고 있지 않은 하드웨어에 대해 묻고, 빈 답을 받아, 그 빈 답을 grep에 흘려보내고, grep은 성실하게 아무것도 찾지 못하는 것입니다. 오류도, 경고도, 무언가가 알아챌 만한 종료 코드도 없습니다. 사람들은 그것을 실행하고, 빈 출력을 보고, 이미 기울어 있던 쪽으로 결론을 내립니다.

실제 SATA 버스가 있는 Intel Mac에서는 이 명령이 작동하며 SATA 장치에 대한 Trim 상태를 보고합니다. 아직 그런 Mac을 쓰고 있다면 내장 드라이브에 대해서는 여전히 유용합니다. 다만 어떤 Mac에서도, USB로 연결된 외장 드라이브에 대해서는 한 번도 무언가를 알려준 적이 없습니다.

diskutil도 Trim 상태를 알려주지 않습니다

세 번째로 제안되곤 하는 변형은 Disk Utility나 diskutil에서 Trim 상태를 확인하라는 것입니다. 거기에는 없습니다.

diskutil info -all | grep -i trim

우리가 테스트한 Mac에서 이 명령은 아무것도 반환하지 않습니다. diskutil info -all은 시스템의 모든 디스크와 모든 볼륨에 대해 diskutil이 아는 모든 속성을 덤프하는데, Trim은 그 안에 없습니다. Disk Utility의 그래픽 정보 패널에도 표시되지 않습니다. 잘못된 창을 보고 있는 문제가 아닙니다. diskutil은 정말로 Trim 상태를 노출하지 않으므로, 거기서 읽을 수 있다고 암시하는 가이드는 일어나지 않는 일을 서술하고 있는 것입니다.

실제로 작동하는 확인 방법

방법은 두 가지이며, 어느 쪽이 적용되는지는 드라이브가 어떻게 연결되어 있느냐에 달렸습니다.

내장 및 NVMe 드라이브를 위한 system_profiler SPNVMeDataType

Mac의 내장 SSD, 그리고 macOS가 SCSI 변환 계층을 거치지 않고 직접 NVMe로 대화하는 Thunderbolt 또는 USB4 연결 NVMe 드라이브에 대해서는, macOS가 Trim 지원 여부를 보고하며 읽기도 쉽습니다.

system_profiler SPNVMeDataType

출력은 작은 들여쓰기 트리입니다. NVMExpress:로 시작해 컨트롤러 항목(Apple Silicon에서는 Apple SSD Controller:)이 오고, 그다음 드라이브 모델명이 제목으로 나옵니다. 우리가 테스트한 Mac에서 그 모델 제목 아래에 보고된 키는 다음 순서로 나타났습니다. Capacity, TRIM Support, Model, Revision, Serial Number, Detachable Drive, BSD Name, Partition Map Type, Removable Media, S.M.A.R.T. status, Volumes.

원하는 줄은 두 번째인 TRIM Support입니다. 우리가 테스트한 Mac의 내장 드라이브에서는 Yes로 표시되었습니다. 건강한 답이란 그런 모습이고, 이는 상황에 대한 Oakley의 요약과도 맞습니다. “Apple의 모든 내장 SSD는 Trim을 완전히 지원하며, NVMe 인터페이스를 가진 서드파티 외장 드라이브도 그래야 합니다.”

그 줄만 뽑아내려면 이렇게 하십시오.

system_profiler SPNVMeDataType | grep -A1 -i "capacity"

아니면 그냥 트리 전체를 읽어도 됩니다. 필터링할 가치가 거의 없을 만큼 짧습니다. 외장 NVMe 인클로저가 이 출력에 나타나기만 한다면 상황은 좋습니다. 여기에 나타난다는 것은 macOS가 USB 대용량 저장장치로 터널링하지 않고 NVMe로 직접 대화하고 있다는 뜻이기 때문입니다.

중요한 한계가 있습니다. 대부분의 USB 외장 SSD는 SPNVMeDataType에 아예 나타나지 않습니다. 인클로저 안의 SSD가 NVMe 모듈이더라도, USB 브리지는 그것을 USB 상의 SCSI 장치로 Mac에 제시하므로 대신 SPUSBHostDataType과 SPStorageDataType에 나타납니다. NVMe 목록에 없다는 것이 트림 여부에 대한 판정은 아닙니다. 이 방법으로는 그 질문에 답할 수 없다는 뜻일 뿐이고, 그때는 두 번째 방법이 필요합니다.

마운트 시점 로그 방법

이것은 연결 방식과 무관하게 APFS로 포맷된 모든 것에 통하는 확인 방법이며, Howard Oakley의 방법입니다. APFS가 관찰 가능한 특정 시점에 트리밍을 수행하기 때문에 통합니다.

APFS 볼륨이 마운트될 때, APFS 공간 관리자는 컨테이너에서 빈 블록을 스캔하고 그에 대해 Trim을 발행합니다. 그리고 자기가 한 일을 spaceman_scan_free_blocks로 시작하는 항목으로 통합 로그에 기록합니다. 트림된 컨테이너는 스캔과 함께 트림 활동을 보여줍니다. 트림되지 않은 컨테이너는 스캔 뒤에 (no trims)라는 표식을 보여줍니다.

그 한 문자열이 답입니다. 방금 마운트되었고 빈 공간이 있는 드라이브에서 (no trims)가 나온다면 Trim이 그 드라이브에 도달하지 못하고 있다는 뜻입니다.

절차는 이렇습니다.

1. 드라이브를 정상적으로 추출하십시오. Finder에서 마우스 오른쪽 버튼을 눌러 추출을 선택하거나 diskutil eject /dev/diskN을 사용하십시오. 그냥 케이블을 뽑지 마십시오.
2. 물리적으로 연결을 끊으십시오. 몇 초 기다리십시오.
3. 정확한 시각을 적어 두십시오. Mac이 쓰는 것과 같은 시계로, 초 단위까지. 터미널의 date가 정확히 알려줍니다.
4. 드라이브를 다시 연결하고 볼륨이 Finder에 나타나 마운트가 끝날 때까지 기다리십시오. 10~20초 정도 주십시오.
5. 연결 전후 구간의 로그를 읽으십시오.

log show --last 2m --predicate 'senderImagePath CONTAINS[c] "apfs"'

Oakley의 술어는 senderImagePath CONTAINS[c] "apfs"이며, 서브시스템 이름과 무관하게 APFS 코드가 내보낸 모든 것을 잡아냅니다. 시각을 적어 두었고 구간을 더 좁히고 싶다면, log show는 명시적 경계도 받습니다.

log show --start "2026-08-15 14:30:00" --end "2026-08-15 14:30:40" --predicate 'senderImagePath CONTAINS[c] "apfs"'

그래도 아무것도 나오지 않으면 정보 수준 항목까지 포함하도록 --info를 추가하고, 그래도 비어 있으면 그다음에 --debug를 추가하십시오. 이 플래그들은 매칭 대상을 바꾸는 것이 아니라 수준 필터를 넓힙니다.

그런 다음 결과에서 spaceman_scan_free_blocks를 검색하고, 테스트 중인 드라이브의 장치(disk5, disk6 등 diskutil list가 보여주는 이름)를 지목하는 항목을 찾아 (no trims) 표식이 있는지 보십시오. 디스크 번호가 테스트 중인 드라이브와 일치하는지 확인하십시오. 부팅 컨테이너와 마운트된 다른 APFS 볼륨도 각자의 항목을 내보내기 때문에 엉뚱한 것을 읽기 쉽습니다.

가동 시간이 이 확인을 망치는 이유

여기에 함정이 있고, 많은 사람이 이 방법을 시도해 보고 로그 방법은 안 통한다고 결론짓는 이유가 바로 이것입니다.

APFS의 Trim 메시지는 마운트 시점에만 기록됩니다. 주기적이지 않습니다. 매시간 뛰는 심장 박동 같은 것은 없습니다. 볼륨이 3주 전에 마운트되어 계속 마운트된 상태였다면, 그 Trim 항목은 3주 전에 기록되었고 로그의 보존 기간을 한참 지나 사라졌습니다.

우리는 정확히 이것을 테스트했습니다. 가동 시간이 21일인 Mac에서 다음을 실행했습니다.

log show --last 7d --predicate 'senderImagePath CONTAINS[c] "apfs"'

결과는 0줄이었습니다. TRIM Support: Yes를 보고하는 완벽히 건강한 내장 SSD를 가진 완벽히 건강한 기기에서, 일주일 치 로그 전체에 항목이 단 하나도 없었습니다. 부팅 볼륨은 3주 전 부팅 시점에 마운트되었는데 그것은 보존 구간 밖이고, 그 이후로 마운트된 것이 없었습니다.

따라서 --last 7d 질의의 빈 결과는 아무 의미가 없습니다. Trim이 고장 났다는 증거도 아니고, 작동 중이라는 증거도 아닙니다. 최근에 마운트된 것이 없다는 증거일 뿐입니다. 이 확인은 로그를 읽기 직전에 마운트 이벤트를 스스로 만들어야만 답을 냅니다. 뽑고, 시각을 적고, 다시 꽂고, 그다음 읽으십시오. 그 순서대로, 지체 없이.

터미널을 쓰고 싶지 않다면, Oakley의 도구들

Howard Oakley는 이 과정을 감싸는 무료 유틸리티 두 개를 제공합니다. Mints에는 마운트 전후의 로그 구간을 캡처하는 Disk Mount 기능이 있고, LogUI는 같은 술어를 인터페이스로 적용할 수 있는 범용 통합 로그 브라우저입니다. 둘 다 The Eclectic Light Company에서 받을 수 있습니다. log show 호출을 손으로 조립하고 싶지 않다면, 술어를 잘못 입력할 여지 없이 같은 일을 해줍니다.

읽기 대 쓰기를 정직하게 벤치마크하는 방법

비율 테스트는 측정의 질만큼만 유효하고, SSD에 대한 가벼운 벤치마크는 대개 안심시켜 주지만 아무 의미 없는 숫자를 만들어냅니다.

방금 지운 드라이브가 항상 멀쩡해 보이는 이유

드라이브를 지운 직후에 벤치마크하면 정격 속도가 나옵니다. 모든 블록이 지워져 있고, 모든 쓰기가 깨끗한 프로그램 동작이며, 벤치마크가 도는 동안 그것을 유지하는 데 Trim은 필요 없습니다. “포맷 직후에 속도 테스트를 돌렸는데 괜찮았다”는 말이 Trim 작동 여부에 대해 아무것도 알려주지 않는 이유가 이것입니다. Trim이 무관해지는 유일한 조건을 측정한 것입니다.

이 글 뒤쪽에서 설명할 치료법이 즉시 효과가 있는 것처럼 보였다가, 여전히 트림되지 않는 드라이브에서 몇 달 뒤 조용히 효력을 잃는 이유이기도 합니다.

의미 있는 것을 측정하려면 드라이브가 Trim이 중요해지는 상태, 즉 상당히 사용되었고 쓰기와 삭제의 실제 이력이 쌓인 상태여야 합니다.

실제 사용을 반영하는 테스트 만들기

이 목적에 맞는 정직한 벤치마크에는 네 가지 조건이 필요합니다.

큰 파일을 쓰십시오. 최소 8GB, 이상적으로는 드라이브의 SLC 캐시보다 크게. 소비자용 드라이브에서 SLC 캐시는 흔히 용량의 몇 퍼센트 수준입니다. 작은 파일 테스트는 메타데이터 처리를 측정하며 정작 보려는 플래시 동작을 가립니다.

드라이브를 절반 이상 채운 상태로 두십시오. 거의 빈 드라이브는 Trim 상태와 무관하게 쓸 수 있는 빈 공간이 있습니다. 지금 쫓고 있는 문제는 컨트롤러가 지워진 블록이 부족할 때 나타납니다.

대량 삭제 사이클 이후에 테스트하십시오. 큰 것을 삭제하고 휴지통을 비운 뒤 쓰십시오. 이것이 바로 Trim이 존재하는 이유가 되는 시나리오입니다. 파일 시스템은 비어 있다고 여기지만 드라이브는 알 수도 모를 수도 있는 공간 말입니다.

처음 몇 초가 아니라 지속 처리량을 테스트하십시오. 요즘 SSD는 모두 첫 버스트를 빠른 캐시로 흡수합니다. 전송을 3분간 지켜보며 어디로 수렴하는지 보십시오.

투박하지만 정직한 명령줄 측정

dd는 아무것도 설치하지 않고 숫자를 줍니다. 쓰기부터 하십시오.

dd if=/dev/zero of=/Volumes/YourDrive/speedtest.bin bs=1m count=8192

이 명령은 0으로 채운 8GB를 씁니다. 끝나면 dd가 전송된 바이트 수, 경과 시간, 초당 바이트 처리량을 담은 요약 줄을 출력합니다. 그 처리량을 적어 두십시오.

그런 다음 읽기 테스트가 RAM이 아니라 실제로 드라이브에서 읽도록 Mac의 디스크 캐시를 비우고, 파일을 다시 읽으십시오.

sudo purge
dd if=/Volumes/YourDrive/speedtest.bin of=/dev/null bs=1m

두 처리량 수치를 비교하십시오. 그런 다음 테스트 파일을 삭제하십시오.

한 가지 유의점이 있습니다. 일부 SSD 컨트롤러는 반복이 심한 입력을 압축하거나 중복 제거하는데, 순수한 0으로만 이루어진 파일은 가장 쉬운 경우이므로 /dev/zero를 쓰는 dd는 드라이브를 실제보다 좋게 보이게 할 수 있습니다. 그것을 피하려면 동영상 같은 실제 대용량 파일을 복사하며 시간을 재십시오. 그래픽 도구도 잘 작동합니다. Blackmagic Disk Speed Test는 몇 분에 걸쳐 값이 수렴하는 과정을 지켜볼 수 있는 연속 표시를 제공하므로 캐시 소진에 따른 급락을 알아보기 쉽습니다.

결과 읽기

같은 드라이브, 같은 케이블, 같은 포트, 같은 세션에서 쓰기 속도가 읽기 속도의 몇 퍼센트인지 계산하십시오.

80% 이상이면 아무 문제 없습니다. 플래시에서는 쓰기가 읽기보다 다소 느린 것이 정상이고 늘 그래 왔습니다.

40%에서 80% 사이라면 모호한 영역입니다. 초기 단계의 Trim 문제일 수도, 캐시가 소진된 드라이브일 수도, 발열 동작일 수도, 혹은 그 모델의 원래 성능일 수도 있습니다. 대량 삭제 사이클 이후에 다시 테스트하고, 마운트 시점 로그 확인을 실행하십시오.

20% 미만이면 Oakley의 말을 그대로 받아들여 Trim 문제로 취급하십시오. 그의 표현은 의도적입니다. 그 비율에서라면 “Trim 문제라고 확신해도 좋습니다.”

파일 시스템 선택: APFS, HFS+, 그리고 exFAT의 함정

드라이브를 어떤 파일 시스템으로 포맷했는지가, 하드웨어에 대한 어떤 질문보다 먼저 Trim이 시도되기라도 하는지를 결정합니다.

exFAT는 트림하지 않습니다

이것은 이 문제 전체에서 가장 쉽게 피할 수 있는 원인입니다. Oakley는 직설적으로 말합니다. “APFS와 HFS+는 보통 SSD가 마운트될 때마다 Trim을 수행하지만, ExFAT 같은 오래된 PC 파일 시스템으로 포맷된 드라이브는 아예 Trim되지 않을 가능성이 매우 높습니다.”

드라이브가 출하될 때 포맷되어 있는 것이 exFAT입니다. 추가 소프트웨어 없이 macOS와 Windows 양쪽에서 읽고 쓸 수 있는 유일한 형식이기 때문입니다. 또한 Mac과 PC 사이에서 드라이브를 옮겨야 할 때 사람들이 일부러 고르는 형식이기도 합니다. 그리고 그것은 어떤 인클로저에 들어 있든, 어떻게 연결되어 있든, 어떤 확인 결과가 나오든, 그 드라이브가 macOS로부터 Trim 명령을 결코 받지 못한다는 뜻입니다.

느려진 외장 SSD가 exFAT라면 답을 찾은 것이고 로그 확인을 실행할 필요도 없습니다. 스캔할 APFS 컨테이너 자체가 없으므로 그 드라이브에 대한 APFS 마운트 항목은 하나도 나오지 않습니다.

크로스 플랫폼의 맞교환

이 맞교환은 실재하며 공짜 답은 없으므로, 어느 쪽을 고르는지 분명히 하십시오.

포맷	macOS에서의 Trim	Windows 호환성	적합한 용도
APFS	예, 마운트할 때마다	기본 지원 없음, 서드파티 소프트웨어 필요	Mac 전용 드라이브, 최신 macOS의 Time Machine, 성능이 중요한 모든 용도
HFS+ (Mac OS Extended)	예, 마운트할 때마다	기본 지원 없음, 서드파티 소프트웨어 필요	구형 Mac, 레거시 워크플로, 아주 오래된 시스템과 함께 써야 하는 드라이브
exFAT	아니요	예, 기본 지원	성능 손실을 감수하는 진짜 크로스 플랫폼 공유

Mac과 Windows 기기 양쪽에 꽂아야 하는 드라이브가 정말로 필요하다면 exFAT가 실용적인 선택이고, 시간이 지날수록 쓰기 성능이 저하된다는 점을 받아들여야 합니다. 드라이브를 용량에 한참 못 미치게 유지하고, 아예 안 하는 대신 가끔씩 다시 포맷해서 완화하십시오. 하지만 크로스 플랫폼 접근이 매주 하는 일이 아니라 언젠가 필요할지도 모르는 것이라면 APFS로 포맷하십시오. 파일은 언제든 네트워크로 복사할 수 있고, 몇 년간 빠른 상태를 유지하는 드라이브가 가상의 편의보다 낫습니다.

HFS+는 트림되지만 시한부입니다

HFS+는 여전히 트림되고 여전히 작동합니다. 다만 Mac에서 장기적으로 좋은 선택은 아니며, 특히 암호화된 HFS+는 폐기 수순을 밟고 있습니다. HFS+ 외장 드라이브를 쓰고 있고 어차피 다시 포맷할 생각이라면, 지금이 APFS로 옮기기 좋은 시점입니다. 암호화된 HFS+ 볼륨을 APFS로 변환하기 가이드에서 마이그레이션 방법과 Time Machine 관련 영향을 다룹니다.

연결 방식 선택: USB 브리지 대 Thunderbolt와 NVMe

파일 시스템은 필요조건이지만 충분조건은 아닙니다. APFS 드라이브라도 Trim 명령이 물리적으로 플래시 컨트롤러에 도달해야 하고, 거기서 인클로저가 개입합니다.

브리지 칩이 해야 하는 일

USB 외장 SSD는 Mac과 직접 대화하는 드라이브가 아닙니다. 인클로저 안에는 USB와 스토리지 모듈이 쓰는 언어(SATA 또는 NVMe) 사이를 번역하는 브리지 칩이 있습니다. macOS는 스토리지 명령을 보통 UASP(USB Attached SCSI Protocol)를 사용해 USB 위의 SCSI로 보내며, Trim에 해당하는 SCSI 명령은 UNMAP입니다.

그래서 명령은 다음 연쇄를 살아남아야 합니다. APFS가 트림을 결정하고, macOS가 USB로 UNMAP을 발행하고, 브리지 칩이 그것을 받고, 브리지 칩이 그것을 SATA TRIM이나 NVMe Deallocate로 번역하고, 스토리지 모듈이 실행합니다. 브리지가 그 번역을 구현하지 않으면 명령은 버려집니다. 조용히. 어디에도 오류가 표면화되지 않으며, 바로 그래서 진단이 어렵고 로그 확인만이 유일하게 믿을 만한 판독 수단인 것입니다.

벤더 문서와 커뮤니티 테스트에서 일관되게 보고되는 상황은, USB 브리지를 통한 Trim 통과가 들쭉날쭉하다는 것입니다. 어떤 브리지는 UNMAP을 통과시키고 많은 브리지는 그러지 않으며, 드라이브 브랜드보다는 칩과 펌웨어 리비전에 따라 달라집니다. Thunderbolt와 네이티브 NVMe 경로가 신뢰할 수 있는 길입니다. 명령을 잃어버릴 번역 계층이 없기 때문입니다. 다시 Oakley의 요약입니다. “Apple의 모든 내장 SSD는 Trim을 완전히 지원하며, NVMe 인터페이스를 가진 서드파티 외장 드라이브도 그래야 합니다.” “그래야 한다”는 표현은 그의 것이고, 정직하게 제 몫을 하고 있습니다.

구형 SATA 드라이브가 가장 취약합니다. Oakley의 표현대로 “SATA 인터페이스를 가진 더 느린 드라이브들이 Trim을 지원하지 않을 가능성이 가장 높습니다.” 외장이 USB 캐디에 든 SATA SSD라면, 남는 2.5인치 SSD로 조립한 상당수 드라이브가 여기에 해당하는데, 존재하는 구성 중 가장 위험도가 높습니다.

Apple은 호환성 목록을 공개하지 않습니다

이 점은 구매 방식을 바꾸므로 분명하게 말해 두겠습니다. Apple은 macOS에서 Trim을 지원하는 외장 인클로저 목록을 공개하지 않습니다. 지원 문서도, 인증 하드웨어 페이지도, USB 연결 드라이브에 대해 그것을 보고하는 API도, System Information상의 표시도 없습니다. Apple은 외장 스토리지의 Trim 동작을 애초에 문서화한 적이 없습니다.

즉 특정 인클로저가 Trim을 통과시킬지를 구매 전에 확실히 알 방법이 없다는 뜻입니다. 제조사 마케팅도 믿을 만한 안내가 되지 못합니다. 대부분의 인클로저 벤더는 Trim에 대해 되든 안 되든 언급 자체를 하지 않기 때문입니다. 알아내는 유일한 방법은 사서, APFS로 포맷하고, 마운트 시점 로그 확인을 돌려 보는 것입니다.

이것은 정말로 개운치 않은 결론이며, 특정 칩셋이 macOS에서 Trim을 확실히 지원한다거나 확실히 지원하지 않는다고 말하는 사람은 확보된 근거보다 더 많은 주장을 하고 있는 것입니다. 칩 펌웨어 리비전은 서로 다르고, 인클로저 벤더는 모델 번호를 바꾸지 않은 채 내부 부품을 바꾸며, macOS 자체의 동작도 릴리스에 따라 달라져 왔습니다. 자기가 가진 드라이브를 테스트하십시오.

구매할 때 이것이 의미하는 바

호환성 목록이 없는 이상, 번역 문제가 애초에 존재하지 않는 구성을 우선하십시오. Thunderbolt 또는 USB4 NVMe 인클로저는 브리지를 방정식에서 제거하고, 덤으로 훨씬 높은 처리량을 제공합니다. 이미 연결 환경 쪽을 살펴보고 있다면, 우리의 Thunderbolt 5 독 구매 가이드가 현세대 하드웨어가 실제로 무엇을 제공하는지 다룹니다.

캐디와 여분의 드라이브로 조립하는 대신 주요 제조사의 완제품 포터블 SSD를 사는 편이 일반적으로 위험이 낮습니다. 벤더가 그 특정 모듈에 맞는 브리지를 고르고 검증했기 때문입니다. 보장은 아니지만 변수 하나는 줄어듭니다.

그리고 무엇을 사든, 반품이 아직 쉬운 첫 주에 테스트하십시오. APFS로 포맷하고, 데이터를 좀 복사해 넣고, 좀 지우고, 추출한 뒤 다시 연결해서 로그를 읽으십시오. 2분이면 알 수 있습니다.

치료법: 지우고 다시 포맷하기

원할 때 드라이브를 트림하는 명령은 없습니다

사람들은 “지금 내 드라이브를 트림해라” 같은 명령을 찾지만 그런 것은 없습니다. macOS는 요청 시 볼륨에 Trim을 발행하는 사용자용 방법을 제공하지 않습니다. trimforce는 앞서 확인했듯 AHCI에 연결된 서드파티 드라이브에 대한 시스템 정책을 토글할 뿐 여기에는 적용되지 않습니다. Disk Utility에는 그런 기능이 없습니다. diskutil에도 그런 동사가 없습니다.

드라이브를 거대한 파일로 가득 채운 뒤 삭제하라는 제안을 보게 될 수도 있습니다. 그것은 도움이 되지 않으며, Trim을 받지 못하는 드라이브에서는 컨트롤러가 유효하다고 여길 데이터를 더 쓰게 되므로 오히려 상황을 악화시킵니다.

남은 방법에 대해 Oakley는 모호하지 않습니다. “유일한 치료적 처치는 SSD를 완전히 다시 포맷하고 정상 쓰기 속도가 회복되는지 보는 것입니다.”

드라이브를 지우면 파티션 맵과 파일 시스템이 처음부터 다시 만들어집니다. 컨트롤러가 그것을 존중하는 드라이브에서는 지우기 자체가 사실상 블록을 자유 상태로 되돌리며, 드라이브는 제 속도로 돌아옵니다. 그래서 이 해결책은 진짜입니다. 그리고 근본적인 Trim 경로가 여전히 망가져 있다면 그것이 일시적인 이유이기도 합니다. 메커니즘을 고치지 않은 채 시계만 되돌린 것이기 때문입니다.

데이터를 먼저, 제대로 빼내십시오

지우기는 드라이브의 모든 것을 파괴하므로, Disk Utility에 손대기 전에 전부 복사해 내고 확인하십시오. “복사가 끝났다”가 아니라, 복사본에서 큰 파일을 포함해 여러 파일을 실제로 열어보고 온전한지 확인하십시오. 이 드라이브의 읽기는 여전히 빠르니 이 과정은 빨리 끝납니다. 이 고장 방식의 작은 자비입니다.

드라이브에 유일한 사본이 들어 있다면 먼저 다른 곳에 두 번째 사본을 만드십시오. Trim 문제가 있는 드라이브는 고장 나고 있는 것이 아니고 지우기 도중 죽을 가능성도 낮지만, 소중한 것을 사본 하나로만 두는 일은 절대 하지 마십시오. 그리고 드라이브가 Time Machine 대상이라면, 곧 백업 이력을 버리게 되는 것이므로 결정하기 전에 아래 Time Machine 절을 읽으십시오.

지우기 실행하기

Disk Utility를 사용하되, 기본 설정 하나를 먼저 바꾸십시오.

Disk Utility를 열고 보기 → 모든 기기 보기를 선택하십시오. 이것이 중요합니다. 그렇게 하지 않으면 Disk Utility는 볼륨만 보여주고, 볼륨을 지우면 컨테이너와 파티션 체계는 그대로 남습니다. 지워야 할 것은 물리 기기, 즉 사이드바에서 드라이브 모델명이 붙은 최상위 항목입니다.

그 최상위 기기를 선택하고 지우기를 클릭한 뒤 다음과 같이 설정하십시오.

• 방식: GUID 파티션 맵
• 포맷: exFAT를 써야 할 특별한 이유가 없다면 APFS

드라이브를 여러 번 덮어쓰는 보안 옵션 슬라이더는 사용하지 마십시오. SSD에서는 느리고, 아무 이득 없이 엄청난 양의 데이터를 쓰며, 지금 복원하려는 바로 그 블록 상태에 역행합니다.

명령줄을 선호한다면 동등한 방법은 이렇습니다.

diskutil list
diskutil eraseDisk APFS DriveName GPT /dev/diskN

먼저 diskutil list를 실행하고 출력을 주의 깊게 읽어 올바른 기기를 식별하십시오. 잘못된 diskN에 eraseDisk를 실행하면 엉뚱한 드라이브가 파괴되며, 확인 프롬프트는 없습니다.

그 후 무엇을 기대해야 하나

곧바로 벤치마크하면 빠를 것입니다. 그것이 증명하는 것은 플래시가 건강하다는 사실, 그 이상은 아닙니다.

진짜 시험은 이후 몇 달 동안 무슨 일이 일어나느냐입니다. 데이터를 다시 복사해 넣고 평소처럼 쓰다가, 드라이브가 실제 삭제·재기록 사이클을 겪은 뒤인 6~8주 후에 비율 테스트를 다시 실행하십시오. 쓰기 속도가 유지되고 있다면 Trim이 드라이브에 도달하고 있을 가능성이 크고 이번은 일회성이었던 것입니다. 같은 곡선으로 다시 저하된다면 인클로저가 Trim을 통과시키지 않는 것이고, 다시 포맷하기는 해결책이 아니라 주기적으로 해야 할 유지 보수입니다.

그 시점에서 결정은 경제적인 문제가 됩니다. 한 시간이면 다시 만들 수 있는 작업용 스크래치 디스크라면 주기적인 재포맷도 견딜 만합니다. 실사용 아카이브라면 견딜 수 없습니다. 드라이브가 중요하다면, 인클로저를 Thunderbolt나 NVMe 제품으로 교체하고 그 경로를 테스트하는 것이 지속 가능한 답입니다.

예방: 드라이브를 이 상태에 빠뜨리지 않기

여유 공간을 남기십시오

가장 효과적인 습관 하나입니다. 70% 이하로 유지되는 드라이브는 Trim이 없더라도 컨트롤러가 쓸 수 있는 여유 논리 공간이 있습니다. 한 번도 기록되지 않은 블록은 지워진 상태로 남아 있기 때문입니다. 98%까지 채워 써온 드라이브는 사실상 모든 블록이 손을 탄 상태이고 여유가 전혀 없습니다.

이는 내장 스토리지에도 적용됩니다. 부팅 SSD에도 같은 물리 법칙이 작용합니다. 다만 그쪽은 Trim이 작동한다는 것이 보장되어 있습니다. 우리의 저장 공간 관리 가이드가 꽉 차가는 Mac에서 공간을 찾아 회수하는 방법을 다룹니다.

가득 채우는 워크플로를 피하십시오

어떤 습관은 드라이브에 훨씬 가혹합니다. 카메라 촬영본으로 드라이브를 용량까지 채우고, 전부 옮긴 다음, 다시 채우는 것이 최악의 경우입니다. 손 타는 블록 최대, Trim 의존도 최대, 그리고 무한 반복입니다. 미디어 전문가들은 일반 사용자보다 훨씬 이른 시점에 이 고장 방식을 만나고, 드라이브 수명이 다한 것으로 오해하는 경우가 많습니다.

그런 작업을 한다면, Trim 통과가 확인된 드라이브를 쓰거나 프로젝트 사이에 재포맷 사이클을 계획하십시오. 드라이브 두 개를 번갈아 쓰면서 옮긴 뒤 각각 재포맷하는 것은 합리적인 작업 패턴이고, 비용은 프로젝트당 지우기 한 번입니다.

인클로저를 신중하게 고르십시오

진단이 아니라 예방의 관점에서 다시 말할 가치가 있습니다. 이것을 결정하는 것은 인클로저이지, 그 안의 SSD 모듈도 상자에 붙은 브랜드도 아닙니다. 작업 부하가 정당화한다면 Thunderbolt나 네이티브 NVMe를 고르고, 무엇을 고르든 첫 주에 테스트하십시오.

가끔 재검사하십시오

마운트 시점 로그 확인은 2분이면 됩니다. 중요한 외장 드라이브에 대해 1년에 한 번, 또는 macOS 메이저 업그레이드 후에 실행하면, 한 달 치 느린 전송을 치르기 전에 동작 변화를 잡아냅니다. 결과는 어딘가에 적어 두십시오. 어떤 드라이브가 3월에 깨끗하게 통과했다는 사실은 12월에 유용한 맥락이 됩니다.

Time Machine 대상 디스크와 부팅 가능한 클론

Time Machine이 최악의 경우인 이유

Time Machine 대상 디스크는 Trim 관점에서 거의 최대 스트레스 시나리오에 가깝습니다. 설계상 용량까지 차오르고, 자리를 만들려고 가장 오래된 스냅샷을 지우기 시작하고, 회수한 공간에 다시 쓰기를, 무한 반복합니다. 그것은 대량 삭제 뒤 대량 쓰기가 이어지는 연속적인 사이클이며, 빠른 속도를 유지하기 위해 Trim에 의존하는 바로 그 패턴입니다.

Trim을 받지 못하는 SSD 대상 디스크에서는 몇 달에 걸쳐 백업이 점점 느려집니다. 사람들이 보고하는 증상은 몇 분이면 끝나던 Time Machine 백업이 몇 시간씩 걸리거나, “백업 준비 중”이나 기록 중에 멈춘 것처럼 보인다는 것입니다. Time Machine을 탓하기 쉽고, 실제로 Time Machine에는 따로 배제해 볼 만한 진짜 문제도 많으며 우리의 Time Machine 문제 해결 가이드가 그것을 자세히 다룹니다. 하지만 대상 디스크가 SSD이고 읽기는 여전히 빠른데 쓰기만 기어간다면, Time Machine 자체 설정에 오후 한나절을 쏟기 전에 Trim을 의심하십시오.

복잡한 지점은 Time Machine 대상 디스크를 지우면 백업 이력이 파괴된다는 것입니다. 드라이브를 다시 포맷하면서 스냅샷을 유지할 방법은 없습니다. 선택지는 이력 손실을 받아들이고 새 백업을 시작하거나, 다른 드라이브에 새 대상 디스크를 구성한 뒤 새 백업이 자리를 잡으면 기존 것을 은퇴시키는 것입니다. 대부분의 사람에게는 두 번째가 드라이브 값을 치를 만합니다. 이력이 없는 백업은 몇 달치 버전을 가진 백업보다 훨씬 쓸모가 덜하기 때문입니다.

백업 전용 하드웨어 선택에 관한 참고 사항 하나. 이 경우는 일반 하드디스크가 나쁘지 않은 답이 되는 사례입니다. 회전식 디스크에는 소거 블록 문제도, Trim 요구도 전혀 없습니다. 명세상으로는 느리지만, 밤새 도는 증분 백업에서는 그것이 무의미한 경우가 많고, 수년간 채우고 지우기를 반복해도 동작이 저하되지 않습니다.

부팅 가능한 클론과 외장 부팅 볼륨

부팅 가능한 클론도 비슷하게 동작합니다. 클론 소프트웨어는 실행할 때마다 대량의 데이터를 다시 쓰므로, 대상이 트림되지 않고 있다면 클론 시간이 꾸준히 늘어납니다. 여기에는 한 가지 이점이 있는데, 클론 대상 디스크는 자주 마운트되고 언마운트된다는 점입니다. 덕분에 마운트 시점 로그 항목을 만들어내기가 아주 쉽습니다. 추출하고, 다시 연결하고, 로그를 읽으면 1분 안에 끝납니다.

복구 도구가 아니라 상시 작업 환경으로 외장 드라이브에서 macOS를 부팅한다면 걸린 것이 더 큽니다. 모든 시스템 쓰기가 같은 저하된 경로를 지나기 때문입니다. 특히 부팅 드라이브에 대해서는 USB 캐디보다 Thunderbolt NVMe 인클로저를 택해야 한다는 강력한 논거가 됩니다.

자주 발생하는 문제 해결

로그 확인이 아무것도 반환하지 않음

문제: APFS 술어로 log show를 실행했는데, 드라이브가 연결되어 있는데도 0줄이 나옵니다.

해결: 거의 확실히 마운트 이벤트를 먼저 만들지 않았거나, 만든 지 너무 오래 지난 뒤에 로그를 읽은 것입니다. 이 항목들은 볼륨이 마운트될 때만 기록됩니다. 드라이브를 추출하고, 물리적으로 연결을 끊고, date로 시각을 적어 두고, 다시 연결하고, 볼륨이 Finder에 나타날 때까지 15초를 기다린 다음, 그때에야 log show --last 2m을 실행하십시오. 그래도 비어 있으면 --info를 추가하고 다음으로 --debug를 추가해 수준 필터를 넓히십시오. 그래도 비어 있는데 드라이브는 분명히 마운트되었다면, 그 드라이브가 실제로 APFS인지 확인하십시오. exFAT 드라이브는 스캔할 APFS 컨테이너가 없으므로 APFS 항목을 전혀 만들지 않습니다.

system_profiler SPSerialATADataType이 아무것도 출력하지 않음

문제: 모든 사이트가 권하는 Trim 확인 명령이 아무 출력도 내지 않아, 그것이 Trim이 꺼져 있다는 뜻인지 알 수 없습니다.

해결: 둘 다 아닙니다. Apple Silicon Mac에는 그 데이터 타입이 존재하지 않습니다. system_profiler -listDataTypes | grep -i sata로 확인해 보십시오. 이것 역시 아무것도 반환하지 않습니다. 내장 및 NVMe 드라이브에는 system_profiler SPNVMeDataType을, 그 밖의 모든 것에는 마운트 시점 로그 방법을 사용하십시오. 이 기기들에서 빈 SATA 결과에 의미 있는 해석이란 존재하지 않습니다.

sudo trimforce enable을 실행했는데 아무 변화가 없음

문제: trimforce를 활성화하고 안내대로 재부팅했는데, 외장 드라이브는 이전과 똑같이 느립니다.

해결: 그것이 예상된 결과입니다. trimforce는 자체 man 페이지대로 AHCI(SATA) 컨트롤러에 연결된 서드파티 드라이브에 영향을 주며, USB나 NVMe 외장은 그에 해당하지 않습니다. 실행해서 망가진 것도 없고 고쳐진 것도 없습니다. 확인하고 싶다면 man trimforce를 실행해 DESCRIPTION을 직접 읽어 보십시오. 실제로 무슨 일이 벌어지고 있는지 알아내려면 마운트 시점 로그 확인으로 넘어가십시오.

드라이브가 TRIM Support: Yes인데도 쓰기가 여전히 느림

문제: system_profiler SPNVMeDataType이 그 드라이브에 대해 Trim 지원을 보고하는데도 쓰기 성능이 나쁩니다.

해결: Trim 지원이 보고된다는 것은 드라이브와 경로가 그 기능을 광고한다는 뜻입니다. 이 볼륨에서 실제로 트리밍이 일어나고 있는지를 확인해 주지는 않으며, 그것은 마운트 시점 로그 확인이 측정하는 것입니다. 그 확인을 다음 단계로 실행하십시오. 아울러 Trim이 아닌 원인들도 배제하십시오. System Information에서 협상된 링크 속도를 확인하고, 케이블을 바꾸고, 다른 포트에서 테스트하고, 3분간 지속 전송을 돌려 블록 고갈이 아니라 캐시 소진이나 발열 스로틀링을 보고 있는 것은 아닌지 확인하십시오.

처음 30초는 괜찮다가 무너짐

문제: 대용량 복사가 최고 속도로 시작했다가 중간쯤에서 70% 이상 떨어지는 일이 매번 반복됩니다.

해결: 이것은 대개 Trim 문제가 아니라 SLC 쓰기 캐시가 차는 현상이며, 소비자용 드라이브에서는 정상 동작입니다. 다만 Trim이 고갈된 드라이브는 급락 후의 바닥값이 더 낮게 나옵니다. 구분하려면 드라이브에 전원이 들어온 상태로 유휴 시간을 준 뒤 테스트하십시오. 캐시 관련 저하는 드라이브가 플러시할 시간을 갖고 나면 회복되지만, Trim 고갈은 회복되지 않습니다. 인클로저 온도도 확인하십시오. 뜨거워진 브리지 칩이나 NVMe 모듈은 심하게 스로틀링되며 밖에서 보기에는 똑같이 느껴집니다.

작은 파일은 느린데 큰 파일은 빠름

문제: 수천 개의 작은 파일이 든 폴더를 복사하는 데, 같은 총용량의 파일 하나를 복사할 때보다 훨씬 오래 걸립니다.

해결: Trim 문제가 아닙니다. 작은 파일 전송에서는 파일당 오버헤드가 지배적이며, Spotlight 인덱싱이나 보안 소프트웨어가 파일이 도착할 때마다 검사하면 상황이 극적으로 악화됩니다. 깨끗한 처리량 수치를 얻으려면 큰 파일 하나로 테스트하십시오. 큰 파일 쓰기가 정상이라면 플래시는 멀쩡합니다. 작은 파일에 대한 손해를 줄이려면 시스템 설정 → Siri 및 Spotlight → Spotlight 개인 정보 보호에서 해당 드라이브를 제외하거나, 폴더를 단일 아카이브로 묶어 전송하는 방법을 고려하십시오.

지우기로 고쳐졌지만 몇 달뿐이었음

문제: 재포맷으로 속도가 완전히 돌아왔는데, 몇 달이 지난 지금 같은 곡선으로 쓰기가 다시 저하되었습니다.

해결: 재포맷은 증상을 다룬 것입니다. 재발은 Trim이 이 드라이브에 정말로 도달하지 않고 있다는 뜻이며, 쓰기와 삭제의 이력이 다시 쌓이는 순간 블록 풀이 또 고갈됩니다. 재포맷한 드라이브에서 마운트 시점 로그 확인을 실행해 (no trims)가 있는지 보고 확인하십시오. 확인되었다면 현실적인 선택지는 주기적 재포맷을 유지 보수로 받아들이거나, SSD 모듈을 Thunderbolt 또는 NVMe 인클로저로 옮기고 그 경로를 테스트하는 것입니다. 결과를 바꿔줄 소프트웨어 설정은 없습니다.

드라이브가 무작위로 연결이 끊기기도 함

문제: 느린 쓰기와 함께 드라이브가 스스로 추출되거나, “디스크가 올바르게 추출되지 않았습니다” 알림이 반복해서 뜹니다.

해결: 이 둘을 별개의 결함으로 취급하고 연결 끊김부터 고치십시오. 불안정한 연결은 모든 측정을 신뢰할 수 없게 만들고, 쓰기 도중 볼륨을 손상시킬 수 있습니다. 연결 끊김은 대개 플래시 문제가 아니라 전원이나 버스 문제입니다. 허브에 물린 버스 전원 드라이브, 공격적인 인클로저 절전, 또는 아슬아슬한 케이블이 원인입니다. 우리의 디스크가 올바르게 추출되지 않았습니다 오류와 USB 전원 가이드가 구체적인 원인들을 다룹니다. 드라이브가 안정적으로 연결을 유지하게 되면, 돌아와서 비율 테스트를 다시 하십시오.

FAQ

sudo trimforce enable이 외장 USB SSD에 도움이 되나요?

아닙니다. man 페이지는 AHCI 컨트롤러에 연결된 서드파티 드라이브, 즉 SATA 인터페이스에 대해 Trim을 활성화한다고 명시합니다. USB 외장 드라이브는 USB 브리지를 거쳐 Mac에 닿고, NVMe 드라이브도 AHCI가 아닙니다. 이 명령은 구형 Mac 내부에 설치한 서드파티 SATA SSD에 적용될 뿐, 그 밖의 어디에도 적용되지 않습니다.

왜 제 Mac에서 system_profiler SPSerialATADataType이 아무것도 반환하지 않나요?

Apple Silicon Mac에는 SATA 컨트롤러가 없어서 그 데이터 타입 자체가 존재하지 않기 때문입니다. system_profiler -listDataTypes | grep -i sata로 직접 확인해 보십시오. 일치 항목이 하나도 없습니다. 빈 출력은 Trim이 비활성화되어 있다는 보고가 아닙니다. 하드웨어 범주 자체가 없다는 뜻입니다.

Disk Utility나 diskutil로 Trim 상태를 확인할 수 있나요?

아닙니다. diskutil info -all | grep -i trim은 아무것도 반환하지 않습니다. diskutil이 보고하는 속성 중에 Trim 상태가 없기 때문이고, Disk Utility의 정보 패널에도 표시되지 않습니다. 그렇지 않다고 암시하는 가이드는 macOS가 제공하지 않는 것을 서술하고 있습니다. 대신 system_profiler SPNVMeDataType이나 마운트 시점 로그 확인을 사용하십시오.

Trim 문제와 불량 케이블을 어떻게 구분하나요?

같은 세션에서 같은 드라이브에 대해, 최소 8GB짜리 파일 하나로 읽기 속도와 쓰기 속도를 비교하십시오. 케이블이나 포트 문제는 양방향을 비슷한 배율로 느리게 만듭니다. Trim 문제는 읽기를 최고 속도로 남겨둔 채 쓰기만 붕괴시킵니다. Howard Oakley의 기준은 쓰기가 읽기의 20% 이하일 때입니다.

드라이브를 지우면 느린 쓰기가 영구적으로 해결되나요?

즉시 속도는 완전히 회복됩니다. 지우기가 플래시를 사전 소거 사이클 없이 쓸 수 있는 상태로 되돌리기 때문입니다. 그것이 지속될지는 평소 사용 중에 Trim이 드라이브에 도달하는지에 달려 있습니다. 도달한다면 문제는 재발하지 않아야 합니다. 도달하지 않는다면 몇 달 안에 같은 저하를 다시 겪을 것입니다.

Mac에서 외장 SSD에 exFAT가 정말 그렇게 나쁜가요?

시간에 따른 성능 측면에서는 그렇습니다. exFAT는 드라이브를 트림하지 않으므로, 인클로저나 연결 방식과 무관하게 exFAT SSD는 쓰기 이력이 쌓일수록 반드시 저하됩니다. Windows 기본 접근이 정말로 필요할 때만 exFAT를 고르고, 그렇게 한다면 드라이브를 용량에 한참 못 미치게 유지하고 주기적으로 다시 포맷하십시오.

결론

읽기는 최고 속도인데 쓰기만 느린 외장 SSD는, 명령을 하나 실행하기도 전에 이미 무엇이 잘못되었는지 알려준 것입니다. 그 비대칭은 미리 지워둔 블록이 바닥났고 어떤 블록을 회수해도 되는지 듣지 못한 드라이브의 지문입니다.

이것을 진단하기 어려운 이유는 메커니즘이 미묘해서가 아닙니다. 인터넷이 합의한 두 가지 확인법이 최신 Mac에서 둘 다 조용히 실패하기 때문입니다. system_profiler SPSerialATADataType은 Apple Silicon에 없는 하드웨어 범주를 조회하고 빈 결과를 돌려줍니다. sudo trimforce enable은 AHCI에 연결된 SATA 드라이브를 위한 정책을 토글할 뿐 USB 외장에는 손댈 수 없다고, 자체 man 페이지가 첫 문단에서 말하고 있습니다. 둘 중 어느 것도 오류를 보고하지 않습니다. 그 침묵이 잘못된 조언을 계속 돌게 만들고, 우리가 앞선 가이드에서 그것을 되풀이했던 이유이기도 합니다.

통하는 방법은 더 좁습니다. 내장 드라이브와 NVMe 외장에 대해서는 system_profiler SPNVMeDataType이 TRIM Support를 직접 보고합니다. APFS로 포맷된 모든 것에 대해서는 드라이브를 추출하고, 시각을 적고, 다시 연결하고, 마운트를 기다린 다음, 통합 로그에서 spaceman_scan_free_blocks 항목을 읽고 (no trims) 표식을 찾으십시오. 그 순서대로, 지체 없이 하십시오. 그 항목들은 마운트 시점에 기록되고 그 외에는 어디에도 기록되지 않기 때문입니다. 우리가 테스트한 기기에서는 가동 시간 3주에 일주일 치 로그 전체에 그런 항목이 하나도 없었습니다.

확인 결과가 나쁘게 나온다면 치료법은 전체 지우기와 다시 포맷하기이며, 그것을 대신할 사용자용 명령은 없습니다. 그 해결이 유지될지는 인클로저에 달렸고, Apple은 외장 인클로저의 Trim 호환성 목록을 공개하지 않으므로, 알아내는 유일한 방법은 다시 포맷하고, 두어 달 써 보고, 다시 측정하는 것입니다. 같은 곡선으로 저하된다면 인클로저가 명령을 버리고 있는 것이고, 지속 가능한 답은 소프트웨어에서 할 수 있는 어떤 변경도 아닌 Thunderbolt 또는 네이티브 NVMe 경로입니다.

이번 주에 세 가지를 하십시오. 주력 외장 드라이브에 대해 큰 파일 하나로 양방향 비율 테스트를 실행하십시오. 비율이 이상하게 나오면, 드라이브가 아직 저하된 상태일 때 마운트 시점 로그 확인을 실행하십시오. 그래야 그냥 고치는 데 그치지 않고 무언가를 알게 됩니다. 그리고 Mac 전용 외장 드라이브는 exFAT가 아니라 APFS로 포맷하십시오. 그 결정 하나가 Trim이 시도되기라도 하는지를 결정합니다.

추가로 읽어볼 글: macOS 외장 SSD 문제 해결 가이드 · Time Machine 완전 문제 해결 가이드