에이전트가 기대만큼 일하지 못할 때 팀이 가장 먼저 꺼내는 카드는 둘 중 하나다. 모델을 바꾸거나, 도구를 더 붙이거나. 둘 다 결재받기 쉬운 선택이다. 예산 항목이 분명하고, 바꾼 뒤에 무엇이 달라졌는지 설명하기도 쉽다.
지난주 GitHub이 공개한 기록은 그 반대 방향을 가리킨다. 더 나은 도구로 바꿨더니 결과가 나빠졌고, 도구를 그대로 둔 채 사용 규칙만 다시 써서 되돌렸다.
도구를 좋은 것으로 바꾼 일은 개선이 아니었다
GitHub은 Copilot 코드 리뷰가 쓰던 전용 도구를 Copilot CLI가 쓰는 공용 도구 — grep, glob, view — 로 옮겼다. 더 검증된 도구였으니 리뷰도 좋아질 것으로 봤다.
결과는 반대였다. 에이전트는 리뷰를 하는 대신 저장소를 넓게 훑기 시작했다. GitHub의 표현으로는 "넓게 검색하고, 그럴듯한 경로를 추측하고, 그 여분의 맥락을 그대로 안고 갔다". 도구 호출 결과는 전부 토큰으로 컨텍스트 창에 남는다. 평균 비용은 올랐고 쓸모 있는 코멘트는 줄었다.
원인은 도구가 아니라 도구에 붙은 설명이었다. 공용 도구의 지시문은 대화형 코딩 어시스턴트를 위해 쓰인 것이다. 그 어시스턴트에게는 넓게 탐색하는 것이 맞는 행동이다. 리뷰어에게는 아니다. 리뷰어는 diff에서 출발해 특정 질문에 답하면 된다. 같은 도구가 같은 능력을 갖고도 다른 일을 한 이유는, 무엇을 쥐고 있느냐가 아니라 언제 쓰라고 적혀 있느냐가 달랐기 때문이다.
고친 것은 코드가 아니라 문장이었다
GitHub이 한 일은 도구 지시문을 리뷰어의 행동에 맞춰 다시 쓴 것이다. diff의 질문에서 시작할 것, 파일을 읽기 전에 검색 범위를 먼저 좁힐 것, grep과 glob으로 찾고 view로 정확한 근거만 확인할 것, 검색과 읽기를 번갈아 하지 말고 좁힌 읽기를 묶어서 할 것. 도구 구현은 건드리지 않았다.
평균 리뷰 비용이 약 20% 내려갔고 품질은 유지됐다. GitHub은 여기서 "도구 설명과 시스템 지시문은 API 문서에 가깝다"는 결론을 남겼다. 사람에게 주는 안내문이 아니라 호출 규약이라는 뜻이다.
20%는 이 워크로드의 숫자다. 다른 작업에 그대로 옮겨 붙지 않는다. 더 중요한 함의는 비용률이 아니라 비용 구조다. 도구를 바꾸는 일은 한 번의 마이그레이션이지만, 설명서를 업무에 맞추는 일은 작업 종류마다 다시 해야 하는 반복 작업이다. 이 비용을 누가 지는지 정해두지 않은 조직에서는 아무도 지지 않는다.
도구가 늘어날수록 이 문제는 커진다
나흘 뒤 반대 방향의 뉴스가 나왔다. 7월 14일 구글은 Microsoft, GitHub, Hugging Face, NVIDIA, Salesforce, Snowflake 등과 함께 Agentic Resource Discovery(ARD) 명세를 공개했다. 조직이 ai-catalog.json으로 자기 역량을 공개하면 레지스트리가 이를 모으고, 에이전트는 하드코딩된 연동 대신 작업 의도로 도구를 검색한다. MCP가 도구를 어떻게 호출할지를 정했다면 ARD는 그 앞 단계인 발견을 맡는다. GitHub의 Agent Finder와 Hugging Face의 Discover Tool이 이미 이 위에 있다.
7월 1일에는 VS Code의 Copilot 브라우저 도구가 정식 출시됐다. 에이전트가 실제 브라우저를 열어 클릭하고 입력하고 콘솔 오류를 읽는다.
에이전트가 손댈 수 있는 도구의 수는 계속 늘어난다. 그런데 GitHub 사례가 보여준 것은 도구가 늘어난다는 것이 곧 능력이 는다는 뜻은 아니라는 점이다. 쓸 수 있는 도구가 셋에서 서른이 되면, 언제 무엇을 쓰지 않을지 적어두는 일의 값이 같이 오른다. 발견을 자동화한 다음에 남는 질문은 선별이다.
교육과 AX 현장에서 반복해서 보는 것도 같다. 에이전트가 되는 팀과 안 되는 팀의 차이는 어떤 모델을 붙였는지가 아니라, 그 도구를 자기 업무의 순서로 다시 설명해 본 적이 있는지에서 나온다. 그 설명은 벤더가 대신 써주지 않는다. 자기 업무를 아는 사람만 쓸 수 있다.