원격 소재 패키지에 localhost가 나타나면, 왜 다른 컴퓨터에서는 열리지 않을 수 있을까?

원격 패키지의 소재 주소가 localhost를 가리키면, 컴퓨터를 바꾼 뒤에는 수신자 자신의 컴퓨터로 요청이 갑니다. 제작자 컴퓨터의 서비스는 ZIP과 함께 옮겨지지 않으므로 "내 쪽에서는 재생된다"는 것만으로 다른 사람도 재생할 수 있다고 증명할 수 없습니다. 처리 순서는 실제 요청 주소 확인, 애플리케이션 도메인 대조, 재내보내기, 다른 기기에서 검증입니다.

이 글은 DramaFork가 정리했으며, 현재 프로젝트의 내보내기와 소재 전달 구현 설명에 근거한 문제 해결 방법입니다. 아래의 《안개 항구에서 온 편지》, 포트와 현상은 가상의 교육용 예시이며, 이를 온라인 실측 기록으로 취급하지 않았습니다.

원격 링크 패키지는 여전히 압축을 풀고 패키지 안의 설명에 따라 여는 플레이어 패키지입니다. 영상 등의 리소스를 서버 측에 남겨 두고, 애플리케이션 도메인 아래의 소재 전달 진입점을 통해 읽습니다. 플레이어 페이지는 열리지만 첫 번째 영상 로딩이 실패하는 것과 압축 패키지의 압축을 풀 수 없는 것은 서로 다른 종류의 문제입니다.

먼저 수신자가 받은 패키지 버전, 발생 위치, 네트워크 사용 가능 여부, 페이지에 표시된 원래 메시지를 기록하세요. 플레이어조차 열리지 않았다면 먼저 README.txt에 따라 압축 해제와 시작 방식을 확인하고, 제목과 옵션이 보이는데 영상만 실패한다면 소재 요청을 확인하세요. 위치를 아직 특정하지 않은 상태에서 시나리오, 영상, 도메인을 동시에 수정하지 마세요. 그렇지 않으면 어느 변경이 효과가 있었는지 판단할 수 없습니다.

확인해야 하는 것은 실제 리소스 주소이지, 본문에 이 단어가 나타났는지 여부가 아닙니다. 설명 텍스트가 로컬 테스트 방법을 언급할 수 있지만, 그것이 플레이어가 실제로 로컬 리소스를 요청했다는 뜻은 아닙니다.

가상 예시에서 제작자는 자신의 컴퓨터에서 포트 3000의 서비스를 실행하고, 이 환경에서 원격 패키지를 내보냈습니다. 패키지 안의 영상 주소는 localhost:3000을 사용합니다. 제작자가 열면 주소는 자신의 서비스를 가리키고, 수신자가 열면 수신자 컴퓨터의 3000 포트를 가리킵니다. 수신자가 같은 서비스를 실행하지 않으면 영상을 가져올 수 없습니다.

127.0.0.1도 마찬가지로 로컬 루프백 주소를 나타냅니다. 이를 다른 로컬 포트로 바꿔도 컴퓨터 간 공유 문제는 해결되지 않습니다. LAN 주소는 해당 네트워크에서 도달 가능한 기기만 포괄할 수 있고, 공인 출구 IP만으로도 특정 포트가 외부에서 도달 가능하다고 증명할 수 없습니다. 정식 전달에는 실제로 배포되어 수신자가 접근할 수 있는 애플리케이션 도메인을 사용하고, 구체적인 소재 요청을 검증해야 합니다.

이런 확인은 주소가 누구를 가리키는지, 서비스가 도달 가능한지에 관심을 두며, 수신자가 자신의 컴퓨터에 전체 제작 환경을 복제할 필요는 없습니다.

현재 내보내기 패키지에는 story.json, index.html, 설명과 시작 파일이 포함됩니다. 텍스트 편집기로 스토리 데이터와 플레이어 페이지를 살펴보고 localhost, 127.0.0.1을 검색하여, 해당 항목이 영상이나 다른 소재 주소에 있는지 확인하세요. 먼저 원본 패키지를 보관하고, 검색하면서 일괄 치환하지 마세요.

브라우저 개발자 도구에 익숙하다면, 재생 시 실패한 요청의 도메인과 응답 상황을 확인할 수도 있습니다. 도메인, 노드 위치와 오류 유형만 기록하고, 공개 피드백에 전달 자격 증명이 포함된 소재 링크 전체를 붙이지 마세요.

애플리케이션 첫 페이지가 열린다고 해서 모든 소재 진입점이 정상이라는 뜻은 아닙니다. 첫 페이지와 특정 영상은 서로 다른 요청이므로, 실제 실패한 위치를 따라 계속 확인해야 합니다.

현재 구현은 애플리케이션 주소에 따라 원격 소재 진입점을 생성합니다. 애플리케이션 도메인을 설정했다면 그것이 실제 배포된 서비스를 가리키는지 확인해야 합니다. 로컬 주소를 발견하면 먼저 프로젝트를 유지하는 사람이 배포 도메인을 대조한 뒤 재내보내기하세요. 이전 패키지에 이미 기록된 주소는 프로젝트 설정을 수정했다고 자동으로 갱신되지 않습니다.

패키지 안의 모든 localhost 문자열을 특정 도메인으로 직접 치환하는 것은 권장하지 않습니다. 리소스 진입점은 경로와 접근 자격 증명도 관련되므로, 호스트 이름만 바꿔서 새 서비스가 같은 프로젝트와 소재를 인식한다고 증명할 수 없습니다. 재내보내기 후에는 새 패키지의 실제 요청에서 예상한 도메인을 사용했는지 확인해야 합니다.

새 패키지에 구분 가능한 버전 이름을 붙이고, 수신자에게 어느 파일을 사용할지 알리세요. 두 파일 모두 "최종판"이라고 하면 수신자가 여전히 이전 패키지를 열어, 이미 수정된 문제가 다시 나타날 수 있습니다.

제작 서비스를 실행하지 않는 기기를 선택해 새 원격 패키지의 압축을 풀고, 설명에 따라 시작하고, 네트워크에 연결된 상태를 유지하세요. 최소한 오프닝, 선택 지점 하나, 선택 후 다음 영상까지 확인하세요. 오프닝만 검증하면 이후 노드의 이전 리소스 주소를 놓칠 수 있습니다.

결과를 기록으로 작성하세요: 패키지 버전, 기기와 네트워크, 거친 선택, 로딩 성공 여부, 실패가 어디서 발생했는지. "검증 대기"와 "검증 완료"는 구분해야 하며, 다른 기기가 없으면 이 공백을 남겨 두고 원래 컴퓨터 재생으로 수신자 검수를 대체할 수 없습니다.

원격 패키지는 네트워크와 소재 서비스가 지속적으로 사용 가능한 것에 의존합니다. 안정적인 전달 진입점은 영구 서비스 보장으로 해석될 수 없습니다. 수신자가 완전히 오프라인이어야 한다면 로컬 소재 패키지로 바꾸고 설명에 따라 오프라인 재생을 검증해야 합니다. 이는 전달 조건이 바뀐 뒤의 선택이며, 원격 도메인 수정으로 달성할 수 없습니다.

다음 전달 전에 먼저 원본 패키지를 보관하고, 실제 실패 요청 하나를 확인한 뒤, 재내보내기하고 같은 경로를 테스트하세요. 이렇게 하면 피드백이 명확한 버전과 명확한 리소스에 대응될 수 있습니다.