git bisect로 버그를 못 잡겠다면? 베이지안 확률로 비결정적 버그를 추적하는 git-bayesect

git bisect, 좋긴 한데 한계가 있었죠

git bisect는 버그가 처음 발생한 커밋을 찾아주는 Git의 킬러 기능이에요. 이진 탐색(binary search)으로 커밋 히스토리를 반으로 쪼개가면서, "이 커밋은 괜찮아 / 이 커밋은 버그 있어"를 반복하면 원인 커밋을 빠르게 좁힐 수 있거든요. 알고리즘 수업에서 배운 이진 탐색을 실전에서 바로 쓸 수 있는 멋진 도구죠.

그런데 이 도구에는 치명적인 전제가 하나 있어요. "특정 커밋에서 테스트를 돌리면 결과가 항상 같다"는 거예요. 즉, 버그가 있으면 항상 실패하고, 없으면 항상 성공해야 해요. 하지만 현실 세계의 버그는 그렇게 착하지 않거든요. 타이밍에 따라 가끔만 실패하는 레이스 컨디션(race condition), 메모리 상태에 따라 재현되었다 안 되었다 하는 버그, 네트워크 환경에 따라 달라지는 테스트... 이런 비결정적(non-deterministic) 버그 앞에서 git bisect는 속수무책이에요. 한 번 잘못된 good/bad 판정을 내리면 완전히 엉뚱한 커밋을 범인으로 지목하게 되니까요.

git-bayesect가 등장했어요

git-bayesect는 이 문제를 베이지안 확률(Bayesian probability)로 해결하는 도구예요. 이름에서 느껴지시죠? bisect + Bayesian = bayesect. 기존의 이진 탐색 대신, 각 커밋이 "버그를 도입한 커밋일 확률"을 계산하고 업데이트해 나가는 방식이에요.

베이지안 확률이라고 하면 어려워 보이지만, 핵심 아이디어는 간단해요. 처음에는 모든 커밋이 범인일 확률을 동일하게 놓고 시작해요. 그다음 특정 커밋에서 테스트를 돌려보고, 그 결과를 바탕으로 각 커밋의 확률을 업데이트하는 거예요. 테스트가 실패하면 "이 커밋 이전에 버그가 도입됐을 확률이 높겠군" 하고 확률을 조정하고, 성공하면 "이 커밋 이후에 도입됐을 가능성이 크겠네" 하고 조정하는 식이죠.

여기서 핵심은 한 번의 테스트 결과를 100% 신뢰하지 않는다는 거예요. 기존 git bisect가 "이 커밋은 good이야!" 하고 확정 짓는 것과 달리, bayesect는 "이 커밋은 70% 확률로 괜찮아 보여" 같은 식으로 불확실성을 유지해요. 그래서 가끔 테스트가 거짓 성공(flaky pass)을 내더라도 전체적인 추론이 망가지지 않아요.

어떻게 사용하나요?

사용법은 기존 git bisect와 꽤 비슷해요. 먼저 범위를 지정하고, 테스트 스크립트를 넘기면 돼요. 도구가 알아서 "다음에 어떤 커밋을 테스트하면 정보를 가장 많이 얻을 수 있을까"를 계산해서 최적의 커밋을 골라줘요. 이것도 베이지안 접근의 장점인데, 단순히 중간 커밋을 고르는 게 아니라 불확실성을 가장 크게 줄일 수 있는 커밋을 선택하거든요.

같은 커밋에서 테스트를 여러 번 돌리는 것도 지원해요. 비결정적 버그니까 당연히 같은 커밋에서 여러 번 시도해봐야 정확도가 올라가겠죠. 도구가 "이 커밋에서 한 번 더 돌려보는 게 나을까, 다른 커밋으로 넘어가는 게 나을까"도 확률적으로 판단해줘요.

Python으로 작성되어 있고, pip install git-bayesect로 간단히 설치할 수 있어요. 의존성도 가벼운 편이라 CI 환경에 넣기에도 부담이 적어요.

기존 도구들과 비교하면?

git bisect의 한계를 보완하려는 시도가 이전에도 없었던 건 아니에요. git bisect의 run 모드에서 스크립트의 종료 코드 125를 써서 "판단 불가"를 표현할 수는 있지만, 이건 해당 커밋을 건너뛰는 것이지 확률적으로 판단하는 게 아니에요. 결국 건너뛴 커밋이 많아지면 범위를 제대로 좁히지 못하게 되죠.

비슷한 아이디어로는 Mozilla에서 만든 mozregression이 있는데, 이건 브라우저 빌드에 특화된 도구라 범용적이지 않아요. git-bayesect는 범용 Git 도구로서, 어떤 프로젝트든 테스트 스크립트만 있으면 바로 쓸 수 있다는 점이 강점이에요.

한국 개발자에게 주는 시사점

비결정적 버그는 정말 모든 개발팀의 골칫거리예요. 특히 CI/CD 파이프라인에서 가끔씩 실패하는 flaky test 때문에 고생해 본 경험, 다들 한 번쯤은 있으시죠? "내 로컬에서는 되는데..."가 일상인 분들에게 이 도구는 꽤 실용적인 무기가 될 수 있어요.

당장 도입해보기 좋은 시나리오를 몇 가지 꼽자면, 동시성(concurrency) 관련 버그를 추적할 때, 테스트 환경의 타이밍이나 리소스에 민감한 테스트를 다룰 때, 또는 대규모 커밋 히스토리에서 성능 저하(regression)가 시작된 지점을 찾을 때 유용해요. 성능 테스트는 본질적으로 결과에 노이즈가 있으니까 확률적 접근이 딱 맞거든요.

마무리

git-bayesect는 "테스트 결과를 한 번에 믿지 않는다"는 단순하지만 강력한 아이디어로, 현실 세계의 지저분한 버그를 추적할 수 있게 해주는 도구예요. 여러분 팀에서 가장 골치 아팠던 비결정적 버그는 뭐였나요? 그때 이런 도구가 있었다면 얼마나 빨리 잡을 수 있었을까요?