오랫동안 우리 회사의 용량 계획 (Capacity Planning)은 대시보드를 지켜보다가 무언가 주황색으로 변하면, 부족해진 리소스를 더 구매하는 것을 의미했습니다. 데이터베이스 스토리지 (Database storage)가 한계치에 다다르면 누군가 티어 (Tier)를 올렸습니다. 바쁜 주간에 큐 (Queue)가 쌓이면 누군가 워커 (Worker)를 추가했습니다. 모든 결정은 개별적으로는 옳았지만, 전체적인 접근 방식은 이미 문제가 발생하기 시작한 상황에 대해 한 발 늦게 반응하는 것에 불과했습니다.

불편한 점은 이 중 그 어떤 것도 실제로 계획 (Planning)이 아니었다는 것입니다. 계획이란 필요하기 전에 무엇이 필요할지 아는 것을 의미합니다. 제가 하고 있었던 일은 결핍이 발생한 후에 이를 인지하고, 그 해결책을 계획이라고 불렀던 것인데, 이는 사실 문제와 고통 사이의 지연 시간만 길어진 응급 처치 (Triage)에 불과했습니다.

Claude Code는 성장이 이미 결정을 강요한 후에 측정하는 대신, 성장이 일어나기 전에 모델링 (Modeling)하는 비용을 낮춤으로써 이 상황을 변화시켰습니다. 용량 계획 (Capacity Planning)의 근저에 깔린 수학적 계산은 결코 어려운 부분이 아니었습니다. 숫자가 주황색으로 변하기 전에, 중요한 모든 리소스에 대해 정기적으로 앉아 실제로 이를 실행하는 것이 아무도 시간을 낼 수 없었던 부분이었습니다. 여기 그 워크플로우 (Workflow)가 있습니다.

반응형 스케일링 (Reactive Scaling)이 괜찮게 느껴지다가 결국 문제가 되는 이유

반응형 스케일링 (Reactive Scaling)은 주황색 대시보드가 결국 수정되고 시스템이 계속 작동한다는 좁은 의미에서는 효과가 있습니다. 하지만 이것이 해주지 못하는 것은 누군가가 좋은 결정을 내릴 수 있는 시간을 주는 것이 아닙니다. 데이터베이스 티어 (Database tier)는 미리 선택된 차분한 순간이 아니라, 압박감이 느껴지는 상황에서 그 순간에 존재하는 가격과 마이그레이션 리스크 (Migration risk)를 감수하며 업그레이드됩니다.

더 깊은 문제는 반응형 스케일링 (Reactive Scaling)이 모든 리소스를 독립적인 것으로 취급한다는 점입니다. 스토리지는 모니터링됩니다. 컴퓨팅 (Compute)도 모니터링됩니다. 하지만 그들 사이의 관계를 지켜보는 사람은 아무도 없습니다. 따라서 성장이 지속됨에 따라 가장 먼저 고갈될 단 하나의 리소스, 즉 실제 제약 조건 (Constraint)은 사고를 일으키는 주체가 될 때까지 보이지 않는 상태로 남아있게 됩니다.

성장 또한 선형적이지 않으며, 지난 분기의 성장률을 기반으로 구축된 계획은 아무도 알아차리지 못하는 사이에 조용히 현실과 어긋나기 시작합니다. 1년 동안 매월 10%씩 꾸준히 성장하는 것처럼 보였던 트래픽 곡선도, 기능 출시(Feature launch)나 새로운 고객 세그먼트의 유입 이후 하룻밤 사이에 형태가 바뀔 수 있습니다. 이때 기존의 용량 모델(Capacity model)은 예측이 틀리기 직전까지 계속해서 여유로운 헤드룸(Headroom)이 있다고 보고합니다.

용량을 사전에 예측해 본 적이 없는 시스템은 안전 마진(Safety margin)을 가지고 있지 않습니다. 단지 측정되지 않은 마진을 가지고 있을 뿐이며, 측정되지 않은 마진은 문제가 발생하는 바로 그 주가 되기 전까지는 건강한 마진과 똑같아 보입니다.

아래의 워크플로우는 용량 계획(Capacity planning)을 주황색 대시보드가 경고를 울릴 때 시작되는 사후 대응적 허둥지둥(Reactive scramble)에서, 성장의 뒤를 쫓는 대신 성장을 앞서 나가는 일상적인 예측 과정으로 전환해 줍니다.

시스템이 모델링되지 않은 부하(Load)를 만났을 때 어떤 일이 발생하는지에 대한 관련 내용은 Claude Code for Load Testing을 참조하십시오. 해당 글은 현재 임계점(Breaking point)이 어디인지에 대해 다룹니다. 본 워크플로우는 성장이 언제 그 임계점에 도달할 것인지에 대해 답합니다.

성장 모델링 기술 (The Growth Modeling Skill)

첫 번째 기술은 스토리지(Storage), 컴퓨팅(Compute), 데이터베이스 연결(Database connections), 큐 처리량(Queue throughput), 요청 볼륨(Request volume) 등 중요한 모든 리소스에 걸쳐 사용량이 실제로 어떻게 추세(Trending)를 보이는지에 대한 정직한 그림을 그리는 것입니다. 이 기술은 노이즈(Noise)와 실제 추세를 구분할 수 있을 만큼 충분히 긴 기간 동안의 과거 사용 데이터를 추출하며, 모든 것이 동일한 속도로 성장한다고 가정하는 대신 각 리소스에 독립적으로 성장 곡선(Growth curve)을 맞춥니다.

이것이 중요한 이유는 리소스들이 함께 성장하지 않기 때문입니다. 누적된 데이터로 인해 스토리지는 꾸준히 성장하는 동안 요청 볼륨은 평탄할 수 있습니다. 특정 기능으로 인해 컴퓨팅은 급증할 수 있지만 데이터베이스 연결은 안정적으로 유지될 수도 있습니다. 성장을 하나의 숫자로 취급하는 것은 결국 예상치 못한 상황을 초래하는 바로 그 '차이(Divergence)'를 숨기게 됩니다.

이 기술은 또한 리소스의 성장 곡선 모양이 최근에 변경되었는지 여부를 표시합니다. 기울기의 변화는 상위 스트림(upstream)에서 무언가 변경되었다는 신호이기 때문입니다. 새로운 기능, 새로운 고객 세그먼트, 변경된 사용 패턴 등이 원인이 되어 기존 예측이 더 이상 적용되지 않게 됩니다.

임계값 기술 (The Threshold Skill)

성장 곡선을 아는 것은 실제 한계가 어디에 있는지 알아야만 유용합니다. 두 번째 기술은 모든 리소스를 실제 최대치(real ceiling)와 비교하여 매핑합니다. 데이터베이스 계층이 포화되는 지점, 큐의 처리량(throughput)이 더 이상 속도를 따라잡을 수 없는 지점, 응답 시간이 저하되기 전에 컴퓨팅 클러스터가 노드를 추가해야 하는 지점 등이 해당됩니다.

이 기술은 이론적인 최대치보다는 실질적인 한계까지 고려합니다. 데이터베이스는 쿼리 지연 시간(query latency)이 오르기 시작하는 지점보다 더 많은 연결을 기술적으로 지원하지만, 실제로 중요한 것은 후자입니다. 스토리지도 마찬가지로, 디스크가 문자 그대로 가득 차기 훨씬 전에 성능이 저하되는 경우가 많습니다.

성장 곡선과 실제 임계값을 결합하면 실제로 중요한 숫자가 나옵니다: 예상 날짜입니다. 단순히

이는 인프라 지출이 증가하고 있다는 막연한 느낌을 구체적이고 날짜가 명시된 숫자로 바꿔줍니다. 즉, 아무런 변화가 없을 때 3개월 후의 청구서가 어떤 모습일지, 그리고 각각의 현실적인 확장 옵션(scaling option) 하에서는 어떤 모습일지를 보여줍니다. 또한 단순한 용량 관점에서는 완전히 놓치기 쉬운 옵션, 즉 한계치(ceiling)에 도달했을 때의 해답이 더 높은 티어(tier)로 올라가는 것이 아니라, 티어 업그레이드 자체가 필요 없도록 만드는 아키텍처 변경(architectural change)일 수도 있다는 점을 드러내 줍니다. 이러한 트레이드오프(tradeoff)는 비용과 용량이 동일한 보고서에 함께 놓일 때에만 비로소 가시화됩니다.

이는 Claude Code를 활용한 성능 최적화 패턴 (Claude Code for Performance Optimization Patterns)의 이면에 있는 것과 동일한 원칙이며, 현재 사용량에 드는 비용이 아니라 성장에 따라 비용이 얼마나 들 것인가라는 질문에 적용된 것입니다.

계획 보고서 기술 (The Planning Report Skill)

네 번째 기술은 성장 곡선, 임계값(thresholds), 비용 예측치를 누군가가 압박 속에서 해석해야 하는 숫자 더미가 아니라, 팀이 실제로 의사결정을 내릴 수 있는 무언가로 변환합니다. 이 기술은 긴급도에 따라 순위가 매겨진 보고서를 생성합니다. 즉, 어떤 리소스가 가장 빨리 한계치에 도달하는지, 그 시점의 옵션은 무엇인지, 각 옵션의 비용은 얼마인지, 그리고 각 옵션을 안전하게 실행하는 데 필요한 리드 타임(lead time)은 얼마인지를 보여줍니다.

이 보고서는 실행될 때마다 이러한 예측치를 시간에 따라 추적하므로, 변화하는 성장 곡선이 문제가 되는 주에 갑작스럽게 발견되는 놀라운 사건이 아니라 하나의 트렌드(trend)로서 가시화됩니다. 릴리스가 거듭될수록 계속해서 앞당겨지는 예상 날짜는 안정적인 상황과는 매우 다른 상황이며, 오직 추적된 이력만이 어떤 상황이 벌어지고 있는지를 보여줍니다.

또한 트래픽 모델이 마케팅 캠페인과 연결되는 것과 같은 방식으로, 용량 예측을 이미 알려진 향후 이벤트와 연결합니다. 만약 성장 곡선이 이미 2개월 내에 데이터베이스가 한계치에 도달할 것임을 보여주고 있고, 새로운 고객 온보딩(onboarding)이 그 곡선을 가속화할 것으로 예상된다면, 보고서는 문제가 발생하는 사고(incident) 도중에 이를 드러내는 대신, 충돌이 일어나기 전에 미리 이를 표면화합니다.

실제 워크플로우 작동 방식 (How the Workflow Runs in Practice)

성장 모델링 (growth modeling) 기술이 가장 먼저 실행되어, 현재 사용량 데이터를 기반으로 추적 중인 모든 리소스의 트렌드를 갱신합니다. 임계값 (threshold) 기술은 해당 곡선들을 실제 운영 한계치 (operating ceilings)와 대조하여, 정적인 백분율 대신 각 리소스에 대한 예상 날짜를 산출합니다. 비용 예측 (cost projection) 기술은 해당 타임라인의 각 시점에서 각 확장 경로 (scaling path)가 얼마의 비용이 드는지 계산합니다.

계획 보고서 (planning report) 기술은 이 모든 것을 하나의 순위가 매겨진 뷰 (ranked view)로 통합하며, 대시보드에 주황색 경고가 뜨는 트리거 방식이 아니라 정해진 일정에 따라 갱신됩니다. 예상 날짜가 곧 다가오는 모든 항목은 긴급한 결정 대신 차분한 결정을 내릴 수 있도록 충분한 리드 타임 (lead time)과 함께 플래그가 지정됩니다.

시간이 흐르면서 "이것을 언제 확장해야 할까?"라는 질문에 대한 답변은 어깨를 으쓱하며 허둥지둥 대처하는 방식에서 벗어났습니다. 대신 정기적으로 재계산되는 구체적인 날짜, 부착된 비용, 그리고 압박 속에서 가장 빨리 실행할 수 있는 옵션이 아닌 올바른 옵션을 선택할 수 있는 충분한 준비 기간 (runway)을 갖춘 답변이 되었습니다.

이 워크플로우가 나의 실무에 가져온 변화 (What This Workflow Did to My Practice)

첫 번째 변화는 리소스가 실제 장애 (incident)로 나타나기 두 달 전에, 문제가 될 리소스를 미리 포착하게 된 것입니다. 기능 (feature)이 출시된 후 큐 (queue)의 처리량 (throughput)에 대한 성장 곡선이 조용히 가팔라졌는데, 보고서가 이를 포착했을 때 이미 "그 큐는 괜찮아"라는 기존의 사고 모델은 틀린 상태였습니다.

두 번째 변화는 확장 (scaling) 결정이 내려지는 방식입니다. 워크플로우 도입 전에는 리소스가 실제로 고갈되는 주에 그로 인해 발생하는 압박 속에서 확장 결정이 내려졌습니다. 워크플로우 도입 후에는 몇 주 전에 결정이 이루어지며, 가장 빨리 켤 수 있는 것을 고르는 대신 비용과 노력 측면에서 옵션들을 비교할 수 있는 충분한 시간을 갖게 되었습니다.

세 번째 변화는 인프라 비용이 송장 (invoice)을 통해 매달 깜짝 놀랄 일로 다가오는 것이 멈췄다는 점입니다. 용량 곡선 (capacity curve) 옆에 예상 비용 곡선 (projected cost curve)을 함께 확인함으로써, 확장 결정과 예산 논의가 서로 어긋나는 두 개의 대화가 아닌 하나의 대화가 되었습니다.

네 번째 변화가 가장 컸습니다. 저는 리소스가 부족하다는 사실을 리소스 자체로부터 알게 되는 것을 멈추고, 몇 주 전에 이미 계산을 마친 보고서를 통해 알게 되기 시작했습니다. 이러한 변화는 용량 계획 (Capacity Planning)을 팀에게 일어나는 수동적인 사건에서, 팀이 실제로 의도적으로 수행하는 활동으로 전환시킵니다.

제가 Claude Code를 사용하여 프로덕션 시스템 (Production Systems)을 운영하는 전체적인 모습은, DEV.to의 전체 시리즈에서 용량 계획부터 부하 테스트 (Load Testing), 카오스 엔지니어링 (Chaos Engineering)에 이르기까지 제가 의존하는 모든 워크플로 (Workflow)를 다루고 있습니다.

FAQ

용량 예측 (Capacity Projection)은 얼마나 앞을 내다봐야 합니까?

예산 승인, 마이그레이션 (Migration), 또는 하드웨어 주문 등 가장 느린 확장 옵션이 요구하는 실제 리드 타임 (Lead Time)을 확보할 수 있을 만큼 충분해야 합니다. 대부분의 팀에게 이는 한 번 계산하고 무기한 신뢰하는 것이 아니라, 정기적으로 업데이트되는 2~3개월의 예측 기간을 의미합니다.

실제 성장세가 예측 곡선과 일치하지 않으면 어떻게 됩니까?

그것이 바로 이 워크플로가 단일 예측치를 생성하는 대신 정해진 일정에 따라 다시 실행되는 정확한 이유입니다. 형태가 변하는 성장 곡선은 다음 실행 시 예측 날짜의 변화로 나타나며, 이는 워크플로가 실패했다는 신호가 아니라 상류 (Upstream) 단계에서 무엇이 변했는지 살펴보라는 신호입니다.

이것이 아키텍처 변경과 스케일 업 (Scaling Up) 사이의 판단을 대체합니까?

아니요. 이것은 그러한 판단을 가능하게 하는 수치를 제공합니다. 특정 임계치 (Ceiling)에서 적절한 조치가 더 큰 티어 (Tier)로의 확장인지 아니면 재설계 (Redesign)인지 여부는 여전히 팀이 내리는 결정이지만, 직감이나 주황색 대시보드에 의존하는 것보다 날짜가 명시된 예측치와 비용 비교를 앞에 두고 내리는 결정이 훨씬 더 나은 결정입니다.

이것은 대규모 인프라 팀에만 유용합니까?

아니요. 소규모 팀은 사후 대응적인 혼란을 흡수할 여유(Slack)가 적기 때문에 어떤 면에서는 이 방식으로부터 더 많은 이득을 얻습니다. 데이터베이스 티어의 업그레이드가 필요하다는 것을 두 달 전에 미리 아는 것은 규모와 상관없이 가치 있는 일이며, 비용 예측은 예산이 빠듯할 때 가장 중요합니다.

부족함에 반응하는 것에서 미리 예측하는 것으로의 전환은 제가 인프라를 운영하는 방식에 있어, 겉으로 드러나지는 않지만 가장 영향력이 큰 변화 중 하나였습니다. 그 대가는 제가 없어도 정해진 일정에 따라 작동하는 네 가지 기술(skills)을 구축하는 것이었습니다. 그 보상은 자원이 실제로 고갈된 주에 내리는 값비싼 결정 대신, 마감일 두 달 전에 내리는 차분한 결정이었습니다.