Resource,Whitepaper

실제 오픈소스 저장소의 버그를 모델이 직접 고치고 그 수정이 프로젝트 검증을 통과하는지로 채점하는 SWE-Bench Verified에서, Qwen3.6-27B는 77.2%를 기록했습니다. 같은 시험에서 Claude Sonnet 4.5도 정확히 77.2%로, 소수점까지 겹치는 동점입니다. 다만 한 세대 뒤인 Sonnet 4.6은 79.6%로 2.4포인트 앞서 있어, 정확한 표현은 “한 세대 전 프론티어와 동급, 최신 세대에는 근소하게 뒤짐”입니다. 동급이지 추월은 아닙니다. 이 수치가 조직 워크로드에 그대로 적용되는지는 백서의 벤치 조건표에서 점검해야 합니다.

이 동점이 의미를 갖는 이유는 점수의 크기가 아니라 위치입니다. 77.2%는 프롬프트를 외부로 보내 받아 온 점수가 아니라 조직의 GPU 안에서 낼 수 있는 점수입니다. 두 오픈 모델(Qwen3.6-27B Dense와 Qwen3.6-35B-A3B MoE)은 모두 Apache-2.0으로 배포되어, 가중치를 사내에 세우고 사내 데이터로 특화해도 된다는 점이 법적으로 보장됩니다. 성능 수치는 측정 조건에 따라 흔들려도 이 라이선스는 고정된 사실이므로, 규제 심사를 앞둔 조직은 라이선스 조항을 먼저 확인할 수 있습니다.

국내 기업과 공공기관의 AI 도입은 세 통증을 공통으로 안고 있습니다. 첫째는 비용 구조로, 프론티어 API는 토큰량에 비례해 과금되므로 사내 도구가 성공해 사용량이 몇 배로 늘면 예산이 그대로 끌려다닙니다. 둘째는 데이터 주권으로, 금융·의료·공공은 프롬프트에 담긴 고객정보나 미공개 자료가 담장 밖으로 나가는 순간 규제 심사에서 결격 소지가 생깁니다. 셋째는 벤더 종속으로, 한 사업자의 가격 인상이나 모델 단종에 도입 조직이 그대로 노출됩니다.

지금까지 온프렘이 이 통증의 해법으로 거론될 때마다 “그 대신 성능을 크게 내줘야 한다”는 전제가 따라붙었습니다. 온프렘은 곧 타협이라는 인식이었습니다. 2026년 4월 공개된 Qwen3.6 세대가 흔든 것이 이 전제입니다. 오픈 로컬 모델이 프론티어 코딩 벤치 상위 리그에 이름을 올리면서, 온프렘 검토는 “성능 포기”가 아니라 “비용·데이터 주권·성능을 다시 묶는 재조합”이 됐습니다. 온프렘 LLM을 유보했던 조직은 이 전제를 다시 점검해야 합니다.

도입 검토에는 온프렘 오픈 모델 두 종과 프론티어 API를 같은 표에서 견주는 작업이 필요합니다. 다만 Sonnet 계열 공개 수치는 확장 사고·도구 사용을 켠 셋업 위주여서, Qwen 수치와 나란히 둘 때는 “같은 시험지인가”를 함께 물어야 합니다. 코딩 실무를 재는 SWE-Bench에서 27B는 77.2%로 Sonnet 4.5와 동점, Sonnet 4.6(79.6%)에는 근소하게 뒤집니다. 같은 오픈 계열에서도 27B는 35B-A3B(73.4%)보다 앞서, 큰 숫자가 붙은 MoE보다 실연산이 짙은 27B Dense가 코딩에서 더 안정적입니다.

두 오픈 모델은 크기 표기가 비슷해도 성격이 갈립니다. 27B Dense는 파라미터를 전량 켜 느리지만 답이 짙고 긴 대화에서 일관성이 높습니다. 35B-A3B는 토큰당 3B만 켜는 MoE라 약 3.3배 빠르지만(32 대 105 tok/s), 약 8만 토큰 부근에서 같은 문장을 반복하는 벽이 보고돼 있습니다. 온프렘과 API의 갈림도 성능 하나가 아니라 데이터 주권·비용·성능이 얽힌 저울입니다. 도입 검토 조직은 이 세 축을 백서 비교표에서 함께 확인할 수 있습니다.

세 후보 중 하나가 모든 자리를 이기지는 못하며, 정답은 워크로드가 정합니다. 지시 준수와 코드 품질이 결과물 가치를 좌우하는 잡, 8만 토큰을 넘는 긴 문서 검색 잡에는 짙고 정확한 27B가 제자리입니다. 사용자가 응답을 기다리는 실시간 대화에는 빠른 35B-A3B가 유리하되, 세션이 길어질 여지가 있으면 피하는 편이 안전합니다. 시스템 장애 대응이나 100만 토큰급 초장문, 대고객 안전 응대처럼 실패 비용이 큰 자리는 여전히 프론티어 API가 지킵니다. 세 모델을 경쟁 후보가 아니라 한 팀의 서로 다른 역할로 배치하면, 대부분의 물량을 온프렘 두 모델이 낮은 비용으로 흡수하고 실패 비용이 큰 소수 잡만 API로 넘겨 비용과 성능을 함께 취할 수 있습니다.

이 워크로드별 배치를 조직 전체 운영 전략으로 옮기는 일이 MSAP.ai가 다루는 영역입니다. MSAP.ai는 마이크로서비스 기반 운영 위에 AI를 얹어, 온프렘 모델과 프론티어 API를 워크로드 성격에 따라 나눠 쓰는 하이브리드 구성을 조직의 거버넌스와 규제 요건에 맞춰 설계합니다. 온프렘 LLM 도입이 성능 타협이 아니라 통제권의 재조합이 되도록, TCO 손익분기와 데이터 주권 요건을 함께 저울에 올리는 도입 의사결정을 지원합니다.

세 후보의 구조·벤치마크·운영 함정·손익분기를 조사일 2026-07-03 기준으로 정리하고, 미공개 항목은 지어내지 않고 미확인으로 표기한 전체 비교 백서를 준비했습니다. 온프렘 LLM 도입 검토 회의에 바로 올릴 결정표와 성공 기준 체크리스트를 담았으니, 아래에서 전문을 확인하시기 바랍니다.