Foundations - 05. build vs buy, on-pre vs cloud

클라우드에서 자체 인프라로 돌아간 회사들 — build vs buy의 진짜 조건

2016년, Dropbox는 AWS S3에 올려뒀던 사용자 데이터 대부분을 자체 인프라로 옮겼다. "Magic Pocket"이라는 이름의 자체 분산 스토리지 시스템이 그 주인공이다. 이 결정은 이례적이었다 — 2008년 AWS 위에서 시작한 스타트업이, 8년 뒤 하이퍼스케일 클라우드를 버리고 자체 인프라로 간 것이다. Dropbox는 이후 공식 발표에서 연간 약 7,500만 달러를 절감했다고 밝혔다. 클라우드에서 벗어나 돈을 든 게 아니라 덜 쓰게 된 것이다. 단, 그 전에 수년간의 엔지니어링 투자와 수십 명의 인프라 엔지니어 고용이 선행했다.

이 사건이 보여주는 것은 "클라우드가 항상 싸다"는 통념이 틀렸다는 점이다. 그렇다고 "자체 인프라가 항상 싸다"도 아니다. Dropbox는 특별한 조건 — 저장소가 핵심 역량이고, 규모가 충분히 컸고(수억 사용자), 트래픽 패턴이 예측 가능했기 때문에 자체 인프라가 이득이었다. 같은 시기에 Netflix는 AWS에 남았다 — 영상 스트리밍의 트래픽이 너무 불규칙하고, AWS의 글로벌 인프라를 활용하는 게 비즈니스에 더 맞았기 때문이다. 두 회사 모두 합리적이었다. 차이는 맥락에 있었다.

이 글은 인프라 의사결정의 가장 근본적 분기 — build vs buy, on-pre vs cloud를 다룬다. foundations 첫 글에서 "되돌리기 비싼 결정"의 대표 사례로 이 주제를 잠깐 언급했고, 04 글에서 redundancy와 DR이 "직접 구축"의 가장 큰 부담이라는 걸 봤다. 여기서는 그 부담을 숫자로 계산하고, 어떤 조건에서 클라우드가 이기고 어떤 조건에서 자체가 이기는지, 그리고 "벤더 종속"이 실제로 무슨 비용을 갖는지를 파헤친다.

build vs buy — make-or-buy의 인프라 버전

build vs buy는 경영학의 고전적 질문이다. "필요한 걸 직접 만들까, 사올까." 소프트웨어 세계에서는 "라이브러리를 쓸까, 직접 짤까"로, 인프라 세계에서는 "관리형 서비스를 쓸까, 자체 인프라에 올릴까"로 번역된다.

Buy 쪽이 클라우드 관리형 서비스(Managed Service)다. AWS RDS, GCP Cloud SQL, Azure SQL Database 같은 데이터베이스 서비스. AWS S3, GCP Cloud Storage 같은 객체 스토리지. AWS EKS, GCP GKE 같은 관리형 Kubernetes. 핵심은 — 벤더가 운영을 책임진다는 것이다. 백업, 복제, 장애 복구, 보안 패치, 용량 증설을 벤더가 알아서 한다. 사용자는 API를 호출해 자원을 요청하고 사용한 만큼 낸다.

Build 쪽이 자체 인프라다. 베어메탈 서버를 사서 랙에 꽂거나(Iron Hive·OpenStack), 클라우드의 IaaS(EC2·GCE) 위에 자체 데이터베이스·객체 스토리지를 올리는 것. 핵심은 — 운영을 사용자가 책임진다는 것이다. 04에서 본 Aurora의 6-way 쿼럼을 직접 PostgreSQL로 짜려면, 백업 자동화, 복제 설정, failover 로직, 디스크 교체 주기까지 모두 손수 구현해야 한다.

flowchart LR
    NEED["인프라 필요"] --> Q{"핵심 역량인가?"}
    Q -->|Yes| BUILD["Build<br/>(자체 구축)"]
    Q -->|No| Q2{"규모가 충분한가?"}
    Q2 -->|Yes| MIX["Hybrid<br/>(핵심만 build, 나머지 buy)"]
    Q2 -->|No| BUY["Buy<br/>(관리형 서비스)"]

이 결정은 한 번 내리면 되돌리기 비싸다. foundations 01에서 본 "되돌림 비용 매트릭스"를 떠올려보자 — "온프레미스 → 클라우드 마이그레이션"은 매우 높음, "데이터센터 물리 이전"은 사실상 불가능. build로 가면 하드웨어를 사고 랙을 세팅하고 팀을 고용해야 하고, buy로 가면 코드와 절차를 클라우드 API에 맞춰야 한다. 양쪽 모두 몇 년 단위의 헌신이 필요하다.

TCO — 총소유비용 계산

"싸다/비싸다"를 논하려면 TCO(Total Cost of Ownership, 총소유비용)를 계산해야 한다. 클라우드 월 청구서만 보고 판단하면 빠진다. 진짜 비용은 몇 가지 항목으로 쪼개진다.

자체 인프라(build)의 TCO 항목:

항목	예시	비고
하드웨어 구매	서버, 스위치, 케이블, 랙	3 ~ 5년 감가상각
데이터센터 비용	랙당 월 비용, 전력(kW당), 냉각	PUE 1.2 ~ 1.5
네트워크	상용 회선, IP 대역	정액제 또는 트래픽당
인건비	인프라 엔지니어, SRE, NOC	가장 큰 항목 (미국 기준 연봉 15 ~ 30만 달러)
소프트웨어 라이선스	OS, 하이퍼바이저, 모니터링 도구	상용 vs 오픈소스
유지보수	하드웨어 교체, 펌웨어 업데이트	보통 하드웨어 가격의 연 10 ~ 15%
여유 용량	피크 대비 여분 서버	클라우드처럼 "딱 맞게" 못 씀

클라우드(buy)의 TCO 항목:

항목	예시	비고
컴퓨트	EC2/GCE 인스턴스 시간당	24/7 실행 시 온프레보다 비싸질 수 있음
저장소	GB당 월 비용	용량에 비례
네트워크 송신(egress)	GB당 비용	가장 큰 숨겨진 비용
API 요청	PUT/GET/리스트 등	작은 객체 많을수록 폭발
관리형 서비스 프리미엄	RDS, EKS 등	동일 IaaS 대비 30 ~ 100% 비쌈
데이터 전송(리전 간)	cross-AZ, cross-region	보통 GB당 $0.01 ~ 0.02
지원	Business/Enterprise support	월 최소 $100 ~ $15,000+
인건비	클라우드 엔지니어	온프레 인건비와 비슷하거나 약간 더 셈

두 표를 비교하면 차이가 명확해진다. 자체 인프라는 초기 자본이 크지만(c apex) 운영 비용이 비교적 안정적이다. 클라우드는 초기 자본은 거의 없지만(opex) 사용량에 따라 비용이 무한히 커질 수 있다. 02에서 본 capex vs opex의 차이가 여기서 결정적인 역할을 한다.

가장 많이 놓치는 클라우드 비용이 egress(데이터 송신) 이다. AWS에서 S3 객체를 인터넷으로 내보낼 때 GB당 약 $0.09. 매월 100TB를 내보내는 서비스라면 egress 비용만 월 $9,000, 연 $108,000. 이 단일 항목만으로 자체 인프라가 싸질 수 있다. CDN을 앞에 두거나(egress 비용 절반), 클라우드 벤더와 엔터프라이즈 계약을 맺거나(할인), 아예 자체 인프라로 가는 게 답일 수 있다. Dropbox가 자체 인프라로 간 핵심 이유 중 하나가 이 egress 비용이었다 — 사용자가 파일을 다운로드할 때마다 AWS가 돈을 받는 구조였기 때문.

역사 박스 — 클라우드 비용 모델은 2006년 AWS EC2 출시와 함께 정립됐다. "쓴 만큼 내는" 모델은 당시 혁신적이었다 — 서버 한 대 사는 데 수천 달러를 들이는 대신, 시간당 $0.10 내면 됐다. 하지만 20년이 흐른 뒤, 많은 회사가 "클라우드가 생각보다 비싸다"는 걸 깨닫고 있다. 2022년 37signals의 발표, 2023년 DoorDash·Pinterest 등의 비용 최적화 발표가 그 신호다. 비용이 발표된다는 건 이미 클라우드 단가가 눈에 띌 만큼 커졌다는 뜻이다.

벤더 종속 — 무엇을 잃는가

build vs buy의 또 다른 축이 벤더 종속(vendor lock-in) 이다. 클라우드 벤더의 서비스를 깊이 쓸수록, 다른 벤더로 옮기거나 자체 인프라로 돌아가는 비용이 커진다. lock-in의 네 가지 형태를 보자.

1. API 종속 — 코드가 클라우드 API에 맞춰지면, 다른 클라우드로 옮길 때 코드를 다시 짜야 한다. AWS DynamoDB에 맞춘 데이터 접근 코드를 GCP Datastore로 옮기려면, 쿼리 패턴부터 인덱스 구조까지 다르기 때문에 거의 재작성에 가깝다. AWS S3 API는 사실상 업계 표준이 돼서(GCS·MinIO·Ceph가 S3 호환 API를 제공) 이 축은 상대적으로 약하지만, 데이터베이스·메시지 큐·인증 서비스는 여전히 강한 종속을 만든다.

2. 데이터 이동 비용 — 데이터가 클라우드에 쌓일수록, 그걸 빼내는 데 비용이 든다. 앞서 본 egress 비용이 핵심이다. 100TB 데이터를 AWS에서 자체 인프라로 옮기려면, 단순히 egress 비용(약 $9,000)만이 아니라 전송 시간(10Gbps 회선으로 약 22시간), 검증 절차, 일시적 이중 운영 비용까지 합쳐진다. "데이터 중력(data gravity)"이라 부르는 현상이다 — 데이터가 크면 그 데이터를 중심으로 다른 서비스들이 모이고, 이사 비용이 기하급수적으로 커진다.

3. 도구 생태계 종속 — AWS CloudFormation, GCP Deployment Manager, Azure Resource Manager 같은 IaC 도구는 해당 클라우드에 종속된다. Terraform은 멀티 클라우드를 지원하지만 provider에 따라 코드가 달라진다. 모니터링(CloudWatch·Stackdriver), 로깅, CI/CD 도구까지 같은 클라우드를 쓰면 — 전부 같이 옮겨야 한다.

4. 인력 학습 곡선 — 팀이 한 클라우드에 깊이 익숙해지면, 다른 클라우드나 자체 인프라로 옮길 때 팀을 다시 교육해야 한다. 인프라 엔지니어 한 명이 AWS에 5년 익숙해진 상태에서 GCP로 옮기는 건 — 도구는 비슷해도 상세 동작·모범 사례가 달라 적응에 수개월이 걸린다.

이런 lock-in이 항상 나쁜 건 아니다. 전략적 lock-in이라는 개념이 있다 — 한 벤더와 깊이 협력하면 할인·기술 지원·신기능 조기 접근 같은 혜택을 받는다. Snapchat이 2016년 Google Cloud와 맺은 5년 20억 달러 계약은 전략적 lock-in의 사례다. Netflix의 AWS 전면 의존도 마찬가지. lock-in 자체를 피하려다 보면 멀티 클라우드라는 또 다른 복잡도를 떠안게 되니 — 어느 시점에 종속을 받아들일지가 전략적 질문이다.

종속 형태	위험도	완화 전략
API 종속	높음	추상화 레이어(Terraform, libcloud), 벤더 중립 API(IaC)
데이터 이동	매우 높음	데이터 중복 동기화, CDN 분산, 백업 외부 보관
도구 생태계	중간	오픈소스 도구 우선(Terraform, Prometheus, Grafana)
인력 학습	중간	Kubernetes 같은 표준 레이어 사용, 다중 벤더 경험 장려

규제와 데이터 주권 — 기술을 넘어선 제약

때로는 기술·비용과 무관한 이유로 build를 선택해야 한다. 규제·데이터 주권이다.

GDPR(유럽 연합 일반 개인정보보호법, 2018년 시행)은 EU 시민의 개인정보를 EU 외부로 반출하는 것을 제한한다. 클라우드 벤더가 EU 리전을 제공하더라도, 데이터 저장 위치를 계약으로 명시해야 하고, 미국 정부의 데이터 요청(Patriot Act·CLOUD Act)에 대응하는 절차가 있어야 한다. 독일·프랑스 정부 부처는 자체 인프라를 고집하는 경우가 많다 — "데이터가 자국 안에 있어야 한다"는 건 정치적·법적 요구사항이다.

의료(HIPAA), 금융(PCI-DSS·SOX·바젤 III), 정부(FedRAMP·K-ISMS), 통신 등 산업별 규제도 비슷하다. 한국의 경우 공공기관은 ISMS-P 인증, 금융권은 금융보안원 심사를 거쳐야 클라우드 사용이 가능하다. 클라우드 벤더가 이런 인증을 보유하더라도, 일부 워크로드는 자체 통제가 필요한 법적 요구사항이 있다.

flowchart TD
    REG["규제/법적 요구사항"] --> Q1{"데이터 현지화 의무?"}
    Q1 -->|Yes| ONPRE["자체 인프라 또는 전용 리전"]
    Q1 -->|No| Q2{"산업별 규제?"}
    Q2 -->|의료/금융/정부| CERT["인증된 클라우드 또는 자체"]
    Q2 -->|일반 상용| Q3{"데이터 민감도?"}
    Q3 -->|높음| HYBRID["하이브리드 — 민감 데이터는 자체, 나머지 클라우드"]
    Q3 -->|낮음| CLOUD["퍼블릭 클라우드"]

이런 규제는 "자체 인프라가 비싸더라도 해야 한다"는 강제력을 갖는다. 비용 최적화가 늘 우선이 아니다. 오히려 규제 위반의 비용(벌금, 영업 정지, 평판 훼손)이 자체 인프라 비용보다 훨씬 큰 경우가 많다.

의사결정 프레임워크 — 언제 어떤 쪽이 이기나

지금까지의 요소를 종합하면, build vs buy는 다음 다섯 질문으로 좁혀진다.

1. 이 인프라가 비즈니스의 핵심 역량인가? Dropbox에게 저장소는 핵심 역량이었다 — 저장소가 느리면 제품이 느린 거다. 자체 인프라 투자가 정당화됐다. Netflix에게 영상 인코딩 인프라는 핵심 역량이었지만, 저장소는 아니었다 — 저장소는 AWS에 맡기고 인코딩에 집중했다. 핵심 역량은 build, 비핵심은 buy.

2. 규모가 충분한가? 클라우드는 소규모엔 싸고 대규모엔 비싸다. 보통 월 클라우드 비용이 100만 달러(연 약 1,200만 달러)를 넘으면 자체 인프라 검토가 시작된다. Dropbox·37signals·Apple 같은 곳이 이 임계점을 넘었다. 물론 그 밑에서도 자체 인프라가 이길 수 있지만, 그 인프라를 운영할 팀을 고용할 만큼의 규모가 필요하다.

3. 트래픽 패턴이 예측 가능한가? 24/7 일정한 트래픽은 자체 인프라(capex)에 유리 — 서버가 항상 켜져 있으니 클라우드 비용이 누적된다. 트래픽이 불규칙하거나 스파이크가 크면 클라우드(opex)에 유리 — 필요할 때만 자원을 늘린다. 미디어 스트리밍·이커머스 프로모션·이벤트성 서비스가 클라우드에 맞는 이유다.

4. 글로벌 확장이 필요한가? 전 세계 사용자를 서비스하려면 여러 리전에 인프라가 필요하다. 이걸 자체로 구축하려면 전 세계 데이터센터 계약·네트워크 백본·현지 인력까지 확보해야 한다. 클라우드는 버튼 한 번이면 된다(대략). 글로벌 확장이 핵심이면 클라우드가 압도적으로 유리.

5. 규제·데이터 주권 제약이 있나? 이미 본 대로, 규제가 있으면 선택지가 좁아진다. 자체 인프라 또는 규제 인증된 특정 클라우드만 쓸 수 있다.

질문	Build 유리	Buy 유리
핵심 역량?	Yes	No
규모?	매우 큼	작거나 중간
트래픽 패턴?	예측 가능, 안정적	불규칙, 스파이크 큼
글로벌 확장?	단일 리전 중심	다중 리전 필요
규제?	엄격한 규제	일반 상용

5개 질문 모두 build 쪽이면 build, 모두 buy 쪽이면 buy. 하지만 현실은 보통 혼합이다 — 핵심 데이터는 자체, 일반 웹 서비스는 클라우드. 이런 하이브리드(hybrid) 모델이 대기업의 표준이다. Apple은 사용자 데이터는 자체 데이터센터에, 일반 서비스는 AWS·GCP·Azure에 분산 배포한다고 알려졌다. 다만 하이브리드는 두 세계의 단점을 다 갖는 구조이기도 하다 — 클라우드 비용 + 자체 인프라 운영 부담 + 두 환경 연동 비용.

클라우드 사용의 숨겨진 함정

기술적 의사결정이 끝났어도, 클라우드를 쓰면서 빠지는 함정이 있다. 02에서 본 Goodhart의 법칙("측정이 목표가 되면 더 이상 좋은 측정이 아니다")이 클라우드 비용에도 그대로 적용된다.

"클라우드가 싸다"는 합리화 — 초기에는 진짜 싸다. 서버 살 돈 없이 시작할 수 있으니까. 하지만 몇 년 지나면 "클라우드 비용이 예산의 30%를 차지한다"는 상태가 돼 있다. 그때 가서야 비용 최적화(FinOps)를 시작하는데, 이미 코드·아키텍처가 클라우드에 깊이 종속된 뒤라 옮기기 어렵다.

"no-ops" 환상 — 클라우드가 운영을 없앤다는 통념은 틀렸다. 운영의 형태가 바뀐 것이다. 서버 고장은 안 나지만 — 클라우드 서비스 장애, API rate limit, 잘못된 IAM 설정, 예기치 않은 과금은 계속 생긴다. 클라우드를 잘 쓰려면 클라우드 엔지니어가 필요하고, 그들은 결국 SRE의 또 다른 이름이다. 03에서 본 "운영을 소프트웨어 공학으로"가 클라우드에서 더 강하게 적용된다.

멀티클라우드 환상 — "AWS가 죽어도 GCP가 살려준다"는 멀티클라우드 전략은 이론상 그렇지만 현실에선 비용이 크다. 두 클라우드의 차이를 추상화하는 레이어가 필요하고, 두 벤더의 인증·네트워크·비용 구조를 모두 관리해야 한다. Kubernetes가 "한 번 짜면 어디서든 돈다"는 약속을 했지만, 실제로는 클라우드별 세부 설정이 다르고, 멀티클라우드는 복잡도 2배를 의미한다. 진짜 필요한 경우(규제, 재해 복구, 벤더 협상력)에만 쓰는 게 정답이다.

예산 폭발 — 클라우드는 "지출 한도(budget alert)"를 설정하지 않으면 무한히 과금된다. 개발자가 실수로 큰 인스턴스를 밤새 띄우거나, 테스트 데이터를 프로덕션 저장소에 올리거나, 크론 작업이 무한 루프에 빠지면 — 청구서가 폭발한다. AWS Cost Anomaly Detection 같은 도구가 있지만, 기본적으로는 사용자가 경계해야 한다. 자체 인프라는 이런 "무한 과금"이 물리적으로 불가능하다 — 랙에 꽂을 수 있는 서버 수가 한정돼 있으니까.

실습 — 비용·종속도 직접 확인하기

이 글의 개념을 직접 확인하는 기본 명령들이다.

1. AWS 월별 청구 항목 분석 (AWS 환경)

# 현재 월의 서비스별 비용 분석. egress가 얼마인지, 어떤 서비스가 비싼지.
aws ce get-cost-and-usage --time-period Start=2026-07-01,End=2026-07-31 \
  --granularity MONTHLY --metrics BlendedCost \
  --group-by Type=SERVICE --output table

확인할 것: EC2·S3·RDS 외에 DataTransfer(egress) 항목. 이게 상위 3위 안에 있으면 egress 최적화(또는 자체 인프라 검토) 신호.

# 예상 출력 (월별 상위 서비스)
---------------------------------------------------------------------------------
|                            GetCostAndUsage                            |
+-----------------------------+-------------+
|           SERVICE           |  BLENDEDCOST|
+-----------------------------+-------------+
|  Amazon Elastic Compute Cloud|  4523.12   |
|  Amazon Simple Storage Service|  1820.50   |
|  Amazon Relational Database  |  894.30    |
|  Amazon EC2 Other            |  623.80    |
|  Data Transfer               |  1240.70   |  # ← egress, 주의
+-----------------------------+-------------+

2. egress 비용 추정 (간단 계산)

# 지난 달 S3 송신량 확인
aws cloudwatch get-metric-statistics --namespace AWS/S3 --metric-name BytesDownloaded \
  --dimensions Name=BucketName,Value=my-bucket \
  --start-time 2026-07-01T00:00:00Z --end-time 2026-07-31T23:59:59Z \
  --period 2592000 --statistics Sum --output text

확인할 것: 송신 바이트 합계. GB로 환산(나누기 1,073,741,824) 후 GB당 $0.09 곱하면 월 egress 비용 추정. 이게 월 수천 달러 이상이면 CDN 도입 또는 자체 인프라 검토.

3. 클라우드 사용 추상화 정도 점검 (코드에서 종속 탐지)

# Terraform 코드에서 AWS 전용 리소스 비율. provider가 몇 개인지.
grep -rh 'provider "' ./terraform/ 2>/dev/null | sort -u
grep -rl 'aws_' ./terraform/ 2>/dev/null | wc -l
grep -rl 'google_' ./terraform/ 2>/dev/null | wc -l

확인할 것: 한 provider(예: aws)만 있으면 단일 벤더 종속. 멀티클라우드를 원하면 provider가 여러 개여야 하는데, 리소스 수가 크게 다르면 실제로 한 벤더에 치우쳐 있는 것.

# 단일 벤더 종속 예시 (위험)
provider "aws" { region = "us-east-1" }
# aws_ 리소스 142개, google_ 리소스 0개

4. 자체 인프라 TCO 추정 — 디스크 단순 계산

# 예: 100TB 저장소의 자체 인프라 vs S3 비교
# 자체: 12TB NVMe × 10대 (3-way 복제 시 100TB 가용) = 하드웨어 비용
# S3: 100TB × $0.023/GB/월 = 월 $2,300, 연 $27,600
python3 -c "tb=100; print(f'S3 연간: \${tb*1024*0.023*12:.0f}')"

확인할 것: S3 비용이 하드웨어 감가상각(보통 3년)보다 비싸면 자체 인프라 검토 신호. 다만 이건 하드웨어만 비교한 거고 — 전력·인건비·냉각·네트워크까지 더해야 진짜 TCO.

미검증: 위 AWS CLI 명령은 자격증명이 설정된 환경에서만 동작. 정확한 비용 숫자는 리전·계약·할인에 따라 다르다. AWS Pricing Calculator(pricing calculator 웹 도구)가 공식 추정 도구.

판단 표 — 서비스 특성별 권장 전략

서비스 특성	권장	이유
스타트업 초기	클라우드(buy)	초기 자본 없음, 빠른 출시
트래픽 예측 불가 스파이크	클라우드(buy)	오토스케일링, 사용한 만큼 지불
대규모 데이터 저장소 (수 PB+)	자체 또는 하이브리드	egress 비용 한계, 데이터 중력
규제 산업 (금융·의료·정부)	자체 또는 인증 클라우드	규제·데이터 주권
글로벌 소비자 서비스	클라우드	다중 리전, 글로벌 CDN
AI/ML 워크로드 (GPU 집약)	클라우드 또는 전용 GPU 클러스터	GPU 가용성, 스파이크 대응
핵심 역량 인프라 (Dropbox 저장소)	자체(build)	경쟁 우위의 원천
CI/CD 인프라	클라우드 또는 SaaS	비핵심, 관리형이 편리
로그·모니터링 파이프라인	클라우드 관리형(OpenSearch 등)	비핵심, 확장성 중요

build vs buy 결정 체크리스트

• TCO를 capex(하드웨어·인건비·데이터센터)와 opex(클라우드 사용료·egress) 양쪽으로 3년 이상 계산했는가?
• egress 비용을 TCO 모델에 포함했는가? (자주 빠지는 항목)
• 핵심 역량인가 — 이 인프라가 우리 제품의 차별점인가?
• 트래픽 패턴을 1년 치 데이터로 봤는가? (예측 가능 vs 불규칙)
• 규모 임계점(보통 월 클라우드 $100만 이상)을 넘었는가?
• 규제·데이터 현지화 의무가 있는가?
• 벤더 종속을 감수할 수 있는가, 아니면 멀티클라우드/추상화가 필요한가?
• 자체 인프라로 갈 경우 팀 고용·교육 계획이 있는가? (팀 없는 자체 인프라는 재앙)
• 3년 뒤 비용 구조가 어떻게 변할지 시나리오를 그렸는가? (트래픽 증가, 신기술, 벤더 단가 변화)
• 하이브리드로 갈 경우, 두 환경 연동 비용을 포함했는가?

인프라 결정은 비용 계산이 아니라 전략이다

도입의 Dropbox 사건으로 돌아가자. Magic Pocket을 만든 건 단지 "클라우드가 비싸서"가 아니었다 — Dropbox에게 저장소는 핵심 역량이었고, 자체 인프라는 경쟁 우위의 원천이 됐다. 같은 시기 다른 회사들은 AWS에 남는 게 합리적이었다. 같은 질문, 다른 맥락, 다른 정답. 그게 build vs buy의 본질이다.

이 결정을 "비용 계산"으로만 보면 위험하다. TCO는 필요조건이지 충분조건이 아니다. 핵심 역량, 규모, 트래픽 패턴, 규제, 벤더 종속 — 이 모든 축을 함께 봐야 한다. 그리고 한 번 결정하면 몇 년 단위의 헌신이 필요하다는 걸 잊으면 안 된다. foundations 01에서 본 "되돌리기 비용" 매트릭스의 가장 무거운 항목들이 바로 이 결정들이다.

다음 글에서는 인프라 결정이 코드가 되는 순간을 다룬다 — Infrastructure as Code(IaC). 선언적 인프라, mutable vs immutable, "인프라를 코드처럼"이라는 패러다임이 왜 생겼고 무엇을 바꿨는지. build를 선택하든 buy를 선택하든, 그 결정을 재현 가능하게 만드는 IaC는 이제 기본 소양이다.

---

참고

• Harris, D. "Why Dropbox's Storage Infra is Now Mostly In-House", Platform Engineering / Dropbox Tech Blog, 2016-03 — Magic Pocket 자체 스토리지 발표. 접근 2026-07-21. URL: https://dropbox.tech/infrastructure/inside-the-magic-pocket
• Bhagwan, R., Tung, I. "Fixing UNIX Hardlinks and Reflink Copies", Dropbox Tech Blog — Magic Pocket 기술 디테일. 접근 2026-07-21
• Hansson, D. H. "Why we're leaving the cloud", 37signals Signal v. Noise blog, 2022-10-28 — 클라우드에서 베어메탈로 회귀한 비용 분석. 접근 2026-07-21. URL: https://world.hey.com/dhh/why-we-re-leaving-the-cloud-654b47e0
• AWS Well-Architected Framework, Cost Optimization Pillar — 비용 최적화 5원칙. 접근 2026-07-21. URL: https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/
• European Union, "General Data Protection Regulation (GDPR)", 2016/679, 2016-04-27 (시행 2018-05-25) — EU 개인정보보호법. 접근 2026-07-21
• Gartner, "Cloud Pricing Comparison: AWS vs Azure vs Google Cloud", 2024 — 클라우드 단가 비교. 접근 2026-07-21
• Kleppmann, M. , O'Reilly, 2017, Ch.1 — 신뢰성·확장성·유지보수성과 비용의 관계. 접근 2026-07-21
• Cloud Native Computing Foundation, "Cloud Native Definition v1.0" — 클라우드 네이티브 철학. 접근 2026-07-21. URL: https://github.com/cncf/toc/blob/main/DEFINITION.md
• Snapshot Inc., Form S-1 (IPO 등록 신청서), 2017 — Snapchat·Google Cloud 20억 달러 5년 계약 공개. 접근 2026-07-21