Chrome 메모리 점검: 자동화 브라우저 6.8GB 사례

Mac에서 Chrome 메모리 사용량이 커졌을 때, 모든 Chrome을 닫기 전에 자동화가 만든 세션인지부터 확인할 필요가 있습니다. 이 글은 제 Mac mini의 당시 기록을 통해 종료 대상의 소유자를 찾는 순서와 정리 후 비교 기준을 설명합니다.

Chrome이 메모리를 많이 쓴다는 말은 익숙합니다. 그런데 2026년 7월 21일, 제 Mac mini의 작업 기록에 남은 숫자는 조금 달랐습니다. 일반 Chrome은 약 447MB, 자동화용 Chrome for Testing의 Helper 프로세스 80개는 약 6.8GB를 차지하고 있었습니다.

평소 쓰던 브라우저를 닫는 것으로 해결할 일이 아니었습니다. 끝난 줄 알았던 웹 자동화의 실행 흔적이 남아 있었습니다.

이 글은 그날의 점검 기록을 바탕으로, 메모리를 많이 쓰는 프로세스를 찾은 뒤 어디까지 확인하고 무엇을 종료해야 하는지를 정리한 사례입니다. 모든 Mac의 메모리 부족 원인을 자동화로 설명하려는 글은 아닙니다.

먼저 확인한 것은 점유량보다 출처였습니다

자동화 도구가 띄운 브라우저와 사람이 쓰는 브라우저는 이름이 비슷합니다. 둘을 한꺼번에 종료하면 메모리는 줄겠지만, 진행 중인 로그인이나 테스트까지 함께 끊을 수 있습니다.

당시에는 프로세스 이름뿐 아니라 실행 경로와 부모 프로세스를 함께 확인했습니다. 기록에는 자동화용 브라우저 본체 7개와 그 아래에 누적된 Helper 프로세스가 구분되어 있습니다. 정리 범위도 일반 Chrome 전체가 아니라, 종료해도 되는 자동화 세션으로 한정했습니다.

이 구분이 중요합니다. 같은 이름의 프로세스가 많다는 사실만으로는 장애를 판단할 수 없습니다. 먼저 어느 작업이 만들었는지, 그 작업이 아직 진행 중인지 알아야 합니다.

그날의 전후 기록

수치는 당시 작업 기록의 값입니다. 이번 글 수정 과정에서 같은 장애를 다시 일으켜 측정한 결과는 아닙니다. 원자료의 세부 집계 방식도 이 글에서 재검증하지 않았으므로, 여유 메모리 증가분 전체가 종료한 프로세스에서 나왔다거나 동일한 절감 효과가 재현된다고 단정할 수는 없습니다.

확인할 수 있는 범위는 더 좁습니다. 정리 대상으로 지정한 자동화 세션을 종료한 뒤, 기록상 해당 프로세스 수와 메모리 점유가 줄고 여유 메모리가 늘었습니다. 이것이 메모리 누수 자체의 원인 분석이나 영구 해결을 뜻하지는 않습니다.

비슷한 상황이라면 이렇게 확인합니다

1. 전체 메모리 상태를 함께 봅니다

활동 모니터의 메모리 탭에서 많이 사용하는 앱을 확인하되, 여유 메모리 숫자 하나만 보지 않습니다. Apple은 메모리 압박을 여유 메모리, 스왑률, 와이어드 메모리, 파일 캐시 등을 함께 반영하는 지표로 설명합니다. 메모리 압박 그래프와 스왑 사용량을 같이 보는 편이 판단에 도움이 됩니다. Apple 메모리 사용량 안내

2. 부모와 자식 프로세스를 구분합니다

활동 모니터의 보기 메뉴에서 프로세스를 계층적으로 표시하면 어느 프로세스 아래에서 실행되는지 확인할 수 있습니다. 낯선 Helper 하나를 바로 종료하기 전에 실행 주체를 찾는 데 유용합니다. Apple 프로세스 확인 안내

터미널에 익숙하다면 다음 읽기 전용 명령으로 PID, 부모 PID, RSS, 실행 파일 이름을 볼 수도 있습니다.

ps -axo pid=,ppid=,rss=,comm=

이 명령은 조회만 합니다. RSS는 활동 모니터의 표시값과 같은 측정치로 취급하지 말고, 실행 주체를 구분하는 보조 정보로 사용합니다. 실행 경로에도 개인 사용자명 등이 들어갈 수 있으므로 출력 전체를 공개 글이나 외부 서비스에 그대로 올리지는 않습니다.

3. 세션 소유자에게 종료 가능 여부를 확인합니다

다음 중 하나라도 불분명하면 정리를 보류합니다.

• 현재 로그인, 예약, 다운로드, 테스트가 진행 중인가요?
• 이 브라우저는 해당 자동화가 새로 만든 것인가요, 사용자가 쓰던 것을 연결한 것인가요?
• 종료하면 안 되는 다른 작업과 브라우저를 공유하고 있나요?

가능하면 프로세스 이름으로 일괄 종료하기보다 자동화 도구의 세션 종료 기능을 먼저 사용합니다. 프로세스가 오래됐다는 이유만으로 사용이 끝났다고 추정하지 않습니다.

4. 정리 뒤 같은 항목을 다시 기록합니다

프로세스 수, 메모리 압박, 대상 프로그램의 점유량을 같은 방식으로 다시 확인합니다. 숫자가 줄었더라도 원래 하던 작업이 끊겼다면 좋은 정리가 아닙니다. 실행 중이던 작업의 결과도 함께 확인해야 합니다.

종료할지 관찰할지 나누는 기준

저라면 6.8GB라는 숫자만으로 종료 여부를 정하지 않겠습니다. 아래 세 경우를 나누면 정리의 목적을 잃지 않을 수 있습니다.

• 소유 작업이 불명확한 경우: 실행 경로와 부모 프로세스, 진행 중인 작업을 먼저 기록하고 종료를 보류합니다.
• 종료된 작업의 전용 세션인 경우: 해당 작업의 결과물과 종료 승인을 확인한 뒤 그 세션만 정리 대상으로 삼습니다.
• 정리 뒤 다시 늘어나는 경우: 같은 작업의 시작 전·완료 후를 같은 도구로 기록해 반복 양상을 비교합니다. 한 번 줄어든 결과를 영구 해결로 보고하지 않습니다.

Apple 문서가 설명하는 메모리 압박에는 여유 메모리 외의 요소도 반영됩니다. 따라서 기록 칸을 “여유 메모리” 하나가 아니라 시각·대상·측정 도구·메모리 압박·작업 상태로 나누는 것을 권합니다. Apple의 메모리 지표 설명을 기준으로 표시값의 의미부터 맞춥니다.

세션 수를 보고 바로 장애라고 단정하지 않았던 3월 30일 자동화 유지 일기와 함께 보면, 단일 숫자보다 반복되는 운영 패턴을 남겨야 하는 이유가 더 분명해집니다.

다음 자동화에는 종료 조건을 적어둡니다

이번 사례에서 얻은 운영 원칙은 단순합니다. 자동화를 맡길 때 결과물만 지정하면 세션 정리가 빠지기 쉽습니다. 앞으로는 아래 항목도 작업 조건에 포함하려고 합니다.

이 표는 재발을 줄이기 위한 설계 제안이지, 모든 자동화에 이미 적용해 검증한 결과는 아닙니다.

메모리를 많이 쓰는 앱을 찾는 일과, 안전하게 종료할 대상을 고르는 일은 다릅니다. 그날 필요했던 것은 강한 종료 명령보다 정확한 소유 범위였습니다.

사례 기준일: 2026-07-21. 기존 작업 기록을 바탕으로 2026-09-03에 재구성했습니다. 당시 수치는 기록값이며 새로운 벤치마크가 아닙니다.

편집 보완: 2026-09-10. 당시 경험과 기록은 유지하고 읽기 흐름과 판단 기준을 보강했습니다. 이번 편집을 위해 새로운 실행·측정·복구 시험을 수행하지 않았습니다.