소프트웨어 개발 과정에서 버그를 수정하는 방식에 대한 새로운 접근법인 '클루버 기법(Kluever Maneuver)'이 개발자들 사이에서 논의되고 있습니다. 이 기법은 버그 수정을 단일 커밋이 아닌 두 개의 커밋으로 나누어 처리하는 것을 제안합니다. 첫 번째 커밋에서는 현재 버그가 있는 잘못된 동작을 '통과하는 테스트'로 기록하고, 두 번째 커밋에서는 실제 버그 코드를 수정하고 동시에 첫 번째 커밋에서 작성했던 테스트의 기대값도 올바른 값으로 변경하는 방식입니다.
클루버 기법의 핵심은 버그가 수정되기 전과 후의 동작 변화를 명확하게 보여주면서도, 모든 커밋에서 지속적인 통합(CI) 테스트가 통과 상태를 유지하도록 하는 데 있습니다. 예를 들어, `add(2, 2)`가 `5`를 반환하는 버그가 있을 때, 첫 커밋에서는 `assert add(2, 2) == 5`와 같이 현재의 잘못된 동작을 확인하는 테스트를 작성합니다. 이후 두 번째 커밋에서 `add` 함수를 `a + b`로 수정하고, 테스트도 `assert add(2, 2) == 4`로 변경하는 식입니다. 이는 버그 추적기(bug tracker)에 재현 커밋과 수정 커밋을 명확히 연결하여 기록하는 데도 유용하며, 첫 커밋의 테스트에 'FIXME: bug #1729'와 같은 버그 번호를 남기고 두 번째 커밋에서 이를 제거하며 'fixes: #1729'를 기록하는 것을 권장합니다.
이러한 방식은 단순히 코드와 테스트를 한 번에 수정하는 것과 달리, 버그가 실제로 수정되었음을 증명하는 강력한 근거를 제공합니다. 기존 방식에서는 테스트가 수정 전에도 우연히 통과했을 가능성이 있어, 실제 버그가 해결되지 않았음에도 잘못된 확신을 줄 수 있었습니다. 클루버 기법은 이러한 문제를 방지하고, 코드 리뷰어(code reviewer)가 변경 사항을 더 쉽게 이해하고 검증할 수 있도록 돕습니다. 또한, 모든 커밋이 CI를 통과하므로 개발 파이프라인의 안정성을 유지하면서도 버그 수정 과정을 투명하게 관리할 수 있다는 장점이 있습니다.
일부 개발자들은 이 기법이 테스트 주도 개발(TDD)과 유사하지만, TDD가 '실패하는 테스트'를 먼저 작성하는 것과 달리 클루버 기법은 '통과하는 잘못된 테스트'를 먼저 작성한다는 점에서 차이가 있다고 지적합니다. 하지만 LLVM이나 Rust 프로젝트 등에서는 이미 이와 유사한 접근 방식을 표준으로 채택하고 있으며, pytest의 `xfail` 데코레이터를 활용하여 예상된 실패를 명시하는 방식으로 클루버 기법의 의도를 구현하기도 합니다. 이는 버그 수정 과정의 명확성과 신뢰성을 높여 소프트웨어 품질 향상에 기여하는 중요한 개발 관행으로 자리 잡을 수 있습니다.