> ## Content Index
> Fetch the complete content index at: https://zerodraftlab.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# 유저는 0명인데 서버는 10만 명을 걱정한다
- URL: https://zerodraftlab.com/scale-follows-demand/
- Published: 2026-08-09T03:19:57.000Z
- Updated: 2026-09-15T08:34:59.000Z
- Author: JooMong

토끼가 AI로 사이드프로젝트 하나를 만들고 싶다고 말한다. 곧바로 세 명이 끼어든다. 계획도 없이 프롬프트만 치면 끝날 줄 알았느냐, 로그인과 결제와 에러 처리는 생각했느냐, 유저 10만 명이 몰리면 서버는 누가 버틸 것이냐.

질문 하나하나는 틀리지 않았다. 계정이 있는 제품에는 로그인이 필요하고, 돈을 받으면 결제 실패를 다뤄야 하며, 사용자가 늘면 서버도 버텨야 한다. 그런데 이 정답들을 한꺼번에 꺼내는 순간 제품은 시작 전에 완성품의 의무를 떠안는다. 아직 한 명도 쓰지 않는 서비스가 10만 명의 트래픽을 견디기 위해 첫 사용자를 만나는 일을 미룬다.

상상 속 성공은 이상하게 구체적이다. 데이터베이스를 어떻게 나눌지, 큐를 어디에 둘지, 다중 리전을 언제 열지까지 그릴 수 있다. 반면 첫 사용자가 왜 이 제품을 켜야 하는지는 흐릿하다. 기술 문제는 답을 찾을 수 있어서 편하고, 수요 문제는 거절을 만나야 해서 불편하다. 확장성은 이 불편을 엔지니어링 문제로 바꿔주는 좋은 피난처가 된다.

폴 그레이엄은 [「Do Things that Don't Scale」](https://www.paulgraham.com/ds.html?ref=zerodraftlab.com)에서 초기 스타트업은 사용자를 한 명씩 직접 모집하고, 필요하면 소프트웨어가 해야 할 일까지 사람이 대신하라고 썼다. 자동화할 병목을 알기 전에 자동화부터 해두는 것보다, 실제 문제를 손으로 해결하면서 무엇이 반복되는지 배우는 편이 낫다는 주장이다. 그는 실수의 대가가 큰 영역은 예외라고도 선을 그었다.

**현재의 증거보다 앞선 규모는 만들지 않는다.** 사용자가 다섯 명이면 다섯 명의 행동을 정확히 볼 수 있어야 한다. 유료 제품이면 실제 결제가 한 번 끝나야 한다. 핵심 작업이 실패하면 원인을 찾고 복구할 수 있어야 한다. 이 요구는 지금 존재한다. 10만 동시접속은 아직 존재하지 않는다.

마틴 파울러가 설명한 [YAGNI](https://martinfowler.com/bliki/Yagni.html?ref=zerodraftlab.com)는 아직 쓰이지 않을 능력을 미리 구현할 때 생기는 비용을 다룬다. 구현비뿐 아니라 가치가 늦게 전달되는 비용과, 복잡성을 계속 들고 가는 비용이 생긴다. 더 큰 문제는 요구가 실제로 도착했을 때 과거의 추측으로 만든 구조가 맞지 않을 수 있다는 점이다.

첫 제품이 견뎌야 할 것은 상상 속 유명세가 아니라 다음번 진짜 학습이다. 로그인, 결제, 테스트, 보안, 배포, 확장성 가운데 무엇을 지금 넣고 무엇을 뒤로 미룰지는 틀렸을 때의 비용과 되돌리기 어려운 정도로 가른다.

같은 로그인도 커뮤니티 프로필을 위한 로그인과 환자 기록을 여는 로그인은 다르다. 같은 결제도 테스트용 가격 버튼과 자동 갱신 구독은 다르다. “초기 제품이니까”라는 말은 낮은 트래픽을 설명할 수는 있어도 돈과 개인정보를 잃어도 된다는 허가는 아니다.

## 미뤄도 되는 복잡성과 미루면 안 되는 책임

유저 10만 명을 위한 샤딩, 여러 지역에 걸친 복제, 복잡한 이벤트 버스는 대개 아직 일어나지 않은 부하를 위한 능력이다. 반면 결제 금액이 맞는지, 비밀번호와 세션이 안전한지, 실패한 작업을 다시 실행해도 중복 청구되지 않는지는 현재 한 명의 사용자에게도 영향을 준다. 전자는 수요의 증거가 생길 때 키울 수 있지만 후자는 첫 거래부터 책임져야 한다.

[OWASP ASVS](https://owasp.org/www-project-application-security-verification-standard/?ref=zerodraftlab.com)는 애플리케이션이 다루는 자산과 신뢰 수준에 맞춰 어떤 보안 통제를 확인할지 합의하는 기준을 제공한다. 회원 계정이 없는 실험에 인증 시스템을 미리 만들 필요는 없다. 계정과 민감정보를 받기로 했다면 보안은 현재 제품의 일부가 된다.

미래 용량을 덜어낸 자리에 무엇을 남겨야, 지금은 작게 만들면서 나중에는 싸게 바꿀 수 있을까?

YAGNI에도 같은 예외가 있다. 파울러는 리팩터링, 자동화된 테스트, 지속적 배포처럼 코드를 바꾸기 쉽게 만드는 활동을 미래 기능과 구분한다. 이 장치들은 언젠가 필요할 기능을 미리 구현하는 것이 아니라, 오늘의 판단이 틀렸을 때 싸게 고칠 수 있게 한다. 초기 제품에 필요한 기술적 여유는 10만 명을 위한 용량보다 방향을 바꿀 수 있는 가역성에 가깝다.

## 시간을 고정하면 상상이 잘린다

Basecamp의 [Shape Up](https://basecamp.com/shapeup/1.2-chapter-03?ref=zerodraftlab.com)은 일을 시작하기 전에 얼마나 오래 쓸지 정하고, 그 시간 안에 들어오도록 범위를 바꾸는 방식을 제안한다. 예상 기능을 모두 쌓은 뒤 기간을 계산하는 대신, 이 문제에 쓸 수 있는 시간부터 정하면 설계가 제약을 받는다. “있으면 좋은 것”이 “이번에 없으면 사용자가 핵심 작업을 끝내지 못하는가”라는 질문을 통과해야 한다.

AI 사이드프로젝트라면 이 제약은 더 중요하다. 코드를 빨리 만들 수 있으니 생각나는 기능을 모두 넣기 쉬워졌고, 서로 다른 라이브러리를 연결해 본격적인 시스템처럼 보이게 만들기도 쉬워졌다. 제작 속도가 빨라진 만큼 잘못 고른 범위를 완성하는 속도도 빨라졌다.

처음 다섯 명에게 유료로 한 가지 작업을 끝내게 하려는 제품을 생각해보자. 결제가 가설의 일부라면 결제 흐름은 필요하다. 핵심 작업이 오래 걸린다면 진행 상태와 실패 복구도 필요하다. 그러나 다섯 명이 같은 시간에 몰려도 버티는 단일 앱과 데이터베이스가 있다면, 10만 명을 위한 마이크로서비스는 다음 가설을 검증하지 않는다. 오히려 로그가 여러 곳으로 갈리고 배포 지점이 늘어 첫 실패의 원인을 찾기 어려워질 수 있다.

## 규모는 숫자가 아니라 사건으로 도착한다

확장 준비를 언제 시작할지 달력으로 정할 수는 없다. 실제 응답 시간이 핵심 작업을 방해하고, 수작업이 주문을 놓치게 하고, 데이터 양 때문에 배치가 끝나지 않고, 한 고객의 계약이 특정 격리를 요구하는 순간이 온다. 이때 규모는 상상이 아니라 관찰된 병목이나 합의된 의무다. 그 증거에 맞춰 캐시, 큐, 파티셔닝, 격리를 한 단계씩 더하면 된다.

반론도 있다. 갑작스러운 방송 노출이나 대형 캠페인처럼 첫날부터 많은 사람이 들어올 것이 확정된 제품은 미리 용량을 준비해야 한다. 데이터 구조를 나중에 바꾸기 매우 비싼 제품도 있다. 하지만 이것은 “언젠가 잘되면”이라는 막연한 기대와 다르다. 예정된 트래픽, 체결된 계약, 법적 의무, 되돌릴 수 없는 데이터 선택은 이미 현재의 증거다.

좋은 초기 구조는 미래를 정확히 맞히지 않는다. 틀린 예측을 제거하고, 실제 사용에서 나온 다음 요구를 받아들일 자리를 남긴다. 첫 번째 서버의 임무는 10만 명을 견디는 것이 아니라 한 명의 결제를 잃지 않고, 한 번의 실패를 설명하며, 다음 변경을 두려움 없이 배포하게 하는 것이다.

---

초기 사용자를 직접 모집하고 수작업으로 병목을 배우는 설명은 Paul Graham의 [「Do Things that Don't Scale」](https://www.paulgraham.com/ds.html?ref=zerodraftlab.com), 추정 기능의 구현·지연·유지 비용과 변경 용이성의 구분은 Martin Fowler의 [「Yagni」](https://martinfowler.com/bliki/Yagni.html?ref=zerodraftlab.com), 보안 검증의 범위와 엄격도는 [OWASP ASVS](https://owasp.org/www-project-application-security-verification-standard/?ref=zerodraftlab.com), 시간 예산으로 범위를 제한하는 설명은 Ryan Singer의 [「Shape Up — Set Boundaries」](https://basecamp.com/shapeup/1.2-chapter-03?ref=zerodraftlab.com)를 대조했다. “규모는 수요의 증거 뒤에 온다”와 현재 책임·미래 용량을 나누는 구분은 이 글의 해석이다.