깃허브 코파일럿 CLI, '러버덕' 출시: 클로드와 GPT-5.4 교차 검증

개발자가 코딩 도중 벽에 부딪힐 때 책상 위 고무오리를 붙잡고 혼잣말을 하며 해법을 찾는 기법이 있습니다. 하지만 코딩 에이전트가 스스로 작성한 코드를 혼자 검토하게 두면, 같은 훈련 데이터에서 비롯된 맹점까지 그대로 답습하는 한계가 있었습니다.

GitHub는 4월 6일 Copilot CLI에 실험 모드로 새 에이전트인 Rubber Duck을 선보였습니다. 같은 모델 안에서 자아성찰을 반복시키는 대신, 서로 다른 AI 모델 가문을 교차 배치해 상호 검증을 맡기는 방식을 채택했습니다.

클로드의 계획을 GPT가 뜯어고친다

현재 코딩 에이전트들은 작업 분석, 계획 수립, 구현, 테스트라는 정형화된 루프를 따릅니다. 여기서 가장 치명적인 문제는 초기 계획 단계의 오류입니다. 초반 가정이 잘못되면 뒤이어 작성되는 수많은 코드가 고스란히 기술 부채로 쌓이기 때문입니다.

자체 피드백 메커니즘을 돌려도 동일한 편향을 벗어나기 어렵습니다. GitHub는 주 오케스트레이터로 Anthropic의 Claude 모델군을 선택했을 때, Rubber Duck 검토관으로 OpenAI의 GPT-5.4를 붙여 두 번째 시각을 제공하도록 설계했습니다.

고난도 실제 오픈소스 저장소 과제를 다루는 SWE-Bench Pro 벤치마크 결과, Claude Sonnet 4.6에 GPT-5.4 기반 Rubber Duck을 결합하자 Sonnet과 상위 모델인 Opus 4.6 간 성능 격차의 74.7%를 메운 것으로 나타났습니다.

특히 3개 이상의 파일을 건드리고 70단계 이상 소요되는 복잡한 작업에서 효과가 두드러졌습니다. 해당 작업군에서 Sonnet 단독 대비 3.8% 높은 해결률을 기록했고, 세 차례 평가에서 가장 까다롭다고 판정된 과제들에서는 4.8% 더 높은 성적을 거뒀습니다.

실제 버그 차단 사례도 명확합니다. OpenLibrary 프로젝트에서는 스케줄러가 작업 없이 즉시 종료되는 구조적 결함과 특정 작업의 무한 루프를 짚어냈습니다. Solr 검색 모듈에서는 딕셔너리 키를 덮어써 검색 패싯 4개 중 3개가 오류 없이 누락되던 버그를 잡아냈고, NodeBB에서는 Redis 키 쓰기를 중단하면서 다른 3개 파일의 읽기 로직이 배포 직후 깨질 뻔한 충돌을 사전에 발견했습니다.

고무오리는 언제 개입하나

모든 과정마다 모델을 두 개씩 호출하면 속도와 비용을 감당하기 어렵습니다. GitHub는 피드백 효용이 가장 높은 특정 체크포인트에만 Rubber Duck을 호출하도록 제한했습니다.

첫 번째 시점은 초기 계획을 작성한 직후입니다. 설계 결함을 초기에 차단해 하류 작업의 연쇄 실패를 막는 것이 목표입니다.

두 번째는 복잡한 구현을 마친 직후로, 놓치기 쉬운 엣지 케이스를 점검합니다.

세 번째는 테스트 코드를 작성한 뒤 실제 실행에 들어가기 직전입니다. 테스트의 단언문 자체에 오류가 있어 모든 테스트가 통과했다고 착각하는 자기강화 오류를 걸러냅니다.

에이전트가 실행 루프에 갇혔을 때도 구원투수로 투입되며, 사용자가 필요할 때 직접 호출할 수도 있습니다. Copilot CLI에서 /experimental 명령어를 입력하고 Claude 모델과 GPT-5.4 접근 권한이 활성화되어 있으면 즉시 이용 가능합니다.

왜 중요한가

사용자 관점에서 이 기능은 비교적 저렴한 비용으로 최상위 플래그십 수준의 성능을 뽑아낼 수 있는 실속 있는 선택지입니다. 고가의 Opus 모델을 계속 띄워두지 않더라도, 주 작업은 가벼운 Sonnet에 맡기고 핵심 관문에서만 GPT-5.4의 검토를 받으면 안정적인 결과물을 얻을 수 있습니다. 여러 파일이 얽힌 리팩터링이나 사일런트 버그가 치명적인 작업에 당장 투입해볼 만합니다.

산업 전반으로 보면 단일 모델의 벤치마크 점수 경쟁에서 벗어나 모델 가문 간 교차 협업이라는 새로운 실용 경로를 열었습니다. 모델마다 학습 방식과 정렬 철학이 달라 결함의 유형도 제각각인데, 서로 다른 계열을 맞물려 상호 보완하는 편이 단일 초대형 모델을 쓰는 것보다 효율적이라는 점을 수치로 증명했습니다. Cursor나 Windsurf 같은 경쟁 개발 도구들도 이와 유사한 멀티 모델 파이프라인을 도입해야 하는 압박을 받게 될 것입니다.

GitHub의 접근 방식은 비용과 지연 시간을 고려해 세 군데 중요 지점에만 선별적으로 개입하도록 절제했다는 점에서 영리해 보입니다. 다만 두 개의 상용 API를 번갈아 거치면서 발생하는 응답 지연과, 두 프론티어 모델이 아키텍처 설계를 두고 상충하는 피드백을 내놓았을 때 이를 조율하는 판단 로직은 향후 실무 검증을 통해 지켜볼 대목입니다.