손님이 몰릴 때 버티기

손님이 두 배 늘어도 멀쩡했던 서비스가 어느 지점부터 갑자기 무너져요. 그 지점은 아무 곳이 아니라 가장 좁은 한 곳이고, 무너지는 순서도 거의 정해져 있어요.

쉽게 말하면

테이블 열 개에 계산대 한 대인 가게를 생각해 보세요. 손님이 스무 명일 때는 아무 문제가 없어요. 그런데 방송을 타서 이백 명이 한꺼번에 오면, 부족한 건 가게 전체가 아니라 계산대 한 대예요. 테이블은 아직 비어 있는데 문 앞에 줄이 서요. 서비스가 무너지는 방식이 정확히 이래요. 어딘가 한 곳이 먼저 막히고, 손님 눈에는 가게 전체가 고장 난 것으로 보여요.

그래서 이 문서는 빠른 화면 만들기와 다른 이야기예요. 속도는 손님 한 명이 얼마나 빨리 보는지의 문제고, 여기는 손님이 한꺼번에 왔을 때 어디가 먼저 부러지는지의 문제예요. 혼자 열었을 때 1초에 뜨는 화면이 백 명이 동시에 열면 30초가 되기도 해요. 같은 코드인데요.

같은 가게, 평소

손님 20명 계산 20초 줄: 없음 체감: 빠르다

이 상태에서 아무리 점검해도 문제가 안 보여요. 여유가 있을 때는 좁은 곳이 좁아 보이지 않아요.

같은 가게, 몰린 날

손님 200명 계산 20초 그대로 줄: 계속 길어짐 체감: 먹통

고장이 난 게 아니에요. 계산대가 처리하는 속도보다 손님이 오는 속도가 빨라진 순간부터 줄이 무한히 밀려요.

왜 서서히가 아니라 갑자기 무너지나

손님이 두 배 되면 느려짐도 두 배일 거라고 생각하기 쉬워요. 실제로는 그렇지 않아요. 어느 선까지는 거의 그대로이고, 그 선을 넘으면 한꺼번에 무너져요. 이유는 줄의 성질에 있어요.

계산 한 건에 20초가 걸린다고 해 볼게요. 손님이 25초마다 한 명씩 오면 계산대는 매번 5초 쉬어요. 줄이 안 생겨요. 손님이 21초마다 오면 여전히 처리는 되는데 여유가 1초뿐이라, 두 명이 붙어 들어온 순간의 밀림이 사라지지 않고 남아요. 20초보다 짧아지면 줄은 그냥 끝없이 길어져요. 손님이 조금 더 온 게 아니라, 여유가 0이 된 거예요.

여기에 사람의 행동이 하나 더 얹혀요. 화면이 늦게 뜨면 손님은 기다리지 않고 새로고침을 눌러요. 그 순간 요청이 두 배가 돼요. 앞의 요청은 취소되지 않고 계속 처리되는 중이니까요. 불이 났는데 부채질을 하는 셈이고, 이게 몰림 사고가 순식간에 완전 정지로 가는 진짜 이유예요.

1요청이 늘어 응답이 1초에서 5초로 늘어요. 아직 다 되고 있어요. 손님만 답답해요.
2손님들이 새로고침을 눌러요. 처리해야 할 일이 두 배가 돼요. 응답이 15초가 돼요.
3기다리는 요청이 쌓여요. 기다리는 것도 자리를 차지해요. 연결 자리와 메모리가 차기 시작해요.
4자리가 다 차면 새로 온 손님은 줄에도 못 서요. 화면에 오류가 뜨거나 흰 화면이 나와요.
5여기서 프로그램이 자동으로 다시 시도하게 만들어져 있으면 요청이 또 배로 늘어요. 사람의 새로고침과 기계의 재시도가 겹쳐요.
6완전 정지. 이때는 손님이 줄어도 바로 안 살아나요. 쌓인 줄을 다 비울 때까지 계속 먹통이에요.

마지막 줄이 무서운 이유

손님이 정상으로 돌아온 뒤에도 몇십 분을 못 여는 경우가 여기서 나와요. 그래서 몰림 대응은 터진 뒤 수습이 아니라 터지기 전 차단이에요. 자리가 다 차기 전에 "지금 대기 중입니다" 화면으로 손님을 붙잡아 두는 쪽이, 전원을 다시 올리는 쪽보다 항상 싸요. 자세한 순서는 사고 대응에 있어요.

무너지는 순서는 거의 정해져 있어요

가장 좁은 곳 하나가 먼저 막혀요. 그곳을 넓히면 편해지는 게 아니라, 다음으로 좁은 곳이 새 병목으로 드러나요. 그래서 몰림 대응은 한 번에 끝나는 공사가 아니라 좁은 곳을 순서대로 만나는 과정이에요. 아래 순서는 작은 서비스에서 실제로 자주 나오는 순서예요.

순서	먼저 막히는 곳	대략 언제부터	손님 눈에 보이는 증상
1	사진과 동영상 전송량	방문자가 하루 수백 명대로 늘 때	글은 뜨는데 사진이 한참 뒤에 뜨거나 깨져 보여요. 가장 흔한 첫 병목이에요
2	데이터베이스 연결 자리	동시에 처리되는 요청이 수십 건대로 늘 때	"연결할 수 없습니다" 류의 오류가 간헐적으로 섞여 나와요. 새로고침하면 되기도 해요
3	무거운 조회 한 개	쌓인 자료가 수만 건대가 될 때	특정 화면 하나만 유독 느려요. 목록·검색·관리자 화면이 대표적이에요
4	서버 대수	동시 처리가 수백 건대로 늘 때	전체가 고르게 느려져요. 어느 한 화면이 아니라 전부요
5	남의 회사 한도	몰린 순간에 바로	결제나 문자만 실패해요. 화면은 정상인데 알림이 안 가요. 호출 한도 문제예요
6	사람	주문이 하루 수십 건을 넘을 때	서비스는 멀쩡한데 문의 답장이 이틀 밀려요. 후기가 나빠지는 건 보통 여기서예요

표의 숫자는 정확한 경계가 아니라 순서를 보여 주는 눈금이에요. 사진 한 장이 5MB인 서비스는 1번이 훨씬 빨리 오고, 글만 있는 서비스는 1번을 건너뛰어요. 내 서비스의 진짜 경계는 재 보지 않으면 알 수 없어요. 지금 어디쯤인지 감을 잡는 첫걸음은 방문자 통계의 시간대별 최고점이에요. 평균이 아니라 가장 몰린 10분을 보세요.

6번을 빼먹지 마세요

몰림 이야기를 하면 다들 서버만 봐요. 그런데 작은 서비스에서 실제로 가장 먼저 한계에 닿는 건 사장님 본인이에요. 손님 백 배는 문의 백 배이기도 해요. 미리 준비할 것은 자주 오는 질문 답변을 고객 응대 기준으로 정리해 두는 것이고, 이건 돈이 안 들어요.

넓히는 방법은 다섯 가지, 각각 값이 달라요

"서버를 늘린다"는 다섯 가지 중 하나일 뿐이고, 보통 가장 비싸고 가장 늦게 써야 하는 카드예요. 선택지를 값과 함께 놓고 봐야 순서를 고를 수 있어요.

방법	무엇을 하는가	드는 값	이건 언제 쓰면 안 되나
줄이기	사진 용량과 요청 개수를 깎아요. 첫 화면에서 안 보이는 것은 나중에 불러요	돈 0원. 시간만 들어요	이미 최소로 깎여 있을 때. 더 깎을 게 없으면 효과가 없어요
미리 만들어 두기	같은 답을 손님마다 새로 계산하지 않고 한 번 만들어 재사용해요. 캐시라고 불러요	싸고 효과가 커요. 열 배도 흔해요	값이 자주 바뀌는 것. 재고·잔여석·가격은 옛 값을 보여 주면 사고가 커져요
가까운 창고에 복사	사진과 파일을 손님 가까운 곳에 미리 뿌려 둬요	쓴 만큼. 사진이 많으면 가장 남는 장사예요	사진이 거의 없는 서비스. 1번 병목이 없으면 순서를 뒤로 미뤄요
서버를 더 크게	지금 쓰는 기계의 사양만 올려요. 구조를 안 바꿔요	매달 고정으로 늘어요. 대신 한 시간 안에 끝나요	상한이 있어요. 그리고 여전히 한 대라, 그 한 대가 죽으면 전부 멈춰요
서버를 더 많이	같은 서버를 여러 대 두고 손님을 나눠 받아요	매달 고정으로 늘고, 구조가 복잡해져요	측정 전. 그리고 파일 저장과 로그인 상태를 정리하기 전엔 늘리면 오히려 고장 나요

마지막 줄의 경고는 실제로 자주 터지는 사고예요. 서버가 두 대가 되면 손님 요청이 번갈아 들어가요. 그런데 손님이 올린 사진을 1호 기계 안에 저장해 뒀으면, 다음 요청이 2호로 갔을 때 그 사진이 없어요. 로그인 상태도 1호 메모리에만 있으면 손님이 2호로 갈 때 갑자기 로그아웃돼요. 대수를 늘리는 공사의 절반은 서버가 아니라 저장 위치를 바깥으로 옮기는 일이에요.

순서가 중요해요

재기 → 줄이기 → 미리 만들어 두기 → 대수 늘리기. 이 순서를 지키세요. 재지 않고 사양부터 올리는 것은 돈으로 시간을 사는 것인데, 병목이 데이터베이스 쪽이면 사양을 두 배로 올려도 아무 변화가 없어요. 돈만 나가고 원인은 그대로 남아요.

언제 하면 안 되나

여기가 이 문서에서 가장 중요한 부분이에요. 몰림 대비는 보험처럼 보이지만 매달 나가는 비용이고, 구조를 복잡하게 만드는 부채예요. 복잡해진 구조는 나중에 고칠 때마다 값을 다시 받아 가요. 안 올 손님을 위해 미리 넓힌 사장님은 매달 돈을 내면서 개발도 느려지는 쪽을 삽니다.

1방문자가 하루 수십 명일 때. 이때 병목은 손님이 많아서가 아니라 손님이 없어서예요. 넓힐 시간에 첫 손님 쪽 일을 하는 게 백 배 남아요.
2재 보지 않았을 때. 어디가 좁은지 모르고 넓히면 열에 여덟은 안 좁은 곳을 넓혀요. 재는 데 30분, 잘못 넓히면 매달 요금이에요.
3바뀌는 값에 캐시를 걸 때. 재고·잔여석·가격을 미리 만들어 두면 이미 팔린 것을 판 것으로 보여 줘요. 느린 것보다 틀린 것이 훨씬 큰 사고예요.
4결제 쪽에 재시도만 늘릴 때. 몰려서 답이 늦는 걸 실패로 보고 다시 시도하면 승인이 두 번 나요. 이건 넓히는 문제가 아니라 기다림과 다시 시도의 문제예요.
5하루짜리 행사를 위해 영구 구조를 바꿀 때. 방송 하루, 마감 세 시간을 위해서라면 그날만 사양을 올리고 끝나면 되돌리는 게 정답이에요. 구조는 그대로 두세요.

세 번째 줄을 한 번 더 볼게요. 미리 만들어 두기는 만능키처럼 보이지만, 정확히 말하면 "조금 옛 값을 보여 주는 것을 허락한다"는 뜻이에요. 그래서 공사 전에 정해야 하는 건 기술이 아니라 정책이에요. 소개글은 10분 옛 값이어도 아무 일이 없고, 잔여석은 1초도 안 돼요. 화면마다 몇 초까지 옛 값이어도 되는지를 사장님이 정해서 종이에 적어 주는 것이, 이 공사에서 사장님만 할 수 있는 일이에요.

몰릴 날을 미리 아는 경우

방송 예정일, 공동구매 오픈, 마감 직전처럼 언제 몰릴지 아는 경우가 대비하기 가장 쉬운 상황이에요. 상시 구조를 바꾸지 않고 그날만 넓히고 되돌리면 되니까요.

1일주일 전 · 재기. 지금 상태로 몇 명까지 버티는지 확인해요. 여러 명이 한꺼번에 들어오는 상황을 일부러 만들어 보는 시험을 부하 시험이라고 해요. 개발자에게 맡길 수 있고, 결과는 "동시 접속 몇 명에서 응답이 몇 초가 됐다"는 숫자 한 줄로 받으세요.
2사흘 전 · 줄이기. 첫 화면 사진을 줄이고 안 쓰는 위젯을 떼요. 값이 안 드는 것부터 끝내요. 사진 용량 줄이기가 여기서 제일 크게 먹혀요.
3하루 전 · 임시로 넓히기. 사양을 한 단계 올려요. 값과 되돌리는 방법을 업체 요금표에서 미리 확인해 두세요.
4하루 전 · 대기 화면 준비. 자리가 다 차면 오류 대신 "순서를 기다리는 중"을 보여 주게 만들어요. 먹통보다 대기가 훨씬 낫고, 손님도 화를 덜 내요. 기다림 표시와 같은 원리예요.
5당일 · 미루기. 알림 문자, 정산 집계, 통계 계산처럼 1초 안에 안 끝나도 되는 일은 뒤로 미뤄 둬요. 계산대 앞에서 장부 정리를 하지 않는 것과 같아요.
6끝난 뒤 · 되돌리기. 올린 사양을 내려요. 이걸 잊는 게 다음 달 요금 사고의 절반이에요. 되돌릴 날짜를 달력에 적어 두세요.

장면 1 · 방송에 소개된 날

“10분 만에 평소 한 달치 사람이 들어왔어요. 화면이 안 뜬다는 문의가 쏟아지는데 뭘 봐야 할지 몰랐어요.”

몰림 사고에서 가장 큰 손해는 서버 요금이 아니라 그 10분에 왔다가 돌아간 손님이에요. 다시 안 와요. 그래서 목표는 완벽한 속도가 아니라 문 닫지 않기예요. 사진을 다 못 보여 줘도, 대기 순번을 보여 주더라도, 열려 있으면 절반은 남아요.

장면 2 · 외주 개발자가 말했다

“지금 구조로는 안 됩니다. 서버를 늘리고 구조를 다시 잡아야 해요.”

맞는 말일 수도 있고, 큰 공사를 팔려는 말일 수도 있어요. 가르는 질문은 하나예요. "지금 몇 명에서 무너지고, 공사 후에는 몇 명이 되나요?" 숫자 두 개로 답이 오면 진단이고, "요즘은 다 이렇게 합니다"로 오면 아직 진단이 아니에요. 외주 맡기기 기준으로 한 번 더 확인하세요.

장면 3 · 다음 달 요금 안내를 받았다

“행사 때 올린 사양을 그대로 두고 두 달이 지났어요.”

넓히는 것보다 되돌리는 것을 잊기가 훨씬 쉬워요. 임시로 올린 것은 올린 날에 내릴 날짜까지 함께 적어 두세요. 상시로 필요해서 두는 것과 잊어서 두는 것은 금액이 같아도 완전히 다른 일이에요.

남에게 맡길 때 요구할 것

몰림 대비는 사장님이 눈으로 확인하기 가장 어려운 공사예요. 결과물이 화면에 안 보이니까요. 그래서 받아야 할 것을 미리 정해 두는 것이 유일한 방어예요. 아래 다섯 가지를 문서로 요구하세요. 다섯 개 다 어려운 요구가 아니고, 제대로 한 사람이면 이미 손에 있는 것들이에요.

요구할 것	왜 필요한가	이걸로 무엇을 확인하나
공사 전후 숫자	"빨라졌습니다"는 결과가 아니에요	동시 몇 명에서 몇 초였는지, 공사 후 몇 명에서 몇 초인지. 같은 방식으로 재야 비교가 돼요
병목 지목	어디가 좁았는지 못 짚으면 고친 게 아니라 바꾼 거예요	사진·데이터베이스·서버 대수 중 무엇이었는지 한 줄로. 못 짚으면 다음에 또 터져요
옛 값 허용 목록	미리 만들어 두기를 걸었다면 반드시 있어야 해요	어느 화면을 몇 초까지 옛 값으로 보여 주는지의 목록. 재고와 가격이 이 목록에 있으면 위험 신호예요
되돌리는 방법	새 구조가 더 나쁠 때 돌아갈 길이 필요해요	무엇을 어떤 순서로 되돌리면 공사 전 상태가 되는지. 종이 한 장으로 받으세요
매달 늘어나는 비용	공사비는 한 번이고 요금은 평생이에요	이 공사 뒤 매달 얼마가 더 나가는지. 내 서비스가 아니라 내 명의 계정에서 나가는 금액인지도 확인하세요

마지막 칸을 특히 보세요. 넓히는 공사는 대부분 상시 요금을 만들어요. 공사비 한 번보다 그 요금이 몇 년치로는 더 클 수 있어요. 정확한 금액은 쓰는 호스팅 업체의 요금표와 데이터베이스 제공 업체 콘솔에서 확인할 수 있고, 그 화면을 사장님이 직접 열어 볼 수 있어야 해요. 남의 계정 안에 내 요금이 있는 상태는 인수인계 때 반드시 문제가 돼요.

확인해 보세요

방송이 나가고 화면이 느려졌어요. 손님들이 계속 새로고침을 누르고 있어요. 지금 무슨 일이 벌어지고 있나요?

하나 더

"손님이 몰려도 버티게 미리 만들어 두기(캐시)를 걸겠습니다." 여기서 사장님이 반드시 확인해야 하는 건?

마지막

하루 방문자 30명인 서비스에서, 나중을 대비해 서버를 여러 대로 늘려 두는 건 어떨까요?

직접 해보기

연결 센터에서 남의 회사 한도를 세어 보세요

표의 5번 병목은 내 서버와 상관없이 몰린 순간 바로 와요. 결제·문자·지도·AI처럼 붙어 있는 것이 몇 개인지 목록으로 확인하고, 각 회사 발급 화면에서 한도를 보는 것이 다음 순서예요. 지금 아무것도 바꾸지 않아도 돼요.

연결 센터 열기

Q. 몇 명까지 버티는지 지금 알 수 있나요?: 재 보지 않으면 알 수 없어요. 여러 명이 한꺼번에 들어오는 상황을 일부러 만들어 보는 시험으로 확인하는데, 이건 개발자에게 맡기는 게 맞아요. 사장님이 챙길 것은 결과를 "동시 몇 명에서 응답 몇 초"라는 숫자로 받는 것이에요.
Q. 무료로 쓰는 호스팅이면 몰릴 때 어떻게 되나요?: 업체마다 다르고, 보통 일정량을 넘기면 느려지거나 잠시 막혀요. 어떤 곳은 초과분을 요금으로 받아요. 이건 추측하지 말고 쓰는 업체의 요금표와 초과 시 정책을 직접 확인하세요. 호스팅에 어디를 봐야 하는지 정리돼 있어요.
Q. 사진을 가까운 창고에 복사한다는 게 뭐예요?: 손님이 서울에 있는데 사진이 미국 서버에만 있으면 매번 바다를 건너와요. 그래서 사진 같은 안 바뀌는 파일은 여러 지역에 미리 복사해 두고 가까운 곳에서 꺼내 줘요. 사진이 많은 서비스에서 가장 값싸게 크게 먹히는 방법이에요.
Q. 몰려서 결제만 실패했어요. 서버 문제인가요?: 아닐 가능성이 높아요. 결제사나 문자 회사가 정한 호출 한도에 걸린 거예요. 내 서버를 열 배로 키워도 이건 안 풀려요. 남의 회사 한도를 올려 달라고 요청하거나, 몰릴 때 순서대로 흘려보내는 방식으로 풀어요.
Q. 무너진 뒤에는 어떻게 살려요?: 쌓인 줄을 비우는 게 먼저예요. 손님을 잠깐 막아 두고(대기 화면) 쌓인 것을 처리한 다음 다시 열어요. 손님을 계속 받으면서 살리려고 하면 계속 안 살아나요. 순서는 사고 대응을 따르세요.
Q. AI 기능이 들어간 서비스는 몰릴 때 뭐가 다른가요?: 하나 더 있어요. 요청 한 건마다 돈이 나가니까, 몰림이 곧 요금이에요. 사람 백 배는 요금 백 배예요. 그래서 AI가 들어간 서비스는 몰림 대비에 반드시 한도를 함께 걸어요. AI 요금 쪽에 걸어 두는 방법이 있어요.

더 깊이 (안 읽어도 괜찮아요)

비유가 어디까지 맞고 어디부터 다른가 · 계산대 비유는 "좁은 한 곳이 전체를 정한다"까지 정확해요. 다른 점은 늘리는 속도예요. 계산대는 사서 설치해야 하지만 서버는 몇 분 만에 대수를 늘릴 수 있어요. 그래서 몰림 대비의 승부는 장비가 아니라 재 봤는지, 되돌릴 수 있는지에서 갈려요.

동시 접속자와 하루 방문자는 다른 숫자예요 · 하루 만 명이라도 24시간에 고르게 퍼지면 동시에는 몇 명뿐이에요. 반대로 하루 천 명이 방송 10분에 몰리면 동시 수백 명이에요. 서비스를 무너뜨리는 건 하루 숫자가 아니라 가장 몰린 10분의 숫자예요. 통계에서 볼 것도 그 최고점이에요.

왜 조회 하나가 만 건 넘으면 갑자기 느려지나 · 찾는 방법의 차이예요. 색인이 없으면 프로그램은 처음부터 끝까지 다 훑어요. 천 건일 때는 다 훑어도 순식간이라 아무도 몰라요. 만 건, 십만 건이 되면 같은 화면이 몇 초로 늘어요. 장부에 색인표를 붙이는 것과 같고, 이건 서버 사양이 아니라 데이터베이스 쪽 손질이에요.

미루기가 가장 저평가된 방법이에요 · 손님 화면이 늦는 이유의 상당 부분은 손님이 기다릴 필요 없는 일을 그 자리에서 하기 때문이에요. 주문 알림 발송, 집계, 외부 회사 호출을 뒤로 미루면 손님 화면만 눈에 띄게 빨라져요. 돈이 거의 안 들면서 효과가 큰 쪽이라, 대수를 늘리기 전에 먼저 보는 게 맞아요.

안 무너지는 서비스는 목표가 아니에요 · 큰 회사도 몰림에 무너져요. 차이는 무너졌을 때의 모습이에요. 준비된 쪽은 사진이 안 보이고 대기 순번이 뜨는 정도로 끝나고, 준비 안 된 쪽은 흰 화면과 오류로 끝나요. 목표는 완벽이 아니라 무너지는 방식을 고르는 것이에요.

이것만 기억하세요

·무너지는 곳은 전체가 아니라 가장 좁은 한 곳이에요. 그곳을 넓히면 다음 좁은 곳이 나와요
·여유가 0이 되는 순간 갑자기 무너져요. 손님의 새로고침이 그 불에 부채질을 해요
·순서는 재기, 줄이기, 미리 만들어 두기, 그다음이 대수 늘리기예요. 사양부터 올리는 건 돈으로 시간을 사는 것
·손님이 적을 때 미리 넓히는 건 대비가 아니라 매달 나가는 손해예요
·맡길 때는 공사 전후 숫자, 병목 지목, 옛 값 허용 목록, 되돌리는 방법, 매달 늘어나는 비용을 문서로 받으세요