모델을 업그레이드하면 결과가 좋아진다고 믿는 팀들이 있다. 더 비싼 모델, 더 큰 파라미터, 더 높은 벤치마크 점수. 그런데 dev.to에 올라온 한 실험이 그 믿음에 정면으로 반박하는 데이터를 들고 나왔다. Anthropic의 가장 작고 저렴한 모델인 Claude Haiku 4.5가, 더 강력한 Claude Sonnet 4.6으로 돌아가는 Claude Code를 PR 작성 품질에서 앞질렀다. 그것도 Gemini의 블라인드 평가로.
결과만 보면 의외처럼 보이지만, 이유는 단순하다. Claude Code는 PR 작성 요청을 받았을 때 git log --oneline과 git diff --stat 두 커맨드만 실행했다. 커밋 제목과 파일 변경 통계. 이게 전부다. 반면 Haiku에게는 380KB짜리 구조화된 XML 파일이 주어졌다. 변경된 모든 파일의 전체 내용, 유니파이드 diff, 커밋별 메타데이터, 미커밋 변경사항 경고까지. 같은 피처 브랜치를 두고, 한 쪽은 썸네일을, 다른 쪽은 원본 소스를 받은 셈이다.
품질 차이는 세 군데에서 명확하게 드러났다. 첫째, 제품 컨텍스트. Claude Code 출력은 "the Stack"이라는 내부 용어를 설명 없이 썼다. Haiku 출력은 "Git Tools를 Notion, Local Files, Context Blocks와 함께 네 번째 소스 타입으로 도입"이라고 풀어냈다. 둘째, 기능 정확도. Claude Code는 Commit Brief가 "단일 커밋을 스캔한다"고 설명했지만, 실제로는 미커밋 변경사항을 스캔하는 기능이다. diffstat으로는 절대 잡을 수 없는 의미론적 차이다. Haiku는 구현 코드를 직접 읽었기 때문에 맞게 썼다. 셋째, 테스트 증거. "pytest 커버리지 완비"(주장)와 "test_git_service.py에 41개 신규 테스트, 총 199개 통과"(증거)의 차이. Gemini는 전자를 'trust me', 후자를 'brings the receipts'라고 평가했다.
흥미로운 건 최종 랭킹이다. 1위는 XML 컨텍스트 + Sonnet, 2위는 XML 컨텍스트 + Haiku, 3위는 Claude Code + Sonnet이었다. 모델 등급이 아니라 컨텍스트 품질이 순위를 결정했다. 그리고 Haiku는 Sonnet 대비 비용이 극적으로 저렴하다. 프롬프트 캐싱까지 적용하면 입력 비용 대부분이 흡수된다. 더 스마트한 모델에 돈을 쓰는 게 아니라, 무엇을 먹일지 설계하는 데 시간을 쓰는 것이 ROI가 훨씬 높다는 뜻이다.
이 실험이 더 의미 있는 이유는, 동시에 터지고 있는 Vibe 코딩 현장의 데이터와 정확히 같은 방향을 가리키기 때문이다. 소프트웨어 개발 에이전시 Redwerk의 창업자가 dev.to에 공개한 내부 설문 결과는 냉정하다. AI 생성 코드를 수정 없이 배포하는 비율은 팀원 대부분이 0~40% 수준에 머물렀다. 89%가 중간~상당한 수준의 수정을 한다. 22%는 대규모 재작업이 필요하다고 답했다. CodeRabbit 보고서를 인용하면 AI 생성 코드는 취약점을 2.74배 증폭시키고, 로직·정확성 오류가 75% 더 많다.
더 구체적인 패턴도 있다. 팀원들이 꼽은 가장 큰 문제는 컨텍스트 창이 커질수록 심해지는 환각, 여러 파일에 걸친 리팩터링에서의 일관성 붕괴, 그리고 "대시보드 만들어줘" 같은 모호한 프롬프트가 만들어내는 쓸모없는 출력이었다. 주목할 부분은 이 세 문제가 결국 같은 뿌리를 가지고 있다는 점이다. AI에게 충분한 컨텍스트를 주지 않거나, 컨텍스트가 너무 커서 오히려 노이즈가 된 상황이다.
비기술 창업자가 Lovable이나 Bolt.new로 MVP를 만들고 200명, 2000명의 사용자를 받는다. 그러다 SSO 요구, Safari 버그, Stripe 이중 결제, 50만 행에서의 쿼리 타임아웃이 몰려온다. 이 시점에 필요한 건 AI가 아니라 코드를 이해하는 사람이다. 기술 부채는 1일 차에 보이지 않는다. 60일 차에, 창업자가 'vibe code cleanup service'를 검색하는 순간 가시화된다. 이게 Vibe 코딩 실패 패턴의 전형이다.
두 데이터를 합치면 하나의 명확한 교훈이 나온다. AI가 코드를 쓰는 것과, AI가 코드를 제대로 쓰게 만드는 것은 완전히 다른 작업이다. 전자는 프롬프트 한 줄로 시작된다. 후자는 무엇을 컨텍스트로 넣을지, 어떤 구조로 정리할지, 어떤 부분을 검증할지를 설계하는 일이다. Claude Code가 느리거나 나쁜 도구여서가 아니다. 범용 도구는 범용적인 방식으로 컨텍스트를 수집하고, 그 결과 특정 작업에서는 구조화된 전문 컨텍스트보다 낮은 출력을 낼 수밖에 없다.
팀 리드 입장에서 이 논의는 두 가지 실행 과제로 좁혀진다. 하나는 컨텍스트 어셈블리를 AI 도구에 위임하지 않는 것이다. PR 작성이든, 코드 리뷰든, 설계 문서 초안이든—AI가 어떤 정보를 보고 작업하는지를 팀이 직접 통제해야 한다. CLAUDE.md 같은 프로젝트 규약 파일, 구조화된 diff 컨텍스트, 명시적인 테스트 커버리지 정보를 미리 조립해서 먹이는 것이 모델 등급을 올리는 것보다 효과적이다. 다른 하나는 AI 생성물에 대한 품질 게이트를 자동화하는 것이다. 89%의 코드가 수정을 필요로 한다면, 검토 프로세스를 사람이 매번 수동으로 처리하는 구조는 병목이 된다. 어떤 체크를 자동화하고, 어떤 판단을 사람에게 남길지를 명시적으로 설계해야 한다.
모델은 계속 좋아질 것이다. 6개월 후 Haiku 자리에 어떤 모델이 올지는 모른다. 하지만 컨텍스트를 잘 조립하는 팀과 그렇지 않은 팀의 격차는 모델이 좋아진다고 줄어들지 않는다. 오히려 더 강력한 모델일수록 좋은 컨텍스트와 나쁜 컨텍스트의 차이를 더 크게 증폭시킨다. 지금 당장 팀의 AI 워크플로우에서 'AI가 실제로 무엇을 보고 작업하는지'를 한 번 들여다봐야 할 이유가 여기에 있다.