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

컴포넌트 라이브러리를 구축할 것인가, 아니면 구매할 것인가? 이 질문은 개발자와 개발 관리자들이 자주 다루는 문제입니다. 효율성과 일관성이 전부가 될 때, 결정은 단순한 선호 이상의 문제가 됩니다. 기술 전략을 장기적인 비즈니스 목표와 일치시키는 것입니다.

그래서 이 글의 목표는 소프트웨어 엔지니어들이 비용이 들지 않는 다양한 UI 컴포넌트 라이브러리 중에서 선택할 때 결정을 내릴 수 있도록 돕는 것입니다:

• 그들의 시간– 촉박한 마감일 속에서 밀린 업무를 처리하느라 종종 낭비됩니다.
• 예산은 부족 하고, 추가 자원이 필요할 때 보통 통제할 수 없는 상황입니다.
• 자신의 기술에 대한 자신감– 사실 그들은 극히 틈새 앱의 특정 목적을 위해 서드파티 UI 라이브러리를 사용할 수 없습니다. 또한 예를 들어, 다른 개발자가 동시에 여러 기능을 지원해야 하는 다른 선택된 컴포넌트를 동시에 처리하는 동안 Angular 피벗 그리드를 처음부터 만들 수도 없습니다. 결국 두 가지 요소가 UI와 UX에서 충돌하게 됩니다.

어디서부터 시작해야 하고, UI 컴포넌트 라이브러리를 선택할 때 무엇을 고려해야 할까요?

필요, 목적, 기술, 앱 유형 등 핵심 요소를 다룰 때, 개발 처리 옵션은 다음과 같이 요약됩니다:

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

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

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

1.회사 규모와 팀 

컴포넌트 라이브러리를 구축할지 구매할지 결정하기 전에, 회사 규모, 팀 구성, 그리고 달성하고자 하는 목표를 생각해 보세요.  최선의 선택은 팀이 어떻게 일하는지, 이미 가지고 있는 도구들, 그리고 확장성과 일관성이 얼마나 중요한지에 달려 있습니다.

중요한 질문:

• 디자인과 개발 사이에 공통 디자인 시스템이 있나요?
• 이미 어떤 애플리케이션 프레임워크나 UI 컴포넌트 라이브러리를 사용하고 계신가요?
• 앱 전달에 중요한 것은 무엇인가요 – 속도/시장 출시 시간, 개발자 생산성, 맞춤화, 아니면 장기 유지보수인가요?
• 팀/앱 간 일관성이 개발 과정을 더 효율적으로 만들까요?

2. 기술적 노하우와 경험 

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

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

• 과거에 생산용으로 복잡한 부품을 만든 적이 있나요?
• UI 컴포넌트 라이브러리에 매핑되는 기존 디자인 시스템이 있나요?
• 어떤 프레임워크와 기술과 함께 작동하나요?
• 오늘날 필요한 유지보수 노력은 얼마나 되며, 새로운 부품을 만드는 것이 이에 어떤 영향을 미칠까요?
• 기존 아키텍처와의 컴포넌트 통합을 어떻게 보장하고 있나요?

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

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

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

• 재사용 가능한 컴포넌트가 반복적인 작업을 없애고 코드베이스의 다른 영역에서 재사용을 장려할까요?
• 아니면 한 번뿐인, 매우 특수하고 특화된 사용 사례로, 다시는 사용하지 않아 여러 시나리오, 앱, 프로젝트에 적용되지 않는 건가요?
• 광범위한 맞춤화가 필요하고 엄격한 설계 요구사항을 준수하는 외부 고객을 위해 제작하고 계신가요?
• 기본 제공되는 데이터 그리드 기능과 기타 기능이 필요를 충족할까요, 아니면 사용자별로 더 많은 유연성과 맞춤화가 필요한가요?
• 더 빠른 앱 개발과 교차 기능 팀 간 협업을 개선하는 사내 시스템을 구축/유지 관리하고 있나요?
• 독특한 제품을 만들고 혁신하는 것이 목표라서, 언제든지 변경·업데이트할 수 있는 완전한 통제권과 무제한 시나리오/기능이 필요하다는 건가요?

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

이 섹션에서는 각 옵션을 7가지 요소로  필터링하고 각 옵션의 상충점을 강조할 것입니다.

요소 1: 부품 재사용 가능성 

이것은 특히 연속적인 프로젝트라면 프로젝트 간에 표준화를 이루는 데 큰 도움이 되며, 같은 코드를 여러 번 사용할 계획이라 수작업과 반복적인 작업을 줄일 계획입니다. 하지만 특히 Blazor 같은 비교적 새로운 프레임워크의 특정 컴포넌트는 처음부터 구축하기 특히 어렵습니다. 여기서 말하는 버튼이 아니야. 접근성 준수, 모든 종류의 열, 셀, 행 동작, 데이터 조작, 맞춤 시각화 등을 제공할 만큼 빠르고 포괄적일 수 있는 데이터 그리드를 생각해 보세요.

구성 요소 재사용 가능성	Advantages	Disadvantages
상업용 UI 라이브러리	다양한 개발자와 프로젝트를 지원하며; 빠른 문제 해결; 일관된 스타일링; 표준화를 가속화합니다.	초기 교육이 필요할 수 있으며; 틈새 기능은 구현하는 데 시간이 더 걸릴 수 있습니다.
내부 도서관	프로젝트 필요에 맞게 맞춤 제작; 기능 우선순위 집중; 내부 노하우를 얻었습니다.	제한된 재사용성; 문서가 부족하다; 접근성을 무시하고; 장기적인 유지보수 비용이 높습니다.
오픈 소스 소프트웨어(OSS)	지역사회 주도의 개선; 기능을 확장할 수 있는 유연성.	자주 버려지고; 기능이 빠진 것; 심한 디버깅과 일관성 없는 업데이트.

요인 2: 외부 의존성 

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

외부 종속	Advantages	Disadvantages
상업용 UI 라이브러리	의존성이 최소화되고; 공급업체가 관리 및 테스트; 복잡도가 낮습니다.	제3자 벤더 지원에 대한 의존도; 외부 수리는 시간이 걸릴 수 있습니다.
내부 도서관	의존성에 대한 완전한 통제.	구식 의존성은 복잡성을 증가시키며; 내부 보안 위험은 관리되어야 합니다.
오픈 소스 소프트웨어(OSS)	재사용 가능한 코드를 가진 대규모 생태계.	불분명한 의존 관계; 보안 취약점과 충돌 가능성.

요인 3: 업데이트 

여러분이나 개발팀이 하루, 매달, 연간 몇 번의 업데이트를 처리할 수 있나요...? 세 가지 옵션 각각에는 장단점이 분명히 있으니, 결정하기 전에 업데이트 측면에서 평가하는 것이 매우 중요합니다.

소프트웨어 업데이트	Advantages	Disadvantages
상업용 UI 라이브러리	프레임워크에 맞춘 정기적인 업데이트; 전담 팀이 관리하며; 안정성 검사를 받았다.	잦은 업데이트는 조정이 필요할 수 있습니다; 베타 버전은 일시적인 불안정성을 일으킬 수 있습니다.
내부 도서관	일관성 없는 유지보수; 작은 프로젝트는 종종 구식이거나 포기된 경우가 많습니다.	거의 업데이트되지 않았다; 빠르게 구식이 되었고; 내부 팀이 모든 유지보수를 담당해야 합니다.
오픈 소스 소프트웨어(OSS)	잘 관리된 프로젝트는 활발한 업데이트와 커뮤니티 지원이 있을 수 있습니다.	일관성 없는 유지보수; 작은 프로젝트들은 종종 구식이거나 방치된 경우가 많습니다.

요인 4: UI 라이브러리 문서 및 학습 자료 

데모, 구현된 구성 요소 예시, 추가 리소스 섹션, 지식 기반을 포함한 잘 작성된 포괄적인 문서가 핵심입니다. 코드를 문서화하지 않거나 이미 만들어진 코드가 없으면 드롭다운 리스트나 페이지네이터 하나조차 만들기 어려울 수 있습니다. DockManager 같은 복잡한 구성 요소나 Blazor Angular 금융/주식 차트 같은 복합 시각화는 말 할 것도 없습니다.

문서 및 학습 자료	Advantages	Disadvantages
상업용 UI 라이브러리	포괄적인 문서, 라이브 샘플 및 튜토리얼; 대규모 온라인 커뮤니티.	불완전하거나 부족한 문서; 불규칙한 업데이트는 학습 곡선을 증가시킵니다.
내부 도서관	맞춤형 지식은 회사 워크플로우에 적합합니다.	제한된 자원으로 인해 문서가 종종 소홀히 처리되었고; 신규 개발자의 어렵은 온보딩입니다.
오픈 소스 소프트웨어(OSS)	오픈 콜라보레이션; 커뮤니티가 기여한 가이드들입니다.	불완전하거나 부족한 문서; 불규칙한 업데이트가 학습 곡선을 증가시킵니다.

요소 5: 맞춤화 

앱에서 올 인(All in App)을 얻고 제공하는 데는 업데이트와 변경이 필요합니다. 그렇다면 UI 라이브러리는 얼마나 유연해야 하며, 얼마나 유연하게 만들 수 있을까요? 어떤 솔루션을 선택할 때 이 점을 간과하지 마세요. 다만 모두가 변경할 수 있는 매우 구성 가능한 컴포넌트나 기능이 유지보수가 어렵고, 아무도 익숙하지 않거나 구체적인 "것"을 망칠 수 있다는 점을 명심하세요. 그래서 예를 들어 Combo Box 컴포넌트보다 더 단순한 커스텀 Angular 컴포넌트를 가지고 있습니다.

맞춤화	Advantages	Disadvantages
상업용 UI 라이브러리	매우 쉽게 구성할 수 있습니다; 접근성, 테마 설정 및 디자인 시스템을 지원합니다; 로우코드 도구와 통합됩니다.	공급업체의 설계 범위에 의해 제한되며; 과도한 커스터마이징은 유지보수를 복잡하게 만들 수 있습니다.
내부 도서관	무제한 커스터마이징; 기능과 업데이트에 대한 완전한 통제권.	시간 집약적인 개발; 광범위한 테스트와 검증이 필요합니다.
오픈 소스 소프트웨어(OSS)	유연하고 수정 가능하며; 커뮤니티 확장 가능성.	단편화된 품질; 강력한 커뮤니티 지원 없이 일관성 없는 확장성.

요소 6: 기술 지원 

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

기술적 지원	Advantages	Disadvantages
상업용 UI 라이브러리	전담 지원팀; 시기적절한 전문적인 답변.	공급업체 SLA에 따라 다릅니다; 비근무 시간대 문제에 대한 유연성이 제한적입니다.
내부 도서관	창작자와 직접 연결해 빠른 디버깅을 할 수 있습니다.	전담 지원은 없었고; 내부 업무량은 시간이 지날수록 증가합니다.
오픈 소스 소프트웨어(OSS)	커뮤니티 협력과 열린 토론.	보장된 지원은 없고; 프로젝트 인기도와 자원봉사 시간에 따라 다릅니다.

요인 7: 비용, 라이선스, 투자 수익률(ROI) 

마지막으로, 모든 것이 얼마에 달려 있는지, 그리고 그 가격이 미래에 충분히 가치 있는지에 달려 있습니다.

비용, 라이선스 및 투자 수익률	Advantages	Disadvantages
상업용 UI 라이브러리	유연한 라이선스 플랜; 빈번한 업데이트; 장기 사용에 비용 효율적입니다.	초기 비용이나 연간 비용이 높을 수 있습니다; 체험판은 전체 기능 접근을 제한할 수 있습니다.
내부 도서관	초기 라이선스 비용 절감.	유지보수, 업그레이드, 문서화에 숨겨진 장기 비용; 전체 비용 대비 투자 대비 10배에서 50배 더 높습니다.
오픈 소스 소프트웨어(OSS)	무료 접근; 유연한 라이선스 모델.	지식재산권 및 라이선스 위험; 불확실한 투자 수익률(ROI); 커스터마이징과 유지보수 시간이 많이 걸립니다.

처음부터 만드는 숨겨진 비용

개발자들은 종종 '빌드'가 실제로 무엇을 의미하는지 과소평가합니다. 단순히 코딩 부품만이 아닙니다. 수년간 유지해야 합니다. 이 현실을 간과하는 팀은 내부 라이브러리가 출시되기도 전에 구식이 되는 경우가 많습니다. 이런 일이 발생하면 일관성이 무너집니다. 개발자들은 마감일을 맞추기 위해 외부 소스에서 컴포넌트를 가져오기 시작해 UI가 조각나고, 중복된 작업이 반복되며, 회복하기 어려운 장기적인 기술 부채가 생깁니다.

많은 팀이 자체 UI 컴포넌트 라이브러리를 구축하는 아이디어에 끌리지만, 그 범위와 복잡성을 종종 오해합니다. 또한 미묘한 매몰비용 오류도 작용하고 있습니다. 맞춤형 구성 요소에 시간과 노력을 투자한 후, 개발자들은 더 견고하고 비용 효율적인 서드파티 솔루션으로 교체하는 것을 주저하게 됩니다.

진정한 가치는 기본 구성 요소를 재창조하는 데 있는 것이 아니라, 비즈니스 목표에 부합하고 일관성을 보장하며 팀이 더 빠르게 혁신할 수 있도록 돕는 패턴 라이브러리를 만드는 데 있습니다. 하지만 개발자들은 너무 자주 공유된 디자인과 UX 패턴을 다듬기보다는 그리드, 드롭다운, 버튼 재구성에만 집중합니다.

내부적으로 구축한다는 것은 다음에 대해 전적인 책임을 지는 것을 의미합니다:

• 접근성, 브라우저 업데이트, 프레임워크 변경을 위한 지속적인 유지보수.
• 문서 작성, 신규 개발자 온보딩, 거버넌스 집행.
• 엔지니어가 기능을 구축하지 않고 인프라를 유지할 때 생산성이 떨어집니다.

DIY UI 컴포넌트 라이브러리는 성능, 유지보수 가능성, 테스트, 접근성을 간과하여 전략적 이점이 장기적인 운영 부담으로 전락합니다. 결과는? 유지에 비용이 많이 들고 진화하기 취약한 느리게 움직이는 시스템입니다.

나의 개인적인 견해와 왜 이 Ignite UI를 선택했는지

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

IT 팀이 불편한 소프트웨어 개발 프로세스에 의존하고 모든 것을 처음부터 만들어야 했던 시절은 오래전에 지나갔습니다.

외부 고객을 위한 앱 개발이든 사내 솔루션이든, UI 컴포넌트 라이브러리와 도구 세트에 대해 이야기하든 상관없습니다. 항상 똑같아. 만약 도구들이 테마, 반응성, a11y, 빠른 앱 개발 등 최신 원칙을 준수하면서 앱 개발을 가속화하고 용이하게 하며, 더 나은 UX를 달성할 수 있다면, 거의 선택의 여지가 없을 것입니다.

수백만 달러에 달하는 비용이 들고, 몇 달 또는 몇 년이 걸릴 수 있으며, 회사의 핵심 사업이나 도메인 전문성이 아닌 소프트웨어 개발 프로젝트를 승인해 줄 개발 매니저나 임원을 찾기 어려울 것입니다. 더 나쁜 것은, 생산 단계에 들어가기 전에는 완전히 구식이라는 점입니다. 결정이 몇 달 또는 몇 년 전에 내려졌기 때문에, 현대 UI 프레임워크는 새로운 기능, 보안 업데이트, 버그 수정이 포함된 여러 차례 출시되고 있습니다.

컴포넌트 라이브러리에 관해서는, 포괄적인 라이브러리가 대부분의 설계 및 애플리케이션 요구사항을 충족하며, 기대할 수 있는 내장된 확장성을 갖추고 있습니다. Angular, Blazor, React, Web Components 등 인기 있는 프레임워크를 위한 도구 상자를 제공하는 저희 Ignite UI 처럼요.

각 라이브러리는 모든 비즈니스에 적합한 지속적인 개선과 기능을 제공하며, 무엇보다도 프레임워크 간 일관성을 제공합니다. 저는 그리 드, 차트, 데이터 입력, 심지어 파일 내보내기 같은 수십 가지 구성 요소 중에서 선택할 수 있고, 여러분도 선택할 수 있습니다. 원하는 프레임워크로 어떤 것도 이룰 수 있도록 도와줄 강력한 커뮤니티의 일원이 될 수 있고, 개발자/디자이너로서 성장할 수 있으며, 회사에 상당한 비용 절감도 가져다줄 수 있습니다.

재사용 가능한 UI 컴포넌트 라이브러리의 ROI와 빌드 vs. 구매 비용에 대한 추가 정보는 저희 백서를 참고 하세요.