소프트웨어 자체 개발 대 구매: 비즈니스 리더를 위한 비용 및 리스크 프레임워크

귀사가 새로운 운영 플랫폼을 평가한 지 3주째입니다. 두 벤더가 화려한 제안서를 보내왔습니다. 엔지니어링 책임자는 계속 "몇 달이면 우리가 직접 만들 수 있습니다"라고 말합니다. CFO는 금요일까지 숫자를 원합니다. 그리고 마음 한구석에는 지난번 어떤 팀이 "몇 달"을 약속하고 18개월간의 재작성 프로젝트로 사라져버린 기억이 남아 있습니다. 대부분의 자체 개발 대 구매 결정은 사실 바로 이 순간에 내려집니다. 스프레드시트가 아니라 어깨를 으쓱하며 마감일에 쫓겨서 말입니다. 바로 그 때문에 그토록 많은 결정이 잘못됩니다.

자체 개발 대 구매 문제는 기술적 결정처럼 들리지만, 실제로는 비즈니스 베팅입니다. 귀사는 앞으로 3년에서 5년 동안 어느 한 경로가 고객과 운영에 더 잘 봉사할 것이라는 믿음에 시간, 비용, 조직의 집중력을 걸고 있습니다. 제대로 선택하면 소프트웨어는 배경으로 사라지고 비즈니스는 성장합니다. 잘못 선택하면 앞으로 2년 동안 맞지 않는 플랫폼과 싸우거나, 아무도 소유하고 싶어 하지 않는 코드베이스를 유지 보수하며 시간을 보내게 됩니다.

잘못된 제품을 구매한 회사들을 위해 맞춤형 시스템을 구축하고, 자체 개발을 과도하게 진행한 회사들을 위해 기성품 도구를 통합해 온 수년의 경험을 통해, 저희는 이 결정이 대개 다섯 가지 질문으로 귀결된다는 사실을 발견했습니다. 그중 어느 것도 기술적인 질문이 아닙니다. 모두 회사가 실제로 무엇을 하는지에 대해 정직할 준비가 된 비즈니스 리더가 답할 수 있는 질문들입니다.

질문 1: 이 프로세스는 경쟁 우위의 원천입니까, 아니면 기본 요건입니까?

여기서부터 시작하십시오. 모든 비즈니스는 수십 가지 프로세스 위에서 운영됩니다. 급여, 회계, 이메일, 고객 지원, 재고 추적, 영업 파이프라인 관리 등입니다. 이 프로세스 중 일부는 귀사가 이기는 방식입니다. 그러나 대부분은 단순히 귀사가 운영되는 방식일 뿐입니다.

어떤 프로세스가 기본 요건이라면 — 즉 업계의 모든 경쟁사가 대체로 동일한 방식으로 수행하는 것이라면 — 소프트웨어를 구매하십시오. 회계에서 QuickBooks를, 이메일에서 Gmail을 능가하는 혁신은 불가능합니다. 이러한 카테고리에 특화된 벤더들은 귀사가 아직 생각조차 못 한 기능들을 다듬는 데 10년과 수억 달러를 투자해 왔습니다. 자체 구축을 시도하는 것은 야망이 아니라 엔지니어링 팀에 대한 세금이며, 실제로 귀사를 차별화하는 작업으로부터의 주의 분산입니다.

그러나 어떤 프로세스가 진정으로 귀사가 이기는 방식이라면 — 물류 회사가 경쟁사보다 8% 낮은 가격을 제시할 수 있게 해주는 가격 책정 엔진, 마켓플레이스의 핵심인 매칭 알고리즘, 대출 업체가 경쟁사가 거절한 대출을 승인할 수 있게 해주는 심사 모델이라면 — 계산이 달라집니다. 기성 소프트웨어는 다른 모두를 위해 만들어졌기 때문에 귀사를 다른 모두와 똑같아 보이게 만들 것입니다. 이러한 경우 맞춤형 소프트웨어는 비용이 아닙니다. 그것이 곧 제품입니다.

테스트는 간단합니다. 이 프로세스를 경쟁사에게 설명한다면 그들이 부러워하겠습니까? 그렇다면 맞춤형 투자를 받을 자격이 있습니다. 그들이 어깨를 으쓱한다면 도구를 구매하십시오.

저희는 한 번 중견 유통업체와 일한 적이 있는데, 그들은 "아무도 우리 워크플로를 이해하지 못한다"며 맞춤형 창고 관리 시스템이 필요하다고 주장했습니다. 두 번의 워크숍을 거친 후, 그들의 워크플로는 유사한 규모의 다른 유통업체와 90% 동일하다는 것이 드러났습니다. 나머지 10% — 공급업체 계약과 연결된 특수한 반품 프로세스 — 가 진짜 차별화 요소였습니다. 정답은 맞춤형 WMS를 구축하는 것이 아니었습니다. 검증된 WMS를 구매하고 반품 프로세스를 처리하며 그것과 통합되는 작은 맞춤형 모듈을 구축하는 것이었습니다. 총비용은 완전 맞춤형 구축의 약 5분의 1이었고, 18개월이 아닌 4개월 만에 가동에 들어갔습니다.

질문 2: 기반이 되는 프로세스는 얼마나 안정적이며, 실제로 얼마나 잘 이해하고 계십니까?

맞춤형 소프트웨어는 구축 당시 존재했던 요구사항의 화석입니다. 그 요구사항이 6개월마다 바뀐다면 소프트웨어는 유지 보수의 트레드밀이 됩니다. 시작할 때 요구사항을 완전히 이해하지 못했다면, 소프트웨어는 귀사의 가장 초기의, 가장 혼란스러운 가정들의 기념비가 됩니다.

기성 제품은 이러한 변동성을 대신 흡수해 줍니다. 세법이 바뀌면 회계 벤더가 업데이트를 배포합니다. 새로운 결제 방식이 주류가 되면 e-커머스 플랫폼이 그것을 추가합니다. 다른 누군가가 움직이는 부품들에 대해 걱정하는 대가로 구독료를 지불하는 것입니다.

맞춤형 소프트웨어를 구축하는 것은 프로세스가 안정적이고 잘 이해되어 있을 때, 또는 변동성 자체가 귀사의 경쟁 우위이고 로드맵을 통제해야 할 때 의미가 있습니다. 비즈니스가 아직 프로세스가 무엇인지조차 파악하고 있을 때는 거의 의미가 없습니다. "만들면서 반복하겠다"는 애자일하게 들리지만, 실제로는 요구사항을 힘든 방식으로 발견하는 대가를 지불하는 것을 의미합니다. 새로운 것을 배울 때마다 리팩터링해야 하는 코드베이스와 함께 말입니다.

유용한 직관적 점검: 운영팀의 누구도 정정하지 않을 정도로, 모든 예외 사례를 포함하여 이 프로세스가 오늘날 어떻게 작동하는지 정확히 두 페이지 분량으로 설명할 수 있습니까? 그렇지 않다면 그 프로세스에 대해 구축할 만큼 충분히 이해하지 못하고 있는 것입니다. 유연한 것을 구매하고, 그 위에서 1년간 프로세스를 운영하고, 현실이 실제로 무엇이 중요한지 가르쳐준 후에 질문을 다시 검토하십시오.

질문 3: 정가가 아닌 5년간의 정직한 총비용은 얼마입니까?

대부분의 자체 개발 대 구매 분석이 궤도를 이탈하는 지점입니다. 팀들은 SaaS 제품의 연간 구독료를 맞춤형 구축을 위한 일회성 개발 견적과 비교하고, 맞춤형 구축이 첫해에 더 저렴하다는 것을 알아차리고, 승리를 선언합니다. 그러다가 2년 차가 찾아옵니다.

맞춤형 소프트웨어에는 초기 견적에 거의 포함되지 않는 세 가지 비용 항목이 있습니다. 첫째는 지속적인 유지 보수입니다. 버그 수정, 보안 패치, 의존성 업그레이드, 인프라 비용, 그리고 코드베이스를 이해하며 쉽게 대체할 수 없는 엔지니어들입니다. 합리적인 경험 법칙은 연간 유지 보수 비용이 원래 구축 비용의 15%에서 25%에 이르며, 매년, 영원히 지속된다는 것입니다. 둘째는 진화입니다. 버전 1에서 출시하지 못한 기능, 나중에 도입한 도구와의 통합, 원래 UI가 낡아 보이기 시작할 때의 재설계입니다. 셋째는 기회비용입니다. 엔지니어링 팀이 내부 도구를 유지 보수하는 데 쓰는 매 시간은 실제로 수익을 창출하는 소프트웨어에 쓰지 못하는 시간입니다.

기성 소프트웨어에도 자체적인 숨겨진 비용이 있습니다. 성장에 따라 고통스럽게 확장되는 좌석당 라이선스. 도구를 스택의 나머지 부분과 연결하기 위한 통합 작업. 표준 구성이 딱 맞지 않을 때의 커스터마이징 수수료. 교육 비용. 벤더가 가격을 인상하거나 인수될 때의 전환 비용. 그리고 통제하지 못하는 플랫폼 위에 비즈니스 프로세스를 구축하는 것의 전략적 비용입니다.

엄밀한 5년 총소유비용 분석은 대개 이렇게 진행됩니다. 구매 경로의 경우, 연간 구독료에 5를 곱하고, 통합 및 커스터마이징 비용을 더하고, 교육 비용을 더하고, 가격 인상에 대한 20% 버퍼를 더하고, 벤더가 사용 불가능해질 경우 이전할 예상 비용을 더합니다. 구축 경로의 경우, 초기 개발 견적에 1.5를 곱하여 고전적인 과소평가를 반영하고, 유지 보수 및 진화를 위해 연간 20%를 더하고, 이를 소유할 엔지니어들의 전액 부담 비용을 더합니다. 그런 다음 진지한 표정으로 두 숫자를 비교하십시오.

대부분의 경우, 잘 구축된 맞춤형 시스템을 가정할 때 구매 옵션이 처음 3년간 더 저렴하고 구축 옵션이 4년과 5년 차에 더 저렴합니다. 그러나 더 저렴한 것이 요점이 아닙니다. 요점은 약속하기 전에 실제 숫자를 보는 것입니다.

질문 4: 이 프로젝트는 실제로 얼마나 많은 리스크를 감당할 수 있습니까?

모든 소프트웨어 프로젝트는 리스크를 안고 있습니다. 맞춤형 구축은 초과 비용의 리스크, 작동하지 않는 것을 출시할 리스크, 그것을 이해하던 엔지니어들을 잃을 리스크, 그리고 완전히 잘못된 것을 구축할 리스크를 안고 있습니다. 기성품 구매는 벤더 종속의 리스크, 사용하지 않는 기능에 대한 비용 지불의 리스크, 더 이상 맞지 않는 워크플로를 변경할 수 없는 리스크, 그리고 벤더가 폐업하거나 방향을 바꿀 리스크를 안고 있습니다.

질문은 어떤 리스크를 감당할 수 있느냐입니다. 제품-시장 적합성을 입증하기 위해 달리는 자금이 풍부한 스타트업은 핵심 제품 자체 외에는 어떤 것에도 18개월간의 맞춤형 구축을 감당할 수 없습니다. 규제를 받는 금융 기관은 내년에 데이터 거주 정책을 바꿀 수 있는 SaaS 제품에서 컴플라이언스 워크플로를 실행할 여유가 없습니다. 소규모 IT 팀을 가진 중견 제조업체는 맞춤형 ERP의 유일한 유지 보수자가 될 여유가 없습니다.

유용한 프레이밍은 프로젝트가 잘못되는 것을 상상해 보는 것입니다. 맞춤형 구축이 12개월 지연되고 비용이 두 배가 된다면 비즈니스가 살아남을 수 있습니까? SaaS 벤더가 가격을 두 배로 올리거나 제품 라인을 폐쇄한다면, 얼마나 빨리 마이그레이션할 수 있습니까? 최악의 시나리오가 감당 가능한 경로가 대개 옳은 경로입니다. 종이 위의 기대 시나리오가 약간 더 나빠 보이더라도 말입니다.

저희가 자주 권장하는 한 가지 패턴이 있습니다. 리스크가 있고 차별화되지 않은 80%는 구매하고, 진정으로 귀사를 차별화하는 20%만 구축하는 것입니다. 이 하이브리드 접근법은 신뢰성이 가장 중요한 곳에서 검증된 제품의 신뢰성과 속도를 제공하고, 맞춤형이 실제로 보상을 가져오는 곳에 맞춤형 개발의 값비싸고 위험한 작업을 예약합니다. 둘 사이의 통합은 실제 작업이지만, 경계가 있는 작업입니다. 그리고 이는 가장 흔한 두 가지 실패 모드로부터 귀사를 보호합니다. 모든 것을 구축하고 아무것도 출시하지 못하는 것, 또는 모든 것을 구매하고 업계의 다른 모든 회사와 똑같아 보이는 것입니다.

질문 5: 이 소프트웨어를 소유할 조직적 역량이 있습니까?

이 질문이 어떤 기술적 도전보다도 많은 맞춤형 소프트웨어 프로젝트를 죽입니다. 소프트웨어를 구축하는 것은 쉬운 부분입니다. 향후 10년간 그것을 소유하는 것이 어려운 부분입니다.

맞춤형 소프트웨어를 소유한다는 것은 그것을 이해하는 엔지니어, 로드맵의 우선순위를 정하는 제품 관리자, 인터페이스를 발전시키는 디자이너, 그것을 테스트하는 QA, 그리고 인프라를 운영하는 운영팀을 직원으로 두는 것을 의미합니다. 이는 정당화할 새로운 기능이 눈에 보이지 않을 때조차 매년 유지 보수 예산을 편성하는 것을 의미합니다. 이는 주요 제품 출시 중간에 치명적인 버그가 나타났을 때 트레이드오프를 결정하는 것을 의미합니다. 그리고 이는 원래 팀이 떠날 때, 세상 어디에도 존재하지 않는 코드베이스를 배우도록 새로운 누군가에게 비용을 지불해야 함을 받아들이는 것을 의미합니다.

직원 200명 미만의 대부분의 기업은 이 비용을 극적으로 과소평가합니다. 그들은 소프트웨어가 일단 구축되면 그냥 실행될 것이라고 상상합니다. 그렇지 않습니다. 소프트웨어는 기념비가 아니라 정원입니다. 끊임없이 관리하지 않으면 무성해지고, 안전하지 않게 되고, 결국 사용할 수 없게 됩니다.

기성 소프트웨어는 이 소유 비용을 벤더에게 외부화합니다. 그것이 지불하는 비용의 큰 부분입니다. 구독료는 단순히 소프트웨어에 대한 것이 아닙니다. 수백 명의 엔지니어가 귀사를 대신하여 그것을 살아 있게 유지하고 있다는 사실에 대한 것이며, 뒤에 고아가 된 코드를 남기지 않고 떠날 수 있다는 사실에 대한 것입니다.

조직이 출시 후 소프트웨어를 소유할 전담 소규모 팀을 보유하고 있지 않고, 현실적으로 채용할 수 없다면, 맞춤형으로 구축하지 마십시오. 잘 구축된 시스템조차 소유자 없이는 부패하며, 비즈니스를 운영하는 부패하는 시스템은 슬로우 모션 위기입니다.

실용적 의사결정 프레임워크

다섯 가지 질문을 함께 모으면 작동하는 프레임워크가 됩니다. 간단한 2×2 매트릭스를 그리십시오. 한 축에는 프로세스가 경쟁 우위에 얼마나 중심적인지 표시합니다. 다른 축에는 프로세스가 얼마나 안정적이고 잘 이해되어 있는지 표시합니다.

높은 전략적 가치, 높은 안정성: 이것이 맞춤형의 최적 지점입니다. 무엇이 필요한지 알고 있으며, 필요한 것은 진정한 우위입니다. 그것을 구축하고, 소유하고, 투자하십시오.

높은 전략적 가치, 낮은 안정성: 이것이 위험 지대입니다. 그것이 중요하다는 것은 알지만, 아직 어떤 모습이어야 하는지는 모릅니다. 가장 유연한 도구를 구매하고, 12개월에서 18개월 동안 그 위에서 운영하고, 프로세스가 안정된 후에 구축 질문을 다시 검토하십시오.

낮은 전략적 가치, 높은 안정성: 이것은 교과서적인 구매 영역입니다. 회계, HR, 이메일, 표준 CRM입니다. 잘 지원되는 제품을 선택하고, 통합하고, 다시는 생각하지 마십시오.

낮은 전략적 가치, 낮은 안정성: 이는 소프트웨어로 문제를 해결하려는 충동을 억제해야 하는 곳입니다. 실제 투자를 받을 만한지 알 만큼 충분히 이해할 때까지 프로세스, 스프레드시트, 또는 사람으로 해결하려고 시도하십시오.

비용, 리스크, 소유권 질문을 이 매트릭스 위에 겹쳐 놓으면 대개 답이 명확해집니다. 명확하지 않을 때는 그 모호함 자체가 정보입니다. 이는 프로세스가 논쟁을 정당화할 만큼 중요하지 않다는 것을 의미하며, 가장 저렴한 합리적 옵션을 구매하고 더 중요한 결정으로 넘어가야 함을 의미합니다.

좋은 조달과 좋은 제품 엔지니어링의 공통점

저희가 함께 일하는 최고의 소프트웨어 리더들은 자체 개발 대 구매를 일회성 판단이 아니라 지속적인 포트폴리오 결정으로 취급합니다. 그들은 내부 도구를 정기적으로 감사하고 각 도구가 여전히 받고 있는 투자를 받을 만한지 묻습니다. 그들은 벤더 계약을 정기적으로 감사하고 그중 어느 것이 맞춤형 대체를 정당화할 만큼 중요해졌는지, 또는 더 저렴한 것으로 대체될 만큼 사소해졌는지 묻습니다. 그들은 두 가지 게으른 기본값에 저항합니다. "우리 팀이 똑똑하니까 이것을 구축해야 한다"와 "구축이 너무 어려우니까 이것을 구매해야 한다"입니다.

정직한 답은 거의 항상 지루한 답입니다. 상품은 구매하고, 우위는 구축하고, 신중하게 통합하고, 비즈니스가 변화함에 따라 매년 조합을 다시 검토하십시오. 소프트웨어에서 대부분의 경쟁 우위는 단 하나의 영웅적 결정에서 오는 것이 아니라, 10년 동안 몇 번이고 올바른 작은 결정을 내리는 규율에서 옵니다.

특정 자체 개발 대 구매 결정을 진행 중이며 비용 모델이나 통합 아키텍처에 대한 두 번째 시각이 필요하다면, 이는 경험 많은 파트너가 도울 수 있는 정확히 그런 종류의 작업입니다 — 구축이나 구매를 판매하기 위해서가 아니라, 약속하기 전에 트레이드오프를 명확히 볼 수 있도록 돕기 위해서입니다. 최고의 결과는 어느 방향으로 가든 3년 차에도 여전히 만족할 결정입니다.