디버거 사용법

아무리 숙련된 개발자라도 코드를 작성하는 과정에서 오류(버그)를 피할 수는 없습니다.

프로그램이 예상대로 동작하지 않을 때, 가장 강력하고 효율적인 문제 해결 도구는 바로 디버거(Debugger)입니다.

디버거는 실행 중인 프로그램의 내부 상태를 검사하고, 실행 흐름을 제어하여 논리적 오류를 식별하고 수정하는 데 도움을 줍니다.

이번 장에서는 C++ 개발에서 널리 사용되는 디버거의 기본적인 사용법과 핵심 기능들을 학습합니다.

여러분이 효과적으로 버그를 찾아 해결할 수 있도록 돕겠습니다.

아래 그림은 디버거를 단순 실행 버튼 모음이 아니라, 추측을 실행 상태 확인으로 바꾸는 과정으로 정리합니다.

왜 디버거를 사용해야 하는가?

많은 개발자가 std::cout을 이용한 출력으로 디버깅을 시도합니다.

물론 간단한 경우에는 유용하지만, 복잡한 오류나 예측 불가능한 동작을 추적하는 데는 한계가 있습니다.

• 실시간 상태 확인: 프로그램이 특정 시점에서 어떤 변수 값을 가지고 있는지, 어떤 함수가 호출되었는지 등을 실시간으로 정확하게 파악할 수 있습니다.
• 실행 흐름 제어: 코드를 한 줄씩 실행하거나, 함수 내부를 펼치지 않고 실행하는 등 프로그램의 실행 흐름을 원하는 대로 제어할 수 있습니다.
• 복잡한 오류 추적: 여러 스레드 간의 상호작용 문제, 메모리 손상, 예측 불가능한 크래시(crash) 등 cout 디버깅으로는 찾기 어려운 문제를 해결할 수 있습니다.
• 시간 절약: 문제를 재현하고 cout을 삽입하며 재빌드하는 과정을 반복하는 것보다 훨씬 효율적입니다.

디버깅 빌드 (Debugging Build)

디버거를 효과적으로 사용하려면, 소스 수준 관찰에는 디버깅 심볼을 포함하는 것이 좋습니다. 최적화 빌드도 디버깅할 수 있지만 일부 변수가 사라지거나 실행 줄이 재배치될 수 있습니다.

• 디버깅 심볼 포함: 컴파일러에게 소스 코드의 라인 번호, 변수 이름, 함수 이름 등 디버깅 정보를 실행 파일에 포함하도록 지시합니다. (GCC/Clang: -g, MSVC: /Zi)
• 최적화 비활성화: 컴파일러 최적화(-O2, -O3 등)를 비활성화합니다. 최적화는 코드의 실행 순서를 바꾸거나 일부 코드를 제거할 수 있으므로, 디버거가 소스 코드와 일치하지 않게 동작하게 만들 수 있습니다. (GCC/Clang: -O0, MSVC: /Od)

일반적으로 IDE(통합 개발 환경)에서 Debug 구성을 선택하면 이러한 설정이 자동으로 적용됩니다.

주요 디버거와 기본적인 사용법

널리 사용되는 C++ 디버거는 다음과 같습니다.

• GDB (GNU Debugger): Linux/macOS 환경에서 가장 보편적으로 사용되는 커맨드라인 기반 디버거.
• LLDB: macOS 환경에서 주로 사용되는 LLVM 프로젝트의 디버거. GDB와 유사한 인터페이스를 가집니다.
• Visual Studio Debugger: Windows 환경의 Visual Studio IDE에 통합된 GUI 기반 디버거.
• IDE 통합 디버거: CLion (JetBrains), VS Code (Microsoft) 등 대부분의 현대 IDE는 GDB나 LLDB를 백엔드로 사용하는 통합 디버깅 환경을 제공합니다. 이 책에서는 IDE 통합 디버거를 사용하는 일반적인 방법을 위주로 설명하겠습니다.

실제 디버깅 과정 (가상 시나리오)

가상 시나리오를 보기 전에, 문제 재현부터 수정 검증까지 범위를 좁히는 흐름을 먼저 확인해 봅시다.

간단한 프로그램에서 디버거를 사용하는 가상 시나리오를 통해 디버깅 과정을 이해해 봅시다.

아래 완전한 프로그램을 sum_debug.cpp로 저장합니다. GCC를 쓰는 Linux의 예시 빌드는 g++ -std=c++17 -g -O0 sum_debug.cpp -o sum_debug이며, 실행하면 Sum up to 5 is: 10이 나옵니다. IDE에서는 이 실행 파일과 현재 소스가 같은 빌드인지 확인한 뒤 디버깅을 시작합니다. 각 버튼은 소스 줄을 단위로 실행을 요청하지만, 한 번 누르면 반드시 루프 한 회가 끝난다는 뜻은 아닙니다. 중단점·예외·디버그 정보와 현재 실행 위치에 따라 더 일찍 멈출 수 있습니다. GDB의 step·next 설명도 실행 위치와 호출 스택을 구별합니다.

문제: 다음 코드는 1부터 5까지의 숫자를 더해야 하지만, 예상과 다른 결과가 나온다.

#include <iostream>

int calculate_sum(int max_val) {
    int total_sum = 0;
    for (int i = 0; i < max_val; ++i) { // 오류 가능성이 있는 부분
        total_sum += i;
    }
    return total_sum;
}

int main() {
    int limit = 5;
    int final_result = calculate_sum(limit);
    std::cout << "Sum up to " << limit << " is: " << final_result << std::endl; // 예상: 1+2+3+4+5=15
    return 0;
}

calculate_sum 예제처럼 watch의 누적 값과 실제 반복 범위를 대조해 첫 차이를 찾습니다.

예시

어느 줄을 실행하기 전인지까지 함께 기록해야 값의 차이를 설명할 수 있습니다. 원 루프에서 i=4인 반복의 본문 실행 전 total_sum은 6이고, total_sum += i 뒤에는 10입니다. 다음 i=5 조건 검사는 거짓이라 5를 더하는 본문을 실행하지 않습니다. 수정 루프는 i=5 본문 실행 전에는 10·실행 후에는 15이며 다음 i=6에서 끝납니다. total_sum=10이라는 값 하나만으로 오류 위치를 확정할 수 없는 이유입니다.

독립 확인: 이 문제의 계약을 0≤max_val≤100에서 1부터 max_val까지의 합으로 정합니다. max_val=4와 0일 때 원 함수·수정 함수의 결과를 각각 구하세요. max_val=0만 통과한 시험으로 수정이 충분하다고 볼 수 있는지도 판단하세요.

고급 디버깅 기법 (간략 소개)

• 로그포인트 (Logpoint)
  • 브레이크포인트와 유사하지만, 프로그램 실행을 중지시키지 않고 변수 값을 출력하거나 특정 메시지를 출력합니다. cout 디버깅의 장점과 디버거의 편리함을 결합한 기능입니다.
• 데이터 브레이크포인트 (Data Breakpoint / Watchpoint)
  • 특정 메모리 주소의 값이 변경될 때 프로그램 실행을 중지시킵니다.
  • 어떤 코드가 의도치 않게 변수 값을 변경하는지 찾을 때 매우 유용합니다. (하드웨어 지원이 필요하며, 모든 디버거에서 지원하지 않을 수 있습니다.)
• 조건부 브레이크포인트
  • 특정 조건(i > 100, ptr == nullptr 등)이 참일 때만 브레이크포인트에서 멈추도록 설정합니다.
  • 수백만 번의 반복이 있는 루프에서 특정 조건이 만족되는 지점에서만 멈추고 싶을 때 유용합니다.
• 덤프 파일 (Dump File) 분석
  • 프로그램이 비정상 종료(크래시)되었을 때 생성되는 덤프 파일(core dump on Linux, .dmp on Windows)을 디버거로 로드하여 크래시 시점의 스택 트레이스 및 메모리 상태를 분석할 수 있습니다.
• 스레드 디버깅
  • 멀티스레드 프로그램에서 각 스레드의 실행 상태, 호출 스택, 지역 변수를 개별적으로 검사하고 제어할 수 있습니다.

디버거 기능은 모두 한 번에 쓰기보다 증상에 맞게 고르는 것이 좋습니다.

아래 다이어그램은 버그의 형태별로 우선 확인할 기능과 단서를 연결한 것입니다.

limit = 5
i = 4; total_sum = 10

i > 100
ptr == nullptr

디버깅 세션은 재현 조건을 고정하고 멈출 위치, 관찰할 상태, 수정 후 확인 범위를 순서대로 좁히면 훨씬 짧아집니다.

디버거 사용은 버튼 이름을 많이 외우는 것보다 실패를 재현하고, 정상 상태와 오류 상태가 처음 갈라지는 지점을 찾는 과정으로 이해하는 편이 오래 갑니다.