웹사이트의 속도, CPU와의 거리가 중요한 이유

웹사이트를 열었을 때 화면이 늦게 나타나면 흔히 서버의 CPU 성능부터 생각한다. CPU의 처리 능력이 웹서비스 속도에 중요한 것은 사실이지만, 사용자가 느끼는 웹페이지의 속도는 CPU 하나만으로 결정되지 않는다. 사용자의 기기에서 서버까지 데이터가 이동하는 시간, 서버가 요청을 처리하는 시간, 그리고 결과를 다시 전달받아 브라우저가 화면을 구성하는 시간이 모두 합쳐져 최종적인 체감 속도가 만들어진다.

이 가운데 중요한 요소가 바로 ‘CPU와의 거리’다. 여기서 말하는 거리는 서버 내부에서 CPU와 다른 부품이 떨어져 있는 물리적 거리가 아니라, CPU가 위치한 서버와 사용자 사이의 네트워크 거리를 뜻한다. 사용자가 웹사이트에 접속하면 요청은 서버의 CPU가 있는 곳까지 이동하고, 처리된 결과는 다시 사용자에게 돌아온다. 서버가 멀리 있을수록 데이터가 더 긴 네트워크 경로를 거칠 가능성이 높아지고, 그만큼 왕복 지연 시간도 늘어날 수 있다.

광섬유에서 신호는 대략 초당 20만 킬로미터의 속도로 이동한다. 따라서 네트워크 경로가 1,000킬로미터라면 한 방향으로만 약 5밀리초가 걸리며, 요청과 응답을 단순하게 계산하면 왕복에 약 10밀리초가 필요하다. 실제로는 데이터가 직선으로 이동하지 않고 여러 라우터와 통신망을 거치기 때문에 지연 시간은 더 길어질 수 있다.

특히 작은 데이터를 여러 번 주고받는 웹서비스일수록 이런 지연에 민감하다. 페이지 하나를 표시하는 데 서버와 여러 차례 통신해야 한다면 네트워크 왕복 시간이 반복해서 쌓이기 때문이다. 이 경우 서버의 CPU가 아무리 빨라도 사용자가 멀리 떨어져 있으면 사이트가 둔하게 느껴질 수 있다.

반대로 서버의 CPU나 데이터베이스가 과부하 상태라면 사용자가 서버와 가까워도 응답은 늦어진다. 결국 웹 응답 속도는 네트워크 지연과 서버 처리 시간, 브라우저의 렌더링 시간이 함께 결정한다. 따라서 원인을 확인하지 않고 CPU만 교체하거나 서버 위치만 바꾸는 것은 효과가 제한적일 수 있다.

사용자와 서버 사이의 거리를 줄이는 대표적인 방법이 CDN이다. CDN은 여러 지역에 서버를 두고 이미지, 스타일시트, 자바스크립트, 동영상 같은 정적 콘텐츠를 사용자와 가까운 곳에서 전달한다. 캐싱 역시 자주 사용하는 데이터를 가까운 곳에 저장해 원본 서버까지 이동해야 하는 횟수와 서버의 반복 작업을 줄인다.

하지만 모든 데이터를 CDN으로 해결할 수 있는 것은 아니다. 로그인 정보처럼 사용자마다 달라지는 데이터나 실시간 정보는 직접 서버에서 처리해야 할 수 있다. 이런 경우에는 필요한 데이터를 먼저 전달하고 나머지는 나중에 불러오도록 구성하거나, 불필요한 요청과 데이터의 양을 줄이는 방식이 효과적이다.

사용자의 네트워크와 기기 성능도 빼놓을 수 없다. 와이파이 신호가 약하거나 이동통신망이 혼잡하면 서버가 가까워도 느릴 수 있고, 서버에서 데이터를 빠르게 받아왔더라도 브라우저가 복잡한 자바스크립트를 처리하느라 화면 표시가 늦어질 수 있다.

따라서 웹사이트를 빠르게 만들려면 먼저 어디에서 시간이 발생하는지를 측정해야 한다. 서버가 응답을 만드는 데 오래 걸리는지, 네트워크 구간에서 지연되는지, 아니면 브라우저가 화면을 구성하는 데 시간이 걸리는지를 구분해야 한다.

사용자와 CPU가 위치한 서버 사이의 거리가 문제라면 CDN과 지역별 서버, 캐싱이 도움이 될 수 있다. 서버의 계산이나 데이터베이스가 병목이라면 서버와 데이터베이스를 개선해야 하고, 브라우저가 문제라면 자바스크립트와 콘텐츠를 줄여야 한다.

결국 웹서비스의 속도는 단순히 CPU의 성능으로 결정되지 않는다. CPU가 얼마나 빠른가뿐만 아니라 그 CPU가 사용자와 얼마나 떨어져 있는가, 데이터가 어떤 경로로 이동하는가, 서버가 얼마나 효율적으로 처리하는가, 브라우저가 얼마나 빠르게 화면을 구성하는가가 모두 중요하다. 빠른 웹사이트를 만드는 핵심은 CPU와 사용자의 거리를 무조건 좁히는 것이 아니라, 요청부터 화면 표시까지 전체 과정에서 가장 큰 지연이 발생하는 구간을 찾아 줄이는 데 있다.