Windows에서 잘 저장되던 설정 파일을 macOS 빌드에서 찾지 못하는 문제가 있었다. 파일 이름도 같고 JSON 내용도 같아서 경로 문자열의 구분자만 바꾸면 될 줄 알았다. 실제로는 앱이 쓸 수 있는 위치, 패키지 안의 읽기 전용 리소스, 사용자 데이터 위치가 플랫폼마다 달랐다.
개발 PC의 프로젝트 폴더를 기준으로 만든 상대 경로가 빌드 뒤에도 존재할 거라는 가정부터 잘못됐다.
경로를 문자열로 이어 붙이지 않았다
"/"나 "\\"를 직접 넣는 대신 플랫폼 API와 Path.Combine을 사용했다.
string settingsPath = Path.Combine(
Application.persistentDataPath,
"settings",
"user.json");
Directory.CreateDirectory(Path.GetDirectoryName(settingsPath));
실행 중 수정할 파일은 영구 데이터 경로에 두고, 앱과 함께 배포되는 초기 파일은 스트리밍 리소스에서 읽어 첫 실행에 복사했다.
파일 이름의 대소문자도 확인했다
개발 환경에서는 우연히 동작하던 Settings.json과 settings.json 차이가 다른 파일 시스템에서 문제를 만들 수 있었다. 코드의 경로와 실제 배포 파일 이름을 같은 규칙으로 맞췄다.
저장 실패 로그에는 전체 사용자 경로를 그대로 남기지 않고 파일 종류, 작업 단계, 예외 종류를 기록했다. 개발 빌드에서만 필요한 경우 안전하게 경로를 확인했다.
쓰기 성공 뒤 읽기까지 검증했다
예외가 없었다고 저장된 것으로 끝내지 않았다. 임시 파일에 쓴 뒤 교체하고, 다시 열어 JSON 헤더와 버전을 확인했다. 앱 종료 후 재실행, 사용자 계정 변경, 이전 파일이 있는 상태도 시험했다.
파일이 깨졌으면 원본을 바로 덮지 않고 복구 가능한 사본을 남긴 뒤 기본 설정으로 시작했다. 복구 정책은 데이터 중요도에 맞춰 정했다.
같은 시나리오를 Windows와 macOS에서 반복해 플랫폼별 결과를 나란히 비교했다.
파일 시스템도 외부 환경이었다
API 서버만 외부 의존성이라고 생각했지만 파일 시스템도 플랫폼과 권한에 따라 행동이 달랐다. 코드가 같은 경로 문자열을 만들었다고 같은 장소를 의미하진 않았다.
이 경험 이후 파일 기능을 만들 때 목표 플랫폼의 쓰기 가능 위치와 수명부터 확인한다. Windows에서 저장됐다는 증거는 macOS 저장의 증거가 아니었다. 작은 경로 문제로 플랫폼 추상화의 이유를 제대로 느꼈다.