일단 캐시 문제다.

실제 서버 DB에 존재하는 데이터가 클라이언트로 순수하게 전송되지 않고 과거의 스냅샷이 보여진다.

캐시는 어디어디에 존재하는지 살펴봄으로써 해결 방법을 찾을 수 있다.

일단 웹 브라우저 캐시가 존재한다. 같은 URL에 대한 리퀘스트에 대해 클라이언트 단에서 이전에 기록된 결과를 리턴하는 방식이다.

이 캐시는 사용자가 끌 수 있다.

IE를 예로 들어보면 도구|인터넷 옵션|검색기록|설정 에서 [저장된 페이지의 새 버전 확인] 옵션을 [페이지를 열 때 마다]로 설정하면 된다.

웹 개발자들이 보통 이 설정으로 세팅해 놓고 사용하는 경우가 많다.

다음으로 추정해 볼 수 있는 캐시는 서버 캐시이다.

똑 같은 리퀘스트가 올 때 이전에 저장해 놓은 스냅샷을 전송하는 것이다.

이렇게 하면 DB서버에 대한 부담을 크게 줄일 수 있고, 스크립트에 대한 파싱을 줄일 수 있으므로 CPU에 대한 부담도 줄일 수 있다.

이 방식은 내부적으로 URL을 키로 한 해시맵으로 구현하는 것이 일반적일 것으로 추측된다.

따라서 이 방식은 해시키를 살짝 바꾸어 주면 캐시 히트를 피할 수 있다.

Ajax에서 많이 쓰는 해결방법을 응용하면 쉽게 해결된다.

예를 들어 우리가 L을 눌러서 새글을 확인한다고 할 때 URL은 [https://gall.dcinside.com/list.php?id=programming&keyword=&k_type=0100&search_pos=&page=1] 가 된다.

서버 캐시를 활성화 시켜 놓았다면 항상 같은 리퀘스트에 대해 캐시 히트가 될 것이다.

URL이라는 것은 ? 뒤에 붙는 정보들이 Form 데이터에 대한 전송이다.

Form 데이터는 HTTP 프로토콜상에서 느슨한 체크를 한다. 다르게 얘기하면 ? 뒤에 붙은 폼 데이터가 실재로 존재해도 되고 안 해도 된다는 것이다.

서버가 필요한 항목만 파싱해서 취사선택하기 때문에, 서버의 폼과 매칭되지 않는 쓰레기 변수들이 있어도 오류를 발생시키지 않는다.

따라서 저 URL뒤에 불필요한 항목을 붙여 보자.

[https://gall.dcinside.com/list.php?id=programming&keyword=&k_type=0100&search_pos=&page=1]가 딱 필요한 정보로 구성된 정상적인 URL이다.
[https://gall.dcinside.com/list.php?id=programming&keyword=&k_type=0100&search_pos=&page=1&garbage=12345] 라고 URL을 변형하면

서버는 이 URL을 정상적인 URL로서 처리해 줄 것이다. 뒤에 붙인 garbage=12345 라는 폼 데이터는 서버가 처리하지 않기 때문에 오류를 발생시키지 않는다.

하지만 캐시 히트는 피할 수 있다.

왜냐하면 URL을 검증하지 않고 전체 URL을 해시키로 쓰기 때문에 두 URL은 명확하게 다른 해시키가 되기 때문이다.

살짝 또 바꿔보자. garbage=12345 대신 garbage=12346을 붙여서 URL을 조합하면 역시 두 URL은 완전히 다른 놈이 된다.

따라서 서버의 캐시 히트를 피해갈 수 있다.

마지막으로 존재할 수 있는 캐시는 프락시 서버다.

프락시는 클라이언트와 서버 사이에 위치하면서, 클라이언트의 요청에 대해 눈치껏 파악해서 자신이 갖고 있는 캐시를 리턴시키는 방식으로 동작한다.

이 방식을 통해 프락시는 내부의 여러 유저의 캐시를 공유하는 역할을 해 준다.

자 그렇다면 프락시 서버는 어떤 키값으로 캐시를 검색할까?

웹서버와 마찬가지로 전체 URL을 해시키로 사용한다.

따라서 URL에 쓰레기를 붙이는 방식으로 프락시의 캐싱을 피해갈 수 있다.

자 이제 답은 명확하다. URL에 쓰레기 붙이기가 답이다.

답을 알았으므로 편하게 이 방식을 쓸 수 있도록 프로그램을 개발 해 보자.

URL의 변조는 철저히 클라이언트가 해야 하는 몫이다.

클라이언트에서 사용자는 URL 변조를 위해 불편함을 느껴서는 안 된다.

그리고 클라이언트 어플리케이션은 웹 브라우저다.

몇 가지 방법을 생각해 볼 수 있다.

첫 번째 안은 웹브라우저를 직접 제작하는 것이다.

URL을 네트웍에 전송할 때 https://gall.dcinside.com/ 이라고 시작한다면 문자열 비교 또는 정규식으로 간단히 비교하여 뒤에 쓰레기를 붙이면 된다.

이 방안의 단점은 웹브라우저를 직접 개발해야 한다는 부담과, 신기술을 따라가야 한다는 부담. 그리고 근본적으로 다른 유저들이 과연 이 브라우저를 사용할 것인가 하는 문제가 대두된다.

IE 컨트롤을 사용하여 한 시간 정도면 이 기능을 하는 웹 브라우저를 개발할 수 있다. 환경 설정과 플러그인도 IE와 공유하므로 훌륭한 대안이 될 수 있으므로 개발부담은 Zero로 가깝게 줄어들 수 있다.

그렇지만 다른 유저들이 사용할 것인가에 대한 고민은 해결이 되지 않는다. 웹마 같은 대중적인 브라우저로 성장한다면 다른 유저들도 사용하겠지.

하지만 웹마 수준의 브라우저는 개발 부담이 있다. 따라서 또 다시 같은 고민을 하게 되는 재귀논리모순에 빠지게 된다.

두 번째 안을 보자.

플러그인을 만드는 것이다. 불여우 플러그인 SDK를 이용하여 만들고, IE도 지원하려면 ActiveX로 구현하면 된다.

오픈 아키텍쳐(플러그인을 지원하는)구조의  웹 브라우저는 필수적으로 URL 가로채기를 지원한다.

왜냐하면 그 기능이 필수적이기 때문이다.

URL을 중간에 가로채서 어떤 동작을 할 지 판단해야 하는건 기본중의 기본 기능일 수 밖에 없다.

URL이라는게 한 페이지에서 한 번만 발생한다고 생각하는가?

HTTP는 너무나도 단순한 프로토콜이기 때문에 어떤 페이지를 요청해서 받은 HTML문서에 이미지가 두 개, 플래시가 하나 포함되어 있다면, 이미지 요청을 위해 두 번의 URL리퀘스트와 플래시를 다운받기 위한 한 번의 리퀘스트를 날리게 되어 있다.

플래시 플러그인을 활성화 시키려면 마지막의 플래시 파일 요청 URL을 가로채야만 한다.

그게 아니면 뭔 수로 쉽게 플래시와 플러그인을 연결시키겠는가?

URL을 가로챌 수 있으면 URL을 변조하여 전송하는 것도 가능하다.

그게 아키텍쳐에서 제공하는 기능이던 약간의 해킹을 해야 하는 것이던간에 분명히 변조하여 전송할 수 있다.

내가 아는 바로는 IE는 분명히 그 기능을 제공한다. 불여우나 기타 브라우저의 제공 여부는 확실치 않지만, 상식적으로 판단할 때 그 기능을 제공하지 않는 경우는 별로 없을 거 같다.

이 방식의 장단점도 짚어보자.

장점은 첫 번째 안의 단점이 사라진다는 것이다. 브라우저 개발의 부담은 없다. 그리고 많은 사용자들이 즐겁게 사용해 줄 것이다.

단점은 뭘까? 여러 브라우저를 지원해야 한다. 그런데 브라우저마다 플러그인 인터페이스가 다 다르다. 따라서 코드 재활용이 제한적일 수 밖에 없다. 많은 버전을 만들어야 한다는 부담이 있다.

하지만 여러 안 중에 가장 적절한 안이라고 본다.

마지막 안은 로우레벨의 구현이 필요한 안이다. 로우레벨인 만큼 응용레벨의 구현이 어찌 되었던간에 동일한 기능을 구현 할 수 있는 장점이 있는 안이다.

바로 URL이 날라가는 도중에 네트웍을 타기 전에 바꿔치기를 하는 것이다.

TCP/IP 드라이버를 변조하여 구현할 수 있다. 드라이버를 건드리지 않고도 구현이 가능하다. 윈도 OS인 경우 알다시피 후킹을 사용할 수 있을 것이다.

내가 아는 범위에서 네트웍 리퀘스트에 대해서도 후킹이 가능한지는 확실치 않다. 하지만 TCP/IP 패킷을 보여주는 스파이 프로그램들이 존재하는 걸로 봐서, 그리고 그 스파이들이 드라이버를 건드리지 않는 거 같기 때문에 무언가 방법은 분명히 존재한다.

존재 하지 않는다면 드라이버를 건드리면 되고, 아니면 로컬 프락시를 만들어도 된다.

장점은 앞서 말한 대로다. 모든 브라우저를 동시에 지원하게 된다.

가장 큰 단점은 플러그인이 아니라는 점이다.

드라이버를 건드리는 프로그램은 로우레벨의 문제를 발생시킬 소지가 있다.

특히 네트웍이 먹통이 되었을 때, 그 문제를 복구하기가 참 어렵다. 인터넷 검색이라도 되어야 복구할 방법을 찾을 것이고, 원본 드라이버를 새로 다운로드를 받을 수 있을게 아닌가?

이런 이유로 사용자들은 로우레벨까지 건드리는 소프트웨어를 설치하기 꺼려한다.

그래서 내 결론은 두 번째 안이 가장 좋다는 것이다.