탭과 로그인이 사라진 것처럼 보여도 실제 자료가 지워진 것이 아닐 수 있었다. 같은 실행 파일이 다른 사용자 저장 위치를 열면 빈 작업실이 나타난다. 북극성의 경로 수정 기록에서는 파일을 옮기는 것보다 먼저 어떤 저장소를 선택했는지 확인하는 일이 중요했다.
설치 폴더와 자료 폴더를 같은 것으로 보지 않는다
실행 EXE의 위치, 프로젝트 프로그램과 노트북 폴더, 로그인과 탭을 담은 사용자 저장소는 역할이 다르다. runtime-paths는 명시한 절대 폴더 설정을 읽고 없는 설정만 사용자 자료 아래 기본값으로 잡는다. 형식이 잘못됐으면 조용히 새 경로로 대체하지 않고 오류를 낸다.
이 방식은 다른 PC에도 제작자의 드라이브를 강제하지 않으면서 기존 프로그램 경로를 유지하기 위한 선택이었다. 소스 연결 도구도 developmentSource만 바꾸고 나머지 설정을 보존한다. 소스의 위치를 바꿨다는 이유로 프로그램 ID나 기존 원장을 새 폴더의 빈 목록으로 대신하면 연속성이 끊긴다. 경로마다 어떤 자료를 맡는지 먼저 나눠 읽었다.
바로가기만 고친 단계에는 한계가 있었다
0.1.210 기록은 Explorer와 기존 실행 환경의 AppData 실제 위치가 달랐다고 설명한다. 같은 EXE에 기존 userData를 지정해 작업실을 확인하고 바로가기의 경로를 고정했다. 하지만 직접 EXE 실행과 새 설치의 자동 위치 선택까지 고친 것은 아니었다.
이 단계를 전체 제품 수정으로 보고하면 다른 실행 입구에서 같은 문제가 다시 나타난다. 후속0.1.211은 시작 시 앱이 위치 기록을 먼저 읽도록 바꿨다. 로컬 설정 복구와 앱 자체의 선택 규칙 수정을 다른 결과로 남긴 이유다. 정상 재실행 한 번이 모든 실행 방식의 같은 저장소 선택을 증명하는 것은 아니다.
위치 기록은 인증 자료를 복사하지 않는다
현재 시작 코드는 resolveDataLocation 결과를 userData와sessionData에 함께 지정한다. 위치 기록에는 root·폴더 identity·owner·초기화 상태를 두며 웹사이트 쿠키와 원고를 넣지 않는다. 기존 저장소를 선택하는 것과 인증 DB를 새 프로필에 복제하는 것은 다르다.
기록을 읽을 때 실제 폴더 identity와 저장소 존재도 확인한다. 준비된 root가 사라지거나 바뀌고 여러 후보가 모호하면 빈 프로필을 자동 생성해 계속하지 않는다. 명시한 개발·QA 경로는 일반 사용자 pin을 바꾸지 않는 별도 분기다. 이 identity는 해당 파일 시스템 선택의 근거이지 실제 웹 계정 인증을 증명하는 수단은 아니다.
인자 없는 실행과 업데이트를 따로 확인했다
실제0.1.211 보고서는 바탕화면·시작 메뉴·직접 EXE의 인자 없는 실행과 NSIS 업데이트·재설치 뒤 같은 root를 확인했다. 탭13개와 프로젝트3개의 식별자·연결, 실제 사이트 인증과 원고 지문도 각각 근거로 남겼다. 탭 개수 하나로 모든 보존을 대신하지 않았다.
이 결과는 같은 PC와 Windows 사용자, 명시한 실행 경로의 근거다. 다른 PC와 OS 계정 변경, 사이트 만료까지 해결한 보장은 아니다. 기존 선택 핸들이 목표 시작에0개였다는 사실도 유지한다. 예전 다른 검수에서7개가 있었다고 이번에도 보존했다고 쓰지 않는다. 전후 비교의 시작 상태부터 정확해야 했다.
경로 오류는 새 자료를 만드는 신호가 아니다
저장소를 찾지 못했을 때 빈 화면으로 정상 시작하면 사용자는 자료가 사라졌다고 생각하기 쉽다. 명시적으로 멈추고 위치를 확인하게 하는 편이 보존의 의미를 지킨다. 이 오류는 새 로그인이나 새 프로젝트를 자동으로 만들라는 지시가 아니다.
이번 글은 소스와 실제 과거 보고서를 대조했으며 현재 앱 위치나 프로필을 수정하지 않았다. 공유 보존 비교기는 합성 별칭과 지문만 읽고 경로 선택을 구현하지 않는다. 설치할 수 있다는 편의에 더해 어디의 작업을 계속 여는지 설명할 수 있어야 업데이트가 기존 사용자의 시간도 지킬 수 있다. 경로는 설정의 세부사항이면서 업무 연속성의 핵심이었다.