AI 코딩 에이전트 멀티모델 파이프라인 - 계획·구현·리뷰에 다른 모델을 쓰는 이유

핵심 메시지

• 발표자는 소프트웨어 엔지니어의 일이 '코드를 쓰는 것'에서 '코드를 쓰는 시스템을 설계하는 것'으로 옮겨가고 있다고 진단한다.
• 가장 비싼 모델에 모든 단계를 맡기는 방식은 활발히 쓰는 엔지니어 한 명당 월 2천 달러 수준의 API 비용으로 이어졌다는 것이 사내 측정치다.
• 계획 단계는 최고 성능 모델을 고정하고 구현 모델만 바꿔 본 실험에서, 오히려 값싼 모델이 더 나은 결과를 냈고 구현 비용은 약 80%, 계획과 구현을 합친 주기는 약 60% 줄었다.
• 리뷰 단계에서도 구현에 쓴 것과 같은 모델로 자기 작업을 검토하는 것은 회계 감사에 자기 회사를 부르는 격이라며, 서로 다른 모델을 섞은 리뷰 파이프라인이 정밀도와 재현율 모두에서 더 나았다고 밝혔다.
• 명세 주도 개발은 과하게 부풀리면 오히려 해가 된다. 문제를 지나치게 규정해 해법의 창의성을 묶고 토큰을 낭비하지만, 계획하고 구현하는 두 단계 구조 자체는 여전히 유효하다.

쉽게 이해하기

AI Dev 26 샌프란시스코 행사에서 젠코더의 앤드루 필레브가 사내 응용 연구 조직이 2년간 축적한 실험 결과를 공개했다. 주제는 하나의 모델에 모든 것을 맡기는 대신, 계획·구현·리뷰 단계마다 서로 다른 모델을 배치하는 멀티모델 파이프라인이다. 약 50명 규모의 자사 엔지니어링 팀이 먼저 실험 대상이 됐고, 이후 고객사로 확대됐다.

발표자는 먼저 관점을 정리한다. 예전에는 일의 결과물이 코드였다면, 지금은 코드를 만들어 내는 시스템을 짜는 쪽으로 무게중심이 옮겨갔다는 것이다. 그는 이것이 소프트웨어 산업에서 새로운 일이 아니라고 본다. 절차적 프로그래밍에서 객체지향으로, 단일 애플리케이션에서 마이크로서비스로 옮겨간 것처럼 추상화 수준이 한 단계 올라간 것뿐이며, 그만큼 시스템 설계 역량은 오히려 더 중요해진다는 설명이다.

비용 이야기는 현실적이다. 코딩 에이전트가 잘 작동한다는 것을 처음 체감한 사람들은 곧바로 최고 성능 모델에 모든 작업을 몰아주는 경향이 있는데, 사내 측정으로는 이런 사용 패턴에서 엔지니어 한 명이 월 2천 달러가량의 API 비용을 태웠다. 개인 구독 요금제를 쓰는 1인 개발자라면 몰라도, 토큰 단위로 비용을 지불하는 기업에서는 예산이 고정된 만큼 누군가의 몫에서 그 돈이 나온다는 지적이다.

실험 설계는 단순하다. 공개 벤치마크인 SWE-Bench Pro에서 가장 어려운 문제들을 고르고, 계획 담당 모델은 최고 성능 모델로 고정한 채 구현 담당 모델만 바꿔 가며 비교했다. 최고급 모델, 경쟁사 코딩 모델, 오픈소스 모델, 그리고 저가·고속 모델까지 붙여 봤는데, 예상과 달리 가장 저렴한 모델이 더 많은 이슈를 해결했다. 발표자의 해석은 두 가지다. 계획이 확실하면 '단순한 코딩'은 이미 대부분의 모델이 해내는 수준에 도달했다는 것, 그리고 계획과 구현에 서로 다른 모델을 쓰면 관점의 다양성이 더해진다는 것이다.

리뷰에도 같은 논리를 적용했다. 자기가 만든 결과물을 같은 모델로 검토하게 하는 것은 회계에서 자기 회사에 감사를 맡기는 것과 다르지 않다는 비유다. 여러 모델을 섞은 리뷰 파이프라인은 단일 고성능 모델 기반 리뷰보다 비용이 훨씬 낮으면서 정밀도와 재현율 모두 개선됐다는 것이 자체 데이터셋 기준 결과다. 다만 발표자는 100% AI 리뷰를 주장하지는 않는다. AI가 단순하고 반복적인 지적을 앞단에서 걸러 주면 사람은 더 어려운 판단에 집중할 수 있다는 쪽에 가깝다. 검증 단계에 대한 조언도 이어진다. 그는 검증을 LLM 판정에 맡기기보다 종단 간 테스트, 추적, 정적 분석 같은 결정론적인 전통 소프트웨어 공학 관행 쪽으로 최대한 옮기라고 권한다. LLM은 그 파이프라인을 조율하거나 결과를 루프에 되먹이는 역할로 쓰는 편이 낫다는 것이다. 평가(eval) 구축은 모델이 똑똑해질수록 어려워지지만, 규모가 큰 조직이라면 멀티 소싱과 멀티모델 전략은 선택이 아니라 필수라는 것이 결론이다.

주요 인사이트

• 비용 최적화와 품질 최적화가 반드시 상충하지는 않는다. 단계별로 모델을 나누면 더 싸고 더 빠르면서 결과도 더 나은 지점이 실제로 존재한다는 것이 이번 실험의 핵심 메시지다.
• 모델 다양성 자체가 성능 요인이 될 수 있다. 계획과 구현에 같은 모델을 쓰면 같은 사고방식이 반복되지만, 다른 모델을 넣으면 다른 관점이 더해진다는 해석이다.
• 명세 주도 개발의 가치는 문서의 두께가 아니라 검토 지점에 있다. 50개 파일에 흩어진 수정을 검토하는 것보다 짧은 계획서를 검토하는 편이 사람에게 훨씬 쉽다.
• '자기 채점'의 위험은 AI에도 적용된다. 리뷰 단계에 구현과 다른 모델을 세우는 것은 성능 문제이기 이전에 견제 구조의 문제다.
• 벤치마크는 빠르게 낡는다. 발표자는 기존 SWE-Bench가 사실상 풀렸고 과적합됐다고 보아 더 어려운 후속 벤치마크를 골랐는데, 그마저도 과적합에서 자유롭지 않다고 인정한다.

자주 묻는 질문

관련 AI 소식