확실히 컴퓨터 과학에서 풀기 어려운 문제는 캐시를 쓸모 없게 만드는 것과 뭔가에 이름을 붙이는 것 두 가지 뿐이다. (필 칼튼의 격언에 따르면 그렇다.) 이달초 우리는 트위터, 페이스북, 스프라우트코어(SproutCore), 팜의 웹OS, 마이크로소프트의 ‘오피스 온 더 웹(Office On The Web)’, 야후, 그리고 구글 대표자들을 초대했다. 우리는 뭔가에 이름을 붙이는 것도 큰 문제임을 잘 알고 있었지만 (다른 것들 보다는) 그 모임은 캐시를 쓸모 없게 만드는 문제에 대해서 얘기하기 위해서였다.

캐싱은 휴대용 단말기에서 웹 애플리케이션을 널리 쓰이게하는 것 말고도 웹상에서 올바른 권리를 얻기 위해 중요하다. 모임에서 우리가 추구한 목표는 캐싱과 HTTP request 효율을 향상시킬 수 있는 사용사례를 확립하는 것이었다. 예를 들어 우리가 직접 팔을 걷어부치고 파이어폭스에서 HTTP/1.1 파이프라이닝(Pipelining)을 살피는 것이 이상적인 방식일까? 이밖에 HTTP layer에 필요했던 것이 뭘까? 그리고 파이어폭스 3.5에서 전면적으로 지원하기로 알려진 HTML5 앱캐시(AppCache) 기능이 개발자들에게 실제로 유용한가? 이밖에 within content나 additional headers 가운데 웹 애플리케이션에 노출돼야 하는 것은 무엇인가?

개발자 피드백은 매우 소중한 것이며 우리가 원하는대로 조각난 웹 플랫폼들을 점차 통합해 나가는 일에 밑거름이 된다. 웹 개발자들은 우리들의 주요 유권자 가운데 하나다 : 웹 표준에 대해 우리가 수행하고 집중할 필요가 있는 것들 가운데 우선순위를 정할 수 있도록 개발자들이 도와주길 바란다. 우리는 참가자들을 현명하게 택한 셈이다 ; 어떤 사람들이 속한 그룹이든 웹 플랫폼에서 웹 애플리케이션(web application) at scale, 현재 캐시의 성능, 그리고 앞으로 등장할 브라우저가 행하는 캐시 처리동작에 대한 희망사항에 대해 얘기할 수 있다면. 그리고 이들이 우리에게 돌려준 피드백은 내용이 풍부하고 유용했다 — 우리 일은 이를 발췌하는 것뿐이었다. 특히 우리는 우리가 뒤이어 진행해야 할 몇가지 행동을 찾아냈다 :

• 디스크와 메모리 캐시 기본크기를 늘려라. 파이어폭스에서 디스크 캐시 기본값이 50메가바이트(MB)로 돼 있는데, 요새 하드웨어에서 쓸 수 있는 디스크 용량에 비해 작다. (그리고 고급 설정 항목에서 캐시를 늘릴 수 있지만 실제로 기본값을 바꾸는 사용자는 거의 없다.) 우리 입장에서는 쉽게 고칠 수 있는 일이다. 우리가 디스크 캐시 크기를 더 늘려 정하는 대신에 자동산출 방식으로(heuristically) 만드는 게 어떻냐는 재미있는 질문을 받았다. 캐싱 서밋에 참석했던 스티브 소더스(Steve Souders)는 블로그에 캐시 크기와 조기 캐시 메모리 반환(premature cache evictions)에 관한 글을 올렸다.

• 모질라 시범사용자(Mozilla Test-Pilot) 프로젝트를 운영해서 현재 캐시 사용현황에 대한 정확한 데이터를 수집해라. 이건 우리 캐시 알고리즘 갱신에 대한 더 방대한 질문 가운데 일부분이다. 다른 브라우저들처럼 우리는 LRU-SP라 불리는 최근최소사용(LRU : Least Recently Used) 캐싱 알고리즘을 쓴다. 캐시 자원 히트율, 평균, 변동량, 분포를 측정한 것이 우리에게 필요한 데이터에 포함된다. 캐시 데이터들의 평균 수명이 어느정도인지? 상이한 모드로 작동하는 LRU-SP기반 메모리 반환정책이 어떤 애플리케이션에서 잘 작동하지 않는지, 어떤 경우에 (필수 스크립트 파일처럼) 큰 데이터가 (맵 타일같은) 작은 것보다 먼저 삭제되는지? 우리는 주기적으로 캐시를 초기화하는 안티바이러스 소프트웨어 작동방식을 연구해야 한다. 이러한 안티바이러스 동작은 유효한 자원을 뜬금없이 날려버리는 현상을 더욱 조장한다.

• MIME 형식 기반 캐시 데이터에서 우선순위를 고려해라. 예를 들어 자바스크립트(text/javascript)가 우리 LRU-SP 알고리즘으로 불필요한 것들을 제거하고 항상 더 높은 우선순위를 받아가도록 허용할 수 있다. 이 방식을 제대로 구현하기위해 크롬, IE, 애플, 그리고 오페라가 우리와 의논을 하고, MIME 형식 기반 “나이브(naive)한” 우선순위 부여 방식에 대한 문서를 만드는 것이다. 우리는 또한 개발자들이 어쩌면 헤더를 통해서 직접 캐시 데이터 우선순위를 설정할 수 있게 만들었으면 한다. 이건 곧 논의될 가능성이 높다.

• 프록시에서 나온 데이터를 포함해, 웹에서 HTTP/1.1 파이프라이닝 도입을 진짜로 방해되는 것과 이를 없앨 방법을 찾아라. (노키아 N900과 안드로이드 단말기에서 돌아가는) 모바일 파이어폭스 버전에서 파이프라이닝 기능은 기본적으로 작동하는데, 데스크톱 파이어폭스 버전에서는 이걸 꺼놨다. 이유는 여러가진데 특히 파이프라인 기능을 통한 요청 하나가 다른 것들을 느리게 만들 경우 전체적인 성능이 떨어지는 문제가 있어서다. 우리 의논에서 확실한 것은 캐싱 서밋에 참석했던 사람들 대부분은 자신들의 애플리케이션들이 파이프라이닝을 쓰면 성능이 훨씬 향상될 거라고 생각했다는 점이다. 오늘날 웹에서 파이프라이닝 기술에 대한 상황은 일종의 인질의 딜레마(hostage’s dilemma)다. 주요 데스크톱 브라우저들은 성능 저하를 일으키는 시나리오를 겁내기 때문에 아무도 파이프라이닝 기능을 활성화하지 않는다(먼저 나서서 “느려 터진 브라우저”라는 비난에 시달릴 테니까). 우리를 찾아온 개발자들은 낡은 논쟁을 그만뒀다; 웹에서 파이프라이닝 기술을 쓸모없게 만드는 게 무엇인지 이해하고 우리가 실제로 그런 장애들을 없애기 위해 할 수 있는 게 뭔지 결정해야 했다.(역자 주: 인질의 딜레마, 다수인 인질들이 자신을 잡아둔 소수 범죄자에게 덤비지 못하는 이유를 먼저 나섰다가 목숨을 잃을지 모른다는 심리 때문이라고 설명하는 게임 이론 사례. 우리나라 식으로 말하자면 고양이 목에 방울 달기쯤.)

• HTML5 앱캐시를 발전시킬 방법을 찾아라. 우리는 처음 예상했을 때 솔직히 앱캐시가 채택될 거라고 생각지 않았다. 우리가 캐시 매니페스트(Cache Manifests)와 윈도.애플리케이션캐시(window.applicationCache)처럼 HTML5를 구성하는 부분들을 아직 (사용량이 빠르게 늘어나는 웹 애플리케이션 작동을 보장하기 위한) 또다른 성능 툴이라고 간주한다면, 일반적인 브라우저 캐시와는 다를 것이다. 이름에 무슨 의미가 있는 것이며, 무언가에 이름을 붙이는 건 왜 컴퓨터 과학 분야에서 가장 어려운 문제일까? 오프라인 웹 애플리케이션을 다루는 HTML5 부분들을 설명하고자 “캐시”라는 낱말을 쓰는 것은 일부 개발자들에게 혼란을 초래한다. 우리가 HTML5 앱캐시라고 부르는 것은 원래 오프라인 웹 애플리케이션을 쓸 수 있게 만들어주는 것이었는데, (스프라우트코어 같은 것으로 구축된) 많은 애플리케이션들은 보조 캐시를 사용한다. 애플리케이션 실행 속도와 일반적인 성능을 보장하기 위해서다. 왜? 우리는 의문을 품었고, 두 가지 생각이 들었다 : 일반적으로 브라우저 캐시가 갖는 목적은, 오프라인 환경에서 쓰기 위한 것인가? 한가지 드는 생각은, HTML5 앱캐시는 (일부 모바일 단말기에 쓰이는 “빠른 실행 아이콘”을 쓸 수 있는) 네이티브 앱처럼 작동하는 웹앱을 허용하는데, 어쩌면 결국 네이티브 애플리케이션 실행방식과 통합될지도 모른다. 그리고 다른 측면에서 보자면, 일반 캐시에서 HTML5 앱캐시를 분리하는 것은 일반 캐시를 사용하기 위한 또다른 API를 만들어낸다는 의미일 수도 있다. 일반적으로, 이름에 “캐시”라는 표현이 포함된 API를 동시에 만들어내는 것은 혼란을 초래한다. 그러나 저것이 바로 어려운 문제 가운데 하나로 이름붙이기가 들어가는 이유이며, 우리가 다음번에 이런 혼란과 중복성을 되풀이하지 않도록 염두에 두고 설계해야 하는 까닭이기도 하다.

  우리는 데이터 참조 위치를 기억해주는 곳에서 버그를 추적해왔다: “HTTP 캐시 향상.” 당신은 우리가 여기서 소개하려고 하는 다방면의 변화를 보게 될 것이고, 여기에는 크롬(Chromium)에 대한 캐시 벤치마킹도 포함된다. (그리고 만일 우리가 필요하다면 그냥 크롬의 캐시 코드를 사용할 수도 있다.)

  캐싱은 중요하지만 어렵다. 인덱스를 만들 수 있는 데이터베이스 용량, 스트리밍 비디오, 또는 CSS를 활용한 새 레이아웃 모델 등을 소개하는 방법으로 웹의 단기간 발전 대부분을 묘사하는 것이 적당할수도 있다. 이런 변화들은 꼭 표준 body나 listserv 안에서가 아니라 차라리 시험판을 신속하게 만들고 의미있는 피드백을 주고받으며 만들어진 것이다. 이것이 우리가 웹 개발자들에게 우리를 도와 옳은 일을 할 수 있게 해 달라고 얘기하는 이유이며, 우리가 최근 캐싱 서밋을 진행한 것처럼 계속 모임을 조직하는 이유다.

원저자: Arun Ranganathan – 원문으로 가기