infrastructure2026년 2월 15일11분 소요

클라우드 비용 최적화: MVP에 과도하게 지불하는 것을 멈추세요

대부분의 스타트업은 클라우드 예산의 40-60%를 낭비합니다. 여기 신뢰성을 희생하지 않고 인프라를 적절하게 조정하는 실용적인 가이드가 있습니다.

cloudawscost-optimization

지난 분기에 한 스타트업의 AWS 청구서를 감사했는데, 그들은 월 900달러로 충분히 운영할 수 있는 인프라에 월 2,800달러를 지출하고 있었습니다. Node.js API를 실행하는 t3.2xlarge 인스턴스는 CPU 사용률이 12%에 불과했습니다. 사용되지 않는 Elastic IP 3개가 각각 월 3.65달러씩 유휴 상태로 있었습니다. 200개 행의 데이터베이스를 위한 RDS Multi-AZ 배포가 있었고, 무료로 VPC 엔드포인트를 통해 갈 수 있었던 트래픽을 라우팅하는 NAT Gateway도 있었습니다. 이 모든 것이 악의적이거나 특별히 부주의한 것은 아니었습니다. 그저 제품을 출시하기 위한 스프린트 중에 "일단 작동하는 것을 프로비저닝하자"는 결정들이 쌓인 결과였습니다.

이것은 예외가 아니라 일반적인 현상입니다. 대부분의 초기 스타트업은 클라우드 지출의 40-60%를 낭비합니다. 팀 내에 기능을 출시해야 할 때 비용을 최적화할 시간이나 인센티브가 있는 사람이 없기 때문입니다. 문제는 더욱 심화됩니다. 일단 인프라가 프로비저닝되고 작동하면 아무도 건드리지 않습니다.

계속해서 발견되는 가장 큰 비용 함정

해결책을 찾기 전에 돈이 실제로 어디로 가는지 이해하는 것이 도움이 됩니다. 다음은 스타트업 인프라를 검토할 때 가장 자주 접하는 함정들입니다.

과도하게 프로비저닝된 컴퓨팅 인스턴스

이것이 가장 큰 낭비의 원인입니다. 팀은 초기 설정 시 인스턴스 크기를 선택합니다. 보통 블로그 게시물이나 "안전을 위해"라는 생각에 기반하며, 다시 검토하지 않습니다. 저는 매시간 30초 동안 실행되는 cron 작업을 위해 m5.xlarge 인스턴스가 사용되는 것을 보았습니다. 인스턴스는 59.5분 동안 유휴 상태로 있으면서 본질적으로 아무것도 하지 않고 시간당 0.192달러(월 140달러)를 소모합니다.

근본적인 원인은 심리적인 것입니다. 아무도 서버를 과소 프로비저닝하여 장애를 일으킨 사람이 되고 싶어 하지 않습니다. 그래서 모두가 두 번씩이나 넉넉하게 잡습니다.

# 지난 2주간 EC2 인스턴스의 CPU 사용률 확인
aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 \
  --metric-name CPUUtilization \
  --dimensions Name=InstanceId,Value=i-0abcdef1234567890 \
  --start-time $(date -u -d '14 days ago' +%Y-%m-%dT%H:%M:%S) \
  --end-time $(date -u +%Y-%m-%dT%H:%M:%S) \
  --period 3600 \
  --statistics Average Maximum

평균 CPU 사용률이 20% 미만이고 피크가 50% 미만이라면 거의 확실히 과도하게 프로비저닝된 것입니다. 인스턴스 크기를 한두 단계 낮추고 일주일 동안 모니터링한 다음 조정하세요.

잊혀진 EBS 볼륨 및 스냅샷

EC2 인스턴스를 종료할 때, 시작 시 구성하지 않았다면 연결된 EBS 볼륨은 자동으로 삭제되지 않습니다. 이는 종료된 인스턴스가 고아 볼륨을 남겨두고 계속 요금이 청구된다는 의미입니다. 저는 수십 개의 연결되지 않은 gp3 볼륨이 있는 계정을 보았는데, 각 볼륨은 GB당 월 0.08달러가 청구되어 아무도 사용하지 않는 스토리지에 수백 달러가 지출되고 있었습니다.

스냅샷은 훨씬 더 교묘합니다. 자동 백업 스크립트는 수명 주기 정책 없이 매일 스냅샷을 생성하므로 무한정 축적됩니다. 500GB 볼륨이 1년 동안 매일 스냅샷되면 365개의 스냅샷이 생성되며, EBS 스냅샷은 증분 방식이지만 비용은 상당한 금액으로 합산됩니다.

# 연결되지 않은 모든 EBS 볼륨 찾기
aws ec2 describe-volumes \
  --filters Name=status,Values=available \
  --query 'Volumes[*].{ID:VolumeId,Size:Size,Created:CreateTime}' \
  --output table

# 90일보다 오래된 스냅샷 찾기
aws ec2 describe-snapshots \
  --owner-ids self \
  --query 'Snapshots[?StartTime<=`2025-12-01`].{ID:SnapshotId,Size:VolumeSize,Date:StartTime}' \
  --output table

NAT Gateway: 조용한 예산 살인자

NAT Gateway는 존재 자체만으로 시간당 0.045달러(월 32.40달러)가 청구되며, 처리되는 데이터 1GB당 0.045달러가 추가됩니다. 프라이빗 서브넷에서 외부 서비스로 자주 API 호출을 하는 스타트업의 경우, 데이터 처리 요금만으로 월 100달러를 초과할 수 있습니다. 저는 소규모 스타트업의 총 AWS 청구서에서 NAT Gateway 요금이 15-20%를 차지하는 것을 보았습니다.

해결책은 NAT를 통해 흐르는 트래픽의 종류에 따라 다릅니다.

AWS 서비스(S3, DynamoDB, SQS)로의 트래픽: VPC Gateway Endpoints(S3 및 DynamoDB는 무료) 또는 Interface Endpoints(각각 월 7.20달러이지만, 고용량 트래픽의 경우 NAT보다 여전히 저렴)를 사용하세요.
Lambda 함수에서 인터넷으로의 트래픽: 해당 함수가 실제로 VPC 내에 있어야 하는지 고려하세요. 많은 Lambda 함수는 VPC 리소스에 액세스하지 않음에도 불구하고 "보안을 위해" VPC에 배치됩니다.
저용량 아웃바운드 트래픽: t4g.nano(월 3.02달러)의 NAT 인스턴스는 NAT Gateway 비용의 일부로 적당한 트래픽을 처리합니다.

데이터 전송 요금

AWS는 리전을 벗어나는 데이터에 대해 GB당 0.09달러를 청구하며, AZ 간 트래픽은 각 방향으로 GB당 0.01달러가 청구됩니다. 이러한 요금은 눈에 띄지 않다가 어느 순간 엄청나게 불어납니다. 세 개의 가용 영역에 분산된 수다스러운 마이크로서비스 아키텍처는 초당 수백 번 서로를 호출하여 놀라운 데이터 전송 요금을 발생시킬 수 있습니다.

아키텍처 수정: 중요하지 않은 워크로드의 경우 자주 통신하는 서비스를 동일한 AZ에 배치하거나, AZ 선호도를 가진 내부 로드 밸런서를 사용하세요.

적정 규모 조정: 체계적인 접근 방식

적정 규모 조정은 일회성 작업이 아닙니다. 분기별로 다시 검토해야 합니다. 다음은 제가 따르는 과정입니다.

1단계: 활용 데이터 수집

AWS Compute Optimizer는 무료이며 EC2, EBS, Lambda, ECS에 대한 적정 규모 조정 권장 사항을 제공합니다. 이를 활성화하고 권장 사항에 따라 조치하기 전에 최소 14일간의 데이터를 수집하도록 하세요.

더 세분화된 분석을 위해서는 CloudWatch 지표가 주요 데이터 소스입니다. 주시해야 할 주요 지표는 다음과 같습니다.

EC2: CPUUtilization, NetworkIn/Out, MemoryUtilization (CloudWatch 에이전트 필요)
RDS: CPUUtilization, DatabaseConnections, FreeableMemory, ReadIOPS, WriteIOPS
ElastiCache: CPUUtilization, CurrConnections, BytesUsedForCache

2단계: 워크로드 분류

모든 워크로드를 동일한 방식으로 적정 규모로 조정해서는 안 됩니다. 저는 워크로드를 세 가지 범주로 나눕니다.

정상 상태 워크로드 (API 서버, 데이터베이스): 일관된 용량이 필요합니다. 피크 로드를 30%의 여유 공간으로 처리하는 가장 작은 인스턴스를 찾아 적정 규모로 조정하세요. 기본 워크로드에는 Reserved Instances 또는 Savings Plans를 사용하세요.

가변 워크로드 (배치 처리, 빌드 서버): 적절한 스케일링 정책을 가진 Auto Scaling Groups를 사용하거나, 내결함성 배치 작업에는 Spot Instances를 사용해야 합니다.

주기적 워크로드 (cron 작업, 예약 보고서): 이러한 워크로드는 전용 인스턴스에서 전혀 실행되어서는 안 됩니다. Lambda, Fargate Spot 또는 Step Functions로 옮기세요.

3단계: 점진적으로 조치

모든 것을 한 번에 적정 규모로 조정하지 마세요. 한 번에 인스턴스 크기를 한 단계 낮추고 일주일 동안 모니터링한 다음 더 진행할지 결정하세요. 짧은 과도한 프로비저닝 기간의 비용은 공격적인 규모 축소로 인한 프로덕션 중단 비용보다 훨씬 적습니다.

Reserved Instances vs Savings Plans vs Spot

여기서 실제 절약이 발생합니다. 온디맨드 가격에서 30-72% 할인되지만, 약정 메커니즘이 너무 혼란스러워서 많은 스타트업이 아예 피합니다.

Reserved Instances (RIs)

1년 또는 3년 동안 특정 리전의 특정 인스턴스 유형에 약정합니다. 그 대가로 30-40%(선불 없음, 1년)에서 60%(전액 선불, 3년) 할인을 받습니다. 단점은 인스턴스 유형을 변경해야 할 경우 Standard RI는 유연하지 않다는 것입니다. Convertible RI는 약간 낮은 할인율(3년 전액 선불의 경우 약 45%)로 더 많은 유연성을 제공합니다.

RI를 사용해야 할 때: 데이터베이스 및 인스턴스 유형과 크기가 실제로 안정적인 기타 워크로드. RDS Reserved Instances는 거의 항상 가치가 있습니다. 데이터베이스는 크기가 거의 변하지 않습니다.

Savings Plans

Savings Plans는 컴퓨팅용 RI의 현대적인 대안입니다. 1년 또는 3년 동안 시간당 컴퓨팅 비용(예: 시간당 0.10달러)을 약정합니다. 이 약정은 EC2, Fargate, Lambda 사용량에 자동으로 적용되며, 인스턴스 패밀리, 크기, OS, 리전 전반에 걸쳐 유연합니다.

Savings Plans를 사용해야 할 때: 컴퓨팅 워크로드의 경우 EC2 RI보다 거의 항상 선호됩니다. Compute Savings Plans는 최고의 유연성-할인율을 제공합니다. 최소 기준 지출을 커버하는 약정으로 시작하세요.

# 예시: Savings Plan 약정 계산
# 현재 온디맨드 지출: EC2에 월 500달러
# 최소 기준 (절대 떨어지지 않는 금액): 월 350달러
# 권장 Savings Plan 약정: 월 350달러 = 약 시간당 0.48달러
# 예상 절감액: 약정 금액의 약 30% = 약 월 105달러
# 나머지 월 150달러는 유연성을 위해 온디맨드로 유지

Spot Instances

Spot Instances는 60-90% 할인을 제공하지만 2분 전에 통보하고 중단될 수 있습니다. 다음 용도에 이상적입니다.

CI/CD 빌드 에이전트 (여러 인스턴스 유형을 가진 Spot Fleet 사용)
체크포인트를 설정하고 재개할 수 있는 배치 처리 작업
개발 및 스테이징 환경
부하 테스트

프로덕션 API 서버, 데이터베이스 또는 갑작스러운 종료를 처리할 수 없는 모든 것에는 적합하지 않습니다.

# 예시: Spot의 GitHub Actions 자체 호스팅 러너
# 컴퓨팅 집약적인 빌드의 경우 GitHub 호스팅 러너에 비해 약 70% 절약
Resources:
  SpotFleet:
    Type: AWS::EC2::SpotFleet
    Properties:
      SpotFleetRequestConfigData:
        IamFleetRole: !GetAtt SpotFleetRole.Arn
        TargetCapacity: 2
        AllocationStrategy: lowestPrice
        LaunchSpecifications:
          - InstanceType: c5.xlarge
            SpotPrice: "0.06"
          - InstanceType: c5a.xlarge
            SpotPrice: "0.06"
          - InstanceType: c6i.xlarge
            SpotPrice: "0.06"

서버리스 비용 모델: 항상 저렴하지는 않다

서버리스가 스타트업에게 항상 더 저렴하다는 지속적인 신화가 있습니다. 낮은 규모에서는 종종 더 저렴하지만, 트래픽이 증가함에 따라 경제성이 달라집니다.

Lambda 가격 현실

Lambda는 요청당(백만 건당 0.20달러) 및 GB-초 컴퓨팅당(0.0000166667달러) 요금을 청구합니다. 200ms 동안 256MB 메모리로 실행되는 일반적인 API 엔드포인트의 경우:

하루 1,000 요청: 월 약 0.03달러. 사실상 무료.
하루 100,000 요청: 월 약 3.00달러. 여전히 매우 저렴.
하루 1,000,000 요청: 월 약 30달러. 작은 EC2 인스턴스와 비교되기 시작.
하루 10,000,000 요청: 월 약 300달러. 적절한 캐싱을 갖춘 t3.medium(월 30달러)이 이를 쉽게 처리.

교차점은 실행 시간과 메모리 할당에 크게 의존하지만, 대부분의 API 워크로드의 경우 Lambda는 하루 100만~500만 요청 사이에서 비용 효율성이 떨어지기 시작합니다. 그 임계값 미만에서는 거의 항상 가장 저렴한 옵션입니다.

API Gateway 비용 증가

사람들은 API Gateway 뒤의 Lambda 함수가 추가 요금을 발생시킨다는 사실을 잊습니다. API Gateway는 백만 요청당 3.50달러(REST API) 또는 백만 요청당 1.00달러(HTTP API)가 청구됩니다. 규모가 커지면 API Gateway 비용이 Lambda 비용을 초과합니다. Lambda 비용에 대해 걱정할 만큼 충분한 트래픽을 실행하고 있다면 API Gateway 대신 Application Load Balancer(LCU-시간당 0.008달러)를 사용해야 합니다.

Fargate: 중간 지점

AWS Fargate는 비용과 운영 복잡성 면에서 Lambda와 EC2 사이에 있습니다. 인스턴스 관리 없이 vCPU와 메모리 사용량에 따라 초 단위로 요금을 지불합니다. 지속적으로 실행되어야 하지만 서버를 관리하고 싶지 않은 워크로드의 경우, Spot 용량 공급자를 사용하는 Fargate는 좋은 균형을 제공합니다.

0.25 vCPU 및 0.5GB 메모리를 가진 Fargate 태스크는 지속적으로 실행될 때 월 약 9달러가 청구됩니다. 이는 t4g.nano와 경쟁할 만하며, 기본 호스트를 관리할 필요 없이 자동 배치, 상태 확인 및 스케일링을 얻을 수 있습니다.

비용 모니터링 및 알림

측정하지 않으면 최적화할 수 없습니다. 다음은 제가 모든 프로젝트에 설정하는 모니터링 스택입니다.

AWS Cost Explorer

Cost Explorer를 활성화하고 50%, 80%, 100% 임계값에서 알림이 있는 월별 예산을 설정하세요. 이것이 최소한의 조치입니다. Cost Explorer의 "서비스별 비용" 보기는 돈이 어디로 가는지 즉시 보여줍니다.

# 이메일 알림과 함께 예산 생성
aws budgets create-budget \
  --account-id 123456789012 \
  --budget '{
    "BudgetName": "Monthly-Total",
    "BudgetLimit": {"Amount": "500", "Unit": "USD"},
    "TimeUnit": "MONTHLY",
    "BudgetType": "COST"
  }' \
  --notifications-with-subscribers '[{
    "Notification": {
      "NotificationType": "ACTUAL",
      "ComparisonOperator": "GREATER_THAN",
      "Threshold": 80,
      "ThresholdType": "PERCENTAGE"
    },
    "Subscribers": [{
      "SubscriptionType": "EMAIL",
      "Address": "team@startup.com"
    }]
  }]'

Infrastructure as Code를 위한 Infracost

Terraform을 사용하는 경우, Infracost는 CI 파이프라인에 통합되어 모든 인프라 변경 사항이 적용되기 전에 비용 추정치를 보여줍니다. 이는 혁신적입니다. 비용 인식을 월별 놀라움에서 풀 리퀘스트 대화로 전환합니다.

# .github/workflows/infracost.yml
name: Infracost
on: pull_request
jobs:
  infracost:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Setup Infracost
        uses: infracost/actions/setup@v3
        with:
          api-key: ${{ secrets.INFRACOST_API_KEY }}
      - name: Generate cost estimate
        run: |
          infracost breakdown --path=. \
            --format=json --out-file=/tmp/infracost.json
          infracost comment github \
            --path=/tmp/infracost.json \
            --repo=$GITHUB_REPOSITORY \
            --pull-request=${{ github.event.pull_request.number }} \
            --github-token=${{ secrets.GITHUB_TOKEN }}

비용 이상 감지

AWS Cost Anomaly Detection은 머신러닝을 사용하여 비정상적인 지출 패턴을 식별합니다. 무료이며 지출이 과거 패턴에서 벗어날 때 알림을 보냅니다. 각 서비스에 대해 활성화하고 SNS 알림을 Slack으로 설정하세요.

비용을 절약하는 아키텍처 패턴

개별 리소스의 적정 규모 조정을 넘어, 특정 아키텍처 결정은 비용 구조를 근본적으로 변화시킵니다.

적극적인 캐싱

캐시 가능한 응답을 위해 API 앞에 CloudFront 배포를 두면 HTTPS 요청 10,000건당 0.085달러, GB 전송당 0.085달러가 청구되지만, 백엔드에 대한 요청을 제거합니다. 읽기 집약적인 API(대부분 그렇습니다)의 경우 90%의 캐시 적중률은 백엔드가 10배 적은 트래픽을 처리한다는 것을 의미합니다.

더 간단하게는 Redis와 같은 인메모리 캐시 또는 애플리케이션 내의 로컬 LRU 캐시만으로도 중복 데이터베이스 쿼리를 제거할 수 있습니다. 저는 가장 자주 액세스하는 5개 엔드포인트에 15분 캐시를 추가한 후 데이터베이스 비용이 60% 감소하는 것을 보았습니다.

S3를 지능적으로 사용

S3에는 여러 스토리지 클래스가 있으며, 올바른 것을 사용하는 것이 중요합니다.

스토리지 클래스	GB당 월 비용	사용 사례
S3 Standard	$0.023	활성 데이터, 빈번한 액세스
S3 Infrequent Access	$0.0125	백업, 30일보다 오래된 로그
S3 Glacier Instant	$0.004	즉시 액세스해야 하는 아카이브
S3 Glacier Deep Archive	$0.00099	장기 아카이브, 드문 액세스

S3 수명 주기 정책을 설정하여 객체를 스토리지 클래스 간에 자동으로 전환하세요.

{
  "Rules": [
    {
      "ID": "TransitionToIA",
      "Status": "Enabled",
      "Transitions": [
        {
          "Days": 30,
          "StorageClass": "STANDARD_IA"
        },
        {
          "Days": 90,
          "StorageClass": "GLACIER_INSTANT_RETRIEVAL"
        }
      ]
    }
  ]
}

관리형 서비스 vs 자체 호스팅

이러한 장단점은 미묘합니다. 관리형 서비스(RDS, ElastiCache, OpenSearch Service)는 EC2에서 자체 호스팅하는 것보다 컴퓨팅 단위당 비용이 더 많이 들지만, 패치, 백업, 페일오버 및 모니터링이 포함됩니다. 전담 운영 인력이 없는 스타트업의 경우, 절약되는 엔지니어링 시간은 거의 항상 프리미엄을 정당화합니다.

예외: 최고 티어의 관리형 서비스. db.r6g.2xlarge RDS 인스턴스는 PostgreSQL을 실행하는 동등한 EC2 인스턴스보다 훨씬 비쌉니다. 운영 능력이 있는 팀이 있고 단일 관리형 서비스에 월 1,000달러 이상을 지출하고 있다면 자체 호스팅을 평가할 가치가 있습니다.

가능한 경우 통합

스테이징, QA 및 개발 환경을 위해 별도의 RDS 인스턴스를 실행하는 것은 비용이 많이 듭니다. 옵션:

비프로덕션 환경에 대해 별도의 데이터베이스를 가진 단일 RDS 인스턴스를 사용합니다.
개발/스테이징에 Aurora Serverless v2를 사용합니다. 유휴 상태일 때 0으로 스케일링됩니다.
Docker를 사용하여 단일 EC2 Spot Instance에서 개발 데이터베이스를 실행합니다.

실제 비용 최적화 플레이북

다음은 제가 비용 최적화 프로젝트를 수행할 때 따르는 단계별 프로세스입니다. 이는 일반적으로 첫 달 내에 30-50%의 절감 효과를 달성합니다.

1주차: 감사

아직 활성화되지 않았다면 AWS Cost Explorer를 활성화합니다.
서비스별 3개월 비용 분석을 가져옵니다.
지출 상위 5개 서비스를 식별합니다.
AWS Compute Optimizer 및 Trusted Advisor를 실행합니다.
연결되지 않은 모든 EBS 볼륨, 사용되지 않는 Elastic IP, 유휴 로드 밸런서를 나열합니다.

2주차: 빠른 성과

감사에서 식별된 사용되지 않는 리소스를 삭제합니다.
가장 과도하게 프로비저닝된 인스턴스의 크기를 조정합니다(1단계 낮추고 모니터링).
S3 및 DynamoDB 트래픽에 대한 VPC 엔드포인트를 설정합니다.
모든 버킷에 S3 수명 주기 정책을 활성화합니다.
예산 알림을 설정합니다.

3주차: 약정

Savings Plan 적격성을 위해 정상 상태 워크로드를 분석합니다.
기본 컴퓨팅 지출에 대한 Compute Savings Plans를 구매합니다.
프로덕션 데이터베이스에 대한 RDS Reserved Instances를 구매합니다.
적합한 워크로드를 Spot Instances로 전환합니다.

4주차: 아키텍처

적절한 곳에 캐싱 계층을 추가합니다.
적합한 워크로드에 대한 서버리스 마이그레이션을 평가합니다.
비프로덕션 환경을 통합합니다.
CI 파이프라인에 Infracost를 설정합니다.
지속적인 모니터링을 위한 비용 기준선을 문서화합니다.

최적화하지 말아야 할 것

비용 최적화는 한계 효용 체감의 법칙이 적용되며, 일부 "절약"은 해결하는 문제보다 더 많은 문제를 야기합니다.

비용을 위해 신뢰성을 희생하지 마세요. Multi-AZ 요금을 절약하기 위해 단일 AZ 배포에서 프로덕션 데이터베이스를 실행하는 것은 잘못된 경제입니다. 첫 번째 장애는 Multi-AZ 프리미엄 몇 년치보다 더 많은 비용이 들 것입니다.

현재 규모에 대해 과도하게 최적화하지 마세요. 스타트업이 월 20%씩 성장하고 있다면, 월 50달러짜리 서비스를 최적화하는 데 일주일을 보내는 것은 시간 낭비입니다. 큰 비용 항목에 집중하세요.

클라우드 공급자의 가격 모델과 싸우지 마세요. AWS는 그들의 관습과 싸우면 비싸게 설계되어 있습니다. 관리형 서비스를 의도된 방식으로 사용하고, 무료 티어를 활용하며, 그들이 제공하는 약정 할인을 활용하세요. 지나치게 영리한 아키텍처로 가격 책정을 우회하려고 시도하는 것은 보통 역효과를 냅니다.

돈을 절약하기 위해 모니터링을 제거하지 마세요. CloudWatch는 돈이 들지만, 눈을 감고 비행하는 것은 더 많은 비용이 듭니다. 상세 모니터링에 지출하는 월 15달러는 상세 모니터링이 잡아냈을 500달러의 놀라움으로부터 당신을 구할 것입니다.

복리 효과

초기 비용 최적화의 가장 큰 장점은 즉각적인 절약이 아니라, 당신이 구축하는 습관과 인프라입니다. 예산 알림을 설정하고, CI에서 Infracost를 사용하며, 매월 비용을 검토하는 스타트업은 규모가 커짐에 따라 효율적인 인프라를 유지할 것입니다. 시리즈 B까지 비용을 무시하는 스타트업은 월 30,000달러의 AWS 청구서를 받게 될 것이며, 이를 해결하는 데 6개월의 전담 노력이 필요할 것입니다.

감사부터 시작하세요. 숫자가 어디에 집중해야 할지 알려줄 것입니다.