1. 비용 절약
오픈소스 기반 인프라스트럭처에는 유지 관리, 개선 논의, 피드백을 담당하는 많은 개발자가 있습니다. 소프트웨어 품질을 인년(man-year) 작업량으로 측정한다면, 오픈소스 소프트웨어는 많은 개발자의 작업을 축적했으므로 필연적으로 소규모 팀이 독립적으로 완성한 소프트웨어보다 품질이 좋습니다. 많은 것을 직접 재사용할 수 있습니다. 그리고 많은 사용자가 동일한 기본 프레임워크를 테스트하여 테스트 비용을 절약합니다.
2. 더 빠른 반복
많은 사용자 피드백 덕분에 최신 기술 트렌드가 오픈소스 소프트웨어에 신속하게 추가되는 경우가 많습니다. 반면 독립 소프트웨어 개발자는 그런 동기가 없을 수 있습니다. 예를 들어, Rails에 추가된 CoffeeScript 지원, asserts 집계 지원 등이 있습니다.
3. 완전한 아키텍처
모든 개발자나 아키텍트는 자신의 맹점이 있습니다. 대규모 소프트웨어는 시스템 엔지니어링이므로 소수의 사람이 모든 점을 커버하기 어렵습니다. 많은 국내 대형 웹사이트에서 폭로한 XSS 취약점처럼, 단순히 지식 범위의 문제이자 중요도의 문제일 수 있습니다. 오픈소스 소프트웨어는 각 방향에 능숙한 개발자가 공동으로 결정하고 개선합니다.
4. 기술 지원
문서 유지 관리와 후속 기술 지원은 개발 자체보다 비용이 더 많이 드는 작업일 수 있습니다. 오픈소스 소프트웨어는 종종 많은 사람이 문서를 공유하고 블로그를 작성합니다. 동일한 요구와 문제는 대부분의 경우 다른 사람이 이미 겪었고, 해결책이 있습니다. 반면 내부 개발 문서 유지 관리는 매우 어렵고, 교육과 소통도 매우 시간이 많이 걸립니다.
5. 오픈소스 위에 아키텍처를 구축하는 “단점”
오픈소스 기본 프레임워크의 단점은 너무 방대해서 모든 세부 사항을 파악하는 데 매우 많은 시간이 걸린다는 것입니다. 그래서 종종 문제에 직면하고, 처리 방법을 다시 연구해야 합니다. 모든 세부 사항을 이해하는 제로 아키텍처에 비해, 오픈소스 제품은 블랙박스를 마주하고 사용하는 것과 더 비슷합니다. 하지만 다행히 많은 사람이 사용하면서 이미 그 정확성을 증명했습니다.
6. 제로 아키텍처와 오픈소스 아키텍처 선택
팀의 시간과 자원이 상대적으로 부족하고, 관련 경험이 비교적 적다면, 오픈소스 위에 아키텍처를 구축하는 것이 최선의 선택일 수 있습니다. 개발 비용을 절약하면 더 많은 에너지를 다른 측면에 쏟을 수 있습니다.
아키텍트가 전체 시스템의 모든 측면을 잘 알고, 모든 기술 트렌드를 추적할 충분한 에너지가 있으며, 구축하는 시스템이 매우 간단하거나, 기존 오픈소스 제품과 차이가 크다면, 제로 아키텍처를 선택할 수 있습니다. 하지만 이것은 “어렵습니다”. 때로는 집단 지혜의 결과가 한 명의 전문가보다 더 좋습니다.
재게시 출처: 개발자 관계 »
