갑자기 몰릴 때
누가 소개해 준 뒤 사이트가 느려지는 상황이에요. 대비가 없으면 가장 좋은 기회가 온 날에 문이 닫혀요.
쉽게 말하면
전단지를 몇 달 돌려도 하루 스무 명이던 가게가, 어느 날 지역 계정에 소개되면서 오후 두 시에 이백 명이 문 앞에 서요. 이때 부족한 건 물건이 아니에요. 봉투와 잔돈, 그리고 계산해 줄 손 하나예요. 재고는 창고에 그대로 있는데 줄이 안 줄어서 손님이 그냥 돌아가요. 인터넷 가게에서 갑자기 몰릴 때 벌어지는 일이 정확히 이거예요. 물건은 멀쩡하고, 손님을 받아 주는 창구 한 곳이 막혀요.
이 문서는 몰리는 날 사장님이 손으로 하는 일만 다뤄요. 무엇이 왜 부러지고 어디를 넓혀야 하는지는 손님이 몰릴 때 버티기에, 열기 전에 미리 재 보는 방법은 몰릴 때 버티나 미리 시험에 따로 있어요.
가장 아까운 건 멈춘 시간이 아니에요. 그 시간에 온 손님은 다시 안 와요. 소개글은 이미 다 읽힌 뒤예요.
몰림 자체를 막은 게 아니에요. 손님이 최소한 무슨 일인지 알고 기다릴 수 있게 만든 것이에요.
몰림은 네 가지 얼굴로 와요
대응이 갈리는 기준은 크기가 아니라 예고가 있었는지예요. 예고가 있으면 준비의 문제고, 없으면 첫 15분의 문제예요.
| 몰림의 종류 | 예고 | 보통 얼마나 이어지나 | 먼저 준비할 것 |
|---|---|---|---|
| 누가 소개해 줬을 때 | 대개 없어요. 게시되고 나서 알아요 | 몇 시간 안에 가장 세게 오고 며칠에 걸쳐 옅어져요 | 폰으로 볼 수 있는 감시 알림. 살아 있나 감시하기가 이 자리예요 |
| 커뮤니티나 뉴스에 퍼졌을 때 | 없어요. 심지어 좋은 소개가 아닐 수도 있어요 | 하루에서 이틀. 밤에도 와요 | 문의가 몰릴 창구 하나와 답할 문구 |
| 내가 여는 프로모션 | 있어요. 날짜를 내가 정해요 | 시작 직후 몇십 분이 가장 세요 | 여는 시각을 손님 적은 시간대로. 재고는 품절 대응과 함께 |
| 선착순이나 한정 수량 | 있어요. 대신 가장 좁은 시간에 몰려요 | 몇 분. 이 종류만 유일하게 초 단위예요 | 동시에 눌렸을 때 수량이 어긋나지 않는지 확인 |
네 번째 줄이 가장 어려워요. 몇 분 안에 다 들어오는 종류라서, 준비를 해도 창구를 넓히는 것만으로는 안 풀려요. 수량이 실제보다 더 팔리는 사고가 여기서 나요.
몰림은 사고가 아니라 결과예요
이 상황의 원인은 대개 사장님이 잘한 일이에요. 소개를 받았거나 광고가 통했거나 후기가 좋았던 거예요. 그래서 목표를 잘못 잡기 쉬워요. 목표는 서비스를 완벽하게 버티게 만드는 것이 아니라, 온 손님이 다시 올 이유를 남기는 것이에요. 느려도 안내가 있으면 손님은 기다려요. 흰 화면만 뜨면 두 번 안 와요.
몰리면 사장님 눈에 보이는 순서
몰림은 한 번에 먹통이 되지 않아요. 순서가 거의 정해져 있어서, 어디까지 왔는지 보면 지금 무엇을 해야 할지가 정해져요.
- 1화면이 느려져요. 뜨긴 뜨는데 몇 초 걸려요. 여기서 알아채면 가장 싸게 끝나요.
- 2목록이나 검색만 먼저 멈춰요. 자료를 많이 뒤지는 화면부터 티가 나요. 첫 화면은 아직 멀쩡해 보여요.
- 3저장과 결제가 실패해요. 손님이 돈을 내려는 순간에 실패하는 단계예요. 여기부터는 매출이 직접 깎여요.
- 4오류 화면이 떠요. 손님 눈에 처음으로 고장으로 보이는 시점이에요. 상태 코드 숫자가 화면에 보이기도 해요.
- 5문의가 몰려요. 같은 질문이 반복돼요. 이 단계에서는 사람 손이 응대에 다 들어가요.
- 6요금 알림이 와요. 사용량으로 값이 붙는 항목이 있으면 며칠 뒤 청구서로 한 번 더 와요.
여기서 지킬 것을 하나만 고르라면 세 번째예요. 돈을 내려는 손님이 실패하지 않는 것이 목록 화면 속도보다 훨씬 값이 나가요. 무엇을 먼저 포기할지 미리 정해 두면 당일에 고민할 일이 없어요.
느린 것과 죽은 것은 다르게 대응해요
느린 상태는 손님이 기다릴 수 있어서 안내로 버틸 수 있어요. 아예 안 열리는 상태는 안내가 손님 눈에 닿지도 않아요. 그래서 안내 문구는 몰리기 전에 만들어 둬야 해요. 정말 멈췄다면 사이트 밖 창구, 즉 SNS 계정이나 문의 채널이 유일한 확성기예요.
몰릴 걸 알 때 하루 전에 하는 일
하루가 있으면 할 수 있는 게 많아요. 순서는 값이 큰 것부터예요. 코드를 크게 고치는 일은 여기에 넣지 않아요. 몰리기 직전의 큰 수정은 그 자체가 사고의 원인이 돼요.
- 1손님이 처음 보는 화면 한 장만 가볍게 해요. 큰 사진 몇 장을 줄이는 것만으로도 첫 화면이 달라져요. 이 한 장에 손님 대부분이 몰려요.
- 2같은 답을 여러 번 만들지 않게 해요. 모든 손님에게 똑같이 보이는 화면은 한 번 만들어 두고 나눠 주면 돼요. 가까운 창고에서 보내기와 같은 답 다시 쓰기가 여기에 쓰여요.
- 3안내 문구를 미리 써 둬요. 느려질 때 띄울 한 줄과 문의에 보낼 답 하나예요. 급할 때 글을 쓰면 어조가 무너져요.
- 4폰에 알림이 오는지 확인해요. 감시 장치가 있어도 알림이 사장님 폰까지 오지 않으면 없는 것과 같아요. 장애 알림 받기를 미리 눌러 봐요.
- 5요금 상한과 사용량 알림을 걸어요. 쓰는 서비스마다 한도 설정이 있는지 보세요. 몰림이 요금으로 오는 경로는 아래 절에 따로 적었어요.
- 6당일에 하지 않을 일을 정해요. 새 기능 배포와 표 구조 변경은 그날 하지 않아요. 문제가 생겼을 때 원인이 둘이면 아무것도 못 가려요.
- 7여는 시각을 옮길 수 있는지 봐요. 프로모션이라면 손님이 가장 적은 시간에 열면 겹침이 줄어요. 이건 돈이 안 드는 유일한 대비예요.
직접 해보기
안내 한 장을 미리 만들어 두세요
몰리는 날 가장 자주 쓰이는 것은 서버 설정이 아니라 문장 세 줄이에요. 지금 접속이 많아 느리다는 것, 주문은 정상이라는 것, 언제 다시 보면 되는지예요. 스튜디오에서 한 장짜리 안내 화면을 미리 만들어 링크만 저장해 두세요. 당일에는 그 링크를 SNS와 문의 답변에 붙이기만 하면 돼요.
스튜디오에서 만들어 두기이미 몰려서 느려진 지금
지금 느린 상태라면 원인을 찾는 것보다 손님을 잡는 게 먼저예요. 순서를 지키면 혼자서도 15분 안에 할 수 있어요.
- 1정말 몰려서인지 먼저 봐요. 방문자 수가 평소와 비슷한데 느리면 그건 몰림이 아니라 다른 고장이에요. 방문자 통계에서 지금 사람 수를 봐요.
- 2결제와 주문이 되는지 직접 해 봐요. 사장님이 손님처럼 한 번 눌러 보는 게 가장 빠른 진단이에요. 여기가 되면 시간은 벌었어요.
- 3안내를 먼저 띄워요. 준비한 세 줄을 사이트와 SNS 양쪽에 올려요. 침묵이 가장 비싼 대응이에요.
- 4무거운 기능 하나를 잠시 접어요. 실시간 집계나 추천 목록처럼 없어도 장사가 되는 것부터요. 잠시 접는다고 안내에 적어요.
- 5문의 창구를 하나로 모아요. 여러 곳에서 답하면 답을 못 한 문의가 생겨요. 답 문구는 하나로 통일해요.
- 6끝난 뒤 무엇이 먼저 막혔는지 적어요. 이 기록 한 장이 다음 몰림의 준비 목록이 돼요. 장애가 났을 때 순서에 이어지는 자리예요.
장면 1 · 몰림 한 시간 뒤 손님이 남긴 문의
“결제 버튼을 세 번 눌렀는데 계속 실패해요. 돈은 빠져나갔나요?”
몰릴 때 가장 많이 오는 문의예요. 여기서 할 말은 정해져 있어요. 확인해서 오늘 안에 연락드린다까지만 말하고, 되는지 안 되는지를 추측으로 답하지 않아요. 그리고 결제가 여러 번 눌린 흔적은 그날 안에 확인해야 해요. 몰릴 때는 같은 주문이 두 번 들어가는 사고가 유난히 많아요.
이때 코드를 고치지 않아요
몰리는 중에 원인을 짐작해서 코드를 고치면, 문제가 하나에서 둘로 늘어나요. 지금 할 수 있는 건 접는 것과 알리는 것이에요. 고치는 일은 몰림이 지나간 뒤에 해요. 그때는 어디가 먼저 막혔는지 증거도 남아 있어요.
몰림이 요금으로 돌아오는 길
손님이 몰렸는데 서비스는 멀쩡했다는 날에도 며칠 뒤 청구서가 커질 수 있어요. 쓴 만큼 값이 붙는 항목들이 그날 같이 늘어난 거예요. 무엇이 그런 항목인지 알아 두면 상한을 미리 걸 수 있어요.
| 몰릴 때 같이 늘어나는 것 | 왜 늘어나나 | 미리 해 둘 수 있는 것 |
|---|---|---|
| 서버가 돌아간 시간 | 요청이 늘면 그만큼 더 오래 돌아요. 요청 수로 값을 매기는 방식도 있어요 | 요금제의 한도와 초과 시 동작을 확인해요. 멈추는지 계속 받는지가 완전히 달라요 |
| 밖으로 나간 데이터 양 | 사진과 영상이 무거우면 손님 수에 곱해져요 | 첫 화면 사진 용량을 줄여 두는 게 가장 값이 커요 |
| AI 기능 호출 | 손님이 쓰는 만큼 호출이 늘어요. 몰림에 정비례해요 | AI 요금 구조를 보고 하루 상한을 걸어요 |
| 문자나 알림 발송 | 주문마다 한 통이면 주문 수가 그대로 발송 수예요 | 꼭 필요한 발송만 남겨요. 안내 메일은 묶어 보내도 돼요 |
| 이미지 변환이나 저장 공간 | 손님이 올리는 파일이 있으면 몰림에 같이 늘어요 | 올릴 수 있는 크기와 개수를 제한해 둬요 |
한도가 있으면 어느 쪽이 멈추는지 알아 두세요
무료나 저가 요금제에는 대개 한도가 있어요. 중요한 건 한도에 닿았을 때의 동작이에요. 서비스가 멈추는 쪽이면 몰림의 절정에서 문이 닫혀요. 초과분을 청구하는 쪽이면 문은 열려 있고 청구서가 커져요. 어느 쪽이 나은지는 사장님이 정할 문제인데, 모르고 맞는 것이 가장 나빠요. 쓰는 서비스의 이 항목을 오늘 한 번 확인해 두세요. 운영비 점검과 구독 정리와 같이 보면 좋아요.
많이 하는 오해
- Q. 서버를 미리 크게 사 두면 되지 않나요?
- 크게 사면 도움이 되지만 그것만으로는 안 풀려요. 막히는 곳이 서버 힘이 아니라 자료를 뒤지는 한 곳일 때가 많아서예요. 그리고 몰림은 몇 시간이고 요금은 매달 나가요. 어디가 좁은지 모르는 상태에서 크게 사는 건 값이 가장 안 나오는 대비예요.
- Q. 손님이 갑자기 늘었는데 공격일 수도 있나요?
- 가능해요. 가르는 방법은 손님의 행동이에요. 사람이 오면 여러 화면을 돌아다니고 일부는 주문까지 가요. 한 주소만 초 단위로 계속 두드리면 그건 사람이 아니에요. 뒤쪽이 의심되면 트래픽으로 문 막기 공격으로 넘어가세요.
- Q. 느려지자마자 서버를 다시 켜면 되나요?
- 권하지 않아요. 다시 켜는 동안은 완전히 닫히고, 켜진 직후에는 그동안 밀린 요청이 한꺼번에 들어와요. 몰리는 중의 재시작은 잠깐 나아 보이다가 더 세게 막히는 경우가 많아요.
- Q. 바이브캠퍼스에서 만든 것도 몰리면 느려지나요?
- 만든 결과물을 어디에 올려 두었는지에 달려요. 화면과 자료를 어디서 보내는지, 요금제 한도가 얼마인지가 그대로 버티는 힘이 돼요. 그래서 이 문서의 준비 항목은 만든 도구와 상관없이 같아요.
- Q. 미리 시험해 보는 건 언제 하나요?
- 날짜를 내가 정하는 몰림, 즉 프로모션이나 선착순을 열기 전이에요. 방법은 몰릴 때 버티나 미리 시험에 있어요. 예고 없이 오는 몰림에는 시험보다 알림과 안내 준비가 먼저예요.
확인해 보세요
지역 계정에 소개된 직후 사이트가 느려졌어요. 결제는 아직 되는 상태예요. 지금 첫 번째로 할 일은?
하나 더
다음 주에 선착순 한정 판매를 열려고 해요. 오늘 준비할 것으로 가장 알맞은 것은?
더 깊이 (안 읽어도 괜찮아요)
왜 두 배가 두 배로 안 끝나나 · 손님이 두 배 되면 느려짐도 두 배일 것 같지만 실제로는 어느 선까지 거의 그대로이다가 그 선을 넘으면 한꺼번에 밀려요. 계산대 앞의 줄과 같은 성질이에요. 처리하는 속도보다 들어오는 속도가 조금이라도 빠르면 줄은 계속 길어져요. 그래서 몰림 대비의 목표는 여유를 두 배로 만드는 것이 아니라, 그 선이 어디인지 아는 것이 돼요. 이 원리를 자세히 보려면 손님이 몰릴 때 버티기로 가세요.
무엇을 먼저 포기할지 미리 정하는 이유 · 몰리는 중에는 판단할 시간이 없어요. 그래서 잘 준비된 가게는 접을 순서를 종이에 적어 둬요. 실시간 집계, 추천 목록, 후기 자동 표시처럼 없어도 장사가 되는 것이 앞이고, 주문과 결제가 마지막이에요. 순서를 적는 데는 십 분이면 되고, 그 십 분이 당일의 삼십 분을 줄여요.
이 비유가 어디부터 달라지나 · 가게 비유는 줄이 밀리는 부분까지 잘 맞아요. 다른 점이 하나 있어요. 실제 가게는 손님이 문 앞에서 기다리는 걸 눈으로 보고 포기하지만, 인터넷 가게의 손님은 기다리는 사람이 몇 명인지 몰라요. 그래서 다들 같은 버튼을 여러 번 눌러요. 이 반복이 몰림을 실제보다 더 크게 만들어요. 안내 한 줄이 값이 나가는 진짜 이유가 여기예요. 지금 몇 명이 기다리는지 손님이 알면 손이 멈춰요.
이것만 기억하세요
- ·몰림은 사고가 아니라 잘한 일의 결과예요. 목표는 완벽한 버팀이 아니라 온 손님이 다시 올 이유를 남기는 것이에요
- ·대응이 갈리는 기준은 크기가 아니라 예고예요. 예고가 있으면 준비의 문제, 없으면 첫 15분의 문제예요
- ·지킬 것을 하나만 고르면 결제와 주문이에요. 목록 화면 속도는 그다음이에요
- ·몰리는 중에는 접는 것과 알리는 것만 해요. 코드 수정과 재시작은 문제를 하나 더 만들어요
- ·쓴 만큼 값이 붙는 항목은 며칠 뒤 청구서로 와요. 한도와 초과 시 동작을 오늘 확인해 두세요