Coding Agents Play Favorites With Your Dependencies
Deep into a coding session, you realize you want beta testers to try some new functionality first....
개요 #
한창 코딩에 몰입하다가 새 기능을 베타 테스터에게 먼저 열어주고 싶어졌다. 에이전트에게 기능 플래그(feature flag)를 붙여 달라고 요청하니, LaunchDarkly의 실험 솔루션과 그럴듯한 구현 계획을 내놓는다. 마크다운 문서를 대충 훑어보고 "괜찮아 보이네" 하며 수락하면, 에이전트는 곧바로 코드를 쓰기 시작한다.
이건 충분히 현실적인 장면이다. Claude, ChatGPT, Gemini 모두 LaunchDarkly를 추천하기 때문이다. 문제는 그 대답이 단 한 번 질문받은 단일 모델에서 나온다는 점이다. 여느 프롬프트와 똑같이 학습 편향과 비결정성에 휘둘린다. 저자가 직접 조사해 보니, 도구 추천 결과는 생각보다 크게 갈렸다.
의존성은 어떻게 정해지는가 #
업계가 인정하는 1위 도구든 아니든, 모델이 편애하는 도구는 늘 같은 자신감을 두르고 등장한다. 당신은 그 계획을 똑같이 가볍게 읽고, 똑같이 "괜찮아 보인다"고 반응한다.
그런데 이건 의존성을 정하는 결정이다. 그리고 그 결정 대부분을 에이전트에게 떠넘긴 셈이다.
어떻게 보면 자연스러운 흐름이다. 앱을 설계하고 코드를 짜라고 그 에이전트를 신뢰했으니, 나머지 판단도 믿고 맡길 만하다. 게다가 에이전트가 쓴 코드는 검토하고 다른 방식을 제안할 수도 있다. 다만 요즘은 구현 문서를 훑듯이 코드도 대충 훑고 넘기는 엔지니어가 점점 늘고 있다.
실제로 AI Engineer World's Fair에는 코드 리뷰가 죽었다고 선언하거나, 아예 없애겠다는 의지를 밝히는 세션이 여럿 있다. 사람 손을 거치는 리뷰가 병목이 되면서, 엔지니어들은 믿고 맡길 만한 자동 리뷰 방식을 찾는 중이다. Erik Meijer가 기조연설에서 시사할 법한, 수학적 증명 수준의 견고한 접근을 요구하는 조직도 많을 것이다.
의존성 상당수는 코드베이스 바깥에서도 생명을 이어간다. 어떤 리뷰 절차로도 완전히 들여다볼 수 없는 영역이다. 대략 2년 전, 이 시대가 열리기 전까지만 해도 의존성은 학술적 엄밀함으로 채택되지는 않았다. 하지만 대개 여러 사람의 눈을 거쳤고, 결정에 걸리는 시간도 지금보다 훨씬 길었다.
2024년 이전에는 새 도구를 찾을 때 웹 검색이나 동료와의 채팅에서 출발했다. 대안을 조사하고, 유지보수 상태를 살피고, 오픈소스 라이선스를 꼼꼼히 따졌다. RFC를 쓰거나 최소한 팀원의 직관적 판단이라도 구했다. 프로젝트에 새 도구를 들이는 데는 이런 대화와 데이터 수집이 깔려 있었다.
AI 에이전트가 코드 대부분을 짜는 지금도, 자동화 수준이 낮고 잘 조사된 의사결정 방식을 고수하는 엔지니어나 팀이 있을 수 있다. 그러나 요즘 도구들은 그런 방식을 권하지 않는다. 사실상 굳어진 흐름은 앞서 본 기능 플래그 이야기 그대로다. 에이전트에게 묻고, 추천을 받고, 곧장 빌드를 시작한다.
최상위 모델들은 개발 도구를 어떻게 줄 세우나 #
더 많은 엔지니어가 리서치를 에이전트에 맡기면서, 저자는 어떤 도구가 추천되는지 카테고리별로 추적해 왔다. 애플리케이션 데이터베이스, 매니지드 호스팅, 그리고 LaunchDarkly 같은 실험 플랫폼이 그 대상이다. 같은 프롬프트 묶음을 최상위 모델들에 여러 번 돌리고, 그 결과를 매달 llmrank.fyi에 공개한다.
Photo by Godfrey Atima on Pexels
각 카테고리 순위는 최신 Claude, ChatGPT, Gemini 모델의 결과를 평균 낸 값이다. LaunchDarkly가 실험 플랫폼 리더보드 1위를 석 달째 지키고 있지만, 2위와 3위는 매번 달랐다. 모델별로 뜯어보면 편차는 더 커진다. 최근 데이터에서는 Gemini와 Claude 둘 다 Split.io를 LaunchDarkly에 이어 2위로 꼽았지만, ChatGPT는 아예 목록에 올리지도 않았다. 기능 플래그 후보를 여러 개 물었다면, 어느 모델을 쓰느냐에 따라 전혀 다른 답을 받았을 것이다.
모델 간 이런 불일치는 곳곳에서 나타난다. 재미있는 사례 하나. "개발자 친화적인 AWS 경쟁 제품"을 물었더니 ChatGPT는 응답의 100%에서 Azure를 내놨다. 반면 Gemini는 어떤 답에도 Azure를 넣지 않았다. 온갖 음모론이 나올 만하다.
이런 불일치가 의미심장한 건, 흔히 말하는 AI 노이즈로 치부할 수 없기 때문이다. 저자가 쓴 방법론은 엔지니어가 에이전트에게서 한 번 받는 단발성 답이 아니라, 추천의 분포를 담아낸다. 약 5만 건의 짝 비교(pairwise) 실행을 근거로 보면, 세 모델이 (순서와 무관하게) 상위 3개 묶음을 공유한 경우는 약 58%였다. 바꿔 말하면, 최소한 하나는 다른 답을 내놓는 경우가 서로 일치하는 경우와 별 차이가 없다는 뜻이다.
이 불일치가 실제로 뜻하는 것 #
엔지니어는 비결정적 출력에 익숙하다. 코드 리뷰 두 번이 조금씩 다른 답을 줄 수 있고, 같은 모델 안에서도 그 정도 편차는 예상 범위다. 의존성 추천은 조금 더 교묘하다. 권위 있는 계획서를 앞세워 등장하는 데다, 한 모델 안에서는 놀라울 만큼 일관적이다.
Gemini는 97%의 확률로 같은 최상위 추천을 내놓는다. ChatGPT와 Claude도 1%포인트 안쪽이다. 각 모델은 자기 자신과는 잘 맞지만, 서로와는 자주 어긋난다. 최소한 결정을 확정하기 전에 다른 모델의 의견 한 번쯤은 들어볼 만하다.
Menlo Ventures가 2025년 4분기에 낸 보고서에 따르면 Claude는 엔터프라이즈 AI 시장의 약 54%를 차지한다. 그런데 이 Claude가 가장 자주 튀는 아웃라이어이기도 하다. 나머지 둘과 다른 상위 3개를 내놓을 확률이 가장 높은 모델이다. 방금 에이전트가 자신 있게 추천한 도구가, 두 번째 의견이라면 뒤집었을 선택일 수 있다는 얘기다.
모델이 추천한 의존성을 채택하는 비용은 대개 버튼 클릭 한 번이다. 하지만 나중에 후회하는 의존성을 걷어내는 일은 훨씬 고되다. 모델에게 사과시키고 실수를 함께 고치게 하더라도 마찬가지다. 이미 그 도구가 제공하는 기능에 의존하게 된 다른 시스템이 있을 수 있고, 그것들까지 손봐야 한다. 두 번째 의견이었다면 다른 곳을 가리켰을 42%의 경우가 바로 여기에 걸린다.
AI Engineer World's Fair의 여러 세션은 모델 그 너머를 겨눈다. 하네스 엔지니어링, 컨텍스트 최적화, 소프트웨어 팩토리는 모두 워크플로를 개선하고 더 예측 가능한 결과를 만드는 이야기다. 의존성은 모델 간 불일치가 선명하게 드러나는 한 지점일 뿐, 아마 유일한 지점은 아닐 것이다. 이런 틈을 찾아내 새로운 엔지니어링 규율로 메우는 일이 남았다.
모든 팀이 멀티 모델 방식을 택하지는 않을 것이다. 대부분의 의존성 결정은 여전히 기본 경로에서 이뤄진다. 그리고 그곳이 바로 개발자 도구 회사가 노출되느냐 마느냐가 갈리는 자리다. 제품이나 마케팅 팀과 일한다면, 이 데이터는 그들이 아직 존재조차 모르는 빈틈일 가능성이 크다.
그 기능 플래그 결정, 그리고 그와 비슷한 수천 건의 결정은 당신이 신경 쓰든 안 쓰든 어디선가 내려진다. 42%라는 불일치 수치는 모델이 수렴하거나 벌어지고 시장이 함께 움직이면서 바뀔 것이다. 변하지 않는 건, 결정이 결국 어딘가에 안착한다는 사실이다. 그 어딘가는 당신의 에이전트인가, 단일 모델인가, 서브 에이전트인가, 모델 라우팅 알고리즘인가, 아니면 루프 안의 사람인가? AI Engineer World's Fair에서는 이 모두가 저마다 주장되고 있다. 그래도 가장 좋은 신호는, 우리가 이 문제를 이야기하기 시작했다는 것이다.
이 글은 위 출처를 바탕으로 한국 독자를 위해 재작성한 기사입니다. 원문의 사실과 수치에 근거하며, 별도의 견해를 포함하지 않습니다.