CDN 도입했는데 고작 성능 4% 향상?

NewCodes7·2025년 10월 15일

CDN NewCodes 최적화

NewCodes, 기술 블로그&영상 모음 서비스

목록 보기

2/4

안녕하세요! NewCodes 개발자입니다.

저번 글에서는 NewCodes의 서비스에 대해서 소개드렸는데요.

NewCodes는 각 기업의 기술 블로그를 모아둔 큐레이팅 서비스입니다.

올해 5월부터 저 혼자 군대에서 만들기 시작했어요! 현재에도 서버를 안정적으로 운영하려 노력하고 있습니다 😊

이번 글에서는 NewCodes는 어떻게 게시글 조회 성능을 최적화시켰는지 알려드리려 해요!!

CDN, NginX, Local Cache, DB Query Tuning 등 다방면에서 노력을 했었는데요. 그 중에서도 이번 글에서는 CDN을 어떻게 사용했는지 알아보려 해요.

이 글을 통해 CDN은 왜 쓰는 것이고, 실질적으로 어떤 도움이 되는지 알아봅시다!

저의 생각과 흐름을 그대로 드러내기 위해, 이제부터 평어체로 작성하는 점 양해 부탁드립니다!

NewCodes 아키텍처

최적화를 하고 난 현재 NewCodes의 아키텍처는 이러하다.

AWS를 통해 서비스하고 있으며, 해당 아키텍처의 주요 포인트에 대해 알아보자.

AWS와 함께!

AWS 클라우드를 선택한 이유는 무엇일까?

나는 군대 사지방 환경에서 서버를 구축하고 안정적으로 운영할 수 있는 방법을 마련해야했다. 그런 측면에서 클라우드를 사용하는 게 적합했다. 참고로 개발을 하는 환경 또한 github에서 제공하는 codespace 클라우드를 사용하고 있다.

위 사진은 우리 사지방과 가장 비슷해서 가져와봤다 ㅎㅎ..
지금 이 글도 저 곳에서 쓰고 있다!

많은 클라우드 서비스 중에서 AWS를 선택했던 이유는 신뢰도와 비용이다. AWS는 이미 증명된 클라우드이고 학습할 자료도 정말 많다. 그렇지만 너무 비싸면 안 쓸 생각이었다. 내 소중한 월급을 쓰는 것이니..!

서버를 지속적으로 운영하기 위해서 클라우드 비용을 최소화하고 싶었다. 그래서 CPU와 Memory를 최대한 낮은 걸로 사용하려 했었고, 여러 서비스와 비교해보니 AWS가 의외로 상대적으로 저렴했다. 신뢰적인 측면이나 레퍼런스 측면에서도 AWS가 매력적인 선택지였다.

집에서 유휴 상태로 있는 맥북으로 홈서버를 구축하는 것도 생각해봤지만, 운영적인 측면에서 고려했을 때 좋은 선택지는 아니라고 판단했다. 장애가 생겼을 때 물리적으로 해결해야 하는 이슈라면 며칠동안 서비스가 다운될 수 있기 때문이다.

CDN -> Web Server -> WAS -> DB

아키텍처는 크게 4가지로 구성되어있다.

CDN과 NginX를 도입한 이유는 빠르고 안정적인 조회 성능을 위해서이다. 게시글 조회 API는 우리 NewCodes 서비스의 핵심이기 때문이다.

NewCodes 서비스에서 핵심은 크롤링된 기술 블로그를 유저에게 보여주는 것이다. 최대한 빠르게 보여주는 게 유저의 UX를 향상시키며 이탈을 방지할 수 있다.

그런데 '이 친구 저렴하게 운영하고 싶다면서 뭘 이렇게 많이 뒀나?' 싶을 수도 있다. 이렇게 구성한 서버는 실제로 비용이 얼마나 나오는지 살펴보자.

저번 달 9월 기준, 세금 포함 35,386원이 나왔다. 실질적으로 비용이 드는 부분은 크게 2가지이다. EC2와 VPC이다. 현재 AWS free tier 혜택을 받아 RDS(Relational Database Service) 비용은 지불하고 있지 않은 상태이다. EC2는 vCPU 2개, Memory 2GB 사양을 사용하고 있다.

올해 12월 free tier가 끝나면 비용을 더 아낄 수 있는 구조로 옮겨가려 한다.

CDN 도입 전후 성능 비교

CDN을 도입한 것과 아닌 것의 성능 차이가 궁금하지 않은가?

이를 직접 실험해본 결과를 공유하려 한다.

해당 실험은 Chrome 개발자 도구에서 Fast 3G로 throttling한 것 기준으로 진행했다. 개발자 도구 network 탭을 보면 throttling을 정할 수 있다. 이로써 사지방 네트워크 변수에 의존하지 않고 비교적 정확한 속도 비교를 할 수 있다.

참고로 Fast 3G는 대략 아래 정도의 성능을 보이는 속도이다.

항목	값
다운로드 속도	1.6 Mbps
업로드 속도	750 Kbps
지연시간 (Latency)	150 ms

CDN이 전달하는 대상 콘텐츠는 블로그 글의 썸네일로 했다. NewCodes에서 가장 중요한 이미지는 썸네일이기 때문이다.

before (NginX)

서버 측의 NginX를 통해 서빙한 결과부터 살펴보자.

평균 5.56s의 속도이다.

after

이번엔 CDN을 통해 서빙한 결과를 살펴보자.

평균 5.34s의 속도이다.

5.56s -> 5.34s로 약 4% 향상되었다. 얼핏 보면 드라마틱한 개선은 아니다.

물론 전세계 곳곳에서 실험해본다면 CDN의 성능은 더욱 도드라질 것이다. 하지만, 국내에서만 서비스한다면 위처럼 성능이 비슷할 것이다.

NginX가 워낙 빨라서 차이가 심해보이지 않을 수 있다. 위 속도로만 보면 국내에서는 NginX만 써도 무방한 것처럼 보인다.

하지만 우리는 위 속도에만 집중해서는 안 된다. CDN은 그것보다 더 큰 의미를 가진다. 지금부터 알아보자.

CDN은 어떤 기술인가?

성능이 별로 안 좋아졌는데도 국내에서 CDN을 굳이 도입할 필요가 있었을까? 이에 대한 답을 내리기 위해 CDN에 대해 더욱 알아보자.

CDN(Contents Delivery Network)을 도입한 이유는 블로그 글 썸네일과 같은 이미지를 빠르고 안정적으로 서빙하기 위함이다. CDN은 지리적 제약 없이 웹 컨텐츠를 서빙해주는 분산 서버 네트워크이다.

위처럼 전세계 곳곳에서 빠른 속도로 콘텐츠를 전달받을 수 있게 된다.

CDN 구성요소

CDN에 대해서 더 자세히 알아보자.

CDN은 Origin Server와 Edge Server로 구성되어 있다. Origin Server는 실제 콘텐츠를 저장하고 Edge Server에게 원본 콘텐츠를 전달하는 역할을 한다. Edge Server는 Origin Server로부터 콘텐츠를 받아와 캐시하고 있는 역할을 한다.

사용자가 콘텐츠를 요청하면 아래와 같은 순서로 동작한다.

사용자는 가깝고 적합한 Edge Server의 IP 주소를 DNS 서버로부터 받는다.
이 IP 주소를 토대로 Edge Server에 콘텐츠 요청을 보낸다.
이 때, Edge Server에 해당 콘텐츠가 있으면 바로 응답을 해주고,
없다면 Origin Server로부터 콘텐츠를 받아와서 응답을 보내준다.

즉, Edge Server는 세계적으로 여러 곳에 분산되어 있으면서, Origin Server로부터 콘텐츠를 받아와 캐시하고 있는 서버라고 보면 된다.

AWS CloudFront

참고로 AWS에서 제공하는 CDN인 CloudFront는 아래와 같이 이루어져있다. CloudFront의 이름을 보면 사용자에게 가장 앞단에 있는 클라우드 서비스임을 강조하는 듯하다.

Edge Location은 앞서 살펴봤던 Edge Server에 해당한다. 가장 앞단에서 사용자를 맞이해주는 건 Edge Location이다.

Regional Edge Caches는 중간 캐시 계층이라 보면 된다. Edge Location에서 콘텐츠가 필요할 때 굳이 Origin까지 안 가더라도 빠르게 콘텐츠를 받아올 수 있다.

Application Content Origin은 Origin Server에 해당한다. S3가 될 수도 있고, EC2 등 다양한 서비스가 Origin Server 역할을 할 수 있다. 주로 S3(Simple Storage Service)를 사용한다.

CDN의 매력적인 장점

국내 서비스들의 이미지 URL을 살펴보면 CDN을 흔하게 사용하는 걸 볼 수 있다. 지금 이 velog도 CDN을 사용한다. 국내 서비스인데도 왜 CDN을 이용할까? 그 이유를 알아보자.

CDN의 큰 장점은 운영 서버의 부하를 덜 수 있다는 점이다.

원래는 html, css, js, image와 같은 정적 콘텐츠를 운영 서버에서 서빙해야 했다. 하지만, 이 서빙을 CDN이 담당해주니 운영 서버는 그 만큼의 트래픽을 덜 받게 된다. 그럼 그만큼 운영 서버의 스펙을 낮추고 서버 비용을 절감할 수도 있다.

또, CDN은 운영하기 편리하며, 가용성이 좋다. 실제로 CDN을 사용해보면 알겠지만, 사용하는 게 그리 어렵지 않다. 운영 중에도 이슈가 거의 일어나지 않아서 좋다.

여러 지역 여러 서버에 캐시가 분산되어 있으므로 한 곳에서 장애가 발생해도 다른 서버에서 콘텐츠를 제공할 수 있다.

그런데 CDN 비용도 고려해야 하지 않겠는가? 비싸면 결국 사용하기 싫어지지 않겠는가?

바로 살펴보자.

AWS CloudFront 비용

CloudFront 기준으로 CDN 비용을 알아보자. 정확한 비용 계산을 위해 총 3가지 항목을 살펴볼 것이다. 요금은 월 기준으로 부과한다는 점을 알아두자.

CloudFront 전송 데이터 요금

CloudFront에서는 전송하는 데이터 양만큼 요금을 부과한다.

보시다시피 첫 1TB는 어떤 지역이든 무료이다. 그 다음 1TB ~ 10TB 사용 구간에서는 대한민국 기준 1GB당 0.120 달러를 지불해야 한다. 대략 8GB에 1달러라고 보면 된다.

NewCodes 서버의 전송 데이터는 얼마나 되는지 봐보자.

지난 한 달간 1.78GB를 썼다.

즉, 무료이다! 1TB 무료인 게 아주 큰 장점이다!

CloudFront http/https requests 요금

또, 몇 개의 요청을 처리했는지에 따라 요금을 부과한다.

10만 개까지의 요청은 역시 무료이다. 그 다음부터 10,000개당 대한민국, HTTPS 기준 0.0120 달러를 지불해야 한다. 대략 80만개 요청에 1달러라고 보면 된다.

NewCodes 서버의 requests는 얼마나 되는지 보자.

총 47,961개이다. 이 역시 10만 개 이내이므로 무료이다.

참고로 AWS free tier는 HTTP 또는 HTTPS 요청 1,000만 건/월 무료이다.

S3 저장 요금

마지막으로 S3 저장 요금이다.

CloudFront를 통해 콘텐츠를 전달하기 위해서는 S3가 필요하다. S3는 Simple Storage Service의 약자로 여러 콘텐츠를 저장한다. CDN에서 사용할 경우 S3는 원본 콘텐츠를 가지고 있는 Origin Server를 역할을 한다.

S3에서 CloudFront로 전송하는 데이터에 대해서는 무료이다. 그래서 S3는 저장 요금만 살펴보면 된다.

S3의 저장 요금을 살펴보자.

처음 50TB까지는 1GB당 0.025 달러를 부과한다. 대략 40GB를 쓰면 1달러를 지불해야 한다.

NewCodes에서 사용한 S3의 요금을 살펴보자.

대략적으로 현재 170MB를 사용하고 있다. 거의 요금이 부과되지 않는 수준이다.

참고로 AWS free tier는 5GB까지 무료이다.

여기까지 해서 총 3가지 요금을 살펴봤다. 결국 나는 현재 무료로 CDN을 사용하고 있다. 무료로 운영 서버의 부담을 덜고 있으니 정말 좋다.

하지만, 트래픽이 점점 늘어난다면 어떨까?

EC2에서 서빙하는 것과 비용 차이도 고려해봐야 한다. EC2에서 정적 콘텐츠를 서빙하는 게 훨씬 싸고 국내에서만 서비스를 한다면, CDN을 쓰지 않는 게 나을 수 있기 때문이다.

EC2와의 비교

비교를 위해 NewCodes 서비스가 현재보다 100배의 트래픽이 늘어났다고 해보자. S3에 저장해야 하는 콘텐츠도 100배 늘어났다고 가정해보자.

데이터 전송량: 178GB -> 1TB 이내이므로 무료
requests 개수: 400만개 -> 4.68 USD
S3 저장 용량: 17GB -> 0.425 USD

총 5.105 USD가 나온다. 매우 저렴하다!

반면에 EC2 아웃바운드 트래픽 비용을 살펴보자.

EC2에서 서빙했을 때는 178 * 0.126 = 22.4 USD를 지불해야 한다. 확연한 차이이다. TB 수준으로 어림잡아 봤을 때에도 CloudFront과 비슷하거나 살짝 더 저렴한 수준이다.

이러니 국내 서비스여도 직접 EC2에서 서빙하는 것보다는 더 빠르고 안전한 CloudFront를 사용하는 게 이득이다.

카카오스타일 CDN 비용

실무에서는 CDN을 어떻게 쓰는지 궁금해서 찾아봤다. 지그재그를 운영하는 카카오스타일의 CDN 이용내역을 발견했다!

해당 비용은 모든 걸 합산한 게 아니고, 폰트만을 전송하는 데 든 비용이다.

데이터 전송량: 39,407GB -> 4,145.50 USD
requests 개수: 250,883,581개 -> 301.06 USD
S3 저장 용량: 폰트이니 거의 없음

총 4,446.56 USD가 나온다. 이는 한국 돈으로 약 600만원이다. 폰트만을 전송하는 데에도 이렇게 많은 돈이 든다니.. 물론 AWS 약정을 하면 더 저렴하다고 한다.

여기서 한 가지 더 생각해보자.

카카오스타일의 케이스를 보면 폰트 CDN 요청만 한 달에 250,883,581개가 들어온다. 이 만큼의 요청을 운영 서버에서 책임진다면 어떨까? 운영 서버의 스케일 아웃 혹은 스케일 업은 불가피할 것이다. 경우에 따라서는 운영 서버가 불안정해질 때도 잦을 것이다.

CDN을 도입함으로써 얻는 큰 장점은 운영 서버와 별도로 관리할 수 있으며, 운영 서버의 트래픽을 덜어낼 수 있다는 점이다.

정리

NewCodes에서 CDN을 쓰는 이유

성능 개선이 약 4%밖에 되지 않았지만, 국내 서비스인 NewCodes에서 CDN을 여전히 쓰는 이유는 분명하다.

운영 서버의 부담을 덜 수 있고, 비용이 저렴하기 때문이다.

품질이 좋고 저렴하면 사게 되는 게 소비자의 심리 아니겠는가? 무엇 하나를 사더라도 신중히 장단점을 고려하며 사는 게 개발자의 덕목이라 생각한다.

CDN 사용 시 주의사항

그렇지만 대규모 트래픽에서는 CDN 역시 비용이 많이 나올 수 있다. 그러므로 CDN을 이용할 때 주의해야 할 사항과 비용에 도움이 되는 TIP을 알아보고자 한다.

CDN 관련 블로그 글을 읽으며 정리해봤다.

콘텐츠 용량
- 전달하고자 하는 콘텐츠의 용량을 최적화하는 것이 좋다.
- 데이터 전송량만큼 요금을 부과하기 때문이다.
- 이미지를 쓴다면 압축을 고려해보자.
호출 횟수
- 요금 부과에 비례하는 게 또 호출 횟수이다.
- CDN에 제대로 캐시되지 않으면 Origin 호출 횟수가 늘어날 수 있다.
- 그러므로 CDN을 처음에 설정할 때 캐시 키를 유의해서 설정하자.
모니터링, 사후 검증 필요
- CDN, 캐시는 눈에 보이지 않는 부분이라 놓치기 쉽다.
- 별도의 테스트코드가 있는 것도 아니니 방심하기 쉽지만, 항상 모니터링 해야 한다.
DDoS 공격 방어
- AWS CloudFront에서는 기본적으로 AWS Shield Standard와 통합되어 있다.
- Shield Standard는 L3, L4 DDoS 공격을 방어하는 서비스이다.
- L7 DDoS 공격을 막기 위해서는 별도의 조치가 필요하다.
- L7 수준의 방어가 필요하다면 CloudFlare를 고려해보자.
S3 OAI(Origin Access Identity)
- OAI는 S3 버킷에 안전하게 접근할 수 있도록 하는 사용자 계정이다.
- CloudFront를 통해서 콘텐츠를 전달한다면 S3는 CloudFront 이외에 다른 요청에는 응답하지 않는 게 안전하다.
- 그러므로 OAI를 통해서 S3에 CloudFront만 접근할 수 있도록 설정하는 것이 좋다.