무슨 일이 있었나요
오픈소스 프로젝트 Memdoor에 흥미로운 예제가 올라왔어요. 270억 파라미터(27B) 오픈 모델인 Qwen3.8-27B 다섯 개를 한 팀으로 묶어 코딩 문제를 풀게 했더니, 어려운 코딩 벤치마크인 LiveCodeBench Hard에서 Anthropic의 프런티어 모델 Fable 5보다 점수가 높았다고 해요. 레포의 examples/workflows/team-solve 경로에 워크플로가 공개돼 있어서 직접 들여다볼 수 있어요.
이게 왜 흥미롭냐면요, 지금까지 AI 업계에서는 '모델이 클수록 잘한다'가 거의 공식이었거든요. 이번 결과는 '혼자 똑똑한 한 명보다 적당히 똑똑한 다섯 명이 협업하는 게 나을 수도 있다'는 걸 보여줘요. 모델을 키우는 대신 답을 낼 때 계산을 더 써서(test-time compute) 성능을 올리는 흐름의 연장선이기도 하고요.
LiveCodeBench가 뭐냐면
LiveCodeBench는 LeetCode, AtCoder, Codeforces 같은 사이트에 새로 올라오는 문제를 계속 모아서 만드는 코딩 벤치마크예요. 핵심은 '시간'이에요. 오래된 벤치마크는 문제와 정답이 인터넷에 퍼져 있어서, 모델이 학습하면서 이미 답을 봤을 가능성(데이터 오염)이 있거든요. LiveCodeBench로는 모델이 학습된 시점 이후에 나온 문제로 평가할 수 있어서 '외운 실력'이 아니라 '푸는 실력'을 재기 좋아요. 그중 Hard는 경쟁 프로그래밍에서도 어려운 편에 드는 문제들이라 단순 구현으로는 안 되고 알고리즘 설계 능력이 있어야 해요.
팀으로 푼다는 건 어떻게 동작할까요
이런 멀티 에이전트 방식은 보통 몇 가지 패턴을 섞어 써요. 회사 개발팀을 떠올리면 이해하기 쉬워요.
- 역할 분담: 한 모델은 문제를 분석해서 접근법을 설계하고(설계자), 다른 모델은 코드를 짜고(개발자), 또 다른 모델은 엣지 케이스 테스트를 만들고(QA), 나머지는 코드를 검토해요(리뷰어).
- 여러 풀이 중 고르기: 모델마다 다른 풀이를 내고, 테스트를 통과하거나 여러 모델이 동의하는 풀이를 골라요.
- 피드백 루프: 테스트가 실패하면 그 로그를 공유해서 다시 고치게 해요. 혼자라면 같은 실수를 반복했을 텐데, 다른 관점을 가진 모델이 '여기서 오버플로 나요' 하고 짚어주는 거죠.
업계 맥락: 처음 나온 아이디어일까요?
사실 이 방향은 꾸준히 연구돼 왔어요. 딥마인드의 AlphaCode(2022)는 풀이를 엄청나게 많이 만든 다음 테스트로 걸러내는 방식으로 경쟁 프로그래밍에 도전했어요. 2024년 논문 More Agents Is All You Need는 같은 모델을 여러 번 돌려서 투표만 시켜도 성능이 오른다는 걸 보였고요. Together AI의 Mixture-of-Agents는 여러 모델의 답을 다음 단계 모델이 종합하는 구조를 제안했어요.
다만 냉정하게 봐야 할 부분도 있어요. 첫째, 비용 비교가 공정한지예요. 모델 다섯 개가 여러 라운드를 돌면 토큰 사용량이 한 번 호출할 때의 수십 배가 될 수도 있어요. 프런티어 모델에도 같은 예산을 주고 여러 번 샘플링하면 점수가 오를 수 있고요. 둘째, 응답 시간이에요. 협업 라운드가 길어지면 답이 나오는 데 몇 분씩 걸릴 수 있어서 IDE 자동완성 같은 실시간 용도에는 맞지 않아요. 셋째, 벤치마크와 실무는 달라요. 경쟁 프로그래밍은 정답과 테스트가 명확하지만, 실무 코드는 요구사항이 모호하고 레포 전체 맥락을 알아야 하잖아요.
한국 개발자에게 주는 시사점
제가 가장 의미 있다고 보는 건 외부 API를 못 쓰는 환경이에요. 금융, 공공, 의료처럼 망분리나 데이터 반출 규제 때문에 클라우드 LLM을 쓰기 어려운 곳이 한국에는 정말 많잖아요. 27B급 모델은 4비트로 양자화하면 24GB GPU 한 장에도 올라가요. 그리고 '모델 다섯 개'라고 해도 같은 모델에 역할 프롬프트만 다르게 준 것이라면, vLLM이나 SGLang 같은 서빙 엔진에 모델을 한 번만 올려두고 요청 다섯 개를 동시에 처리하면 돼요. 하드웨어 부담이 생각보다 크지 않은 거죠.
당장 해볼 만한 건 사내 코드 리뷰 봇이나 테스트 생성 파이프라인에 '작성자 모델 + 리뷰어 모델' 구조를 넣어보는 거예요. 모델 하나에게 다 맡길 때보다 결과가 안정적인지 직접 비교해보면 좋은 경험이 될 거예요.
마무리
한 줄 정리: 모델 크기 대신 협업 구조로 성능을 끌어올리는 방식이 오픈 모델 쪽에서 점점 현실적인 선택지가 되고 있어요.
같은 예산이라면 여러분은 프런티어 모델 한 번 호출과 오픈 모델 팀의 여러 라운드 중 어느 쪽을 고르시겠어요? 사내에서 멀티 에이전트를 써보신 분이 있다면 어떤 역할 구성이 효과가 좋았는지 공유해주세요.
🔗 출처: Hacker News