기업용 소프트웨어, 직접 개발할까 구매할까: 벤더 중립적 프레임워크 (12점 평가 루브릭 포함, 2026)

기업용 소프트웨어, 직접 개발할까 구매할까: 벤더 중립적 프레임워크 (12점 평가 루브릭 포함, 2026)

지난 9월, ARR 5,000만 달러 규모의 SaaS 고객사가 우리에게 이런 질문을 던졌다. 잘못 답하면 수백만 달러가 날아가는 질문이었다. 향후 5년간 48.7만 달러짜리 Salesforce + Tableau + Outreach 스택을 유지할 것인가, 아니면 31.2만 달러를 들여 커스텀 매출 운영(revenue-ops) 플랫폼을 직접 개발할 것인가. '더 저렴한' 답은 틀렸다. 우리가 그 답을 찾아낸 프레임워크를 공개한다. 12점 평가 루브릭, 5년 TCO 모델, 그리고 현재 구글 상위 10개 '개발 vs 구매' 가이드 중 어느 곳도 제대로 언급하지 않는 Gartner의 Buy/Build/Blend 3분법이다. 그리고 그렇다, 우리는 엔지니어링 에이전시다. 그래서 우리를 고용하는 대신 SaaS를 사야 할 때도 솔직히 말해줄 것이다.

핵심 요약 (TL;DR):

• 대부분의 개발 vs 구매 조언은 한쪽 답에서 이익을 얻는 벤더가 작성한다. 신뢰하기 전에 그 출처의 이해관계를 먼저 파악하라.
• Gartner의 Buy/Build/Blend 프레임워크는 현재 기업용 소프트웨어 지출의 76%를 포괄한다. 2026년엔 순수 개발이나 순수 구매가 소수 사례다.
• 감이 아니라 12개 가중치 기준으로 의사결정을 점수화하라. 총점 45 초과면 커스텀 개발, 30 미만이면 SaaS가 답이다.
• AI 코딩 에이전트(Cursor, Claude Code)는 2026년 기능당 시니어 엔지니어링 시간을 40~60% 줄였다. 개발의 셈법이 바뀌었다.

기업용 소프트웨어에서 '개발 vs 구매' 의사결정이란?

개발 vs 구매 의사결정이란 기존 SaaS나 COTS 소프트웨어를 라이선스하는 것(구매), 사내에서 커스텀 소프트웨어를 개발하는 것(개발), 또는 파트너 에이전시에 의뢰해 독점 소프트웨어를 만드는 것(파트너) 사이의 선택이다. Gartner의 현대적 프레임은 이를 Buy/Build/Blend로 확장하며, 현재 기업용 소프트웨어 지출의 76%는 순수 개발이나 순수 구매가 아닌 표준 제품과 커스텀 확장 기능의 조합으로 흘러간다.

이 의사결정은 세 가지 질문에 달려 있다.

• 해당 역량이 경쟁 차별화 요소인가, 아니면 범용 기능(commodity)인가?
• 각 경로의 실질적 5년 TCO는 얼마인가?
• 장기적으로 이를 책임질 시니어 엔지니어링 팀을 갖출 수 있는가?

미리 밝혀둔다: Techsy는 엔지니어링 에이전시다. 우리는 고객이 개발할 때 돈을 번다. 그래서 우리를 고용하지 말고 SaaS를 사야 하는 모든 경우를 솔직히 말해줄 것이다. 장기적으로, 이런 글은 셈법이 정직할 때만 가치가 있기 때문이다. 글 맨 아래에 우리 퍼널 목표를 명시해뒀다. 그 사이의 모든 내용은 피치가 아니라 프레임워크다.

대부분의 개발 vs 구매 가이드는 두 답 중 한쪽에서 이익을 얻는 사람들이 쓴다. SaaS 마켓플레이스는 당신이 구매하길 원한다. 개발 에이전시는 당신이 개발하길 원한다. COTS 벤더는 자신들의 재계약(리뉴얼)을 지키는 방향이라면 뭐든 원한다. 세 곳만 읽어봐도 자신감 넘치지만 서로 정반대인 추천 세 개를 받게 되고, 각각은 영업용 미끼 아래 파묻혀 있다. 만약 음성 AI 개발을 구체적으로 검토 중이라면, 같은 논리를 더 좁은 의사결정에 적용한 이 프레임워크의 버티컬 버전을 따로 작성해뒀다. 이 글의 나머지 부분은 실제 회의에서 바로 실행할 수 있는 일반적인 조달 프레임워크다.

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

Gartner의 조달 프레임워크는 개발 vs 구매라는 이분법적 질문을 거부하고, 이를 세 가지 선택지로 대체한다. 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 = 대부분의 기업이 결국 도달하는 셈법

블렌딩이란 지루한 80%는 COTS로 유지하고, 차별화된 20%는 커스텀으로 개발한다는 뜻이다. 고전적 패턴은 이렇다. Salesforce를 시스템 오브 레코드(system of record)로 두고, Salesforce가 모델링하지 못하는 워크플로에는 얇은 커스텀 레이어를 올리는 것이다. Thoughtworks는 이를 Buy/Build/Partner라 부르고, Gartner는 Buy/Build/Blend라 부른다. 같은 아이디어에 어휘만 약간 다르다. 이 3분법은 1990년대 McKinsey의 Make-or-Buy 매트릭스로 거슬러 올라가지만, 클라우드 시대가 세 번째 선택지를 지배적인 위치로 만들었다.

12점 평가 루브릭 (스프레드시트에 복사해 쓰세요)

각 기준에 대해 해당 사항이 얼마나 강하게 적용되는지에 따라 1~5점을 매긴다. 가중치를 곱한다. 총점을 더한다. 맨 아래 임계값 범례가 어느 경로로 가야 하는지 알려준다. 실제 조달 회의에서 이걸 쓰면 2시간 걸릴 논의를 20분으로 줄일 수 있다.

임계값 범례:

• 총점 30 미만 → SaaS 구매
• 총점 30~45 → Blend
• 총점 45 초과 → 개발

실제 적용 예시로, 우리가 사례 연구로 다룬 고객사(아래 H2 #8에서 자세히 다루는 바로 그 곳)를 보자. 이들은 38점을 받았다. 차별화 요소는 3점(매출 운영은 중요하지만 그들의 해자는 아님), 엔지니어링 역량은 2점(장기적으로 엔지니어를 전담 배치할 수 없었음), SaaS 커버리지 공백은 4점(Salesforce가 워크플로의 약 3분의 1을 놓침), AI 개발 비용 절감은 5점이었다. 결과: 확실히 Blend 영역이었고, 실제 추천도 그렇게 내려졌다.

한 가지 주의할 점. 루브릭은 의사결정 보조 도구이지 의사결정자가 아니다. 점수가 경계선에 있다면(2832 또는 4347) 확정하기 전에 다음 섹션의 TCO 모델을 먼저 돌려보라. 숫자가 판단을 바꾼다.

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

소프트웨어 비용 분석에 대한 Gartner 리서치에 따르면, 기업들은 소프트웨어 소유 비용을 계산할 때 TCO의 50~70%를 놓친다. 가장 자주 빠뜨리는 항목은 통합, 관리 인력(FTE), 그리고 탈출 비용(escape cost)이다. 1년 차 가격표는 청구서의 가장 작은 부분일 뿐인데, 거의 모든 벤더 데모가 정확히 그 숫자만 보여준다.

각 경로별로 5년 TCO를 정직하게 계산하는 방법은 이렇다.

Buy (SaaS) 항목: 라이선스 × 사용자 수 × 연수, 구현 및 설정, 교육, 관리 인력(FTE) 배분(엔터프라이즈 규모에서 보통 0.5~2 FTE), 기존 시스템과의 통합, 그리고 결국 마이그레이션할 때의 탈출 비용.

Build (커스텀) 항목: 초기 엔지니어링(엔지니어-개월 수 × 완전부담 단가), 연간 유지보수(업계 경험칙: 초기 개발 비용의 15~20%), 인프라 및 도구, 그리고 투입하는 엔지니어링 역량의 기회비용.

Blend 항목: 범용화 레이어의 SaaS 구독료, plus 커스텀 통합/확장 비용, plus 커스텀 레이어의 유지보수. 초기 비용은 완전 개발보다 낮고, 지속 비용은 완전 구매보다 낮다.

미국 해안가 기준 완전부담 엔지니어 비용으로 23만 달러를 사용하라. BLS(미국 노동통계국) 중위값은 2024년 5월 기준 130,160달러였고, 여기에 복리후생 약 30%, 간접비(오버헤드) 약 25%를 더한다. 지역별로 ±30% 조정하라. 유럽 팀은 보통 2030% 낮고, 미국 비해안가 팀은 1520% 낮다.

일반적인 예시 범위다. 당신의 숫자는 다를 수 있지만, 항목 카테고리는 다르지 않다.

언제 BLEND를 선택하나 (대부분의 기업이 결국 택하는 중간 경로)

순수 구매도 순수 개발도 워크플로에 깔끔하게 들어맞지 않을 때 블렌딩이 답이다. 범용화된 레이어(CRM, 청구, 아이덴티티, 옵저버빌리티)는 COTS로 유지하고, 경쟁 차별화 요소이거나 SaaS로 모델링이 불가능한 워크플로는 커스텀으로 개발한다. 둘을 잇는 접착제는 API, MCP 서버, 또는 로우코드 워크플로 엔진이다.

우리가 반복해서 보는 네 가지 구체적인 블렌드 패턴:

1. Salesforce + 커스텀 RevOps 레이어. Salesforce는 시스템 오브 레코드로 유지한다. 커스텀 레이어가 Salesforce의 프로세스 빌더로 깔끔하게 모델링되지 않는 다단계 매출 워크플로를 처리한다. 아래 고객 사례가 정확히 이 패턴이다.
2. SAP/NetSuite + 커스텀 데이터 레이어. 원장과 조달은 ERP로 유지한다. CFO가 실제로 원하는 재무 분석을 위해 데이터 웨어하우스 + 커스텀 대시보드를 구축한다.
3. HubSpot + 커스텀 인리치먼트(enrichment) 파이프라인. 시퀀싱과 CRM은 HubSpot을 쓰되, 상용 데이터 벤더가 당신의 ICP(이상적 고객 프로필)에 충분히 정확하지 않을 때는 자체 인리치먼트를 구축한다.
4. COTS HR + 커스텀 워크플로 자동화. 기록 관리는 BambooHR이나 Rippling로, 온보딩 + 오프보딩 오케스트레이션은 n8n이나 커스텀 코드로 처리한다. 이 부분은 누구도 제대로 패키징하지 못한다.

2026년 들어 블렌드가 실질적으로 저렴해졌는데, 기존 SaaS에 AI 기능을 점진적으로 추가하는 것이 더 이상 리서치 팀을 요구하지 않게 되었고, SaaS와 커스텀 코드를 이어주는 MCP 서버가 역사적으로 블렌드를 비싸게 만들었던 통합 비용을 압축해주기 때문이다. 블렌드는 타협안이 아니다. Gartner에 따르면 76%의 기업에 대한 답이다.

언제 BUILD를 선택하나 (커스텀이 이기는 3가지 시나리오)

개발이 이기는 경우는 명확히 세 가지다. 이 중 어느 것도 당신 상황에 해당하지 않는다면, 아마 개발해선 안 된다.

1. 해당 역량이 경쟁 차별화 요소일 때

고객이 바로 이 특정 역량 때문에 당신을 선택한다면, 다른 고객사가 당신의 경쟁사인 벤더로부터 이를 라이선스할 수는 없다. Stripe는 결제 스택을 라이선스하지 않았다. Notion은 문서 엔진을 라이선스하지 않았다. 그 역량은 해자여야 한다. 단순히 당신이 우연히 사용하는 기능 정도여서는 안 된다.

2. SaaS가 당신의 고유한 데이터 구조를 모델링할 수 없을 때

당신의 데이터가 기존 SaaS가 문자 그대로 표현할 수 없는 구조를 갖고 있다면(복잡한 다중 엔티티 금융, 특이한 규제 스키마, 실시간 멀티플레이어 상태), 처음부터 개발하는 것보다 커스터마이징 비용과 컨설팅 시간에 더 많은 돈을 쓰게 된다. 두 곳의 SaaS 벤더에게 유료 POC를 의뢰해 이를 검증해보라. 둘 다 실패하면 개발하라.

3. 5년 SaaS TCO가 커스텀 개발의 2배 이상일 때

사용량에서 셈법이 뒤집힌다. 사용자 500명이 시트당 월 200달러 SaaS를 쓰면 = 연 120만 달러 = 5년간 600만 달러다. 같은 워크플로를 위한 집중적인 커스텀 개발은 초기 40만 달러 + 연 8만 달러 유지보수 = 5년간 80만 달러에 그칠 수 있다. 배수가 2배 이상이고 워크플로가 안정적이라면, 개발하라.

솔직한 리스크 경고: 개발은 프로젝트 리스크를 떠안는다는 뜻이다. Standish Group CHAOS 리포트에 따르면 IT 프로젝트의 69%가 부분적으로 또는 완전히 실패한다. 셈법이 그렇다 해도 개발은 공짜가 아니다. 범위 규율, 실질적인 프로덕트 오너십, 그리고 초기 MVP로 리스크를 완화하라. 특히 사내 AI 도구의 경우, 셀프 호스팅 엔터프라이즈 AI 도구는 2026년 우리가 실제로 작동하는 것을 보는 개발 패턴인데, 기성 옵션들이 데이터 거주지(data-residency) 요건을 충족하지 못할 때 유효하다.

언제 BUY를 선택하나 (그리고 아무도 말하지 않는 숨은 비용)

구매가 이기는 경우는 해당 역량이 범용화되어 있고, 빠르게 가동이 필요하며, SaaS가 아웃 오브 더 박스로 요구사항의 대부분을 해결해줄 때다. 세 가지 시나리오:

1. 해당 역량이 범용화되어 있을 때

CRM, 이메일, 회계, 옵저버빌리티, 아이덴티티, 경비 관리. 이들은 이미 해결된 문제다. SaaS 벤더들은 당신이 직접 부딪혔을 수천 가지 엣지 케이스를 이미 출시해뒀다. 2026년에 이 중 어떤 것이든 처음부터 개발하는 것은 거의 항상 잘못된 선택이다.

2. 90일 이내에 가동이 필요할 때

해당 워크플로가 매출을 막고 있고 여유 엔지니어링 역량이 없다면, 구매하라. 6개월 개발 vs 6주 SaaS 도입의 기회비용은 거의 모든 경우 라이선스 비용을 압도한다.

3. SaaS가 아웃 오브 더 박스로 80% 이상 해결할 때

나머지 20%의 커스터마이징 부채가 SaaS 프리미엄 총액보다 적게 든다면, 그냥 구매하라. 계약 전에 갭 리스트를 작성해 이를 검증하라. 갭이 워크플로 측면에서 가볍다면(설정, 통합, 가벼운 리포팅) 괜찮다. 워크플로 측면에서 무겁다면, 괜찮지 않다.

아무도 데모 슬라이드에 올리지 않는 숨은 비용:

SaaS 가격은 슬금슬금 오른다. Zylo의 2025 SaaS 관리 지수에 따르면 평균적인 기업은 미사용 또는 중복된 SaaS 시트에 연간 약 2,100만 달러를 낭비한다. 라이선스 비용은 첫 번째 비용이지 총비용이 아니다.

실제 사례: ARR 5,000만 달러 SaaS 고객의 의사결정을 도왔다 — 48.7만 달러 Salesforce 스택 vs 31.2만 달러 커스텀 개발

2025년 3분기, ARR 5,000만 달러 규모의 B2B SaaS 고객사가 우리에게 물었다. 기존 Salesforce + Tableau + Outreach 스택을 확장할 것인가(추정 5년 TCO 48.7만 달러), 아니면 Next.js + Postgres + 자체 파이프라인 도구 위에 커스텀 매출 운영 플랫폼을 개발할 것인가(추정 5년 TCO 31.2만 달러). 우리가 실제로 그들과 함께 짚어본 항목별 계산, 왜 31.2만 달러짜리 '더 저렴한' 선택지가 그들에게 잘못된 답이었는지, 그리고 그들이 대신 무엇을 출시했는지 공개한다.

헤드라인 질문은 이분법적으로 보였다. SaaS 프리미엄을 계속 내느냐, 더 저렴한 것을 개발하느냐. 하지만 항목별 내역은 다른 이야기를 했다.

서류상으로는 개발이 17.5만 달러를 이겼다. 하지만 추천은 반대 방향으로 갔다.

왜 '더 저렴한' 커스텀 개발이 그들에게 잘못됐는가: 그들은 0.5 FTE의 유지보수를 무기한 흡수할 수 있는 시니어 엔지니어링 역량이 없었다. 엔지니어링 조직은 이미 핵심 제품을 출시하고 있었다. 시니어 역량의 10~15%를 향후 5년간 매출 운영 유지보수에 배정한다는 건, 제품 로드맵을 늦추거나 인력을 채용하는 것(흡수 역량이 아닌 시장 가격의 실제 채용을 고려하면 실질 Build TCO는 80만 달러를 넘긴다) 중 하나를 의미했다. '저렴한' 숫자는 공짜 엔지니어를 가정했다. 엔지니어는 절대 공짜가 아니다.

우리가 실제로 출시한 것: Blend였다. Salesforce를 시스템 오브 레코드로 유지한다. Salesforce가 깔끔하게 모델링하지 못하는 4개 워크플로를 위해 얇은 커스텀 매출 운영 레이어(초기 8.5만 달러, 지속 비용 거의 0)를 구축한다. 5년 순 TCO는 약 42만 달러로 두 헤드라인 숫자 사이에 착지했고, 그들은 실제로 필요한 워크플로를 손에 넣었다. 11주 만에 출시했고, 신규 채용도, 로드맵 지연도 없었다.

18개월 후: 커스텀 레이어는 여전히 프로덕션에서 돌아가고, Salesforce 재계약은 잡음 없이 진행됐으며, 엔지니어링 팀은 초기 구축 이후 매출 운영 유지보수로 컨텍스트를 다시 전환할 필요가 없었다. 최종 판단: Blend가 정답이었던 이유는, Build 셈법이 무시했던 엔지니어링 역량 제약을 존중했기 때문이다.

숫자는 컨설팅 계약에 따라 익명화 및 반올림 처리했다. 비용은 2025~2030년 기간을 가정한다. Salesforce 가격은 2025년 8월 이후 정가 인상을 반영한다. AI 코딩 에이전트 생산성 향상(2025년 3분기 기준선)은 이미 31.2만 달러 엔지니어링 견적에 반영되어 있다. 엔지니어 완전부담 23만 달러 = BLS 2024 기준 미국 해안가 중위값 + 복리후생 30% + 간접비 25%, 지역별 ±30% 조정. 우리는 엔지니어링 에이전시다. 이것은 우리 자신의 상업적 이익에 반하는 실제 추천이었다.

AI가 2026년 개발 vs 구매 셈법을 어떻게 바꿨나

교차점(crossover point)이 움직였다. AI 코딩 에이전트는 2026년 우리 고객 작업 전반에 대한 내부 측정에서 기능당 시니어 엔지니어링 시간을 40~60% 압축했다. 즉, 2023년에 돌린 개발 견적은 이제 실질적으로 틀렸다. Gartner는 2028년까지 기업 소프트웨어 엔지니어의 75%가 AI 코드 어시스턴트를 사용할 것으로 전망하는데, 이는 2023년의 10%에서 오른 수치이며, 우리 파이프라인 데이터는 이미 그 채택의 대부분이 예정보다 앞서 진행되고 있음을 반영한다.

세 가지 구체적인 변화:

• 범위를 고정하면 18개월짜리 커스텀 개발이 이제 68개월 만에 출시된다. 위의 사례 연구 Blend는 11주 만에 출시됐다. 같은 범위라면 2023년에는 1820주가 걸렸을 것이다.
• 사내 도구용 팀 규모가 줄었다. 우리는 2년 전엔 엔지니어 5명이 필요했던 개발을 이제 일상적으로 2명 포드로 운영하는데, Cursor나 Claude Code 같은 AI 코딩 에이전트가 과거 미드레벨 역량을 잡아먹던 보일러플레이트를 흡수하기 때문이다.
• 사례 연구 고객사의 31.2만 달러 개발 견적은, AI 네이티브 엔터프라이즈 소프트웨어 개발이 기본 업무 모드가 되기 전인 2023년의 동일 견적보다 약 30% 낮았다.

솔직한 반론: AI는 개발 비용을 줄이지만, SaaS 벤더가 기능을 출시하는 데 드는 비용도 줄인다. 벤더 가격 압박은 실재하며, 일부 SaaS 가격은 내려갈 것이고, 교차점 이동이 완전히 한쪽 방향인 것만은 아니다. 그럼에도 방향성 효과는 여전히 개발(특히 Blend)에 유리한데, 사내 엔지니어링 처리량이 AI와 함께 복리로 증가하는 속도가 벤더 가격 변동보다 빠르기 때문이다.

흔한 의사결정 함정 (가성비 착각, 매몰비용, NIH 증후군, 벤더 낙관주의)

우리가 반복해서 보는, 판단을 그르치는 네 가지 함정:

1. 가성비 착각(False economy). 5년 TCO를 무시하고 더 저렴한 1년 차 숫자를 고르는 것. 위 사례 연구가 하마터면 이쪽으로 갈 뻔했다. 1년 차 가격표는 모든 경로에서 청구서의 가장 작은 부분이다.
2. 매몰비용(Sunk cost). 마이그레이션이 비싸 보여서 이미 한계를 넘긴 SaaS에 머무는 것. 마이그레이션은 보통 잘못된 도구를 3년 더 쓰는 것보다 저렴하다. 계산해보라.
3. NIH(Not Invented Here) 증후군. 엔지니어링 팀이 문제를 흥미롭게 여긴다는 이유로 구매해야 할 것을 개발하는 것. CRM은 흥미롭지 않다. 결제 처리기도 흥미롭지 않다. 구매하라.
4. 벤더 낙관주의. 통합 비용 없이 벤더 데모의 모든 줄이 당신의 환경에서 작동할 거라 믿는 것. 데모는 최선의 경우다. 당신의 경우는 더 어렵다. 비교하기 전에 데모를 30% 할인하라.

우리가 보는 가장 비싼 실수: 더 저렴한 1년 차 숫자를 고르고 5년 탈출 비용을 무시하는 것.

Techsy가 개발 vs 구매 평가를 진행하는 방식

Techsy는 커스텀 엔터프라이즈 플랫폼을 구축하고, SaaS를 기존 스택에 통합하며, B2B 고객을 위해 COTS 평가에 대한 기술 실사(듀 딜리전스)를 수행한다. 업무는 이 세 가지에 대략 40/30/30으로 나뉜다.

Techsy의 개발 vs 구매 평가는 이렇게 진행된다. 1시간 디스커버리 콜로 워크플로 범위를 잡고, 공유 스프레드시트에서 12점 루브릭을 함께 실시간으로 돌리고, 1주일 안에 TCO 모델을 전달하며, 'SaaS를 구매하세요, 우리를 고용하지 마세요'라고 말할 수도 있는 서면 추천을 보낸다. 우리의 최근 3건 평가: 1건은 개발 추천, 1건은 구매 추천, 1건은 블렌드 추천이었다. 우리에겐 할당량이 없다. 더 넓은 엔터프라이즈 AI 전환을 큰 그림으로 생각하고 있다면, 평가가 보통 올바른 출발점이다. 무료 30분 개발 vs 구매 평가 예약하기.

자주 묻는 질문

소프트웨어에서 개발, 구매, 파트너의 차이는 무엇인가?

구매는 기존 SaaS나 COTS 소프트웨어를 라이선스하는 것을 뜻한다. 개발은 자체 엔지니어로 사내에서 커스텀 소프트웨어를 개발하는 것을 뜻한다. 파트너는 에이전시나 계약자를 고용해 당신이 소유하는 독점 소프트웨어를 만드는 것을 뜻한다. Gartner는 이를 Buy/Build/Blend로 재구성하는데, Blend는 범용 워크플로용 라이선스 COTS와 차별화된 워크플로용 커스텀 코드를 결합하며, 현재 기업용 소프트웨어 지출의 76%를 포괄한다.

언제 구매 대신 소프트웨어를 개발해야 하나?

세 가지 조건이 충족될 때 개발하라. 해당 역량이 고객이 당신을 선택하는 경쟁 차별화 요소이고, 로드맵을 늦추지 않으면서 5년 이상 이를 소유할 수 있는 시니어 엔지니어링 역량이 있으며, 해당 사용자 수 기준 5년 SaaS TCO가 커스텀 개발 TCO를 최소 2배 이상 초과할 때. 셋 중 하나라도 빠지면, 정직한 셈법으로는 블렌드나 구매가 거의 항상 이긴다.

5년 기준으로 SaaS 구매가 커스텀 개발보다 저렴해지는 때는?

해당 워크플로 사용자가 약 100명 미만이고, 역량이 범용화되어 있으며(CRM, 이메일, 회계, 옵저버빌리티), 90일 이내에 가동이 필요할 때 구매가 TCO에서 이긴다. 이 임계값 아래에서는 연간 가격 인상을 감안해도 SaaS 구독료가 완전부담 엔지니어링 + 유지보수 + 인프라 + 기회비용보다 낮게 착지한다.

Gartner는 개발 vs 구매를 어떻게 말하는가?

Gartner는 이분법적 프레이밍을 거부하고 Buy/Build/Blend라는 세 가지 모델을 사용한다. 그들의 데이터에 따르면 현재 기업용 소프트웨어 지출의 76%가 블렌디드 스택(라이선스 COTS + 커스텀 확장)으로 흘러가며, 순수 개발이나 순수 구매가 아니다. Gartner는 또한 기업들이 초기 계산에서 실제 TCO의 50~70%를 놓친다고 보고하는데, 대부분 통합, 관리 FTE 배분, 탈출 비용 항목에서 발생한다.

개발 vs 구매는 죽었나?

이분법적 프레이밍은 죽었다. 세 가지 선택지는 죽지 않았다. 질문을 '개발 vs 구매'라 부르는 것은, 대부분의 기업이 결국 블렌딩을 한다는 사실을 가린다. 범용 워크플로는 SaaS로, 차별화된 워크플로는 커스텀으로, 그 사이는 접착제로 잇는다. 이 의사결정은 살아있고 보이는 것보다 어렵다. 이제는 한쪽을 고르는 게 아니라 분할 지점을 고르기 때문이다. Buy/Build/Blend로 프레이밍하면 셈법이 깔끔해진다.

AI 코딩(Cursor, Claude Code)은 2026년 개발 vs 구매 셈법을 어떻게 바꾸나?

Cursor나 Claude Code 같은 AI 코딩 에이전트는 2026년 고객 개발 전반에 대한 우리 측정에서 기능당 시니어 엔지니어링 시간을 4060% 줄였다. 이는 교차점을 움직인다. 2023년에는 채산이 맞지 않던 개발이 이제 맞는다. Gartner는 2028년까지 기업 소프트웨어 엔지니어의 75%가 AI 코드 어시스턴트를 사용할 것으로 전망하므로, 이 변화는 일시적이 아니라 지속적이다. 18개월짜리 개발이 이제 일상적으로 68개월 만에 출시된다.

커스텀 엔터프라이즈 소프트웨어의 전형적인 연간 유지보수 비용은?

업계 경험칙은 초기 개발 비용의 연 1520%, 지속적이다. 30만 달러짜리 커스텀 플랫폼은 유지보수(버그 수정, 의존성 업데이트, 보안 패치, 소규모 기능 개선)로 연 4.5만6만 달러를 예산에 잡아야 한다. 여기에는 대규모 기능 작업이 제외되며, 이는 신규 개발로 취급된다. 유지보수 과소 예산은 커스텀 개발 TCO 모델에서 가장 흔한 단일 실수다.

엔터프라이즈 SaaS 구매의 숨은 비용은?

대부분의 데모가 건너뛰는 여섯 가지 숨은 비용: 벤더 락인(전환에 618개월), 커스터마이징 및 변경 요청 비용(시간당 200500달러), 조직 성장에 따른 시트당 연 715% 증가, 통합 비용(연결 시스템당 2만10만 달러), 탈출 및 마이그레이션 비용(엔지니어링 36개월), 사용량과 무관한 연 715% 가격 인상. 1년 차 라이선스 비용은 실제 5년 비용의 30~40%를 좀처럼 넘지 않는다.

소프트웨어의 총소유비용(TCO)이란?

TCO는 소프트웨어 경로의 라이선스 또는 개발, 구현, 교육, 통합, 지속 유지보수, 관리 FTE 배분, 기회비용, 그리고 결국 떠날 때의 탈출/마이그레이션 비용을 포함한 5년 총비용이다. Gartner 리서치에 따르면 기업들은 보통 초기 계산에서 실제 TCO의 50~70%를 놓친다. 확정한 후에가 아니라, 확정하기 전에 계산하라.

커스텀 엔터프라이즈 소프트웨어 개발을 정당화하려면 회사가 얼마나 커야 하나?

대략적 규칙: ARR 약 1,000만 달러 이상 또는 해당 워크플로 사용자 약 50명 이상. 이 임계값 아래에서는 SaaS 구독이 거의 항상 이기는데, 엔지니어링과 유지보수를 충분한 사용량에 걸쳐 상각할 수 없기 때문이다. 이를 넘으면, 특히 워크플로가 경쟁 위치의 핵심일 때 셈법이 개발이나 블렌드에 유리해지기 시작한다. 2026년 AI 코딩 에이전트는 그 임계값을 2023년 기준선 대비 20~30% 낮춘다.

저자 소개

Mert Batur Gurbuz는 Techsy.io의 공동 창업자로, 팀은 B2B 고객을 위해 AI 에이전트, 자동화 시스템, 음성/SDR 파이프라인을 구축한다. 그는 University of Birmingham에서 공부하며 Techsy 팀이 실제 프로덕션에서 사용하는 LLM 도구 스택에 대해 글을 쓴다. 공동 창업자, Techsy.io, University of Birmingham. LinkedIn에서 연결하자.

결론

이 글에서 한 가지만 기억한다면: 추천을 신뢰하기 전에, 읽는 모든 프레임워크의 이해관계를 먼저 파악하라. 벤더는 벤더 조언을 한다. 에이전시는 에이전시 조언을 한다. 당신의 CFO는 CFO 조언을 한다. 세 가지를 읽고, 겹치는 부분을 찾아, 그것을 신뢰하라.

• 회의에서 12점 루브릭을 실시간으로 돌려라. 논의를 2시간에서 20분으로 줄여준다.
• 5년 TCO를 정직하게 계산하라. 1년 차 가격표는 절대 답이 아니다.
• 점수가 30~45에 착지하면 Blend를 기본값으로 삼아라. 대부분의 기업이 어차피 여기에 도달한다.

판단에 대한 제3의 시선이 필요하다면, 무료 30분 개발 vs 구매 평가를 예약하라. 그것이 정답이라면 SaaS를 사라고 말해줄 것이다. 그런 적 있다. 또 그럴 것이다.