두말하면 잔소리겠지만 웹 사이트의 성능을 높이는 일은 굉장히 중요합니다. 사용자가 해당 서비스를 판단하는 가장 중요한 잣대도 바로 사이트의 성능입니다. 하지만 성능과 질을 우선시 하기 보다는 결과를 만들어 내기 급급한 국내 IT환경에서는 최적화된 성능을 기대하기는 어려울 것입니다. 때문에 산출물이 나왔지만 성능이 나오지 않아 여러 전문가에게 자문을 구하며 급급히 수습하려는 일도 일상다반사입니다. 여러 전문가에게 자문을 구해는 보지만 사이트에서 무엇이 문제인지 정확하게 진단할 수 있는 전문가 또한 많지 않다는 것도 문제인 것이죠.
 

그래서 앞으로의 포스트에서는 HOONS가 그 동안 경험하고 연구한 성능에 관한 미약한 지식을 공유할 예정입니다. 성능을 진단하는 방법에서부터 여러 가지 관점(서버단, UI단)으로 성능을 튜닝 하는 예제들을 다루어 보도록 하겠습니다. 





웹 사이트 성능을 결정하는 요소들
 

그 성능을 위한 첫번째 시간으로 사이트의 성능을 어떻게 진단해야 할 것인지에 대해서 알아보겠습니다. 가끔 HOONS에게 프로젝트 성능 튜닝에 대한 요청이 들어옵니다. 대부분의 내용을 보면 DB는 이상이 없고 프로그램 로직도 크게 문제가 없는 것 같은데 왜 프로그램이 느린지 모르겠다는 것입니다. 즉, 이말은 어디에서 어떤 시간들이 소요되고 있는지 진단하지 못하고 있다는 것입니다. 이 문제를 해결하기 위해서는 무엇이 사이트의 성능을 결정하는지 알아야 합니다. 웹 사이트에서 성능을 결정하는 요소는 다음 그림처럼 3가지 요소로 구분할 수 있습니다.
 

 

[웹 사이트의 성능을 결정하는 3가지 요소]

사이트의 성능을 진단해 보고자 한다면 이 그림에서처럼 서버, 네트워크, 브라우저 동작을 진단해야 합니다. 하지만 대부분 성능 튜닝이다라고 한다면 주로 서버 단의 작업에 목매어 작업을 하는 것이 일반적일 것입니다. 예를 들자면,

''어, 이거 사이트 느리네, DB튜닝 좀 부탁해볼까?"
"우리 미들웨어에 COM+를 적용하면 좀 빨라 지려나?"

하지만 아주 많은 양의 데이터를 다루는 사이트가 아니라면 서버단의 동작은 일반적으로 웹사이트 성능에 큰 영향을 주지 않습니다. 또한 초보 프로그래머가 짠 조금 좋지 않은 프로그램 로직이라고 하더라도 그것이 성능에 큰 영향을 주지는 않습니다. 주어봐야 1~2% 정도일 것입니다. 

서버 단 보다도 일반적으로 브라우저의 동작(UI단)과 네트워크에서 더 많은 영향을 주게 됩니다. 네트워크의 경우 사용자와 서버가 지리적으로 먼 곳에 위치해 있다면 수많은 라우터를 거치면서 네트워크의 통신속도는 느려지게 됩니다. 그래서 도입하는 기술이 바로 CDN(Contents Delivery Network) 이라는 서비스입니다. 하지만, 한국에서만 서비스를 적용한다면 거리 때문에는 크게 문제되지 않습니다. 우리나라는 땅도 좁고 초고속 인터넷 망이 설치되어 있는 인터넷 강국이기 때문이죠. (단,인터넷강국이지, IT강국은 아닙니다-_-;) 전세계적으로 서비스 하는 다국어 버전의 사이트라면 CDN이나 네트워크 문제에 신경을 써야 할 것입니다. 이런 네트워크의 속도들은 개발자가 코드를 가지고 어떻게 조율할 수 없는 부분이기 때문에 성능과 관련된 포스트에서는 다루지 않도록 하겠습니다. 


서버단 vs UI 단

그럼 여기서 개발자가 성능을 진단해야 할 부분은 크게 두 가지로 볼 수 있습니다. 바로 서버 단(Backend)과 브라우저의 동작(Frontend)입니다. 쉽게 말하자면 서버 단은 프로그래밍 언어가 되는 것이고 브라우저의 동작은 HTML이 해당되는 것입니다. S.I업체의 경우 서버 단의 동작에 좀 더 무게를 두게 되고 서비스 업체의 경우 UI(브라우저)단의 동작에 무게를 두게 됩니다. 여기서는 UI단의 성능 튜닝과 서버 단의 성능 튜닝에 대해서 살펴볼 것입니다.

 그렇다면 성능은 어떻게 진단해야 하는가? 먼저 앞에서 살펴본 3가지 요소 중에 어떤 부분에 문제가 있는지 진단해야 합니다. 그럼 어떤 툴을 이용해야 할까요? 여러 도구가 있지만 필자가 추천하는 툴은 브라우저 진단 도구인 IE Watch(http://www.iewatch.com/)라는 툴을 추천합니다. 이 툴은 30일 평가 판으로 다운받아 30일 동안은 자유롭게 사용할 수 있습니다. 이 툴은 HTTP 프로토콜이 어떻게 요청되고 응답되고 있는지 보여줍니다. 유사한 툴로는 피들러와 HTTP핸들러와 같은 툴들이 존재합니다. 하지만 이 툴은 HTTP 요청에 대한 시간들을 그래프로 보여주기 때문에 유료지만 추천하는 것입니다 (^_^;)

그럼 이 툴을 가지고 어떻게 사이트의 성능을 진단해야 할까요? 먼저 HOONS닷넷을 진단한다고 가정해 보겠습니다.  
 

[HOONS닷넷의 실행 속도]
 

브라우저는 먼저 HTML 문서를 TCP를 이용하여 호출하여 받게 됩니다. 그리고 HTML안에 포함된 여러 요소들을 다운 받게 됩니다. 여기서 그 HTML이 바로 서버단의 동작시간이고 그 다음 브라우저에 포함된 구성요소들을 다운 받는 시간들이 바로 UI  단의 동작시간인 것입니다. 이 시간만 보면 어디에서 문제가 생기는 것인지 쉽게 알 수 있습니다.

HOONS닷넷 사이트의 경우 서버 단 동작시간은 전체속도에서 35%초 소요되는 것을 볼 수 있습니다. HOONS닷넷의 경우는 이미지나 스크립트와 같은 기타 구성요소들을 많이 사용하고 있지 않기 때문에 30% 정도 밖에 되지 않습니다. S.I의 경우 서버 단의 비중이 조금 더 높을 것이고 서비스 업체의 경우 이 비중이 더 높을 것입니다. 그럼 넥슨 사이트를 살펴보도록 하겠습니다. 

 

[넥슨 사이트의 실행 속도]

넥슨은 서버 단의 실행 속도가 전체의 약 10%밖에 되지 않고 UI단의 동작 시간은 90%나 차지하고 있는 것을 볼 수 있습니다. 그럼 넥슨과 같은 사이트의 경우 어느 부분을 튜닝해야 할지 대충 감이 올 것입니다. 튜닝을 하려면 확률이 큰 쪽(UI단)에서 튜닝을 진행해야 성능이 좋아졌다는 것을 체감할 수 있습니다. 

이런 방식으로 사이트를 진단해 보고 어느 부분에서 속도를 내기 어려운지 판단해야 합니다. 앞에서도 설명했듯이 S.I의 경우 서버단의 동작 시간에 무게가 실릴 것이고 서비스의 경우 UI단에 무게가 실릴 것입니다. 하지만 꼭 S.I라고 해서 UI 동작시간을 무시할 수 없는 것이고 서비스 사이트라고 해서 서버단의 시간을 무시할 수 없는 것이다. 중요한 것은 UI 단의 튜닝은 쉽고, 시간이 적게 드는 반면 서버단의 튜닝은 어렵고, 많은 시간이 든다는 것입니다.

때문에 앞으로의 포스트에서는 UI단의 성능 튜닝에 대해서 먼저 살펴볼 것이고 그 이후에 서버단의 시간에 대해서 살펴볼 것입니다. UI단의 내용으로는 압축, 캐시의 활용, 스타일시트& 스크립트의 위치, 스크립트 최소화 등 성능을 올릴 수 있는 여러 가지 내용들을 다루어 볼 것입니다. 일반적으로 개발자들은 프로그래밍 언어와 같은 서버 쪽 기술들에 대해서는 잘 알고 있지만 HTTP 프로토콜과 브라우저가 동작되는 방식과 같은 기술들은 많이 미숙한 편입니다. 대부분의 사이트의 경우 UI단에서 많은 시간을 소비하고 있고 UI단을 튜닝하는 것이 더 쉽게 튜닝할 수 있습니다. 그러기 위해서는 HTTP 프로토콜의 기본 개념과 브라우저의 동작에 대해서도 알고 있어야 합니다. 이 기술들은 포스트 중간에 계속 보충하며 설명해 나가도록 하겠습니다.