Node ESM 파일을 고쳤는데 옛 코드가 돌았다
2026년 9월 14일 12:55에 시작한 omo 프로세스는 9월 16일에 확인했을 때도 시작할 때 읽은 텔레그램 브리지 확장을 그대로 쓰고 있었다. 그사이 확장 파일을 두 번 고쳤지만 둘 다 실행 중인 프로세스에는 반영되지 않았다. 디스크의 파일과 실행 중인 모듈이 서로 다른 세대일 때 그 차이를 어떻게 대조했는지 기록한다. 대상은 로컬 에이전트나 봇의 Node ESM 확장을 고쳤는데 동작이 그대로인 개발자다. 목표는 수정이 실제로 올라왔는지 판정하고, 무엇을 바꿨을 때 무엇을 다시 띄워야 하는지 구분하는 것이다. 아래는 9월 당시 내 omo 하네스와 OpenClaw 텔레그램 브리지의 기록이다. Node.js ESM 캐시 동작 전반을 따로 실험해 확인한 글은 아니다. 증상: 모델만 바꾸라는 요청이 빈 요청이 됐다 이 브리지에서는 텔레그램으로 /blog --model <선택자> 작업내용 을 보내면 그 요청만 지정 모델로 처리하고, --model-sticky 를 쓰면 모델을 유지한다. 9월 15일 15:55와 16:24에 작업 내용 없이 --model 아스트라 만 보냈다. 두 번 모두 실제 소비 세션은 새 확장을 reload하지 않은 상태였고, 기존 구현이 빈 프롬프트를 세션에 넣은 뒤 최종 답변을 확인하지 못했다는 안내를 보냈다. 이것을 UX 결함으로 보고, 모델만 담긴 요청은 모델을 유지 전환하고 모델 호출 없이 바로 성공 회신하도록 세션 확장을 고쳤다. 원인: 파일은 새것, 프로세스는 9월 14일 것 9월 16일에 다시 확인하니 모델 변경 명령이 안 먹는 진짜 원인은 프로세스 세대였다. omo 프로세스는 9월 14일 12:55에 시작해 그때의 확장을 계속 쓰고 있었다. 9월 15일 16:00의 모델 단독 요청 처리 수정과 9월 16일 08:21의 em/en 대시 허용 수정이 모두 반영되지 않았다. 로더 캐시 버전을 올려도 /reload 나 재시작 전에는 적용되지 않았다. 9월 13일 날짜가 붙은 기록 절에도 이런 주의가 적혀 있다. ...
