(2/5) 모델 고르기 — 어떤 오픈웨이트가 코딩 에이전트급인가
- 왜, 그리고 무엇을 갖춰야 하나 — 3층 구조와 손익분기
- 모델 고르기 — 어떤 오픈웨이트가 코딩 에이전트급인가 ← 지금 글
- 하드웨어와 서빙 — GPU·VRAM·양자화·vLLM 로 띄우기
- 하네스 연결 — 로컬 모델을 에이전트 CLI 에 물리기
- "완벽히 동일"의 조건 — 검증·남는 갭·하이브리드 운영
Summary
지난 글에서 코딩 에이전트를 모델·서빙·하네스 3층으로 갈랐어요. 이번엔 그중 가장 중요한 모델을 고릅니다. 인프라를 아무리 잘 깔아도 모델이 코딩 에이전트급이 아니면 방향 자체가 달라지거든요.
그런데 여기서 흔한 함정이 있어요. “코드 잘 짜는 모델”과 “에이전트로 잘 굴러가는 모델”은 다른 능력이에요. 이 글에서는 그 둘을 가르는 기준을 세우고, 오픈웨이트 지형을 훑은 뒤, 하드웨어 예산에서 역산해 후보를 좁히는 법까지 갑니다.
💡 이 글에서 다루는 것
- “코드 완성”과 “에이전트”는 다른 능력 — 무엇을 벤치로 봐야 하나
- 판별 기준 셋: 에이전틱 벤치 · 툴 콜 안정성 · 긴 컨텍스트
- Dense vs MoE — 왜 이 구조가 서빙 비용을 좌우하나
- 오픈웨이트 지형: 대형 MoE / 중형 Dense / 소형 로컬
- 예산에서 역산해 고르는 실전 순서
⚠️ 모델 지형은 한 달 단위로 바뀌어요. 이 글은 특정 버전의 점수를 외우게 하려는 게 아니라, “무엇을 기준으로 볼지”를 잡는 데 목적이 있어요. 실제 선택 직전엔 최신 리더보드를 꼭 다시 확인하세요.
1. “코드 완성”과 “에이전트”는 다른 능력
예전엔 코딩 모델을 HumanEval 같은 함수 하나 완성 벤치로 줄 세웠어요. 그런데 코딩 에이전트가 하는 일은 그것과 결이 달라요.
- 저장소 전체를 탐색하고,
- 여러 파일에 걸쳐 수정하고,
- 테스트를 돌려 실패를 읽고 다시 고치는,
여러 턴에 걸친 문제 해결이에요. 그래서 요즘은 실제 깃허브 이슈를 자동으로 고치게 시키는 SWE-bench(특히 사람이 검수한 SWE-bench Verified)나, 여러 언어로 실제 수정을 시키는 Aider polyglot 같은 에이전틱 벤치를 봐요.
💡 실전 감별법: 후보 모델을 고를 때 “HumanEval 몇 점”이 아니라 “SWE-bench Verified 계열에서 어느 티어냐”를 먼저 보세요. 코드 완성만 잘하고 에이전트로는 헤매는 모델이 이 벤치에서 걸러집니다.
2. 판별 기준 세 가지
리더보드 숫자에 휘둘리지 않으려면, 저는 이 세 축으로 후보를 봅니다.
- ① 에이전틱 문제 해결력 — 위에서 말한 SWE-bench Verified 티어. 여러 턴을 버티며 실제 코드를 고쳐내는가.
- ② 툴 콜 안정성 — 모델이 “이 도구를 이런 인자로 불러줘”를 구조화된 형식(함수 호출)으로 정확히 뱉는가. 이게 흔들리면 하네스가 파일을 엉뚱하게 고치거나 루프가 깨져요. 벤치 점수는 좋은데 툴 콜 포맷이 자주 깨지는 모델은 에이전트용으로 탈락이에요.
- ③ 긴 컨텍스트 — 큰 저장소를 담으려면 넉넉한 토큰 창이 필요해요. 여기서 “광고된 최대 창”과 “실제로 쓸 만한 창”이 다르다는 걸 조심해야 해요. 128K 를 지원한다 해도 뒤쪽 절반에서 내용을 놓치는 모델이 흔하거든요. 3편에서 다루지만, 긴 창은 서빙 메모리(KV 캐시)도 크게 먹어서 하드웨어 비용과 직결돼요.
✅ 세 축 다 초록불이어야 “에이전트급”이에요. 하나라도 빨간불이면(특히 툴 콜) 아무리 벤치가 높아도 실사용에서 삐걱거립니다.
3. Dense vs MoE — 서빙 비용을 가르는 구조
모델을 고르기 전에 구조 하나는 알고 가야 해요. 요즘 강한 오픈웨이트는 대부분 MoE(Mixture of Experts) 예요.
- Dense(밀집) — 파라미터 전부가 매 토큰마다 계산에 참여해요. 32B 면 32B 를 다 굴려요. 구조가 단순하고 서빙이 예측 가능하지만, 지능을 키우려면 계산량이 통째로 늘어요.
- MoE(전문가 혼합) — 전체 파라미터는 크지만, 매 토큰엔 일부 전문가만 활성화돼요. 예를 들어 “전체 480B 인데 토큰당 35B 만 활성”인 식이죠. 총 파라미터(=지능 잠재력)와 활성 파라미터(=계산량)를 분리한 게 핵심이에요.
이게 왜 중요하냐면, 온프렘 비용의 두 축을 각각 다른 숫자가 결정하기 때문이에요.
| 무엇 | 무엇이 결정하나 |
|---|---|
| GPU 메모리(VRAM) | 총 파라미터 — 가중치를 다 올려둬야 함 |
| 계산 속도·전력 | 활성 파라미터 — 토큰당 실제 연산량 |
💡 그래서 큰 MoE 는 “메모리는 많이 먹지만, 그 지능치고는 빠른” 특성이 있어요. 총 480B 를 다 담을 VRAM 은 필요하지만, 토큰 생성 속도는 35B 급이라 큰 모델치고 반응이 경쾌하죠. 반대로 VRAM 이 부족한 환경에선 MoE 의 “총량”이 곧바로 벽이 돼요. 이 트레이드오프가 3편 하드웨어 계산의 뼈대예요.
4. 오픈웨이트 지형 — 세 덩어리로 보기
특정 버전명은 금방 바뀌니까, 덩어리(티어) 로 이해하는 게 오래 가요. 대략 이렇게 나뉩니다.
| 티어 | 성격 | 온프렘 현실 |
|---|---|---|
| 대형 MoE | 프런티어에 근접, 에이전트급 | 멀티 GPU 노드 필요 |
| 중형 Dense | 준수, 특정 언어 강함 | GPU 1~2장에 탑재 |
| 소형 로컬 | 보조·자동완성용 | 워크스테이션급 |
- 대형 MoE(프런티어 근접) — 총 수백 B~1T급 MoE 계열이 여기예요. 오픈웨이트 중에서 에이전틱 코딩 티어에 실제로 근접한 건 대체로 이 덩어리고, 상용을 “같은 방향”으로 대체하려면 결국 여기를 봐야 해요. 대신 뒤에서 볼 것처럼 멀티 GPU 노드가 필요합니다. 대표적으로 대형 코더 특화 MoE, 범용 대형 MoE(리즈닝 포함) 계열이 이 자리를 다투고 있어요.
- 중형 Dense(10~30B급) — GPU 한두 장에 올라가는 실용 구간이에요. 프런티어급까진 아니어도 특정 언어·정형 작업에선 충분히 쓸 만하고, 자동완성·리팩터 같은 좁은 태스크나 소규모 팀엔 가성비가 좋아요.
- 소형 로컬(1~9B급) — 노트북·워크스테이션에서 도는 구간. 에이전트 메인으로 쓰긴 벅차고, 인라인 자동완성이나 오프라인 보조용이에요.
⚠️ 여기서 이름을 콕 집어 “이게 정답”이라고 못 박지 않는 이유가 있어요. 이 지형은 분기마다 순위가 갈아엎어져요. 선택 직전에 최신
SWE-bench Verified/Aider polyglot/LiveCodeBench리더보드를 직접 확인하고, 후보 2~3개를 뽑아 본인 코드베이스로 파일럿을 돌리는 게 어떤 글의 추천보다 정확합니다.
5. 예산에서 역산해 고르는 실전 순서
모델을 먼저 정하고 하드웨어를 맞추는 것보다, 거꾸로 가는 게 현실적이에요. 대부분 예산이 먼저 정해져 있으니까요.
- GPU 예산·VRAM 총량을 먼저 고정 — “8×80GB 노드 하나” 처럼요. (계산은 3편)
- 그 VRAM 에 들어가는 최대 티어를 추림 — 양자화까지 고려해서 “이 메모리엔 이 크기까지” 가 나와요.
- 그 안에서 에이전틱 벤치 상위 2~3개 후보 선정 — 최신 리더보드 기준.
- 툴 콜·긴 컨텍스트로 2차 필터 — 벤치는 높은데 툴 콜이 불안한 후보 제거.
- 본인 코드베이스로 파일럿 — 실제 이슈 몇 개를 던져 성공률·속도·토큰 소모를 재봅니다. 여기서 순위가 리더보드와 뒤집히는 일이 흔해요.
✅ 정리하면 모델 선택은 “예산이 허용하는 VRAM → 그 안의 최대 티어 → 에이전틱 벤치 상위 → 툴 콜·컨텍스트 필터 → 자체 파일럿” 순서예요. 리더보드 1등을 무작정 쫓기보다, 내 하드웨어에 들어가면서 내 코드에서 잘 도는 모델이 정답입니다.
이렇게 후보를 좁혔으면, 이제 그 모델을 실제로 GPU 에 올릴 차례예요.
일단 오늘은 여기까지…..
다음 글에서는 VRAM 을 어떻게 계산하고, 양자화로 얼마나 줄이며, vLLM 으로 모델을 어떻게 띄우는지 — 하드웨어와 서빙을 정면으로 풀어볼게요.
← 이전 글: (1/5) Claude Code·Codex 를 온프렘으로 — 왜, 그리고 무엇을 갖춰야 하나 ｜ 다음 글 →: (3/5) 하드웨어와 서빙 — GPU·VRAM·양자화·vLLM 로 모델 띄우기
