# Mole을 위해 수백 개의 Mac 앱을 테스트하다 > Mac 앱을 하나씩 설치하고 제거하면서, 남은 파일과 지우면 안 되는 파일을 확인한 이야기. Published: 2026-09-22 Mole의 앱 제거와 잔여 파일 정리를 개선하려고 같은 작업을 계속 반복하고 있습니다. 중국과 해외의 Mac 앱을 300개 넘게 모았더니 다운로드 용량만 100 GB가 넘었습니다. 10개씩 30개 묶음으로 나누고 AI가 computer use로 공식 사이트에서 내려받아 제 Mac에 설치하도록 했습니다. 디렉터리, 업데이트 번들, 시작 항목을 확인한 뒤 앱을 제거하고, 남은 파일을 찾아 부족한 규칙을 보완했습니다. ## 100개에서 300개, 그리고 549개로 처음에는 많이 쓰는 앱 100개만 테스트할 생각이었습니다. 그런데 100개만 더 하자는 생각을 거듭하다 300개를 넘었고, 나중에는 App Store 버전과 확장 기능을 포함해 549개가 됐습니다. 평소에는 Mac에 앱을 30개 정도만 두려고 하는데, 테스트 중에는 바탕화면이 이렇게 변했습니다.
테스트 당시 실제 바탕화면입니다. 앱, 권한 요청 창, 작업 창이 한꺼번에 열려 있습니다.
테스트 당시 실제 바탕화면입니다. 앱, 권한 요청 창, 작업 창이 한꺼번에 열려 있습니다.
지루해 보이는 작업이지만 설치 과정은 순탄하지만은 않습니다. 권한 요청과 구매 안내가 뜨고 관리자 암호가 필요한 경우도 있습니다. 대부분은 에이전트가 처리하고 나머지는 제가 돕습니다. 놀라웠던 건 AI가 자기 작업을 편하게 하려고 설치, 제거, 잔여 파일 확인 스크립트까지 만들었다는 점입니다. 어느새 제가 보조 역할을 하고 있더군요.
설치, 제거, 잔여 파일 확인 과정의 실제 녹화입니다. 소리 없이 재생 버튼으로 볼 수 있습니다.
## 설치는 시작일 뿐 시간이 드는 부분은 첫 실행부터 권한 요청, 업데이트, 시작 항목, 제거까지 앱의 사용 과정을 확인하는 일입니다. 설치 파일만 살펴보면 실행 후 생성되는 폴더를 놓칩니다. 앱 본체를 지우는 것만으로는 다른 위치에 둔 파일까지 없어졌는지 알 수 없습니다. 폴더를 만든 앱은 무엇인지, 업데이트 helper는 누구 소유인지, 시작 항목이 남았는지부터 확인합니다. 실제 경로와 소유 관계를 알아야 규칙에 넣을 수 있으며 이름이 비슷하다는 이유로는 부족합니다. App Store 버전과 공식 사이트 버전도 이름은 같아도 설치 방식과 데이터 위치가 다를 수 있어 따로 확인합니다. AI는 검사를 반복하고 익힌 절차를 스크립트로 만들 수 있지만 권한, 관리자 암호, 소유 관계가 불분명한 파일은 여전히 사람이 살펴야 합니다. 전부 수작업이었다면 제 예상으로는 10배의 시간이 들었을 겁니다. ## 직접 설치해야 알 수 있는 것들 소프트웨어가 어느 정도 규칙적으로 만들어진다면 100개쯤 테스트한 뒤에는 새로 보완할 것이 별로 없을 줄 알았습니다. 실제로는 그렇지 않았습니다. 공통 규칙으로 찾을 수 없는 경로가 많았고, 번들 ID가 역방향 도메인 형식조차 아닌 앱도 있었습니다. 규칙처럼 보이던 값이 개발자가 한때 임의로 적은 것일 수도 있기에 하나씩 설치해서 확인해야 했습니다. 검사하면서 지워야 한다고 생각했지만 건드리면 안 되는 곳도 수정했습니다. 앱 캐시, 사용자의 파일, 여러 앱이 공유하는 데이터는 같은 디렉터리에 있다는 이유만으로 모두 쓰레기가 되지 않습니다. 더 많이 테스트할수록 남겨야 할 것도 더 많이 발견합니다. ## 남겨야 할 것도 찾기 처음 300개 넘는 앱을 검사한 과정에서 재사용할 공통 규칙 13종과 정확한 정리 경로 90개 이상을 추가했습니다. 지워야 한다고 생각했지만 건드리면 안 되는 곳도 30개 이상 수정했고, 업데이트와 시작 항목 검사를 보완하고 단위 테스트 100개 이상을 추가했습니다. 당시 작업의 수치이며 앱 목록은 계속 늘고 있습니다. 남겨야 할 항목을 찾는 일도 잔여 파일을 찾는 것만큼 중요합니다. 캐시는 다시 만들 수 있어도 사람이 작성한 파일은 그렇지 않습니다. 여러 앱이 공유하는 데이터는 앱 하나를 제거했다고 함께 지우면 안 됩니다. 버려진 것처럼 보여도 다른 앱이 쓰는 파일일 수 있으니 소유 관계가 불분명하면 남겨 두는 편이 낫습니다. 정리 용량을 늘리는 데만 집중하면 판단이 흐려집니다. 반복되는 패턴은 공통 규칙으로 다루고 특이한 경로는 개별 확인하며, 지우면 안 되는 사례는 테스트로 남겨 이후 규칙 변경에서 같은 실수를 막습니다. ## 접근성에서 돌아온 뜻밖의 도움 Mole은 초기 버전부터 시각장애인의 사용을 지원하려고 접근성 속성을 추가해 왔습니다. 이번에는 AI도 그 속성으로 정확한 요소와 버튼을 찾을 수 있어 테스트가 수월해졌습니다. 사용자를 위해 했던 일이 제 작업에도 도움이 됐습니다. 접근성 속성은 위치뿐 아니라 버튼 이름, 컨트롤 종류와 현재 상태도 알려줄 수 있습니다. 레이아웃이 움직여도 같은 버튼을 찾는 단서가 됩니다. 화면 이미지와 고정 좌표만 사용하면 창이나 대화상자가 이동했을 때 다른 곳을 누르기 쉽습니다. 물론 먼저 사람을 위한 기능입니다. AI가 버튼을 찾았다고 VoiceOver 사용자도 작업을 끝낼 수 있다는 뜻은 아닙니다. 이름이 명확한지, 초점이 순서대로 이동하는지, 결과를 읽어 주는지 여전히 확인해야 합니다. 다양한 사용 방식을 지원하는 일이 지닌 가치를 이번에 더 느꼈습니다. 100개 이후에는 반복만 남을 줄 알았는데 300개, 549개에서도 새로운 세부 사항이 나왔습니다. 앞으로도 많이 쓰는 앱을 직접 설치하고 확인한 내용을 Mole에 반영하고 싶습니다. 이런 평범한 검사가 실제로 앱을 제거하는 순간 도움이 될 수 있습니다. 앱이나 웹사이트를 만든다면 코딩 AI에게 접근성 속성 보완을 맡겨볼 만합니다. 시각장애인이 더 편하게 사용할 수 있고, 자동화 테스트에도 도움이 될 수 있습니다. 이 테스트는 계속할 생각입니다. 기록은 [실측 앱 목록](https://mole.fit/ko/tested-apps)에 정리했고, 다음에 확인했으면 하는 앱은 [토론 글](https://github.com/tw93/Mole/discussions/1604)에 남겨 주세요. --- Canonical HTML page: https://mole.fit/ko/blog/testing-mac-apps-one-by-one Blog index for agents: https://mole.fit/ko/blog/llms.txt Site index for agents: https://mole.fit/llms.txt