만약 당신이 "파일에 접속해서, 세 가지 도구를 호출하고, 보고서를 작성한 뒤, 여섯 번째 단계에서 실수하지 마라"와 같은 유형의 작업에서 로컬 모델을 돌려본 적이 있다면, 그 순간을 잘 알고 있을 것입니다. 7-14B 규모의 모델은 질문 하나에는 멋지게 답변하지만, 긴 체인(chain)에서는 무너져 버립니다. 반대로 무너지지 않는 모델은 용량이 너무 커서 집에서 실행할 수 없죠.

2026년 7월 3일, InternScience 팀(Shanghai AI Laboratory 내부의 AI for Science Center)은 GitHub에 Apache 2.0 라이선스로 Agents-A1 모델을 공개했습니다. 이 모델은 Qwen3.5-35B-A3B를 기반으로 구축된 35B Mixture-of-Experts (MoE) 모델이며, 저자들은 이 모델이 여러 에이전트 작업(agentic tasks)에서 약 30배 더 큰 모델들과 대등한 성능을 유지한다고 주장합니다 (출처: GitHub / InternScience, 2026-07-03).

아래에서는 이것이 실무적으로 무엇을 의미하는지, 저자들의 주장이 어디서 끝나고 검증 가능한 수치가 어디서 시작되는지, 그리고 이를 어떻게 직접 체험해 볼 수 있는지에 대해 다룹니다.

"에이전트 AI (Agentic AI)"란 무엇인가

핵심: 에이전트 AI (Agentic AI)는 별개의 모델이나 채팅 장르가 아닙니다. 이는 언어 모델을 사용하는 방식 중 하나로, 모델이 단일 답변을 내놓는 것이 아니라 다단계 작업을 수행하는 것을 의미합니다. 즉, 계획을 세우고, 도구(검색, 코드, 파일, API)를 호출하며, 호출 결과를 읽고 다음 단계를 수정합니다.

일반적인 채팅은 '질문 - 답변' 방식으로 작동합니다. 반면 에이전트는 '목표 - 단계 - 도구 호출 - 관찰 - 다음 단계'의 방식으로 작동하며, 목표가 달성되거나 단계 예산이 소진될 때까지 수십 번의 반복(iteration)을 거칩니다.

여기서 주요 난관이 발생합니다. 일반적인 답변에서는 오류가 단 하나만 존재합니다. 하지만 에이전트 체인에서는 4단계의 오류가 5단계부터 40단계까지 오염시킵니다. 고립된 작업을 훌륭하게 해결하는 모델이라도, 컨텍스트(context)를 잃지 않고 호출 결과로 존재하지 않는 내용을 지어내지 않으면서 20번 연속으로 작업을 수행해야 하는 곳에서는 절망적일 수 있습니다.

Agents-A1이 바로 이 지점을 겨냥하고 있습니다. 개발자들이 밝힌 초점은 파라미터(parameter)의 숫자를 늘리는 것이 아니라, 모델이 학습하는 시퀀스(sequence)의 길이와 복잡성인 "작업 지평(task horizon)"을 확장하는 것입니다 (출처: GitHub / InternScience). 쉽게 말해, 그들은 박학다식함보다는 장거리 달리기에서의 지구력을 훈련시킨 것입니다.

에이전트용 모델을 무엇으로 설치할지 결정해야 하는 단계에 도달했다면, 실질적인 기준을 하나 제시하겠습니다. Agents-A1의 동작을 Claude나 GPT와 같은 폐쇄형 (closed-source) 에이전트와 비교하는 가장 쉬운 방법은 이들이 모두 하나의 호환 가능한 API를 통해 제공될 때입니다. 이에 대해서는 아래 라우팅 (routing) 섹션에서 자세히 다루겠습니다.

7월 3일에 정확히 무엇이 바뀌었나

핵심 요약: 에이전트 시나리오에 특화된 오픈 소스 35B 모델이 등장했으며, 평가를 위한 코드와 상업적 이용을 허용하는 라이선스가 함께 공개되었습니다.

1차 출처(GitHub / InternScience, 2026-07-03)에 기록된 내용은 다음과 같습니다:

• Agents-A1 - Qwen3.5-35B-A3B 기반의 35B Mixture-of-Experts (MoE).
• Apache 2.0 라이선스 - 사용, 미세 조정 (fine-tuning) 및 제품 통합이 가능합니다.
• 256K 토큰의 컨텍스트 창 (context window)을 지원하며, 양자화 (quantized) 버전이 존재합니다.
• 추론 (inference)을 위해 vLLM 및 SGLang과 호환됩니다.
• 가중치 (weights)와 함께 벤치마크를 실행할 수 있는 코드가 공개되었습니다.

날짜에 주의하십시오. 여러 출처에서 6월 30일부터 7월 7일 사이의 기간을 언급하고 있습니다. 저는 1차 저장소(repository) 및 Creati.ai의 2차 분석(2026-07-03)에서의 게시일인 7월 3일을 기준으로 삼고 있습니다. 만약 보고서를 위해 일 단위의 정확성이 중요하다면, 뉴스 날짜가 아닌 저장소의 커밋 (commit) 날짜를 확인하십시오.

그리고 주장과 사실을 즉시 구분하겠습니다. "1조 개의 파라미터를 가진 모델들과 대등하다"라는 표현은 릴리스 저자들의 평가이며, 독립적인 검증 결과가 아닙 (source pack의 주의 사항). 7월 첫째 주에 MarkTechPost, KuCoin News 및 중국 기술 매체에서 방법론에 대한 분석이 나왔으나, 이는 커뮤니티의 주목 신호일 뿐 품질에 대한 확증은 아닙니다. 논의되고 있다고 해서 검증된 것은 아닙니다.

실제로 얼마나 뛰어난가: 수치

핵심 요약: 저자들이 제시한 수치가 포함된 세 가지 구체적인 벤치마크가 있습니다. 이는 업계의 컨센서스(consensus)가 아니라 "무엇이 주장되었는가"로 읽어야 합니다.

GitHub / InternScience (2026-07-03)의 데이터에 따르면, Agents-A1은 저자들이 해당 데이터셋에서 SOTA (State-of-the-Art)라고 명명한 다음과 같은 결과를 보여줍니다:

이를 냉철하게 해석하자면 다음과 같습니다:

1. 수치들은 평가 코드와 함께 공개되었습니다. 이는 장점입니다. 단순히 말을 믿는 것이 아니라, 직접 재현 (Reproduce)할 수 있기 때문입니다.
2. "벤치마크 X에서 SOTA"라는 주장과 "일반적으로 1T 규모 모델보다 뛰어나다"는 주장은 서로 다른 차원의 이야기입니다. 전자는 특정 데이터셋에 관한 것이며, 후자는 아직 외부에서 아무도 확인하지 않은 일반화된 주장입니다.
3. 에이전트 작업에 대한 벤치마크는 아직 초기 단계입니다. IFBench에서 높은 점수를 받았다고 해서, 당신이 사용하는 특정 도구와 파이프라인에서도 모델이 무너지지 않을 것이라고 보장할 수는 없습니다.

실질적인 결론: 이 표를 당신을 대신해 결정을 내려줄 정답으로 보지 말고, 저녁 시간을 내어 직접 돌려봐야 할 근거로 삼으십시오.

학습 구조 및 소형 모델이 긴 작업을 수행할 수 있는 이유

핵심: 모델을 "]얼마나 크게"] 만드느냐가 아니라, "]무엇을"] 학습시키느냐에 초점을 맞췄습니다.

저자들은 세 단계의 학습 과정을 설명합니다 (출처: GitHub / InternScience):

1. 전 도메인 SFT (Supervised Fine-Tuning): 모델이 기본적으로 도구와 함께 다단계 대화를 수행할 수 있도록 광범위한 도메인 세트에서 지도 학습을 진행합니다.
2. 도메인별 교사 모델 (Teacher Models) 세트: 검색, 코드, 도구 활용 등에 특화된 개별 전문가 모델들입니다. 각 모델은 자신의 좁은 영역에서 강력한 성능을 발휘합니다.
3. Multi-teacher on-policy 증류 (Distillation): 최종 모델은 이러한 교사 모델들로부터 자신의 실제 궤적 (Trajectory), 즉 미리 기록된 "정답"이 아니라 모델이 실제로 수행하는 동작을 바탕으로 학습합니다.

여기서 세 번째 단계가 핵심입니다. On-policy 증류란 모델이 정적인 데이터셋이 아니라, 작업 수행 중 보여주는 자신의 행동을 바탕으로 증류된다는 것을 의미합니다. 에이전트에게는 이것이 일반 채팅 모델보다 더 중요합니다. 오류는 실제 궤적에서 누적되기 때문에, 바로 그 궤적을 바탕으로 학습해야 하기 때문입니다.

이것이 바로 "작업 지평 (task horizon)"에 관한 논지입니다. 팀은 일반적인 박학다식함을 위해 파라미터 (parameters)를 늘리는 대신, 긴 시퀀스 (sequences)에서의 안정성을 키우는 데 집중했습니다. 이것이 비용 측면에서 30배 더 효율적인지는 미지수이지만, 아이디어는 명확하며 검증 가능합니다. 평가 코드는 리포지토리 (repository)에 공개되어 있습니다.

Agents-A1 로컬 실행 방법

핵심: 이 모델은 vLLM 및 SGLang과 호환되므로, 해당 엔진들의 표준적인 방식으로 구동할 수 있습니다. 아래는 vLLM을 사용한 최소한의 프레임워크입니다.

사전에 하드웨어를 확인하십시오. 35B MoE 모델은 양자화 (quantized)된 상태에서도 상당한 비디오 메모리 (VRAM)를 요구합니다. 리포지토리에서 언급하는 양자화 버전들은 요구 사양을 낮춰주지만, 요구 사항 자체를 없애지는 않습니다. 정확한 요구 사항은 GitHub의 모델 카드 (model card)를 참조하십시오. 이는 선택한 양자화 방식에 따라 달라집니다.

vLLM으로 OpenAI 호환 서버 실행하기:

# MODEL_PATH - InternScience 리포지토리에서 다운로드한 가중치 (weights) 경로
# VRAM이 부족할 경우 모델 카드에 있는 양자화 버전을 사용하십시오
vllm serve "$MODEL_PATH" \
...

그 다음, 일반적인 OpenAI 엔드포인트 (endpoint)처럼 호출하면 됩니다:

from openai import OpenAI

# base_url은 로컬 vLLM을 가리키며, 키는 형식적인 용도로 사용됩니다
...

에이전트에게 핵심적인 요소는 256K 토큰의 컨텍스트 (context)입니다 (출처: GitHub / InternScience). --max-model-len 플래그는 사용자의 메모리가 실제로 감당할 수 있는 범위 내로 유지하십시오. 전체 컨텍스트를 설정할 수는 있지만, 그에 따른 비용은 VRAM으로 지불하게 됩니다.

비용 및 로컬 실행이 부적절한 경우

핵심: "오픈 소스 및 무료 라이선스"가 "무료 인퍼런스 (inference)"를 의미하는 것은 아닙니다. 하드웨어, 전기, 그리고 운영에 드는 본인의 시간을 지불해야 합니다.

솔직한 선택 기준은 다음과 같습니다:

공정한 비교를 위해서는 Agents-A1이 실제로 어디에서 경쟁력이 있고 어디에서 성능이 떨어지는지 파악하기 위해 강력한 폐쇄형 모델(closed model)이라는 두 번째 기준점이 여전히 필요합니다. 여기서 영원한 러시아의 고충에 직면하게 됩니다. 폐쇄형 외국 모델(foreign-models)은 결제와 연결이 매우 불편합니다.

여기에 실용적인 가교가 놓여 있습니다: provod.ai는 OpenAI 및 Anthropic의 SDK와 호환되는 단일 API를 통해 Claude, GPT, Gemini, DeepSeek 및 Qwen에 대한 접근을 제공합니다. 키(key)와 base_url만 변경하면 되며, VPN이나 해외 카드 없이 러시아 카드, SBP 또는 계좌 이체를 통해 루블로 결제할 수 있습니다. 즉, 로컬에서 Agents-A1을 돌리면서, 비교를 위한 기준 모델은 base_url만 바꿔서 동일한 코드로 호출할 수 있다는 의미입니다:

from openai import OpenAI

# 폐쇄형 모델과 비교하기 위한 호환 API용 키 및 주소
...

환상을 갖지 않는 것이 중요합니다: provod.ai는 호환 API를 통해 타사의 모델에 접근하는 것이지, 귀하의 로컬 Agents-A1을 호스팅해 주는 것이 아니며 자체 인프라를 대체하는 것도 아닙니다. 자신의 하드웨어에서 수행하는 프라이빗 인퍼런스(Private inference)를 대신해 주지는 않습니다.

빈번한 실패: 에이전트가 고장 나는 지점과 이를 포착하는 방법

핵심: 에이전트 실패의 대부분은 "멍청한 모델" 때문이 아니라 도구(tools), 형식(formats), 그리고 루프(loops)의 문제입니다. 로그를 기록한다면 이를 확인할 수 있습니다.

가장 자주 발생하는 실패 목록과 그에 대한 대처법은 다음과 같습니다:

1. 호출 결과의 환각 (Hallucination of call result). 모델이 도구의 결과를 기다리는 대신 답변을 스스로 "지어냅니다". 엄격한 스키마(Scheme)로 해결할 수 있습니다: 먼저 호출을 수행하고, 관찰된 사실을 바탕으로 추론을 진행해야 합니다. 모든 tool_call과 tool_result를 나란히 기록(Log)하세요.
2. 무한 루프 (Looping). 에이전트가 동일한 도구를 반복해서 호출합니다. 단계 제한(Step limit)과 반복 탐지기(Repeater detector)를 설정하세요: 동일한 인자(Argument)가 연속으로 두 번 나타나면 중단해야 합니다.
3. 컨텍스트 오버플로 (Context overflow). 긴 작업 시 도구의 가공되지 않은(Raw) 답변을 컨텍스트에 계속 밀어 넣으면 256K 컨텍스트가 생각보다 빨리 소진됩니다. 중간 결과들을 요약(Summarize)하세요.
4. 함수 호출(Function calling) 형식 불일치. 모델이 스키마 검증을 통과하지 못하는 인자를 반환합니다. 모든 호출을 검증하고, 모델에게 침묵하는 거절 대신 이해할 수 있는 오류 메시지를 반환하세요.
5. 양자화(Quantization) 시 발생하는 조용한 성능 저하. 너무 공격적인 양자화는 특히 긴 체인(Chain)에서 품질을 떨어뜨립니다. 벤치마크의 총점만 믿지 말고, 다양한 양자화 수준에서 시나리오를 실행하여 비교해 보세요.

만약 n8n과 같은 시각적 도구에서 에이전트를 오케스트레이션(Orchestration)하고 있다면, 동일한 실패 사례들이 노드(Node)에서 나타납니다: HTTP 노드의 타임아웃, 모델의 유효하지 않은 JSON, 멈춰버린 루프 등입니다. 조언은 동일합니다. 최종 오류를 보고 추측하지 말고, 전체 궤적(Trajectory)을 디버깅할 수 있도록 각 노드의 입출력을 기록하세요.

별도로, 농담이 아니라 진지하게 말씀드리자면: provod.ai는 n8n과 같은 자동화 플랫폼을 대체하거나 당신의 구축 작업을 대신 해주지 않습니다. 이 서비스는 정확히 한 가지, 즉 API를 통한 모델 접근 권한만을 제공합니다. 오케스트레이션, 재시도(Retry), 그리고 비즈니스 로직은 여전히 당신이 구축해야 합니다.

Agents-A1을 실전에 투입하기 전 빠른 체크리스트