- Published on
Chrome(크롬)이 실행 중인데 창이 안 뜰 때: Headless Chrome 프로세스 누수 해결기
- Authors
- Name
- 테크버킷
목차
- 이런 문제가 해당됩니다
- 발단: 프로필이 사라진 줄 알았다
- 원인은 어떻게 확인했나?
- 터미널에서는 무엇을 확인하면 될까?
- 왜 Chrome을 종료해도 다시 살아났을까?
- 실제로 복구한 순서
- 가장 먼저 실행할 복구 명령
- 알려진 agent-browser 결함과 같은 문제인가?
- 시스템 Chrome의 GUI 실행을 막는 이슈 #1607
- 비정상 종료 후 프로세스가 남는 이슈 #1113
- Helper가 CPU를 계속 사용하는 이슈 #1371
- 앞으로 agent-browser를 안전하게 쓰는 방법
- 1. 최신 버전으로 업데이트한다
- 2. Chrome for Testing을 설치한다
- 3. daemon 유휴 종료 시간을 짧게 둔다
- 4. 성공·실패 경로 모두에서 세션을 닫는다
- 5. 개인 Chrome 프로필을 직접 공유하지 않는다
- 자주 묻는 질문
- Chrome 프로필이 정말 삭제된 것인지 어떻게 구분하나요?
- Chrome 재설치로 해결할 수 있나요?
- Headless Chrome을 쓰면 항상 이런 문제가 생기나요?
- Browser Use를 쓴 뒤 Chrome 창이 안 뜨면 같은 문제인가요?
- 활성 상태 보기에서 Chrome Helper가 많으면 모두 문제인가요?
- 마치며
- 참고 자료
macOS에서 Chrome(크롬)은 실행 중으로 표시되는데 창이 안 뜨고, 새 창이나 외부 링크도 열리지 않는다면 먼저 Headless Chrome 프로세스가 남아 있는지 확인해 보세요. 제 경우 Chrome 프로필이 삭제된 것이 아니라, agent-browser가 실행한 창 없는 Chrome과 백그라운드 daemon이 종료되지 않은 것이 원인이었습니다.
복구 전에는 Google Chrome 앱에 속한 프로세스가 443개까지 쌓여 있었습니다. 자동화 프로세스만 정리하자 기존 Chrome 프로필 9개와 Aside의 창·탭이 그대로 돌아왔습니다. 프로필 삭제나 Chrome 재설치는 필요하지 않았습니다.
한 줄 결론: 이 현상은 Headless Chrome 자체의 일반적인 고장이라기보다,
agent-browser가 시스템 Chrome을 자동화에 사용한 뒤 daemon과 프로세스 트리를 정리하지 못해 발생한 고아 Headless Chrome 프로세스 누수였습니다.
이런 문제가 해당됩니다
다음 증상이 여러 개 겹친다면 Chrome 설정을 초기화하기 전에 실행 중인 프로세스를 확인하는 편이 안전합니다.
- Dock의 Chrome 아이콘 아래에는 실행 표시가 있지만 창이 하나도 나타나지 않습니다.
파일 → 새 창을 선택하거나 단축키를 눌러도 새 창이 열리지 않습니다.- 메일이나 메신저의 링크를 눌러도 Chrome 창이 뜨지 않습니다.
- Chrome 프로필 선택 화면이 나타나지 않아 로그인 프로필이 사라진 것처럼 보입니다.
- Chrome을 강제 종료한 뒤에도 같은 문제가 바로 반복됩니다.
- 활성 상태 보기에 Google Chrome과 Chrome Helper가 비정상적으로 많이 표시됩니다.
- 메모리·스왑 사용량, 발열 또는 배터리 소모가 갑자기 늘었습니다.
특히 Codex나 다른 AI 에이전트로 브라우저 자동화를 실행했고 그 과정에서 agent-browser를 사용했다면 가능성이 높습니다. 작업이 타임아웃되거나 강제로 중단되면 자동화 브라우저의 부모·자식 프로세스가 남을 수 있기 때문입니다.
이 글에서 직접 확인한 원인은 agent-browser(Agent Browser)입니다. 다만 Browser Use나 Playwright·Puppeteer 기반 자동화를 사용한 뒤에도 Chrome 창이 열리지 않는다면, 아래 진단 순서로 고아 Headless Chrome 프로세스가 남았는지 확인할 수 있습니다. 도구가 다르면 원인도 다를 수 있으므로 --headless=new, 임시 프로필 경로와 부모 프로세스를 함께 확인해야 합니다.
발단: 프로필이 사라진 줄 알았다
처음에는 Chrome뿐 아니라 Chromium 기반 브라우저인 Aside도 같은 증상을 보였습니다. 앱은 실행 중으로 표시됐지만 보이는 창이 없었고, 새 창과 외부 링크도 열리지 않았습니다. Chrome 메뉴에서는 기존 로그인 프로필까지 보이지 않는 것처럼 느껴졌습니다.
가장 먼저 의심한 것은 프로필 손상이었습니다. 하지만 사용자 데이터 폴더를 확인하니 상황이 달랐습니다.
~/Library/Application Support/Google/Chrome
이 폴더에는 약 7.7GB의 데이터와 9개의 프로필 디렉터리가 그대로 남아 있었습니다. Aside의 사용자 데이터 약 1GB도 보존되어 있었습니다. 데이터가 사라진 것이 아니라 정상 프로필을 화면에 보여줄 GUI Chrome이 실행되지 못하고 있던 것입니다.
이 차이는 중요합니다. 프로필 삭제, Chrome 초기화 또는 재설치를 먼저 시도했다면 온전히 남아 있던 로그인 정보와 설정까지 잃을 수 있었습니다.
원인은 어떻게 확인했나?
macOS 활성 상태 보기와 프로세스 실행 정보를 확인하자 비정상적인 규모가 드러났습니다.
| 확인 항목 | 정리 전 | 복구 후 |
|---|---|---|
| 자동화용 Headless Chrome 본체 | 42개 | 0개 |
| 자동화 임시 프로필을 쓰는 Chrome 프로세스 | 401개 | 0개 |
Google Chrome.app 소속 전체 프로세스 | 443개 | 정상 프로세스 8개 |
| 정상 Chrome 본체 | 보이는 창 없음 | 1개 |
| 시스템 메모리 여유 비율 | 약 69% | 약 83% |
| 스왑 사용량 | 약 3.20GB | 약 858.7MB |
가장 오래된 자동화 Chrome은 약 1일 17시간 동안 실행되고 있었습니다. 남아 있던 프로세스의 명령에는 다음 옵션이 반복해서 나타났습니다.
--headless=new
--remote-debugging-port=0
--user-data-dir=/var/folders/.../T/agent-browser-chrome-<UUID>
--headless=new은 Chrome을 화면 없이 실행한다는 뜻입니다. agent-browser-chrome-<UUID>는 실제 사용자 프로필이 아니라 자동화 세션용 임시 사용자 데이터 경로입니다. Headless Chrome 본체 하나만 남은 것이 아니라 Renderer, GPU, Network, Storage Helper가 포함된 프로세스 트리가 여러 세트 누적돼 있었습니다.
터미널에서는 무엇을 확인하면 될까?
프로세스를 종료하기 전에 아래처럼 읽기 전용으로 실행 경로와 지속 시간을 확인할 수 있습니다.
ps ax -o pid,ppid,etime,command | rg 'agent-browser|Google Chrome'
결과가 많다면 자동화 프로세스를 식별하는 두 문자열로 범위를 좁힙니다.
ps ax -o pid,ppid,etime,command | rg -- '--headless=new|agent-browser-chrome-'
여기서 확인할 핵심은 프로세스 수뿐 아니라 PPID로 표시되는 부모 프로세스, 실행 시간, --user-data-dir 경로입니다. 일반 Chrome 프로세스와 자동화 프로세스를 구분하지 않은 채 일괄 종료하면 작성 중인 작업이나 다운로드까지 함께 끊을 수 있습니다.
왜 Chrome을 종료해도 다시 살아났을까?
처음에는 자동화용 Chrome에 정상 종료 신호만 보냈습니다. 프로세스 수는 줄었지만 일부 Chrome Helper가 남거나 다시 생성됐습니다. 부모 프로세스를 추적하니 Homebrew로 설치된 agent-browser-darwin-arm64 daemon 여러 개가 계속 살아 있었습니다.
즉, 누수된 대상은 Chrome만이 아니었습니다. Chrome을 실행하고 관리하던 daemon까지 남아 있었기 때문에 자식 프로세스를 정리해도 다시 생성될 수 있었습니다. 이번 문제를 더 정확히 표현하면 agent-browser daemon과 Headless Chrome 프로세스의 수명주기 누수입니다.
문제가 일반 Chrome 전체로 번진 이유는 macOS의 앱 실행 방식과도 관련이 있습니다. 자동화 도구는 별도의 Chrome for Testing이 아니라 사용자의 /Applications/Google Chrome.app을 Headless 모드로 실행하고 있었습니다. macOS는 같은 앱이 이미 실행 중이라고 판단해 Dock 클릭과 새 창 요청을 기존의 창 없는 인스턴스로 전달했습니다.
사용자: Google Chrome을 열어줘
macOS: Google Chrome.app이 이미 실행 중이므로 기존 앱을 활성화
기존 앱: Headless 모드라 표시할 창이 없음
결과: Chrome은 실행 중이지만 아무 창도 나타나지 않음
프로필이 없어진 것처럼 보인 것도 같은 이유였습니다. 프로필 데이터는 디스크에 남아 있었지만 이를 보여줄 정상 GUI가 열리지 않았습니다.
실제로 복구한 순서
복구의 원칙은 사용자 데이터는 건드리지 않고 자동화 프로세스만 좁게 정리하는 것이었습니다.
- 프로세스 수, 실행 옵션, 부모·자식 관계와 메모리 상태를 기록했습니다.
- Chrome 사용자 데이터 폴더와 프로필 디렉터리가 남아 있는지 확인했습니다.
- 먼저
agent-browser close --all로 자동화 세션의 정상 종료를 시도했습니다. - 계속 남는 프로세스의 부모를 추적해 고아
agent-browserdaemon을 식별했습니다. --headless=new과agent-browser-chrome-*임시 프로필을 사용하는 프로세스 트리만 종료했습니다.- 약 2일 11시간 동안 멈춰 있던 Aside 본체와 고아 crashpad handler도 구분해 정리했습니다.
- Chrome과 Aside를 정상 방식으로 다시 실행하고 창·프로필·기존 탭이 복구됐는지 확인했습니다.
정리 후 자동화용 Chrome과 agent-browser daemon은 모두 0개가 됐습니다. Chrome 프로필 선택 화면에는 기존 9개 프로필이 다시 나타났고, Aside도 기존 작업과 탭을 복원했습니다.
이 화면은 프로필 데이터가 삭제되거나 초기화된 것이 아니라는 가장 직접적인 증거입니다. 공개용 이미지에서는 개인 프로필 이름과 아바타만 마스킹하고, 복구된 프로필 카드의 개수와 Chrome 사용자 선택 화면의 구조는 유지했습니다.
Aside도 새로 설치된 빈 화면이 아니라 기존 Chats와 Tabs 목록이 함께 돌아왔습니다. 작업명과 방문 페이지 제목은 개인정보 보호를 위해 가렸지만, 복구된 목록의 구조와 항목 수는 확인할 수 있습니다.
가장 먼저 실행할 복구 명령
정상적인 종료 경로가 살아 있다면 아래 명령이 가장 안전한 첫 단계입니다.
agent-browser close --all
그래도 남는다면 활성 상태 보기에서 agent-browser, Google Chrome, Google Chrome Helper를 검색하고, 실행 시간과 자동화용 임시 경로를 기준으로 대상을 구분하세요. 이 글에서는 복사 실수로 일반 Chrome까지 종료하는 일을 막기 위해 광범위한 pkill 명령을 제시하지 않습니다.
프로필 폴더 삭제, Chrome 설정 초기화, 앱 재설치는 프로세스 정리 후에도 문제가 계속될 때 검토할 마지막 단계입니다.
알려진 agent-browser 결함과 같은 문제인가?
공개 보고를 확인한 결과, 이번 사례는 이미 보고된 macOS용 agent-browser 문제와 매우 높은 수준으로 일치했습니다.
시스템 Chrome의 GUI 실행을 막는 이슈 #1607
agent-browser 이슈 #1607은 Headless daemon이 사용자의 시스템 Chrome을 실행한 상태에서 Dock을 클릭해도 창이 열리지 않는 현상을 설명합니다. 보고에 따르면 agent-browser install을 실행하지 않은 환경에서 /Applications/Google Chrome.app으로 폴백할 수 있고, macOS는 이를 이미 실행 중인 일반 Chrome으로 인식합니다.
2026년 8월 25일 확인 기준 이 이슈는 Open 상태입니다. 보고자는 0.31.1에서 재현했고, 임시 프로필 잠금보다 동일한 앱 번들을 시스템 Chrome과 자동화가 공유한 충돌에 초점을 맞췄습니다.
비정상 종료 후 프로세스가 남는 이슈 #1113
이슈 #1113은 자동화 세션이 비정상 종료된 뒤 Headless Chrome 본체, GPU·Renderer·Network·Storage Helper와 crashpad handler가 고아 상태로 남는 사례입니다. 이슈의 환경은 macOS Apple Silicon과 agent-browser 0.23.4였고, 이번 컴퓨터에 설치돼 있던 0.23.3과 거의 같은 세대였습니다.
이 이슈는 수정 작업과 함께 Closed 처리됐지만, 이후 더 새로운 버전에서 유사 증상이 다시 보고됐습니다. 따라서 업데이트만으로 운영상의 격리와 종료 확인을 생략하기는 어렵습니다.
Helper가 CPU를 계속 사용하는 이슈 #1371
이슈 #1371은 agent-browser-chrome-* 임시 프로필을 쓰는 Chrome Helper가 세션 종료 후에도 남아 CPU와 배터리를 계속 소모하는 문제를 기록합니다. 2026년 8월 25일 확인 기준 Open 상태이며, 프로세스 경로와 --headless=new 옵션이 이번 사례와 같습니다.
Chrome의 Headless 모드 자체는 자동화와 테스트를 위한 정상 기능입니다. Chrome 공식 Headless 문서에 따르면 현재 Headless 모드는 일반 Chrome과 통합된 코드 기반을 사용하되 화면에 보이는 UI를 표시하지 않습니다. 그러므로 “Headless Chrome이 고장 났다”보다 다음 설명이 더 정확합니다.
agent-browser가 macOS에서 사용자의 시스템 Chrome을 Headless 자동화 엔진으로 사용한 뒤 daemon과 프로세스 트리를 정리하지 못했고, macOS가 같은 앱 번들을 이미 실행 중인 Chrome으로 처리하면서 일반 Chrome 창까지 열리지 않았다.
앞으로 agent-browser를 안전하게 쓰는 방법
브라우저 자동화를 포기할 필요는 없습니다. 다만 일상용 Chrome과 자동화 브라우저를 분리하고, 정상·비정상 종료 모두를 고려한 안전장치가 필요합니다.
1. 최신 버전으로 업데이트한다
문제가 발생한 환경은 agent-browser 0.23.3이었습니다. 2026년 8월 25일 기준 최신 릴리스는 0.34.0입니다.
agent-browser upgrade
Homebrew로 직접 관리한다면 brew upgrade agent-browser를 사용할 수도 있습니다. 다만 더 새로운 0.31.1에서도 GUI 차단 문제가 보고됐으므로 업데이트만으로 충분하다고 단정하면 안 됩니다.
2. Chrome for Testing을 설치한다
가장 중요한 예방 조치입니다. agent-browser 공식 설치 안내는 처음 한 번 아래 명령으로 Chrome for Testing을 내려받도록 안내합니다.
agent-browser install
Chrome for Testing은 브라우저 자동화와 테스트에 맞춘 Google의 별도 배포 채널입니다. 자동화용 앱과 사용자가 평소 쓰는 Google Chrome.app을 분리하면, Headless 프로세스가 잠시 남더라도 일반 Chrome 실행을 가로막는 범위를 줄일 수 있습니다.
사용자가 직접 쓰는 브라우저 → Google Chrome.app
AI·테스트 자동화 브라우저 → Chrome for Testing
3. daemon 유휴 종료 시간을 짧게 둔다
현재 CLI는 AGENT_BROWSER_IDLE_TIMEOUT_MS 환경 변수로 유휴 daemon의 자동 종료 시간을 지정할 수 있습니다. 10분은 600,000밀리초입니다.
export AGENT_BROWSER_IDLE_TIMEOUT_MS=600000
agent-browser open https://example.com
이 환경 변수는 실행 전에 설정해야 합니다. 0이나 무제한으로 두기보다 짧은 조사 작업은 5~10분, 여러 단계 자동화는 실제 작업 시간에 맞춰 조금 더 길게 설정하는 편이 안전합니다.
4. 성공·실패 경로 모두에서 세션을 닫는다
자동화가 정상적으로 끝났을 때는 마지막 단계에 세션 종료를 넣습니다.
agent-browser close --all
하지만 네트워크 단절, 작업 강제 중단, 시스템 절전처럼 정리 명령이 실행되지 못하는 상황도 있습니다. 그래서 명시적인 close --all과 유휴 종료 시간을 함께 사용해야 합니다.
5. 개인 Chrome 프로필을 직접 공유하지 않는다
평소 사용하는 Chrome 프로필 전체를 자동화의 지속 프로필로 지정하지 않는 편이 좋습니다. 개인 프로필에는 이메일, 결제, 소셜 계정과 관리자 페이지의 로그인 상태가 함께 들어 있을 수 있습니다.
로그인이 필요한 자동화에는 별도 프로필을 사용합니다.
agent-browser --profile ~/.agent-browser-research-profile open https://example.com
작업별로 격리된 세션도 함께 사용할 수 있습니다.
agent-browser --session research open https://example.com
프로필과 세션을 분리해도 프로세스 자동 종료가 보장되는 것은 아닙니다. 격리, 유휴 종료, 명시적 세션 종료를 함께 적용해야 합니다.
브라우저 자동화가 어떤 작업에 적합한지 궁금하다면 Aside로 직접 해본 10가지 브라우저 활용 사례를 참고하세요. 터미널에서 자연어로 브라우저를 다루는 흐름은 Aside CLI 사용법에 정리했습니다. AI 자동화의 입력·권한·복구·관측성을 더 넓게 설계하려면 Harness Engineering 실무 가이드도 이어서 볼 수 있습니다.
자주 묻는 질문
Chrome 프로필이 정말 삭제된 것인지 어떻게 구분하나요?
먼저 ~/Library/Application Support/Google/Chrome 아래의 Default, Profile 1 같은 디렉터리가 남아 있는지 확인하세요. 폴더와 용량이 정상인데 GUI만 열리지 않는다면 프로필 삭제보다 실행 프로세스 충돌을 먼저 의심할 수 있습니다. 폴더를 수정하거나 삭제하지 말고 존재 여부만 확인해야 합니다.
Chrome 재설치로 해결할 수 있나요?
이번 사례에서는 필요하지 않았습니다. 원인이 실행 중인 자동화 프로세스였기 때문에 앱을 다시 설치해도 고아 프로세스가 남아 있으면 같은 증상이 이어질 수 있습니다. 세션과 프로세스를 정리한 뒤에도 실행되지 않을 때 재설치를 검토하세요.
Headless Chrome을 쓰면 항상 이런 문제가 생기나요?
아닙니다. Headless 모드는 정상적인 Chrome 기능입니다. 이번 장애는 시스템 Chrome 앱을 자동화가 함께 사용한 점, 자동화 daemon과 프로세스가 남은 점, macOS가 동일 앱을 이미 실행 중으로 처리한 점이 겹친 사례입니다. Chrome for Testing으로 앱을 분리하고 세션 종료를 관리하면 위험을 크게 줄일 수 있습니다.
Browser Use를 쓴 뒤 Chrome 창이 안 뜨면 같은 문제인가요?
증상만으로 같은 결함이라고 단정할 수는 없습니다. Browser Use를 포함한 다른 브라우저 자동화 도구도 Chrome 또는 Chromium 프로세스를 실행할 수 있으므로, 자동화가 끝난 뒤 --headless=new 프로세스와 임시 사용자 데이터 경로가 남았는지 먼저 확인하세요. 이번 글의 프로세스 수치와 공개 이슈는 agent-browser 사례에 한정됩니다.
활성 상태 보기에서 Chrome Helper가 많으면 모두 문제인가요?
Chrome은 탭, 확장 프로그램, GPU와 네트워크 작업을 여러 프로세스로 나누므로 Helper가 여러 개인 것 자체는 정상입니다. 일반 Chrome을 닫았는데도 수십·수백 개가 장시간 남아 있고, 명령줄에 --headless=new 또는 agent-browser-chrome-이 보일 때 자동화 프로세스 누수를 의심해야 합니다.
마치며
이번 문제는 화면에 보이는 증상과 실제 원인이 완전히 달랐습니다. Chrome 프로필이 사라진 것처럼 보였지만 데이터는 그대로였고, 보이지 않는 자동화 프로세스가 정상 GUI 실행을 가로막고 있었습니다.
자동화용 Headless Chrome 본체 42개와 임시 프로필 기반 프로세스 401개, 이를 유지하던 agent-browser daemon을 정리하자 Chrome과 Aside는 정상으로 돌아왔습니다. 스왑 사용량도 약 3.20GB에서 858.7MB로 줄었습니다.
같은 증상을 만났다면 프로필을 지우기 전에 프로세스부터 확인하세요. 그리고 평소에는 **Chrome for Testing 분리, 짧은 AGENT_BROWSER_IDLE_TIMEOUT_MS, 작업 종료 시 agent-browser close --all**을 기본 원칙으로 두는 것이 좋습니다.