systematic-debugging — 오류의 원인부터 찾기
오류를 재현하고 원인을 좁힌 뒤 작은 수정으로 검증하는 스킬입니다. 급한 오류일수록 추측으로 고치지 않도록 돕습니다.
systematic-debugging 은 프로그램이 예상과 다르게 움직일 때 원인을 확인하고 고치는 순서를 안내하는 스킬입니다. 우리 작업 기록의 활용도 TOP10에서 9위 였습니다. 버튼이 반응하지 않거나 테스트가 실패하고, 배포 후에만 오류가 생기는 상황처럼 원인을 바로 알 수 없는 작업에 씁니다.
언제 쓰나요?
오류 메시지가 나타났을 때, 같은 작업이 어떤 날은 되고 어떤 날은 실패할 때, 최근 수정 이후 기능이 달라졌을 때 사용합니다. 단순해 보이는 문제라도 먼저 재현하고 근거를 모으도록 안내합니다. 사용자가 보는 증상과 실제 원인이 다른 위치에 있을 수 있기 때문입니다.
어떻게 부르나요?
“검색 버튼이 눌려도 결과가 안 바뀝니다. systematic-debugging 순서로 재현하고 원인을 찾아 고쳐 줘” 라고 요청할 수 있습니다. 오류가 난 주소, 누른 버튼, 입력한 값, 기대한 결과, 실제로 본 메시지를 함께 주면 시작점이 분명해집니다. “어제 수정한 뒤 회원 글이 열리지 않습니다. 실패한 테스트부터 읽어 줘” 처럼 변화한 시점도 알려 주세요.
실제로 하는 일
원인 조사: 오류 메시지 전체를 읽고 같은 방법으로 실패를 재현합니다. 최근 변경과 구성 요소 사이의 데이터 흐름을 확인합니다.
작동 사례 비교: 같은 프로젝트에서 잘 작동하는 비슷한 코드를 찾아 차이를 살핍니다.
가설 검증: “이 값이 전달되지 않아 실패한다”처럼 한 가지 가설을 세우고 작은 실험으로 확인합니다.
수정과 재검증: 원인을 겨냥한 최소 수정 후 원래 실패한 경우와 기존 테스트를 다시 실행합니다.
스킬에는 추측으로 여러 곳을 한꺼번에 바꾸지 말라는 원칙이 있습니다. 수정이 세 번 이상 효과가 없으면 같은 방법을 계속 반복하지 않고 구조 자체가 문제인지 살펴보라고 안내합니다. 환경이나 외부 서비스 문제로 결론 나더라도 조사한 내용과 남은 불확실성을 기록합니다.
잘 쓰는 요령
재현 순서 를 적어 주세요. “로그인 → 메뉴 선택 → 저장”처럼 순서가 있어야 같은 실패를 확인할 수 있습니다.
오류 문구를 그대로 전하세요. 짧게 요약하다가 원인을 가리키는 정보가 빠질 수 있습니다.
고친 뒤 원래 문제가 없어졌는지 확인해 달라고 하세요. 빌드 통과만으로 화면 문제가 해결된 것은 아닙니다.
확인하지 못한 부분 을 따로 보고받으세요. 재현하지 못한 오류를 해결됐다고 말하지 않는 것이 중요합니다.
빨리 고치는 길은 먼저 실패가 어디서 시작되는지 확인하는 것입니다.