자동 업데이트
문제가 생기면 다시 설치하면 된다고 생각하기 쉽습니다. 사용자가 열 명이면 그렇습니다. 그런데 현장 컴퓨터 수십 대에 깔려 있으면, 고친 것을 반영하는 일 자체가 매번 방문 작업이 됩니다. 그래서 만들 때 같이 넣는 편이 훨씬 쌉니다.
한 문장으로
자동 업데이트는 프로그램이 스스로 새 버전을 확인하고 받아서 교체하는 장치입니다.
하는 일
- 버전 확인 — 새 것이 있는지 스스로 묻기
- 내려받기와 교체 — 사용자를 방해하지 않는 시점에
- 단계적 배포 — 일부에게 먼저 내보내 확인하기
- 되돌리기 — 문제가 생기면 이전 버전으로
- 강제 업데이트 — 반드시 받아야 하는 변경 다루기
- 서명 검증 — 받은 파일이 우리 것인지 확인
하지 않는 일
- 기능 자체 — 업데이트는 전달 방법이지 내용이 아닙니다
- 데이터 이전 — 구조가 바뀔 때는 별도 처리가 필요합니다
- 운영체제 업데이트 — 다른 주체가 하는 일입니다
이웃 개념과 헷갈리는 지점
- 코드 서명만든 사람을 밝히는 절차
- 업데이트 파일도 서명돼 있어야 합니다. 검증 없이 받으면 중간에 바꿔치기당해도 알 수 없습니다.
- OTA앱에서 심사 없이 일부를 교체하는 방식
- 생각은 같고 제약이 다릅니다. 데스크톱은 심사가 없는 대신 사용자 컴퓨터의 권한과 실행 중 교체 문제가 있습니다.
- 배포 서버새 버전을 올려 두는 곳
- 자동 업데이트는 여기를 보고 판단합니다. 폐쇄망이라면 사내에 이 자리를 따로 두어야 합니다.
- 버전 관리무엇이 언제 바뀌었는지 기록
- 되돌릴 버전을 고르려면 이력이 있어야 합니다. 자동 업데이트만 있고 이력이 없으면 되돌릴 곳이 없습니다.
언제 필요한가
이럴 때 필요합니다
- 여러 대에 깔려 있는데 고칠 때마다 방문해야 할 때
- 사용자마다 버전이 달라 문의 대응이 어려울 때
- 급한 수정을 빨리 반영해야 할 때
- 처음 만들 때 — 나중에 붙이는 것보다 훨씬 쌉니다
아직 아니어도 됩니다
- 몇 대뿐이고 직접 관리한다면 굳이 넣지 않아도 됩니다
- 폐쇄망이라 외부에서 받을 수 없다면 사내 배포 방식을 먼저 정해야 합니다
- 이미 배포가 자동이고 되돌리기까지 된다면 손댈 것이 없습니다
여기서부터는 갈립니다
업무 중에 강제로 재시작해도 되는지, 어느 정도 지연을 허용할지는 현장마다 다릅니다. 계산대나 생산 라인처럼 멈추면 안 되는 자리에서는 자동 업데이트가 오히려 사고가 됩니다. 그래서 언제 적용할지를 프로그램이 정할지 관리자가 정할지부터 합의해야 하는데, 그건 기술 판단이 아니라 운영 판단입니다. 여기를 안 정하고 만들면 대부분 자동 업데이트를 꺼 두는 것으로 끝납니다.
자주 묻는 질문
설정하기 나름입니다. 조용히 받아 두고 다음에 켤 때 적용하는 방식이 가장 방해가 적습니다. 다만 중요한 변경은 알리는 편이 낫습니다. 화면이 갑자기 바뀌면 문의가 늘어납니다.
이전 버전으로 되돌립니다. 그래서 되돌리기를 처음부터 넣어 두는 것이 중요합니다. 그리고 전체에 한 번에 내보내지 않고 일부에게 먼저 보내면 피해 범위를 줄일 수 있습니다.
사내에 배포 자리를 따로 두면 됩니다. 외부 인터넷 대신 사내 서버를 보게 하는 방식입니다. 다만 그 서버를 누가 관리할지가 정해져야 합니다.
가능합니다. 특정 버전 미만은 실행을 막고 업데이트를 요구하는 방식입니다. 데이터 구조가 바뀌었을 때처럼 옛 버전이 돌면 안 되는 경우에 씁니다.
필요합니다. 서명 검증이 없으면 받은 파일이 우리 것인지 확인할 방법이 없습니다. 자동으로 받아 실행하는 구조라 오히려 서명이 더 중요합니다.
범위가 애매해도 괜찮습니다
지금 상황만 알려 주시면 필요한 범위와 대략의 규모를 짚어 드립니다.