# Mole을 위해 수백 개의 Mac 앱을 테스트하다

> Mac 앱을 하나씩 설치하고 제거하면서, 남은 파일과 지우면 안 되는 파일을 확인한 이야기.

Published: 2026-09-22 | Updated: 2026-10-01

요즘 좀 바보 같은 일을 하고 있습니다. AI 시대에 많은 엔지니어가 피하고 싶어 할, 같은 일을 계속 반복하는 작업입니다. Mole의 앱 제거와 잔여 파일 정리를 개선하려고 시작했습니다. 중국과 해외의 Mac 앱을 300개 넘게 모았더니 다운로드 용량만 100 GB가 넘었습니다. 10개씩 30개 묶음으로 나누고 AI가 computer use로 공식 사이트에서 내려받아 제 Mac에 설치하도록 했습니다. 디렉터리, 업데이트 번들, 시작 항목을 확인한 뒤 앱을 제거하고, 남은 파일을 찾아 부족한 규칙을 보완했습니다.

## 100개에서 300개, 그리고 709개로

처음에는 많이 쓰는 앱 100개만 테스트할 생각이었습니다. 그런데 100개만 더 하자는 생각을 거듭하다 300개를 넘었고, 나중에는 App Store 버전과 확장 기능을 포함해 709개가 됐습니다. 평소에는 Mac에 앱을 30개 정도만 두려고 하는데, 테스트 중에는 바탕화면이 이렇게 변했습니다.

<figure class="blog-diagram">
  <img src="https://mole.fit/img/blog/testing-mac-apps-desktop.webp" width="2400" height="1549" loading="lazy" alt="테스트 당시 실제 바탕화면입니다. 앱, 권한 요청 창, 작업 창이 한꺼번에 열려 있습니다.">
  <figcaption>테스트 당시 실제 바탕화면입니다. 앱, 권한 요청 창, 작업 창이 한꺼번에 열려 있습니다.</figcaption>
</figure>

지루해 보이는 작업이지만 설치 과정은 순탄하지만은 않습니다. 권한 요청과 구매 안내가 뜨고 관리자 암호가 필요한 경우도 있습니다. 대부분은 에이전트가 처리하고 나머지는 제가 돕습니다. 놀라웠던 건 AI가 자기 작업을 편하게 하려고 설치, 제거, 잔여 파일 확인 스크립트까지 만들었다는 점입니다. 어느새 제가 보조 역할을 하고 있더군요.

<figure class="blog-diagram">
  <video src="https://mole.fit/img/blog/testing-mac-apps.mp4" poster="/img/blog/testing-mac-apps-poster.webp" width="1920" height="1080" controls muted playsinline preload="none" aria-label="설치, 제거, 잔여 파일 확인 과정의 실제 녹화입니다. 소리가 없는 영상이며, 재생 버튼을 눌러 볼 수 있습니다."></video>
  <figcaption>설치, 제거, 잔여 파일 확인 과정의 실제 녹화입니다. 소리가 없는 영상이며, 재생 버튼을 눌러 볼 수 있습니다.</figcaption>
</figure>

## 설치는 시작일 뿐

시간이 드는 부분은 첫 실행부터 권한 요청, 업데이트, 시작 항목, 제거까지 앱의 사용 과정을 확인하는 일입니다. 설치 파일만 살펴보면 실행 후 생성되는 폴더를 놓칩니다. 앱 본체를 지우는 것만으로는 다른 위치에 둔 파일까지 없어졌는지 알 수 없습니다.

폴더를 만든 앱은 무엇인지, 업데이트 helper는 누구 소유인지, 시작 항목이 남았는지부터 확인합니다. 실제 경로와 소유 관계를 알아야 규칙에 넣을 수 있으며 이름이 비슷하다는 이유로는 부족합니다. App Store 버전과 공식 사이트 버전도 이름은 같아도 설치 방식과 데이터 위치가 다를 수 있어 따로 확인합니다.

AI는 검사를 반복하고 익힌 절차를 스크립트로 만들 수 있지만 권한, 관리자 암호, 소유 관계가 불분명한 파일은 여전히 사람이 살펴야 합니다. 전부 수작업이었다면 제 예상으로는 10배의 시간이 들었을 겁니다.

## 직접 설치해야 알 수 있는 것들

소프트웨어가 어느 정도 규칙적으로 만들어진다면 100개쯤 테스트한 뒤에는 새로 보완할 것이 별로 없을 줄 알았습니다. 실제로는 그렇지 않았습니다. 공통 규칙으로 찾을 수 없는 경로가 많았고, 번들 ID가 역방향 도메인 형식조차 아닌 앱도 있었습니다. 규칙처럼 보이던 값이 개발자가 한때 임의로 적은 것일 수도 있기에 하나씩 설치해서 확인해야 했습니다.

## 남겨야 할 것도 찾기

처음 300개 넘는 앱을 검사한 과정에서 재사용할 공통 규칙 13종과 정확한 정리 경로 90개 이상을 추가했습니다. 지워야 한다고 생각했지만 건드리면 안 되는 곳도 30개 이상 수정했고, 업데이트와 시작 항목 검사를 보완하고 단위 테스트 100개 이상을 추가했습니다. 당시 작업의 수치이며 앱 목록은 계속 늘고 있습니다.

남겨야 할 항목을 찾는 일도 잔여 파일을 찾는 것만큼 중요합니다. 캐시는 다시 만들 수 있어도 사람이 작성한 파일은 그렇지 않습니다. 여러 앱이 공유하는 데이터는 앱 하나를 제거했다고 함께 지우면 안 됩니다. 버려진 것처럼 보여도 다른 앱이 쓰는 파일일 수 있으니 소유 관계가 불분명하면 남겨 두는 편이 낫습니다.

정리 용량을 늘리는 데만 집중하면 판단이 흐려집니다. 반복되는 패턴은 공통 규칙으로 다루고 특이한 경로는 개별 확인하며, 지우면 안 되는 사례는 테스트로 남겨 이후 규칙 변경에서 같은 실수를 막습니다.

## 접근성에서 돌아온 뜻밖의 도움

Mole은 초기 버전부터 시각장애인의 사용을 지원하려고 접근성 속성을 추가해 왔습니다. 이번에는 AI도 그 속성으로 정확한 요소와 버튼을 찾을 수 있어 테스트가 수월해졌습니다. 사용자를 위해 했던 일이 제 작업에도 도움이 됐습니다.

접근성 속성은 위치뿐 아니라 버튼 이름, 컨트롤 종류와 현재 상태도 알려줄 수 있습니다. 레이아웃이 움직여도 같은 버튼을 찾는 단서가 됩니다. 화면 이미지와 고정 좌표만 사용하면 창이나 대화상자가 이동했을 때 다른 곳을 누르기 쉽습니다.

물론 먼저 사람을 위한 기능입니다. AI가 버튼을 찾았다고 VoiceOver 사용자도 작업을 끝낼 수 있다는 뜻은 아닙니다. 이름이 명확한지, 초점이 순서대로 이동하는지, 결과를 읽어 주는지 여전히 확인해야 합니다. 다양한 사용 방식을 지원하는 일이 지닌 가치를 이번에 더 느꼈습니다.

앱이나 웹사이트를 만든다면 코딩 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