그는 저에게 팀의 상황을 차근차근 설명해 주었습니다.

시니어 엔지니어 두 명이 업무 시간의 30%를 Spark 클러스터 유지보수에 할애하고 있었습니다. 한 명은 새벽 3시에 실패하는 작업들을 위해 온콜 (on-call) 대기를 하고 있었죠. 세 번째 엔지니어는 지난 분기에 Kubernetes 오퍼레이터 (operator)를 업그레이드하는 데 시간을 보냈습니다. 리드 데이터 엔지니어는 지난 4월에 퇴사했습니다. 팀원들은 번아웃 (burnout) 때문이라고 말했습니다.

그들은 8만 달러를 아낀 것이 아닙니다. 엔지니어들의 업무 시간으로 40만 달러를 지출하고는 그것을 자유라고 불렀을 뿐입니다.

아무도 이 계산을 해보지 않습니다. 그러니 이제 실제로 계산해 봅시다. 수치는 예시일 뿐이며 모델이 핵심이므로, 여러분의 실제 수치를 직접 대입해 볼 수 있는 코드를 준비했습니다.

아무도 계산하지 않는 수치

셀프 호스팅 (self-hosting)을 제안할 때 항상 내세우는 것은 인보이스 (invoice)입니다. 관리형 플랫폼 (managed platform)을 쓰면 연간 8만 달러가 더 들기 때문에, 직접 호스팅하면 8만 달러를 "아낄" 수 있다는 논리죠. 그 8만 달러는 실제 비용입니다. 또한 사람들이 계산하는 유일한 숫자이기도 합니다.

다음은 나머지 청구서입니다. 항목별 비용이 아닌 '사람'으로 나타나는 부분입니다:

# 시니어 데이터 엔지니어 한 명의 총 소요 연간 비용 (Fully-loaded annual cost).
# 급여 + 복리후생 + 급여세 + 오버헤드 + 장비. 시장 상황에 맞게 조정하세요.
LOADED_SENIOR = 200_000
...

  클러스터 유지보수에 투입되는 시니어 2명 @ 30%             $   120,000
  온콜 엔지니어 1명 (새벽 3시 / 주말 세금)                 $    40,000
  K8s 오퍼레이터 업그레이드에 분기별 투입된 엔지니어 1명    $    50,000
...

8만 달러 절감. 하지만 32만 달러는 적자입니다. 게다가 네 명의 엔지니어가 제품을 만드는 대신 플랫폼 팀으로서 조용히 부업을 하느라, 결국 출시하지 못한 로드맵 (roadmap) 비용까지 고려하기 전의 수치입니다.

"하지만 규모가 커지면 셀프 호스팅이 유리하다" — 좋습니다, 그럼 그 경계선은 어디일까요?

저는 관리형 서비스가 항상 승리한다고 말하려는 것이 아닙니다. 그렇지 않습니다. 분명한 교차점 (crossover)이 존재하며, 추상적으로 논쟁하기보다는 그 지점을 찾아내는 것이 가치 있는 일입니다.

셀프 호스팅이 유리해지는 시점은 관리형 벤더가 부과하는 프리미엄 (premium)이 플랫폼을 "제대로" 운영하는 팀의 비용보다 커질 때입니다. 여기서 "제대로"란, 실제 로드맵의 부수적인 업무로 플랫폼을 운영하는 네 명이 아니라, 플랫폼 운영 자체가 전체 업무인 실제 팀을 의미합니다.

LOADED_SENIOR = 200_000

# 이 플랫폼을 "제대로" 운영하는 플랫폼 팀 — 부업을 하는 4명이 아닌 실제 팀.
...

실제 플랫폼 팀 운영 비용은 연간 약 $800,000

컴퓨팅 비용 $ 200,000/yr 매니지드 프리미엄 $ 70,000 -> 매니지드 서비스 이용
...

해당 선은 컴퓨팅 비용 기준으로 연간 약 $2.3M 지점에 위치합니다. 이 선 아래 — 즉, 압도적 다수의 팀이 실제로 머물고 있는 지점 — 에서 당신은 청구서에 맞서 돈을 잃기 위해 플랫폼 팀을 고용하고 있는 셈입니다. 이 선 위로 올라가야 비로소 실제 플랫폼 조직이 스스로의 가치를 증명하기 시작합니다. 실수는 셀프 호스팅 (Self-hosting) 그 자체가 아니었습니다. 문제는 규모가 적절한 지점의 10분의 1 수준에서, 필요한 팀 규모의 10분의 1만 가지고 셀프 호스팅을 시도했다는 점입니다.

진짜 질문은 "클라우드 vs 셀프 호스팅"이 아닙니다

따라서 2026년의 질문은 추상적인 '직접 구축할 것인가(Build) vs 구매할 것인가(Buy)'가 아닙니다. 질문은 더 좁고 훨씬 더 유용해야 합니다: 당신의 경쟁 우위 (Edge)는 실제로 어느 계층 (Layer)에 있는가? 당신의 것인 계층은 직접 구축하십시오. 당신의 것이 아닌 모든 계층은 비용을 지불하십시오.

제가 사용하는 지도는 다음과 같습니다:

계층 (Layer)	범용 기술 (Commodity)인가 경쟁 우위인가?	결정	이유
객체 스토리지 (Object storage, S3/GCS)	범용 기술 (Commodity)	구매 (Buy)	더 나은 버킷(Bucket)으로 시장을 제패한 사람은 아무도 없습니다.
...

위에서 아래로 읽어보면 패턴이 나타납니다. 스토리지, 데이터 웨어하우스 (Warehouse), 오케스트레이션 (Orchestration), 엔진, 모델과 같이 차별화되지 않는 고된 작업 (Undifferentiated heavy lifting)은 모두 누군가가 이미 당신보다 더 잘 운영하고 있는 범용 기술 (Commodity)입니다. 변환 로직 (Transformation logic), 기능 (Features), 검색 전략 (Retrieval strategy), 제품 (Product)과 같이 당신만의 것인 모든 영역이 실제로 엔지니어링 시간이 복리로 쌓이는 지점입니다.

대부분의 팀은 정확히 그 반대로 행동합니다. 그들은 벤더 종속 (Lock-in)을 피하기 위해 자체 데이터 웨어하우스를 구축하지만, 정작 평가 프레임워크 (Eval harness)나 검색 전략도 없이 프롬프트를 모델 API에 무작정 (YOLO) 던져버립니다. 그들은 범용 기술은 보호하면서 차별화 요소는 포기하고 있습니다.

셀프 호스팅을 할 때 실제로 떠안게 되는 것들

송장(Invoice)상의 "절감"은 작업의 제거가 아니라 작업의 전이를 숨기고 있을 뿐입니다. 오케스트레이터를 셀프 호스팅하면 이제 당신은 다음을 책임져야 합니다: 버전 업그레이드, CVE 패치, 오토스케일링 (Autoscaling), 고가용성 (HA) 및 장애 조치 (Failover), 백업 및 복구, 온콜 (On-call) 당번, 그리고 아무도 작성했다는 사실을 기억하지 못하는 values 파일까지 말입니다.

매니지드 서비스를 이용하면, 이 모든 운영 영역 (Ops surface)은 설정 (Config) 하나로 축소됩니다.

# 매니지드 오케스트레이션 (Managed orchestration) — 업그레이드, 스케일링 (scaling), 고가용성 (HA), 패칭 (patching): 당신의 문제가 아닙니다.
orchestration:
  provider: managed
...

셀프 호스팅 (Self-hosted) 방식에서는, 피치 슬라이드(pitch slide)에 절대 포함되지 않는 부분이 바로 이 부분입니다:

# 동일한 "Airflow 실행"이지만, 이제는 영원히 당신의 것입니다:
helm upgrade airflow apache-airflow/airflow \
  --values values.prod.yaml \
        # 이제 당신이 소유하고 논리적으로 파악해야 하는 400줄의 코드
...

둘 중 어느 하나가 틀린 것은 아닙니다. 하지만 하나는 드롭다운 메뉴이고, 다른 하나는 30%의 시간을 할애하는 시니어 엔지니어 두 명과 #pipelines-help라는 이름의 Slack 채널입니다. 결정 자체는 괜찮습니다. 양쪽의 비용을 모두 산정하기만 한다면 말이죠. 바로 그 단계가 생략되었을 뿐입니다.

원칙

범용 기술 (Commodity)에는 비용을 지불하세요. 차별화 요소 (Differentiator)를 구축하세요. 시니어 엔지니어들이 타인의 차별화되지 않은 인프라를 유지하는 데 소비하는 매 시간은, 경쟁사가 단순히 돈으로 살 수 없는 단 한 가지—즉, 당신만의 로직, 기능, 그리고 실제 제품—에 투자하지 못하는 시간입니다.

그리고 이것은 결코 클라우드 대 셀프 호스팅의 논쟁이 아니었다는 점에 주목하십시오. 이것은 인프라의 탈을 쓴 데이터 엔지니어링 자원 배분 (allocation) 문제입니다. 즉, 팀의 한정된 시니어 시간이 실제로 어디에 쓰이고 있는지, 그리고 그것이 당신의 실제 경쟁 우위 (edge)가 있는 곳과 일치하는지의 문제입니다.

당신의 팀이 구축한 것 중, 그냥 비용을 지불했어야 했던 가장 비싼 것은 무엇입니까?

여기에 제시된 수치들은 예시용 플레이스홀더입니다. 총 급여, 매니지드 프리미엄, 35%의 세금은 모두 조절 가능한 변수입니다. 실제 구축 대 구매 (build-vs-buy) 결정을 내리기 전에 당신만의 수치를 대입해 보십시오. 중요한 것은 수치가 아니라 모델 그 자체입니다.

저는 Vinicius Fagundes입니다. 독립적인 수석 데이터 엔지니어이자 상파울루의 MBA 강사입니다. 저는 팀이 어떤 레이어를 소유해야 하고 어떤 레이어를 임대해야 하는지를 결정하며, 그 후 팀의 것을 구축하는 데 시간을 보냅니다. 저의 작업물은 vf-insights.com에서 확인할 수 있습니다.