VS 2005 원격 디버깅

Written by 안재우(Jaewoo Ahn), 닷넷엑스퍼트(.netXpert)

 

고객사에서 Visual Studio 2005에서의 원격 디버깅 사용법에 대한 문의가 온 김에, 내용을 좀 정리해볼까 합니다. 원격 디버깅은 상당히 유용한 기능 임에도 불구하고, 대부분의 개발자들이 좀처럼 사용하지 않는 기능입니다. 간혹 여러가지 여건 때문에 쓸 수 없는 상황에 처해 있는 경우도 있겠지만, 대다수는 사실 '몰라서' 사용하지 못하고 있는 형편입니다.

 

이번 글에서는 원격 디버깅의 개념, Visual Studio 2005에서의 원격 디버깅에 대해 알아보고, 몇가지 주의할 사항도 함께 살펴보도록 하겠습니다.

 

원격 디버깅이란?

네이버 용어 사전 설명으로는 '원격 시스템에서 사용되는 원격 제어 콘솔에서 프로그램을 수정하고 시험하는 것'이라고 합니다. 사실 이걸로는 정확하게 무슨 말이 잘 와 닿지 않을 수 있으므로, 좀 풀어서 설명해보도록 하죠.

 

일반적으로 우리가 디버깅을 시작하려면 개발툴(Visual Studio)에서 디버그 모드(F5 키)로 애플리케이션을 시작하게 됩니다. 디버그 모드로 애플리케이션을 구동하면, 당연히 애플리케이션을 호스트하는 프로세스가 만들어질테고, 프로세스는 자신이 필요한 모듈(.exe, .dll)을 로드하게 됩니다. 이 때, 디버그 모드에서는 모듈에 해당하는 디버그 심볼 파일(.pdb)을 같이 로드하게 됩니다.

 

그런데, 디버그 모드로 '시작'한다는 의미는 애플리케이션을 처음부터 새로 시작한다는 의미입니다. 그리고 디버그 모드를 '종료'하면 애플리케이션도 같이 종료되어 버립니다. 당장 코드를 개발 중일 때는 이러한 방법으로 디버깅을 할 수 있겠지만, 항상 개발을 하다보면 멀쩡하게 잘 돌아가던 애플리케이션에서 말썽이 생기는 경우가 많습니다. 즉, 이미 돌아가고 있는 애플리케이션에 대해 디버깅을 할 수 있는 방법은 없느냐는 것이죠. 이 형태의 디버깅은 In-Process 모드와 유사하다고 볼 수 있습니다.

 

여기에서 먼저 도입된 개념이 '프로세스 디버깅'입니다. Visual Studio에서는 이미 실행 중인 프로세스에 연결(Attach)시켜서 디버깅을 수행할 수 있습니다. 디버깅을 종료하면 프로세스에서 분리(Detach)시키고, 애플리케이션 프로세스 자체는 여전히 구동되게 됩니다. 이 형태의 디버깅은 Out-Of-Process 모드와 유사하다고 볼 수 있습니다.

 

원격 디버깅은 프로세스 디버깅을 로컬 컴퓨터의 바운더리를 벗어나도록 확장한 개념입니다. 즉 원격 컴퓨터에서 실행되고 있는 프로세스를 내 로컬 컴퓨터의 디버거를 사용하여 디버깅할 수 있게 해줍니다.

 

참고로 약간 변칙적인 녀석 중 하나로 실행 중인 프로그램에 심각한 오류가 발생하면 Visual Studio 디버거를 자동으로 실행할 수 있게 해주는 Just-In-Time 디버깅도 있습니다.

 

원격 디버깅이 왜 필요한가?

로컬 디버깅의 경우, 로컬에 디버거(개발툴)가 설치되어 있다는 것을 전제로 합니다. 그러나 항상 모든 컴퓨터에 디버거(개발툴)이 설치되어 있지는 않겠죠?

예를 들어, 개발자 컴퓨터에서는 이상없이 잘 돌던 프로그램이 서버나 다른 PC에서 실행하면 문제가 발생하는 경우가 있습니다. 이런 경우, 디버깅을 해보기 위해 서버나 그 PC에 디버거(개발툴)를 설치해야 할까요?

실제로 제가 경험한 몇몇 회사에서는 서버에 Visual Studio를 설치해서 디버깅을 하는 웃지 못할 형태로 작업을 하기도 했습니다. 그런데 간혹 가다보면 Visual Studio를 설치하고 나면 제대로 동작해버리는 상황도 발생하더군요. :-)

 

전통적으로 애플리케이션을 배포하고 난 후에는 디버깅이 아닌 다른 방법을 사용해서 문제점을 추적해야 합니다. 문제점 추적 방법에 대한 다양한 개발자들의 행태(?)를 살펴보면...

 

1. 초급: Hello World를 사랑하는 사람들(Windows 애플리케이션에서는 메시지 박스를, Java 스크립트에서는 alert를, ASP나 ASP.NET에서는 Response.Write를 찍어대는 사람들을 의미합니다)

2. 중급: 로그 찍기. 파일, 이벤트 로그 등에 로그를 기록합니다.

3. 고급: 기본적으로는 2번과 동일하지만, 해당 PC에 로그를 기록하는 것이 아니라 원격 로그 수집기에 로그를 기록하게 합니다. DB에 기록하거나 에러 발생 시 원격 통신으로 전송한다든지.. 성능 카운터를 활용하거나 WMI를 이용하기도 합니다.

 

로그 기록 형태가 가장 일반적이지만, 이를 통해 문제를 정확하게 파악하는 것은 디버깅에 비해 상대적으로 쉽지 않습니다. 과거에 일어난 일을 '단서'를 가지고 추정해 나가야 하기 때문입니다.

 

원격 디버깅은 이러한 상황, 즉 로그 기록만으로는 정확한 내용을 알 수 없는 경우에 사용할 수 있는 해결책 중 하나입니다. 원격 컴퓨터에 개발툴을 설치하지 않고도 원격에서 디버깅을 수행할 수 있게 해줍니다.

 

Visual Studio에서 원격 디버깅의 구동 원리

Visual Studio 2005에서 원격 디버깅이 구동되는 형태를 도식화하면 대략 다음 그림과 같습니다. 그림을 보면 이해가 갈 것이라고 판단되므로 별다른 설명은 하지 않겠습니다.

 

 

위 그림처럼 디버거 역할을 하는 로컬 컴퓨터의 VS2005와 실행 중인 프로세스(App1.exe)를 중개하는 역할은 원격 디버깅 모니터(Remote Debugging Monitor)인 msvsmon.exe가 수행합니다. 과거에 일부 원격 디버깅 시나리오에서만 유사한 역할을 수행한 Machine Debug Manager(mdm.exe)가 있었지만, 이는 더이상 사용되지 않습니다. VS2005에서는 T-SQL 디버깅을 제외한 모든 원격 디버깅 시나리오에서 msvsmon.exe가 사용됩니다. 커맨드라인의 MDM에 비해 msvsmon.exe는 GUI를 제공합니다.

 

Visual Studio에서 원격 디버깅 구성

 

위 그림을 살펴보다 보면 원격 디버깅을 하기 전에 몇가지 설정이 필요할 것이라는 점을 추측할 수 있습니다.

1. 원격 디버깅 모니터(msvsmon.exe)를 원격 컴퓨터에 설치

2. 원격 디버깅을 위한 보안 권한 설정

3. 네트워크 방화벽 설정(개인 방화벽 포함, 로컬/원격 모두)

 

1, 3번에 대한 것은 다음 MSDN 문서를 참조하기 바랍니다. 아직 한글판이 나오지 않아서 임시 URL인 것 같습니다.

http://msdn2.microsoft.com/ko-kr/library/y7f5zaaa.aspx

 

2번은 상대적으로 간단해졌는데, 과거에 권한 설정 문제가 비교적 복잡했던 것에 비해서 이제는 원격 디버깅 모니터의 Tools/Permission 메뉴에서 설정할 수 있습니다.

 

원격 디버깅 사용법

구성이 끝났으면, 이제 사용법은 간단합니다.

 

1. 원격 컴퓨터에서 원격 디버깅 모니터를 실행합니다. 다음은 실행된 모습입니다.

 

2. 디버깅할 대상이 되는 프로세스가 아직 실행되어 있지 않다면, 실행합니다. 이 프로세스와 관련 DLL들은 당연히 디버그 모드로 빌드되어 있어야 하며, 디버깅이 사용가능한 상황이어야 합니다.

 

3. 로컬 컴퓨터에서 VS 2005를 실행하고, 디버깅할 프로세스 및 DLL이 포함된 솔루션 또는 프로젝트 파일을 엽니다.

 

4. Debug 메뉴에서 Attach to Process를 선택합니다. Qualifier에 msvsmon.exe를 실행하고 있는 원격 컴퓨터의 이름(또는 IP)을 입력 후, 엔터 키 또는 Refresh 버튼을 누릅니다.

 

5. Available Processes에서 디버깅할 프로세스를 선택한 후 Attach 버튼을 누르면...

이제 디버깅 시작입니다!

 

원격 디버깅 시 주의할 사항

이제 사용법은 알았고, 원격 디버깅에는 몇가지 주의할 사항이 있습니다.

 

첫째, 기본적으로 원격 디버깅은 로그 추적/ 트레이스 등으로 해결할 수 없을 때 사용되는 보조적인 방법이라는 것입니다. 무조건 모든 문제를 원격 디버깅으로 해결하려고 드는 것은 바람직한 것이 아니라는 점입니다.

 

두번째, 디버깅을 하면서 브레이크를 걸었을 때, 실행 중인 프로세스 자체도 정지되어 있는 상태가 된다는 것입니다. 일반적인 애플리케이션이라면 별 상관없지만, 웹 애플리케이션처럼 서버 애플리케이션인 경우에는 문제가 심각해질 수 있습니다.

예를 들어 ASP.NET 애플리케이션을 원격 디버깅하고 있다고 가정해 봅시다. 내가 브레이크 포인트를 걸고 디버깅을 하고 있는 도중에는 ASP.NET 웹 애플리케이션이 다른 사용자의 요청에 응답할 수 없게 됩니다.

실제로 있었던 웃지못할 사건 중 하나는.. 모 고객사에서 실행 중인 서버에서 이상한 문제점이 발견되었는데, 로그나 트레이스를 하는 것이 아무것도 없어서 결국 원격 디버깅을 걸어서 문제점을 찾아 해결했습니다. 그러면서 원격 디버깅 사용법을 가르쳐 주고 나왔는데.. 그 담부터 그 개발자가 원격 디버깅을 지나치게 남발하면서 문제가 생겼습니다. 툭하면 서버가 먹통이 되어 버린다고 사용자들이 난리가 난거죠. 알고보니 개발자가 원격 디버깅을 걸어 둔 채 점심식사를 하러 갔다고 합니다. -_-;;

 

결론적으로 Visual Studio 2005에서 원격 디버깅은 보다 설정 및 사용법이 간편해지긴 했지만, 원격 디버깅은 어쩔 수 없는 경우에 사용하는 히든 카드(?)라는 점이며, 사용 시에는 가급적 빠른 시간 내에 작업을 마치는 것이 바람직하다는 것입니다.

마지막으로 원격 디버깅은 .NET으로 작성된 프로그램뿐만 아니라 Native, Script, T-SQL 등에 모두 사용이 가능하다는 점을 유념하시기 바랍니다.