멀쩡히 돌아가던 드라이버가 Spooler까지 죽여가며(프로그래머들 사이에서 프로그램이 잘못된 연산으로 종료되는 것을 "죽는다"고 표현한다.) 처참하게 뻗어 버렸다. 지난 작업 로그를 보아도 지난 한달간 바뀐 코드가 단 한 글자도 없는데, 안 터지던 프로그램이 죽은 것이다. 드라이버는 운영체제 실행 내내 켜져 있고 임의로 다시 켜기도 힘들기 때문에 안정성이 생명이다. 그래야 하는 드라이버가 터졌다는 것은 반드시 짚고 넘어가야 하고 무한 야근의 저주가 사뿐히 내려진다는 이야기가 된다.

며칠동안 원인을 찾았지만 전혀 실마리조차 찾을 수 없었다. 그러다 문득 여자친구의 액티브 액스 오동작을 잡아주면서 내렸던 User Access Control(이하 UAC) 수준을 다시 올렸던 것이 생각이 났다. 드라이버가 정상동작한 것을 확인한 시점은 UAC가 꺼져 있었고 에러를 확인한 시점은 UAC가 켜져 있었다. 혹시 이 환경 차이가 이 변화를 유발한 것일까? 란 생각에 UAC를 다시 끄고 테스트를 해보았다.

정. 상. 동. 작.

맙소사, 내가 늘 욕해오던 UAC 미지원 프로그램을 내가 만든 것이다. 이 사건이 이 포스팅을 쓰도록 결심하게 된 계기가 되었다.

Windows Vista부터 도입된 UAC는 많은 사람들의 애증을 받고 있다. UAC는 어떤 프로그램이 사용자 모르게 컴퓨터의 정보를 변경하는 것을 막고자 하는 취지에서 개발되었다. 프로그램이 UAC 정책에 위배된 행위를 권한 없이 사용하려고 하면 UAC가 운영체제 수준에서 익셉션을 낸다. 몰래 컴퓨터를 변경하려는 시도를 하는 프로그램을 발본색원하는 셈이다.

하지만 어떻게 하드에 아무것도 쓰지 않고 혼자만 돌아가다 죽는 프로그램이 어디있겠는가. 윈도우 temp 폴더에 어떤 파일을 쓰려고만 하더라도 UAC 위반에 걸리는 것이 현실이다. 그런데 자주 사용하는 프로그램들 중 하나라도 UAC를 지원하지 않는다면? 그 프로그램을 사용하기 위해서는 UAC를 통째로 끄는 수 밖에 없다.

Effective C++의 필자인 스콧 마이어스 아저씨(혹은 3판의 번역자님)가 함수의 예외처리에 대해 설명하면서 들었던 "아이 갖기" 비유가 떠오르는 순간이다. 아이는 갖거나 안 갖거나 둘 중 하나이다. 아이를 반만 가질 수는 없는 것이다. 즉 보안을 걸고 싶으면 반만 걸칠 수는 없다는 것이 UAC의 사상인 것이다. 사용자 입장에서는 방화벽처럼 예외를 갖는 프로그램을 지정하게 하고 싶지만 그렇게 되면 그 프로그램이 또한 보안상의 구멍이 되기 때문에 모든 프로그램에 대해 UAC를 요구할 수 밖에 없는 것이다. 수많은 바이러스가 네트워크, USB 드라이브를 통해 전파되고 있는 현실에서 PC 시장에서 주류 OS를 제작하고 있는 마이크로소프트(마소)의 입장은 십분 이해가 간다.

하지만 마소는 이 시스템을 설계하면서 내가 생각하는 보안의 또 다른 중요한 측면을 "완벽히" 무시해버렸다. 그것은 사용자가 보안 시스템을 사용할 때와 사용하지 않을 때의 차이를 최소화해야 한다는 것이다. 적어도 나를 포함한 한국 사용자들에게는 UAC가 켜진 상태에서 제대로 돌아가는 프로그램만을 살아가기에는 너무 무리가 있었다. 수많은 웹 인쇄문서변환프로그램(리포트뷰어), 동영상 재생기가 사용자들이 UAC를 끄고프게 하는 그 대표적인 예이다. 결국 이 문제점은 많은 사용자들이 Vista에서 XP로 운영체제를 다시 다운그레이드하는 희극을 연출하게 하였다.

또한 이런 상황에서 XP로 돌아가지 않은 Vista 사용자가 쉽게 UAC를 끄는 방법은 존재하지 않았다. 그리고 인터넷상에서 비공식적으로 UAC를 대신 꺼주는 프로그램들이 돌아다녔다. 이렇게 인터넷상에서 돌아다니는 프로그램들은 바이러스에 감염되어 있을 확률이 매우 높다. 아이러니컬하게도 UAC 시스템은 UAC를 끄고자 하는 사용자들이  프로그램을 통해 바이러스에 걸릴 가능성만 키워준 꼴이 된 것이다.

결국 Windows 7으로 넘어오면서 마소는 공식적으로 제어판에서 UAC를 끌 수 있는 기능을 제공한다. 하지만 침투한 바이러스가 키보드 매크로만으로 제어판의 UAC 조절 인터페이스를 변경하여 UAC를 마음대로 끌 수 있게 되었다. 결론적으로 해커와 마소의 싸움에서 일단 해커가 완전히 이긴 셈이 된 것이다. 게임 이론적으로 생각하자면 이 환경은 자주 사용되는 모든 프로그램이 UAC 환경 상에서 잘 돌아가는 세상이 되지 않는 한 아직 세세한 어플리케이션의 개발자들은 굳이 더 시간을 들여서 UAC가 켜진 환경에서 잘 돌아가는 프로그램을 작성해야 할 유인이 전혀 없는 것이다(개발자의 공학자적 자기 만족 외에는..).

UAC정책은 개발자에게도 매우 불친절한데(Windows 개발팀이 이 사안에 대해서는 Visual Studio 팀과는 별로 얘기가 없었던 것 같다), UAC를 제대로 통과하려면 어떻게 작성해야 하는지 또 다시 공부해야 하는 현실은 왠지 마소의 독재에 놀아나는 기분이다. 지금 필자는 Visual Studio 2005 환경에서 작업을 하고 있는데, 이후 버젼에선 적용될지 모르겠다. 지금은 manifest 파일에 administrator 계정을 애초부터 요구해라 로 설정하는 정도밖에 없는 것으로 알고 있다. 굉장히 중요한 사항을 마소에선 개발자가 스스로 신경쓰라고 강요하고 있다.

분명히 UAC는 사용자의 보안을 지켜주는데, 획기적이고 혁신적인 방법이다. 하지만 사용자가 자신이 컴퓨터의 주인이라 생각하는 상황에서 OS가 자신의 컴퓨터가 가진 기능을 마음대로 제한한다면 사용자는 그 방법을 사용하지 않을 것이다. 현재 UAC가 갖고 있는 가장 큰 문제점은 UAC를 사용했을 때 어떤 프로그램들은 사용자에게 묻지도 않고 잘못된 연산으로 죽어버린다는 데 있다. 이 프로그램을 반드시 사용해야 하는 사용자 입장에서는 결국 UAC 전체를 끌 수 밖에 없다.

나는 이 문제에 대한 해결책은 앞에서도 말했듯이 기존 XP에서는 정상적이었던 동작이 권한을 넘어서 프로그램이 어떤 명령을 실행하는 것이 되었을 때 무책임하게 익셉션을 발생시키는 것이 아니라 사용자에게 그 권한을 이 프로그램이 사용해도 좋은지 물어보는 것이라 생각한다.

간만에 긴 포스팅... 흑흑 망할 UAC ㅠㅠ