BurnRate는 Blazor로 매출 성공을 촉진하고 있습니다.

.NET 베테랑이자 사람들의 성공을 돕는 데 열정을 가진 노련한 기업가인 Robert McLaws를 만나보세요. 그의 경력 전반에 걸쳐 McLaws는 벤처 자본가(VC)와 그들의 수천억 달러 규모의 투자액이 스타트업의 성공률을 크게 높이는 데 실패하는 과정들을 목격했습니다. VC 투자 50년 후에도 70%가 넘는 기업들이 여전히 모든 성장 단계에서 실패합니다.

McLaws는 이러한 통계에 크게 놀랐습니다. 그래서 그는 설립자와 수익 리더가 고용 프로세스를 체계화하고 스프레드시트 공식을 이용하느라 고생할 필요 없이 자신의 성장 경로를 구체화할 수 있도록 돕기 시작했습니다. 그는 기술이 확장 가능한 성장을 보다 쉽고 정확하게 계획할 수 있는 가치 있고 구체적인 계산을 할 수 있는 기회를 보았습니다.

인간 알고리즘 빌드

몇 년 전 McLaws는 ASP.NET을 사용하여 상업용 부동산 공간에서 재무 분석 제품을 빌드하는 애플리케이션 프레임워크를 구축했습니다. 그는 아파트 단지를 위한 건물 용량 모델을 통해 SaaS 영업 역량 모델과 인적 업무 역량이 회사의 수익 창출 능력에 어떤 영향을 미치는지 심층적으로 분석할 수 있었습니다.

그때 그는 시장 진출 팀을 위한 수익, 수요 및 인력 계획 시스템인 BurnRate에 대한 아이디어를 생각해 냈습니다. McLaws는 직감과 추측에 의존하여 마케팅, 영업 및 고객 성공과 같은 주요 수익 팀의 인력 수준을 결정하는 것은 지속 가능한 성장을 위한 방안이 아니라고 느꼈습니다.

대신 그는 이 과정에 과학적인 요소가 활용되었다고 생각합니다. 그것은 바로 그가 "사람 알고리즘"입니다. 그는 "이 [고객 성공, 마케팅 및 영업] 팀은 처음부터 돈을 조달하는 일을 담당하므로 계산을 올바르게 하고 수익 팀이 해당 자금을 직관적으로 사용할 수 있도록 계산을 쉽게 만들어야 했습니다."

올바른 기술 스택 선택

금융 수학 분야에 대한 McLaws의 경험은 그에게 JavaScript와 같은 부동 소수점 수학을 사용하는 프로그래밍 언어로는 금융 시스템을 빌드하는 데 충분하지 않다는 것을 배웠습니다. 일관되게 검증할 수 있는 신뢰할 수 있는 결과를 제공하려면 이 알고리즘의 기반이 C#에 있어야 합니다.

BurnRate를 시작하기 위해 이전 회사를 떠났을 때 그는 애플리케이션 프레임워크에서 벗어나 새로운 프레임워크를 처음부터 다시 만들어야 했습니다. .NET Core의 첫 번째 릴리스가 막 출시되었으므로 현대 시대를 위해 다시 빌드하기에 완벽한 시기였습니다.

백 엔드는 Azure SQL과 Microsoft Retier가 프로젝트의 쿼리 가능한 API 요구 사항을 처리할 수 있을 만큼 충분히 단순했습니다. .NET Core에서 그의 급성장하는 "사람 알고리즘"은 번개처럼 빠르며 고도로 구조화된 데이터에서 매우 복잡한 계산을 몇 분의 1초 만에 처리할 수 있었습니다.

그러나 회사에서 여러 시나리오를 만들고 시나리오 간에 전환할 수 있는 방식으로 회사 재무 데이터를 구성하려면 예상하지 못한 구조적 깊이가 필요했습니다.

"시나리오, 상위 시나리오, 시간 척도, 계획된 결과와 실제 [결과]를 하나의 모델에 함께 레이어링하는 것만으로도 머리가 복잡했습니다. 몇 달 간의 집중적인 작업과 반복적인 시도가 필요했습니다."라고 그는 말했습니다. McLaws는 올바른 기능을 보장하기 위해 BurnRate가 자체 알고리즘에서 사용하는 단위 테스트의 수는 "아마도 대부분의 다른 회사가 애플리케이션으로 구축하는 것보다 훨씬 더 많을 것이라고 말했습니다. 우리는 기업이 이 플랫폼을 사용하여 전체 비즈니스의 미래에 대한 결정을 내릴 것을 요청하고 있습니다. 이러한 노력을 헛되게 할 수는 없습니다."

BurnRate는 Breakdance라는 전체 오픈 소스 테스트 프레임워크를 빌드하여 단위 테스트 생산성을 높이고 짧은 시간에 보다 일관된 테스트를 작성했습니다.

프런트 엔드는 다양한 과제를 제시했습니다. McLaws는 Webpack, TypeScript 및 Knockout의 조합을 사용하여 BurnRate UI 프로토타이핑을 시작했지만 수많은 장애물에 직면했습니다. 당시 Webpack에는 빌드를 더 쉽게 구성하는 데 도움이 되는 TypeScript 정의가 없었습니다.

"임의의 대상이 무엇이든 될 수 있고 런타임 시 모든 것이 교체될 수 있는 언어인 JavaScript에서는 실패가 기본 설정입니다. 일반적으로 다양한 정신적 고통을 겪어야만 성공할 수 있습니다."라고 McLaws는 말했습니다.

그가 마침내 모든 것을 작동시키고 완전한 기능을 갖춘 첫 프로토타입을 갖게 되었을 때, 팀은 특히 수백 명의 직원이 있는 회사를 위한 채용 계획을 생성하는 과정에서 확장 문제로 어려움을 겪었습니다.

"규모를 조정하고 UI 업데이트와 재계산 및 서버 측을 처리하는 방법을 알아내려고 할 때 우리는 거꾸로 가고 있었습니다."라고 그는 말했습니다. "렌더링을 시도하면서 브라우저에서 점점 더 많은 문제가 발생했습니다."

Blazor가 확장성을 향한 길을 밝힌 방법

Blazor는 이 무렵에 시장에 진입했고 이 기술은 새로운 프런트 엔드 기술이었습니다.

McLaws는 "JavaScript를 최소화한 브라우저의 엔드투엔드 C#에 대한 약속은 너무 매력적이어서 무시할 수가 없었다."라고 말했습니다.

McLaws에 따르면 클라이언트와 서버 측 사이에서 C#을 사용하면 애플리케이션 개발이 "훨씬 쉬워"졌을 뿐만 아니라 BurnRate의 UI를 계산만큼 신뢰할 수 있게 만드는 데 중요한 역할을 했습니다.

우리는 백 엔드 코드를 작성하는 것과 동일한 언어로 단위 테스트를 작성할 수 있습니다. 대단합니다! 이런 방식의 빌드를 싫어할 이유가 있을까요? 수천 줄의 코드를 제거했고 누구에게나 매우 직관적이었습니다. WPF 세계에서 단 5초 밖에 소요되지 않았습니다."

Blazor를 사용하여 BurnRate는 "매우, 매우 빠르게" 이동할 수 있었습니다. 팀은 3년이 아니라 몇 주 만에 작동하는 Blazor 프로토타입을 빌드했으며 1년 이내에 수십만 줄의 코드를 완전히 포팅했습니다. .

그 시간의 상당 부분을 새로운 오픈 소스 도구를 빌드하는 데 사용하여 다른 회사도 Blazor 앱을 더 빨리 빌드할 수 있도록 했습니다. 이는 McLaws의 유용한 정신에 맞는 접근 방식입니다.

"사람들은 BurnRate와 같은 플랫폼을 빌드할 때 고객 대면 앱만 필요한 것이 아니라 데이터베이스 변경 및 시스템 관리를 위해 앱 뒤에 앱도 필요하다는 사실을 잊는 경향이 있습니다."라고 그는 말했습니다.

"그래서 우리는 Blazor의 XAML에서 Model-View-ViewModel(MVVM) 아키텍처 스타일을 지원하는 라이브러리인 BlazorEssentials를 빌드했습니다. . 이를 통해 앱의 데이터 표시에서 데이터 수집을 명확하게 분리할 수 있습니다. 이를 통해 애플리케이션 아키텍처에 단순성과 일관성 수준을 제공합니다. 이제 코드베이스의 100%를 예측 가능한 패턴을 사용하여 단일 언어로 테스트할 수 있습니다."

고도로 자동화된 CI/CD(지속적인 통합 및 지속적인 업데이트)를 위해 Azure DevOps를 활용하면 BurnRate 팀이 훨씬 더 빠르게 움직일 수 있습니다.

McLaws는 "새로운 앱이든 기존 앱의 새로운 유틸리티든 상관없이 몇 시간 만에 프로덕션으로 배송할 수 있습니다."라고 말했습니다.

BurnRate가 확장됨에 따라 고객의 핵심 일상 작업에 더 많이 포함되도록 제품의 안정성을 보장해야 했습니다. McLaws는 Microsoft를 신뢰했습니다.

손상 없는 솔루션 제공

"나는 오래 전에 Microsoft를 선택했고 Microsoft는 나를 실망시킨 적이 없습니다."라고 그는 말했습니다.

McLaws는 23년 경력의 .NET 베테랑이자 5차례 Microsoft MVP를 수상했으며 오픈 소스 기여도는 총 14억 회 이상입니다. 오늘날까지 그는 Microsoft와 함께 계속해서 발전하고 있으며 함께 훌륭한 것을 빌드할 수 있는 리소스와 커뮤니티가 있다는 것을 알고 있습니다. Blazor를 사용하여 BurnRate 팀은 손상 없이 앱을 빌드하고 McLaws의 비전을 제공할 수 있었습니다.

그는 "그 [수준]의 안정적인 확장성을 지원할 수 있는 .NET 이외의 플랫폼"은 결코 없다고 말했습니다. 그에 따르면 Blazor는 경제적인(lean) 팀이 더 스마트하고 빠르게 빌드할 수 있도록 지원했습니다.