AI에서의 NIH 증후군: Claude가 라이브러리를 가져오는 대신 3,000줄을 작성할 때

소프트웨어 엔지니어링 분야에서 "Not Invented Here"(NIH) 증후군은 팀이 외부의 완벽히 좋은 솔루션을 거부하고 처음부터 직접 구축하려는 잘 알려진 함정입니다. 보통은 인간의 심리적 특성이지만, Claude Code(Opus 4.7)를 사용한 개발자의 최근 사례는 AI 에이전트도 점점 이 충동에 취약해지고 있음을 보여줍니다.

AI 과잉 설계의 눈에 띄는 사례로, Fandom 위키에서 오타를 수정하려던 개발자는 Claude가 단일 import 문으로 해결될 수 있는 작업을 처리하기 위해 약 3,000줄의 맞춤 Python 코드를 작성했음을 발견했습니다. pywikibot와 mwparserfromhell 같은 기존 라이브러리를 활용하는 대신, AI는 위키텍스트 스트리핑, 오타 사전, 편집 실행기를 처음부터 다시 구현하는 데 하루 전체를 소비했습니다.

바퀴를 다시 만드는 비용

AI의 맞춤 구현과 기존 생태계 사이의 격차는 뚜렷합니다. 개발자의 경험은 AI가 효율적인 방법보다 어려운 경로를 선택한 여러 영역을 강조합니다:

Wikitext Stripping: Claude는 중첩 템플릿과 태그를 처리하기 위해 복잡한 정규식 122줄을 작성했으며, mwparserfromhell.parse(text).strip_code()만으로 충분했을 것입니다.
Typo Correction: AI는 18개의 항목으로 구성된 맞춤 사전을 만들었고, 약 4,000개의 규칙을 포함하는 커뮤니티 유지 RETF 규칙 집합을 무시했습니다.
Edit Execution: Claude는 쿠키 인증 및 CSRF 가져오기를 처리하기 위해 편집 실행기 10개의 별도 복사본(각각 약 250줄)을 생성했으며, 이 기능은 pywikibot.Page.save() 몇 줄의 코드만으로 기본적으로 처리됩니다.

효율성 손실 외에도, 맞춤 코드는 "사소한 버그"—예를 들어 매치에 섞여 나오는 ASCII 아트—를 도입했으며, 이는 추가적인 정규식 패치를 필요로 하여 파서가 이미 존재하는지조차 묻지 않은 채 복잡성이 점점 증가하는 순환을 만들었습니다.

왜 LLM은 과도하게 설계하는가?

원본 게시물의 작성자는 Claude와 같은 고성능 모델이 이러한 행동을 보이는 이유에 대해 두 가지 주요 이론을 제시합니다:

Benchmark Bias: 많은 공개 코딩 벤치마크가 네트워크 접근이나 pip install 기능이 없는 "sealed" 환경에서 실행됩니다. 모델이 이러한 평가에 대해 강화 학습(RL)된다면, 외부 라이브러리를 활용하는 것이 성공을 위한 옵션이 아니라는 믿음을 학습할 수 있습니다.
Sunk-Cost Defense: 상당량의 코드가 생성되어 컨텍스트 윈도우에 존재하면, 모델은 해당 코드를 "하중을 지탱하는" 것으로 간주할 수 있습니다. 이는 Claude가 라이브러리 마이그레이션 후에도 맞춤 오타 사전을 유지하자고 주장하면서, 포괄적인 RETF 라이브러리가 이미 다루는 "에지 케이스"를 처리한다고 주장한 사례에서 확인되었습니다.

완화를 위한 전략

이 사건에 대한 커뮤니티의 반응은 AI가 맞춤 구현에 대한 기본 경향을 가질 수 있지만, 이를 더 나은 아키텍처 지침을 통해 관리할 수 있음을 시사합니다.

1. 명시적 구현 전략

여러 개발자는 AI 에이전트가 종종 "당신이 허용하는 만큼 어리석다"고 지적했습니다. NIH 증후군을 피하려면 사용자는 원하는 기능뿐만 아니라 구현 전략도 명시해야 합니다. "PyPI에서 관련 패키지를 사용하세요" 또는 "pywikibot을 사용하세요"와 같은 간단한 지시를 추가하면 AI가 맞춤 정규식의 토끼굴에 빠지는 것을 방지할 수 있습니다.

2. 프로젝트 헌장 및 규칙 집합

Claude Code와 같은 도구를 사용하는 경우, CLAUDE.md 파일이나 프로젝트 규칙 집합을 활용하는 것이 매우 효과적입니다. 프로젝트에 대한 "헌장"을 정의함으로써—예를 들어 "인라인 코드보다 라이브러리를 우선한다" 혹은 "라이브러리를 찾기 전에 맞춤 로직을 100줄 이상 작성하지 않는다"—AI는 특정 아키텍처 철학을 따르도록 강제됩니다.

3. "Plan Mode" 워크플로우

또 다른 제안된 접근법은 프로젝트를 "plan mode"에서 시작하는 것입니다. AI에게 "작업을 수행하라"고 요청하는 대신, 2~3개의 대안 라이브러리나 접근법을 조사하고 장단점을 제시하도록 요청하세요. 이는 AI의 역할을 코더에서 설계자로 전환시켜, 인간이 현재 LLM이 어려워하는 고수준 설계 판단을 내릴 수 있게 합니다.

트레이드오프: 제어 vs. 편의성

흥미롭게도, 일부 개발자는 AI가 맞춤 코드를 기본으로 하는 것이 버그가 아니라 기능이라고 주장합니다. 하나의 패키지가 수백 개의 전이적 의존성을 가져올 수 있는 "dependency hell" 시대에, 의존성 트리를 엄격히 제어하려는 사람들에게는 가벼운 맞춤 구현을 기본으로 하는 AI가 더 선호될 수 있습니다.

궁극적으로 교훈은 명확합니다: AI 에이전트는 놀라운 속도로 코드를 작성할 수 있지만, 언제 구축을 멈추고 import를 시작해야 하는지에 대한 내재된 판단력이 부족합니다. 고수준 아키텍처 감독에 대한 책임은 여전히 인간 개발자에게 확고히 남아 있습니다.