의존성 업데이트로 깨진 동작을 Claude Code와 과학적 방법으로 추적하며, 다중 상속의 MRO로 인한 래퍼 클래스 오버라이드 문제를 밝혀내고 테스트 전용 함수로 우회한 경험과 교훈.
읽는 데 4분
프로젝트의 의존성을 업데이트하려고 했다. 벌써 세 번째 시도다!
지난 두 달 동안의 시도는 성공적이지 못했다. 한 번에 너무 많은 라이브러리를 올리려다 보니(가끔은 되기도 하니까, 알지?) 문제가 생겼다. 자세한 얘기는 생략하겠다. 요점은 우리가 중첩 트랜잭션으로 달성해 둔 트랜잭션 격리가 테스트에서 깨졌다는 것이다.
이번에는 아주 체계적으로 접근했다. 시작점으로 내 코드를 겉보기 수준에서 버전 무관하게 만들어, 잘 동작하는 버전과 깨지는 버전 사이를 쉽게 오갈 수 있게 했다. 왜냐하면 물론 의존성 업데이트는 전혀 관계없는 호환성 파괴 변경을 들이밀기 마련이고, 파이썬 커뮤니티는 2→3 대실수에서 그다지 많이 배우지 못한 듯하니까.
그다음 git bisect로 문제를 일으키는 의존성의 특정 커밋을 찾아냈다. 커밋 메시지는 "draw the rest of the owl"인데, 1,595줄에 달하는 괴수 같은 리라이트였다. 친구, 그 부엉이를 정말 아름답게 그렸길 바란다.
이 야행성 맹금류를 이해하는 데 며칠을 쓰고 싶진 않았다. 그래서 Claude Code를 켜고 상황을 설명하고, diff를 넘겨주고, 좋은 커밋에서 테스트를 돌리고 그다음 나쁜 커밋에서 테스트를 돌리게 했다. 이렇게 해서 문제의 원인이 정말로 의존성 업그레이드라는 걸 납득시키고, "현재 시스템 동작에 맞추기 위해 테스트를 다시 쓰자" 같은 소리를 하지 않도록 말이다. 알잖나, 얘가 그런 식으로 잘 엇나간다는 걸.
Claude Code는 이 방법 저 방법을 시도하다가, 늘 그렇듯 숲속에서 길을 잃기 시작했다. 어느 순간 하나의 아이디어에 꽂히면 그게 맞다고 믿고 억지로 밀어붙이려 든다. 물론 성공하지 못한다. 그 아이디어가 틀렸으니까.
점점 답답해지려던 찰나, 예전에 내가 디버깅 제대로 하는 법에 대해 강연하며 했던 조언을 떠올렸다.
과학적 방법을 쓰고, 모든 걸 적어라!
그래서 즉시 Claude에게 이렇게 지시했다. "우리가 하려는 일, 모든 가설, 이를 뒷받침하거나 충돌하는 증거를 파일 wip.md에 적어라."
이건 확실히 마법의 주문이었다. 장단점을 붙여 다섯 가지 서로 다른 가설을 썼고, 그중 하나에는 단점이 없었다. 심지어 대문자로 ROOT HYPOTHESIS(근본 가설)라고 표시까지 해 놓았다. 하지만 요약해 놓으면 그 생각이 머릿속의 유일한 진리로 굳어지지 않고, 여러 가설 중 하나일 뿐이 된다! 상충하는 증거가 없을 때 가설로 우리가 해야 할 일은 무엇인가? 그게 사실이라고 가정하고 150줄짜리 코드를 쓰는 게 아니다. 반례를 찾기 위한 최소한의 실험을 하고, 관찰을 더 모으는 것이다.
그랬더니 훨씬 매끄럽게 굴러갔고, 실제 문제가 무엇이었는지 금방 찾아냈다. 정답은 다중 상속이 있는 객체 지향 프로그래밍이었다. MRO(Method Resolution Order) 분석 결과, 어떤 컴포넌트가 다른 컴포넌트의 메서드를 오버라이드하는 래퍼 클래스를 만들어내고 있었는데, 이 래퍼 생성은 내부에 몇 가지 매개변수를 넘기느냐에 따라 조건부로 이루어지고 있었다.
흥미로운 점은, OOP와 다중 상속, 오버라이드, 간접화가 얽히면서 Claude조차도 고친 코드를 내는 데 애를 먹었다는 것이다. 결국 나는 그 OOP 난장판을 우회해, 테스트에서만 쓰이는 짧은 전용 함수를 하나 써서 올바르게 설정하도록 했다.
여기, 관련은 없지만 세 가지 관찰:
