gimmesilver's blog

Agbird.egloos.com

포토로그



웹 서비스 용량 최적화 문제... 단상

 2년쯤 전에 캐나다의 한 이동 통신 회사 네트워크 최적화를 위한 컨설팅을 수행한 적이 있습니다. 그 당시 그 이동 통신사의 고민은 단말기용 웹 서비스가 너무 느리다는 점이었죠. 최초 인터넷 접속에 걸리는 시간이 짧게는 15초에서 보통 30초, 최악의 경우에는 1분이 넘게 걸리곤 했으니까요. 가장 근본적인 원인은 무선망이 너무 빈약했기 때문이었지만 그 외에도 어플리케이션 단에서 눈에 띄는 문제가 많이 있었습니다. 

 보통 다음이나 네이버같은 포털 사이트는 이미지를 제외하더라도 수 십~수 백Kbytes 수준이며 이미지 등을 포함하면 수 Mbytes까지도 될 수 있습니다. 보통 페이지당 수십 개 이상의 TCP 세션이 맺어지며 만약 해당 페이지가 처음 방문한 페이지라면 캐시 데이터가 없으므로 백 개가 넘는 HTTP 요청이 발생하기도 합니다. 마우스를 클릭하는 순간 수백개의 패킷들이 순식간에 왔다갔다 하는 것입니다.
 반면 이동 통신 단말기용 웹 페이지는 국내의 경우 - 이미지까지 모두 합쳐서 - 보통 10Kbytes를 넘지 않습니다. 대개 5Kbytes 안팎이죠. 이렇게하면 송/수신 시 2~3개 사이의 패킷으로 나뉘게 됩니다. 무선은 속도도 느릴 뿐더러 에러율도 매우 높기 때문에 무거운 웹 데이터는 주고 받는데 문제가 생기기 마련이기에 이렇게 최대한 페이지 사이즈를 작게 유지합니다.

 당시 캐나다 이동 통신사(편의상 B사라고 부르겠다)의 웹 페이지는 - 국내 이통사에 비해 - 지나치게 무거웠습니다. 보통 웹페이지당 10개 안팎의 이미지가 사용되었습니다. 국내 이통사는 자주 사용되는 이미지의 경우 아예 단말기에 미리 저장을 해놓고 이것을 불러들이도록 구성되어 있지만 B사의 경우엔 그런 장치도 없었습니다. 

 심지어 HTML 소스 자체에도 트래픽 낭비의 흔적이 많았습니다. B사는 자동 소스 생성기를 사용해서 페이지를 구성했는데(아마도 웹 페이지 접속자의 가입자 정보에 따라 다른 화면 구성이 필요했기 때문일것입니다.) 이 생성기 프로그램에 버그가 있었는지 HTML 태그 사이 사이에 공백 문자가 지나치게 많이 들어가 있었습니다. 믿어질지 모르겠지만 이 중복된 공백 문자만 제거해도 평균적으로 HTML 소스 크기를 약 50% 수준으로 줄일 수 있었습니다. 이 공백문자만 걸러내더라도 페이지 로딩 시간이 10초 정도 수준으로 줄어들 수 있을 것 같았죠.

 어쨌든 이런 원인의 대부분은 이통사가 단말기와 웹 컨텐츠를 전부 제어하는 전지전능한 위치에 있는 국내 실정과는 달리 B사는 단말기 회사나 컨텐츠 업체에 어떤 영향력도 발휘하기 힘든 위치에 있었기 때문이기도 했습니다. 그리고 이런 이유로 인해 우리의 결과 보고서는 실제로 그들의 서비스 최적화에 크게 영향을 주지 못했습니다. 단지 우리가 보고한 HTML 소스에 있는 공백문자 버그 때문에 관련 책임자가 사임하는 수준에서 끝났다고 들었습니다.

 비슷한 경우를 올해 3월 쯤에 경험했습니다. KT에서 와이브로 서비스가 4월에 정식 런칭하면서 와이브로 전용 단말기와 해당 기기에서 접속할 수 있는 전용 포털을 준비중이었는데 역시 여기서도 접속 시간이 지나치게 오래 걸리는 문제로 고민하고 있었습니다. 그래서 문제 파악을 위해 서버와 단말기가 주고 받는 데이터를 잠깐 본 적이 있는데 페이지 하나당 단말기에서 요청하는 HTTP 트랜잭션이 평균 20개 안팎이었습니다. 해당 서비스 페이지들은 평균적으로 10~20개 정도의 썸네일 이미지를 포함하고 있었고 때문인데 이는 단말기 성능에 무리를 줄 수 있는 수준이었죠. 당시 와이브로 단말기용 서비스를 기획한 업체는 이동 통신 단말기의 특성을 전혀 고려하지 않았고 대부분의 메뉴를 이미지로 구성한 - 보기에는 - 화려한 UI 서비스를 만들어 놓았던 것입니다.
 결국 모두가 알다시피 와이브로 단말기 및 단말기 전용 서비스가 지금 어디에 어떻게 되었는지 그 누구도 알지 못합니다.

 요즘 Release It! 이라는 책의 번역본을 베타리딩하고 있습니다. 재미있는 사례들이 많이 나오는데 특히 9장에 용량에 관련된 안티패턴을 소개하면서 위에 제 경험과 비슷한 사례들이 나옵니다. 
 웹 서비스를 직접 개발해본 경험이 없기에 이런 용량 최적화 문제는 이동 통신과 같은 특수한 환경에서나 신경쓸 문제인줄 알았는데 유선 인터넷과 같이 비교적 성능 제약이 덜한 곳에서도 영 무시할 수만은 없는 문제인가 보군요...


덧글

댓글 입력 영역