에이전트는 프로세스를 남기고 갑니다.
AgentsRoom이 그것을 찾아냅니다.
AI 코딩 에이전트는 도구를 호출할 때마다 실제 시스템 프로세스를 띄웁니다. 대부분은 몇 초 만에 끝납니다. 어떤 것은 영영 끝나지 않고, 그런 것 몇 개가 한꺼번에 돌기만 해도 컴퓨터 메모리는 꽉 찹니다.
프로세스 가드는 에이전트의 자식 프로세스를 훑어서 메모리를 먹어치우는 것을 하나씩도 떼로도 알려주고, 어느 에이전트 탓인지 이름을 붙여주고, 그 에이전트를 중단시킬 수 있게 해줍니다. 당신 모르게 종료되는 것은 없습니다.
프로세스 가드가 실제로 보는 것: 한 에이전트가 띄운 프로세스들, 그리고 그중 어느 것이 일을 멈췄는지.
AI 코딩 에이전트는 프로세스 하나가 아닙니다. 에이전트가 도구를 호출할 때마다 당신의 컴퓨터에서 진짜 프로세스가 하나 시작됩니다. 검색, 빌드, 타입 검사, 테스트 실행, 스크립트. 여기에 동시에 돌아가는 에이전트 몇 개를 곱하고 하루를 곱하면, 당신이 한 번도 보지 못한 채 태어나고 묻히는 프로세스가 수백 개가 됩니다.
거의 다 끝납니다. 문제는 끝나지 않는 쪽입니다. 패턴 하나가 정규식 엔진을 터뜨린 검색은 죽지도 않고 느려지지도 않습니다. 메모리를 할당하고, 압축 메모리로 밀려나고, 그다음부터는 커널이 그것을 위해 수 기가바이트를 스왑하는 동안 페이지 폴트만 일으키며 평생을 보냅니다. 절대 끝나지 않습니다. 아무도 죽여주지 않습니다. 그리고 그것을 띄운 에이전트를 닫으면, 이 컴퓨터에서 아무도 책임지지 않는 고아 프로세스가 됩니다.
느려짐이 슬금슬금 스며드는 이유가 이것입니다. 극적으로 망가지는 순간이 있는 게 아니라, 하루에 걸쳐 천천히 쌓입니다. 그리고 바로 이 모양 때문에 사람들은 엉뚱한 범인을 지목합니다. 발열이겠지, 에이전트를 너무 많이 띄웠겠지, 앱에 메모리 누수가 있겠지. 우리가 측정한 세션에서 앱 자체는 프로세스 91개에 2.8GB, 에이전트 CLI 8개는 다 합쳐서 1.6GB였습니다. 둘 다 원인이 아니었습니다.
프로세스 가드는 안전망입니다. 에이전트가 남기고 간 것을 지켜보고, 어느 것이 멈췄고 누가 띄웠는지 알려주고, 끝낼 수 있게 해줍니다. 근본 원인은 계속 바뀔 겁니다. 다른 도구, 다른 패턴, 다른 제공자. 안전망은 바뀌지 않아도 됩니다.
AI 에이전트를 돌리는 컴퓨터가 느려지는 이유
아래 숫자는 에이전트 8개를 돌린 16GB 노트북에서 실제로 측정한 세션의 값입니다. 추정치는 하나도 없습니다.
컴퓨터는 다섯 시간 반째 켜져 있었습니다. 발열 문제는 전혀 없었습니다. 스로틀링 기록은 0, 배터리는 30.6도. 로드 애버리지는 8코어에서 17에서 21 사이였고, CPU는 시간의 56%를 커널에서 보내면서 유휴는 1.5%였습니다. 바로 이 비율이 모든 것을 말해줍니다. 진짜로 일하는 컴퓨터는 사용자 코드에서 시간을 씁니다. 시스템 시간이 56%인 컴퓨터는, 메모리를 압축하고 풀고 스왑하는 일밖에 하지 않는 커널입니다.
멈춘 검색 프로세스 7개가 각각 3.9GB에서 8.0GB씩 붙잡고 있었고, RAM이 16GB인 컴퓨터에서 도합 41.8GB를 점유하고 있었습니다. 스왑은 23.5GB 중 22.3GB, 부팅 이후 스왑에 쓰인 양은 약 993GB였습니다. 그 7개를 종료하자 에이전트를 하나도 재시작하지 않고, 앱도 재시작하지 않고 15.5GB가 즉시 돌아왔습니다.
아무도 이걸 손으로 잡아내지 못하는 이유는, 늘 쓰던 도구들이 이 문제에 대해 거짓말을 하기 때문입니다. macOS에서는 멈춘 프로세스가 실제로는 8GB를 붙잡고 있으면서 실제 메모리 20MB로 표시될 수 있습니다. 그것이 건드린 모든 것이 메모리 압축기를 거쳤기 때문입니다. 우리는 살아 있는 프로세스 하나를 실측했는데, 실제 사용량은 14GB인데 실제 메모리 항목은 4.7GB였습니다. 가상 메모리도 도움이 안 됩니다. 이 플랫폼에서는 launchd조차 가상 크기를 약 440GB로 보고하니, 그것으로 거르면 컴퓨터 전체가 걸립니다.
같은 세션을 시간대별로: 이제 아무도 쓰지 않는 메모리 덩어리들, 그리고 그것을 풀어줬을 때 벌어지는 일.
그리고 이 프로세스들에는 내일도 그 자리에 있을 것을 보장하는 네 가지 성질이 있습니다.
절대 끝나지 않습니다
자기 메모리가 스왑에 있으니 계산 대신 페이지 폴트로 시간을 보냅니다. 그러면서 놀고 있는 것도 아닙니다. 우리가 측정한 폭주 프로세스들은 각각 코어 하나의 10~19%를 태우고 있었고, 그런 것이 쌓일수록 하나가 가져가는 몫은 줄어듭니다. 이 악순환에서 빠져나올 길은 없고, 아무리 기다려도 달라지지 않습니다.
절대 죽지 않습니다
도구 호출에는 시간 제한이 없습니다. 50분째 아무것도 안 하는 프로세스에 대해 이 컴퓨터의 그 무엇도 의견을 갖고 있지 않습니다. 누군가 죽이거나 컴퓨터를 재부팅할 때까지 그대로 앉아 있습니다.
자기를 띄운 에이전트보다 오래 삽니다
에이전트 탭을 닫아도 프로세스는 살아남을 수 있습니다. 그리고 그 연결이 끊기는 방식은 시스템마다 다릅니다. 고전적인 Unix는 init에 다시 붙이고, Linux 데스크톱은 systemd 사용자 관리자에 붙이며, Windows는 아무 데도 붙이지 않고 이미 사라진 부모를 가리킨 채로 내버려 둡니다. 그래서 프로세스 가드는 부모를 아예 보지 않습니다. 연결이 아직 살아 있을 때 거둬들인 것을 기억해 두고, 살아 있는 프로세스 트리에서 사라진 것은 전부 고아 프로세스로 취급합니다. 세 시스템에서 똑같이 그렇게 합니다. 우리가 측정한 7개 중 2개는 이미 그 상태였습니다.
차곡차곡 쌓입니다
검증 한 번에 하나, 운 나쁜 검색 한 번에 하나, 그리고 에이전트가 느린 명령을 멈춘 것으로 착각하고 다시 띄울 때마다 또 하나. 우리는 에이전트 6개가 띄운 타입 검사 12개가 한꺼번에 도는 것을 측정했고, 그중 2개 에이전트는 각자 3개씩 물고 있었습니다. 그래서 느려짐이 하루 내내 심해지기만 하고, 재부팅하면 고쳐진 것처럼 보입니다. 아무것도 고쳐지지 않았습니다. 숫자만 0으로 돌아갔을 뿐입니다.
프로세스 가드가 하는 일
에이전트가 띄운 프로세스를 지켜보고, 손대는 대상은 일부러 아주 좁게 잡았습니다.
진짜 메모리를 측정합니다
실제 메모리 크기가 아닙니다. 그 값은 멈춘 프로세스를 기가바이트 단위로 축소해서 보여줍니다. 프로세스 가드는 압축된 페이지와 스왑으로 빠진 페이지까지 포함한 실제 사용량을 읽으므로, 20MB로 표시되면서 8GB를 붙잡고 있는 프로세스도 있는 그대로 드러납니다.
프로세서를 재되, 믿지는 않습니다
프로세서 사용량은 시스템 도구가 보여주는 전 생애 평균이 아니라 두 번의 검사 사이의 변화율로 읽습니다. 그래서 한참 일하다가 멎어버린 프로세스도 놓치지 않습니다. 이 값이 하는 일은 아직 일하고 있는 것에 더 높은 기준을 요구하는 것뿐이지, 면죄부가 되는 일은 없습니다. 코어 하나의 5분의 1을 태우는 폭주 프로세스야말로 이 가드의 첫 버전이 놓치던 바로 그것입니다.
고아 프로세스를 잡아냅니다
자기를 띄운 에이전트보다 오래 살아남은 프로세스는 그 사실만으로 보고됩니다. 다른 누구도 회수해주지 않기 때문입니다. 소유 관계는 프로세스가 아직 붙어 있는 동안 기억해 둡니다. 그때가 그것을 확정할 수 있는 유일한 순간이기 때문입니다.
클릭 한 번으로 종료
상태 표시줄의 칩이 멈춘 프로세스를 하나씩, 그것을 띄운 에이전트와 메모리, 나이, CPU와 함께 보여줍니다. 하나를 종료하면 그것이 포크한 것까지 함께 끝납니다. 메모리는 곧바로 돌아오고 에이전트는 계속 돌아갑니다.
macOS, Windows, Linux
메모리에 대해 사실대로 말하려면 시스템마다 다른 측정이 필요합니다. macOS는 압축된 페이지, Linux는 실제 메모리에 스왑된 분량을 더한 값, Windows는 프라이빗 커밋. 셋 다 계획이 아니라 이미 구현되어 있습니다.
비용이 거의 없습니다
분당 프로세스 스냅숏 한 번, 프로세스 824개가 도는 컴퓨터에서 약 40밀리초로 측정됐습니다. 비싼 메모리 검사는 이미 멈춘 것처럼 보이는 게 있을 때만 돌고, 활성 에이전트가 없으면 검사 자체가 아예 돌지 않습니다.
튀는 하나가 아니라 떼를 봅니다
각각 1.4GB인 타입 검사 12개면 16GB 컴퓨터에서 16.8GB이고, 그 하나하나는 전부 합리적인 기준 아래에 있습니다. 에이전트들이 띄운 프로세스가 다 합쳐 컴퓨터 물리 메모리의 절반을 채우면, 크기는 더 이상 하나씩 따로 판단되지 않습니다.
책임 있는 에이전트를 짚어줍니다
같은 에이전트에서 걸린 명령이 둘 이상이면 그 아바타 아래에 묶어서, 합쳐서 얼마나 붙잡고 있는지와 어떤 굴레에 빠졌는지 설명하는 경고를 함께 보여줍니다. 명령 하나는 사고지만, 한꺼번에 여러 개는 행동 패턴입니다.
프로세스만이 아니라 에이전트를 중단
에이전트가 한 턴을 진행하는 도중에 프로세스를 끝내면 그 에이전트는 오류를 받고 반응하는데, 대개는 같은 명령을 다시 실행합니다. 버튼 하나로 대신 에이전트의 터미널에 Ctrl+C를 보냅니다. 그 턴이 끝나고, 다시 시작되는 것은 없으며, 에이전트는 열린 채로 남습니다.
늑대야 소리를 하지 않게 만드는 두 가지 규칙
빌드를 신고하는 감시자는 일주일이면 꺼버리는 감시자입니다. 그래서 기준은 일부러 높게 잡았습니다. 당신이 정한 기준보다 오래 살아 있는 에이전트의 자식 프로세스는 하나도 빠짐없이 실제 메모리를 측정하고, 당신이 허용한 양보다 많이 붙잡고 있으면 보고합니다. 아직 프로세서를 쓰고 있는 프로세스는 그 두 배를 붙잡고 있어야 하며, 길지만 정당한 빌드가 방해받지 않는 이유가 바로 이것입니다.
프로세서 사용량은 그 기준의 높이를 정할 뿐, 통과 여부를 가르는 관문이 아닙니다. 이 가드의 첫 버전은 메모리를 들여다보기도 전에 프로세스가 놀고 있기를 요구했는데, 그게 틀렸습니다. 패턴이 정규식 엔진을 터뜨린 검색은 놀고 있지 않습니다. 커널이 그것을 위해 수 기가바이트를 스왑하는 동안 코어 하나의 5분의 1을 태웁니다. 더 나쁜 것은, 그런 것이 쌓일수록 하나가 쓰는 프로세서는 줄어든다는 점입니다. 그래서 사각지대가 가장 넓은 때가 하필 맨 처음, 하나를 끝내는 비용이 가장 쌀 때였습니다.
두 번째 규칙이 있는 이유는, 프로세스마다 매기는 기준으로는 떼를 볼 수 없기 때문입니다. 각각 1.4GB를 붙잡은 타입 검사 12개는 하나씩 보면 멀쩡하지만, 다 합치면 16GB 컴퓨터에 치명적입니다. 그래서 에이전트들이 띄운 것을 전부 더한 값이 컴퓨터 물리 메모리의 절반에 이르면, 하나하나의 크기가 어떻든 그 전부를 보고합니다. 이 무리에 속한 것은 절대 자동으로 종료되지 않습니다. 당신이 정한 한계선 아래에 있고, 옆에 있는 것들 때문에 걸린 것뿐이니까요.
동작 방식
분당 한 번, 네 단계. 그중 비싼 단계는 거의 돌지 않습니다.
컴퓨터를 값싸게 한 장 찍습니다
매분 프로세스 가드는 돌고 있는 모든 프로세스의 스냅숏을 한 장만 찍고, 각 에이전트 터미널 아래의 트리를 훑습니다. 프로세스 824개가 도는 컴퓨터에서 측정된 비용은 약 40밀리초. 돌고 있는 에이전트가 없으면 이 일 자체가 일어나지 않습니다.
용의자를 추립니다
그 스냅숏에서, 당신이 정한 기준보다 오래 살아 있는 에이전트의 자식 프로세스를 하나도 빼지 않고 남깁니다. 필터는 그게 전부이고, 아직 프로세서를 쓴다는 이유로 빠지는 것은 없습니다. 바로 그렇게 걸러냈기 때문에 이 가드의 이전 버전이 폭주 프로세스를 놓쳤습니다. 평소에는 이 목록이 비어 있습니다. 에이전트의 도구 호출은 몇 초 만에 끝나니까요.
멈춘 것처럼 보이는 것만 측정합니다
그 짧은 목록에 대해서만 프로세스 가드는 압축된 페이지와 스왑으로 빠진 페이지를 포함한 진짜 메모리 측정 비용을 치릅니다. 측정하지 못한 프로세스는 절대 신고되지 않습니다. 모르는 것은 판정이 아니기 때문입니다.
알려주고, 판단은 당신에게 맡깁니다
상태 표시줄에 칩이 뜨고 알림이 한 번만 알려줍니다. 목록을 열면 그 프로세스가 무엇인지, 얼마나 붙잡고 있는지, 얼마나 오래 멈춰 있었는지, 어느 에이전트가 띄웠는지가 보이고, 원하면 끝내면 됩니다.
절대 건드리지 않는 것
프로세스를 끝낼 수 있는 도구는 자기 관할을 아주 좁게 정해야 합니다. 아래 한계선은 구조적인 것이지, 당신이 켜는 걸 기억해야 하는 옵션이 아닙니다.
- 에이전트 CLI 자체. 어떤 제공자를 쓰든, 프로세스 가드는 앱이 그 터미널을 띄울 때 사용한 실행 파일을 보호합니다. 그 이름을 하드코딩된 목록이 아니라 실행 자체에서 읽기 때문에, 같은 CLI의 하위 프로세스도 깊이에 상관없이 보호됩니다.
- 당신의 개발 명령 터미널. 가만히 떠 있는 개발 서버는 폭주 프로세스의 조건을 전부 만족합니다. 크고, 오래됐고, 프로세서를 쓰지 않습니다. 그러면서도 당신이 진짜로 돌아가길 바라는 바로 그 프로세스입니다. 감시 대상은 에이전트 터미널뿐이므로, 개발 서버는 애초에 시야에 들어오지 않습니다.
- 셸과 앱 자체의 배관. 터미널 헬퍼와 에이전트가 돌아가는 셸은 구조적으로 제외되어 있습니다. 후보가 될 수 있는 것은 에이전트 CLI 아래에 있는 도구 프로세스뿐입니다.
- 자기가 거두지 않은 것 전부. 프로세스를 끝낼 수 있는 유일한 경로는, 프로세스 가드가 에이전트 자신의 트리에서 주워 오지 않은 프로세스를 모두 거부합니다. 당신 컴퓨터의 다른 무언가를 종료하는 수단이 될 수는 없습니다.
그리고 당신이 요청하지 않는 한 자동으로 종료되는 것은 아무것도 없습니다. 기본값에서 프로세스 가드는 찾아낸 것을 알려주고, 결정은 당신이 합니다. 크고 조용한 프로세스가 예상된 것이었는지 아는 사람은 당신뿐이기 때문입니다. 자동 종료를 켜더라도, 아직 프로세서를 쓰고 있는 것과 옆에 있는 것들이 붙잡은 양 때문에만 걸린 것에는 손대지 않습니다.
제 몫을 하는 순간
여기 있는 것은 전부 실제 상황이고, 가정한 이야기는 하나도 없습니다.
아침 9시보다 저녁 6시에 더 느린 컴퓨터
고장 난 순간이 따로 있는 게 아니라, 하루에 걸쳐 꾸준히 미끄러지기만 합니다. 이 모양은 거의 언제나 멈춘 프로세스가 쌓인 결과이고, 어느 순간을 봐도 이상해 보이지 않기 때문에 손으로 진단하기가 가장 어렵습니다.
여러 에이전트를 동시에 돌릴 때
에이전트를 많이 돌릴수록 도구 호출이 늘고, 그중 하나가 멎을 확률도 늘어납니다. 호출 하나당 실패율은 아주 작지만, 병렬로 일한 하루를 곱하면 더는 작지 않습니다.
돌아오지 않는 검색
정규식 엔진을 터뜨리는 패턴은 몇백 킬로바이트짜리 파일에 대고 기가바이트를 할당합니다. 에이전트는 그것을 기다리고, 당신은 에이전트를 기다리고, 값은 컴퓨터가 두 번 치릅니다.
에이전트는 닫았는데 프로세스는 남았을 때
탭을 닫는다고 늘 뭔가가 풀리는 것은 아닙니다. 이미 떨어져 나간 프로세스는 메모리를 그대로 쥔 채, 앱에서 볼 수 있는 것과의 마지막 연결마저 잃습니다.
16GB 노트북
RAM이 넉넉한 컴퓨터에서는 멈춘 프로세스 몇 개가 오래 숨어 있을 수 있습니다. 16GB 노트북에서는 금방 스왑까지 밀리고, 시스템이 메모리를 압축하기 시작하는 순간부터 모든 에이전트가 한꺼번에 느려집니다.
앱을 탓하기 전에
AgentsRoom을 켜 둔 상태에서 컴퓨터가 기어가면 앱이 제일 먼저 의심받습니다. 프로세스별 실제 숫자를, 각각을 띄운 에이전트와 함께 손에 쥐면 의심은 실제로 확인할 수 있는 것이 됩니다.
한계선은 당신이 정합니다
기본값은 일부러 조심스럽게 잡아뒀습니다. 아래 항목은 모두 설정의 터미널 탭에 있고, 하나하나가 AgentsRoom MCP 도구를 통해 에이전트가 읽고 바꿀 수도 있습니다.
- 에이전트 자식 프로세스 감시
- 기본값은 켜짐. 끄면 검사가 단 한 번도 돌지 않습니다.
- 메모리 기준을 넘으면 알림
- 기본값 2기가바이트. 그 아래라면 멈춘 프로세스 하나 때문에 당신을 방해할 이유가 없습니다. RAM이 넉넉한 워크스테이션에서는 올리고, 메모리가 빠듯한 노트북에서는 내리세요.
- 최소 생존 시간이 지난 뒤에
- 기본값 5분. 그보다 어린 것은 측정조차 하지 않으며, 몇 초 만에 끝나는 에이전트의 평범한 도구 호출이 아예 시야에 들어오지 않는 이유가 바로 이것입니다.
- 멈춘 프로세스 자동 종료
- 기본값은 꺼짐이고, 이건 신중함이라기보다 의도적인 제품 결정입니다. 프로세스 가드는 판단을 내리는 중이고, 크고 조용한 프로세스가 예상된 것이었는지 아는 사람은 당신뿐입니다. 켜면 알아서 처리하고, 처리한 뒤에 알려줍니다.
프로세서 기준값은 노출하지 않았고, 컴퓨터가 포화 상태로 간주되는 지점도 마찬가지입니다. 둘 다 한 번씩 틀렸었고, 취향이 아니라 실제로 벌어진 사고를 측정해서 고친 값입니다. 어느 쪽이든 슬라이더를 달아두면 결국 사각지대를 되돌려 놓는 수단이 될 뿐입니다.
자주 묻는 질문
그러면 AgentsRoom이 내 컴퓨터를 느리게 한다는 뜻인가요?
아닙니다. 그리고 바로 그래서 이 기능이 있습니다. 우리가 측정한 세션에서 앱은 프로세스 91개에 2.8GB, 에이전트 CLI 8개는 다 합쳐 1.6GB를 썼습니다. 41.8GB를 붙잡고 있던 것은 멎어버린 도구 프로세스들이었습니다. AgentsRoom은 마침 모든 에이전트와 그것들이 띄운 모든 프로세스를 한눈에 볼 수 있는 유일한 곳이라, 판정을 내릴 수 있는 유일한 곳이기도 합니다.
내 빌드나 테스트를 죽이지는 않나요?
묻지 않고 끝내는 일은 절대 없습니다. 보고는 할 수 있습니다. 빌드가 보고되려면 당신이 정한 기준의 두 배, 기본값으로는 4기가바이트를 붙잡고 있거나, 컴퓨터 메모리의 절반을 채우고 있는 에이전트 프로세스 무리에 속해 있어야 합니다. 다만 자동 종료는 아직 프로세서를 쓰고 있는 프로세스도, 옆에 있는 것들이 붙잡은 양 때문에만 걸린 프로세스도 절대 건드리지 않습니다. 두 경우 모두 당신에게 오는 것은 한 줄의 항목과 실제 수치와 버튼뿐이고, 누르기 전에는 아무 일도 일어나지 않습니다.
내 개발 서버도 감시하나요?
아니고, 앞으로도 하지 않습니다. 가만히 떠 있는 개발 서버는 폭주 프로세스의 조건을 전부 만족합니다. 메모리를 많이 붙잡고, 몇 시간째 돌고 있고, 요청 사이에는 프로세서를 쓰지 않습니다. 감시 대상은 에이전트 터미널의 자식 프로세스뿐이라, 개발 명령은 구조적으로 범위 밖입니다.
에이전트 자체를 종료할 수도 있나요?
아닙니다. 에이전트 CLI는 어떤 제공자를 쓰든 보호되고, 그 보호는 알려진 이름 목록이 아니라 앱이 그 터미널을 띄울 때 사용한 실행 파일을 근거로 합니다. 셸과 앱 자체의 터미널 헬퍼도 마찬가지로 제외됩니다.
고아 프로세스가 뭔가요? 왜 따로 취급하나요?
부모가 종료된 프로세스는 자기를 띄운 에이전트와의 연결을 잃고, 아무도 치워주지 않습니다. 그 연결이 끊기는 방식은 시스템마다 다릅니다. 고전적인 Unix는 init에 다시 붙이고, Linux 데스크톱은 systemd 사용자 관리자에 붙이며, Windows는 아무 데도 붙이지 않고 죽은 부모 ID만 남겨둡니다. 그래서 AgentsRoom은 부모를 아예 확인하지 않습니다. 프로세스가 아직 붙어 있는 동안 소유 관계를 기록해 두는데, 그때가 그것을 확정할 수 있는 유일한 순간이기 때문입니다. 그리고 살아 있는 프로세스 트리에서 사라진 것은 전부 고아 프로세스로 취급합니다. 세 시스템 모두에서 똑같습니다.
감시 자체의 비용은 얼마나 되나요?
분당 프로세스 스냅숏 한 번, 프로세스 824개가 도는 컴퓨터에서 약 40밀리초로 측정됐습니다. 더 비싼 메모리 측정은 이미 멈춘 것처럼 보이는 프로세스에만 돌기 때문에, 평소에는 돌지 않는다는 뜻입니다. 그리고 활성 에이전트가 없는 동안에는 검사 자체가 존재하지 않습니다.
그냥 활성 상태 보기의 메모리 항목을 보면 되지 않나요?
macOS에서는 그 항목이 문제를 자릿수 단위로 작게 보여주기 때문입니다. 압축 메모리로 밀려난 프로세스는 8GB를 붙잡고 있으면서 실제 메모리 20MB로 표시될 수 있습니다. 우리는 살아 있는 프로세스 하나를 실측했는데, 실제 사용량 14GB에 표시는 4.7GB였습니다. 가상 메모리도 나을 게 없습니다. 시스템 프로세스조차 수백 기가바이트로 보고합니다.
Claude Code, Codex 같은 다른 도구에서도 되나요?
됩니다. 프로세스 가드는 특정 도구나 제공자에 대해 아무것도 모릅니다. 당신이 띄운 에이전트 터미널의 자식 프로세스를 지켜볼 뿐이고, 보호할 CLI는 실행 자체에서 읽어옵니다. 제공자가 늘어나도 여기서 달라지는 것은 없습니다.
Windows와 Linux에서도 되나요?
됩니다. 메모리를 정직하게 재려면 플랫폼마다 다른 측정이 필요합니다. macOS는 압축된 페이지, Linux는 실제 메모리에 스왑된 분량을 더한 값, Windows는 프라이빗 커밋. 셋 다 구현되어 있습니다.
나한테 안 묻고 프로세스를 끝내기도 하나요?
당신이 그 설정을 켜지 않는 한 없습니다. 기본값에서는 찾아낸 것을 에이전트, 메모리, 나이, 프로세서 사용량과 함께 알려주고, 결정은 당신이 합니다. 자동 종료는 설정 항목이고, 처음에는 꺼져 있습니다.
프로세스 하나를 끝내면 그 에이전트는 어떻게 되나요?
에이전트는 계속 돌아갑니다. 그 도구 호출은 영원히 매달려 있는 대신 오류를 받습니다. 그게 바라던 결과입니다. 어차피 그 프로세스는 끝날 리가 없었으니까요. 아무것도 재시작되지 않고 맥락도 잃지 않습니다.
근본 원인까지 고쳐주나요?
아니고, 그러려고 하지도 않습니다. 원인은 바뀝니다. 오늘은 어떤 도구, 내일은 다른 패턴, 다음 달에는 다른 제공자. 이건 안전망이고, 아직 아무도 본 적 없는 원인이 와도 계속 동작하도록 설계했습니다.
프로세스가 12개인데 제 기준을 넘는 건 하나도 없습니다. 그래도 알려주나요?
알려줍니다. 규칙을 바꾼 이유가 바로 그 경우입니다. 16GB 컴퓨터에서 측정한 사례입니다. 에이전트 6개가 띄운 타입 검사 12개가 각각 0.84~1.72GB로 전부 2GB 기준에 한참 못 미쳤지만, 다 합쳐 15.4GB에 스왑은 꽉 찼고 컴퓨터는 쓸 수 없는 상태였습니다. 하나씩 따로 보면 전부 멀쩡했습니다. 총합이 물리 메모리의 절반을 넘는 순간, 그 전부가 띄운 에이전트별로 묶여서 보고됩니다.
“에이전트 중단”은 실제로 무엇을 하나요?
그 에이전트의 터미널로 Ctrl+C를 보냅니다. 당신이 직접 누를 그 키와 똑같습니다. 에이전트의 현재 턴이 끝나고 당신을 기다립니다. 닫히지 않고, 세션도 그대로이며, 컴퓨터의 다른 무엇도 건드리지 않습니다. 이 기능이 있는 이유는, 에이전트가 아직 그 일을 하고 있는데 프로세스만 끝내는 것은 증상만 다루는 일이기 때문입니다. 에이전트는 오류를 받고 자주 그 명령을 그냥 다시 실행합니다.
이런 것도 함께 보세요
컨텍스트 카나리아
또 하나의 조기 경보. 컴퓨터가 아니라 에이전트 자신의 맥락을 지켜보다가, 없는 파일과 API를 지어내기 시작하기 전에 에이전트가 흔들리고 있다고 알려줍니다.
개발 터미널
개발 서버와 오래 걸리는 명령을 AgentsRoom 안에서 돌리고, 긴 작업이 끝나면 알림을 받으세요. 이 터미널이 바로 프로세스 가드가 절대 건드리지 않도록 만들어진 대상입니다.
에이전트 상태 추적
어느 에이전트가 일하고 있고, 어느 것이 당신을 기다리고, 어느 것이 놀고 있는지를 터미널 하나 읽지 않고 한눈에 봅니다.
토큰 사용량
지켜볼 가치가 있는 또 하나의 자원. 에이전트별 토큰 소비와 할당량을 보여주니, 사용량이 어디로 가는지 알 수 있습니다.
분할 보기
창 하나에 여러 에이전트를 나란히 두고, 각자 전용 패널과 색, 실시간 상태를 갖습니다.
CLI Doctor
에이전트가 시작되지 않을 때, 빈 터미널만 남기는 대신 이유와 대처 방법을 알려줍니다.
아무도 쓰지 않는 프로세스에 대가를 치르지 마세요
AgentsRoom은 무료로 내려받을 수 있고, 프로세스 가드는 첫 실행부터 켜져 있습니다.
컴패니언 앱: 이동 중에도 에이전트를 모니터링
Claude, Codex, Antigravity CLI 또는 다른 AI 공급자를 사용하세요.
버그와 요청을 공개 백로그로 바로 보내세요.