관련 글 — DeepSeek-R1에 대한 고찰과 PPO, GRPO · LLM은 어떻게 학습되는가 · MCP와 Harness Engineering · 누가 만든 모델을 우리의 AI라고 부를 수 있는가

2026년 9월 GPT-6 Astra가 공개되었다. OpenAI는 이 모델을 복잡한 추론과 코딩, Computer Use, Research와 문서 작업을 위한 자사의 가장 강력한 모델로 소개한다. 105만 Token의 Context Window와 12만 8천 Token의 최대 출력을 지원하고, Web Search와 File Search, Hosted Shell, Computer Use, MCP, Tool Search까지 한 API 안에서 사용할 수 있다. 이제 좋은 모델을 고른다는 말은 질문에 답을 잘하는 언어 모델 하나를 고른다는 뜻에서 꽤 멀어졌다. 브라우저와 터미널을 넘나들고, 도구가 돌아오는 동안 다른 일을 처리하며, 여러 Agent를 나누어 쓰는 작업 시스템을 고르는 일에 가까워지고 있다. 자세한 사양은 GPT-6 Astra 공식 문서와 Model Guidance에서 확인할 수 있다.

성능은 굉장히 좋아 보인다. 다만 표를 읽을 때는 작은 글씨도 같이 봐야 한다. OpenAI는 각 Effort에서 얻은 점수 중 최댓값을 실었으며, 연구 환경이나 API에서 측정해 실제 ChatGPT와 System Prompt, Tool 구성이 다를 수 있다고 명시한다. Computer Use 표의 OSWorld는 오프라인 Subset의 부분 점수이고, ScreenSpot-Pro의 Claude Fable 수치는 안전장치를 줄인 Mythos에서 가져왔다. Coding 표의 FrontierCode에는 별도의 Developer Message를 사용했다. 이 조건을 떼어내고 모델 이름과 점수만 남기면 뒤에서 이야기할 Harness의 차이도 함께 지워진다.

그리고 중요한 것은 성능만이 아니다. 가격표를 보면 GPT-6 Astra는 100만 Token당 입력 10달러, 출력 50달러다. 27만 2천 Token을 넘기는 요청에는 더 높은 요율이 적용되고, Search나 Computer Use 같은 Tool에는 별도의 호출 비용도 붙는다. OpenAI는 이전 모델보다 적은 출력 Token으로 일을 끝내 일부 평가에서는 Task당 비용이 오히려 낮아졌다고 설명한다. 실제 비용은 단순한 Token 단가만으로 정해지지 않는다는 뜻이다. 그래도 긴 Context와 반복되는 Tool Call, 실패 후 재시도가 쌓이는 Agent를 운영하는 입장에서는 요청 한 번의 가격보다 작업 하나를 끝낼 때까지의 총비용을 신경 쓰지 않을 수 없다.

직접 운영한다고 문제가 사라지는 것도 아니다. Frontier급 모델의 Weight를 저장하고 여러 GPU에 올리는 것부터 만만하지 않다. 여기에 긴 Context를 위한 KV Cache와 동시 요청, Tool Runtime과 관찰 로그까지 붙으면 “Open-weight니까 On-premise에서 돌리면 된다”는 말은 갑자기 아주 비싼 문장이 된다.

그 사이 중국의 모델들은 묘한 위치를 차지하기 시작했다. Qwen과 GLM, DeepSeek 계열은 상대적으로 낮은 API 가격을 제시하고, Closed Model과 비슷한 성능을 보인다고 주장하며, 큰 모델의 Weight까지 공개한다. 2026년 9월 7일 기준 DeepSeek V4-Pro의 공식 Peak 요금은 100만 Token당 Cache Miss 입력 1.32달러, 출력 3.96달러다. V4-Flash는 각각 0.44달러와 1.32달러이고 Off-peak에는 절반으로 내려간다. 같은 이름의 API라도 성능과 지연시간, 가용성, 안전 정책은 다르므로 가격표만 나란히 놓고 동급이라고 말할 수는 없다. 그래도 DeepSeek의 공식 가격표가 만드는 차이는 충분히 크다.

필자는 데이터 거버넌스와 운영 환경상의 이유로 최근 중국 모델을 실제 업무에 투입하지 않았다. 따라서 여기서 사용 경험을 근거로 품질이나 보안을 단정하지는 않으려 한다. 대신 이 글에서는 조금 다른 질문을 붙잡아보려고 한다.

이 모델들은 정말 ChatGPT와 Claude, Gemini의 출력을 증류해서 만들어졌을까. 만약 가능하다면 무엇을 모으고 어떻게 학습해야 할까. 그리고 지금처럼 Model뿐 아니라 Harness와 MCP, 여러 Tool과 Agent가 함께 일을 하는 시대에도 그 능력을 하나의 Weight 안에 옮길 수 있을까.

먼저 결론부터 말하면

기술적으로는 가능하다. 실제로 이미 하고 있다. 다만 “중국 모델은 미국 모델의 복제품이다”와 “중국 연구소도 Distillation을 학습 과정에 사용했다”는 전혀 다른 주장이다.

공개된 기술 보고서만 보아도 Qwen과 GLM, DeepSeek가 대규모 Pre-training을 수행했다는 근거는 충분하다. Qwen2.5 Technical Report는 최대 18T Token의 Pre-training과 100만 개가 넘는 SFT Sample, 여러 단계의 강화학습을 설명한다. GLM-4.5는 23T Token의 다단계 학습과 Expert Model Iteration, Reinforcement Learning을 공개했다. DeepSeek-V3는 14.8T Token의 Pre-training과 SFT, RL을 거쳤다. 이런 규모의 Base Model을 API 응답 몇 묶음만으로 대체할 수는 없다.

동시에 내부 Distillation도 명시적으로 사용한다. Qwen3 Technical Report는 큰 Qwen 모델의 지식을 작은 모델에 옮기는 Strong-to-Weak Distillation을 설명한다. DeepSeek-R1은 R1이 만든 약 80만 개의 Sample로 Qwen과 Llama Base Model을 Fine-tuning한 여섯 개의 Distilled Model을 공개했다. 큰 모델이 비싼 RL로 찾아낸 추론 패턴을 작은 모델이 SFT로 배우는 구조다. Distillation을 했다는 사실 자체는 추측이 아니라 공개된 학습 Recipe다. 여기서 Teacher가 자기 회사의 큰 모델이라는 점이 중요하다.

논쟁은 Closed Model이 외부 Teacher로 사용되었는가에서 시작한다. 2026년 2월 Anthropic은 DeepSeek와 Moonshot, MiniMax가 약 2만 4천 개의 부정 계정을 통해 Claude와 1,600만 회가 넘는 Exchange를 만들었다고 공식적으로 주장했다. Anthropic이 DeepSeek에 귀속한 양은 15만 회 이상이며, Reasoning과 Rubric Grading, 검열 정책용 응답을 집중적으로 수집했다고 적었다. OpenAI도 미국 하원에 제출한 2026년 2월 자료에서 DeepSeek와 연결된 계정이 접근 제한을 우회하고 출력을 자동 수집한 정황을 확인했다고 밝혔다.

이 자료들은 가볍게 넘길 내용은 아니다. IP와 결제 수단, 요청 Metadata와 Traffic Pattern을 가진 API 제공자가 할 수 있는 관찰이기 때문이다. 다만 현재 공개된 것은 OpenAI와 Anthropic의 조사 결과와 주장이다. 외부 기관이 학습 Pipeline 전체를 감사한 결과도 아니고, 특정 모델의 성능 중 얼마가 어느 Teacher에서 왔는지 분해한 자료도 아니다. 따라서 “외부 API를 Distillation 데이터 수집에 사용한 정황이 강하게 제기되었다”까지는 말할 수 있지만, “Qwen과 GLM과 DeepSeek의 능력은 전부 ChatGPT와 Claude를 복제한 것”이라고 묶어버리면 공개된 증거보다 멀리 나가게 된다.

API만 볼 수 있는데 무엇을 증류할 수 있을까

원래 Knowledge Distillation은 Teacher의 Logit 분포를 Student가 따라가게 만드는 방법을 가리켰다. 정답 Class 하나만 주는 대신, Teacher가 각 Class에 얼마만큼의 확률을 두었는지 학습하면 Class 사이의 관계까지 전달할 수 있다. Hinton 등의 고전적인 Distillation 연구가 설명한 방식이다.

Closed API에서는 이 정보가 보이지 않는다. Weight도 Hidden State도 없고 대개 다음 Token 전체에 대한 Logit도 받을 수 없다. 볼 수 있는 것은 Prompt를 넣었을 때 나온 Text와 Tool Call, 최종 결과 정도다. 그래서 실제로 가능한 것은 Black-box Sequence-level Distillation에 가깝다.

Prompt $x$를 Teacher에 넣어 응답 $y^T$를 받은 뒤 Student가 그 Sequence의 Likelihood를 높이도록 학습한다고 생각해보자.

$$\mathcal{L}_{\mathrm{SFT}} = -\sum_{t=1}^{|y^T|} \log p_\theta(y_t^T \mid x, y_{<t}^T)$$

수식만 보면 일반적인 SFT와 같다. 차이는 Label을 사람이 쓴 것이 아니라 Teacher가 만들었다는 데 있다. Sequence-Level Knowledge Distillation은 기계번역에서 이미 이런 생각을 다루었고, LLM 시대에는 Teacher에게 설명과 근거까지 생성하게 만드는 방향으로 확장되었다. Distilling Step-by-Step은 Label과 함께 Rationale을 사용했고, Orca는 GPT-4와 ChatGPT의 Explanation Trace를 작은 모델이 배우게 했다.

여기서 흔히 생기는 오해가 하나 있다. API로 얻은 긴 설명이 Teacher의 실제 내부 Chain-of-Thought와 같다는 보장은 없다. 모델은 최종 답을 보고 그럴듯한 풀이를 사후에 구성할 수도 있다. Closed Provider가 내부 Reasoning을 숨기고 요약만 제공하면 수집자는 더더욱 실제 계산 경로를 볼 수 없다. 그래도 교육용 데이터로서 쓸모가 없는 것은 아니다. 정답으로 가는 중간 상태와 확인 절차, 답을 수정하는 언어적 패턴이 Student에게 훨씬 촘촘한 Supervision을 주기 때문이다.

현실적인 Pipeline은 응답 한 종류만 모으지 않는다.

좋은 데이터는 “어려운 문제를 많이 물어본 기록”과도 다르다. 수학과 코드는 정답이나 Test로 걸러낼 수 있지만 글쓰기와 분석은 Teacher의 취향을 다시 Teacher에게 채점시키는 Circular Evaluation에 빠지기 쉽다. 같은 질문에 여러 답을 Sampling하고 독립적인 Verifier와 사람이 일부를 확인해야 한다. 쉬운 문제와 어려운 문제, 정상적인 요청과 공격적인 요청, 성공 Trace와 실패 후 복구 Trace도 섞어야 한다.

Student의 현재 분포를 고려하지 않는 것도 문제다. Teacher가 완벽하게 쓴 답만 학습하면 Student가 실제 추론 중 빠지는 상태를 보지 못한다. 그래서 Student가 먼저 답을 만들고 Teacher가 그 답을 교정하거나, Student가 자주 실패하는 Prompt를 다음 생성 Batch에 더 넣는 On-policy 방식이 중요해진다. Generalized Knowledge Distillation은 Student가 방문하는 상태에서 Teacher의 지도를 받는 접근을 다룬다. 배포 로그에서 실패를 찾고 다시 학습 데이터로 돌리는 순간 Distillation은 일회성 복사가 아니라 Data Engine이 된다.

작은 모델이 큰 모델의 능력을 정말 배울 수 있는가

어느 정도는 배울 수 있다. 그렇다고 Teacher의 능력을 그대로 복사한다고 이해하면 곤란하다.

Student가 이미 Pre-training을 통해 언어와 코드, 세상에 대한 기반 Representation을 가지고 있다면 Teacher의 응답은 그 능력을 꺼내는 방법을 가르칠 수 있다. 어떤 문제에서 계산을 다시 확인하는지, 답을 어떤 순서로 구성하는지, 언제 Tool을 호출하는지와 같은 행동 패턴은 비교적 잘 옮겨진다. DeepSeek-R1-Distill이 Qwen과 Llama Base Model에서 출발한 이유도 여기에 있다. Teacher의 모든 지식을 1.5B 모델 안에 새로 집어넣은 것이 아니라 이미 학습된 Base의 가능성을 좋은 Trace로 재정렬한 것이다.

반대로 Student에 없는 Capacity와 지식을 응답 몇 개로 무한히 만들 수는 없다. The False Promise of Imitating Proprietary LLMs는 Proprietary Model의 출력을 따라 학습한 모델이 문체와 익숙한 문제에서는 닮아 보이지만, 새로운 사실과 분포 밖의 문제에서는 격차가 남을 수 있음을 지적했다. API Distillation이 특히 쉽게 옮기는 것은 말투와 답변 형식이다. Benchmark 문제와 비슷한 분포에서는 높은 점수를 만들 수 있지만, Prompt가 조금만 달라졌을 때 Teacher가 가진 넓은 기반 능력까지 남았는지는 별도로 확인해야 한다.

그래서 공개 Benchmark의 점수만으로 Distillation 여부를 역추적하는 방법도 약하다. 같은 답변 습관과 특이한 오류, 자기 정체성에 관한 모순은 흥미로운 단서가 될 수 있다. 하지만 공통된 Web Data와 비슷한 Post-training Recipe, 같은 Evaluation Prompt만으로도 유사한 행동이 나올 수 있다. 행동 Fingerprint는 조사할 이유를 만들어주지만 학습 데이터의 출처를 확정하는 영수증은 아니다.

Agent는 하나의 입출력 함수가 아니다

여기까지는 질문 $x$와 답변 $y$가 있는 단일 모델을 생각했다. 최근의 Agentic System은 이런 모양으로 끝나지 않는다. 이전 글에서 정리했듯이 실제 Agent의 성능은 Model과 Harness를 합친 결과에 가깝다.

$$\text{Agent System} = \text{Model} + \text{Harness}$$

Harness에는 System Instruction과 Context Routing, Memory, Tool Schema, Retry Policy, Permission, Verification, Log와 UI가 포함된다. MCP는 그중 외부 Tool과 Resource를 공통 형식으로 연결하는 Protocol이다. File Search를 언제 할지 결정하는 것은 Model일 수 있지만, 어떤 파일을 보여주고 어떤 권한으로 읽으며 결과를 얼마나 잘라 Context에 넣을지는 Harness가 결정한다. 같은 Model을 사용해도 Harness가 달라지면 Agent Benchmark 점수가 달라지는 이유다.

DeepSeek의 현재 Benchmark 공지에도 이 사실이 드러난다. DeepSeek V4 Change Log는 Code Agent 평가에 자사의 DeepSeek Harness Minimal Mode와 Max Effort를 사용했다고 적고, 일부 점수는 내부 Dataset에서 측정했다고 밝힌다. 이것이 잘못된 평가라는 뜻은 아니다. 다만 표의 한 칸은 Model Weight만의 점수가 아니라 Prompt와 Effort, Harness와 Tool, Test Environment가 합쳐진 결과다. Closed Model과 Open-weight Model의 표를 비교할 때 Scaffold 조건을 함께 보아야 한다.

그렇다면 이 전체를 하나의 모델 출력으로 간주해 학습할 수 있을까. 답은 관찰 가능한 범위에서는 가능하지만, 환경 자체까지 Weight 안에 넣을 수는 없다에 가깝다.

Agent가 일을 하는 동안 다음과 같은 Trajectory가 생긴다고 생각해보자.

$$\tau = (o_0, a_0, o_1, a_1, \ldots, o_T, y)$$

$o_t$는 현재 화면과 파일, Tool Result 같은 Observation이고 $a_t$는 검색과 클릭, 코드 수정 같은 Action이다. 마지막 $y$는 최종 답이나 작업 결과다. Teacher System을 충분히 관찰할 수 있다면 Student는 현재 Observation에서 다음 Action을 예측하도록 학습할 수 있다. ReAct의 Reason-Act-Observe 기록이나 Browser Agent의 Click Trace, Coding Agent의 read → edit → test → repair 기록이 모두 학습 데이터가 된다.

문제는 최종 답만 보았을 때다. Teacher가 검색을 세 번 했는지, 어떤 문서를 버렸는지, Test 실패를 보고 무엇을 고쳤는지 모르면 성공의 원인을 복원하기 어렵다. 여러 Agent가 토론한 결과만 남고 중간 Message가 없다면 역할 분담도 학습할 수 없다. 블랙박스의 최종 출력은 결과에 대한 Demonstration은 주지만 상태에 따른 Policy는 충분히 보여주지 않는다.

그래서 Agent Distillation에서는 가능한 한 자신의 Harness 안에서 Teacher를 실행하고 다음 항목을 기록해야 한다.

1. 매 단계에서 Teacher에게 실제로 보인 Observation과 Context
2. 선택 가능한 Tool과 Schema, 선택한 Action과 Argument
3. Tool이 돌려준 결과와 오류, Timeout과 Permission Denial
4. 계획 변경과 재시도, Critique와 Repair
5. 최종 결과뿐 아니라 Test와 사용자 피드백으로 확인한 Outcome

이 기록이 있으면 Model이 잘한 부분은 Weight로 옮기고, 확실하게 코드로 만들 수 있는 부분은 Runtime으로 남길 수 있다.

무엇이 Weight에 들어가고 무엇이 밖에 남아야 할까

Tool을 사용하는 법은 어느 정도 Weight에 들어갈 수 있다. 어떤 상황에서 검색이 필요한지, 함수의 Argument를 어떻게 채우는지, 오류가 나오면 어떤 순서로 다시 시도하는지는 Action Prediction으로 학습할 수 있다. Smart Agentic Distillation처럼 Reason-Act-Observe 전체 Trajectory를 이용하는 연구가 이 방향을 다룬다. Tool을 사용해 만든 계산 Trace를 자연어 풀이로 다시 바꾸어 학습한 Back-Translated Traces에서는 추론 시 Tool 없이도 일부 능력이 남았다.

하지만 실시간 주가와 사내 DB, 사용자의 현재 화면을 Weight가 기억하게 만들 수는 없다. 정확한 계산기와 Compiler, Permission System과 Transaction도 마찬가지다. 학습 당시의 Tool 동작을 모방할 수는 있어도 현재 환경에서 실제 부작용을 일으키고 그 성공을 확인하려면 Runtime이 필요하다. Tool Knowledge를 내재화하는 것과 Tool Dependency를 제거하는 것은 같은 일이 아니다.

검증도 밖에 남겨야 하는 경우가 많다. Student가 “Test가 통과했다”고 자연스럽게 말하도록 학습하는 것과 실제 Test를 실행하는 것은 다르다. 삭제와 결제, 배포 전에 승인을 받는 절차는 모델이 착하게 행동할 것이라는 기대보다 Permission Boundary로 만드는 편이 안전하다. Memory도 모든 과거를 Weight에 굳히기보다 수정하고 삭제할 수 있는 외부 State로 두어야 한다.

따라서 현실적인 결과물은 대개 다음 셋 중 하나가 된다.

여러 Agent를 하나로 합치는 연구도 이미 나오고 있다. AgentArk는 Multi-agent Interaction을 Reasoning-enhanced Fine-tuning과 Trajectory Augmentation, Process-aware Distillation로 단일 Agent에 옮긴다. MapCoder-Lite는 하나의 7B Base Model에 역할별 LoRA를 붙여 Retriever와 Planner, Coder와 Debugger를 구성했다. 여기서 “단일 모델”은 항상 한 번의 Forward Pass를 의미하지 않는다. 같은 Weight를 여러 역할과 단계에서 반복 호출하고 작은 Harness가 순서를 관리할 수도 있다. Model Binary는 하나여도 System은 여전히 Loop다.

MCP는 이 과정에서 의외로 중요한 학습 자산을 만든다. Tool의 이름과 Input Schema, Result 형식이 Agent마다 제각각이면 한 환경의 Trajectory를 다른 환경에 재사용하기 어렵다. 공통 Interface가 생기면 search_documents를 선택한 이유와 Argument, Result를 비교적 일정한 형태로 저장할 수 있다. MCP가 Intelligence를 증류해주는 것은 아니지만, 행동 기록의 문법을 맞추는 역할은 할 수 있다.

실제로 만든다면 어떤 학습 순서가 현실적일까

거대한 Closed Agent를 작은 Open-weight Agent로 옮긴다고 가정하면 다음 순서가 가장 현실적이다.

1. 먼저 Student가 이미 가진 것을 확인한다

Base Model의 지식과 언어, 코드 능력이 충분하지 않으면 Distillation 데이터가 형식만 가르치게 된다. Domain 지식이 부족하면 Continued Pre-training이나 Retrieval을 먼저 고려하고, 지시 수행이 문제라면 SFT를 준비한다. 작은 모델이 물리적으로 표현하기 어려운 긴 Context와 복잡한 Planning을 요구한다면 목표를 줄여야 한다.

2. Task와 완료 조건을 고정한다

“좋은 Coding Agent”처럼 넓은 목표로는 데이터를 설계하기 어렵다. 버그를 재현하고 수정한 뒤 정해진 Test를 통과하는 것, 문서를 찾아 근거와 함께 답하는 것처럼 Outcome을 실행 가능한 형태로 만든다. Teacher의 문장보다 실제 환경의 성공 여부가 최종 Label이 되어야 한다.

3. Teacher System을 계측한다

Model 응답만 저장하지 않고 Prompt와 Tool Schema, Observation, Action, Tool Result와 Verification을 함께 남긴다. 여러 Teacher를 사용한다면 출처도 기록한다. Closed API를 사용하는 경우 기술적으로 수집이 가능하다는 사실과 이용약관이 허용한다는 사실은 별개다. 경쟁 모델 개발을 위한 Output 사용을 금지하는 Provider도 있으므로 계약과 데이터 Provenance를 학습 전에 확인해야 한다.

4. 성공보다 복구 과정을 모은다

첫 시도에 성공한 Trace는 깔끔하지만 Agent를 튼튼하게 만들기에는 정보가 적다. 잘못된 Tool을 골랐을 때 돌아오는 법, Test 실패를 읽는 법, 접근 권한이 없을 때 멈추는 법이 실제 운영에서 더 중요하다. 성공 Trace와 실패 Trace, Teacher가 고친 Trace를 함께 두고 Action과 최종 답의 Loss Weight를 다르게 줄 수 있다.

5. SFT 뒤에 Student의 실패 분포로 돌아간다

첫 번째 Student를 실제 환경에서 Rollout하고 자주 실패하는 State를 모은다. Teacher가 그 State에서 더 나은 Action을 제시하게 만든 뒤 다시 학습한다. 쉬운 Teacher Demonstration만 계속 추가하는 것보다 Student가 실제로 방문하는 낯선 상태를 채우는 편이 효과적이다.

6. Model과 Harness를 함께 줄인다

비용을 줄인다고 Verification까지 제거하면 작은 모델은 싸게 실패하는 시스템이 된다. 자주 반복되는 계획은 Skill이나 Workflow Code로 옮기고, Tool 목록은 Task에 맞게 Routing하며, Model에는 애매한 판단을 맡긴다. 큰 Teacher의 모든 자유도를 복사하기보다 좁은 범위에서 안정적으로 끝나는 Agent를 만드는 편이 배포 가치가 높다.

앞으로 더 발전할 수 있을까

가능성은 크다. 이유는 Agent가 일반 Chat보다 더 많은 Supervision을 남기기 때문이다. Chat에는 질문과 답변만 있지만 Agent에는 File Diff와 Browser State, Compiler Error와 Test Result, 사용자 승인과 실제 Outcome이 남는다. 어떤 행동이 성공했는지 환경이 알려주는 영역에서는 사람의 선호를 추측하는 Reward Model보다 훨씬 분명한 학습 신호를 만들 수 있다.

비용 구조도 Distillation을 밀어준다. 비싼 Teacher를 배포 중 계속 호출하면 비용은 사용량에 비례해 늘어난다. Teacher를 학습 데이터 생성과 어려운 예외 처리에만 사용하고 대부분의 요청을 Student가 처리하면 비용의 일부를 추론에서 학습으로 옮길 수 있다. 다만 데이터 생성과 검증, 재학습에도 돈이 든다. 요청량이 작거나 Task가 자주 바뀌면 Teacher API를 그대로 쓰는 편이 더 싸다. Distillation은 무료 점심이 아니라 반복되는 Task에 대한 선불 최적화다.

한계도 분명하다. 긴 작업에서는 작은 Action 오류가 다음 Observation을 바꾸고 이후 오차를 누적시킨다. Tool과 Website가 바뀌면 과거 Trajectory는 금방 낡는다. Teacher가 틀린 채점 기준을 가지고 있으면 Student는 그 오류를 더 싸고 빠르게 반복한다. 공개 Benchmark를 중심으로 Prompt를 생성하면 높은 점수는 얻어도 실제 업무 분포에는 약할 수 있다. 무엇보다 Closed Provider의 출력과 사용자 데이터를 어떤 권리로 학습에 사용했는지는 성능과 별개의 문제로 남는다.

그래서 앞으로의 경쟁은 Parameter 수만으로 설명하기 더 어려워질 것 같다. 강한 Base Model을 만드는 Pre-training 능력, Teacher를 잘 사용하는 Synthetic Data Engine, 실제 실패를 모으는 Harness, Tool과 Environment를 재현하는 Evaluation이 함께 움직인다. Model Card만 보아서는 어느 부분이 성능을 만들었는지 알기 어려워지고, 같은 Weight도 어떤 Harness에 놓였는지에 따라 전혀 다른 Agent가 된다.

결국 무엇을 복제하는가

중국 모델이 빠르게 좋아졌다는 사실을 곧바로 외국 모델의 복제로 설명하면 두 가지를 놓친다. 수조 Token 규모의 Pre-training과 MoE, Attention과 Training Infrastructure에서 이루어진 실제 연구를 지워버리고, 반대로 Synthetic Data와 외부 Teacher가 현대 LLM 개발에서 얼마나 강력한 지렛대가 되었는지도 제대로 보지 못한다.

현재 공개된 자료로 가장 정직하게 말하면 이렇다. Qwen과 GLM, DeepSeek는 자체 Base Model 학습과 내부 Distillation, SFT와 RL을 결합해왔다. 그와 별개로 OpenAI와 Anthropic은 일부 중국 연구소가 Closed Model의 출력을 대규모로 수집해 경쟁 모델 학습에 사용하려 했다는 구체적인 정황을 공개했다. 두 사실은 동시에 참일 수 있다. 외부 Teacher를 사용했다고 해서 모든 기반 능력이 거기서 생기는 것은 아니고, 대규모 Pre-training을 했다고 해서 외부 Distillation이 없었다는 뜻도 아니다.

Agent 시대에는 질문이 한 단계 더 넓어진다. 우리는 더 이상 답변 문장만 복제하려는 것이 아니다. 어떤 Context를 찾고, 어떤 Tool을 고르며, 실패를 어떻게 복구하고, 무엇을 근거로 작업을 끝내는지까지 배우려 한다. 그중 일부는 Weight에 들어갈 수 있다. 일부는 MCP Tool과 Verifier, Permission과 Memory로 남아야 한다. 좋은 Distillation은 이 경계를 지우는 기술이 아니라 어디에 무엇을 남길지 결정하는 기술에 가깝다.

결국 복제하려는 대상은 모델의 영혼 같은 것이 아니다. 반복 가능한 작업 절차와 판단의 분포다. 그리고 그 절차가 실제 환경에서 다시 성공하는지 확인하는 순간, Distillation은 모델 압축을 넘어 Harness와 Data Engine을 함께 설계하는 문제가 된다.

참고 자료

• GPT-6 Astra Model
• OpenAI Model Guidance: GPT-6 Astra
• DeepSeek Models & Pricing
• DeepSeek V4 Change Log
• Qwen2.5 Technical Report
• Qwen3 Technical Report
• GLM-4.5: Agentic, Reasoning, and Coding Foundation Models
• DeepSeek-V3 Technical Report
• DeepSeek-R1: Incentivizing Reasoning Capability via Reinforcement Learning
• Anthropic: Detecting and Preventing Distillation Attacks
• OpenAI U.S. House Select Committee Update, 2026-02-12
• Distilling the Knowledge in a Neural Network
• Sequence-Level Knowledge Distillation
• Distilling Step-by-Step
• Orca: Progressive Learning from Complex Explanation Traces
• The False Promise of Imitating Proprietary LLMs
• Generalized Knowledge Distillation
• Smart Agentic Distillation
• Distilling Tool Knowledge via Back-Translated Traces
• AgentArk: Distilling Multi-Agent Intelligence into a Single LLM Agent
• MapCoder-Lite: Squeezing Multi-Agent Coding into a Single Small LLM