[AI] 같은 요구사항, 다른 선택 — 코딩 에이전트 3종 도구 선택 실측 비교

“결제는 Stripe로 붙여줘"처럼 구체적으로 지시하지 않는 한, 코딩 에이전트가 어떤 서드파티 서비스를 스스로 고르는지는 순전히 에이전트 재량이다. dev tools 성장 서비스를 파는 Armature가 2026년 9월 3일 공개한 실측 연구는 이 재량이 에이전트마다 얼마나 다르게 작동하는지를 처음으로 대규모 데이터로 보여준다. Claude Code, Codex, Cursor 세 에이전트에게 똑같은 요구사항을 줘도, 같은 서드파티 서비스를 고른 세션은 절반에도 못 미쳤다.

방법론 — 16,893개 세션에서 5,292개를 추려낸 방법

Armature는 세 에이전트에게 75개 저장소(10개 프로그래밍 언어)를 대상으로 1,163가지 프롬프트 변형을 실행시켜 총 16,893개의 코딩 에이전트 세션을 수집했다. 이 중 실제로 서드파티 서비스 선택이 발생한 세션을 18개 섹터·51개 저장소 기준으로 검증해 5,292개를 분석 대상으로 좁혔다. 측정 대상은 결제·데이터베이스·파일 스토리지·이메일 등 프로덕션 애플리케이션이 흔히 필요로 하는 인프라 카테고리였고, 에이전트가 실제로 설치·연동한 서비스와 대화 중에 언급만 하고 지나간 서비스를 구분해 집계했다.

세 에이전트가 도구를 고르는 방식이 다르다

가장 먼저 눈에 띄는 수치는 일치율이다. 세 에이전트 모두 같은 서드파티 서비스를 선택한 세션은 42%에 불과했다 — 같은 요구사항을 줘도 절반 이상의 확률로 서로 다른 서비스가 코드베이스에 들어간다는 뜻이다. 이 차이는 우연이 아니라 각 에이전트의 검색·구현 성향이 구조적으로 다르기 때문에 생긴다.

웹 검색 활용률부터 갈린다. Codex는 거의 모든 세션(94%)에서 웹 검색을 사용하며, 도메인 특화 검색 연산자까지 활용하는 경향을 보였다. Cursor는 세션의 약 3분의 2(67%)에서 검색을 사용했다. 반면 Claude Code는 평균적으로 약 30%의 세션에서만 검색했지만, 새로운 기술 분야를 다루는 세션에서는 검색 비율이 80%까지 뛰었고 검색할 때는 경쟁 에이전트 대비 3배 많은 페이지를 열람하는 것으로 나타났다. 즉 Claude Code는 “필요할 때만 검색하되 깊게 판다"는 쪽에 가깝고, Codex는 “일단 검색부터 한다"는 쪽에 가깝다.

자체구현 비율도 갈렸다. 외부 서비스를 붙이는 대신 직접 코드를 작성해 문제를 해결한 비율이 Claude Code는 약 19%로, Codex·Cursor(각 약 10%)의 두 배 수준이었다. 검색을 적게 하는 성향과 자체구현 비율이 높은 성향이 같은 에이전트에서 함께 나타난다는 점은, 검색 빈도와 “외부 서비스에 의존하기보다 직접 짠다"는 판단이 서로 연결되어 있을 가능성을 시사한다.

카테고리별 승자 — 그리고 멘션과 선택의 괴리

카테고리별로 보면 결제·데이터베이스·이메일 각각에서 뚜렷한 1위 서비스가 존재했다.

카테고리	1위 서비스	점유율	2위
결제	Stripe	약 90%	Paddle / Mollie
데이터베이스	Neon	66%	클라우드 네이티브 옵션(각 사)
파일 스토리지	Amazon S3	45%	Azure Blob / GCS (각 약 20%)
이메일	Resend	35.6%	Postmark (27.4%)

흥미로운 부분은 대화 중 언급(mention) 횟수와 실제 선택(selection) 횟수의 괴리다. PayPal은 139회 언급됐지만 실제로 선택된 횟수는 0회였다. LangChain은 194회 언급됐지만 실제 채택은 4회에 그쳤다. Supabase는 242회 언급됐음에도 데이터베이스 카테고리 선택에서는 Neon에 밀렸다. 에이전트가 학습 데이터나 검색 결과에서 자주 접하는 이름과, 실제로 코드베이스에 심는 이름이 다르다는 뜻이다. 벤치마크나 언급 빈도만으로 “에이전트가 어떤 서비스를 선호한다"고 단정하면 실제 채택 패턴과 어긋날 수 있다.

언어별 편향 — 프로그래밍 언어가 서비스 선택까지 바꾼다

이메일 서비스 선택은 프로그래밍 언어에 따라서도 크게 갈렸다. TypeScript 프로젝트에서는 Resend가 89건 중 55건을 차지해 압도적이었고, Python 프로젝트에서는 SendGrid가 24건 중 22건, Go 프로젝트에서는 Postmark가 24건 중 20건, Java 프로젝트에서는 Azure 계열 서비스가 23건 중 22건을 차지했다. 각 언어 생태계의 공식 문서·튜토리얼·커뮤니티 예제가 특정 서비스의 SDK를 표준처럼 다루는 관행이, 에이전트의 학습 데이터와 검색 결과에 그대로 반영된 결과로 해석할 수 있다. 즉 에이전트가 “가장 좋은 서비스"를 고르는 것이 아니라 “그 언어 생태계에서 가장 많이 보이는 서비스"를 고르는 경향이 있다는 뜻이다.

왜 이 연구가 중요한가

에이전트의 코드 품질이나 벤치마크 점수를 측정한 연구는 많지만, “에이전트가 실제 프로덕션 인프라를 어떻게 고르는가"라는 실사용 행동을 대규모로 측정한 자료는 드물다. 이 연구가 보여주는 42%라는 일치율은, 같은 팀이 Claude Code로 만든 서비스와 Codex로 만든 서비스가 결제·DB·스토리지 벤더부터 갈릴 수 있다는 뜻이다. 여러 에이전트를 병행 운영하는 팀이라면 벤더 표준화 정책이나 “이 서비스만 쓰라"는 명시적 가드레일 없이는, 프로젝트마다 인프라 스택이 제각각 흩어질 위험이 실제로 존재한다.

또한 멘션과 선택의 괴리, 언어별 편향 데이터는 에이전트가 서드파티 서비스를 고르는 기준이 “성능이나 적합도"보다 “학습 데이터·검색 결과에서의 노출 빈도"에 더 가깝다는 점을 시사한다. 특정 서비스를 프로젝트 표준으로 강제하고 싶다면, 에이전트의 자율 판단에 맡기기보다 프로젝트 설정 파일이나 시스템 프롬프트에 명시적으로 지정하는 편이 안전하다는 실무적 결론으로 이어진다.

한계와 주의점

이 결과를 일반화하기 전에 짚을 점도 있다. 첫째, 측정 시점의 각 에이전트 버전·모델에 한정된 스냅샷이다. 에이전트의 기본 모델이나 시스템 프롬프트가 바뀌면 검색 빈도·자체구현 비율 같은 성향도 함께 달라질 수 있다. 둘째, 75개 저장소·10개 언어라는 표본이 실제 산업 전반의 언어·프레임워크 분포를 얼마나 대표하는지는 별도로 검증되지 않았다. 셋째, Armature 자신이 dev tools 성장 서비스를 판매하는 회사라는 점에서, 방법론과 원자료 공개 여부를 함께 확인하고 수치를 해석하는 편이 안전하다.