DLL 지옥
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
1. 개요
DLL 지옥은 DLL(Dynamic Link Library) 사용 시 발생하는 문제로, 특히 여러 프로그램을 설치하고 제거하는 과정에서 시스템 DLL이 다른 버전으로 덮어씌워져 애플리케이션 실행에 문제가 생기는 현상을 의미한다. 윈도우 환경에서는 윈도우 2000부터 윈도우 파일 보호(WFP) 기능으로 DLL 덮어쓰기 문제가 해결되었지만, 이전에는 표준 DLL 버전 관리 부재, 소프트웨어 설치 방식의 문제, 비호환 DLL 허용 등으로 인해 문제가 발생했다. 이러한 문제를 해결하기 위해 마이크로소프트는 .NET Framework를 통해 사이드 바이 사이드(Side-by-side) 기술을 도입했고, 유닉스 계열 운영체제에서는 공유 라이브러리명에 버전 번호를 추가하는 방식으로 대응했다. DLL 지옥을 피하기 위해 레지스트레이션-프리 COM, 패키지 관리 시스템 사용, 라이브러리 중앙 관리, 정적 링크, 적절한 소프트웨어 디자인, 시스템 복원 등의 방법이 사용된다.
더 읽어볼만한 페이지
- 컴퓨터 특수용어 - FUD
FUD는 경쟁사의 제품이나 서비스에 대한 부정적인 정보를 퍼뜨려 소비자의 의사 결정을 왜곡하는 전략으로, 1970년대 IBM에서 유래하여 정보통신 기술, 정치, 광고 등 다양한 분야에서 사용되며 비판받는다. - 컴퓨터 특수용어 - 충돌 (컴퓨팅)
충돌은 프로그램 설계 결함, 운영체제 결함, CPU/GPU 과열, 메모리 오류 등으로 인해 소프트웨어가 비정상적으로 종료되거나 작동이 멈추는 현상으로, 데이터 손실, 시스템 불안정 등의 영향을 초래하여 자동 복구, 운영을 통한 완화, 충돌 보고 등의 기술이 사용된다. - 안티패턴 - 기술 부채
기술 부채는 소프트웨어 개발에서 발생하는 개념으로, 현재의 편의적인 설계가 미래에 추가적인 비용을 발생시키는 것을 의미하며, 다양한 원인으로 발생하여 개발 비용 증가, 프로젝트 지연, 경쟁력 약화 등의 부정적인 결과를 초래할 수 있다. - 안티패턴 - 난독화
난독화는 프로그램 코드의 가독성을 낮춰 이해를 어렵게 하는 기술로, 역공학을 방지하여 보안을 강화하며 소스 코드와 바이너리 난독화로 구분되고, 코드 분석을 어렵게 만들지만 불가능하게 하지는 않아 다른 보안 기술과 함께 사용된다. - 정보기술 용어 - 그리드 컴퓨팅
그리드 컴퓨팅은 지리적으로 분산된 컴퓨터 자원을 연결하여 가상 슈퍼컴퓨터를 구축하는 기술이며, 유휴 자원을 활용하고 과학 연구 등 다양한 분야에 활용된다. - 정보기술 용어 - 컴퓨터 클러스터
컴퓨터 클러스터는 여러 대의 상용 컴퓨터를 고속 네트워크로 연결하여 고성능 컴퓨팅 시스템을 구축하는 방식으로, 슈퍼컴퓨터를 포함한 다양한 분야에서 높은 가용성과 확장성을 제공하며, 클러스터 미들웨어를 통해 시스템 관리, 부하 분산, 통신 방식, 데이터 공유 등을 지원하고 노드 장애 관리를 위한 펜싱 기술을 활용한다.
| DLL 지옥 |
|---|
2. 문제점
DLL을 사용하면 여러 문제에 직면하게 되는데, 특히 시스템에 많은 프로그램을 설치하고 제거한 후에는 더욱 그렇다. 가장 일반적이고 까다로운 문제는 시스템 DLL이 다른 버전으로 덮어써져 일부 애플리케이션이 작동하지 않는 경우였다.
DLL 지옥은 원리적으로 동적 연결되는 라이브러리를 사용하는 모든 OS에서 발생할 수 있다. 가장 큰 문제는 "공유 라이브러리에 대해 호환성을 잃는 변경이 이루어졌을 때, 라이브러리를 호출하는 프로그램 측에서 이를 구분할 수 없다"는 점이다.
프로그램 유지 보수, 가독성 향상, 보안 문제 등으로 인해 불가피하게 사양이 변경되어 구 버전과의 호환성이 손실되는 경우가 종종 발생한다. 동적으로 링크되는 공유 라이브러리에서 이러한 호환성 문제가 발생하면, 해당 기능을 이용하는 애플리케이션 작동에 지장을 초래한다. 특히 OS 본체에 함께 제공되는 라이브러리에서 이러한 변경이 발생하면 그 영향 범위는 매우 넓다.
또한, 소프트웨어 설치 프로그램이 시스템 공유 라이브러리의 버전을 확인하지 않고 구 버전으로 덮어쓰는 경우에도 발생한다.
서드 파티 애플리케이션에서는 애플리케이션이 사용하는 라이브러리를 애플리케이션 본체와 같은 디렉토리에 배치하여 이 문제를 회피하려는 시도가 많았다. 그러나 실제로는 파일명이 동일한 라이브러리가 여러 하드 디스크에 존재할 때 어떤 라이브러리를 먼저 호출할지는 OS 설정(주로 환경 변수 PATH 설정)에 따라 달라져, 의도한 라이브러리와 다른 라이브러리가 우선적으로 호출되는 경우도 적지 않았다.
마이크로소프트는 .NET Framework에서 동일한 라이브러리의 서로 다른 여러 버전을 동시에 설치하고, 애플리케이션이 필요에 따라 사용할 라이브러리 버전을 명시적으로 지정할 수 있는 사이드 바이 사이드(Side-by-side)를 제공하는 등, 이 문제를 OS 레벨에서 해소하려 하고 있다.
2. 1. 윈도우 환경
마이크로소프트 윈도우에서는 DLL 덮어쓰기 문제, 일명 'DLL 스탐핑(DLL Stomping)'이 대표적인 DLL 지옥의 사례였다. 윈도우 2000부터 도입된 윈도우 파일 보호(Windows File Protection, WFP) 기능으로 DLL 덮어쓰기 문제는 대부분 해결되었다.[1] WFP가 있기 전에는 다음과 같은 원인들 때문에 DLL 호환 관련 문제가 발생했었다.- 의무적인 표준 DLL 버전 관리 방식과 이름 짓기, 파일 시스템 위치 스키마가 없었다.
- 의무적인 표준 소프트웨어 설치 방법이 없었다.
- DLL 애플리케이션 이진 인터페이스 관리를 위한 중앙 집중적인 권위 있는 지원이 없었다.
- 파일 이름이 같은 서로 호환되지 않는 DLL들을 허용할 수 있는 안전 장치가 없었다.
- 배포되는 버전 구별을 위한 내부 버전 번호가 없었다.
- 사용자가 의심스러운 DLL을 복사하거나, 기존의 DLL을 변경하는 것을 예방하는 간단한 관리 도구조차 없었다.
DLL 호환 문제 해결을 위한 '병렬식 컴포넌트 공유(Side-by-Side Component Sharing)' 같은 일부 예방 기법은 DLL의 복사본을 만들고, 각 버전의 DLL들이 필요에 따라 따로 메모리로 올려지도록 하기 때문에, DLL 공유에 따른 메모리 절약 효과가 감소하게 된다. 또한 버그 수정과 보안 업데이트 시에도 복잡성 증가 등의 영향을 받게 된다.
이전에는 프로그래머의 실수나 설치 프로그램의 문제로 인해 발생 빈도가 높았다. 특히 COM 컴포넌트에 관해서는, 마이크로소프트가 엄격한 버전 관리 규약을 규정하고 있음에도, 이 버전 관리 방식을 이해하지 못한 채 최종 사용자 시스템에 설치하는 개발자가 적지 않았다. 최근에는 시스템 보호 기능이나 사이드 바이 사이드 (Side-by-Side, SxS)라고 불리는 방식에 의해 줄어들고 있지만, 완전한 해결에는 이르지 못했다.
2. 2. 리눅스 및 기타 환경
리눅스에서는 DLL 지옥 대신 '의존성 지옥'이라는 용어를 사용한다. 이는 패키지 관리 시스템의 의존성 문제로 인해 발생한다.[1] 제임스 도널드(James Donald)는 2003년 논문에서 DLL 지옥이 마이크로소프트 윈도우보다 리눅스에서 더 심각하다고 주장했다.[1] 여러 리눅스 배포판들은 자체 패키징되지 않은 소프트웨어의 라이브러리 업데이트 문제로 어려움을 겪으며,[1] 일부 오픈 소스 라이브러리는 버전 변경에 따라 API가 변경되어 호환성 문제를 야기한다.[1]마이크로소프트 윈도우, 리눅스, OS X을 통틀어 의존성 지옥의 최근 사례로는 모질라 프로젝트에서 사용하는 게코 런타임 엔진(Gecko Runtime Engine, GRE)이 있다.[1] 모질라 재단이 발표하는 모든 소프트웨어 제품은 각각 자신만의 게코 런타임 엔진을 포함하는데, 이는 프로그래밍 인터페이스가 서로 충돌할 수 있는 환경이다.[1]
리눅스에서 대상 배포판과 다른 패키지를 사용하거나, 서드파티 패키지 관리 시스템이나 레포지토리를 사용함으로써 라이브러리의 의존 관계가 깨져, 유사한 현상이 발생하는 경우가 많다.[1]
유닉스 계열 운영 체제에서는 공유 라이브러리 이름에 버전 번호를 넣어, 버전 번호가 겹치지 않는 한 문제가 발생하지 않도록 한다.[2] 그러나 버전 번호에 나타나지 않는 변경이나, 같은 공유 라이브러리라도 다른 버전이 동시에 필요한 경우에는 문제가 발생한다.[2]
3. 사례
모질라 프로젝트에서 사용하는 게코 런타임 엔진(Gecko Runtime Engine, GRE)은 의존성 지옥의 대표적인 사례로 꼽힌다. 모질라 재단이 발표하는 모든 소프트웨어 제품은 각각 자신만의 게코 런타임 엔진을 포함하는데, 이는 프로그래밍 인터페이스가 서로 충돌할 수 있는 환경이기 때문이다. 따라서 사용자가 선더버드, 파이어폭스, 선버드를 설치하면, 사용자 시스템에는 세 개의 GRE가 복사된다. 이 세 개의 GRE는 언제 GRE의 소스 트리로부터 갈라졌는지에 따라 서로 호환될 수도, 호환되지 않을 수도 있다. 에피퍼니(Epiphany) 같은 모질라 재단 밖의 프로젝트는 GRE를 사용하기 위해 특정 버전의 모질라 스위트(Mozilla Suite)에 의존하는데, 이 경우 버전이 달라지면 동작하지 않게 된다. 반면에 엔뷰(Nvu) 같은 프로젝트는 자신만의 GRE 복사본을 사용한다.[2]
4. 대응 수단
윈도우 XP는 '레지스트레이션-프리 COM(Registration-free COM, 등록이 필요없는 COM)'이라는 새로운 COM 오브젝트 등록 모드를 도입하였다. 이 기능을 통해 각 애플리케이션은 자신에게 필요한 버전의 COM DLL을 설치하여 사용할 수 있는데, 이 결과로 시스템에는 특정 DLL에 대한 다양한 버전의 DLL 파일들이 존재하게 된다. 레지스트레이션-프리 COM을 사용하면 대부분 DLL 지옥을 피할 수 있다. 다만 최소 윈도우 XP 또는 그 이상의 상위 버전의 OS가 필요하며, EXE COM 서버 및 시스템 전역적인 컴포넌트들 즉 MDAC, MSXML, 다이렉트X 및 인터넷 익스플로러 등에는 사용할 수 없다.
DLL 파일들의 의존성을 추적 및 관리할 수 있는 패키지 관리 시스템을 운영 체제에 포함하여, 사용자에게 패키지 관리 시스템의 사용을 장려하고, 수동으로 DLL 파일을 설치하지 말 것을 권고하는 방법도 있다.
라이브러리 배포에 대한 사항을 중앙에서 집중 관리할 수 있는 시스템을 마련하고, 라이브러리를 변경하려면 이 시스템을 통하도록 하는 방법도 가능하다.
만약 소프트웨어 개발에서 라이브러리의 수정이 불가피하다면, 이 라이브러리의 DLL을 프로그램의 개인적인 공간(프로그램 디렉터리 등)에 두거나, 라이브러리를 프로그램에 정적으로 링크하여 컴파일하도록 할 수 있다.
적절한 소프트웨어 디자인 방법을 따르는 것 또한 대응 수단이 될 수 있다.
Windows ME/Windows XP 이후의 Windows라면, 실수로 시스템 폴더의 라이브러리 파일을 덮어썼을 경우에도, "시스템 복원" 기능을 사용함으로써 거의 모든 경우에 복구가 가능하다.
또한, 위 이외의 OS나 "시스템 복원"이 비활성화되어 있는 경우라도, 시스템의 스냅샷이나 이미지 백업이 존재하는 경우에는 복원을 실시함으로써 복구 가능하다.
Linux에서는 OS 측의 공유 라이브러리에 의존하는 대신, 컨테이너 가상화에 의해 애플리케이션 제공 측이 동작 확인된 공유 라이브러리나 설정 파일 등을 모두 컨테이너에 담아 이를 배포 및 설치하는 대체 수단이 널리 사용되고 있다. 대표적인 예로 도커(Docker)가 있다.
5. .NET 프레임워크
2002년 2월, 마이크로소프트는 .NET 프레임워크를 공개하였다. 이 프레임워크는 어셈블리라 불리는 새로운 버전의 패키지 배포 시스템을 포함하고 있으며, 공용 라이브러리 런타임(common library runtime)에 대한 지원을 제공한다. 공용 라이브러리 런타임에서 많은 DLL 코드가 베이스 파운데이션 클래스(base foundation class)로 이동되었다.
6. 시스템 복원 (윈도우)
Windows ME/Windows XP 이후의 Windows라면, 실수로 시스템 폴더의 라이브러리 파일을 덮어썼을 경우에도, 시스템 복원 기능을 사용함으로써 거의 모든 경우에 복구가 가능하다.[1]
또한, 이 이외의 OS나 시스템 복원이 비활성화되어 있는 경우라도, 시스템의 스냅샷이나 이미지 백업이 존재하는 경우에는 복원을 통해 복구할 수 있다.[1]
참조
[1]
문서
The Versioning Theory for RPC and COM (Windows)
https://msdn.microso[...]
[2]
웹사이트
Dynamic-Link Library Search Order
https://msdn.microso[...]
マイクロソフト
2011-11-15
본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.
문의하기 : help@durumis.com