16-1.어셈블리

16-1-1.DLL 지옥

윈도우같은 복잡한 환경의 응용 프로그램은 단독으로 실행되지 않으며 DLL의 지원을 받는다. Kernel, User, GDI 같은 시스템 DLL은 물론이고 디바이스 드라이버나 특정 기능을 제공하는 라이브러리 DLL과도 연결된다. DLL을 통해 검증된 모듈을 재활용할 수 있어 고기능의 프로그램도 손쉽게 만들 수 있다. 또한 다수의 응용 프로그램이 공유하여 하드디스크와 메모리를 절약한다. 하지만 여럿이서 하나를 공유하다 보니 문제도 많다.

첫째, DLL을 찾는 경로가 정해져 있어 복사만으로는 실행할 수 없고 반드시 설치해야 배포할 수 있다. 위치가 바뀌면 잘 돌아가는 프로그램도 실행되지 않아 재설치해야 하며 DLL에 대한 정보를 재구성해야 한다.

둘째, 시스템 디렉터리의 공유 DLL을 응용 프로그램끼리 덮어 쓰는 DLL 지옥이라는 심각한 문제를 유발한다. A와 B가 공유 DLL D를 사용한다고 해 보자. A가 D 1.0을 설치한 상황에서 B가 D 2.0을 설치하면 A는 실행되지 않을 수 있다. 반대의 경우 B가 설치한 2.0을 A가 1.0으로 다운그레이드시켜 버리면 B는 실행되지 않을 확률이 높다.

자신이 필요한 DLL을 설치함으로써 다른 프로그램의 DLL을 파괴하는 것이다. 흔히 쫑난다고 표현하는데 쫑을 낸 프로그램은 잘 실행되지만 쫑이 난 프로그램은 테러를 당하는 꼴이다. 설치할 때 버전을 점검하여 가급적 최신 버전을 보존하면 문제가 완화되지만 그러려면 하위 호환성이 확보되어야 한다.

이전 기능을 유지하자면 비효율적이고, 구조가 완전히 바뀌면 질적 변화가 생길 수밖에 없어 하위 호환성 유지가 말처럼 쉽지 않다. 또 언어나 설정에 따른 문제도 있는데 한글 DLL이 영문 DLL로 바뀌면 한글로 나타나던 대화상자가 영문으로 바뀌어 버린다.

버전 체크, 병렬 설치, 인터페이스 유지, DLL 잠금 등의 여러 가지 대안이 있지만 임시적인 대책일 뿐 근본적인 해결책이 되지는 못한다. DLL 지옥은 아주 흔한 현상이며 자바에도 비슷한 JAR 지옥이 있다. 뭔가를 공유하면 말썽이 생길 수밖에 없다.

셋째, DLL은 파일일 뿐이어서 보안에 취약하다. 핵심 DLL을 바꿔 버리면 이 DLL의 기능을 사용하는 응용 프로그램은 원래와 다르게 동작하며 해커는 이를 노린다. 패스워드를 입력받는 DLL을 교체하면 비밀번호를 빼낼 수 있다. 백신의 DLL을 덮어 써서 자신을 퍼뜨리는 약아빠진 바이러스도 있고 불필요한 파일을 삭제해 준다며 하드디스크를 박박 긁어대는 얄미운 프로그램도 있다. 그야말로 아무도 믿을 수 없는 난장판이다.

16-1-2.어셈블리의 구조

공유로 인한 문제는 닷넷 환경에서도 똑같이 발생할 수 있다. 닷넷은 이 문제에 대한 명쾌한 해결책으로 어셈블리를 제시한다. 어셈블리는 응용 프로그램을 구성하는 단위로서 배포, 설치, 버전 관리, 보안 권한 지정의 단위이다. exe나 dll같은 실행 파일을 칭하는 개념이라고 생각하면 된다. 지금까지 실습 예제당 하나씩 어셈블리를 만들었다.

어셈블리는 실행 파일의 일종이지만 네이티브 코드가 아닌 MSIL 중간 코드가 들어 있으며 자신의 구조를 설명하는 메타 데이터가 포함되어 있다. 이런 정보에 의해 쫑이 방지되며 어셈블리 자체에 정보가 보관되므로 배포의 문제도 없다. 어셈블리의 물리적인 포맷은 Win32의 PE 포맷과 같지만 포함된 정보의 종류나 역할은 다르다. PE 헤더 안에 닷넷 응용 프로그램이라는 정보가 저장되어 있고 CLR 헤더에는 필요한 런타임의 버전이나 여러 가지 속성을 표현하는 플래그가 기록되어 있다.

PE 헤더나 CLR 헤더는 닷넷 런타임이 관리하는 것이어서 관심을 가질 필요는 없다. 중요한 것은 어셈블리의 논리적인 구조와 역할인데 크게 다음 4가지로 구성된다. 앞쪽의 메타데이터는 일종의 헤더이고 뒤쪽의 코드와 리소스는 어셈블리의 실제 내용이다.

어셈블리 메타 데이터를 저장하는 장소를 매니페스트(Manifest)라고 하는데 별도의 파일에 둘 수도 있다. 다음 정보가 저장되어 있다.

정보	설명
어셈블리 이름	어셈블리의 이름을 문자열 형태로 저장한다.
버전 번호	1.0.34.28 등과 같이 4개의 숫자로 구성된 버전 번호이다. 각각 주버전, 부버전,빌드번호, 수정 횟수를 나타낸다.
컬쳐	어셈블리가 지원하는 컬처 또는 언어이다. 위성 어셈블리에만 나타난다. 쉽게 말해서 한국어 버전인지 영문 버전인지 등을 표현한다.
강력한 이름	공유 어셈블리의 작성자와 공개키를 나타낸다.
파일 목록	다중 파일 어셈블리에 포함되는 파일의 이름과 해시이다. 매니페스트가 있는 디렉터리와 같은 위치에 있어야 한다.
참조 타입	어셈블리에서 외부로 노출하는 클래스에 대한 정보이다.
참조하는 타입	어셈블리가 참조하는 다른 어셈블리의 목록이다. 어셈블리의 이름, 메타 데이터, 강력한 이름 등을 포함한다. 만약 이 정보가 지시하는 어셈블리가 없거나 버전이 틀리면 실행 거부된다.

커스텀 어트리뷰트로 상표나 저작권, 개발사, 개발자 등의 추가 정보를 더 써 넣을 수 있다. 이런 상세한 정보가 모두 기록되기 때문에 레지스트리를 쓸 필요가 없다. 어셈블리는 모든 정보를 보유하여 스스로 설명 가능한 모듈이라고 부른다. 타입 메타데이터에는 외부로 공개한 클래스와 메서드, 필드에 대한 정보가 상세히 저장되어 있다. 인텔리센스는 리플렉션으로 이 정보를 읽어 멤버 목록이나 인수 목록을 보여준다.

메타데이터 뒤쪽에는 어셈블리의 실제 내용인 MSIL이 들어 있다. 클래스나 열거형같은 타입과 메서드의 실행 코드가 이 안에 모두 컴파일되어 있으며 JIT 컴파일러에 의해 기계어로 바뀌어 실행된다. 비트맵, 텍스트, 아이콘처럼 코드가 아닌 데이터는 리소스로 포함된다. 어셈블리도 문제가 전혀 없는 것은 아니다. 하지만 최소한 지금까지 알려진 대부분의 문제에 대한 훌륭한 해결 방법을 제시한다. 어셈블리 자체가 모든 문제를 해결하는 것은 아니지만 적어도 해결 가능한 인프라를 제공한다.

16-1-3.ildasm 유틸리티

어셈블리의 내부 모양을 들여다 보고 싶으면 닷넷과 함께 배포되는 ildasm.exe 유틸리티를 활용한다. 실행 파일의 내부 구조 뿐만 아니라 중간 코드를 디스어셈블해서 보여주기도 한다. 메뉴에 등록되어 있지 않아 직접 찾아야 하는데 경로는 버전마다 조금씩 다르다.

c:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.7.2 Tools\x64\

2장에서 처음 만들었던 FirstCon.exe를 열어 보자. 어셈블리를 구성하는 각종 요소를 트리 형식으로 덤프하며 종류별 아이콘으로 장식되어 있다.

아이콘	설명
	네임스페이스
	클래스
	인터페이스
	값 클래스 = 구조체
	열거형
	메서드
	정적 메서드
	필드
	정적 필드
	이벤트
	프로퍼티
	매니페스트, 클래스에 대한 정보

각각의 요소를 더블클릭하면 상세 정보를 텍스트 형태로 출력한다. 이 정보를 제대로 해독하려면 어셈블리에 대해 훨씬 더 많은 내용을 알아야 한다. 매니페스트를 더블클릭하면 별도의 창이 열리고 어셈블리의 주요 정보가 출력된다.

mscorlib 외부 어셈블리를 참조한다는 것과 모듈의 이름, 서브 시스템, 각종 플래그가 표시되어 있다. 타입 메타 데이터에는 어셈블리에 선언된 타입에 대한 정보가 나타난다. FirstCon 어셈블리는 FirstCon 클래스를 가지며 생성자와 Main 정적 메서드로 구성되어 있다. 다음은 조금 더 복잡한 InheritStudent 예제를 열어 보자.

Human 클래스와 Student 클래스가 선언되어 있고 멤버가 나열된다. Student 클래스의 정보를 출력해 보면 Human으로부터 파생되었음을 알 수 있다.

.class private auto ansi beforefieldinit Student

extends Human

{

} // end of class Student

메서드의 코드도 직접 확인해 볼 수 있다. 다음은 Human::Intro 메서드의 코드를 디스어셈블한 것이다.

.method public hidebysig newslot virtual

instance void Intro() cil managed

{

// 코드 크기 35 (0x23)

.maxstack 8

IL_0000: nop

IL_0001: ldstr bytearray (7B 00 30 00 7D 00 B4 C0 20 00 7B 00 31 00 7D 00 // {.0.}... .{.1.}.

85 C7 C8 B2 E4 B2 2E 00 ) // ........

IL_0006: ldarg.0

IL_0007: ldfld int32 Human::Age

IL_000c: box [mscorlib]System.Int32

IL_0011: ldarg.0

IL_0012: ldfld string Human::Name

IL_0017: call string [mscorlib]System.String::Format(string,

object,

object)

IL_001c: call void [mscorlib]System.Console::WriteLine(string)

IL_0021: nop

IL_0022: ret

} // end of method Human::Intro

ldstr이니 call이니 하는 명령은 닷넷의 중간 코드에 대한 니모닉이다. 대충 훓어 보면 Human의 Name 멤버를 조립하여 WriteLine으로 출력한다는 것 정도는 감잡을 수 있다. 좀 더 실력이 되면 이 코드를 뜯어 고친 후 다시 어셈블할 수도 있다. 다음은 닷넷의 시스템 DLL인 mscorlib.dll을 디스어셈블한 것이다.

트리를 확장해 보면 엄청난 수의 네임스페이스와 클래스가 포함되어 있음을 알 수 있다. 이 툴을 사용하면 닷넷의 안쪽을 샅샅이 들여다 볼 수 있다. ildasm은 트리나 코드를 텍스트 파일로 덤프하는 기능도 제공하는데 코드를 몽땅 덤프하면 닷넷 그 자체를 탐구할 수도 있다.