AI 비서 업데이트 순서: 기준선, 복원 시험, 전환, 실행 확인

5월에는 교체보다 지금 잘되는 이유를 먼저 남겼어요

5월 11일에는 공통 실행 환경과 현재 수정 사항을 확인하고 업데이트 방향을 잡았어요. 기존 수정은 모두 지워도 되는 임시 코드로 볼 수 없었고, 예전에 필요했다는 이유만으로 그대로 옮길 수도 없었어요. 지금 동작을 만드는 이유를 알아야 유지할 것과 새 버전에서 다시 살필 것을 나눌 수 있었어요. 첫 작업에서는 최신 개발 상태를 설치하고 운영을 확인했는데, 목표로 삼은 정식 배포 버전과는 차이가 있었어요. 그래서 다음 날 정식 배포 버전에 맞추고 프로필을 다시 시작한 상태를 확인했어요. 무엇을 최신이라 부를지 정해 두면 나중에 이상이 생겼을 때 실제로 운영한 상태와 비교할 수 있어요.

같은 날 업데이트 뒤 점검에서는 다른 층의 문제가 드러났어요. 서비스의 작업 위치가 프로젝트 루트를 기준으로 잡히는 상황 때문에, 새 버전이 작동하는데도 상태가 오래된 것처럼 읽힐 수 있었어요. 서비스는 설치된 파일만으로 시작되지 않고, 어디에서 어떤 조건으로 실행되는지도 영향을 줘요. 상위 변경에 관련 수정이 있는지, 지금 운영에 가져올 수 있는지 검토했고, 이 작업은 진단과 수정 후보 검토 단계까지 진행됐어요. 적용할 수 있는 수정과 실제로 적용한 수정은 따로 적어 뒀어요.

6월에는 백업을 실제로 되돌려 본 뒤에 전환했어요

6월 업데이트에서는 기존 대화와 기록, 예약 작업을 잃지 않는 것이 가장 중요했어요. 현재 상태를 기준선으로 남기고, 실제 운영은 그대로 둔 채 별도 환경에서 보관한 자료로 다시 구성해 봤어요. 비교해 보니 일부 상태가 일치하지 않았는데, 운영 중인 서비스가 백업하는 동안에도 실행 기록을 바꾸고 있었기 때문이에요. 이 차이를 덮지 않고 보관한 시점과 변하는 상태의 관계를 다시 확인했어요. 새 환경 후보에서는 상태 확인과 운영 방식 차이로 일부 시험이 실패했고, 실제 결함과 다른 운영체제를 전제로 한 시험을 구분하는 동안 교체를 보류했어요.

후보 점검이 진행된 뒤 실제 운영을 새 환경으로 전환했어요. 프로필이 실행 중인지, 기록이 유지됐는지, 대화 맥락에 필요한 상태가 남았는지 확인한 기록이 있어요. 기록을 복원할 때 함께 움직여야 하는 상태의 일관성도 전환 중에 다시 봤어요.

전환 뒤에는 숫자보다 요청을 처리하는 서비스를 확인했어요

6월 30일 Windows 점검에서 명령으로 버전을 확인하니 이전 숫자가 나왔어요. 롤백된 것처럼 보였지만, 실제 메시지를 처리하는 서비스가 참조하는 실행 환경을 살펴보니 새 배포 상태를 쓰고 있었어요. 같은 컴퓨터 안에서 확인 명령이 오래된 실행 파일을 가리키고 있었던 거예요. 실행 중인 프로세스도 함께 보며 새 서비스와 오래된 서비스가 동시에 요청을 받는지, 설정과 기록이 어느 쪽에 연결되는지 확인했어요. 점검 기록에는 실제 서비스가 새 환경으로 작동하고 설정과 기록, 예약 상태도 정상이라는 결과가 남았어요. 실행 경로를 먼저 본 덕분에 불필요한 재설치를 피할 수 있었어요.

이어 보면 순서가 남아요. 교체 전에 지금 잘되는 이유와 선택한 배포 버전을 기준선으로 적고, 서비스가 어떤 조건으로 시작되는지 따로 보고, 백업은 실제로 되돌려 본 뒤에 전환하고, 마지막에는 요청이 지나가는 경로에서 새 환경이 쓰이는지 확인해요. 단계마다 적용과 운영과 후속 관찰을 나눠 적어 두면 다음 문제가 생겨도 같은 시작점에서 비교할 수 있어요.

단계마다 남은 한계도 분명해요. 5월 업데이트는 적용과 즉시 운영 상태까지 확인했고, 이후 모든 예약 작업과 대화에서 문제가 없었다는 장기 관찰 결과는 그 작업에 포함되지 않아요. 시작 조건 문제는 진단과 수정 후보 검토까지이고, 그 수정을 반영해 서비스를 다시 시작한 결과는 기록에 없어요. 6월 전환 직후에는 다음 자연 예약 실행과 메시지 재연결을 관찰할 일이 남아 있었어요. Windows의 확인 명령이 오래된 버전을 보여 주는 표시 문제도 그때는 정리하지 못했고, 실제 실행 상태를 확인하고 차이를 설명한 데서 멈췄어요.