디버깅 지침
업데이트: 2007년 11월
다음 지침에서는 코드 디버깅을 위한 여러 가지 기술에 대해 설명합니다.
필수 사항
디버깅 도구의 사용 방법을 익힙니다.
디버깅 도구를 이해하고 숙지해야 합니다. 자세한 내용은 Visual Studio의 디버깅을 참조하십시오.
기호가 보관되는 위치를 파악합니다.
모든 제품의 기호는 기호 서버에 보관되어야 합니다. 이러한 서버를 찾을 위치를 알아야 합니다. 자세한 내용은 MSDN Library에서 "How to Use the Microsoft Symbol Server"를 참조하십시오.
프로세스를 응답하지 않도록 만드는 버그를 파악하여 해결합니다.
사용자에게 있어 응용 프로그램이 응답하지 않는 상황은 충돌만큼이나 곤혹스럽습니다. 두 경우 모두 사용자는 작업 내용을 잃게 되며 다시 시작해야 합니다. 그러나 버그를 파악하여 해결하기 훨씬 더 어려운 쪽은 응답을 하지 않는 경우라는 생각이 지배적이었습니다. 하지만 응답하지 않는 프로세스의 경우에 이런 생각은 더 이상 사실이 아닙니다. 이러한 문제를 해결할 수 있는 최신 도구와 기술을 사용하십시오. 자세한 내용은 MSDN Library에서 "How to Troubleshoot Program Faults with Dr. Watson"을 참조하십시오.
미니덤프를 디버깅하는 방법을 알아둡니다.
대부분의 테스터와 고객은 연결된 디버거를 활용하지 않고 코드를 훼손합니다. 이러한 문제를 쉽게 재현할 수 없는 경우에는 미니덤프를 이용할 수밖에 없습니다. 따라서 미니덤프를 사용하여 디버깅하는 방법을 반드시 알아야 합니다. 자세한 내용은 MSDN Library에서 "Minidump Files"를 참조하십시오.
손상된 스택을 복구하는 방법을 알아둡니다.
손상된 스택은 복구하기가 복잡하지만 실제로 발생하는 많은 오류에는 이해하기 어려워 보이는 스택이 관련되어 있으므로 손상된 스택을 복구해야 합니다. 자세한 내용은 MSDN Library에서 "Troubleshooting Common Problems with Applications: Debugging in the Real World"를 참조하십시오.
금지 사항
테스트로 모든 버그를 찾을 수 있다는 가정
테스트를 수행하여 버그를 모두 찾을 수는 없습니다. 코드는 너무 복잡하므로 테스트를 통해 버그를 모두 찾을 수 있더라도 전부 수정할 시간이 없습니다. 올바른 해결 방법은 처음부터 버그가 없도록 제품을 디자인하여 나중에 수정하지 않도록 하는 것입니다. 코드 작성자가 코드의 품질을 책임져야 합니다. 테스트 팀에서는 코드의 품질을 확인할 뿐입니다. 테스터에게 문제 정리를 맡겨서는 안 됩니다.
권장 사항
다중 스레드 응용 프로그램을 디버깅하는 방법을 알아둡니다.
프로그램에 스레드를 사용하면 새로운 방식으로 프로그램이 실패할 수 있습니다. 단일 스레드 환경에서 응용 프로그램 디버깅을 돕기 위해 수행하는 모든 작업은 스레드 수가 증가함에 따라 중요해집니다. 예를 들어, 오류가 발생하는 순간 오류를 catch하지 못하는 경우가 있을 수 있습니다. 대개 오류는 나중에 다른 스레드에서 catch됩니다. 이런 경우 문제를 찾기 위해 호출 스택을 되짚어갈 수도 없습니다. 오류는 다른 스레드의 다른 스택에 있기 때문입니다. 일반적으로 미리 대비하는 것이 디버깅 프로세스에 도움이 됩니다.
원격 디버깅 방법을 익힙니다.
자신의 컴퓨터에서 계속 작업하면서 다른 컴퓨터에서 발생한 문제를 디버깅하려는 경우 원격 디버깅이 발생합니다. 코드 세그먼트가 자신의 컴퓨터에서는 제대로 실행되지만 다른 시스템에서 충돌할 경우 개발자들은 주로 이 방법을 사용합니다. 개발자는 해당 컴퓨터 앞에 직접 가지 않고도 시스템에서 원격으로 코드를 디버깅할 수 있습니다. 자세한 내용은 원격 디버깅 설치를 참조하십시오.
라이브 서버에서 디버깅하는 방법을 익힙니다.
고객이 액세스하는 라이브 서버에서 코드를 디버깅할 경우에는 디버깅 절차가 다릅니다. 웹에 맞게 코드를 작성하는 경우가 늘어감에 따라 이 방식이 일반화되고 있습니다. 자세한 내용은 MSDN Library에서 "Troubleshooting Common Problems with Applications: Debugging in the Real World"를 참조하십시오.
모든 버그 수정 내용에 주석을 지정합니다.
버그를 수정할 때는 코드에 버전 번호, 버그 ID 및 수정한 사람의 별칭을 포함합니다. 그러면 나중에 다른 사용자가 코드를 보고 수정 내용이 궁금한 경우 수정한 사람에게 문의할 수 있습니다.
모든 버그 수정 내용을 검토합니다.
모든 수정 내용에 대해 코드 검토를 수행해야 합니다. 한 사람 이상에게 코드 검토를 의뢰하는 동료와의 검토 과정을 거칩니다.
체크 인하기 전에 미세한 버그 수정을 확인합니다.
같은 버그는 두 번 수정하지 않도록 합니다. 빌드를 사용하여 특히 미세한 버그가 올바로 수정되었는지 확인합니다.
테스트 릴리스 문서를 사용하여 모든 버그 수정 내용을 보고합니다.
TRD(테스트 릴리스 문서)에 모든 버그 수정 내용을 문서화하고 전자 메일로 테스트 팀에게 보내 의견을 조정합니다.
기호 서버를 사용하여 제품 기호를 인덱싱하고 보관합니다.
기호 서버를 사용하여 제품 기호를 인덱싱하고 보관하면 고객 시스템을 비롯한 모든 시스템에서 쉽고 빠르게 디버깅할 수 있습니다.
권장되지 않는 사항
해당 개발자에게 알리지 않고 다른 개발자의 버그 수정
다른 개발자의 버그를 확인하여 수정하는 것은 바람직한 일입니다. 그런 과정을 통해 코드에 대한 이해를 높이고 다른 개발자를 지원할 수 있습니다. 그러나 해당 코드 소유자에게 알리지 않고 수정 내용을 체크 인하는 것은 반드시 피해야 합니다.
같은 환경에서 같은 버전을 실행해 보지 않고 버그를 "재현할 수 없음"으로 처리
버그가 발견된 제품 버전으로 롤백해 보아야 합니다. 현재 버전의 제품에서 해당 버그가 문제를 일으키지 않았다고 해서 버그가 수정되었다고 단정해서는 안 됩니다. 실제로 버그가 수정되지 않고 단지 버그가 숨겨지도록 코드가 변경되었을 수 있습니다. 버그를 조사하여 문제가 발생하는 것을 확인하면 실제로 문제의 근본적인 원인을 찾아 모든 컴퓨터에서 버그가 다시 발생하지 않도록 수정할 수 있습니다.