Project Hive X

배경

• 이 일감은 앱 업데이트 기능을 바로 구현하는 개발 일감이 아니라, 데스크톱 앱 업데이트 정책과 사용자 경험을 결정하기 위한 전략/기획 일감이다.
• Windows/macOS 대상 Electron 앱 배포에서 업데이트 확인, 다운로드, 적용 시점, 트래픽 제어, 사용자 노출 방식을 어떻게 가져갈지 먼저 정리한다.

논의 범위

• 카나리 배포 전략: 전체 사용자에게 즉시 배포하지 않고 일부 사용자/버전/조직 단위로 단계적 배포할지 결정한다.
• 지연 업데이트 전략: 사용자별 업데이트 확인 또는 다운로드 시점을 분산해 특정 시간대에 트래픽이 몰리지 않도록 한다.
• 대역폭 제약 업데이트: 네트워크 트래픽 부담을 줄이기 위해 다운로드 속도 제한, 백그라운드 다운로드, 업무 시간 회피, 재시도 간격 등을 검토한다.
• 다운로드 완료 후 UX: 업데이트 파일 다운로드가 끝난 뒤 즉시 설치를 강제할지, “업데이트” 버튼을 노출해 사용자가 적용 시점을 선택하게 할지 결정한다.
• 업데이트 상태 표시: 확인 중, 다운로드 중, 다운로드 완료, 재시작 필요, 실패/재시도 같은 상태를 앱 UI 어디에 어떤 톤으로 보여줄지 정한다.
• 실패 및 롤백 관점: 다운로드 실패, 검증 실패, 설치 실패, 카나리 중단, 이전 버전 유지 정책을 정리한다.
• 엔터프라이즈 배포 관점: requirements.toml 또는 배포 정책에서 업데이트 채널, 허용 버전, 강제 업데이트 여부, 네트워크 제약 정책을 제어할 필요가 있는지 검토한다.

결정해야 할 질문

• 기본 업데이트 채널은 stable/canary를 어떻게 나눌 것인가?
• 카나리 대상 비율과 확대 조건은 무엇인가?
• 업데이트 확인/다운로드를 얼마나 지연 또는 분산할 것인가?
• 대역폭 제한이 필요한 경우 기본 제한값과 예외 조건은 무엇인가?
• 다운로드 완료 후 사용자에게 어떤 버튼/상태 문구를 보여줄 것인가?
• 보안/중요 업데이트는 일반 업데이트와 다른 강제 정책을 가질 것인가?

산출물

• 앱 업데이트 정책 초안
• 카나리 배포 및 확대/중단 기준
• 네트워크 트래픽 부담 완화 전략
• 다운로드 완료 이후 사용자 노출/버튼/재시작 UX 방향
• 구현 단계에서 필요한 설정 키와 UI 상태 목록

완료 기준

• 업데이트 구현 전에 따라갈 수 있는 정책 문서 또는 결정안이 정리된다.
• 카나리 배포, 지연 업데이트, 대역폭 제약, 다운로드 완료 후 업데이트 버튼 노출 여부가 각각 결정된다.
• 이후 개발 일감으로 쪼갤 수 있을 만큼 요구사항과 우선순위가 명확해진다.