UI 구성 요소 라이브러리 – 빌드 vs 구매

"저는 남은 생애 동안 다시는 다른 캘린더 구성 요소를 만들고 싶지 않습니다. 저는 또한 react-select를 좋아합니다." 나는 토론을 탐색하는 동안 reddit에서 이것을 발견했습니다.

​"당신이 당신 자신의 (라이브러리)를 쓸 때 당신은 접근성, 이동 색인, 초점 관리, 자동 ID 등과 같은 더 많은 것을 배우게 될 것입니다. 이 모든 것이 훌륭하고 안정적인 UI 패키지의 복잡성을 높이 평가하게 합니다."

그리고 여기서 "구성 요소 라이브러리 구축 대 구매 : 무엇을 선택해야합니까?"라는 질문에 답하고 개발자가 비용이 들지 않는 결정을 내릴 수 있도록 도와줍니다.

• 그들의 시간은 헛수고이며, 실제로는 빠른 품질의 IT 솔루션을 구축해야 하는 시간 자체에 쫓기고 있습니다.
• 실제로 그들은 엄격한 예산으로 일하고 회사는 X 금액의 돈과 X 시간당 임금이 소요될 것으로 예상되는 프로젝트에 더 많은 것을 할당할 수 없을 때 그들의 돈은 헛되이 됩니다.
• 자신의 프로그래밍 기술에 대한 신뢰는 사실 매우 틈새 시장의 특정 목적을 위해 타사 UI 라이브러리를 사용할 수 없습니다. 예를 들어, 다른 개발자가 여러 기능을 지원해야 하는 다른 선택 구성 요소를 동시에 처리하는 동안 Angular Pivot Grid를 처음부터 구축할 수도 없습니다. 따라서 결국 두 가지는 일관성 없는 UI와 UX에서 충돌합니다.

어느 쪽이든, 이 모든 것은 단일 프로젝트가 미션 크리티컬에서 미션 임파서블로 빠르게 바뀔 수 있는 스트레스가 많은 시나리오입니다. 그러면 어떻게 해야 할까요? 웹 애플리케이션을 구축하는 가장 좋은 방법은 무엇입니까? 사전 구축된 UI 구성 요소를 사용해야 합니까, 아니면 직접 빌드하는 것이 더 낫습니까? 그리고 애초에 컴포넌트 라이브러리를 사용하는 이유는 무엇일까요?

구성 요소 라이브러리란 무엇입니까?

간단히 말해서 UI 구성 요소 라이브러리는 사전 빌드된 기능이 풍부한 구성 요소/컨트롤, API, 지침, 샘플 앱, 통합 시나리오, 코드 예제 및 앱 개발을 간소화하는 추가 도구를 결합하여 개발자가 훌륭한 인터페이스를 더 빠르게 구축할 수 있도록 도와주는 포괄적인 툴킷입니다. 또한 구성 요소를 사용자 정의, 재사용 및 확장하여 브랜딩 옵션과 더 많은 유연성을 얻을 수 있습니다.

그러나 요구 사항, 목적, 기술, 앱 유형 등과 같은 주요 측면을 해결하는 데 있어 개발 처리 옵션은 다음과 같이 요약됩니다.

• 사내 UI 라이브러리 구축
• third-party component library 구매
• Choosing an open-source software (OSS)

어떤 것이 가장 적합한 접근 방식인지 결정하기 위해 먼저 더 큰 그림을 보고 내러티브 렌즈를 조정하고 확대하기 전에 이 세 가지 옵션 각각이 잠재적으로 적용될 수 있는 더 넓은 맥락을 살펴보겠습니다.

• Company size and teams
• 노하우와 경험
• 앱, 용도 및 클라이언트

1.      Company size and teams

구성 요소가 포함된 도구 상자를 구입할지 구축할지 결정할 때 가장 먼저 고려해야 할 사항 중 하나는 회사의 규모와 앱 빌드에 참여하는 프로그래머의 수입니다.

이러한 맥락에서 물어볼 질문:

• 회사가 규제가 엄격한 분야에서 운영되고 있습니까?
• 중소기업입니까, 대기업입니까?
• 융합 팀과 함께 작동합니까? 그림에 원격 개발자나 시민 개발자가 있습니까?
• 대규모 조직인 경우 팀에서 이미 어떤 유형의 UI 라이브러리를 사용하고 있습니까?
• 회사와 팀이 이러한 도구 상자 중 하나인 표준화를 구현할 때 달성하고자 하는 것은 무엇입니까? 장기적으로 지속적인 재사용성? 접근성 준수? 소프트웨어를 만드는 방법에 대한 완전한 통제권? 앱 비즈니스 로직에 더 많은 시간을 할애하고 모든 것을 처음부터 만들 필요가 없습니까?

2. 기술적 노하우 및 경험

사전 구축된 UI 라이브러리를 사용할지 아니면 자체 라이브러리를 만들지 여부를 결정할 때는 IT 팀의 배경을 고려해야 합니다. 개발자가 장기/단기 목표에 부합하는 포괄적인 구성 요소를 구성하는 데 충분한 지식이 없다면(물론 특정 요구 사항에 따라 다름) 시간과 노력을 투자할 가치가 전혀 없습니다. 이를 위해서는 코드와 프로세스를 문서화하기 위해 경험이 많은 개발자의 추가 리소스도 필요합니다.

이러한 맥락에서 물어볼 질문:

• 팀의 개발자와 디자이너는 어떤 실용적이고 기술적인 노하우를 가지고 있습니까?
• 이전에 UI 라이브러리를 사용한 적이 있으며 어느 정도까지 사용했습니까?
• 디자이너와 회사의 UX 뒤에 있는 사람들은 구성 요소를 전문적으로 디자인할 수 있는 충분한 경험을 가지고 있습니까?
• 빠르게 배우고 새로운 모범 사례와 자동화에 적응할 준비가 되어 있습니까?
• 아니면 처음부터 구성 요소를 직접 만들어 보았고 얼마나 재사용 가능했습니까?
• 어떤 프레임워크와 기술과 함께 작동하나요?
• 귀하 또는 귀하의 팀은 종속성을 처리하고 브라우저 버전 또는 프레임워크 업데이트를 따라갈 준비가 얼마나 되어 있습니까? 사내 도서관을 최신 상태로 유지할 시간이 있습니까?
• 얼마나 많은 프론트엔드 작업을 수행해야 합니까?

3. 앱, 그 목적 및 클라이언트

마지막으로, 귀하의 결정은 작업할 프로젝트, 무엇을, 어떻게 사용할 것인지, 그리고 누구에 의해 사용될 것인지에 따라 결정되어야 합니다.

이러한 맥락에서 물어볼 질문:

• 반복적인 작업을 없애고 동일한 모듈과 코드를 사용해야 하는 장기 프로젝트를 위해 재사용 가능한 구성 요소가 필요하십니까?
• 아니면 다시는 사용하지 않을 일회성, 매우 구체적이고 전문화된 사용 사례이므로 여러 시나리오/앱/프로젝트에 적용되지 않습니까?
• 모든 상황에 맞는 단일 솔루션을 수용하지 않고 대신 과도한 사용자 지정을 요구하고 특정 설계 사양을 수반하여 덜 일반적인 문제를 처리하고 해결하는 데 필요한 작업을 부과하는 좁은 틈새 시장에서 외부 클라이언트를 위해 구축하고 있습니까?
• 즉시 사용 가능한 기능이 귀하를 위해 작업을 수행하고 기본적으로 모든 사용자가 사용할 수 있는 기능을 귀하/팀이 사용해도 됩니까?
• 조직의 사내 시스템이며 앱 개발 속도를 높이고 부서 간 팀 간의 협업을 개선해야 합니까?
• 고유한 제품을 구축하고 혁신하여 언제든지 변경 및 업데이트할 수 있는 완전한 제어와 무제한 시나리오/기능이 필요한 것이 목표입니까?

구매 vs 빌드: 타사 구성 요소 라이브러리, 사내 UI 라이브러리 및 OSS의 장단점

이 섹션에서는 7가지 요소를 통해 각 옵션을 필터링하고 각 옵션의 장단점을 강조 합니다.

Factor 1: Component reusability

이것은 특히 연속적인 프로젝트이고 수동 작업과 반복 작업을 줄이기 위해 동일한 코드를 다른 시간에 사용할 계획인 경우 프로젝트 전반에 걸쳐 표준화를 확실히 달성합니다. 그러나 특히 Blazor와 같은 비교적 새로운 프레임워크의 경우 처음부터 구축하기가 특히 어려운 특정 구성 요소가 있습니다. 나는 여기서 버튼을 의미하지 않습니다. 접근성 규정 준수, 모든 유형의 열, 셀 및 행 작업, 데이터 조작, 사용자 지정 시각화 등을 제공할 수 있을 만큼 빠르고 포괄적일 수 있는 Data Grid를 생각해 보십시오.

COMPONENT REUSABILITY
	ADVANTAGES	DISADVANTAGES
상용 UI 라이브러리	가능한 한 많은 개발자, 팀 및 프로젝트를 제공하고 준수하도록 구축되었으며 다양한 앱에 적용할 수 있습니다.   일반적인 문제를 신속하게 해결할 수 있습니다.   여러 구성 요소에 대한 일관된 스타일링.   표준화를 더 빠르게 달성하고 즉각적인 UI/UX 일관성을 제공합니다.	원하는 수준의 지식 공유 및 가속화된 앱 개발을 달성하기 전에 몇 가지 교육과 지침이 필요할 수 있습니다.   틈새 기능의 우선 순위를 정하는 데 더 많은 시간이 걸릴 수 있습니다.
사내 도서관	모듈식 개발이 필요한 다른 목적 및 프로젝트에 사용할 수 있는 노하우를 습득합니다.   원하는 수준의 재사용성으로 필요한 구성 요소만 설계하고 개발하십시오.   중요한 기능/기능의 우선 순위를 더 빠르게 지정합니다.	구성 요소는 현재 사용 사례에 맞게 특별히 제작되었으며 다른 팀/프로젝트 간의 재사용을 고려하지 않습니다.   장기적인 유지 관리 및 비용은 선불로 간주되지 않습니다.   접근성, a11y, 섹션 508 준수 및 구성 요소에 대한 기타 필수 사항에 대한 고려 사항이 없습니다.   문서가 없으므로 API는 구성 요소를 만든 개발자만 알 수 있으므로 다른 사람이 사용하기 어렵습니다.
OSS	많은 OSS 프로젝트는 노력을 재현하고 동일한 코드를 사용합니다. 커뮤니티가 혜택을 받을 수 있는 새로운 기능을 쉽게 제안할 수 있습니다.	대부분의 OSS 프로젝트는 12개월 이내에 중단되며, 커뮤니티의 지원을 전혀 받지 못하는 프로젝트는 더욱 많습니다.   아직 구성 요소 재사용성의 모든 이점을 제공할 수 없습니다.   디버깅하고, 누락된 기능을 파악하고, 나중에 추가하는 데 충분한 시간을 할애합니다.

Factor 2: External dependencies

나중에 추가해야 하는 종속성이 많을수록 처음에 단순화하려고 했던 작업이 더 복잡해집니다. 따라서 이와 관련하여 모든 옵션을 고려하는 것이 중요합니다.

EXTERNAL DEPENDENCIES
	ADVANTAGES	DISADVANTAGES
상용 UI 라이브러리	그것들은 최소한으로 유지되며, 추가해야 하는 경우 대부분 하나뿐입니다. 복잡성 수준은 0에 가깝습니다. 라이브러리 간의 충돌을 처리하지 않습니다. 그러나 혹시나 되는 경우를 대비하여 유료 라이브러리 뒤에 있는 팀이 이를 처리하고 일반적으로 이러한 유형의 문제를 조기에 포착합니다. 타사 라이브러리 자체에만 국한됩니다.	이 종속성 패키지를 해결하는 데는 외부 지원에 의존하기 때문에 시간이 더 걸릴 수 있습니다.
사내 도서관		오래된 종속성을 직접 처리해야 하기 때문에 프로젝트의 복잡성이 배가됩니다.   3 자 OSS 종속성의 보안 위험에 대한 책임은 사용자에게 있습니다.
OSS		오래된 종속성을 직접 처리해야 하기 때문에 프로젝트의 복잡성이 배가됩니다.   제2자 또는 제3자 종속성인지 알 수 없습니다.

Factor 3: Updates

귀하 또는 귀하의 개발 팀이 매일, 매월, 연간 얼마나 많은 업데이트를 처리할 수 있습니까...? 세 가지 옵션 각각은 확실히 서로 다른 장단점을 가지고 있으며 결정을 내리기 전에 업데이트와 관련하여 평가하는 것이 중요합니다.

SOFTWARE UPDATES
	ADVANTAGES	DISADVANTAGES
상용 UI 라이브러리	모두 최신 프레임워크 또는 브라우저 버전으로 업그레이드됩니다. 업데이트는 상용 라이브러리 뒤에 있는 외부 팀에서 수행합니다. 사람들을 재배치하거나 혼자서 처리할 필요가 없습니다.   원활한 테스트 프로세스가 마련되어 있어 팀이 업그레이드를 처리하고 안정성을 보장하는 데 도움이 됩니다.   지속적인 프로젝트는 일반적으로 미래를 염두에 둔 로드맵을 가지고 있으며 그에 따라 정기적인 릴리스를 받습니다.	업그레이드가 너무 많을 수 있습니다.   알파, 베타, RC 버전은 우선 순위가 높은 항목을 해결하기 위해 매일 릴리스될 수 있습니다.
사내 도서관	업데이트를 추적해야 하는 사람은 바로 사용자이기 때문에 최신 릴리스에 대한 직접적인 정보를 얻을 수 있습니다.	당신이 모든 것을 처리합니다.   자체 개발한 라이브러리는 일반적으로 업데이트되지 않으며 제품에 삽입될 때쯤에도 구식입니다.
OSS	매번 업데이트되는 잘 관리된 오픈 소스 프로젝트에 착수할 수 있습니다. 지속적인 프로젝트는 일반적으로 미래를 염두에 두고 로드맵을 가지고 있으며 정기적으로 릴리스됩니다.	업그레이드가 너무 많을 수 있습니다.   자금이 넉넉한 가장 큰 OSS 프로젝트만이 정기적인 일정에 따라 최신 상태로 유지됩니다.

요인 4: UI 라이브러리 문서 및 학습 리소스

데모, 구현된 구성 요소의 예제, 추가 리소스 섹션 및 기술 자료가 포함된 잘 작성된 포괄적인 설명서가 핵심입니다. 코딩을 문서화하지 않거나 기성품이 없으면 단일 드롭다운 목록이나 페이지네이터를 작성하는 데도 어려움을 겪을 수 있습니다. Blazor DockManager와 같은 더 복잡한 구성 요소나 재무/주식 차트와 같은 복합 시각화 Angular 말할 것도 없습니다.

문서 및 학습 리소스
	ADVANTAGES	DISADVANTAGES
상용 UI 라이브러리	항상 상세하고 읽기 쉬운 최신 문서와 함께 제공되며 "한 번 하고 잊어버리지" 마십시오. 개발자가 처리하게 될 코드/UI 구성 요소를 더 잘 이해하고 느끼는 데 도움이 되는 실시간 편집 샘플이 포함될 수 있습니다. 추가 학습 리소스, 블로그, FAQ, 사용 방법 비디오, 자습서, 샘플 앱을 제공합니다. 일반적으로 Stack Overflow, Discord, Medium, Reddit, GitHub에 대규모 커뮤니티가 있습니다.	문서화 및 학습에 대한 헌신이 필요합니다. 익숙해지는 데 시간이 걸릴 수 있습니다.
사내 도서관		추가 작업 시간과 개발 시간이 필요하여 작성하고 업데이트해야 합니다.   대부분의 조직에는 시장에 출시하려는 애플리케이션에 대한 문서를 작성할 리소스가 없으며, 애플리케이션에 사용되는 자체 개발 UI 구성 요소는 말할 것도 없습니다.
OSS		문서가 있는 OSS 프로젝트는 규모가 매우 크고 자금이 넉넉하지 않으면 찾기가 어렵습니다.   추가되고 정기적으로 또는 불규칙적으로 추가되는 모든 것에 익숙해지고 배우는 데 너무 많은 시간이 걸릴 수 있습니다.

Factor 5: Customization

앱에서 모든 것을 얻고 제공하려면 업데이트와 변경이 필요합니다. 그렇다면 UI 라이브러리는 얼마나 유연해야 하며 얼마나 유연하게 만들 수 있을까요? 한 솔루션 또는 다른 솔루션을 선택할 때 이 요소를 간과하지 말지만, 때로는 구성 요소가 매우 다양하고 모든 사람이 변경할 수 있는 구성 요소/기능으로 인해 코드를 유지 관리하기 어려울 수 있으며 아무도 익숙하지 않거나 매우 구체적인 다른 많은 "사항"을 손상시킬 수 있습니다. 이것이 예를 들어 Combobox 구성 요소보다 간단한 사용자 정의 Angular 구성 요소가 있는 이유입니다.

맞춤화
	ADVANTAGES	DISADVANTAGES
상용 UI 라이브러리	Ignite UI와 같은 포괄적인 라이브러리는 사용자 정의, 접근성, 내재화를 위한 공간을 남겨 둡니다. Professional components are super configurable. 사용자가 쉽게 변경할 수 있는 대화형 매개 변수를 포함합니다. 디자인 시스템과 로우코드/노코드 앱 빌더에서도 동일하게 잘 작동합니다.	일부 기능은 즉시 사용할 수 있습니다.   공통/모든 시나리오에 맞게 구축되었습니다(이점도 될 수 있음).
사내 도서관	언제든지 원할 때 원하는 대로 특수 기능을 구축하고 구성 요소를 변경할 수 있는 무한한 옵션과 방법이 있습니다.   정확한 구성 요소와 기능을 결정할 수 있습니다.	자체 개발 라이브러리는 특정 요구 사항에 맞게 특별히 구축되었으며 장기적인 사용자 지정/확장성은 미리 고려되지 않습니다.   구축, 테스트, 검증, 코딩, 문서화에 더 많은 시간이 필요합니다.
OSS	일반적으로 매우 구성 가능합니다.	커뮤니티의 관심을 끌거나 자금 조달이 이루어지면 기능과 확장성이 추가되는 목적으로 구축되었습니다.

요소 6: 기술 지원

상세하고 설명적인 도움말 문서 및 기타 학습 리소스의 이점을 얻는 것 외에도 자격을 갖춘 기술 지원을 받는 것도 중요합니다.

기술적 지원
	ADVANTAGES	DISADVANTAGES
상용 UI 라이브러리	모든 요청과 질문을 처리하고 솔루션을 제공하는 전담 기술 지원 팀이 있습니다. 시기적절하고 자격을 갖춘 도움.
사내 도서관		모든 문제를 스스로 처리하거나 더 많은 기술적 노하우를 가진 사람에게 도움을 요청합니다.   귀하 또는 귀하의 팀은 어느 시점에서 모든 요구와 요청에 응답해야 하며, 이로 인해 중요한 작업과 고품질 코딩이 저하됩니다.
OSS	선택한 OSS 라이브러리에 대규모 커뮤니티 노력이 있는 경우 솔루션을 찾을 가능성이 높습니다.   협업할 수 있습니다.   동료 개발자 커뮤니티가 뒷받침하는 문제 해결 능력을 향상시킵니다.	그렇지 않은 경우 추가 도움을 요청하거나 직접 처리해야 합니다.   전담 기술 지원 없음 또는 기술 지원은 OSS 라이브러리의 인기도와 커뮤니티를 기반으로 합니다." 라이브러리가 새롭고 알려지지 않은 경우, 그 뒤에는 이를 뒷받침할 커뮤니티가 없습니다.

요인 7: 비용, 라이선싱 및 ROI

마지막으로, 모든 것이 비용이 얼마나 들지, 그리고 가격이 미래에 보상을 받는지에 달려 있습니다.

비용, 라이선싱 및 ROI
	ADVANTAGES	DISADVANTAGES
상용 UI 라이브러리	Ignite UI와 같은 라이브러리는 예산과 요구 사항에 맞게 다양한 패키지와 라이선스 옵션을 제공합니다. 사용 가능한 평가판을 통해 100%를 사용하기 전에 제품이 어떻게 작동하는지 탐색하고 확인할 수 있습니다.   모든 패키지는 Angular, Blazor, React, Web Components 등과 같은 프레임워크의 중요한 릴리스 직후에 업그레이드됩니다. Offer per-developer subscriptions.	전체 제품 및 모든 구성 요소 또는 기능에 대한 평가판이 포함되지 않을 수 있습니다.   제품에 따라 비용이 많이 들 수 있으며 모든 기능을 갖춘 계획이 저렴하지 않을 수 있습니다.   때로는 월간 구독이 없고 연간 구독만 있습니다.
사내 도서관	특히 현재 값비싼 타사 UI 구성 요소 라이브러리에 대한 리소스가 없는 경우 가장 빠른 솔루션일 수 있습니다.	일반적으로 비용은 라이브러리를 빌드한 다음 유지 관리 및 업그레이드하고, 설명서를 작성하고, 문제를 처리하고, 추가 작업을 수행하는 데 필요한 개발 시간을 곱합니다.   연구에 따르면 비용은 자체 개발 솔루션의 ROI보다 10배에서 50배 더 높습니다.
OSS	필요한 것과 정확히 일치하는 솔루션을 찾으면 잘 작동하고, 그렇지 않으면 IP를 소유하지 않은 코드 기반을 사용자 지정하는 데 시간을 소비하게 됩니다.	OSS 라이선스에 대한 철저한 이해가 필요하므로 IP가 위험에 처할 수 있습니다.   비용은 라이브러리를 빌드한 다음 유지 관리 및 업그레이드하고, 설명서를 작성하고, 문제를 처리하고, 추가 작업을 수행하는 데 필요한 개발 시간을 곱합니다.   비용과 ROI를 추정하는 것은 거의 불가능합니다.

내 개인적인 견해와 Ignite UI

마지막으로, Ignite UI 란 무엇이며 비즈니스에 좋은 솔루션인 이유는 무엇입니까?

IT 팀이 투박한 소프트웨어 개발 프로세스에 의존하고 모든 것을 처음부터 구축해야 했던 시대는 오래 전에 끝났습니다.

외부 클라이언트 또는 사내 솔루션을 위한 앱 구축을 언급하든, UI 라이브러리 및 도구 집합과 같은 것을 논의하든 상관없습니다. 항상 똑같습니다. 도구가 테마, 응답성, a11y 및 신속한 앱 개발과 관련된 가장 현대적인 원칙을 준수하면서 앱 개발을 가속화하고 용이하게 하고 더 나은 UX를 달성할 수 있다면 도구를 사용할 수밖에 거의 없습니다.  수백만 달러의 비용이 들거나 완료하는 데 몇 달 또는 몇 년이 걸릴 수 있는 소프트웨어 개발 프로젝트를 승인할 개발 관리자 또는 임원을 찾기가 어려울 것입니다.  더 나쁜 것은 결정이 몇 달 또는 몇 년 전에 내려졌기 때문에 프로덕션에 투입될 때쯤에는 완전히 구식이 된 반면, 최신 UI 프레임워크는 새로운 기능, 보안 업데이트 및 버그 수정과 함께 일 년에 여러 번 출시되고 있습니다.

구성 요소 라이브러리와 관련하여 포괄적인 라이브러리는 생각할 수 있는 기본 제공 확장성을 통해 대부분의 디자인 및 응용 프로그램 요구 사항을 실제로 다룹니다. Angular, Blazor, React, Web Components 및 기타 인기 있는 프레임워크에 대한 도구 상자를 제공하는 Ignite UI와 같습니다.

각 라이브러리는 모든 비즈니스에 적합한 지속적인 개선 사항과 기능을 받으며, 무엇보다도 프레임워크 전반에 걸쳐 일관성을 제공합니다. 제가 선택할 수 있고 그리드, 차트, 데이터 입력 및 파일 내보내기와 같은 수십 개의 사용 가능한 구성 요소 중에서 선택할 수 있습니다. 선택한 프레임워크로 무엇이든 달성하는 데 도움이 될 뿐만 아니라 개발자/디자이너로 성장하는 동시에 회사에 상당한 비용 절감을 가져다 줄 강력한 커뮤니티의 일원이 될 수 있는 기회를 얻습니다.

재사용 가능한 구성 요소 라이브러리의 ROI와 빌드 대 구매 비용에 대한 자세한 내용은 백서를 참조하십시오.