성공적인 소프트웨어 개발을 위한 '의존성 최소화' 전략: TigerBeetle 사례와 5가지 평가 기준

핵심 기술: 본 콘텐츠는 외부 라이브러리 및 프레임워크 도입 시 발생하는 숨겨진 비용과 리스크를 경계하며, TigerBeetle의 '제로 의존성' 전략을 중심으로 의존성 관리에 대한 비판적 접근을 제시합니다. 보편성, 안정성, 깊이, 사용성, 완결성의 5가지 평가 기준으로 의존성을 신중하게 판단하는 것의 중요성을 강조합니다.

기술적 세부사항:
* 의존성 도입의 숨은 비용: 학습 부담, 인터페이스 변경에 따른 코드 수정, 복잡한 설치 및 배포 과정, API 변경 시 대규모 코드 수정, 공급망 공격 위험, 성능 저하, 설치 시간 증가 등을 포함합니다.
* TigerBeetle의 제로 의존성 전략: Vanilla Zig 기반의 재무 데이터베이스로, Zig 툴체인 외 외부 의존성을 두지 않아 보안 및 유지보수 이점을 추구합니다.
* 의존성 평가 5가지 기준:
* 보편성(Ubiquity): 대상 환경에 사전 설치되어 있을 확률, 별도 번들 필요성 여부.
* 안정성(Stability): 호환성 깨짐, API 변경 빈도, 지원 중단 등 이슈 발생 빈도.
* 깊이(Depth): 제공하는 기능의 레이어 수준과 대체 구현의 난이도.
* 사용성(Ergonomics): API 직관성, 문서화 현황.
* 완결성(Watertightness): 추상화 수준 및 하위 레이어 신경 쓸 필요성.
* 일반적인 의존성 평가의 문제점: 커뮤니티는 주로 사용성만 논의하며 나머지 네 가지는 간과하는 경향이 있음을 지적합니다.
* 예시: POSIX, ECMA-48, 웹 플랫폼 등의 시스템 인터페이스와 C, C++ 표준 라이브러리의 특성을 5가지 기준으로 평가합니다.
* 의존성 관리 실천 방안: 오픈소스 의존성만 고려, 다각적 검토(라이선스, 제거 노력, 보안 취약점, 버그 이력, 업데이트 지속성, 커뮤니티 활력), 주기적 보안 이슈 검사, 유지/포크 부담 감당 가능한 의존성 도입, 소스 수준 포크 등을 제안합니다.

개발 임팩트:
* 의존성 도입 시 전체 시스템의 잠재적 위험과 비용을 고려하여 장기적인 유지보수성과 안정성을 확보할 수 있습니다.
* 불필요한 의존성을 줄여 코드 복잡성을 낮추고, 보안 취약점 노출 가능성을 최소화할 수 있습니다.
* 개발자가 자체 기능을 구현하는 능력을 향상시키고, 외부 의존성에 대한 비판적 사고를 함양할 수 있습니다.

커뮤니티 반응:
* TigerBeetle의 접근 방식은 특정 고성능 요구사항(금융, CPU 한 코어 백만 트랜잭션)에는 합리적이지만, 일반적인 CRUD 시스템 개발자에게는 과도한 주장일 수 있다는 의견이 있습니다.
* 대부분의 의존성이 직접 구현하는 것보다 품질이 높을 수 있으며, 기업의 병목은 개발자 충원에 있다는 반론도 존재합니다.
* 시스템 인터페이스(POSIX, ECMA-48)와 라이브러리 의존성은 구분해야 하며, 시스템 인터페이스는 변경이 어렵다는 점을 지적합니다.
* 개발자 수준과 무관하게, 남이 만든 의존성을 사용하는 것은 일반적이며, 규제 요건이나 개인적 관심이 의존성 집착으로 이어질 수 있다는 의견이 있습니다.
* NIH(Not Invented Here)는 특정 도메인에 맞는 프레임워크 제작 등에 유용하나, 데이터베이스, 게임 엔진 등은 신중해야 한다는 주장과 함께, 오히려 단순 파일/인덱스만으로 충분한 경우도 많다는 반론이 제시되었습니다.
* 의존성 도입 시 발생하는 벤더 락인(Vendor Lock-in) 및 유료 의존성의 위험성에 대한 논의가 활발하며, 오픈 표준 및 대체 구현체의 중요성을 강조합니다.