0deps 운동 — 로컬 종속성, 불변 계약 및 설계에 의한 보안

수년 동안 소프트웨어 산업은 거의 모든 프로젝트에 수십 개, 심지어 수백 개의 외부 라이브러리를 설치하는 문화를 채택해 왔습니다. 현대적인 프레임워크는 종종 수천 개의 전이적 종속성 (transitive dependencies)에 의존하며, 이는 단 하나의 애플리케이션이 결과적으로 수백 명의 알 수 없는 기여자들에 의해 유지 관리되는 코드에 의존할 수 있음을 의미합니다.

이러한 생태계는 소프트웨어 개발을 상당히 가속화했지만, 동시에 새로운 범주의 위험인 **소프트웨어 공급망 (Software Supply Chain)**을 도입했습니다.

0deps 운동은 다음과 같은 단순한 질문에서 시작되었습니다:

만약 애플리케이션이 실제로 제어하는 코드에만 의존한다면 어떻게 될까?

종속성의 문제

각 종속성은 공격 표면 (attack surface)을 증가시킵니다.

종속성은 다음과 같은 문제를 일으킬 수 있습니다:

• 보안 취약점 (vulnerabilities) 유입
• 공급망 공격의 대상이 됨
• 관리 중단 (abandoned)
• 공개 API 수정
• 기능 삭제
• 하위 호환성 (backward compatibility) 파괴
• 새로운 전이적 종속성 추가
• 호환되지 않는 버전 배포

실제로 개발자들은 프로덕션 환경에서 실행되는 코드의 중요한 부분을 통제할 권한을 잃게 됩니다.

종속성 트리 (dependency tree)가 커질수록 잠재적인 공격 표면은 더 커집니다.

제안

0deps 모델에서는 필요한 모든 종속성이 프로젝트 저장소 (repository)에 직접 통합됩니다.

종속성은 더 이상 설치 또는 컴파일 시 패키지 관리자 (package managers)에 의해 동적으로 다운로드되지 않습니다.

애플리케이션을 빌드하고 실행하는 데 필요한 모든 것이 클론 (cloning) 직후부터 저장소에 이미 존재합니다.

이는 다음과 같은 몇 가지 주요 장점을 제공합니다:

• 재현 가능한 컴파일 (reproducible compilations).
• 외부 패키지 레지스트리 (package registries)에 대한 의존성 감소.
• 중앙 집중식 보안 감사 (security audit).
• 향상된 예측 가능성.
• 공급망 공격 표면 (attack surface) 감소.

불변의 공개 계약 (Immutable public contracts)

0deps의 근본 원칙은 구현 (implementation)을 고정하는 것이 아닙니다.

구현은 진화합니다.

알고리즘은 진화합니다.

보안 패치 (security patches)도 진화합니다.

변하지 않고 안정적으로 유지되는 것은 바로 **공개 계약 (public contract)**입니다.

각 라이브러리는 세심하게 설계된 공개 인터페이스 (public interface)를 노출합니다.

예를 들어:

authenticate()

createSession()
...

이 함수들은 하나의 계약을 정의합니다.

이 계약은 결코 변하지 않습니다.

기저의 구현 (underlying implementation)은 완전히 새로 작성될 수 있습니다.

알고리즘은 진화할 수 있습니다.

내부 라이브러리는 교체될 수 있습니다.

프로토콜은 진화할 수 있습니다.

데이터 구조 (data structures)는 재설계될 수 있습니다.

이러한 내부 변경 사항 중 그 어느 것도 애플리케이션의 나머지 부분이 라이브러리를 사용하는 방식에는 영향을 미치지 않습니다.

애플리케이션을 깨뜨리지 않는 보안 업데이트

취약점 (vulnerability)이 발견되면 일반적으로 두 가지 우려 사항이 발생합니다:

1. 취약점 수정.
2. 업데이트로 인해 얼마나 많은 애플리케이션이 영향을 받을지 결정하는 것.

0deps 아키텍처에서는 이 두 번째 우려 사항이 거의 완전히 사라집니다.

업데이트는 내부적으로 이루어집니다.

인터페이스 뒤의 구현이 수정됩니다.

공개 API는 정확히 동일하게 유지됩니다.

애플리케이션은 코드의 어떠한 수정 없이도 계속 작동합니다.

다시 말해, 계약은 안정적으로 유지되는 동안 구현은 진화합니다.

내부 어댑터 (Internal adapters)

모든 외부 통합은 내부 어댑터 (internal adapter) 뒤에 격리됩니다.

Application

↓
...

만약 외부 라이브러리가 내일 노후화되거나 사라지더라도, 어댑터만 수정하면 됩니다.

애플리케이션의 다른 어떤 부분도 영향을 받지 않습니다.

이러한 격리는 기술적 변화의 영향을 상당히 줄여줍니다.

보이지 않는 버전 관리 (Un versionnement invisible)

0deps 모델에 따라 구축된 애플리케이션은 외부 라이브러리의 API와 직접 상호작용하지 않습니다.

이들은 오직 안정적인 내부 계약 (internal contracts)하고만 통신합니다.

라이브러리의 버전은 단순한 구현 세부 사항이 됩니다.

프레임워크 유지 관리자가 업데이트를 담당합니다.

애플리케이션 개발자는 내부 변경 사항과 관계없이 정확히 동일한 인터페이스를 계속 사용할 수 있습니다.

공급망 보안 (Sécurité de la chaîne d'approvisionnement)

0deps의 목표는 소프트웨어가 무결해질 수 있다고 주장하는 것이 아닙니다.

그 목표는 소프트웨어 공급망 (software supply chain)과 관련된 리스크를 유의미하게 줄이는 것입니다.

컴파일 시 종속성 (dependencies)의 동적 설치를 제거함으로써, 이 아키텍처는 다음과 같은 위협에 대한 노출을 줄입니다:

• 악성 패키지 배포 (malicious packages).
• 패키지 레지스트리 (package registries) 침해.
• 의존성 혼란 (dependency confusion) 공격.
• 타이포스쿼팅 (typosquatting) 패키지.
• 전이적 종속성 (transitive dependencies)의 예기치 않은 변경.

이제 모든 실행 가능한 코드는 프로젝트의 필수적인 일부가 되며, 이를 통해 중앙 집중식 보안 감사 (audit), 버전 관리 및 검토가 가능해집니다.

장기적인 안정성 (Une stabilité à long terme)

0deps의 주요 이점은 프로젝트가 프로덕션에 배포된 후 몇 년이 지나서야 진정으로 드러납니다.

프로젝트는 수십 년 동안 지속됩니다.

라이브러리는 사라집니다.

프레임워크는 진화합니다.

생태계는 변합니다.

그럼에도 불구하고, 애플리케이션은 정확히 동일한 공개 계약 (public contracts)을 계속 사용합니다.

생태계의 변화를 추적하는 책임은 의존하는 모든 애플리케이션에 분산되는 대신, 프로젝트의 내부 어댑터 (internal adapters)로 중앙 집중화됩니다.

잠재적으로 파괴적인 업데이트는 단순한 구현체 교체(implementation replacements)가 됩니다.

운동 (The Movement)

**0deps 운동 (0deps Movement)**은 오픈 소스 소프트웨어에 반대하는 것이 아닙니다.

오히려 그 반대입니다.

이 운동은 오픈 소스의 엄청난 가치를 인정하는 동시에, 다른 소비 모델을 제안합니다.

라이브러리는 더 이상 동적으로 설치되는 의존성(dependencies)으로 간주되지 않습니다.

대신 프로젝트에 통합된 구성 요소가 되어, 감사(audited)되고, 버전 관리(versioned)되며, 안정적인 공개 계약(public contracts) 뒤에 캡슐화(encapsulated)됩니다.

그 결과, 소프트웨어는 더욱 예측 가능하고, 회복 탄력성(resilient)이 높으며, 유지보수가 용이해지고, 공급망 위험(supply chain risks)에 훨씬 덜 노출됩니다.

구현체(implementations)는 무한히 진화할 수 있습니다.

하지만 계약(contract)은 변하지 않은 채로 유지됩니다.

그리고 바로 이러한 안정성 덕분에 오늘날 개발된 애플리케이션들이 향후 수년 동안 정확히 동일한 방식으로 계속 작동할 수 있습니다.