사이트를 중단하지 않고 업데이트할 수 있을까요?

기존 웹사이트를 계속 이용할 수 있는 상태로 많은 업데이트를 배포할 수 있습니다. 콘텐츠와 디자인 변경, 새 페이지, 충분히 준비된 소프트웨어 버전은 대체로 이런 방식이 가능합니다.

모든 변경에 적용되는 보장은 아닙니다. 진행 중인 주문, 회원 계정, 호환되지 않는 소프트웨어 버전, 인프라 또는 외부 서비스와 관련된 업데이트는 정해진 점검 시간이 필요할 수 있습니다. 중요한 질문은 단지 사이트가 온라인 상태인지가 아닙니다. 무엇을 계속 이용할 수 있는지, 변경을 어떻게 확인할지, 예상대로 작동하지 않을 때 어떻게 할지를 알아야 합니다.

사이트 운영 중에 할 수 있는 업데이트는 무엇인가요?

문구 수정, 이미지 교체, 새 글과 페이지, 개별적인 디자인 조정은 전체 사이트를 중단하지 않고 준비해 배포할 수 있는 경우가 많습니다. 사이트와 배포 절차가 지원한다면 작은 소프트웨어 변경도 같은 방식으로 배포할 수 있습니다.

업데이트의 종류만으로는 판단할 수 없습니다. 일반적인 콘텐츠 수정도 어떤 사이트에서는 메뉴, 검색, 캐시된 페이지, 생성 파일에 영향을 줄 수 있고, 다른 사이트에서는 한 페이지에만 영향을 줄 수 있습니다. 익숙한 작업이라도 해당 시스템의 맥락에서 확인해야 합니다.

‘온라인’이라는 말에도 실질적인 의미가 필요합니다. 홈페이지가 정상적으로 열려도 문의, 결제, 로그인, 검색, 관리 기능이 계속 작동한다고 볼 수는 없습니다. 비즈니스에 중요한 기능은 각각 확인해야 합니다.

스테이징 사이트는 무엇을 보호하나요?

스테이징 사이트는 변경 사항을 방문자에게 공개하기 전에 준비하고 검토하는 별도 환경입니다. 작업 중 미완성 레이아웃, 작성 중인 문구, 명백한 기능 오류가 공개 사이트에 나타나는 일을 방지하는 데 도움이 됩니다.

스테이징은 불확실성을 줄이지만 없애지는 못합니다. 스테이징 사본은 데이터, 트래픽, 구성, 인증 정보, 연결된 서비스, 서버 자원이 실제 환경과 다를 수 있습니다. 테스트 성공은 유용한 근거지만 실제 운영 환경도 똑같이 동작한다는 보장은 아닙니다.

배포 계획에는 변경 사항을 공개 사이트에 적용한 뒤 무엇을 점검할지도 포함해야 합니다.

빈 페이지 없이 새 버전으로 바꾸려면 어떻게 해야 하나요?

기존 버전이 방문자를 계속 처리하는 동안 새 버전을 별도 환경에서 준비할 수 있습니다. 준비된 버전을 테스트한 다음에만 트래픽을 전환합니다. 심각한 문제가 생기면 이전 버전으로 트래픽을 돌릴 수도 있습니다.

이 방식은 보통 블루-그린 배포라고 합니다. AWS는 이 방법을 서로 다른 애플리케이션 버전을 실행하는 두 환경 사이에서 트래픽을 전환하는 방식으로 설명합니다. 목표는 중단 시간을 거의 없애고 이전 환경으로 더 빠르게 돌아가는 것입니다.

블루-그린 배포만이 업데이트 방법은 아닙니다. 일부 시스템은 파일을 원자적으로 교체하거나, 서버를 한 대씩 업데이트하거나, 트래픽 일부만 새 버전으로 보내거나, 필요한 지원 작업이 끝난 뒤 완성된 기능을 켭니다. 적절한 방법은 사이트, 호스팅, 데이터, 변경 실패 시의 결과에 따라 달라집니다.

데이터베이스 변경은 왜 다른가요?

데이터베이스에는 현재 주문, 계정, 예약, 양식 제출 내용, 재고, 회원 정보, 게시된 콘텐츠가 들어 있을 수 있습니다. 배포 중에는 이전 버전과 새 버전 모두 해당 데이터를 사용할 수 있어야 할 수 있습니다.

데이터베이스 구조를 한 소프트웨어 버전만 이해할 수 있게 바꾸면 이전 버전으로 돌아가는 일이 간단하지 않을 수 있습니다. 오래 걸리는 변경 작업은 사이트의 정상 활동과 자원을 두고 경쟁할 수도 있습니다. 그래서 일부 배포에서는 데이터베이스 준비와 애플리케이션 업데이트를 분리하거나, 일정 기간 이전 구조와 새 구조의 호환성을 유지하거나, 데이터를 통제된 단위로 옮깁니다.

GitLab의 공개 데이터베이스 마이그레이션 지침은 이런 계획이 얼마나 세밀해질 수 있는지 보여줍니다. 일반, 배포 후, 백그라운드 마이그레이션을 구분하고 시점, 되돌릴 수 있는지, 트랜잭션, 잠금 경합을 고려하도록 합니다. 이런 구체적인 방법이 모든 사이트에 맞지는 않지만, 실시간 데이터 변경에는 별도의 배포 및 복구 계획이 필요하다는 원칙은 폭넓게 유용합니다.

백업은 롤백과 같은 뜻인가요?

아닙니다. 백업은 복원할 수 있도록 보관한 데이터나 파일의 사본입니다. 롤백은 배포 실패 후 알려진 정상 상태로 돌아가기 위해 준비된 절차입니다.

백업을 복원하는 데 시간이 걸릴 수 있고, 백업 생성 후 발생한 유효한 주문, 문의, 편집, 계정 변경을 덮어쓸 수도 있습니다. 사이트 코드는 빠르게 되돌릴 수 있어도 데이터베이스 변경이나 외부 결제, 예약, 이메일 서비스가 이미 완료한 작업까지 취소하지 못할 수 있습니다.

책임 있는 계획은 되돌릴 수 있는 것, 추가 변경으로 복구해야 하는 것, 변경 중 만들어진 데이터를 처리하는 방법을 정합니다. AWS의 실패한 변경에 관한 지침은 배포 전에 복구 절차를 준비하고 모니터링을 통해 변경의 성공 여부를 판단하라고 권합니다.

업데이트 후에도 이전 페이지가 보이는 이유는 무엇인가요?

업데이트 내내 사이트가 이용 가능하더라도 방문자마다 페이지나 파일의 다른 버전을 잠시 받을 수 있습니다. 브라우저, 콘텐츠 전송 네트워크, 서버 캐시, 생성된 페이지는 만료되거나 다시 검증되거나 의도적으로 지워질 때까지 이전 콘텐츠를 보관할 수 있습니다.

이는 서비스 중단과는 다릅니다. 그래도 가격, 약관, 캠페인 정보, 재고 또는 시점이 중요한 다른 내용을 바꾸는 경우에는 중요합니다.

캐시 삭제 범위도 적절해야 합니다. Cloudflare는 가능한 경우 필요한 항목만 삭제하라고 권합니다. 전체 캐시를 지우면 콘텐츠가 다시 캐시될 때까지 이후 요청이 원본 서버로 돌아가기 때문입니다. 배포 계획은 모든 캐시를 한꺼번에 버릴 대상으로 취급하지 말고 변경된 페이지와 파일을 지정해야 합니다.

유지보수 시간을 정하는 것이 책임 있는 선택인 때는 언제인가요?

업데이트 중에도 사이트를 완전히 운영하는 위험이 짧고 사전 공지된 중단보다 클 때 유지보수 시간이 적절할 수 있습니다. 예를 들면 다음과 같습니다.

• 업데이트 중 실시간 데이터를 안전하게 변경할 수 없는 경우
• 이전 버전과 새 버전이 같은 데이터 구조로 작동할 수 없는 경우
• 인프라 또는 네트워크 경로를 한 번의 통제된 절차로 변경해야 하는 경우
• 외부 제공업체가 중단을 요구하거나 병행 테스트 경로가 없는 경우
• 현재 사이트를 충분히 파악하지 못해 안전한 실시간 변경을 뒷받침하기 어려운 경우
• 정해진 시간 동안 활동을 멈추는 편이 더 명확하고 빠르게 복구할 수 있는 경우

유지보수 시간에는 이유, 범위, 예상 시간, 복구 판단, 안내 계획이 있어야 합니다. 문의, 주문, 예약, 회원 접근에 의존하는 기업이라면 “유지보수로 사이트를 이용할 수 없습니다”라는 문구만으로는 충분하지 않습니다.

업데이트를 승인하기 전에 무엇을 물어야 하나요?

• 어떤 페이지와 기능이 바뀌나요?
• 작업 중 방문자와 직원은 무엇을 계속 할 수 있나요?
• 변경 사항은 공개 사이트와 분리된 곳에서 준비되나요?
• 문의, 결제, 예약, 계정 변경 및 다른 실시간 데이터는 어떻게 보호되나요?
• 배포 성공을 확인할 점검은 무엇인가요?
• 점검 하나라도 실패하면 복구 계획은 무엇인가요?
• 유효한 새 데이터를 되돌리지 않고 소프트웨어만 복구할 수 있나요?
• 호스팅, 결제, 이메일, 인증, 예약 또는 다른 외부 서비스가 일정에 영향을 주나요?
• 계속 진행할지, 수리할지, 롤백할지 누가 결정하나요?
• 영향을 받는 사용자에게 언제, 어떻게 알리나요?

답변에 모든 기술 명령을 설명할 필요는 없습니다. 비즈니스에 미치는 영향을 분명히 알 수 있어야 합니다.

LINK-V는 웹사이트 업데이트를 어떻게 진행하나요?

사이트를 평가하거나 유지관리할 때는 배포 방법을 정하기 전에 웹사이트, 호스팅, CMS, 데이터베이스, 연동 서비스, 백업, 접근 권한, 운영 위험을 검토합니다. 올바른 방법은 변경 내용과 기존 시스템에 따라 달라집니다.

일상적인 업데이트는 차분하고 적절한 범위에서 진행하고, 통제된 중단이 필요한 변경은 명확하게 안내하는 것이 저희의 목표입니다. 웹사이트가 매일의 판매, 문의, 예약, 회원 서비스 또는 게시 업무를 지원한다면 유지관리 체계와 지속적인 관리 방식을 평가해 드릴 수 있습니다.