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