CDN과 에지 컴퓨팅: 대규모 웹 서비스의 지연 시간을 줄이는 방법

대규모 웹 서비스가 느려지는 순간에는 방문자 수만 늘어난 것이 아닙니다. 멀리 있는 원본 서버까지 같은 이미지와 스크립트를 반복해서 가져가거나, 모든 요청이 한곳의 처리 과정에 몰리면서 대기 시간이 길어집니다. CDN과 에지 컴퓨팅은 이 문제를 줄이는 도구이지만, 무엇을 가까운 곳에서 처리하고 무엇을 원본에 남길지 정하지 않으면 비용과 복잡성만 늘기 쉽습니다.

핵심은 빠르게 보이는 페이지를 만드는 일이 아니라 요청의 경로를 구분하는 일입니다. 이 글에서는 CDN의 역할, 캐시 설계, 지연 시간 측정, 브라우저의 무거운 작업 분리, 그리고 트래픽 급증 전 점검 순서를 실무 관점에서 정리합니다.

목차 5

CDN과 에지 컴퓨팅은 같은 말이 아니다

CDN은 여러 지역의 전송 거점에 정적 파일 사본을 두어 사용자와 가까운 곳에서 전달하는 방식입니다. 이미지, 글꼴, 스타일시트, 버전이 붙은 JavaScript 파일처럼 많은 사람이 같은 내용을 받는 자산에 특히 잘 맞습니다. 원본 서버는 같은 파일을 되풀이해 보내는 부담을 덜고, 사용자는 멀리 있는 서버까지 왕복하지 않아도 됩니다.

에지 컴퓨팅은 전송 거점에서 제한된 로직을 실행하는 쪽에 가깝습니다. 요청 형식을 확인하거나, 캐시 규칙을 바꾸거나, 국가·언어 같은 공개 정보를 기준으로 응답 경로를 정하는 데 쓸 수 있습니다. 반면 로그인 상태, 결제, 개인화된 데이터처럼 사용자마다 달라지는 정보는 원본 서비스의 권한 확인과 데이터 처리 흐름을 거쳐야 합니다. 가까운 위치에서 실행된다는 이유만으로 모든 작업을 에지로 옮기는 것은 안전한 설계가 아닙니다.

• CDN에 우선 올릴 대상: 버전이 관리되는 이미지, 동영상 조각, 글꼴, CSS, JavaScript 같은 공용 자산
• 에지에서 검토할 대상: 요청 경로 정리, 캐시 가능 여부 판단, 공개 리디렉션과 가벼운 응답 변환
• 원본에 남길 대상: 계정 정보, 주문·결제, 권한 확인, 개인별 결과, 데이터베이스 변경

캐시는 파일 저장이 아니라 응답 규칙이다

캐시가 효과를 내려면 같은 요청에 같은 응답을 돌려줘도 되는지부터 판단해야 합니다. 로고나 게시글 대표 이미지는 좋은 후보지만, 장바구니 수량이나 개인 추천처럼 쿠키·로그인 상태에 따라 내용이 달라지는 응답을 무심코 저장하면 다른 사람에게 잘못된 화면이 보일 수 있습니다.

따라서 캐시 키에 어떤 경로, 쿼리 문자열, 헤더, 쿠키를 포함할지 정하고, 응답의 갱신 시점도 함께 설계해야 합니다. 자산 파일명에 버전을 붙이면 새 파일을 배포할 때 이전 캐시와 충돌할 가능성을 낮출 수 있습니다. 반대로 갱신이 잦은 콘텐츠는 짧은 보관 시간, 명확한 무효화 방법, 원본으로 되돌아갈 때의 동작을 함께 점검하는 편이 낫습니다.

지연 시간은 하나의 숫자로 판단하지 않는다

사용자가 느끼는 느림은 한 구간에서만 생기지 않습니다. 이름 조회, 연결 설정, 암호화 연결, 원본 서버의 처리, 응답 전송, 브라우저 렌더링이 이어집니다. CDN을 붙인 뒤에도 느리다면 원본의 첫 응답, 지나치게 큰 이미지, 차단적인 스크립트, 또는 캐시되지 않는 요청이 원인일 수 있습니다.

그래서 개선 전후에는 같은 지역과 비슷한 네트워크 조건에서 측정하고, 첫 바이트가 도착하는 시간, 가장 큰 콘텐츠가 표시되는 시점, 입력 뒤 화면이 반응하는 시간을 나누어 봐야 합니다. 한 지표만 좋아졌다고 전체 경험이 좋아졌다고 단정할 수는 없습니다. 측정 결과는 캐시 정책을 바꿀지, 원본 쿼리를 줄일지, 프런트엔드 자산을 줄일지 결정하는 출발점이 됩니다.

브라우저에서는 메인 스레드를 먼저 보호한다

네트워크가 빨라도 브라우저가 긴 JavaScript 작업으로 멈추면 페이지는 느리게 느껴집니다. 큰 배열 변환, 무거운 데이터 해석, 반복 계산이 화면을 그리는 메인 스레드를 오래 점유하면 스크롤과 클릭 반응이 늦어질 수 있습니다. 작업을 작은 단위로 나누고, 사용자에게 즉시 보이는 일을 먼저 처리하는 이유가 여기에 있습니다.

Web Worker는 DOM에 직접 접근할 필요가 없는 계산을 별도 실행 흐름으로 옮길 때 유용합니다. 다만 Worker를 쓴다고 모든 문제가 사라지지는 않습니다. 전달하는 데이터가 너무 크거나 결과를 한꺼번에 화면에 반영하면 다시 병목이 생길 수 있으므로, 어떤 작업을 옮길지와 결과를 언제 반영할지를 함께 설계해야 합니다.

트래픽 급증 전에 확인할 순서

1. 요청을 분류합니다. 공용 정적 자산, 캐시 가능한 공개 페이지, 사용자별 동적 요청을 구분합니다.
2. 원본의 부담을 봅니다. 느린 응답이 특정 경로·이미지·데이터 조회에 집중되는지 확인합니다.
3. 캐시 규칙을 작게 검증합니다. 한 번에 전체 정책을 바꾸지 말고, 대상과 만료·무효화 동작을 확인합니다.
4. 브라우저 작업을 측정합니다. 긴 작업과 큰 자산이 상호작용을 막는지 살핍니다.
5. 장애 시 원본 경로를 준비합니다. 캐시가 비었을 때도 원본이 감당할 수 있는지, 오류 응답이 과도하게 반복되지 않는지 점검합니다.

대규모 트래픽 대응은 특정 서비스 하나를 붙이는 일보다 요청마다 알맞은 경로를 고르는 일에 가깝습니다. CDN은 반복되는 전달을 가볍게 하고, 에지 로직은 공개 요청의 일부 판단을 앞당기며, 성능 측정은 실제 병목을 드러냅니다. 이 세 가지를 분리해 관리하면 속도와 안정성을 함께 다루기 쉬워집니다.