(연관된 글이 2개 있습니다.)
원격 디버깅은, 사실 SDK 개발자 입장에서는 그다지 빛을 보지 못하던 기술이었죠.
거의 자신의 개발 PC에서 디버깅을 진행했고, 설령 대상 컴퓨터 환경에서만 오류가 발생하는 경우가 있으면 Trace 로그 등을 활용하는 것이 대부분이었습니다.
물론, 오류가 나는 환경과 같은 PC를 설치할 수도 있었지만 사실 그 많은 클라이언트 환경을 모두 구성해 놓은 개발회사가 그리 많지는 않을 것입니다. 개발자마다 할당된 PC가 2대 이상인 회사를 아직까지 본적이 없습니다. 반면, 클라이언트 환경은 참으로 다양하죠. OS 만 해도, Windows 98, Windows XP, Windows 2000, Windows 2003 등으로 다양하고, 거기에다 다국어 지원까지 포함하는 회사라면, 판매 대상이 되는 언어 환경까지 고려하면 도저히 물리 PC로는 감당이 안되는 상황이 옵니다. (물론, 다중 부팅도 있지만 여간 귀찮은 작업이 아닐 수 없죠.) 그러다 보니 원격 디버깅을 사용할 일이 더더욱 없게 되는 데요.
하지만,
최근 VPC 기술이 나오면서 상황이 바뀌게 되었습니다. 하드 디스크가 넉넉한 PC 1대만 있어도 모든 클라이언트 OS 및 다국어 버전을 소화하게 되었습니다. 실제로, 저만 해도 개인적으로 테스트를 위해 구성한 Virtual Server 환경이 아주 다양합니다. 만약, 아래의 환경을 모두 물리 PC로 구성하려고 했다면 아마도 저희 집의 가산이 휘청했을지도 모르죠. (다중 부팅으로 구성했다면, 환경 구성을 유지하느라 정신적으로 매우 피곤했을지도 모릅니다.)
- Active Directory가 설치된 VPC
- SQL 2005가 설치된 VPC
- 오라클 설치 VPC
- Team Foundation Server가 설치된 VPC
- Vista Beta2가 설치된 VPC
- Windows 2003 영문 VPC
- Windows 2000 한글 VPC
- Windows XP 영문 VPC
- Windows XP 일본 VPC
- Windows XP 덴마크 VPC
- Windows XP 한글 VPC
- Windows 98 VPC
- MOM Server 2005가 설치된 VPC
VPC의 등장으로, 무식하게(?) Trace 로그를 찍어야 하는 코드를 만들기 보다는 "원격 디버깅"이라는 보다 우아한 방법을 사용할 수 있게 되었습니다.
사실, VS.NET의 개발환경이 너무나 잘 되어 있기 때문에 원격 디버깅 방법 또한 그다지 어렵지 않게 구성되어져 있습니다. 그래도, 한번 정리해 본다는 의미를 가지고 이렇게 토픽을 써볼까 합니다. ^^
우선, 원격 디버깅은 VS.NET의 버전마다 다르게 지원이 됩니다. VS.NET 2003의 경우 Managed 원격 디버깅과 Unmanaged 원격 디버깅의 방법이 틀리고, VS.NET 2005 같은 경우에는 그 두 가지가 통합이 되어 지원이 됩니다. 또한, VS.NET 2005에서는 32bit 환경에서 컴파일한 모듈을 64bit 원격 머신에 복사한 후 원격 디버깅을 할 수 있도록 지원하고 있습니다.
그럼, 이야기를 다음의 2가지로 (그리 길게 쓸 내용은 아니지만) 나눠서 풀어보도록 하겠습니다.
1. VS.NET 2003 - 원격 디버깅
- ASP.NET 원격 디버깅
- WinForm App 원격 디버깅
- VC++ 원격 디버깅
2. VS.NET 2005 - 원격 디버깅
- ASP.NET 원격 디버깅
- WinForm App 원격 디버깅
- VC++ 원격 디버깅
- 32bit 머신에서 컴파일한 64bit 모듈을 64bit 원격 머신에서 디버깅
[부록 1]
Vista & Longhorn: VS.NET 2005 원격 디버깅 구성
[연관 글]