Google Gemini API Docs MCP가 보여준 96.3%, 코딩 에이전트는 이제 문서를 같이 읽어야 합니다
96.3%가 붙은 건 모델이 아니었습니다
Google이 2026년 4월 1일 Google Blog에 올린 'Improve coding agents’ performance with Gemini API Docs MCP and Agent Skills.'에서 제가 멈춘 건 새 Gemini 모델 이름이 아니었습니다. Google은 Gemini API Docs MCP와 Gemini API Developer Skills를 같이 쓰면 vanilla prompting 대비 96.3% pass rate를 냈고, correct answer당 token은 63% 줄었다고 적었습니다. 오늘도 Gemini 검색량이 붙는 이유를 저는 이런 숫자에서 봅니다. 요즘 코딩 에이전트 얘기는 다들 모델부터 말하는데, Google은 문서 연결과 작업 습관을 먼저 꺼냈거든요.
문서를 붙인 agent, 규칙을 심은 agent
확인된 내용은 꽤 단순합니다. Google Blog 글 설명대로 Docs MCP는 coding agent를 현재 Gemini API 문서, SDK, 모델 정보에 붙여줍니다. Developer Skills는 best-practice instructions, resource links, patterns를 더해 주구요. 그러니까 agent가 혼자 똑똑해지는 구조가 아니라, 최신 문서와 권장 패턴을 runtime에 밀어 넣는 구조입니다.
Google이 같은 글에서 적은 문장이 하나 있는데, 이 문장이 사실상 요약입니다. 'Agents can generate outdated Gemini API code because their training data has a cutoff date.' 저는 이 문장이 올해 코딩 에이전트 시장의 불편한 진실에 더 가깝다고 봤습니다. 모델이 아무리 좋아도, 어제 바뀐 SDK를 모르면 실무에선 바로 낡아집니다.
제가 크게 본 건 63%였습니다
96.3%도 눈에 띄지만, 제 기준에선 63% fewer tokens가 더 현실적으로 들렸습니다. 매달 API 비용표 보는 사람 입장에선 정답률 몇 포인트보다 헛도는 turn이 줄어드는 게 훨씬 직접적이거든요. agent가 예전 예제 붙잡고 두세 번 다시 쓰고, 에러 읽고, 또 고치는 동안 나가는 건 token만이 아닙니다. 기다리는 사람 시간도 같이 빠집니다.
특히 회사에서 내부 도구 하나 붙일 때 이런 차이가 크게 납니다. 문서 버전이 안 맞아서 한 시간씩 새는 날이 반복되면, 모델 단가보다 운영 피로가 먼저 올라옵니다. Google이 이 숫자를 굳이 같이 내놓은 건 개발자 편의 얘기를 한 게 아니라 배포 비용 얘기까지 같이 한 셈이라고 봤습니다.
vibe coding이 여기서 달라집니다
vibe coding이 재밌는 이유는 프롬프트 몇 줄로 뭔가 바로 나오는 속도에 있죠. 근데 실무로 들어오면 분위기만으로는 오래 못 갑니다. 문서가 바뀌고, API 이름이 바뀌고, 권장 방식이 바뀌니까요. 이번 Google Blog 글이 중요했던 건 vibe coding을 더 화려하게 만들었다는 데 있지 않았습니다. Google은 코딩 에이전트가 최신 문서를 읽고, 권장 패턴을 따라가게 해야 production에 가까워진다는 쪽으로 말을 옮겼습니다.
여기서부터는 해석입니다. 이제 코딩 에이전트 경쟁은 누가 더 긴 context를 주느냐보다, 누가 더 최신 문서와 규칙 묶음을 잘 꽂아 넣느냐가 훨씬 커질 것 같습니다. 모델 성능표만으로는 실사용 차이를 설명하기 어려워질 가능성이 큽니다.
그래도 96.3%를 그대로 믿진 않습니다
의심할 지점도 있습니다. 96.3%와 63%는 Google이 만든 eval set 기준 숫자입니다. 이 수치가 모든 팀의 repo, 모든 SDK 마이그레이션, 모든 에이전트 워크플로에서 그대로 나온다고 단정하면 과합니다. 실전은 사내 wrapper도 있고, 이상한 legacy 코드도 있고, 문서에 없는 예외도 많거든요.
다만 이 한계가 오히려 메시지를 더 선명하게 만든다고 느꼈습니다. Google이 내세운 승부수가 새 모델 벤치마크가 아니라 docs access와 skills packaging이었다는 점 말입니다. 숫자가 조금 내려가도 방향은 남습니다.
다음 비교표엔 뭐가 먼저 올라올까
제 추측은 이렇습니다. 다음 분기부터는 코딩 에이전트 평가표에 model name 옆으로 docs freshness, MCP bundle, team skill pack 같은 항목이 붙기 시작할 수 있습니다. agent를 잘 쓰는 팀과 계속 삐끗하는 팀의 차이도 거기서 벌어질 가능성이 크구요.
다음에 코딩 에이전트가 똑똑하다는 말을 들으면, 저는 benchmark보다 그 agent가 어제 문서를 읽었는지부터 볼 겁니다.
