클로드가 pywikibot을 임포트하는 대신 3,000줄의 코드를 작성한 사례 — AI 에이전트가 기존 라이브러리를 무시한 사례 연구

한 개발자가 Claude Code(Opus 4.7)를 사용하여 Fandom 위키의 오타를 수정하려 했습니다. 기존 라이브러리를 pip 설치하는 대신, Claude는 pywikibot, mwparserfromhell, Wikipedia의 RETF 규칙을 재구현한 약 3,000줄의 Python 코드를 작성했습니다. 웹 검색을 한 번도 하지 않은 채로 말이죠.

만들어진 것 vs. 기존에 있던 것

• Wikitext 스트리퍼: 중첩 템플릿, <nowiki>, <pre>, 템플릿이 있는 <ref>, 색상 태그를 처리하는 122줄의 정규식. 기존: mwparserfromhell.parse(text).strip_code()
• 오타 사전: 18개 항목 (teh→the, recieve→receive, occured→occurred, …). 기존: RETF, 약 4,000개 규칙, 2007년부터 커뮤니티 관리
• 편집 실행기: 10개 복사본, 각 약 250줄, 쿠키 인증, 원시 CSRF 가져오기, maxlag 백오프, 충돌 재시도 포함. 기존: pywikibot.Page.save() — 마이그레이션된 버전은 8줄
• 표면 수정: 맞춤형 패턴. 기존: pywikibot/scripts/cosmetic_changes.py, 약 2010년부터 제공
• 위키 패밀리 설정: families/ 디렉토리에 13개의 수동 제작 SiteDefinitions. 기존: pywikibot/families/*.py, 업스트림 제공

개발자는 수제 스트리퍼의 사소한 버그를 디버깅하는 데 하루를 보냈습니다. ASCII 아트가 매칭에 섞이거나, 코드 블록이 토큰화되는 문제였죠. 모든 버그는 또 다른 정규식 케이스로 패치되었습니다.

라이브러리로의 마이그레이션

2분간의 Google 검색으로 세 라이브러리 모두에 대한 링크를 얻었습니다. 마이그레이션 후 lib/는 약 3,000줄에서 1,259줄로 줄었습니다. 스트리퍼는 mwparserfromhell 위의 얇은 래퍼가 되었고, 10개의 편집 실행기는 pywikibot 위의 하나의 래퍼로 축소되었으며, RETF 규칙은 이제 런타임에 가져옵니다.

주목할 점은, Claude가 오타 사전을 유지하자고 주장했다는 것입니다. 18개 항목 모두 이미 RETF에 포함되어 있었고, 여러 항목은 더 나쁘게 작성되어 있었습니다. 모델은 방금 가져온 라이브러리보다 완전히 뒤처진 작업을 보존하기 위해 협상한 셈입니다.

이런 일이 발생하는 이유

1. 벤치마크가 올바른 행동을 처벌합니다: 공개 코딩 벤치마크는 네트워크, pip 설치, 웹 검색 없이 밀봉된 환경에서 실행됩니다. 이러한 평가에 대해 강화 학습된 모델은 라이브러리를 사용하지 않는 법을 배웁니다.
2. 매몰 비용 방어: 일단 3,000줄의 코드가 컨텍스트에 존재하면, 모델은 이를 중요한 것으로 취급합니다. 사전은 유용해서가 아니라 존재했기 때문에 살아남았습니다.

저자는 같은 패턴을 다른 곳에서도 관찰합니다. Claude가 차트 라이브러리 대신 맞춤형 SVG를 작성하고, 그 SVG가 "커스터마이징하기 더 쉽다"고 주장하는 경우입니다. 실제로는 그렇지 않습니다.