이 글은 마이크로 소프트웨어 95년 9월호에 실려있는 글을 편집한 것입니다.

썽크 - Win16 과 Win32 간의 통역사

(1) 썽크란 무엇인가?

썽크는 일반적인 Win API에 비해 사용법이 까다롭고, 어떤 때에는 개발자들을 아주 곤혹스럽게 만드는 것중의 하나이다.

우선 썽크가 무엇인지 알아보자. 마이크로소프트의 지식 베이스(Knowledge Base)에 보면 썽크에 대해 아주 간결하게 정의한 구절이 있다.

썽크는 16비트와 32비트 프로페스의 경계선의 한쪽에 있는 코드가 경계선 건너편의 코드를 호출할 수 있도록 허용하는 것이다. (Thunk allow code on one side of the 16-32 process boundary to call into code on the other side of boundary)

이 말을 보다 쉽게 이해하려면 "썽크의 전설"이란 아름다운 얘기를 하지 않을 수 없다.

썽크의 전설

태초에 16비트 코드들이 나라를 이뤄 행복하게 모여살고 있었다. 그러나 16비트 나라는 발전을 거듭한 끝에 어느 순간부터 영도의 비좁음을 절감하게 되었지만 거대한 산맥으로 둘러싸여 있는 탓에 고스란히 갇혀 지내야만 했다.

그러던 어느 날 진화된 몇몇 코드들이 새로운 세계로 옮겨 갈 것을 결의하고, '포팅'이라는 비좁고 위험한 동굴을 통해 거대한 산맥을 건너가기로 마음먹었다. 그리하여 32비트라는 이름의 신대륙을 발견하고 풍요로운 나라를 건설하여 그들은 이제 32비트 코드라고 불리는 민족이 되었다.

하지만 새로 출발한 32비트 나라의 민족은 힘도 세고, 지혜로웠지만, 오랜 전통의 16비트 나라처럼 역사가 남겨준 유산이 절대적으로 부족했다. 한동안 두 나라 사이에는 길도 없는 거대한 산맥으로 인해 정보와 문물을 교환할 방법이 없었다. 더욱이 포팅이라는 이름의 동굴은 전진만 할 수 있고, 돌아갈 수 없는 길이었다. 그러나 두고온 고향을 염두에 두고 있던 몇몇 선구자들은 그들이 출발할 때 길가에 '썽크 나무(Thunk Tree)'의 씨앗을 뿌리면서 왔는데, 시간이 지나 썽크 나무가 자라자 이 나무들의 신비로운 힘으로 인해 16비트 나라와 32비트 나라가 서로 자유롭게 왕래할 수 있는 길이 열렸다.

- X - X - X -

썽크의 전설을 읽으면 그 어려운 썽크라는 것을 좀 더 쉽게 이해할 수 있을 것이다.

16비트에서 32비트로의 포팅은 썽크의 전설처럼 '되돌아 갈 수 없는 길'에 비유할 수 있다. 그리고 16비트의 32비트 사이에는 정말 거대한 산맥처럼 큰 경계가 놓여 있어서 자유롭게 왕래할 수조차 없다 . 그렇지만 썽크라는 신비로운 힘을 이용하면, 이 거대한 산맥을 넘어 자유롭게 이동할 수 있다.

하지만 댓가가 없는 것은 아니다. 썽크를 이용할 때면 이동할 때마다 프로세스 자체에 썽크레이어를 통과하는 만큼의 과부하(Overload)가 걸리게 된다. 따라서 아주 간단한 기능을 단순히 재작성하기 싫다는 이유만으로 썽크를 통해 호출하게 되면, 그 기능 차체보다 썽크에 소모하는 CPU의 부하가 훨씬 더 커질 수도 있다는 사실에 주의해야 한다.

(2) 썽크는 왜 필요한가 ?

어느날 갑자기 16비트로 잘 팔리던 어떤 통합 소프트웨어를 32비트로 포팅하라는 요구가 들어왔다고 하자. 라인 수가 30만 라인쯤 되고, 개발자는 2명, 그렇다면 과연 얼마만에 32비트 버전을 출시할 수 있을까?

최대한 빨리 끝내기 위해서 우선 메인 프로그램을 32비트로 바꾸고, 가장 중요한 모듈 DLL들은 32비트로 수정하고 밑바닥의 엔진 부분은 16비트로 가만 놔둔 채로 썽크(Thunk)를 이용해서 불러쓰는 수법으로 포팅작업을 1차로 끝내서 출시할 것이다. 이렇게 하면 두달정도 걸릴 것이다.

물론 치사한(?) 방법이지만, 이 방법이 그 정도 인원을 갖고 발휘할 수 있는 최상의 수완이다. 어쨌든 32비트 운영체제에서 동작하는 32비트 프로그램이니까! 윈도우즈 95 그 자체도 16비트 모듈들을 엄청나게 많이 이용하고 있지 않은가 말이다.

그 다음 계속 남아있는 모듈들을 32비트로 하나씩 포팅하면서 나머지 10달쯤을 소모할 것이라고 예상된다. 포팅작업이니까 두 사람이 한달에 2~3만 라인 정도는 수정할 수 있을 테고, 그러면 거의 1년은 꼬박 잡아먹게 된다.

이렇게 하지 않고, 두 달동안 30만 라인을 포팅하려면 개발자가 20명 정도는 필요하다. 물론 개발자들이 모두 Win16 에 정통하며 Win32 도 잘 알고있는 이들이어야 하는데, 이는 한국의 어느 소프트웨어 업체에서도 가능한 일이 아니다.

썽크를 써야하는 이유로는, 상용 개발자들이 새로운 32비트 코드도 좋지만 기존의 16비트 코드에서도 최대한 부가가치를 쥐어짜려 한다는 것이다.

가장 깨끗한 방법으로는 당분간 16비트와 32비트 버전의 소프트웨어를 따로 유지하는 것이다. 그러나, 이것은 개발자의 입장에서 보면 소스코드를 두 가지씩 유지하고 각종 버전을 두 가지로 만든다는 것은 엄청나게 괴로운 일이다.

또 하나, 현실적인 문제는 제한된 개발인원으로 갑자기 곱배기로 늘어나는 유지보수를 감당하는 것이 힘들다는 사실이다. 이런 이유로 해서 많은 개발자들이 16비트 시장을 아예 깨끗이 포기하고, 32비트 소프트웨어의 개발에 밤낮이 바뀐 생활을 하는 것이다.

그렇지만, 썽크를 써야하는 가장 큰 이유는 이렇게 급박하게 돌아가는 소프트웨어 업계을 위한 최선의 방책이기도 하지만, 좀더 자세히 돌아보면 과거의 많은 유산들을 그대로 버리고 갈 수 없다는 데서 출발한다. 사실 이미지 파일을 해석하는 DLL들이나 스캐너, 프린터 등 주변기기를 구동하는 DLL들은 굳이 32비트로 포팅해야 할 이유가 별로 없는 것이다. 또한 요즘 들어 소프트웨어 부품으로 많이 활용되고 있는 각종 DLL의 32비트 버전들이 16비트 버전에 비해 충분히 안정화되어 있지 못하면서도 가격은 몇 곱절 비싼 것도 썽크를 써야 할 충분한 이유가 된다.

(3) 썽크의 종류

Win32 플랫폼은 현재까지 3가지 종류가 사용가능한데, 기존의 윈도우즈 3.1에서 Win32 API를 이용할 수 있게 해 주는 Win32s, 윈도우즈 3.1의 업그레이드판인 윈도우즈 95, 도스나 윈도우즈와는 뿌리부터 완전히 다른 운영체제이지만 윈도우즈 인터페이스를 붙여서 나온 윈도우즈 NT 까지 해서 모두 3가지이다.

그런데 썽크 또한 플랫폼 별로 3가지 종류가 사용 가능해서 문제를 복잡하게 만들고 있다. 유니버설 썽크(Universal Thunk, 이하 UT), 제너릭 썽크(Generic Thunk, 이하 GT), 플랫 썽크(Flat Thunk, 이하 FT) 등인데, 각각 Win32s용, NT 용, 윈도우즈 95 용으로 생각하면 된다.

다만 GT는 NT 외에 윈도우즈 95에서도 사용이 가능하다는 장점이 있다. 그래서 마이크로소프트는 윈도우즈 95와 NT 모두에서 작동해야 하는 응용 소프트웨어는 GT를 사용하는 것이 좋다고 주장하지만, GT가 실제로 쓰이는 예는 운용체제 그 자체를 제외하고는 응용 소프트웨어에서는 거의 찾아보기 힘들다.

다음 표를 보면 썽크 방법과 플랫폼 간의 대응관계를 알 수 있을 것이다.

그렇다면 왜 이렇게 썽크 방법이 다양할까. 우선 썽크를 하는 목적이 각각 다르기 때문이다. 썽크가 출현한 순서대로 알아보자.

제너릭 썽크 (GT)

우선 제너릭 썽크는 NT와 윈도우즈 95에서 동작하는 Win16 응용 프로그램이 Win32용의 각종 DLL을 로드하고, 호출하는 것을 가능하게 하는 데 목적을 두고 있다. 따라서 이 방법은 프로그램을 기존의 윈도우즈 3.1에 기반한 형태로 작성하면서 Win32의 막강한 신규 API들을 사용하고자 할 때 이용하는 방법이다. 너무 바빠서 Win32/를 새로 배울 틈이 없다든가, 16비트로 작성해 놓은 코드의 분량이 너무 많은데 포팅할 사람과 시간도 없는데 새로운 Win32 API 들을 꼭 쓰고 싶다든가 할 때 쓰는 방법이다. 예를 들어, 프로그램은 16비트로 짜는데 Win32에서 지원되는 3차원 그래픽 라이브러리를 쓰고 싶다든지 할 때 사용하는 것을 생각할 수 있겠다.

유니버설 썽크 (UT)

제너릭 썽크와는 정반대로 작동하는 것이 유니버설 썽크이다. 16비트 응용 프로그램이 32비트 코드를 부르는 것이 아니라, 32비트 응용 프로그램이 16비트 코드를 부르는 것이 주 목적이다. 플랫폼 또한 NT의 WOW (윈도우즈 on 윈도우즈) 와 같은 32비트 운용체제 내의 16비트 환경이 아닌, 16비트 윈도우즈에 얹혀 돌아가는 32비트 환경에서 사용하는 것이기 때문이다.

Win32s 는 16비트 API만 지원하는 윈도우즈 3.x 상에서 Win32 API를 지원하다 보니 플랫폼에 불완전한 구석이 있다. 그래서 32비트 응용 프로그램이 16비트 DLL을 직접 로드하고 호출하는 등의 작업을 해야 할 경우가 많다.

플랫 썽크 (FT)

마지막으로 플랫 썽크는 윈도우즈 95와 함께 화려하게 데뷔한 신기술인데, 자유롭게 16비트와 32비트 사이를 오갈 수 있다.

플랫썽크는 유니버설 썽크처럼 주로 16비트 DLL을 32비트 응용프로그램이 불러쓸 때 사용하게 된다. 하지만 유니버설 썽크는 32UT.DLL, 16UT DLL 과 같은 두 명의 통역사를 필요로 하며, 그 두 통역사를 수작업으로 하나하나 만들어 주어야 하는 단점이 있다. 따라서 10개쯤의 16비트 DLL 을 32비트에서 사용하고, 하나 하나씩 디버깅하려면 숙련된 프로그래머라도 넉넉잡아 1주일 정도는 걸린다.

그렇지만 플랫 썽크는 썽크 스크립트를 만들어 주면 썽크 작업에 필요한 어셈블리 소스를 만들어 준다. 이를 어셈블해서 나온 두 개의 OBJ 파일을 32비트 쪽과 16비트 쪽의 DLL 에 합쳐 주기만 하면 작업은 끝이다.

사실 유니버설 썽크는 16비트 DLL 을 32비트로 포팅하지 않고 편하게 그대로 쓰자는 게 목적인데, 이를 위해 상당히 번거로운 작업을 해야 한다. 이에 반해 플랫 썽크는 '작은 노력, 큰 기쁨' 하는 식으로 쉽게 쓸 수 있다. 실제로 윈도우즈 95 내부의 많은 부분이 16비트 코드를 그대로 이용하고 있으며, 이 과정에서 관여하고 있는 썽킹 방법이 바로 이 플랫 썽크인 것이다.

(4) 썽크를 쓸 때 주의할 점

썽크의 유용성 못지 않게 사용시의 조심해야 할 점도 많다. 우선 가장 많은 경우가 메인 프로그램은 32비트의 장점을 살리기 위해 32비트로 새로 작성하지만, 대부분의 DLL 혹은 일부의 DLL 을 16비트로 사용하는 경우이다.

이 때 변하는 운영체제를 고려하지 않고 유니버설 썽크만을 지원한다면, Win32s 에서는 잘 도는 프로그램이 윈도우즈 95나 윈도우즈 NT에서는 전혀 작동하지 않는다든지 하는 문제가 발생한다. 마찬가지로 플랫 썽크만 지원할 경우, 윈도우즈 95에서는 잘 돈다. 하지만 Win32s 를 돌리기에 여러가지 자원이 부족한 사람이 윈도우즈 3.1과 Win32s 를 이용해서 사용하길 원할 경우에는 전혀 작동하지 않게 된다.

이런 문제의 예가 초기버전의 아래한글 3.0 윈도우즈용인데, 유니버설 썽크만을 고려한 때문에 윈도우즈 3.1과 Win32s 에서는 잘 작동했지만, 윈도우즈 95나 NT 에서는 동작하지 않고 해당환경용으로 리빌드(rebuild) 해야만 했다.

반대로 16비트 프로그램을 윈도우즈 95에서 작업하도록 급하게 수정하면서 가장 손쉽게 쓸 수 있는 플랫 썽크를 써서 작업했다고 하자. 이런 경우 NT에서는 동작하지 않으며, NT에서 동작하지 않는 프로그램은 'Microsoft Windows 95 Compatible' 로고를 사용할 수 없게 된다.(윈도우즈 95에서는 아무 문제없이 동작함에도 불구하고)