지난 9월, 연 매출액 $50M인 SaaS 클라이언트가 우리에게 한 가지 질문을 던졌다. 이를 잘못 답하면 엔터프라이즈에 수백만 달러의 손실을 초래할 수 있다: 향후 5년간 $487K의 Salesforce + Tableau + Outreach 스택을 유지할 것인가, 아니면 $312K를 들여 커스텀 revenue-ops 플랫폼을 구축할 것인가? "더 싼" 답이 정답이 아니었다. 우리가 이 답을 찾기 위해 사용한 프레임워크를 소개한다: 12점 스코어링 루브릭, 5년 TCO 모델, 그리고 Google의 상위 10개 구축 vs 구매 가이드에서 다루지 않은 Gartner의 Buy/Build/Blend 3분법이다. 그리고 우리는 엔지니어링 에이전시이지만, 우리를 고용하는 것보다 SaaS를 구매해야 할 때를 명확히 말해줄 것이다.

핵심 정리 (TL;DR):

  • 대부분의 구축 vs 구매 조언은 한 답에서 이익을 얻는 벤더에게서 나온다. 신뢰하기 전에 출처의 편향을 파악하라.
  • Gartner의 Buy/Build/Blend 프레임워크는 현재 엔터프라이즈 소프트웨어 지출의 76%를 차지한다. 순수 구축이나 순수 구매는 2026년의 소수 사례다.
  • 직감이 아닌 12개의 가중 기준으로 의사결정을 점수화하라. 커스텀 구축은 총점이 45를 초과할 때 승리; SaaS는 30 이하에서 승리한다.
  • AI 코딩 에이전트(Cursor, Claude Code)는 2026년 기능당 시니어 엔지니어 작업 시간을 40~60% 단축했다. 구축 비용 계산이 달라졌다.

엔터프라이즈 소프트웨어에서 구축 vs 구매 의사결정이란?

구축 vs 구매 의사결정은 기존 SaaS 또는 COTS 소프트웨어를 라이선스하는 것(구매), 내부에서 커스텀 소프트웨어를 개발하는 것(구축), 또는 파트너 에이전시와 계약하여 독점 소프트웨어를 구축하는 것(파트너) 중 선택하는 것이다. Gartner의 최신 정의는 이를 Buy/Build/Blend로 확장하며, 현재 엔터프라이즈 소프트웨어 지출의 76%는 순수 구축이나 순수 구매가 아닌 표준 제품과 커스텀 확장의 조합으로 흐르고 있다.

의사결정은 세 가지 질문으로 귀결된다:

  • 이 기능은 경쟁 우위인가, 아니면 일반적인 상품인가?
  • 각 경로의 실제 5년 TCO는 얼마인가?
  • 장기적으로 이를 담당할 시니어 엔지니어링 팀을 구성할 수 있는가?

대부분의 구축 vs 구매 가이드는 두 답 중 하나에서 이익을 얻는 사람들에 의해 작성된다. SaaS 마켓플레이스는 구매를 원한다. 개발 에이전시는 구축을 원한다. COTS 벤더는 그들의 계약 갱신을 보호하는 모든 것을 원한다. 셋을 읽으면 세 가지 자신 있는, 상반된 추천을 받을 것이고, 각각은 세일즈 후크 아래에 묻혀 있을 것이다. 음성 AI 구축을 구체적으로 평가하고 있다면, 우리는 더 좁은 의사결정에 대해 동일한 로직을 실행하는 이 프레임워크의 수직 버전을 작성했다. 이 포스트의 나머지 부분은 실제로 회의에서 실행할 수 있는 일반적인 조달 프레임워크다.

Gartner가 실제로 말하는 것: Buy / Build / Blend 프레임워크

Gartner의 조달 프레임워크는 이진적인 구축 vs 구매 질문을 거부하고 3가지 선택으로 대체한다: Buy(COTS 또는 SaaS 라이선스), Build(내부 커스텀 개발), Blend(상품 워크플로우에는 SaaS, 차별화된 워크플로우에는 커스텀 코드 결합). Gartner Buy/Build/Blend 모델에 따르면, 현재 엔터프라이즈 소프트웨어 지출의 76%는 혼합 스택으로 흐르고 있다. 순수 구축이나 순수 구매는 소수 사례다.

Buy = 상품화된 것을 라이선스하라

기능이 이미 해결된 문제이고 다른 누군가가 대규모로 솔루션을 배포한 경우 구매하라. CRM, 급여, 이메일, 경비 관리, 옵저버빌리티. 구매의 경제성이 가장 좋은 경우는 워크플로우에 사용자가 100명 미만이고, 90일 이내에 시작해야 하며, SaaS가 즉시 사용 가능한 형태로 필요한 80% 이상을 해결할 때다.

Build = 차별화된 것을 소유하라

기능이 당신의 경쟁 우위(moat)일 때 구축하라. 고객이 당신을 위해 사는 것이다. Stripe는 결제 스택을 라이선스하지 않았다. Figma는 렌더링 엔진을 라이선스하지 않았다. 또한 SaaS가 당신의 데이터 구조를 모델링할 수 없을 때(복잡한 다중 법인 재무나 비표준 규정 준수 제도를 생각해보라) 또는 당신의 5년 SaaS 청구액이 커스텀 구축 TCO를 2배 이상 초과할 때도 구축이 승리한다.

Blend = 대부분의 엔터프라이즈가 실제로 택하는 계산

Blending은 지루한 80%에는 COTS를 유지하고 차별화된 20%에는 커스텀을 구축하는 것을 의미한다. 전형적인 패턴: Salesforce를 기록의 시스템(system of record)으로 + Salesforce가 모델링할 수 없는 워크플로우를 위한 얇은 커스텀 계층. Thoughtworks는 이를 Buy/Build/Partner라고 부르고, Gartner는 Buy/Build/Blend라고 부른다. 같은 아이디어, 약간 다른 용어다. 이 3분법은 1990년대 McKinsey의 Make-or-Buy Matrix로 거슬러 올라가지만, 클라우드 시대가 세 번째 선택지를 지배적으로 만들었다.

12점 스코어링 루브릭 (스프레드시트에 복사하기)

각 기준을 당신의 상황에 얼마나 강하게 적용되는지에 따라 1~5점으로 평가하라. 가중치를 곱하라. 총점을 합산하라. 맨 아래 임계값 범례가 계산이 어느 경로를 가리키는지 알려준다. 이를 실제 조달 회의에서 사용하면 2시간의 논쟁을 20분으로 단축할 수 있다.

임계값 범례:
- 총점 <30 → SaaS 구매
- 총점 30~45 → Blend
- 총점 >45 → 구축

우리 사례 연구 클라이언트를 사용한 실제 예시(H2 #8에서 상세히 다루는): 그들은 38점을 받았다. 차별화는 3점(revenue ops는 중요하지만 그들의 경쟁 우위는 아니다), 팀 구성은 2점(장기적으로 엔지니어를 할당할 수 없다), SaaS 커버리지 격차는 4점(Salesforce가 그들의 워크플로우 약 1/3을 놓쳤다), AI 구축비용 감소는 5점. 결과: 확실히 Blend 영역에 있으며, 이것이 추천이 내려진 곳이다.

한 가지 주의. 이 루브릭은 의사결정 보조 도구이지, 의사결정 결정자가 아니다. 점수가 경계선상에 있다면(28~32 또는 43~47) 커밋하기 전에 다음 섹션의 TCO 모델을 실행하라. 숫자가 결정을 바꿀 수 있다.

TCO 모델링: 5년 비용을 정직하게 계산하는 방법

Gartner의 소프트웨어 비용 분석 연구에 따르면, 엔터프라이즈는 소프트웨어 소유권을 계산할 때 TCO의 50~70%를 놓친다. 가장 자주 놓치는 항목: 통합, 관리 FTE, 이탈 비용. 1년차 정가(sticker price)는 청구액의 가장 작은 부분이며, 거의 모든 벤더 데모는 정확히 그 숫자를 제시한다.

각 경로에 대해 5년 TCO를 정직하게 계산하는 방법은 다음과 같다.

Buy(SaaS) 항목: 라이선싱 × 사용자 × 년수, 구현 및 설정, 교육, 관리 FTE 배정(엔터프라이즈 규모에서 일반적으로 0.5~2 FTE), 기존 시스템과의 통합, 최종적으로 마이그레이션할 때의 이탈 비용.

Build(커스텀) 항목: 초기 엔지니어링(엔지니어-월 × 완전 부담 비율), 연간 유지보수(업계 통칙: 초기 구축비용의 15~20%), 인프라 및 도구, 당신이 할당하는 엔지니어링 역량의 기회 비용.

Blend 항목: 상품화된 계층의 SaaS 구독료, 커스텀 통합/확장 비용, 커스텀 계층의 유지보수. 완전 구축보다 초기 비용 낮음, 완전 구매보다 지속 비용 낮음.

미국 해안 지역 완전 부담 엔지니어 비용으로 $230K를 사용하라: 2024년 5월 BLS 중앙값은 $130,160이었고, 여기에 편익으로 ~30%, 오버헤드로 ~25%를 추가한다. 당신의 지역에 따라 ±30% 조정하라. 유럽팀은 일반적으로 20~30% 낮고, 미국 비해안 팀은 15~20% 낮다.

일반적인 예시 범위. 당신의 숫자는 다를 것이지만, 카테고리는 변하지 않을 것이다.

BLEND를 선택할 때 (대부분의 엔터프라이즈가 택하는 중간 경로)

Blend는 순수 구매도 순수 구축도 당신의 워크플로우에 깔끔하게 매핑되지 않을 때 승리한다. 상품화된 계층(CRM, 청구, 신원, 옵저버빌리티)에는 COTS를 유지하고, 당신의 경쟁 차별화 요소이거나 단순히 SaaS에서 모델링이 불가능한 워크플로우를 위해 커스텀을 구축한다. 그들 사이의 접합은 API, MCP 서버, 또는 로우코드 워크플로우 엔진이다.

우리가 반복적으로 보는 네 가지 구체적인 Blend 패턴:

  • Salesforce + 커스텀 RevOps 계층. Salesforce는 기록의 시스템으로 유지된다. 커스텀 계층은 Salesforce의 프로세스 빌더가 깔끔하게 모델링할 수 없는 다단계 수익 워크플로우를 처리한다. 아래 클라이언트 사례 연구가 정확히 이 패턴이다.
  • SAP/NetSuite + 커스텀 데이터 계층. ERP를 원장 및 조달용으로 유지한다. CFO가 실제로 원하는 재무 분석을 위해 웨어하우스 + 커스텀 대시보드를 구축한다.

...

출처 바로가기