저는 많은 소규모 비즈니스 사이트들이 "아무도 방문하지 않는 곳"에서 갑자기 북적이는 곳으로 변하는 과정을 지켜봐 왔습니다. 바이럴 게시물, 지역 뉴스의 언급, 혹은 계절적 급증 같은 이유로 말이죠. 무엇이 무너지는지에 대한 패턴은 주니어 개발자들이 예상하는 것과 거의 일치하지 않습니다.

공유 호스팅 (Shared hosting)은 창피할 정도로 빠르게 한계에 도달합니다. 코드가 아무리 깔끔하더라도, 월 5달러짜리 공유 플랜을 사용 중이라면 하루 방문자가 50명일 때 잘 돌아가던 사이트가 500명이 되면 쓰러질 수 있습니다. 해결책은 대개 재작성 (Rewrite)이 아닙니다. 호스팅 티어 (Hosting tier) 업그레이드와 기본적인 캐싱 (Caching)입니다. 저는 실제 병목 현상 (Bottleneck)이 공유 CPU 할당량이었던 사이트에서 개발자들이 일주일 동안 쿼리 (Query) 최적화에 매달리는 것을 본 적이 있습니다.

페이지가 무너지기 전에 양식 (Forms)이 조용히 실패합니다. 부하가 걸리면 문의 양식이나 결제창이 가장 먼저 조용히 작동을 멈추는 경우가 많습니다. 타임아웃 (Timeout), 플러그인 충돌 (Plugin conflict), 이메일 서비스의 속도 제한 (Rate limit) 등이 원인이 될 수 있으며, 그동안 사이트의 나머지 부분은 완전히 정상적으로 보입니다. 소규모 비즈니스 사이트에서 아무도 양식 제출 로그를 들여다보지 않기 때문에 아무도 알아차리지 못합니다. 이것은 제가 고객들과 나누는 "왜 2주 치의 잠재 고객 (Leads)을 놓쳤나요?"라는 대화 중 가장 흔한 사례입니다.

아무도 계획을 세우지 않는데, 그 이유는 아무도 계획이 필요할 것이라고 예상하지 못했기 때문입니다. 엔터프라이즈 (Enterprise) 프로젝트는 부하 테스트 (Load-tested)를 거칩니다. 하지만 동네 빵집의 사이트는 그렇지 않습니다. 트래픽이 급증할 때, 고객의 본능은 대시보드 (Dashboard)를 확인하는 것이 아니라 패닉에 빠져 당신에게 이메일을 보내는 것입니다. 확인할 대시보드 자체가 애초에 없었기 때문입니다. 출시 시점에 설정해 둔 최소한의 업타임 (Uptime) 및 양식 전달 모니터링만 있어도, 소방 훈련 같은 상황을 5분 만에 해결할 수 있는 작업으로 바꿀 수 있습니다.

고객의 진짜 질문은 "사이트가 다운되었나요?"가 아니라 "지금 돈을 잃고 있나요?"입니다. 기술적인 사후 분석 (Technical postmortems)은 이들에게 와닿지 않습니다. 그들에게 와닿는 것은 다음과 같습니다: 무엇이 고장 났는지, 그것이 비용을 얼마나 발생시켰을 가능성이 있는지, 그리고 다시는 이런 일이 발생하지 않도록 무엇을 변경하는지입니다. 사고 보고서 (Incident reports)를 근본 원인 (Root cause) 대신 비즈니스 영향 (Business impact)을 중심으로 구성하는 것이 실제로 리테이너 (Retainer, 유지보수 계약)를 유지하는 방법입니다.

확장 가능한 제품 (Scaled products) 대신 소규모 비즈니스를 위해 구축한다면, "트래픽 처리"는 시스템 설계 (System design) 문제가 아니라 모니터링 (Monitoring)과 기대치 (Expectations)의 문제입니다. 코드는 거의 항상 가장 먼저 실패하는 요소가 아닙니다.