BLOG
Y2K를 개선하기 위해 많은 양의 자원과 예산을 배정하고 이에 잇달아 발생한 닷컴 버블 붕괴에 대한 두려움이 의도치 않은 결과를 초래했다고 생각합니다. 많은 기업들이 제품을 구축할 때 매우 보수적인 태도를 보이며 가능하면 기성품부터 사는 경향으로 변했습니다. 오늘날 다수의 기업 IT 팀은 고객의 요구를 예측하고 비즈니스를 차별화할 수 있는 무언가를 구축하기 보다는 RFI(정보 요청), RFP(제안 요청), 베이크 오프, 복잡한 피벗 테이블로 철저한 가중 스코어 카드를 작성하는 등의 구매 프로세스에 더 익숙합니다.
저(원문의 저자: Ishit Vachhrajani)는 기업 임원들이 이 ‘구축’을 선호해야만 한다고 말하고자 하는 것은 아닙니다. 저 또한 세계 금융 시스템, HCM(Human Capital Management) 솔루션, CRM(고객 관계 관리) 도구, 광고 판매 및 트래픽 시스템 등에 관련하여 여러 번 ‘구축’ 대신 ‘구매’를 하는 선택을 했습니다. 저는 단지 대부분의 기업이 ‘구축’을 최후의 수단으로만 여기며 ‘구매’를 당연시 여기는 생각에 반론을 제기하고자 합니다.
클라우드 시대에는 비용, 노력, 시간 측면에 있어 ‘구축’에 대한 기본 개념이 바뀌었습니다. 이제 우리는 오랜 논쟁을 다시 검토하고 ‘구축’ 대 ‘구매’에 대해 새롭게 바라봐야 할 때 입니다.
‘구축’이 계속 진행중인 와중에도 ‘구매’는 항상 빠릅니다?
보통 ‘구매’를 더 빠르다고 판단하는 이유가 구현 시점부터 시간을 계산하기 때문입니다. 우리는 요구 사항 수집, 공급 업체 평가, 격차 분석, 데모, 성과 기록표, 협상 및 조달에 소요되는 수 개월, 때로는 수 년의 시간을 종종 간과하곤 합니다. 제가 일한 기간 동안, 저는 적어도 1년 이상 지속된 3개의 큰 “평가 및 판단”과정에 참여했었습니다. 어떤 때는 두 가지 벤더의 제품 중에서 선택을 해야만 해서 옵션을 무작위로 고른 경우라 하더라도 적어도 50%의 확률로 올바른 결정을 내릴 수 있었습니다.
많은 기업들이 고객 피드백을 바탕으로 신속하게 구축, 테스트 및 피벗 할 수 있는 Agile, DevOps 및 소규모 분산 팀을 채택하고 있습니다. 클라우드를 사용하면 빌더는 가치가 높은 차별화된 작업에 즉시 집중할 수 있어, 고객 가치를 창출하지 못한 인프라를 설정하고 관리하는 데 드는 많은 노력을 줄일 수 있습니다. 특히 서버리스는 출시될 때까지의 시간을 크게 단축시켜줍니다.
저희 A+E Networks의 개발 팀은 어느 한 긴 주말 전 금요일에 무서운 전화를 한 통 받았습니다. 바로 화요일까지 안전한 방법으로 전 세계의 사내 전체 회의를 스트리밍할 수 있는 솔루션을 마련하는 것이었습니다. 팀은 주말 동안 내부 포털을 구축, 테스트 및 실행하기 위해 AWS Lambda를 선택했습니다. 솔루션은 이벤트 중에 수백 개의 동시 스트리밍을 지원하도록 확장되었으며 그 후 곧 축소되었습니다. 그것이 ‘민첩성(agility)’입니다. 우리가 ‘구매’ 옵션을 추구했다면 이틀 만에 NDA(비밀 유지 계약)에 서명하는 것 조차 끝냈을 있었을까 생각됩니다.
‘구축’하는 것보다 ‘구매’하는 것이 항상 저렴합니다?
비용을 비교함에 있어 기업은 보통 시판 제품의 라이센스 및 유지 관리를 구매했을 때와 자체적으로 구축 했을 때 소요되는 금액을 비교합니다. 사내 구축 시 견적에는 일반적으로 지금까지의 모범 사례에서 15%~20% 비상 버퍼를 포함합니다. 여기서 종종 간과되는 것은 특정 구현의 요구 사항을 맟추고 타사 상품과 솔루션을 통합하기 위해 추가로 발생하는 제 2의 해결에 관련된 비용입니다.
그 후 비즈니스 공급 업체의 업그레이드 주기에 맞추기 위해 지속적인 비용이 발생합니다. 대부분의 프로젝트가 “단순하고 즉시 사용할 수 있는”것을 목표로 시작하더라도 거의 모든 경우가 맞춤형 볼트온(custom bolt-ons) 때문에 엄청난 작업으로 커지게 됩니다. 망가진 통합과 맞춤 작업을 고치고 테스트하기 위해 몇 주에서 몇 달이 걸리게 됩니다. 이러한 이유로 많은 기업이 업그레이드가 늦어지고 그 과정에서 상당한 기술적 부채를 누적하게 됩니다.
클라우드를 통해 빌더는 전용 데이터 베이스, 고도의 API를 활용하여 폭넓은 서비스에서 선택 가능한 유연성을 갖춘 종량제 모델을 이용할 수 있게 되었습니다. 예를 들어 A+E 팀은 클라우드 네이티브 서비스를 활용한 솔루션을 데이터베이스에서 애플리케이션 계층으로 구축하여, 타사 제품에서 마이그레이션 했습니다. 그 결과, 고객은 비용을 월별 수천 달러에서 5달러로 절감할 수 있었습니다.
우리는 아마존(또는 다른 기술 회사)이 아닙니다. 그러므로 우리는 ‘구축’이 아닌 ‘구매’를 해야 합니다?
여러 업계에서 이러한 주장을 자주 들었습니다. 예를 들어, 우리는 미디어, 자동차 제조업체 또는 CPG 회사이므로 소프트웨어를 구축하는 대신 새로운 컨텐츠나 자동차 또는 제품을 만드는 데 투자해야 한다고 말이죠. 러나 이 주장은 소프트웨어뿐만 아니라 일반적인 기술에 대한 요점을 놓치고 있습니다. 비즈니스를 강화하는 고도의 확장 가능한 기술을 보유하면 핵심 제품의 차별화에 도움이 됩니다. 새로운 컨텐츠 또는 자동차를 보다 빠르게 만들 수 있도록 혁신을 가속화할 수 있습니다. 핵심 제품을 보다 빨리 시장에 출시하는 데 드는 비용을 줄이면서 자동화를 통해 효율성을 높일 수 있습니다. 디지털 경제에서 기술은 제품과 서비스를 배포할 수 있는 새로운 방법을 열어주고 이전에는 불가능했던 새로운 시장과 소비자에게 다가갈 수 있는 조력자입니다.
‘구축’과 ‘구매’에 대한 결정은 당신이 누구인지가 아니라 당신이 무엇을 하려고 하느냐에 따라 좌지우지 되어야 합니다.
기술은 더 이상 백 오피스 기능이 아니라 비즈니스 가속화를 위한 차별화의 요소입니다. 빌더를 위한 도구는 클라우드를 통해 더 넓고 깊어 졌을 뿐만 아니라 작업을 위해 특정 목적으로 구축된 특정 도구에 액세스할 수 있습니다. 소규모 분산 팀, Agile 및 DevOps를 갖춘 운영 및 실행 모델은 대규모 투자 실패의 위험을 줄이면서 시장 출시 속도를 크게 단축 시켰습니다. 이제는 ‘구축’과 ‘구매’에 대한 몇 가지 주요 가정을 다시 살펴보고 생각해 볼 때입니다.
원문 URL: https://aws.amazon.com/ko/blogs/enterprise-strategy/time-to-rethink-build-vs-buy/
** 메가존 클라우드 TechBlog는 AWS BLOG 영문 게재 글 중에서 한국 사용자들에게 유용한 정보 및 콘텐츠를 우선적으로 번역하여 내부 엔지니어 검수를 받아서, 정기적으로 게재하고 있습니다. 추가로 번역 및 게재를 희망하는 글에 대해서 관리자에게 메일 또는 SNS 페이지에 댓글을 남겨주시면, 우선적으로 번역해서 전달해드리도록 하겠습니다.