실제 코드 앞에서는 통하지 않는 벤치마크 승리
Kimi, GLM, DeepSeek, Qwen 등의 오픈 모델은 인상적인 벤치마크 점수를 자주 기록하며, 때로는 Anthropic의 Claude Opus나 OpenAI의 Project Project Astra 같은 프론티어 모델과 대등하거나 이를 능가하기도 합니다. 그러나 이러한 성과는 맥락에 따라 달라지는 경우가 많으며, 소프트웨어 개발 전체가 아니라 특정한 독립형 코딩 과제에서의 성능을 반영합니다.
핵심적인 차이는 작업의 복잡성과 지속 시간에 있습니다. 오픈 모델은 강력한 추론을 독립된 문제에 적용할 수 있는 짧고 개별적인 작업에서 뛰어납니다. 따라서 많은 업무 자동화와 개별 워크플로 단계에 매우 효과적입니다.
반면 실제 소프트웨어 엔지니어링에서는 에이전트가 수많은 도구 호출과 반복적인 개선 과정에서 맥락을 유지하고, 변화하는 지시를 따르며, 아키텍처 결정을 보존하는 능력이 필요합니다. 오픈 모델이 현재 부족한 부분이 바로 이러한 장기적 일관성입니다.
벤치마크는 유용한 신호를 제공하지만 엔드투엔드 코딩 능력을 완전히 보여 주지는 못합니다. SWE-bench 같은 자료는 모델의 소프트웨어 엔지니어링 역량을 더 포괄적으로 평가하며, 개별 작업 성능과 지속적인 프로젝트 작업 사이의 격차를 보여 줍니다.
오픈 모델이 실제로 제값을 하는 곳
그래도 오픈 모델은 더 한정된 맥락에서는 제값을 합니다. Medin의 실무 경험에 따르면, 함수 초안 작성, 스키마 변환, 단위 테스트 생성처럼 특정하고 독립적인 작업에서는 이들 모델이 프론티어 모델에 견줄 만한 품질을 제공할 수 있습니다. 이러한 대등함은 업무 자동화 내의 많은 일상적인 단계에도 적용됩니다.
기업들은 비용을 통제하고 데이터 프라이버시를 유지하기 위해 오픈 모델을 로컬에서 실행하거나 비용 효율적인 API를 통해 활용하는 경우가 많습니다. 다음과 같은 작업에는 Project Project Astra나 Claude Opus 5.5 같은 최상위 모델이 항상 필요한 것은 아닙니다.
- 데이터 검증
- 간단한 콘텐츠 생성
- 내부 API 라우팅 로직
중요한 점은 비용이 단순한 토큰당 비교로 결정되지 않는다는 것입니다. 성공적인 결과의 실제 비용에는 신뢰성, 재시도 빈도, 리뷰에 필요한 사람의 노력, 실패한 변경이 초래할 수 있는 비용이 포함됩니다. 오픈 모델은 토큰 수만 보면 더 저렴해 보일 수 있지만, 복잡한 장기 작업에서의 맥락 한계 때문에 반복과 수정이 늘어나 전체 비용이 더 높아질 수 있습니다. 이러한 미묘한 차이는 효과적인 자원 배분에 매우 중요합니다.
장기 실행 실패: 드리프트, 재시도, 사라진 규칙
코딩 워크플로의 범위가 넓어지면 오픈 모델은 크게 흔들립니다. Medin은 이들 모델이 저장소 규칙을 자주 놓치고, 이미 정해진 제약 조건을 무시하며, 비용이 많이 드는 리뷰와 수정 순환에 빠진다고 관찰합니다. 이러한 "장기 실행 실패(long-run failure)"는 점점 늘어나는 규칙과 맥락에 계속 주의(attention)를 유지하지 못하는 데서 비롯됩니다.
이를 수치로 확인하기 위해 Medin은 Northstar 게임을 만드는 통제된 실험을 진행했습니다. 그는 Claude, OpenAI, Kimi 세 모델에 12개의 기능 티켓을 할당했습니다. Claude는 12개 티켓을 모두 약 14시간 만에 완료했습니다. OpenAI는 11개 티켓을 완료했지만 약 28시간이 걸렸습니다. 반면 Kimi는 44시간 동안 5개 티켓만 처리했습니다.
이 비교는 한 크리에이터의 테스트이며 범용 리더보드는 아니지만, 지시 준수 여부와 반복 작업의 오버헤드가 프로젝트 결과를 좌우할 수 있음을 분명하게 보여 줍니다. 오픈 모델은 토큰당 가격이 낮더라도 수정과 재시도에 토큰을 반복적으로 소비하기 때문에 전체 비용이 더 높아지는 경우가 많습니다. 벤치마크 방법론을 더 살펴보려면 SWE-bench Official Benchmark and Leaderboard를 참고하십시오.
이러한 성능 격차는 모델이 장기 작업(long-horizon tasks)을 다루는 방식에 근본적인 차이가 있음을 시사합니다. 오픈 모델은 개별 코드 생성에서는 뛰어날 수 있지만, 모델이 변화하는 제약 조건과 설계 원칙을 지키면서 대규모 코드베이스 전반에 걸쳐 변경 사항을 통합해야 하는 복잡한 소프트웨어 개발에 필요한 지속적인 맥락 인식에서는 어려움을 겪습니다.
이 글이 마음에 드셨나요? 매일 아침 이런 글을 메일로 받아보세요.
하루 한 통 · 두 번의 클릭으로 구독 취소 · 제3자 추적 없음
모든 것을 걸기보다 하이브리드 워크플로가 낫습니다
전부 아니면 전무식의 선택 대신 하이브리드 워크플로를 쓰면 즉시 활용할 수 있습니다. 함수 초안 작성이나 스키마 변환처럼 범위가 명확한 개별 작업은 오픈 모델에 맡겨 비용 효율과 한정된 문제에서의 경쟁력 있는 성능을 활용하십시오. Claude Opus와 같은 프론티어 시스템은 복잡한 아키텍처 계획, 중요도가 높은 리뷰, 대규모 코드베이스에 걸친 변경에 사용하십시오.
하니스(harness)를 명확하고 견고하게 유지하십시오. 작업을 더 작은 티켓으로 나누고, 자동화된 테스트와 린팅으로 코딩 규칙을 강제하며, 핵심 지표를 지속적으로 측정하십시오. 완료율, 재시도 횟수, 리뷰 실패 횟수, 병합된 변경당 비용을 추적하여 모델의 성능과 효율을 객관적으로 평가하십시오.
오픈 모델은 이미 실용적이지만, 벤치마크 수준이 같다고 해서 소프트웨어 개발 전체를 맡길 수 있다는 보장은 없습니다. 팀은 자체 워크플로에 맞춰 모델을 꼼꼼히 테스트하고, 신뢰성이 입증됨에 따라 책임을 점차 옮겨야 합니다. 이러한 실용적이고 데이터에 기반한 접근 방식은 장기 작업에서의 드리프트와 일관되지 않은 실행의 위험을 줄이면서 오픈소스 혁신을 전략적으로 통합할 수 있게 해 줍니다.
자주 묻는 질문
오픈 모델은 코딩 벤치마크에서 높은 점수를 받으면서도 실제 프로젝트에서는 어려움을 겪는 이유는 무엇입니까?
벤치마크는 범위가 한정된 작업을 테스트하는 경우가 많지만, 실제 프로젝트에서는 에이전트가 규칙을 따르고, 맥락을 유지하며, 여러 단계에 걸쳐 일관된 결정을 내려야 합니다.
오픈 웨이트 모델은 AI 코딩에 유용합니까?
네. 특히 작업 범위가 명확하게 정해져 있다면, 개별적이고 짧은 작업과 일상적인 워크플로 단계에서 좋은 성능을 낼 수 있습니다.
장기 코딩 작업(long-horizon coding task)이란 무엇입니까?
계획 수립, 파일 편집, 테스트 실행, 리뷰 대응, 코드베이스 전반의 일관성 유지처럼 여러 단계에 걸쳐 이어지는 작업입니다.
팀은 모든 작업을 오픈 모델에 의존하지 않으면서 어떻게 활용할 수 있습니까?
명확하게 정의된 저위험 작업에는 오픈 모델을 사용하고, 복잡한 계획 수립, 리뷰, 지속적인 맥락이 필요한 작업에는 프론티어 모델을 사용하십시오.