채팅별 도구 실행기를 띄우는 Windows 데스크톱 AI 코딩 클라이언트에서 node.exe 95개, 대화형 실행기 21개, 명령 셸 64개가 한 번에 관찰됐다. 합계는 180개였지만 이를 독립 작업 180개로 읽어서는 안 됐다. 프로세스 수와 작업 수가 달랐기 때문이다.
하나의 논리적 도구가 패키지 실행기와 명령 셸 래퍼, Node 런타임으로 나뉘어 목록의 여러 줄을 차지했다. 로그를 부모-자식 관계와 대조하자 실행 시점도 개별 채팅에 연결됐다. 준비 완료 로그가 반복된 횟수만으로 새 프로세스 수를 셀 수 없다는 점도 확인했다.
이 구조에서는 실행 파일 이름만 보고 정리하기 어렵다. 현재 작업은 유지하고 유휴 상태이거나 로드되지 않은 채팅 아홉 개만 보관했다. 프로세스를 강제로 종료하지 않았으며 앱 재시작과 설정 변경도 하지 않았다.
첫 채팅을 보관한 지 2초 뒤 그 채팅에서 확인했던 도구 루트 프로세스 8개가 모두 사라졌다. 아홉 개를 모두 보관한 직후 세 종류의 수는 31개, 6개, 22개로 줄었고 8초 뒤에는 22개, 4개, 16개가 됐다. 초기 스냅샷보다 합계 138개가 적었다.
확인한 것은 이 설치 환경에서 채팅을 보관하면 해당 채팅의 도구 실행기가 정리된다는 동작이었다. 메모리 누수를 입증한 결과는 아니며 체감 끊김이 개선됐는지도 측정하지 않았다. 비슷해 보이는 공개 오류 보고는 도구 시작 실패를 다뤘지만 현재 로그에는 그 오류 신호가 없었다. 같은 원인으로 묶지 않은 이유다.
프로세스 목록으로 증상을 볼 수는 있어도 무엇을 닫아야 하는지까지 알 수는 없다. 먼저 실행기를 소유한 채팅을 추적한 뒤 그 채팅의 수명주기에 맞춰 정리해야 현재 작업과 다른 앱의 Node 프로세스를 건드릴 위험을 줄일 수 있다. 보관한 채팅을 다시 열면 도구가 다시 초기화될 수 있다는 조건도 남는다.