Qwen3.6-35B로 만드는 코딩 에이전트: vLLM 서빙부터 툴 콜링까지
가벼운 VRAM 사용량과 강력한 추론 능력을 갖춘 Qwen3.6-35B-A3B 모델을 vLLM으로 최적화하여 실제 동작하는 코딩 에이전트를 구축하는 기술적 여정을 다룹니다.
성능과 비용의 딜레마, 우리는 왜 새로운 모델을 찾는가
많은 개발자와 AI 엔지니어들이 겪는 가장 큰 고민은 ‘성능’과 ‘인프라 비용’ 사이의 타협점입니다. GPT-4나 Claude 3.5 Sonnet 같은 거대 모델은 놀라운 성능을 보여주지만, API 호출 비용이 기하급수적으로 늘어나거나 데이터 보안 문제로 인해 온프레미스(On-premise) 구축이 필수적인 상황이 옵니다. 하지만 자체 서버에 올릴 수 있는 오픈소스 모델들은 종종 추론 속도가 너무 느리거나, 복잡한 툴 콜링(Tool Calling)에서 잦은 환각 현상을 보이며 실무 적용에 한계를 드러냈습니다.
특히 코딩 에이전트를 구축할 때 가장 중요한 것은 단순한 코드 생성이 아니라, 생성한 코드를 실행하고 그 결과를 다시 읽어 수정하는 ‘루프(Loop)’ 구조를 얼마나 정확하게 수행하느냐에 있습니다. 이를 위해서는 모델이 정확한 시점에 정확한 인자로 외부 함수를 호출하는 툴 콜링 능력이 필수적입니다. 최근 주목받는 Qwen3.6-35B-A3B 모델은 이러한 요구사항을 충족시키면서도 효율적인 파라미터 구조를 통해 하드웨어 진입 장벽을 낮췄다는 점에서 매우 매력적인 선택지입니다.
Qwen3.6-35B-A3B: 효율성의 극대화
Qwen3.6-35B-A3B 모델의 핵심은 성능을 유지하면서 메모리 점유율을 획기적으로 줄인 설계에 있습니다. 특히 FP8 양자화 버전을 사용할 경우, VRAM 사용량을 대폭 아끼면서도 FP16 모델과 거의 동일한 수준의 벤치마크 성능을 유지합니다. 이는 고가의 H100 GPU가 아니더라도 A100이나 L40S, 심지어 일부 고사양 소비자용 GPU 환경에서도 충분히 서빙이 가능하다는 것을 의미합니다.
단순히 가벼운 것이 전부가 아닙니다. 이 모델은 코딩 특화 데이터셋을 통해 학습되어 파이썬, 자바스크립트 등 주요 언어에 대한 이해도가 매우 높으며, 무엇보다 구조화된 출력(Structured Output) 능력이 강화되었습니다. 이는 에이전트가 JSON 형태로 툴을 호출해야 하는 환경에서 치명적인 구문 오류를 줄여주는 결정적인 요소가 됩니다.
vLLM을 활용한 고성능 서빙 아키텍처
모델을 단순히 로드하는 것과 ‘서비스’하는 것은 완전히 다른 문제입니다. vLLM은 PagedAttention 기술을 통해 KV 캐시 메모리를 효율적으로 관리하며, 높은 처리량(Throughput)을 보장하는 최적의 서빙 프레임워크입니다. Qwen3.6-35B-A3B를 vLLM으로 서빙하면 OpenAI 호환 API 서버가 구축되어, 기존에 작성된 수많은 LLM 애플리케이션 라이브러리를 그대로 사용할 수 있습니다.
여기서 가장 주의해야 할 점은 툴 콜링 설정입니다. 많은 사용자가 모델을 띄운 후 툴 콜링이 작동하지 않아 당황하곤 합니다. vLLM 0.19.0 이상의 버전에서는 다음과 같은 설정이 필수적입니다.
- –enable-auto-tool-choice: 모델이 스스로 툴 사용 여부를 결정하게 하는 옵션입니다.
- –tool-call-parser qwen3_coder: Qwen 모델 특유의 툴 호출 포맷을 정확하게 파싱하기 위한 전용 파서 설정입니다. 이 설정이 누락되면 모델은 툴을 호출하는 것처럼 텍스트를 생성하지만, 서버는 이를 API 호출로 인식하지 못하고 단순 텍스트로 응답하게 됩니다.
실전: 코딩 에이전트 구축 프로세스
이제 서빙된 모델을 바탕으로 실제 코딩 에이전트를 만드는 흐름을 살펴보겠습니다. 코딩 에이전트의 핵심은 ‘생각(Thought) $\rightarrow$ 행동(Action) $\rightarrow$ 관찰(Observation) $\rightarrow$ 수정(Refinement)’의 사이클입니다.
먼저, 에이전트에게 제공할 툴셋을 정의해야 합니다. 예를 들어 execute_python_code, read_file, write_file과 같은 함수들을 정의하고, 이를 OpenAI SDK의 tools 파라미터에 전달합니다. 모델은 사용자의 요청을 분석하고, 필요한 경우 execute_python_code를 호출하여 실제 런타임에서 코드를 실행합니다.
이 과정에서 Qwen3.6-35B-A3B는 매우 정교하게 작동합니다. 예를 들어 “현재 디렉토리의 모든 .py 파일을 읽어서 중복 함수를 찾아 제거해줘”라는 요청을 받으면, 모델은 다음과 같은 순서로 동작합니다.
ls명령어로 파일 목록 확인 (Tool Call)- 각 파일의 내용을
read_file로 읽기 (Tool Call 반복) - 읽어온 내용을 바탕으로 중복 로직 분석 (Reasoning)
- 수정된 코드를
write_file로 저장 (Tool Call)
이 모든 과정이 자동화된 루프로 돌아갈 때, 우리는 단순한 챗봇이 아닌 ‘에이전트’라고 부를 수 있습니다.
기술적 트레이드오프 분석
모든 기술 선택에는 기회비용이 따릅니다. Qwen3.6-35B-A3B와 vLLM 조합의 장단점을 명확히 분석해 보겠습니다.
| 구분 | 장점 (Pros) | 단점 (Cons) |
|---|---|---|
| 인프라 | FP8 양자화로 VRAM 효율 극대화, 온프레미스 가능 | 최소 수십 GB의 VRAM 확보 필요 (GPU 의존적) |
| 성능 | 코딩 및 툴 콜링 정확도 매우 높음 | 초거대 모델(GPT-4o 등) 대비 복잡한 추론 능력 소폭 낮음 |
| 운영 | OpenAI 호환 API로 빠른 통합 가능 | vLLM 버전 업데이트에 따른 파서 설정 민감도 높음 |
실무자를 위한 단계별 액션 아이템
이 기술 스택을 실제 프로젝트에 도입하려는 개발자와 PM은 다음 단계를 따라 실행해 보시기 바랍니다.
1단계: 인프라 검토 및 환경 구축
사용 가능한 GPU 메모리를 확인하십시오. Qwen3.6-35B-A3B FP8 모델을 서빙하기 위해서는 모델 가중치 외에도 KV 캐시를 위한 여유 공간이 필요합니다. vLLM 0.19.0 이상의 최신 버전을 설치하고 Docker 환경에서 격리된 서빙 환경을 구축하십시오.
2단계: 툴 콜링 파이프라인 검증
복잡한 에이전트를 만들기 전, 아주 간단한 add(a, b) 함수 하나만 정의하여 모델이 정확하게 툴을 호출하고 결과값을 받아 다시 응답하는지 확인하십시오. 이때 반드시 --tool-call-parser qwen3_coder 옵션이 적용되었는지 체크해야 합니다.
3단계: 에이전트 루프 설계
LangGraph나 CrewAI와 같은 프레임워크를 사용하여 에이전트의 상태 관리(State Management)를 설계하십시오. 모델이 무한 루프에 빠지지 않도록 최대 반복 횟수(Max Iterations)를 설정하고, 각 단계에서 모델의 사고 과정을 로그로 남겨 디버깅 가능하게 만드십시오.
4단계: 평가 데이터셋 구축
코딩 에이전트의 성능은 주관적일 수 있습니다. 실제 해결해야 할 코딩 태스크 20~30개를 선정하여 ‘성공/실패’ 여부를 측정하는 자체 벤치마크를 만드십시오. 이를 통해 프롬프트를 튜닝하거나 필요한 툴을 추가하며 최적화하십시오.
결론: 오픈소스 LLM이 만드는 에이전트의 미래
우리는 이제 더 이상 폐쇄형 API에만 의존할 필요가 없는 시대에 살고 있습니다. Qwen3.6-35B-A3B와 같은 고성능 오픈 모델과 vLLM 같은 효율적인 서빙 엔진의 결합은 기업이 데이터 주권을 유지하면서도 강력한 AI 자동화 도구를 구축할 수 있게 해줍니다.
중요한 것은 모델의 크기가 아니라, 그 모델이 실제 환경에서 얼마나 정확하게 ‘행동’할 수 있느냐입니다. 툴 콜링 능력이 검증된 모델을 선택하고, 이를 최적의 인프라 위에서 구동하며, 정교한 에이전트 워크플로우를 설계하는 것. 이것이 바로 현재 AI 실무자가 집중해야 할 핵심 경쟁력입니다.
FAQ
Serving Qwen3.6-35B-A3B With vLLM and Building a Coding Agent With Tool Calling의 핵심 쟁점은 무엇인가요?
핵심 문제 정의, 비용 구조, 실제 적용 방법, 리스크를 함께 봐야 합니다.
Serving Qwen3.6-35B-A3B With vLLM and Building a Coding Agent With Tool Calling를 바로 도입해도 되나요?
작은 범위에서 실험하고 데이터를 확인한 뒤 단계적으로 확대하는 편이 안전합니다.
실무에서 가장 먼저 확인할 것은 무엇인가요?
목표 지표, 대상 사용자, 예산 범위, 운영 책임자를 먼저 명확히 해야 합니다.
법률이나 정책 이슈도 함께 봐야 하나요?
네. 데이터 수집 방식, 플랫폼 정책, 개인정보 관련 제한을 반드시 점검해야 합니다.
성과를 어떻게 측정하면 좋나요?
비용, 전환율, 클릭률, 운영 공수, 재사용 가능성 같은 지표를 함께 보는 것이 좋습니다.
관련 글 추천
- https://infobuza.com/2026/04/20/20260420-cy1d32/
- https://infobuza.com/2026/04/20/20260420-4bhllu/
지금 바로 시작할 수 있는 실무 액션
- 현재 팀의 AI 활용 범위와 검증 절차를 먼저 문서화합니다.
- 작은 파일럿 프로젝트로 KPI를 정하고 2~4주 단위로 검증합니다.
- 보안, 품질, 리뷰 기준을 자동화 도구와 함께 연결합니다.