Movimiento 0deps — 로컬 의존성, 불변 계약 및 설계에 의한 보안

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

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

Movimiento 0deps는 단순한 질문에서 시작되었습니다:

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

의존성의 문제

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

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

• 보안 취약점 유입
• 공급망 공격의 표적이 됨
• 관리 중단 (abandoned)
• 공개 API 변경
• 기능 삭제
• 하위 호환성 파괴
• 새로운 전이적 의존성 (transitive dependencies) 포함
• 호환되지 않는 버전 배포

실제로 개발자들은 프로덕션에서 실행되는 코드의 상당 부분에 대한 통제력을 상실합니다.

의존성 트리 (dependency tree)가 커질수록 잠재적인 공격 표면도 커집니다.

제안

0deps 모델에서는 필요한 모든 의존성을 프로젝트 저장소 (repository)에 직접 포함합니다.

의존성은 설치 또는 컴파일 과정 중에 패키지 관리자 (package managers)를 통해 동적으로 다운로드되지 않습니다.

애플리케이션을 컴파일하고 실행하는 데 필요한 모든 것이 저장소를 클론 (clone)하는 시점부터 이미 저장소 내에 존재합니다.

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

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

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

0deps의 근본적인 원칙은 구현 (Implementation) 자체를 불변으로 만드는 것이 아닙니다.

구현은 진화합니다.

알고리즘은 진화합니다.

보안 패치도 진화합니다.

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

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

예를 들어:

authenticate()

createSession()

verifyPasskey()

sendMagicLink()

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

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

기저의 구현은 완전히 다시 작성될 수 있습니다.

알고리즘이 바뀔 수도 있습니다.

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

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

데이터 구조가 재설계될 수도 있습니다.

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

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

취약점이 발견될 때마다 보통 두 가지 고민이 생깁니다:

1. 취약점을 수정하는 것.
2. 업데이트 후에 얼마나 많은 애플리케이션이 작동을 멈출지 결정하는 것.

0deps 아키텍처 내에서는 두 번째 고민이 사실상 사라집니다.

업데이트는 내부적으로 수행됩니다.

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

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

애플리케이션은 코드를 수정할 필요 없이 계속 작동합니다.

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

내부 어댑터 (Internal adapters)

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

애플리케이션
↓
공개 인터페이스
↓
어댑터
↓
구현

만약 외부 라이브러리가 내일 당장 사라지거나 구식이 되더라도, 어댑터(adapter)만 수정하면 됩니다.

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

이러한 격리는 시간이 흐름에 따른 기술적 변화의 충격을 극적으로 줄여줍니다.

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

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

이들은 오직 안정적인 내부 계약(contracts)을 통해서만 통신합니다.

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

프레임워크 유지 관리자가 업데이트에 대한 책임을 집니다.

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

공급망 보안 (Seguridad de la cadena de suministro)

0deps의 목표는 소프트웨어를 무적(invulnerable)으로 만들겠다는 것이 아닙니다.

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

빌드 과정 중 의존성(dependencies)의 동적 설치를 제거함으로써, 이 아키텍처는 다음과 같은 위협에 대한 노출을 줄입니다:

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

모든 실행 가능한 코드는 프로젝트 자체의 일부가 되어, 중앙 집중식 감사(auditing), 버전 관리 및 보안 검토를 가능하게 합니다.

장기적 안정성 (Estabilidad a largo plazo)

0deps의 가장 큰 이점은 프로젝트가 프로덕션(production)에 투입된 지 몇 년이 지난 후에 명확해집니다.

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

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

프레임워크는 변합니다.

생태계는 진화합니다.

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

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

잠재적으로 파괴적인 업데이트들은 단순한 구현체 교체(implementation substitutions)로 변모합니다.

Movimiento (움직임)

Movimiento 0deps는 오픈 소스 소프트웨어에 반대하는 것이 아닙니다.

오히려 그 반대입니다.

자유 소프트웨어와 오픈 소스의 엄청난 가치를 인정하지만, 소비의 다른 모델을 제안합니다.

라이브러리는 동적으로 설치되는 의존성(dependencies)으로 취급되는 것을 멈춥니다.

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

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

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

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

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