맨위로가기

의존성 지옥

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
목차

1. 개요

의존성 지옥은 애플리케이션이 필요로 하는 라이브러리 간의 복잡한 관계에서 발생하는 문제로, 소프트웨어 설치 및 관리를 어렵게 만든다. 이는 많은 의존성, 긴 의존성 체인, 의존성 충돌, 순환 의존성, 패키지 관리자 의존성, 다이아몬드 의존성 등 다양한 형태로 나타난다. 해결책으로는 의존성 제거, 버전 번호 매기기, 애플리케이션별 개인 버전 사용, 여러 버전의 사이드 바이 사이드 설치, 스마트 패키지 관리, 설치 프로그램 옵션, 프로그래밍의 쉬운 적용성, 코드 개발 및 유지 관리의 엄격한 호환성 요구 사항, 소프트웨어 어플라이언스, 휴대용 애플리케이션 등이 있으며, 플랫폼별로 DLL 지옥, 확장 충돌, JAR 지옥, RPM 지옥과 같은 특정 문제로 나타나기도 한다.

더 읽어볼만한 페이지

  • 패키지 관리 시스템 - 패키지 관리자
    컴퓨터 프로그램의 설치, 업데이트, 제거를 자동화하는 패키지 관리자는 소프트웨어 패키지 관리, 의존성 관리, 설정 관리 기능을 제공하여 다양한 운영 체제와 프로그래밍 언어에서 활용된다.
  • 패키지 관리 시스템 - 제거 프로그램
    제거 프로그램은 컴퓨터에 설치된 소프트웨어를 완전히 제거하기 위해 로거, 제거 프로그램, 분석기, 감시자 등의 도구를 활용하며, 설치 기록을 바탕으로 프로그램 및 관련 파일을 삭제하고 레지스트리를 정리하는 기능을 제공한다.
  • 버전 관리 시스템 - 미디어위키
    미디어위키는 위키백과 등 위키미디어 재단 프로젝트에서 사용되는 PHP 기반의 자유 소프트웨어 위키 엔진으로, 확장성, 다양한 기능, 사용자 지정 용이성 등을 바탕으로 위키 기반 웹사이트 구축 및 관리에 기여한다.
  • 버전 관리 시스템 - 깃 (소프트웨어)
    깃은 리누스 토르발스가 개발한 분산 버전 관리 시스템으로, 빠른 분기 및 병합, 분산 개발 환경 지원, 대규모 프로젝트 처리 효율성 등의 특징을 가지며, 깃허브, 깃랩 등에서 서비스되며 소프트웨어 개발 분야에서 널리 사용된다.
  • 안티패턴 - 기술 부채
    기술 부채는 소프트웨어 개발에서 발생하는 개념으로, 현재의 편의적인 설계가 미래에 추가적인 비용을 발생시키는 것을 의미하며, 다양한 원인으로 발생하여 개발 비용 증가, 프로젝트 지연, 경쟁력 약화 등의 부정적인 결과를 초래할 수 있다.
  • 안티패턴 - 난독화
    난독화는 프로그램 코드의 가독성을 낮춰 이해를 어렵게 하는 기술로, 역공학을 방지하여 보안을 강화하며 소스 코드와 바이너리 난독화로 구분되고, 코드 분석을 어렵게 만들지만 불가능하게 하지는 않아 다른 보안 기술과 함께 사용된다.
의존성 지옥

2. 문제점

의존성 지옥은 소프트웨어의 설치, 실행, 유지보수를 어렵게 만드는 다양한 형태로 나타난다. 주요 문제점은 다음과 같다.


  • 많은 의존성: 애플리케이션이 너무 많은 라이브러리에 의존하면 설치 및 관리가 어려워진다.[2]
  • 긴 의존성 체인: 한 라이브러리가 다른 라이브러리에 의존하고, 그 라이브러리가 또 다른 라이브러리에 의존하는 식으로 연쇄적인 의존 관계가 발생하면 문제가 복잡해진다.[3]
  • 의존성 충돌: 서로 다른 애플리케이션이 동일한 라이브러리의 다른 버전을 요구할 때 발생한다.[3]
  • 순환 의존성: 애플리케이션 A가 애플리케이션 B에 의존하고, 동시에 애플리케이션 B가 애플리케이션 A에 의존하는 상황이다.
  • 패키지 관리자 의존성: 패키지 관리자 자체의 문제로 인해 발생하기도 한다.[9]
  • 다이아몬드 의존성: 라이브러리 A가 라이브러리 B와 C에 의존하고, B와 C는 모두 라이브러리 D에 의존하지만, B는 D의 특정 버전을, C는 D의 다른 버전을 요구하는 경우 발생한다.[4]

2. 1. 많은 의존성

애플리케이션이 많은 라이브러리에 의존하게 되면, 다운로드 시간이 길어지고, 많은 디스크 공간을 차지하며, 이식성이 낮아지는 문제가 발생한다. 모든 의존성을 찾는 것이 어려울 수 있는데, 이는 저장소를 통해 해결할 수 있지만, 부분적으로 불가피한 측면도 있다.[2]

Java와 같은 특정 컴퓨팅 플랫폼을 기반으로 구축된 애플리케이션은 해당 플랫폼이 설치되어야 하지만, 추가적인 애플리케이션은 이를 필요로 하지 않는다. 애플리케이션이 큰 라이브러리의 작은 부분만 사용하거나, 간단한 애플리케이션이 많은 라이브러리에 의존하는 경우 특히 문제가 된다. 이는 코드 리팩토링을 통해 해결할 수 있다.[2]

2. 2. 긴 의존성 체인

어떤 응용 프로그램(앱)이 특정 라이브러리를 사용하고, 그 라이브러리가 또 다른 라이브러리를 사용하는 식으로 의존 관계가 계속 이어지는 경우를 말한다.[3] 사용자는 앱을 설치하기 위해 여러 라이브러리를 순차적으로 설치해야 한다.

예를 들어, `app`이 `liba`에 의존하고, `liba`는 `libb`에 의존하고, ..., `libb`는 `libz`에 의존하는 상황이다. 사용자가 `app`을 설치하려면 `liba`를 먼저 설치해야 하고, `liba`를 설치하려면 `libb`를 설치해야 하는 식으로 계속 진행된다.[3]

이러한 긴 의존성 체인은 패키지 관리자를 사용하면 자동으로 해결될 수 있다. 하지만, 수동으로 해결해야 하는 경우에는 의존성 순환이나 충돌을 가릴 수 있어 문제가 복잡해질 수 있다.[3] 특히, 긴 의존성 체인 중에 동일한 패키지의 서로 다른 버전이 필요한 충돌이 발생할 수 있다.[3]

2. 3. 의존성 충돌

"응용 프로그램 1"이 "가 라이브러리 1.0"에 의존하고, "응용 프로그램 2"가 "가 라이브러리 1.1"에 의존하는 동시에, 서로 다른 버전의 "가 라이브러리"가 동시에 설치될 수 없는 경우가 있다. 이때 "응용 프로그램 1"과 "응용 프로그램 2"는 동시에 실행되거나, 심지어 동시에 설치될 수 없다.[3]

하나의 소프트웨어에 대한 의존성을 해결하면 마치 두더지 게임과 유사하게 다른 소프트웨어의 호환성이 깨질 수 있다. 예를 들어 `app1`이 `libfoo 1.2`에 의존하고, `app2`가 `libfoo 1.3`에 의존하며, `libfoo`의 다른 버전을 동시에 설치할 수 없는 경우, `app1`과 `app2`는 동시에 사용할 수 없다. 이 문제는 다른 의존성을 동시에 설치할 수 있도록 하거나, 기존 의존성과 이에 의존하는 모든 소프트웨어를 제거한 후에 새로운 의존성을 설치해야 해결할 수 있다.

리눅스 시스템에서는 다른 배포판에서 패키지를 설치할 때, 결과적으로 긴 의존성 체인이 수천 개의 패키지가 의존하는 C 표준 라이브러리(예: GNU C 라이브러리)의 충돌 버전을 초래할 수 있다. 이 경우 사용자에게 해당 패키지를 모두 제거하라는 메시지가 표시된다.

2. 4. 순환 의존성

가 의 특정 버전에 의존하고 없이는 실행할 수 없지만, 는 차례로 의 특정 버전에 의존하고 없이는 실행할 수 없는 경우가 순환 의존성에 해당한다. 어느 애플리케이션을 업그레이드해도 다른 애플리케이션이 깨지는 문제가 발생한다.[3] 이 문제는 핵심 시스템이나 업데이트 소프트웨어 자체에 영향을 미치는 경우 매우 심각한 결과를 초래할 수 있다. 예를 들어, 패키지 관리자(A)가 특정 런타임 라이브러리(B)가 작동해야 하는데, 이 라이브러리(B)를 다음 버전으로 업그레이드하는 과정에서 스스로(A) 깨질 수 있다. 이 경우 잘못된 라이브러리(B) 버전으로 인해 패키지 관리자(A)가 깨져서 라이브러리(B)의 롤백 또는 다운그레이드가 불가능해진다.

2. 5. 패키지 관리자 의존성

APT와 같은 패키지 관리자를 통해 준비된 패키지를 설치하여 의존성 지옥이 발생할 수 있지만[9], 주요 패키지 관리자가 성숙되고 공식 저장소가 잘 관리되어 있어 그럴 가능성은 낮다. 이는 데비안의 현재 릴리스와 우분투와 같은 주요 파생 제품의 경우에 해당한다. 그러나 의존성 지옥은 RPM 또는 dpkg와 같은 패키지 설치 프로그램을 통해 직접 패키지를 설치하여 발생할 수 있다.

yum과 같은 패키지 관리자는[4] 해당 저장소의 패키지 간에 충돌이 발생하기 쉬우며, CentOS 및 Red Hat Enterprise Linux와 같은 Linux 배포판에서 의존성 지옥을 유발한다.

2. 6. 다이아몬드 의존성

어떤 라이브러리 A가 라이브러리 B와 C에 의존하고, B와 C는 모두 라이브러리 D에 의존하는 경우가 있다. 이때 B는 D의 버전 D.1을 요구하고 C는 D의 버전 D.2를 요구한다면, 최종 실행 파일에는 D의 한 가지 버전만 존재할 수 있기 때문에 빌드가 실패한다.[4]

3. 해결책

의존성 지옥은 소프트웨어 개발 과정에서 발생하는 문제로, 이를 해결하기 위한 다양한 방법들이 존재한다. 각 해결책은 장단점을 가지므로, 상황에 맞게 적절한 방법을 선택해야 한다. 주요 해결책은 다음과 같다:


  • 의존성 제거: 소프트웨어 라이브러리에서 불필요한 기능을 제거하고 코드를 간결하게 재작성하여 의존성을 줄이는 방법이다.
  • 버전 번호 매기기: 주 버전, 부 버전과 같은 표준화된 버전 번호 체계를 사용하여 호환성을 관리한다. SemVer가 대표적인 예시이다.
  • 애플리케이션별 개인 버전: Windows 2000의 Windows 파일 보호처럼 애플리케이션마다 별도의 라이브러리 사본을 사용하여 시스템 DLL과의 충돌을 방지한다.
  • 여러 버전의 사이드 바이 사이드 설치: 마이크로소프트 윈도우의 글로벌 어셈블리 캐시, 젠투 리눅스의 슬롯팅과 같이 운영 체제 지원을 통해 동일한 라이브러리의 여러 버전을 동시에 설치하고 관리한다.
  • 스마트 패키지 관리: 패키지 관리자가 상호 의존적인 소프트웨어 구성 요소를 동시에 업그레이드하여 주 버전 비호환성 문제를 해결한다. 리눅스 배포판의 Apt, Yum 등이 이 기능을 제공한다.
  • 설치 프로그램 옵션: 데비안의 APT처럼 사용자가 의존성 해결 방법을 선택하거나 거부할 수 있도록 다양한 옵션을 제공한다.
  • 프로그래밍의 쉬운 적용성: 응용 소프트웨어가 OS, 창 관리자, 데스크톱 환경 등의 변화에 쉽게 적응할 수 있도록 설계하여, 프로그래머가 최소한의 노력으로 업데이트를 제공할 수 있게 한다.
  • 엄격한 하위 호환성: 응용 프로그램과 라이브러리가 하위 호환성을 보장하도록 개발 및 유지 관리하여, 패키지 관리 및 설치를 용이하게 한다.
  • 소프트웨어 어플라이언스: 컨테이너(Docker 등)와 같이 의존성이 미리 통합된 자체 포함 단위를 제공하여 사용자가 의존성 문제를 해결할 필요가 없도록 한다.
  • 휴대용 애플리케이션: 실행에 필요한 모든 구성 요소를 자체적으로 포함하거나 자체 디렉토리에 보관하여 의존성 문제를 방지한다.

3. 1. 의존성 제거

많은 소프트웨어 라이브러리는 사용자의 요구 사항을 최대한 충족시키기 위해 관대하게 작성되지만, 호스트 코드에서는 일부 기능만 필요한 경우가 있다. 소스를 검토하면 (라이선스에 따라) 기능을 훨씬 더 간결하게 다시 작성할 수 있다. 이는 애플리케이션 코드를 크게 줄이고, 이후 유지 관리 비용을 절감하며, 프로그래머의 소프트웨어 작성 기술을 향상시킬 수 있다.[5]

3. 2. 버전 번호 매기기

이 문제에 대한 매우 일반적인 해결책은 표준화된 번호 매기기 시스템을 사용하는 것이다. 이 시스템에서 소프트웨어는 각 버전(일명 ''주 버전'')에 특정 번호를 사용하고 각 개정판(일명 ''부 버전'')에 하위 번호를 사용한다(예: 10.1 또는 5.7).[5] 주 버전은 해당 버전을 사용한 프로그램이 더 이상 호환되지 않을 때만 변경된다. 부 버전은 다른 소프트웨어가 문제없이 작동하는 간단한 개정판으로도 변경될 수 있다. 이와 같은 경우, 소프트웨어 패키지는 특정 주 버전과 ''모든'' 부 버전(특정 부 버전 이상)을 가진 구성 요소를 간단히 요청할 수 있다. 따라서 부 버전이 변경되더라도 계속 작동하며 종속성이 성공적으로 해결된다. 시맨틱 버전 관리(일명 "SemVer")는 소프트웨어 버전 관리 체계를 만들기 위해 특별히 형식이 지정된 숫자를 사용하는 기술 사양을 생성하려는 노력의 한 예이다.[5]

3. 3. 애플리케이션별 개인 버전

Windows 2000에 도입된 Windows 파일 보호는 애플리케이션이 시스템 DLL을 덮어쓰는 것을 방지했다. 대신 개발자는 애플리케이션 디렉터리에 애플리케이션별 라이브러리의 사본인 "개인 DLL"을 사용하도록 권장되었다.[6] 이는 로컬 경로가 시스템 전체 라이브러리가 있는 시스템 디렉터리보다 항상 우선 순위가 지정되는 Windows 검색 경로 특성을 이용한 것이다. 이를 통해 특정 애플리케이션 버전별로 라이브러리 버전의 쉽고 효과적인 섀도잉이 가능하므로 의존성 지옥을 방지할 수 있다.[6]

PC-BSD는 TrueOS(FreeBSD를 기반으로 하는 운영 체제)의 이전 버전으로, 8.2 버전을 포함하여 시스템 라이브러리가 업그레이드되거나 변경될 경우 중단을 방지하기 위해 패키지와 종속성을 ''/Programs''의 자체 포함 디렉터리에 배치했다. 자체 "PBI"(Push Button Installer)를 패키지 관리에 사용했다.[7]

3. 4. 여러 버전의 사이드 바이 사이드 설치

버전 번호 매기기 솔루션은 운영 체제 지원 기능으로 버전 번호를 높여 개선할 수 있다. 이를 통해 애플리케이션은 고유한 이름과 버전 번호 제약 조건으로 모듈/라이브러리를 요청할 수 있으며, 애플리케이션에서 운영 체제로 라이브러리/모듈 버전 브로커링 책임을 효과적으로 이전할 수 있다. 그러면 공유 모듈을 이전 또는 이후 버전의 모듈에 의존하는 애플리케이션을 손상시킬 위험 없이 중앙 저장소에 배치할 수 있다. 각 버전은 동일한 모듈의 다른 버전과 나란히 자체 항목을 갖는다.[8]

이 솔루션은 마이크로소프트 윈도우 운영 체제(Windows Vista부터)에서 사용되며, 여기서 글로벌 어셈블리 캐시는 이러한 중앙 레지스트리의 구현으로 관련 서비스와 설치 시스템/패키지 관리자와 통합된다. 젠투 리눅스는 슬롯팅이라는 개념으로 이 문제를 해결하며, 이를 통해 공유 라이브러리의 여러 버전을 설치할 수 있다.[8]

3. 5. 스마트 패키지 관리

일부 패키지 관리자는 스마트 업그레이드를 수행할 수 있다. 여기서 상호 의존적인 소프트웨어 구성 요소가 동시에 업그레이드되어 주 버전 비호환성 문제도 해결된다.[9]

많은 리눅스 배포판은 의존성 문제를 해결하기 위해 저장소 기반 패키지 관리 시스템을 구현했다. 이러한 시스템은 RPM, dpkg 또는 미리 정의된 소프트웨어 저장소에서 검색하여 종속성을 자동으로 해결하도록 설계된 다른 패키징 시스템의 계층이다. 이러한 시스템의 예로는 Apt, Yum, Urpmi, ZYpp, Portage, Pacman 등이 있다. 일반적으로 소프트웨어 저장소는 FTP 사이트나 웹사이트, 로컬 컴퓨터의 디렉터리, 네트워크를 통해 공유되거나, 드물게 CD나 DVD와 같은 이동식 미디어의 디렉터리 형태를 가진다. 이를 통해 리눅스 배포 제공자가 유지 관리하고 전 세계적으로 미러링되는 해당 저장소에 패키지된 소프트웨어에 대한 의존성 지옥을 제거한다. 그러나 이러한 저장소는 방대하지만 모든 소프트웨어를 포함할 수는 없으므로, 의존성 지옥이 발생할 수 있다. 어떤 경우든 저장소 관리자는 여전히 의존성 지옥에 직면한다.[9]

3. 6. 설치 프로그램 옵션

소프트웨어의 각 부분은 서로 다른 종속성을 갖는다. 따라서 새로운 패키지를 설치할 때마다 더 많은 설치를 요구하게 되어, 종속성 요구 사항의 악순환 또는 끊임없이 확장되는 트리 형태의 요구사항에 빠질 수 있다. 이러한 문제를 해결하기 위해 데비안(Debian)의 APT와 같은 시스템은 사용자에게 다양한 해결책을 제시하고, 사용자가 원하는 해결책을 선택하거나 거부할 수 있도록 한다.[9]

3. 7. 프로그래밍의 쉬운 적용성

응용 소프트웨어가 프로그래머가 OS, 창 관리자 또는 데스크톱 환경과 관련된 인터페이스 계층을 새롭거나 변경되는 표준에 쉽게 적용할 수 있도록 설계되면, 프로그래머는 환경 제작자 또는 구성 요소 라이브러리 설계자의 알림을 모니터링하고 최소한의 노력으로 소프트웨어를 빠르게 업데이트할 수 있다. 이를 통해 사용자들은 시간과 비용이 많이 드는 재설계 없이도 변화하는 환경에 적응할 수 있다. 이 방법은 프로그래머가 관련 모든 사람에게 부담이 되지 않는 합리적인 알림 프로세스를 유지하도록 의존하는 이들에게 압력을 가하도록 장려한다.

3. 8. 코드 개발 및 유지 관리의 엄격한 호환성 요구 사항

응용 프로그램과 라이브러리가 하위 호환성을 보장하도록 개발 및 유지 관리되면, 기존 프로그램을 손상시키지 않고 언제든지 새 버전으로 교체할 수 있다. 이는 수많은 의존성을 완화하지는 않지만, 패키지 관리자나 설치 프로그램의 작업을 훨씬 쉽게 만든다.[9]

3. 9. 소프트웨어 어플라이언스

의존성 문제를 피하는 또 다른 방법은 응용 프로그램을 소프트웨어 어플라이언스로 배포하는 것이다. 소프트웨어 어플라이언스는 의존성을 미리 통합된 자체 포함 단위로 캡슐화하여 사용자가 더 이상 소프트웨어 의존성을 해결하는 것에 대해 걱정할 필요가 없도록 한다.[9] 대신 부담은 소프트웨어 어플라이언스 개발자에게 이전된다. 컨테이너 및 해당 이미지(예: Docker 및 Docker Hub에서 제공하는 것)는 소프트웨어 어플라이언스의 구현으로 볼 수 있다.

3. 10. 휴대용 애플리케이션

휴대용 애플리케이션(Portable application)은 실행에 필요한 모든 구성 요소를 자체적으로 포함하거나, 필요한 모든 파일을 자체 디렉토리에 보관하도록 설계되어 의존성 문제를 일으키지 않는다. 이러한 애플리케이션은 연결된 시스템과 독립적으로 실행될 수 있다.[10]

RISC OS의 애플리케이션과 리눅스용 ROX 데스크톱은 애플리케이션 디렉토리를 사용하는데, 이는 프로그램과 그 종속성이 자체 디렉토리(폴더)에 포함된다는 점에서 유사하게 작동한다.[10]

이러한 방식은 유닉스 계열 플랫폼용으로 설계된 애플리케이션을 윈도우로 포팅할 때 유용하다. 예를 들어, gedit, GIMP, HexChat의 윈도우 설치 프로그램은 모두 위젯 렌더링에 사용되는 GTK 툴킷의 동일한 사본을 포함한다. 각 애플리케이션에 다른 버전의 GTK가 필요한 경우, 이는 올바른 동작이며 의존성 지옥을 방지하는 것이다.[10]

4. 플랫폼별 문제

특정 컴퓨팅 플랫폼에서 "의존성 지옥"은 종종 지역 고유의 이름, 일반적으로 구성 요소의 이름으로 불린다.

4. 1. DLL 지옥

DLL 지옥은 16비트 마이크로소프트 윈도우에서 발생하는 의존성 문제의 한 형태이다.

4. 2. 확장 충돌

클래식 Mac OS에서 발생하는 의존성 문제이다.

4. 3. JAR 지옥

아파치 메이븐과 같은 빌드 도구가 2004년에 이 문제를 해결하기 전 자바 런타임 환경에서 발생하는 의존성 지옥의 한 형태이다.

4. 4. RPM 지옥

RPM 지옥은 리눅스의 레드햇 배포판과 RPM을 패키지 관리자로 사용하는 다른 배포판에서 발생하는 의존성 문제이다.

참조

[1] 서적 Linux annoyances for geeks https://archive.org/[...] O'Reilly Media 2012-02-16
[2] 웹사이트 Improved Portability of Shared Libraries http://www.princeton[...] Princeton University 2003-01-25
[3] 간행물 It's Good Work When You Can Find It; The Dependency Carousel http://www.drdobbs.c[...] www.drdobbs.com/blog 2001-05-01
[4] 웹사이트 Yum Dependency Hell http://www.techbrown[...] 2015-12-28
[5] 웹사이트 Project website: semver.org https://semver.org
[6] 웹사이트 The End of DLL Hell http://msdn.microsof[...] microsoft.com 2000-01-11
[7] 문서 pbiDIR https://web.archive.[...]
[8] 문서 Slotting https://devmanual.ge[...] gentoo.org
[9] 웹사이트 Nix fixes dependency hell on all Linux distributions http://archive09.lin[...] linux.com 2008-12-22
[10] 웹사이트 Application directories http://rox.sourcefor[...] 2013-09-07
[11] 웹사이트 Is Linux Annoying? http://linuxdevcente[...] linuxdevcenter.com 2003-09-11
[12] 서적 Linux annoyances for geeks https://books.google[...] O'Reilly Media 2012-02-16


본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com