요약

  • AppCache는 웹 애플리케이션을 오프라인에서도 열 수 있게 하려고 목록 파일에 적힌 자원을 브라우저에 보관했다. 서버의 스크립트나 이미지만 고쳐서는 이미 저장된 묶음이 새로워지지 않았다. 캐시 매니페스트 자체를 바꿔야 했다.
  • 목록에 필요한 파일 하나라도 내려받지 못하면 업데이트 전체가 실패하고 이전 앱이 남을 수 있었다. Chrome은 2020년부터 AppCache를 단계적으로 끝냈다. 오프라인 보관 목록이 소프트웨어 출시의 스위치가 된 셈이다.

고친 스크립트는 서버에, 오래된 동작은 사용자에게

개발자가 main.js를 고쳐 서버에 올렸다. 그런데 다음 방문자는 같은 오류를 만난다. AppCache에서는 서버 파일만 바뀌었다는 사실이 충분하지 않았다. Google의 당시 개발 안내는 캐시 목록에 들어 있는 스크립트나 이미지를 수정해도, 매니페스트가 그대로라면 브라우저가 그 자원을 다시 저장하지 않는다고 설명했다. 목록 파일을 바꿔야 새 묶음을 가져오라는 신호가 된다.

주석에 적은 버전 표시 하나가 그 신호가 될 수 있었다. 오프라인 이용을 위해 만든 작은 문서가 출시 버튼까지 맡게 된 것이다. 새 코드는 서버에 있어도, 독자가 보는 앱은 브라우저가 가진 완성된 옛 묶음일 수 있었다.

연결이 없어도 열리는 웹을 만들겠다는 약속

W3C의 2008년 5월 설명서는 네트워크가 끊긴 뒤에도 메일이나 일정 같은 웹 애플리케이션을 쓰려는 문제에서 출발했다. 일반 HTTP 캐시에 필요한 파일이 우연히 모두 남아 있기를 기대할 수는 없었다. HTML의 manifest 속성은 text/cache-manifest 파일을 가리키고, 그 안에 저장할 자원을 적게 했다. NETWORK: 구역에는 계속 인터넷으로 보내야 하는 요청을 따로 표시했다.

브라우저는 앱을 이루는 파일의 명시적인 목록을 받았다. 대신 업데이트도 하나의 묶음으로 처리했다. Google 안내에 따르면 매니페스트나 목록의 자원 중 하나를 받지 못하면 전체 업데이트가 실패하고 이전 애플리케이션 캐시가 계속 쓰인다. 새 묶음이 모두 도착하더라도 이미 열린 페이지는 즉시 새 파일로 바뀌지 않는다. 페이지를 다시 불러와야 한다.

반쯤 설치된 앱을 피하려는 선택이었다. 그러나 main.js만 고치고 목록을 잊으면 독자는 여전히 옛 동작을 본다. 목록을 고쳤어도 필요한 파일 하나가 빠지면 역시 옛 앱이 남는다. “서버가 수정됐다”와 “독자가 수정본을 쓴다” 사이에 검증할 단계가 생겼다.

목록은 너무 가만히 있어도, 너무 바빠도 문제였다

매니페스트가 바뀌지 않으면 새 자원을 받으라는 신호가 없다. 그렇다고 매 요청마다 시간을 써 넣어 파일을 끊임없이 바꾸는 것도 답이 아니었다. Google의 개발 안내는 브라우저가 다운로드 시작과 끝에 목록을 다시 확인할 수 있다고 적었다. 그 사이 목록이 달라지면 서로 다른 버전의 파일이 섞였을 위험 때문에 브라우저가 새 묶음을 적용하지 않고 나중에 다시 시도할 수 있다.

CACHE, NETWORK, FALLBACK은 각각 저장할 파일, 인터넷으로 보낼 요청, 접속 실패 때 쓸 대체 페이지를 정했다. 몇 줄짜리 목록이 앱의 네트워크 정책이었다. 필수 자원 하나의 실패가 링크 하나의 고장으로 끝나지 않고 새 버전 전체를 막을 수 있었다. 안정적인 오프라인 경험과 빠른 수정 배포가 같은 문서에 걸렸다.

브라우저는 불완전한 신버전보다 완전한 구버전을 택했다. 연결이 끊긴 상황에서 앱을 망가뜨리지 않는 장점이 있었고, 긴급 수정이 화면에 늦게 나타나는 부담도 있었다. 배포 서버만 확인하는 팀은 그 차이를 놓치기 쉬웠다.

Chrome은 옛 문을 단계적으로 닫았다

Chrome의 2020년 이전 안내는 AppCache 종료 일정을 단계별로 제시했다. Chrome 85부터 기본 지원을 끄고, 이행 시간이 필요한 사이트에는 한시적인 오리진 트라이얼을 제공했다. 오프라인 기능의 대안으로 Service Worker를 제시했다. 전환에도 단호한 경계가 있었다. Chrome에서 Service Worker가 페이지를 제어하면 그 페이지의 AppCache는 작동하지 않는다. 새 캐시를 절반만 만들고 나머지를 옛 캐시에 맡길 수 없었다.

개발자는 어떤 요청을 가로채고 어떤 자원을 보관하며 이미 열린 페이지에 새 버전을 어떻게 보일지 다시 설계해야 했다. Google의 이행 도구는 AppCache 동작 일부를 따라 했지만, window.applicationCache 인터페이스와 이벤트까지 대체하지는 않았다. Chrome의 일정은 브라우저 하나의 구체적인 이행 시계였고 다른 브라우저들은 별도의 결정을 내렸다.

AppCache가 지킨 것은 연결이 끊긴 순간의 앱이었다. 연결이 돌아오고 서버가 고쳐진 뒤에도 목록이 그대로라면 옛 앱을 지킬 수 있었다. 작은 매니페스트가 오프라인의 안도감과 업데이트 지연을 함께 붙들고 있었다.