AI 코딩 에이전트로 백그라운드 프로그램을 띄우면 몇 초 뒤 사라지는 이유 — 버그가 아니라 에이전트 셸의 프로세스 정리였다
윈도우에서 늘 대기하다가 "Hey Jarvis"라고 부르면 말을 받아 적어 Claude Code에 넘기고 답을 읽어 주는 로컬 음성 비서(voice-assistant)를 쓰고 있었다. 어느 날 재부팅 뒤 비서가 떠 있지 않아서 AI 코딩 에이전트에게 원인을 찾게 했다. 그런데 에이전트가 직접 띄워 본 프로세스도 20초쯤 지나면 계속 사라졌다. 그래서 "떠도 바로 죽는 버그"처럼 보였다.
결론
에이전트 셸에서 띄운 백그라운드 프로세스가 사라졌다고 해서 프로그램이 죽었다고 단정하면 안 된다. 에이전트의 명령 실행 환경이 호출이 끝날 때 자기가 띄운 자식 프로세스를 함께 정리했을 수 있다. 이 사건에서는 같은 프로그램을 에이전트 셸에서 띄우면 사라졌지만, 셸 밖(WMI)에서 띄우니 30초 내내 살아 있었고 로그도 계속 쌓였다 .
"떠서 죽는다"고 결론 내기 전에 다음 세 가지로 실행 환경 탓인지부터 가른다.
- 띄우는 호출과 확인하는 호출을 나눈다. 띄우는 명령은 바로 반환시키고, 살아 있는지는 별도 호출에서 확인한다
- 프로세스 목록만 보지 말고 로그가 늘어나는지도 본다. 한 호출 안에서 로그 파일 크기와 프로세스 등장·소멸을 촘촘히 추적한다
- 에이전트 셸의 프로세스 트리 밖에서 띄워 본다. 거기서 살아남는다면 코드가 아니라 실행 환경 문제다
3번을 PowerShell로 하면 다음과 같다. 일반적인 예시이고, 세션에서 실행한 명령 원문은 아니다.
# 에이전트 셸의 자식이 아니라 WMI(CIM)가 새 프로세스를 만든다
Invoke-CimMethod -ClassName Win32_Process -MethodName Create `
-Arguments @{ CommandLine = 'cmd /c "C:\path\to\start_assistant.bat"' }
# 다음 호출에서 따로 확인: 프로세스가 있고, 로그가 늘어나는가
Get-Process pythonw -ErrorAction SilentlyContinue
(Get-Item C:\path\to\data\main_log.txt).Length
정확히 어떤 메커니즘(예: Windows job object)이 프로세스를 정리했는지는 이 사건에서 확인하지 못했다. 에이전트의 추정이었다 . 그래도 셸 안에서 띄웠을 때와 밖에서 띄웠을 때 결과가 다르다는 사실만으로 가짜 실패를 걸러 낼 수 있었다.
상황
- 음성 비서는 venv의
pythonw.exe(콘솔 창 없이 도는 파이썬)로 상주한다 - 자동 시작은 시작 프로그램 폴더의 바로가기
VoiceAssistant.lnk가start_assistant_hidden.vbs를 실행하고, 그 VBS가 배치(bat)를 띄우고, 배치가pythonw를 실행하는 구조다 - 대시보드 서버도
DashboardServer.lnk로 같은 방식으로 뜬다 - 조사는 AI 코딩 에이전트가 자기 셸에서 PowerShell 명령을 실행하면서 진행했다
증상
- 시작 프로그램 폴더에
VoiceAssistant.lnk가 그대로 있는데pythonw.exe가 하나도 없었다. 비서도 대시보드도 돌지 않았다 main_log.txt의 마지막 기록은 8월 23일이었고 조사한 날은 8월 27일이었다 . PC는 그날 00:19에 재부팅됐고, 조사는 부팅 7분 뒤에 시작했다- 원인을 찾으려고 에이전트가 직접 띄워 봤더니 프로세스가 없고 로그에도 새 줄이 없었다 . bat/vbs 경로로 띄워도 25초가 지나도록 뜨지 않았다 . vbs로 띄우면 20초 뒤에 사라졌다
원인
진단에 쓰던 에이전트의 실행 환경이 자기가 띄운 프로세스를 정리하고 있었다. 이 때문에 멀쩡한 프로그램이 죽는 것처럼 보였다.
- 콘솔
python.exe로 실행하면 45초가 지나도 죽지 않고 호출어 대기 루프까지 들어갔다. 장치 인식과 "준비 완료"도 확인됐다 . 코드는 정상이었다 - 실제 bat을
cmd /c로 돌리자 40초 넘게 끝나지 않고 블록됐다. cmd가 pythonw가 끝나기를 기다린다는 뜻이니 pythonw는 살아 있었다 . 로그에도 "준비 완료. Hey Jarvis"가 찍혔다 - 그런데 그 백그라운드 태스크가 끝나자
cmd /c bat도 exit 255로 함께 끝났다 - 띄우는 호출과 확인하는 호출을 나눠도 pythonw는 없었다 . WMI로 띄운 첫 시도도 18초 뒤 사라졌다 . 하지만 WMI로
cmd /c bat을 띄우자 30초 내내 pythonw 2개가 살아 있었고 로그도 60615→60777바이트로 늘었다
한계도 있다. vbs 경로는 끝까지 깔끔하게 설명되지 않았다. 같은 세션에서 vbs를 띄운 한 번은 로그가 전혀 늘지 않았고 , 다른 한 번은 로그에 새 "준비 완료"가 찍힌 뒤 20초 만에 사라졌다 . 에이전트는 이것을 "wscript가 곧바로 종료되면서 정리된 것"이며, 부팅 때 explorer가 띄우는 실제 상황과는 다르다고 해석했다 . 이 해석도 검증된 것은 아니다.
해결
- 비서와 대시보드는 설정을 바꾸지 않고, 에이전트 셸 밖에서
pythonw를 창 없이 직접 띄워 되살렸다. 비서는 pid 19652로 대기 상태가 됐고, 대시보드는 로컬 포트 8787에서 HTTP 200을 돌려줬다 - 부작용이 있었다. 이렇게 띄우면 bat의 출력 리다이렉트를 거치지 않으므로
main_log.txt에 stdout이 쌓이지 않는다. 대화 기록(conversation_log.jsonl)은 정상으로 남는다 - 정작 부팅 때 자동 시작이 왜 안 됐는지는 이 세션에서 확정하지 못했다. 확인한 것은 바로가기가 있고, 작업 관리자에서 비활성화되지 않았고(두 항목이 비활성 목록에 없었다), 코드·스크립트·장치 인식이 정상이라는 점까지다 . 에이전트는 "재현이 안 돼서 딱 잘라 말하긴 어렵다"고 적었고, 다음에도 안 뜨면 작업 스케줄러로 옮기자고 제안했다
덤 — 가짜 단서는 하나 더 있었다
pythonw 실행을 테스트하던 중 error: unrecognized arguments: USB Audio가 떴다. 입력 장치 인자 --device "KT USB Audio"가 공백에서 쪼개져 argparse가 죽은 것으로 보였다 . 하지만 실제 bat을 그대로 돌리자 정상이었다. 그 에러는 테스트용 PowerShell Start-Process 명령의 인용부호 문제였다 .
두 가짜 단서의 뿌리는 같다. 진단하려고 만든 실행 경로가 실제 실행 경로와 달랐다.
다음 날 같은 증상이 다시 나타났을 때, 다른 조사에서는 wscript로 VBS를 네 번 돌려 네 번 모두 실패하자 "부팅 실패를 그대로 재현했다"고 판단했다 . 그런데 바로 다음 실행은 같은 경로로 성공했다 . 그 조사에는 에이전트 셸 밖에서 wscript를 돌려 보는 테스트 기록이 없다. 그래서 그 "4/4 재현"이 실제 부팅 실패와 같은 원인인지, 셸의 프로세스 정리 때문인지는 구분되지 않는다. 이 부분은 두 조사를 대조한 판단이며 검증된 사실은 아니다.
취재 후기 — 범인은 우리 손에 든 돋보기였다
박도은pythonw가 하나도 없어. 로그도 8월 23일에서 멈췄어 
정바다박도은VoiceAssistant.lnk가 그대로 있어. 가리키는 곳도 숨김 실행용 VBS 그대로고 
정하늘박도은정바다pythonw라 에러가 안 보이는 거야.정하늘python.exe로 돌려 보면 가려져. 죽는다면 에러가 화면에 찍힐 테니까.박도은정하늘pythonw로 띄우는 bat·vbs 경로야.박도은Start-Process로 pythonw를 띄웠더니 unrecognized arguments: USB Audio가 나왔어 정바다정하늘cmd /c로 그대로 돌려 보면 갈려.박도은정하늘
박도현박도은정바다정하늘박도은박도은cmd /c bat을 띄우니까 30초 내내 pythonw 두 개가 살아 있어. 로그도 60615에서 60777바이트로 늘었어 정하늘정바다박도은정하늘박도현박도현