RTX 3090 2대로 온프레미스 Vibe Coding하기: Qwen3-Coder vs Gemma 4 실전 비교

 

RTX 3090 2대로 온프레미스 Vibe Coding하기: Qwen3-Coder vs Gemma 4 실전 비교

개요

항목 내용

환경	RTX 3090 × 2 (VRAM 총 48GB)
목적	온프레미스 LLM 기반 Vibe Coding
비교 모델	Qwen3-Coder-30B-A3B vs Gemma 4 31B
핵심 질문	48GB VRAM 환경에서 에이전트형 코딩 작업에 어떤 모델이 더 유리한가?
결론 요약	Qwen3-Coder 계열 우세 (에이전틱 워크플로우 기준)

---

클라우드 API 의존 없이 내 GPU 위에서 코딩 에이전트를 돌리는 시대가 왔다. RTX 3090 두 장, 즉 48GB VRAM이라는 자원을 손에 쥐고 있다면 어떤 모델을 선택해야 할까? 이 글은 그 질문에 대한 실용적 판단 기준을 정리한다.

---

1. 왜 RTX 3090 2대인가 — 자원의 의미 파악

RTX 3090 한 장은 VRAM 24GB다. 두 장이면 합산 48GB. 이 숫자가 중요한 이유는 모델 사이즈와 양자화 전략의 조합 가능성을 결정하기 때문이다.

실용적으로 정리하면 다음과 같다. 30B급 MoE 모델을 Q5 이상의 품질로 올리거나, 72B급 Dense 모델을 Q4로 풀 로딩하거나, 두 가지 경로 모두 가능한 구간이 바로 48GB다. 즉, 양자화 품질을 희생하지 않아도 되는 임계점에 닿아 있다는 뜻이다. 이 점이 이번 비교에서 중요한 배경이 된다.

---

2. 모델 비교: Qwen3-Coder vs Gemma 4

2-1. 벤치마크 성능 비교

평가 항목 Qwen3-Coder-30B-A3B Gemma 4 31B

SWE-bench Verified	50.3%	미공개
Terminal-Bench 2	우위	열세
TAU2 (멀티스텝 에이전트)	우위	열세
LiveCodeBench	상위권	86.6% (단일 우세)
도구 호출 안정성	강함	상대적 약함
양자화 내성	quant 시 성능 저하 있음	quant에 안정적

Gemma 4가 LiveCodeBench 단일 항목에서 높은 수치를 보이는 것은 사실이지만, 이 벤치마크는 독립적인 알고리즘 문제 풀이에 특화되어 있다. Vibe Coding에서 실제로 필요한 것은 파일 탐색, 코드 편집, 도구 호출, 멀티턴 추론의 연쇄, 즉 에이전트형 루프다. 이 맥락에서 SWE-bench와 TAU2의 수치가 훨씬 의미 있는 지표가 된다.

2-2. 48GB 환경에서의 실질적 차이

양자화 안정성에서 Gemma 4가 유리하다는 것은 Q4_K_M 수준의 저비트 양자화를 전제로 한 비교다. RTX 3090 두 장 환경에서는 Qwen3-Coder-30B-A3B를 Q5 또는 Q6로 구동할 수 있으므로, 이 단점이 사실상 상쇄된다. 상위 양자화일수록 Qwen3-Coder의 에이전트 성능 저하는 최소화되고, Gemma 4와의 양자화 안정성 격차는 줄어든다.

추론 속도 면에서도 Qwen3-Coder-30B-A3B는 MoE(Mixture of Experts) 구조 덕분에 활성 파라미터가 실제로는 3B 수준이다. 이는 RTX 3090 환경에서도 실용적인 토큰/초를 확보할 수 있음을 의미하며, 에이전트 루프처럼 반복 추론이 잦은 작업에서 체감 속도 차이를 만든다.

---

3. Vibe Coding이란 무엇인가 — 그리고 왜 모델 선택에 영향을 주는가

Vibe Coding은 자연어 명세를 전달하면 에이전트가 파일을 읽고, 코드를 수정하고, 테스트를 실행하고, 결과를 다시 추론에 반영하는 방식의 개발 패러다임이다. 단발 코드 생성과는 본질적으로 다르다.

이 작업 방식에서 병목은 단일 답변의 정확도가 아니라, 멀티스텝 루프 전반의 일관성과 도구 호출 신뢰성이다. 파일 경로를 잘못 참조하거나, 도구 호출 포맷이 불안정하거나, 중간 단계에서 컨텍스트를 잃으면 전체 파이프라인이 무너진다. Qwen3-Coder가 SWE-bench와 TAU2에서 강한 이유가 바로 이 지점이다.

Gemma 4는 단발 완성도와 양자화 내성 면에서 장점이 있다. 만약 한 번의 호출 품질이 핵심인 서비스형 추론(inference-as-a-service) 환경이라면 Gemma 4도 충분히 유효한 선택이다. 그러나 지금 논의하는 컨텍스트, 즉 반복적 에이전트 루프 기반의 Vibe Coding에는 Qwen3-Coder가 더 적합하다.

---

4. 권장 세팅

4-1. 하드웨어 구성

두 장의 RTX 3090이 동일 모델(non-Ti 포함)인 경우 NVLink 브리지를 통한 텐서 병렬(tensor parallel) 구성을 권장한다. NVLink 없이 PCIe 기반으로 연결해도 동작하지만 대역폭 병목이 발생할 수 있으며, 특히 KV 캐시 공유 시 성능 차이가 생긴다.

4-2. 모델 및 양자화 선택

시나리오 권장 모델 양자화

에이전트형 Vibe Coding (기본 권장)	Qwen3-Coder-30B-A3B	Q5_K_M 이상
단일 호출 품질 우선, 안정성 중시	Gemma 4 31B	Q4_K_M
최대 품질, 대기 시간 감내 가능	Qwen2.5-72B	Q4 풀 로딩

4-3. 서빙 스택

vLLM 또는 llama.cpp + tensor parallel 조합이 현재 가장 안정적이다. OpenAI 호환 엔드포인트를 활성화하면 Cline, Continue.dev, Aider 같은 에이전트 도구와 별도의 어댑터 없이 연결된다.

# vLLM 예시 (tensor_parallel_size=2)
vllm serve Qwen/Qwen3-Coder-30B-A3B-GGUF \
  --tensor-parallel-size 2 \
  --quantization gguf \
  --dtype auto

---

5. 솔직한 한계

Qwen3-Coder의 MoE 구조는 활성 파라미터가 적어 속도에 유리하지만, 전체 파라미터를 VRAM에 올려야 하는 것은 동일하다. 30B-A3B 기준으로 Q5_K_M에서 약 22~24GB가 필요하므로 두 카드 분산 시 여유가 있지만, 더 높은 양자화나 긴 컨텍스트를 동시에 처리할 경우 메모리 한계에 부딪힐 수 있다.

또한 Qwen3-Coder 계열의 양자화 성능 저하 이슈는 Q4 이하 수준에서 실제로 관측된 현상이다. 48GB 환경에서 Q5 이상을 유지한다면 문제가 줄어들지만, 더 낮은 비트 양자화를 강요하는 제약(예: 단일 카드 운용, 메모리 압박)이 생긴다면 Gemma 4로 전환을 고려할 필요가 있다.

벤치마크 수치 자체도 주의가 필요하다. SWE-bench나 LiveCodeBench의 점수가 내 실제 코드베이스, 내 도구 연결 방식, 내 프롬프트 스타일에서 동일하게 재현된다는 보장은 없다. 결국 자신의 워크플로우를 소규모로 직접 테스트하는 것이 가장 신뢰할 수 있는 판단 기준이다.

---

추천 대상

RTX 3090 두 장으로 Cline, Continue.dev, Aider 등 에이전트 프레임워크 기반의 Vibe Coding을 구성하려는 개발자에게 이 글이 유용하다. 클라우드 API 비용을 절감하면서도 에이전트형 코딩 워크플로우의 품질을 유지하고 싶은 경우, Qwen3-Coder-30B-A3B를 Q5_K_M 이상으로 구동하는 것이 현재 시점에서 가장 균형 잡힌 선택이다.

---