Mac 최적화 앱: 한 단어 뒤에 숨은 세 가지 다른 작업

서로 무관한 세 가지 작업이 "최적화"라는 한 단어에 묶여 팔리고 있고, 그래서 최적화 앱을 써도 바뀌는 게 없는 경우가 많습니다. 하나는 저장 공간 문제입니다. 하나는 물어본 적도 없는데 뭔가 돌아가고 있는 문제입니다. 하나는 고장난 서브시스템을 고치는 문제입니다. 셋은 증상도 다르고 원리도 다르고 필요한 도구도 다릅니다. 멀쩡한 Mac에 셋을 다 돌리면 오히려 더 느려질 가능성이 큽니다. 지금 내 상황이 어느 쪽인지는 이미 기기에 있는 소프트웨어만으로 몇 분이면 가려낼 수 있으니, 먼저 이 세 가지를 구분하는 것부터 시작합니다.

하나의 단어를 나눠 쓰는 세 가지 작업

용량 회수는 성능 문제로 위장한 저장 공간 문제입니다. Mac이 느린 건 지저분해서가 아니라, macOS가 쓰기 작업 하나하나를 처리하려고 추가로 일을 더 하고 있기 때문입니다.

상주 부하 제거는 여러분이 열지도 않았는데 존재하는 프로세스, 즉 로그인 항목, 백그라운드 도우미, launchd 에이전트, 업데이터, 브라우저 헬퍼를 다루는 일입니다. 효과는 실제로 있지만 한정적입니다. 최고 속도가 아니라 로그인 시간과 유휴 전력 소모에서 나타납니다.

정상 동작 복구는 수리 작업을 가리킵니다. Spotlight 재색인, DNS 캐시 비우기, 멈춘 미리보기 캐시 초기화 같은 것들입니다. 이런 작업은 속도를 더해주는 게 아니라 잘못 답하고 있던 서브시스템을 고치는 것뿐이니, 멀쩡히 돌아가는 Mac에 실행하면 그냥 손해입니다.

용량: 성능 문제로 위장한 저장 공간 문제

APFS는 copy-on-write 방식입니다. 파일을 수정해도 기존 블록을 그 자리에서 덮어쓰지 않습니다. 새 블록을 할당하고 메타데이터를 다시 가리키게 만드니, 파일 크기가 커지지 않아도 큰 파일을 편집하려면 여유 블록이 필요할 수 있습니다. 스냅샷이 존재하는 동안에는 예전 블록도 계속 참조된 상태로 남습니다. macOS는 또 스왑, 임시 파일, 시스템 업데이트를 통째로 준비해두는 스테이징 복사본을 위한 공간도 필요로 합니다. 다운로드 용량보다 여유 공간이 더 많은 볼륨에서도 업데이트 설치가 거부되는 이유가 여기 있습니다.

공간이 빠듯해지면 할당이 더 이상 즉각적이지 않습니다. 시스템이 먼저 회수 작업부터 하기 때문입니다. 캐시를 몰아내고, 대상이 되는 스냅샷을 줄이고, 최적화된 클라우드 콘텐츠를 비웁니다. 여러분의 쓰기 작업이 끝나기도 전에 실제 I/O가 발생하는 겁니다. 플래시 저장 장치는 그 아래에서 두 번째 효과를 더합니다. 쓰기 단위보다 훨씬 큰 단위로 지워지기 때문에, 여유 블록이 얼마 없는 컨트롤러는 지우기 전에 유효한 데이터부터 정리해야 합니다. 이 계층은 macOS에서 보이지 않으니, 공간을 아슬아슬하게 쓰지 말아야 할 이유로 받아들이세요.

어디서나 볼 수 있는 규칙은 10퍼센트, 15퍼센트, 혹은 20퍼센트를 비워두라는 겁니다. 이 중 어느 것도 Apple의 공식 기준이 아니고, Apple은 "시동 디스크 공간이 거의 다 찼습니다" 알림이 언제 뜨는지도 공개하지 않습니다. 퍼센트 대신 정직하게 대체할 수 있는 건 할당량입니다. 여러분이 평소에 하는 일 중 가장 큰 것 하나를 위한 공간을 남겨두는 겁니다. 대부분에게 그건 macOS 업데이트가 스스로를 준비하는 과정입니다.

df -h /
diskutil info / | grep -i "Container"

수치를 적어두고, 한 가지를 바꾼 뒤, 다시 읽어보세요. 판단 기준은 비율이 아니라 원래 실패하던 작업 그 자체입니다. Mole에서 같은 일을 하는 건 Analyze입니다. 볼륨을 트리맵으로 그려서 무엇이 공간을 차지하는지 추측이 아니라 사각형으로 보여주고, 이름을 댈 수 있는 캐시 후보는 Clean이 맡습니다. 수동으로 하는 방법은 큰 파일 찾기에 있습니다.

상주 부하: 열지도 않았는데 돌아가는 것들

여기서는 네 종류가 하나로 뭉뚱그려집니다. 로그인할 때 열리도록 설정된 앱, Service Management를 통해 등록된 백그라운드 항목, 각자의 plist를 가진 launchd 에이전트와 데몬, 그리고 앱이 스스로 띄우는 헬퍼(브라우저의 사이트별 렌더러 같은 것들)입니다.

"종료했는데 다시 돌아왔다"가 정상인 이유

launchd는 모든 백그라운드 작업을 계속 돌리고 있지 않습니다. 대부분은 조건을 등록해두고 기다립니다. 들어오는 소켓 연결, 감시 중인 경로의 변화, XPC 요청, 정해진 시간 간격 같은 것들이죠. 조건이 충족되면 launchd가 작업을 시작하고, 작업이 유휴 상태가 되면 종료를 허용합니다. 그러니 실행 중인 목록은 하루 종일 바뀌고, 이런 프로세스 중 하나를 강제 종료해봤자 다음 트리거가 오면 다시 시작될 뿐입니다.

그러니 프로세스를 죽이는 건 최적화가 아닙니다. 시스템 설정 > 일반 > 로그인 항목 및 확장 프로그램에서, 또는 해당 앱의 환경설정에서 항목을 끄고, 그 항목이 제공하던 기능을 테스트해 보세요.

launchctl print-disabled가 실제로 보여주는 것

launchctl print-disabled gui/$(id -u)

disabled services = {
    "com.raycast.macos.RaycastLauncher" => enabled
    "com.apple.Siri.agent" => disabled
    "ddddxxx.LyricsXHelper" => enabled
}

명령어 이름과 달리, 이건 비활성화된 서비스의 목록이 아닙니다. 하나의 도메인에 대한 영구 재정의 데이터베이스입니다. 명시적으로 활성화 또는 비활성화 결정이 기록된 모든 label과, 그 결정이 무엇이었는지를 담고 있습니다. 대부분의 항목은 enabled로 나오고, label이 목록에 없다는 건 재정의 기록이 없다는 뜻일 뿐, 설치되지 않았다는 뜻은 아닙니다.

그러니까 이 명령어는 "지금 무엇이 실행 중인가"가 아니라 "나 또는 앱이 명시적으로 무엇을 껐는가"에 답합니다. launchctl print gui/$(id -u)는 현재 사용자 도메인을 읽기 전용으로 보여주는 명령이고, 여기 나오는 서비스 label이 항상 파일 이름이나 앱 이름과 일치하는 건 아니니, 프로세스 이름만 보고 plist를 추측해서 지우면 안 됩니다. 전체 절차는 시작 프로그램 비활성화하기에 있습니다.

얻는 게 뭔지 솔직하게 봅시다. 유휴 상태인 헬퍼 네 개를 정리해서 얻는 건 조금 더 빠른 로그인과 약간 낮은 대기 전력이지, 더 빠른 빌드가 아닙니다. 그리고 백업 에이전트나 동기화 클라이언트는 대개 그 비용을 감수할 가치가 있습니다.

수리: 속도가 아니라 정상 동작을 되찾는 일

다음은 각각 하나의 구체적인 오작동을 고치는 작업들입니다.

• Spotlight 재색인은 찾아야 할 파일을 놓치는 검색을 고칩니다. 먼저 mdutil -s /로 상태를 확인하세요. 전체 재구축은 CPU, 발열, 배터리를 몇 시간씩 소모하고 얻는 건 오직 정확한 검색 결과뿐입니다.
• DNS 비우기는 잘못된 DNS 서버나 VPN 전환 이후 남은 오래된 리졸버 응답을 고칩니다: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder. 라우팅 테이블은 다시 만들지 않습니다. 라우트 초기화는 그보다 훨씬 파급 범위가 커서 활성 터널이나 시스템 프록시를 끊어버릴 수 있습니다.
• 멈춘 미리보기 캐시 초기화는 잘못 렌더링되는 미리보기를 고칩니다. 다시 채워지는 동안 다음 몇 번의 미리보기는 느려집니다.

어느 것도 멀쩡한 Mac을 더 빠르게 만들지 않습니다. 이름 붙일 수 있는 증상이 있을 때만 실행하세요. 이것들을 일정에 맞춰 한꺼번에 돌려주겠다는 도구는 의식을 팔고 있는 겁니다.

Mole의 Optimize 화면은 이런 작업들을 검토 가능한 하나의 실행으로 묶고, 건너뛴 작업은 이유와 함께 보고합니다. VPN이나 시스템 프록시가 활성화된 동안 실행을 거부하는 네트워크 작업도 마찬가지입니다. 이유가 붙은 건너뛰기가, 어떤 판단을 숨긴 체크 표시보다 낫습니다.

최적화가 할 수 없는 것

어떤 소프트웨어도 RAM을 늘려주지 않습니다. Apple Silicon은 제조 시점에 납땜된 통합 메모리를 씁니다. 어떤 소프트웨어도 발열 제한을 풀어주지 않습니다. 뜨거워진 칩은 스스로 클럭을 낮추고, kernel_task가 치솟는 건 macOS가 의도적으로 그걸 강제하는 겁니다. 어떤 소프트웨어도 플래시 마모를 되돌리거나 CPU가 설계된 것보다 초당 더 많은 명령을 처리하게 만들지 못합니다.

메모리 관련 주장은 최적화 앱들이 지금도 여전히 기대는 부분인데, 사실은 거꾸로 이해하고 있는 겁니다. macOS는 쓰지 않는 RAM을 파일 캐시로 채워두다가 프로그램이 그 공간을 필요로 하는 순간 바로 내줍니다. "사용 중인 메모리" 수치가 높은 건 시스템이 제대로 일하고 있다는 뜻입니다. Mac이 실제로 어떻게 느껴지는지를 예측하는 숫자는 메모리 압박이고, 스와핑도 결함이 아닙니다. 커널은 메모리가 넉넉할 때조차 오래 건드리지 않은 페이지를 디스크로 내보냅니다. 메모리 정리 도구는 시스템이 애써 만들어둔 캐시를 비우는 거라, 계기판 수치는 좋아지지만 그다음 몇 분은 오히려 느려집니다. 자세한 내용은 메모리 압박 이해하기에 있습니다.

먼저 진단하고, 그다음 도구를 고르세요

증상을 재현하고 그게 일어나는 동안 수치를 측정하세요. 나중에 찍은 스냅샷은 아무것도 증명하지 못합니다. 용량은 df -h /, CPU를 잡아먹는 게 뭔지는 top -o cpu, 기록된 발열 상태는 pmset -g therm, 그리고 Activity Monitor의 Memory Pressure 그래프를 보세요. 이건 명령줄에서 그만큼 읽기 편한 대응물이 없습니다. 그런 다음 관찰한 걸 아래 표에 대입해 보세요.

여섯 행 중 세 행이 "어떤 최적화 도구도 도와줄 수 없다"로 끝나는데, 이 섹션이 있는 이유가 바로 그겁니다. Mole의 Status 탭은 이런 측정치를 한데 모아놓은 화면입니다. 상태, CPU, 메모리, GPU, 디스크 I/O, 네트워크, 배터리, 발열과 팬, 가동 시간을 다루는 약 아홉 개의 타일이 각각 60초 스파크라인과 함께, 1초마다 갱신되는 프로세스 목록 위에 놓여 있습니다. 60초는 저장된 이력이 아니고, 그런 척도 하지 않습니다.

도구별로, 어떤 작업을 맡는지에 따라

셋 중 어느 것이든 될 수 있다면, Mole

Mole은 여기서 세 가지 의미를 모두 다루는 유일한 도구인데, 더 유용한 건 이걸 버튼 하나로 뭉뚱그리지 않고 따로 유지한다는 점입니다. Clean은 용량을, Software는 앱과 시작 항목을, Optimize는 수리를 맡고, Status는 애초에 문제가 있는지 없는지를 알려줍니다.

용량 문제에서는 합계보다 순서가 중요합니다. Clean은 먼저 스캔부터 하고, 아무것도 움직이기 전에 모든 후보를 정확한 경로, 소유자, 크기와 함께 보여줍니다. 확신이 서지 않는 항목은 선택 해제 상태로 나타나니 기본 동작은 항상 더 작은 쪽입니다. 일반적인 삭제는 unlink가 아니라 휴지통으로 가서, 실수했을 때 백업 복원 대신 그냥 도로 꺼내면 되고, 파일 작업 하나하나가 ~/Library/Logs/mole/operations.log에 기록됩니다. 진짜 작업은 보호 목록에 있습니다. ~/.ollama/models, ~/.lmstudio/models, ~/.cache/huggingface는 절대 후보가 되지 않습니다. 이 도구들이 공유되는 콘텐츠 주소 기반 blob을 추적하고, 어떤 blob이 아직 참조되는지는 그 도구만 알기 때문입니다. ~/.codex/sessions와 ~/.claude/projects 아래의 세션은 아무리 오래됐어도 건드리지 않습니다.

상주 부하 문제에서는 Software 탭이 앱 목록, 업데이트 상태, 시작 항목을 한 화면에 모아 보여주고, 검증된 launchd 작업이나 시스템에 등록된 로그인 항목으로 매칭할 수 있는 것만 켜고 끕니다. 증명할 수 없는 항목은 보호된 데이터베이스에 손대거나 서비스 label을 임의로 지어내는 대신 시스템 설정으로 안내합니다.

실제로는 이렇게 씁니다. 먼저 Status 타일을 읽고, 본 것에 맞는 탭을 엽니다. 디스크가 꽉 찼으면 Clean, 로그인이 느리면 Software, 검색이나 미리보기가 망가졌으면 Optimize입니다.

Mole의 경계를 솔직히 밝히면, 악성코드 대응 도구도, 백업 도구도 아니고, 드라이버나 VPN 구성 요소, 시스템 확장 기능을 함께 설치하는 소프트웨어에는 제조사 제거 도구를 대체할 수 없습니다.

가격은 $19 일회성 구매로 평생 무료 업데이트가 따라오고, 라이선스 하나로 Mac 두 대를 쓸 수 있으며, macOS 14 이상이 필요하고 14일 환불도 됩니다. 스캔은 항상 무료고 유료 도구는 결제 전에 두 번 무료로 써볼 수 있으니 위에 적은 내용을 결제하기 전에 직접 확인할 수 있고, 모든 작업은 원격 측정 없이 로컬에서만 이뤄집니다. 터미널에서는 Mole CLI가 brew install mole로 설치하는 무료 오픈소스(GPL-3.0)로, 파괴적인 명령어마다 --dry-run이 있습니다.

부하와 용량을 시간을 두고 지켜보려면, iStat Menus

Bjango의 iStat Menus는 세 작업 중 어느 것도 직접 하지 않습니다. 대신 지금 어느 문제인지 알려주는 도구고, 그 역할에서는 가장 깊이 있는 선택지입니다. 코어별 CPU와 이력 그래프, 압박 수치가 딸린 메모리 사용량, 압축된 메모리와 스왑, S.M.A.R.T. 상태를 포함한 디스크 공간과 활동, 앱별로 나눈 네트워크 대역폭, 센서, 배터리 상태까지 보여줍니다. 7.3 버전은 macOS 11 이상이 필요합니다. 기간 한정 체험판이 딸린 개인용과 패밀리용 일회성 구매로 판매되고, Setapp을 통해서도 살 수 있습니다. 현재 조건은 공식 페이지에서 확인하세요.

이력 그래프와 앱별 대역폭은 두 번째 작업, 즉 상주 부하와 맞닿아 있습니다. 밤새 조용히 네트워크를 쓰는 앱은 다른 어디서도 아니고 여기서만 보이기 때문입니다. 정리도, 제거도, 수리도 하지 않지만, 그 좁은 초점 자체가 강점입니다. 자세한 내용은 iStat Menus를 넘어서에서 다룹니다.

하드웨어 상태 진단에 정리 기능까지, Sensei

Cindori의 Sensei는 진단과 용량 사이 어딘가에 자리합니다. 공식 페이지에는 CPU, GPU, 배터리 통계, 온도와 팬 모니터링, S.M.A.R.T. 드라이브 상태, 배터리 사이클 수, 디스크 속도 벤치마크, SSD Trim 제어, 상태 막대 모니터가 정리와 앱 제거 기능과 함께 설명돼 있습니다. 스토어 페이지는 연간 구독과 일회성 라이선스를 제공하며 각각 최대 Mac 세 대까지 유효하고, macOS 최소 버전은 명시하지 않습니다. 드라이브와 배터리 상태가 주된 관심사라면 고려할 만합니다. 어떤 상황에 맞는지는 Sensei를 넘어서에서 다룹니다.

발열 문제만 콕 집어서, TG Pro

Tunabelly Software의 TG Pro는 여기서 가장 폭넓게 센서를 읽는 도구입니다. Apple Silicon의 코어별 CPU, GPU, S.M.A.R.T. 기반 저장 장치, 배터리 상태, 모델마다 다른 보드 센서를 온도 기반 Auto Boost 규칙, 알림, CSV 로깅, 진단 리포트와 함께 다룹니다. macOS 10.13부터 macOS 26까지 지원한다고 명시하고 있고, 일회성 구매이며, FAQ에는 라이선스 하나로 개인용 Mac 최대 세 대를 쓸 수 있고 2.x 업데이트는 무료였다고 나와 있습니다.

이 도구는 세 작업 중 어느 것도 다루지 않는 질문에 답합니다. Mac이 뜨거워서 느린 거라면, 아무리 정리하고 시작 항목을 손봐도 달라지지 않습니다. 팬 제어는 권한 있는 헬퍼를 통해 이뤄지니, 신중하게 판단하고 허용해야 할 권한입니다.

이름 붙은 수리 작업이 필요하면, OnyX

Titanium Software의 OnyX는 무료(기부 요청 있음)이고 세 번째 작업을 직접 다룹니다. 유지보수 작업을 추천이 아니라 직접 조작할 수 있는 항목으로 노출합니다. 시스템 파일 구조 검증, 정리, 애플리케이션 제거, 캐시 삭제, 데이터베이스와 색인 재구축, Finder, Dock, Safari, Apple 앱 설정까지 다룹니다. macOS 메이저 버전마다 별도 빌드를 내놓고, 이렇게 명확히 밝히고 있습니다. "OnyX는 macOS 메이저 버전마다 별도의 버전이 있습니다. 올바른 버전을 사용하고, 이전 운영체제용 버전을 쓰려 하지 마세요." 이름을 댈 수 있는 작업만 실행하세요.

대부분 먼저 써봐야 할 무료 기본기, Activity Monitor

Apple의 Activity Monitor는 CPU, 메모리, 에너지, 디스크, 네트워크, 캐시 활동을 다루며, 기기의 프로세스에 대해 가장 권위 있는 시야를 제공합니다. 첫 번째와 두 번째 작업의 진단 단계는 이것만으로 끝낼 수 있습니다. Memory 탭에는 압박 그래프가, CPU 탭에는 프로세스 이름이, Energy 탭에는 유휴 상태에서 전력을 소모하는 헬퍼가, Disk 탭에는 멈춰 있는 동안의 I/O가 나타납니다.

약점은 능력이 아니라 조합에 있습니다. 한눈에 훑어보는 도구가 아니라 창을 열고 들여다봐야 하는 도구고, 숨겨진 Library 폴더를 누가 소유하고 있는지는 알려주지 않습니다. 최적화 도구를 사려는 사람이라면 누구나 먼저 여기서 10분만 써보세요. 지금 어느 작업이 필요한지 공짜로 가려낼 수 있으니까요.

빠른 비교

자주 묻는 질문

Mac 최적화 앱은 실제로 효과가 있나요?

정직한 도구라면 한정된 일을 잘 해냅니다. 용량 확보는 저장 공간이 실제 제약이니 효과가 있고, 상주 부하 제거는 로그인 시간과 유휴 전력에서 효과가 있고, 수리는 뭔가 고장났을 때 효과가 있습니다. 효과가 없는 건 대부분의 마케팅이 깔고 있는 약속, 즉 아무 문제 없는 Mac을 한 번 쓸어주는 것만으로 빨라진다는 그 이야기입니다.

Mac에는 여유 공간이 얼마나 있어야 하나요?

공식적인 수치는 없고, 어디서 보든 그 퍼센트는 누군가의 경험칙일 뿐입니다. 쓸모 있는 접근은 비율이 아니라 할당량입니다. macOS 업데이트를 통째로 준비할 수 있을 만큼, 그리고 평소 작업량에서 스왑이 쓸 여유 공간까지 남겨두는 겁니다. 변경 전후로 df -h /를 측정하고, 실패하던 작업이 이제 성공하는지로 판단하세요.

앱을 종료해도 계속 다시 실행돼요. 악성코드인가요?

거의 아닙니다. launchd는 대부분의 백그라운드 작업을 트리거로 시작하고 유휴 상태가 되면 종료를 허용하니, 프로세스를 종료해도 등록 정보는 그대로 남습니다. 프로세스를 죽이는 대신 로그인 항목 및 확장 프로그램이나 해당 앱의 설정에서 항목을 끄고, 소유자는 시작 프로그램 비활성화하기를 참고해 먼저 확인하세요.

성능을 위해 Spotlight 색인을 다시 만드는 게 효과가 있나요?

아니요. 재구축은 잘못되거나 누락된 검색 결과만 고칠 뿐이고, 그 대가로 몇 시간에 걸친 백그라운드 색인 작업이 진행되는 동안 Mac은 오히려 느려집니다. 실행하기 전에 mdutil -s /로 확인하고 제외 항목과 개인정보 설정부터 배제하세요. 그리고 절대 일정을 잡아 자동으로 돌리지 마세요.

다음으로 볼 것

어떤 자원이 한계에 다다랐는지 아직 모르겠다면, Mac이 느린 이유가 병목을 순서대로 짚어줍니다. 걱정되는 게 메모리 그래프라면, 메모리 압박 이해하기에서 "사용 중인 메모리"가 왜 틀린 지표인지 다룹니다. 답이 상주 부하였다면, 시작 프로그램 비활성화하기가 동기화나 백업, VPN을 망가뜨리지 않는 절차입니다.