왜 필요한가

“내 컴퓨터에서는 된다”만으로는 사용자가 제품을 얻는 방법도, 실패했을 때 복구할 사람도 알 수 없습니다. 브라우저 페이지, 내려받는 게임, 온라인 멀티플레이 서비스는 전달과 운영 방식이 다릅니다. 원하는 사용자 경험을 반복 가능한 공개 절차와 복구 가능한 실행 환경으로 연결해야 합니다.

어떻게 해결하는가

  1. 사용자가 어디서 실행하고 어떻게 받을지 정합니다. 공개 카탈로그는 URL로 열고, 데스크톱 게임은 설치 파일이나 스토어로 받을 수 있습니다. 온라인 기능은 설치된 클라이언트와 별개로 계속 실행되는 서비스가 필요할 수도 있습니다. “앱을 배포한다”라는 한마디 안의 서로 다른 책임을 풀어 적습니다.
  2. 인프라를 고르기 전에 예산, 운영에 쓸 시간, 허용 중단 시간, 데이터 손실 허용 범위, 복구 담당을 합의합니다. 이는 프로젝트 결정입니다. AI는 이 범위 안에서 절차를 정할 수 있지만, 추가 유료 자원이나 가용성 변경은 해당 권한과 결정을 확인해야 합니다. 익숙한 제품부터 골라 제약을 뒤늦게 맞추지 않습니다.
  3. 소스부터 사용자까지 릴리스 하나를 따라갑니다. 재현 가능한 결과물을 만들고 미리보기나 시험 환경에서 검증하며 버전과 설정을 기록합니다. 개발 프로세스만 보지 말고 실제 제공할 주소나 설치 패키지를 확인합니다. 비밀정보와 환경별 설정을 공개 결과물에 넣지 않습니다. 결과물과 검증 대상이 같은지도 확인합니다.
  4. 전환 전에 실패를 계획합니다. 어떤 신호에서 중단할지, 누가 대응할지, 이전의 사용 가능한 상태로 어떻게 돌아갈지 정합니다. 트래픽을 이전 프로그램으로 돌려도 새 데이터베이스 기록이 자동으로 취소되지는 않습니다. 프로그램 파일 교체와 데이터의 호환성·복구를 따로 확인해야 합니다.
  5. 일부 사용자부터 노출하는 방식이 필요하다면 비교 대상, 측정 기간, 확대할 근거를 정합니다. 요청이 없거나 관측값이 빠진 상태는 성공이 아니라 불확실성입니다. 작은 사이트라면 큰 점진 배포 시스템보다 미리보기와 전환 절차가 적합할 수 있습니다. 절차의 복잡성은 실제 실패 비용과 운영 능력에 맞춥니다.

결과물, 대상, 검증, 중단 조건, 복구 순서, 담당자를 짧은 운영 절차서로 남깁니다. 가능하면 안전한 환경에서 필요한 복구를 연습하고 시험하지 못한 부분도 솔직하게 기록합니다. 다른 담당자가 따라 하며 실패를 알아볼 수 있어야 계획이 구체적입니다. 계획 작성 자체가 배포 허가는 아니므로 이미 허가된 공개 작업의 범위 안에서 실행합니다.

Browser ← URLMobile ← StorePC ← DownloadConsole ← Platform

무엇이라 부르는가

런타임은 실행되는 곳, 배포 경로는 사용자가 얻는 방법, 호스팅은 파일이나 서비스를 제공하는 역할입니다. 배포와 릴리스 절차가 이 책임을 연결합니다. Google SRE의 카나리 지침은 제한된 노출에서 평가하는 방법을 설명합니다. 호스팅 상품명이나 교체 방식의 이름을 전체 계획으로 여기지 말고 합의한 운영·복구 조건을 만족하는 절차를 선택합니다.