소프트웨어에 대한 허위사실: 저렴하고 빠르고 좋은 소프트웨어를 만들 수 있습니다. 두 가지를 선택하세요.
가격은 소프트웨어 품질 및 속도와 별개로 결정됩니다.
"저렴하고, 빠르고, 좋은 걸 만들 수 있어요. 둘을 고르세요"는 소프트웨어 개발 우선순위에 내재된 트레이드오프를 일컫는 말입니다. 직관적으로 말이 되지만 실제 애플리케이션에서는 완전히 실패합니다. 이 상관관계가 성립하지 않는 두 가지 간단한 이유는 다음과 같습니다.
- 가격은 결과의 질 과 현실적으로 연관되지 않습니다 .
- 가격도 빠른 배송 시간과 연관이 없습니다 .
가격은 구매자와 판매자가 가치를 인식하는 방식에 따라 전적으로 결정되는 독립적인 특성입니다.
제가 링크한 Dan Luu의 기사에서 언급했듯이, 특정 분야의 전문가조차도 자신의 서비스(또는 다른 사람의 서비스)의 시장 가치를 정확하게 평가하기는 매우 어렵습니다. 따라서 가격 발견은 지속적으로 테스트되어야 합니다 .
하지만 가격 대 품질, 가격 대 속도 관계를 좀 더 자세히 살펴보겠습니다.
가격 대 품질
가격과 품질 상관관계를 공식적으로 위조하고 싶다면, 가장 쉬운 방법은 반례를 통해 증명하는 것입니다. 매우 비싼 "선임" 개발자가 팀, 프로젝트 또는 조직에 몇 번이나 들어와서 가치의 완전한 파괴 외에는 아무것도 기여하지 않았습니까 ? 아니면 호스팅 서비스, 컨설팅 회사, 타사 구성 요소에 많은 돈을 썼지만 그 대가로 매우 형편없는 결과를 얻은 경우는 어떻습니까?
소프트웨어 산업에서는 과다 지불이 흔한데, 가격을 합의할 때 과거의 실적이 아닌 평판에 따라 합의하는 경우가 많기 때문입니다.
조직적 적합성
하지만 그보다 좀 더 나아갑니다. 예를 들어, 누군가가 입증된 실적(예: 과거에 여러분 팀의 다른 멤버와 성공적으로 협력한 경우)이 있는 정말 "훌륭한" 소프트웨어 개발자라면, 여러분은 그들에게 여러분의 회사에 합류하도록 상당한 프리미엄을 지불합니다. 하지만 여러분의 팀은 회의에 소요되는 시간이 전달하는 시간의 5배인 관료주의적이고 거대한 회사입니다.
이 개발자의 품질 에도 불구하고 이 개발자에게서 많은 가치를 추출할 수 없을 것입니다. 왜냐하면 여러분의 조직이 인재로부터 가치를 제대로 극대화하도록 설계되지 않았기 때문입니다. BigCo 유형의 환경에서 조직은 꼬리 위험을 최소화하도록 운영됩니다. 실제로는 경험이 있고 배를 흔들거나 큰 변화를 원하지 않는 중간 계층 개발자를 고용하는 것이 더 나을 것입니다.
"양질의 소프트웨어"의 특성
여기서 다음과 같은 의문이 생깁니다. 소프트웨어 품질은 어떤 모습 일까요 ? 소프트웨어 개발 라이프사이클의 출력을 살펴보면 상당한 버그 없이 출시되고, 성능이 뛰어나고, 문서화가 잘 되어 있고, 잘 테스트되었으며, 이해 관계자를 만족시키는 충분히 좋은 인터페이스이며, 시간과 예산 내에서 제공되는 소프트웨어입니다.
귀하의 조직에서 얼마나 많은 개발자가 기억을 바탕으로 현재 일상 업무에 적용할 수 있는 완전한 사용자 스토리를 작성할 수 있을까요? 얼마나 많은 개발자가 실제 최종 사용자 수용 기준을 완벽하게 정확하게 파악할 수 있을 뿐만 아니라 이 사용자 스토리의 복잡성의 원천이 무엇인지, 그리고 이를 완화하기 위한 최상의 전략이 무엇인지 설명할 수 있을까요? 실제 사용자와 처음 접촉한 후 사용자 스토리의 어떤 부분이 변경되고 진화할 가능성이 있는지 설명할 수 있을까요?
저는 최근에 제조 회사에서 컨설팅 업무를 했습니다. 회의에 참석한 사람 중 한 명은 회사에 거의 30년 동안 근무한 베테랑 소프트웨어 개발자였습니다. 그는 일부 임베디드 시스템에 대한 네이티브 드라이버를 작성했고, 회사가 Akka.NET을 사용하여 백엔드 서비스로 병렬화하려고 시도한 WPF 애플리케이션의 상당 부분을 작성했습니다. 그는 이 모든 것을 빠르고 자신 있게 수행할 수 있는 극히 드문 개발자 중 한 명이었습니다.
아무리 좋은 의도를 가진 개발자라 할지라도, 품질을 측정하는 가장 기본적인 방법, 즉 자신이 무엇을 만들고 있는지, 왜 만들고 있는지, 누구를 위해 만들고 있는지 이해하는 소프트웨어 개발자는 거의 없습니다.
품질 측정
그리고 품질에 대한 양적 접근 방식도 있습니다. 어떻게 측정할 수 있을까요?
"고품질 소프트웨어"에 대한 내 일반화에는 상당히 많은 측정 가능한 요소가 암묵적으로 설명되어 있습니다. CRAP 점수 , 버그 목록, 벤치마크, 테스트 결과, 측정된 개발 속도입니다. 얼마나 많은 조직이 이러한 요소를 일관되게 측정 합니까 ?
아주, 아주 적습니다. 그렇다면 조직은 어떻게 고품질 또는 저품질 결과를 얻고 있는지 알 수 있을까요? 보통은 프로젝트가 마감일을 놓치거나, 고객을 엄청나게 화나게 하거나, 엄청난(그리고 보통 피할 수 있는) 생산 사고로 불타거나, 가장 흔하게는 프로젝트 요구 사항이 불가피하게 변경되고 이전에 구현된 프로그램 구조로 인해 이런 일이 발생하지 않을 때입니다.
요약하자면, 개발자들이 결과의 "품질"에 대해 말할 때, 그들은 종종 질적으로 무슨 말을 하는지 전혀 알지 못하고, 양적으로는 더더욱 알지 못합니다.
Akka.NET 프로젝트 에서 우리는 이를 측정하기 위해 매우 열심히 노력했고 , 심지어 하고 싶을 때조차 도전이었습니다 . 즉, 모든 풀 리퀘스트에서 전체 프로젝트에 대한 CRAP 점수를 생성하면 이미 긴 테스트 실행 시간에 20~30분이 더 추가됩니다. 모든 PR에서 벤치마크를 수행하면 아마 90분이 더 추가될 것입니다. 이 모든 것이 사이클 시간을 방해하는데, 이는 우리가 다음에 논의할 것입니다.
가격 대 속도
속도를 위해 돈을 바꿀 수 있는 경우가 분명히 있습니다.
- 자체 호스팅 인프라를 구축하고 구성하는 대신 AWS에 비용을 지불합니다.
- Seq 와 같은 자체 호스팅 APM 도구에 대한 라이선스 구매
- Cursor 와 같은 AI 코드 생성 도구 구독
- JetBrains 제품 과 같은 더 나은 개발 도구 구매
- 뻔뻔스러운 광고: Petabridge 와 같은 회사를 고용하여 새로운 기술인 Akka.NET에 대한 팀 교육을 실시합니다(시행착오를 통해 몇 달을 보내는 대신) 2
속도를 위해 돈을 교환하는 이 모든 거래에서 눈에 띄는 점은 다음과 같습니다.
- 공급업체가 판매하는 이러한 제품은 모두 매우 일반화되었거나 상품화되었습니다.
- 따라서 공급업체는 이러한 문제에 대한 일반화 가능한 솔루션을 갖고 있습니다.
- 우수한 결과에 대한 명확한 약속도 없습니다. DataDog는 반드시 애플리케이션 동작에 대한 실행 가능한 통찰력을 제공하지 않고도 한 달에 5자리 수의 청구서를 기꺼이 발행할 수 있습니다.
문제는 이겁니다. 외부 조직의 전문 지식에 대한 적시 접근을 제품과 서비스의 형태로 받는 대가로 돈을 거래할 수 있지만, 그것은 자사 고객에게 소프트웨어 제품을 제공하는 데 필요한 것의 아주 작은 일부에 불과합니다.
소프트웨어 개발의 핵심은 결국 사용자, 비즈니스 사례, 요구 사항, 규정, 제한 등을 포함한 모든 측면을 사용자 정의하는 것입니다.
더 많은 사람을 고용하다
어떻게 하면 이 모든 것을 질적으로, 빠르게 달성할 수 있을까요? 원래 속담은 돈이 이 문제를 해결하는 방법이라고 전제합니다. 더 많은 사람을 고용하는 것입니다.
여기서 신화적 인력에 대한 내용 을 다시 설명할 생각은 없습니다 . 좀 더 게으른 방식으로 신화적 인력 에 대한 내용을 브룩스의 법칙을 인용 하여 다시 설명하겠습니다 . "늦어진 소프트웨어 프로젝트에 인력을 추가하면 프로젝트가 더 늦어진다."
이 지점의 요점은 팀 규모를 확대하면 커뮤니케이션 오버헤드도 확대된다는 것입니다. 이는 전달 시간/전달에 대한 대화 시간 비율을 잘못된 방향으로 전환하여 전달이 늦어 지게 됩니다. 이를 극복하려면 Jeff Bezos의 Amazon 3 에 대한 API 우선 명령과 같이 매우 사려 깊은 조직 설계가 필요합니다 .
'적합한' 사람 고용
소프트웨어 속도가 더 많은 사람으로 달성될 수 없다면, "적절한" 사람으로 달성하는 건 어떨까요? 우리가 더 많은 경험이 있는 소프트웨어 개발자를 고용하기 시작하면, 그들은 주니어나 현재 사람들보다 더 빨리 무언가를 생산할 수 있을 텐데요?
어느 정도 도움이 될 수 있습니다. 내부적으로 고용하거나 관련 기술 스택과 도메인 전문 지식을 갖춘 컨설턴트를 데려올 수 있습니다. 하지만 두 가지 새로운 잠재적 문제가 발생합니다.
- 도메인 교육 오버헤드 - 관련 전문 지식을 가진 업계 내 사람을 고용하더라도 여전히 귀하의 업무 수행 방식 과 요구 사항 에 대한 교육을 받아야 합니다 . 내부 또는 외부 고용 시마다 반복합니다.
- 불확실성 - 업계에서 좋은 실적을 가진 탄탄한 선임 개발자를 확보하더라도, 그들이 팀의 다른 개발자보다 더 빠르고 신속하게 일을 진행할 수 있다는 보장은 전혀 없습니다. 다시 품질 문제가 발생합니다.
소프트웨어의 반복 속도/사이클 타임을 개선하려고 한다면 "빠른 개발자 고용"은 희망에 기반한 전략이며, 따라서 실패할 것입니다.
소프트웨어 품질과 속도는 방법론 문제입니다
제가 처음부터 말했듯이, 가격은 가치와 상관관계가 있고 가치는 평가하기 매우 어렵습니다. 이것이 돈이 소프트웨어 제공 문제에 대한 확실한 치료법이 아닌 이유입니다.
소프트웨어 제공 품질과 속도는 궁극적으로 방법론적 문제입니다. 인력도 분명히 요인이긴 하지만, 80%는 우리가 사업을 수행하는 방식 이고 20%는 누가 수행하는가에 달려 있습니다.
다음은 여러분이 집으로 가져갈 수 있는 실제 상관 관계입니다. 속도를 측정하고 이에 집중하는 소프트웨어 개발 팀은 본질적으로 더 높은 품질의 소프트웨어를 제공할 것입니다. 지속적인 제공 우주에서 이와 동일한 결론에 도달하는 수많은 연구가 있습니다 . 팀이 소프트웨어를 제공하는 속도가 빨라질수록 버그를 더 빨리 찾아 수정하고 따라서 품질이 향상됩니다.
소프트웨어 팀을 위한 속도 개선 개발 방법론(CI/CD가 전부는 아닙니다)에 대한 후속 블로그 게시물을 작성할 예정이니 구독 부탁드립니다.
가격 책정은 지역적 극대값을 찾는 것과 관련이 있으며, 이는 아무리 작은 지역이라도 찾기가 매우 어렵습니다 .
Petabridge에서 제공하는 서비스에 대한 자세한 내용은 여기에서 확인하세요: https://petabridge.com/training/onsite-training/ ↩
https://konghq.com/blog/enterprise/api-mandate - 이는 결국 Amazon Web Services의 탄생으로 이어졌습니다. ↩
“지속적인 배포가 코드 품질에 미치는 영향: 업계 사례 연구” , “ 매우 작은 소프트웨어 개발 엔터티에서의 CI/CD 관행 도입 및 적용: 체계적인 문헌 검토 ” ↩
토론, 링크 및 트윗
저는 Petabridge 의 CTO이자 창립자입니다 . Petabridge에서 저는 Akka.NET , Phobos 등 의 작업을 통해 .NET 개발자를 위한 분산 프로그래밍을 쉽게 만드는 데 주력하고 있습니다 .
원문: