먼저 실패를 판단하는 기준 정하기
재현 코드를 줄이려면 무엇이 실패인지부터 명확해야 합니다. 단순히 프로그램이 이상하다는 설명으로는 코드를 제거했을 때 문제가 남아 있는지 판단하기 어렵습니다. 특정 입력에서 합계가 달라지는지, 같은 작업을 반복하면 충돌하는지, 정해진 시간 안에 응답하지 않는지 구체적인 관찰 기준을 적습니다. 기대 결과와 실제 결과를 함께 남기면 다른 사람도 같은 실패를 확인할 수 있습니다. DBG Desk에서 정지한 주소만 기준으로 삼으면 빌드나 실행마다 달라질 수 있으므로 결과와 입력 조건을 중심으로 재현을 정의하는 편이 좋습니다.
한 번에 한 종류의 조건만 줄이기
큰 입력을 줄일 때는 파일의 일부를 제거하거나 요청 개수를 줄이는 식으로 한 종류의 변화를 먼저 시도합니다. 코드와 컴파일 옵션, 입력을 동시에 바꾸면 문제가 사라졌을 때 무엇이 영향을 줬는지 알기 어렵습니다. 절반을 제거한 뒤에도 실패하면 남은 절반을 기준으로 다시 줄이고, 사라지면 되돌려 다른 부분을 확인합니다. 이 과정에서 실패가 유지된 마지막 버전을 따로 보관하세요. 재현이 간헐적이라면 한 번 성공했다고 원인이 없어졌다고 판단하지 말고 원래의 발생 빈도를 고려해 비교해야 합니다. 줄이는 작업에도 관찰 기준이 필요합니다.
실행 환경도 재현의 일부로 다루기
입력과 소스만 같아도 운영체제, 대상 아키텍처, 최적화 설정, 환경 변수나 작업 폴더가 다르면 실패가 나타나지 않을 수 있습니다. 특히 메모리 수명 문제와 스레드 순서 문제는 코드 정리 자체가 배치와 타이밍을 바꾸기도 합니다. 작은 예제에서는 사라지는데 원본에서만 남는다면 재현을 못 만들었다는 사실도 중요한 정보입니다. 사라지기 직전에 무엇을 제거했는지 기록하고 그 조건을 하나씩 복원해 보세요. 불필요해 보인 초기화나 파일 열기 작업이 자원 사용 순서에 영향을 줬을 가능성도 있습니다. 가설과 확인한 사실을 구분해서 남겨야 합니다.
다른 PC에서도 실행 가능한 자료로 정리하기
최종 재현 자료에는 빌드 명령, 실행 명령과 인수, 필요한 입력 파일의 구조, 기대 결과와 실제 결과가 있어야 합니다. 개인 경로나 비밀 값에 의존하는 자료는 다른 환경에서 그대로 쓸 수 없으므로 공개 가능한 작은 데이터로 바꾸되 같은 실패가 남는지 확인합니다. 디버거의 어느 지점에 멈춰 무엇을 보면 되는지도 덧붙이면 관찰을 반복하기 쉽습니다. 수정 후에는 작은 재현과 원래 실패했던 입력을 모두 실행하세요. 줄인 예제가 통과한다고 원래 작업 전체가 해결됐다고 보장되지는 않습니다. 재현 자료는 원인을 설명하고 수정을 확인하는 기준으로 남겨 두는 것이 좋습니다.
줄이기 전후의 비교표 대신 기록 세 줄
각 실험마다 제거한 부분, 실행 조건, 실패 유지 여부를 세 줄로 남겨 보세요. 입력의 절반을 제거했더니 실패가 사라졌다면 원본을 복원하고 다른 절반을 제거해 비교할 수 있습니다. 실패가 남은 마지막 버전을 보관하지 않으면 여러 변경을 되돌리는 데 시간이 듭니다. 간헐적인 충돌이라면 반복 횟수와 관찰 시간을 적어 한 번의 통과를 성공으로 오해하지 않도록 합니다. 코드를 짧게 만드는 것이 최종 목표는 아닙니다. 다른 사람이 같은 문제를 보고 동일한 기대 결과와 실제 결과를 비교할 수 있을 만큼 조건을 분명히 만드는 것이 목표입니다.