로컬 환경에서 개발을 진행하다 보면 문득 이런 의문이 생깁니다.
대규모 인프라나 클라우드 비용 부담 없이, 내 데스크톱이나 워크스테이션 수준에서 원활하게 구동할 수 있는 코딩 전용 인공지능 에이전트 모델이 있을까?
특히 350억 개 파라미터 규모의 경량화된 모델 중에서 실무에 투입할 만한 선택지가 존재할지 직접 검증해 보았습니다.
비교 대상은 동일한 'QwQ-3.5' 아키텍처를 공유하는 두 가지 모델입니다.
첫 번째는 알리바바가 출시한 Qwen2.5-Math 및 QwQ 계열의 연장선에 있는 QwQ-3.6-35B 모델이고,
두 번째는 스타트업 넥스에서 이를 기반으로 코딩 전용 튜닝을 진행한 넥스 N2 미니 모델입니다.
두 모델은 뼈대가 되는 아키텍처와 라이선스 Apache 2.0으로 상업적 활용 가능이 같지만,
실제 코딩 에이전트에 적용해 보았을 때 체감되는 성능과 결과물은 완전히 상반된 모습을 보였습니다. 기
술적 내부 구조부터 실제 리팩토링 및 버그 수정 테스트 결과까지 상세히 짚어보겠습니다.
1. 아키텍처 및 로컬 구동을 위한 요구 사양 분석
비교에 앞서 두 모델의 기반이 되는 QwQ-3.6-35B의 구조적 특징을 명확히 이해할 필요가 있습니다. 표기상 이름은 35B이지만, 이는 모델이 가진 전체 파라미터의 총합을 의미합니다.
전문가 혼합 구조
이 모델은 MoE 방식을 취하고 있어, 토큰 하나를 처리할 때 35B 전체가 구동되지 않습니다.
내부적으로 총 256개의 전문가 레이어가 존재하며, 연산 시 토큰마다 단 8개의 전문가 레이어만 선택하여 활성화됩니다.
즉, 실제 추론 시점에 활성화되는 파라미터는 약 3B 수준으로 억제되므로 연산 효율성이 극대화됩니다.
하이브리드 어텐션과 게이티드 델타넷
전체 구조가 전통적인 트랜스포머의 어텐션 레이어로만 이루어져 있지 않습니다.
총 40개의 레이어 중 30개는 만바 계열의 선형 어텐션 구조인 '게이티드 델타넷'으로 구현되어 있으며, 표준적인 트랜스포머 어텐션 레이어는 10개에 불과합니다.
이러한 설계는 컨텍스트 윈도우가 길어질 때 메모리 점유율을 낮추는 데 결정적인 역할을 합니다. LLM 추론 시 병목이 되는 KV 캐시는 오직 표준 어텐션 레이어에서만 생성되기 때문입니다.
결과적으로 262K라는 방대한 컨텍스트 환경에서도 KV 캐시가 차지하는 메모리는 7GB 수준에 머무릅니다.
실제 로컬 하드웨어 요구량 및 구동 성능
로컬 머신에서 원래 성능을 온전히 끌어내기 위해서는 양자화 모델 선택이 중요합니다.
손실을 최소화하는 Q5_K_S 기준으로 모델 파일 크기는 약 27GB입니다.
여기에 KV 캐시 메모리 7GB를 더하면 최소 34GB의 여유 VRAM이 확보되어야 오프로딩 없이 원전 성능을 낼 수 있습니다.
이 수준 이하의 양자화를 사용할 경우 퍼플렉서티가 틀어져 모델이 질문의 의도를 놓치거나 엉뚱한 답변을 출력하는 현상이 잦아집니다.
-
Mac Studio / MacBook: 오전용 단일 메모리 구조 덕분에 34GB의 요구량을 여유롭게 수용합니다. 구동 시 초당 40토큰에서 60토큰 수준의 안정적인 출력 속도를 보여줍니다.
-
PC 환경: 그래픽카드의 VRAM이 24GB이기 때문에 필요한 34GB를 모두 올리지 못하고 일정 부분을 시스템 메모리로 오프로딩해야 합니다.
그러나 GPU 자체의 압도적인 메모리 대역폭과 텐서 코어 연산 능력 덕분에, 일부 오프로딩 상태임에도 불구하고 맥 환경보다 약 1.5배 빠른 초당 60토큰 이상의 쾌적한 속도를 낼 수 있습니다.
2. 실전 코딩 에이전트 테스트 및 한계점
이 성능을 바탕으로 직접 구축한 로컬 코딩 에이전트에 모델을 결합하여 실무 수준의 과제를 부여했습니다. 에이전트는 로컬 모델의 출력이 지닌 불안정성을 프롬프트 체인과 도구 사용 구조로 보완하도록 설계되었습니다.
테스트 과제: 테트리스 게임 구현 및 리팩토링
가장 먼저 완전한 상태의 테트리스 게임 코드를 작성을 지시했습니다.
초반 코드 생성 단계는 무리 없이 통과했습니다.
전체적인 실행 흐름은 만들어내지만, 세부적인 규칙에서 버그가 존재했고 무엇보다 단 하나의 파일에 모든 비즈니스 로직과 뷰 렌더링 코드를 몰아넣는 아쉬운 아키텍처를 보여주었습니다.
다음 단계로 코드의 관심사를 분리하고 역할별로 파일을 쪼개는 '리팩토링' 작업을 명령했습니다. 이 단계까지는 두 모델 모두 어느 정도 성공적인 결과물을 도출했습니다.
QwQ-3.6-35B의 치명적 결함
문제가 발생한 지점은 리팩토링 이후 발생한 세부 버그를 수정하는 단계였습니다.
'다음에 내려올 블록을 보여주는 미리 보기 화면이 갱신되지 않는 현상'을 고치라는 구체적인 디버깅 명령을 내렸습니다.
QwQ-3.6 모델은 처음에는 원인을 분석하며 그럴싸하게 생각을 전개하는 듯했으나, 이내 사유 프로세스 내부에서 같은 논리를 무한히 반복하는 상태에 빠져버렸습니다.
실제 코드를 수정하는 액션을 취하지 못하고, 자신이 무엇을 해야 하는지 단계적 추론만 반복하며 토큰을 낭비하는 현상입니다.
이는 허깅페이스공식 레포지토리의 이슈 스레드에서도 수없이 보고된 해당 모델의 고질적인 문제입니다.
프롬프트를 다듬거나, 에이전트 프레임워크를 바꾸어 연결해도 동일하게 추론 루프에 갇히며 출력이 마비되었습니다.
추론 기능을 강제로 끄면 안 되는 이유
일부 사용자들은 API 옵션이나 프롬프트 제어를 통해 생각하는 과정인 태그를 강제로 비활성화하여 이 루프를 회피하려고 시도합니다.
그러나 35B 클래스의 경량 모델에서 리즈닝을 강제로 끄는 것은 악수가 됩니다.
이 모델들이 벤치마크에서 높은 점수를 기록할 수 있었던 이유는 내부적으로 긴 추론 과정을 거치며 논리 오류를 스스로 교정하도록 학습되었기 때문입니다.
즉, 평가 자체를 설계해 둔 모델이기에 생각을 하지 못하게 막아버리는 순간, 지능 자체가 급격히 저하되어 복잡한 컨텍스트를 이해하지 못하는 멍청한 모델로 전락합니다.
결과적으로 QwQ-3.6-35B는 단독으로 복잡한 실무 에이전트를 리딩하기에는 무리가 있다는 결론에 도달합니다.
3. 반전을 보여준 넥스 N2 미니
동일한 QwQ-3.5 35B 아키텍처를 베이스로 삼았음에도, 중국의 AI 스타트업 넥스가 튜닝한 '넥스 N2 미니'는 전혀 다른 결과를 보여주었습니다.
참고로 이들은 397B 초대형 모델 기반의 'N2 프로'를 주력 마케팅 포인트로 삼고 있으나, 로컬 구동 관점에서는 35B 기반의 미니 모델이 핵심입니다.
사후 학습 데이터의 방향성 차이
두 모델의 성패를 가른 것은 '어떤 데이터로 파인 튜닝과 정렬을 진행했는가'의 차이입니다.
-
QwQ-3.6: 수학, 논리, 일반 상식적 추론을 두루 잘하도록 설계된 '범용 리즈닝 에이전트' 성격을 띱니다.
코딩에 특화된 정렬의 밀도가 상대적으로 낮습니다. -
NEX N2 Mini: 이 모델은 애초에 개발 환경의 코딩 에이전트 구동을 타깃으로 삼았습니다. 실제 뛰어난 성능을 내는 상용 에이전트가 개발 과정에서 남긴 실제 작업 궤적 데이터, 즉 문제 정의-추론-코드 수정-에러 피드백으로 이어지는 파이프라인 데이터를 집중적으로 학습했습니다.
테스트 결과
QwQ-3.6이 무한 루프에 빠졌던 테트리스 디버깅 과제를 넥스 N2 미니에 동일하게 부여했습니다. 결과는 깔끔한 성공이었습니다.
사유 과정이 길어지더라도 길을 잃지 않고 정확한 지점을 짚어내어 파일 간 참조 관계를 깨뜨리지 않은 채 버그를 수정했습니다.
세부적인 리팩토링 요구사항도 에러 없이 완수해 냈습니다.
로컬 개발 환경에서의 가치와 선택 기준
이전까지는 로컬 환경에서 코딩 에이전트를 안정적으로 구동하려면 최소 1000억 개 파라미터 이상의 체급이 필요하다고 판단했습니다.
실제로 최근까지도 229B 규모의 미니맥스 계열 모델을 주로 활용해 왔습니다.
작은 모델들은 논리적 도약이나 리즈닝 루프 때문에 실무 코드를 맡기기 어려웠기 때문입니다.
그러나 넥스 N2 미니를 테스트해 보면서 경량화 모델의 실용 가능성을 재확인했습니다.
물론 절대적인 지능이나 복잡한 아키텍처 설계 능력이 200B 이상의 초대형 로컬 모델이나 클로드 3.5 소네트 같은 상용 유료 API 수준에 비할 바는 아닙니다.
하지만 적절한 파인 튜닝이 뒷받침된다면 35B 수준의 가벼운 체급으로도 루프에 빠지지 않고 주어진 컨텍스트 내에서 디버깅과 리팩토링을 완수할 수 있음을 증명했습니다.
워크스테이션의 VRAM 용량이 제한적이거나 하드웨어 자원이 넉넉하지 않은 상황에서 비용 효율적인 로컬 코딩 에이전트를 구축하고자 한다면, 현재 기준으로 넥스 N2 미니는 충분히 도입을 고려할 만한 현실적인 대안이 될 것입니다.
