준비를 많이 한 날일수록 사이트가 죽으면 아픕니다. 방송에 소개되는 날, 인플루언서가 링크를 올리는 날, 큰 광고를 트는 날.
그런데 이런 날의 준비는 대개 콘텐츠와 재고에 집중되고, 사이트가 그 사람들을 받을 수 있는지는 확인되지 않은 채 넘어갑니다. 그리고 접속이 몰린 5분 동안 아무도 못 들어오면, 그날 쓴 광고비와 준비 기간이 통째로 날아갑니다.
"하루 몇 명"이 아니라 "분당 몇 명"
여기서 계산이 자주 어긋납니다.
"하루 방문자 3만 명"이라고 하면 감이 잘 안 옵니다. 24시간으로 나누면 시간당 1,250명이라 별것 아닌 것 같습니다.
문제는 트래픽이 고르게 오지 않는다는 것입니다. 방송에서 언급되는 순간부터 2~5분 사이에 대부분이 몰립니다. 3만 명 중 1만 명이 3분에 들어오면 분당 3,300명, 초당 55명입니다. 이건 완전히 다른 숫자입니다.
그래서 계산은 이렇게 하세요.
예상 유입 × 집중 비율 ÷ 집중 시간(초) = 초당 요청 수
10,000 × 0.6 ÷ 180 ≒ 초당 33명
한 사람이 페이지 하나를 여는 동안 이미지·CSS·스크립트까지 2050개의 요청이 발생합니다. 초당 33명이면 초당 7001,600건의 요청입니다.
이 숫자를 개발자에게 전달하면 대화가 훨씬 빨라집니다. "많이 올 것 같아요"보다 "초당 30명 정도 예상합니다"가 준비할 수 있는 말입니다.
어디서 먼저 무너지는가
병목은 대체로 정해진 순서로 나타납니다.
① 이미지와 파일 용량 (가장 흔함)
메인 페이지 하나가 8MB인 사이트가 드물지 않습니다. 상세페이지를 큰 이미지로 만든 경우 특히 그렇습니다. 초당 30명이 8MB를 받아 가면 초당 240MB의 전송이 필요합니다. 대부분의 호스팅 요금제가 여기서 먼저 막힙니다.
② 데이터베이스
상품 목록을 그릴 때마다 데이터베이스를 여러 번 조회하는 구조라면, 접속이 몰릴 때 조회가 밀리기 시작합니다. 한 번 밀리기 시작하면 대기가 대기를 부르면서 급격히 나빠집니다. 이 현상이 왜 일어나는지는 대기행렬로 본 일정 지연에서 다룬 원리와 같습니다.
③ 서버 처리 능력
위 둘을 해결하고 나면 그때 서버 대수가 문제가 됩니다. 순서를 거꾸로 해서 서버부터 늘리면 돈은 쓰는데 효과가 작습니다.
돈 안 들이고 할 수 있는 것
준비 기간이 짧고 예산이 없다면 이 순서로 하세요. 대부분 하루 안에 됩니다.
1. 이미지 줄이기
가장 큰 효과가 가장 싸게 납니다. 상세페이지 이미지를 WebP로 바꾸고 폭을 화면에 맞게 줄이면 용량이 절반 이하로 떨어지는 경우가 많습니다. 8MB짜리 메인이 1.5MB가 되면 그것만으로 버티는 인원이 다섯 배가 됩니다.
지금 확인해 보세요. 크롬에서 F12 → Network 탭 → 새로고침 → 맨 아래 transferred 숫자. 이게 3MB를 넘으면 손볼 여지가 큽니다.
2. CDN 붙이기
이미지와 정적 파일을 전 세계 서버에 복사해 두고 가까운 곳에서 내보내는 서비스입니다. Cloudflare는 무료 요금제로도 이걸 해 줍니다. 네임서버만 바꾸면 되고, 설정은 30분이면 끝납니다.
효과가 큽니다. 이미지 요청이 원 서버에 오지 않으니 서버 부담이 크게 줄어듭니다.
3. 페이지 캐시 켜기
로그인이 필요 없는 페이지(메인, 상품 목록, 소개)는 매번 새로 만들 필요가 없습니다. 한 번 만든 결과를 몇 분간 저장해 두고 같은 걸 내보내면, 데이터베이스 조회가 거의 사라집니다.
워드프레스면 캐시 플러그인, Next.js면 정적 생성이나 재검증 설정, 카페24 같은 임대형이면 이미 적용돼 있는 경우가 많습니다. 개발자에게 "메인과 목록 페이지에 캐시 걸 수 있나요"라고 물어보세요.
4. 안 쓰는 스크립트 빼기
챗봇, 히트맵, 여러 개의 광고 추적 스크립트. 하나씩은 가벼워도 예닐곱 개가 쌓이면 무겁습니다. 그날만이라도 필수가 아닌 것을 빼면 체감이 달라집니다.
돈을 쓴다면
예산이 있고 규모가 크다면 여기까지 갑니다.
- 서버 임시 증설: 클라우드라면 그날만 사양을 올렸다가 내리면 됩니다. 하루 비용은 대개 몇만 원 수준입니다
- 오토스케일링: 트래픽에 따라 자동으로 늘어나는 구성. 설정에 시간이 걸리므로 미리 해 둬야 합니다
- 대기열 페이지: 티켓팅처럼 접속을 순번으로 받는 방식. 구축 비용이 있지만, 다 죽는 것보다 낫습니다
미리 한 번 돌려 보기
가장 확실한 건 실제로 부하를 걸어 보는 것입니다. k6나 Artillery 같은 도구로 "초당 30명이 3분간 들어오는" 상황을 재현할 수 있습니다. 개발자에게 요청하면 반나절이면 결과가 나옵니다.
중요한 건 실제 사용자 흐름으로 돌려야 한다는 것입니다. 메인 페이지만 두드리면 통과하는데, 실제로는 사람들이 상품을 보고 장바구니에 담고 결제를 시도합니다. 결제 단계에서 막히면 앞이 아무리 빨라도 소용이 없습니다.
부하 테스트는 반드시 미리 협의하고 하세요. 예고 없이 돌리면 호스팅사가 공격으로 보고 차단할 수 있습니다.
그날 준비할 것
기술 준비가 끝났어도 사람 쪽 준비가 남습니다.
- 누가 지켜보나: 그 시간에 사이트를 실시간으로 보고 있을 사람을 정하세요
- 연락 경로: 개발자·호스팅사 연락처를 그날 손에 두세요. 장애 대응 절차를 미리 정해 뒀다면 그대로 씁니다
- 멈출 스위치: 최악의 경우 광고를 끄거나 대기 안내 페이지로 돌릴 방법을 미리 준비
- 실시간 확인: 구글 애널리틱스 실시간 보고서를 띄워 두면 지금 몇 명이 있는지 보입니다
정리
- 분당·초당으로 계산하세요. 하루 총량은 의미가 없습니다.
- 순서는 이미지 → CDN → 캐시 → 서버입니다. 서버부터 늘리면 돈만 씁니다.
- 지금 F12로 페이지 용량을 재 보세요. 3MB가 넘으면 여기부터입니다.
- 가능하면 미리 부하를 걸어 보고, 실제 결제 흐름까지 포함하세요.
- 그날 지켜볼 사람과 끌 스위치를 정해 두세요.
가장 흔한 실패는 준비를 안 해서가 아니라, 준비를 콘텐츠와 재고에만 하고 사이트는 "되겠지"로 넘겨서 생깁니다. 한 번 계산해 보는 데 30분이면 됩니다.
성능 자체를 개선하는 방법은 Core Web Vitals가 좌우한다를, 초기 로딩을 줄이는 실무는 bundle-analyzer로 초기 JS를 줄이는 방법을 보세요.