사용자가 늘면 무엇부터 느려질까요 | 확장 비용이 생기는 자리
서비스가 커질 때 운영비는 고르게 늘지 않고 특정 지점에서 계단처럼 뛰어요. 조회 속도·파일 저장·건당 과금 알림 세 곳이 먼저 걸리는데, 자체 SaaS 4종을 10년 이상 운영하며 겪은 순서대로 어디에 미리 손을 써두면 되는지 정리했어요.
핵심 요약 — 서비스가 커질 때 비용은 완만하게 늘지 않아요. 어느 지점까지는 거의 그대로였다가 계단처럼 뛰어요. 실제로 먼저 걸리는 곳은 대체로 정해져 있어요. 쌓인 데이터를 훑는 조회, 파일과 이미지 저장, 그리고 건당 돈이 나가는 알림이에요. 자체 SaaS 4종을 직접 운영하며 이 순서를 여러 번 겪었고, 처음 만들 때 몇 자리만 끊어두면 대부분 미리 피할 수 있어요.
“사용자가 두 배 되면 서버비도 두 배쯤 되겠죠?”
발주 단계에서 자주 나오는 질문이에요. 그렇게 되면 계획을 세우기 편할 텐데, 실제로는 그렇게 안 움직여요. 한동안 거의 그대로 있다가 어느 순간 한 번에 뛰고, 또 한동안 잠잠해요.
그 뛰는 지점이 어디인지는 대체로 정해져 있어요. 오늘은 그 순서를 정리해볼게요.
1. 왜 사용자가 늘면 갑자기 느려질까요
느려지는 건 대개 사람이 많아져서가 아니라 데이터가 쌓여서예요.
이 둘은 다르게 움직여요. 동시에 들어오는 사람이 많으면 순간적으로 버거워지지만, 사람이 빠지면 원래대로 돌아와요. 반대로 쌓인 데이터가 많아서 느린 건 시간이 지나도 안 돌아와요. 오히려 매일 조금씩 더 느려져요.
그래서 오픈 직후엔 아무 문제가 없다가 반년쯤 지나 “요즘 좀 느린 것 같은데”가 시작돼요. 이때 서버 사양을 올리면 잠깐 나아지는데, 몇 달 뒤 같은 자리로 돌아와요. 원인이 사양이 아니라 조회 방식에 있기 때문이에요.
2. 가장 먼저 막히는 곳은 어디인가요
목록 화면이에요.
거의 예외가 없어요. 주문 목록, 회원 목록, 게시물 목록처럼 쌓인 걸 죽 보여주는 화면이 제일 먼저 느려져요. 만들 때는 데이터가 100건이라 순식간이었는데, 10만 건이 되면 같은 코드가 몇 초씩 걸려요.
그다음이 검색과 통계예요. “이번 달 매출 얼마”처럼 전체를 한 번 훑어야 나오는 숫자들이요. 관리자 화면에서 이런 걸 눌렀는데 화면이 멈춘 것처럼 보인다면 대개 여기예요.
고치는 방법 자체는 어렵지 않아요. 자주 찾는 기준으로 색인을 걸거나, 한 번에 다 불러오지 않고 나눠서 가져오거나, 매번 계산하지 말고 미리 세어둔 값을 쓰는 식이에요. 문제는 오픈하고 한참 뒤에 발견된다는 거예요. 그때는 이미 데이터가 많아서 고치는 작업 자체가 조심스러워져요.
3. 파일과 이미지는 언제 문제가 되나요
용량보다 위치가 먼저 문제가 돼요.
사용자가 올리는 사진과 첨부파일을 서버 안에 그냥 쌓아두는 구조가 있어요. 처음엔 아무 문제가 없어요. 그런데 두 가지 순간에 걸려요. 서버를 한 대 더 늘릴 때, 그리고 서버를 옮길 때예요.
파일이 서버 안에 있으면 서버가 늘어나는 순간 어느 쪽에 저장됐는지에 따라 보이고 안 보이고가 갈려요. 옮길 때도 몇 십 기가씩 되는 파일을 통째로 복사해야 하고요. 저희도 서비스를 운영하면서 이 자리에서 시간을 쓴 적이 있어요. 그 뒤로는 파일 저장 위치를 처음부터 밖으로 빼두는 걸 기본으로 잡아요.
비용 자체는 저장소가 서버보다 저렴한 편이에요. 대신 이미지가 많은 서비스는 내보내는 양에서 돈이 나가요. 사용자가 볼 때마다 원본을 그대로 내려보내면 그만큼 쌓여요. 크기를 줄인 버전을 따로 만들어두는 게 결국 비용 얘기인 이유예요.
4. 알림·문자·메일은 왜 비용이 튈까요
여기가 가장 예측이 어긋나는 자리예요.
서버는 사람이 늘어도 어느 정도까지 버텨줘요. 그런데 문자와 알림톡, 메일은 보낸 만큼 그대로 돈이 나가요. 회원이 두 배가 되면 이쪽은 정직하게 두 배가 돼요.
문제는 건수가 회원 수보다 빨리 는다는 점이에요. 주문 하나에 접수·발송·완료 알림이 나가면 주문 1건당 3건이에요. 여기에 마케팅 알림까지 붙으면 더 늘고요. 회원이 두 배 될 때 발송 건수는 세 배가 되는 식이에요.
용어 정리 — 건당 과금은 쓴 만큼 계산하는 방식이에요. 정액은 정해진 금액을 매달 내는 방식이고요. 개발비는 보통 한 번 내면 끝나지만, 이런 항목은 서비스가 살아 있는 동안 계속 나가요. 견적서에서 “개발 범위 외”로 적혀 있는 줄이 대개 여기예요.
5. 서버를 키우면 해결되나요
절반은 되고 절반은 안 돼요.
사양을 올려서 넘어가는 구간이 분명히 있어요. 동시 접속이 몰려서 느린 거라면 서버를 키우거나 대수를 늘리는 게 가장 빠르고 확실한 방법이에요. 사람 손도 덜 들어가고요.
안 되는 쪽은 앞에서 본 조회 문제예요. 10만 건을 매번 처음부터 훑는 코드는 서버가 두 배로 빨라져도 여전히 10만 건을 훑어요. 조금 빨라진 것처럼 보이다가 데이터가 더 쌓이면 원래 자리로 돌아와요.
판단 기준은 단순해요. 사람이 빠졌을 때 빨라지면 사양 문제, 새벽에도 느리면 구조 문제예요. 이 한 줄만 알고 계셔도 개발사와 얘기할 때 방향이 훨씬 빨리 잡혀요.
6. 처음 만들 때 무엇을 정해두면 나중이 덜 아플까요
전부 대비할 필요는 없어요. 갈아끼울 자리만 끊어두면 돼요.
처음부터 대규모를 전제로 만들면 개발 기간이 길어지고 운영도 복잡해져요. 사용자가 몇 백 명인 단계에서는 손해인 경우가 많아요. 대신 나중에 바꿔야 할 자리를 한 곳에 모아두는 건 비용이 거의 안 들어요.
| 미리 끊어둘 자리 | 지금 안 해두면 |
|---|---|
| 파일 저장 위치 | 서버 늘릴 때 전체를 손대게 돼요 |
| 알림 보내는 통로 | 업체 바꿀 때 코드 곳곳을 고쳐요 |
| 목록 조회 방식 | 데이터 쌓인 뒤 고치기가 조심스러워요 |
| 통계 계산 위치 | 관리자가 누를 때마다 서비스가 함께 느려져요 |
저희가 자체 서비스를 운영하면서 배운 것도 이 지점이에요. 초기 기능을 몇 개 더 넣었는지보다, 이런 자리를 끊어뒀는지가 2～3년 뒤 비용을 훨씬 크게 바꿨어요. 기능은 나중에 추가하면 되는데, 구조는 나중에 바꾸려면 멈춰야 하거든요.
지금 만들고 계신 서비스가 어느 규모까지 갈지 애매해도 괜찮아요. 어떤 자리를 미리 끊어두면 되는지부터 짚어드릴 수 있어요. 운영까지 보는 관점으로 상담받기 →
7. 견적서에서 확장은 어떻게 보이나요
두 줄만 확인하시면 돼요.
예상 규모가 적혀 있나요. 동시 접속 몇 명, 데이터 몇 건을 전제로 만든 건지가 있어야 해요. 이 숫자가 없으면 나중에 느려졌을 때 누구 책임인지 가릴 근거도 없어요.
건당 나가는 비용이 누구 부담인가요. 문자·알림톡·결제 수수료·지도나 인증 같은 외부 서비스 사용료요. 개발비에 안 들어가는데 오픈하면 매달 나가는 자리예요. 이 줄이 비어 있으면 오픈 첫 달 청구서에서 놀라게 돼요.
이 두 줄이 적혀 있는 견적서는 대개 운영을 해본 곳에서 나와요. 만들어서 넘기는 것까지만 본 견적서에는 이 항목이 잘 안 보여요.
8. 자주 묻는 질문
사용자가 늘면 서버만 키우면 되나요?
동시 접속 때문이면 사양을 올려 넘길 수 있어요. 쌓인 데이터 때문이면 사양을 올려도 다시 느려져요. 사람이 빠졌을 때 빨라지는지로 나눠서 보시면 돼요.
확장을 처음부터 대비해서 만들면 비용이 얼마나 더 드나요?
전부 대비하면 많이 들고, 바꿀 자리만 끊어두면 거의 안 들어요. 파일 저장 위치와 알림 통로를 한 곳에서 갈아끼울 수 있게 해두는 정도면 충분해요.
견적서에서 확장성은 어떻게 확인하나요?
예상 사용자 수와 데이터 양, 그리고 건당 나가는 비용의 부담 주체가 적혀 있는지 보세요. 두 줄이면 대략 판단이 돼요.
9. 마무리
서비스가 커질 때 드는 돈은 서버비가 전부가 아니에요. 조회 방식, 파일이 놓인 자리, 건당 나가는 알림처럼 처음엔 안 보이던 곳에서 계단이 생겨요.
다행인 건 이 순서가 대체로 정해져 있다는 점이에요. 미리 알고 몇 자리만 끊어두면 대부분은 그 계단을 완만하게 만들 수 있어요.
저희는 10년 넘게 50개 이상 프로젝트를 진행하고 자체 SaaS 4종을 직접 운영해온 개발사예요. 누적 60만+ 사용자를 받아본 서비스를 직접 지켜보면서 이 계단을 여러 번 올라가 봤어요. 롯데·캐논 같은 곳과도 함께해 왔고요. 지금 어느 단계인지만 알려주시면 무엇부터 손봐야 할지 같이 짚어볼게요 →
관련 글