디버깅이 막힐 때: 재현·가설·검증으로 작업 나누기

오류를 고칠 때 여러 조건을 한꺼번에 바꾸면 어떤 변경이 문제를 해결했는지 알기 어렵습니다. 먼저 같은 입력으로 문제가 다시 나타나는지 확인하고, 예상과 실제를 적은 뒤 하나의 가설을 검증합니다. 다음 코드는 실제 Focus Zone의 결제 기능이 아니라 설명을 위해 만든 독립적인 JavaScript 예제입니다.

기대 동작과 오류를 먼저 적기

가상의 규칙은 ‘10,000원 이상이면 1,000원 할인’입니다. 입력은 음수가 아닌 정수 금액이라고 가정합니다.

function finalPrice(amount) {
  return amount > 10000 ? amount - 1000 : amount;
}

console.log(finalPrice(10000)); // 실제: 10000, 기대: 9000

오류 메모는 ‘할인이 안 됨’보다 ‘10,000원 입력에서 9,000원을 기대했지만 10,000원이 나옴’이 좋습니다. 실행 위치와 입력이 정해져야 같은 문제를 다시 확인할 수 있습니다. 이 예제의 입력 조건 밖에 있는 문자열이나 통화 소수점 처리는 별도의 요구사항입니다.

가설을 구분해서 검증하기

첫 가설은 금액이 잘못 전달됐다는 것입니다. 함수에 숫자 10000을 직접 넣어도 문제가 남으므로 이 작은 재현에서는 입력 전달 과정 없이도 오류가 발생합니다. 실제 앱 전체의 전달 오류까지 없다고 증명한 것은 아닙니다.

다음 가설은 경계 조건이 빠졌다는 것입니다. 9,999원, 10,000원, 10,001원을 넣어 봅니다. 원래 코드는 각각 9,999원, 10,000원, 9,001원을 반환합니다. 규칙의 ‘이상’에 비해 코드의 비교는 ‘초과’여서 정확히 10,000원만 할인에서 빠집니다.

최소 수정 뒤 같은 입력으로 확인

function finalPrice(amount) {
  return amount >= 10000 ? amount - 1000 : amount;
}

const cases = [[9999, 9999], [10000, 9000], [10001, 9001]];
for (const [input, expected] of cases) {
  if (finalPrice(input) !== expected) {
    throw new Error('할인 경계 검증 실패: ' + input);
  }
}

수정 뒤에는 실패했던 입력뿐 아니라 경계 양쪽을 확인합니다. 정상 입력 하나만 실행하면 비교 조건이 올바른지 놓칠 수 있습니다. 이 검증은 여기서 정한 단순 할인 규칙에 대한 것이며 실제 결제에 필요한 모든 검증을 대신하지 않습니다.

실제 프로젝트에서 재현이 안 될 때

입력, 로그인 상태, 데이터 버전, 발생 순서, 시간대처럼 결과를 달리할 수 있는 조건을 기록합니다. 민감한 토큰과 개인정보는 로그나 질문에 붙이지 않습니다. 재현되지 않는다는 이유로 해결됐다고 표시하기보다 어느 조건까지 확인했는지 남깁니다.

가설 메모는 ‘입력 전달 문제 → 직접 호출에서도 재현 → 다음은 비교 조건 확인’처럼 짧아도 됩니다. 확인할 자료가 없으면 설정을 무작위로 바꾸는 대신 필요한 관찰을 얻는 작업으로 전환합니다. 실제 운영 데이터 변경 없이 작은 입력으로 분리할 수 있는지 먼저 봅니다.

한 세션 끝에 남길 내용

‘재현 입력 / 기대와 실제 / 검증한 가설 / 변경 / 남은 범위’를 저장합니다. 원인을 찾았지만 배포 환경은 확인하지 않았다면 그 구분을 유지합니다. 다음 세션은 남은 검증부터 시작합니다. 90분을 채웠다는 기록보다 어떤 가설을 배제하고 무엇을 확인했는지가 인계에 유용합니다.