작은 AI 모델에 무엇을 가르칠 것인가: 증류의 업무 설계
DeepSeek-R1의 출력 기반 증류 사례로 작은 모델에 능력을 전하는 방식을 살펴보고, 업무용 학습 사례의 선별·독립 평가·운영 비용을 함께 설계하는 방법을 제안한다.
GPT Image 2로 생성한 개념 이미지이며, 실제 모델 구조나 실험 장치를 재현한 그림은 아니다.
매일 들어오는 고객 문의를 담당 부서에 나누는 일을 생각해 보자. 큰 언어 모델은 질문의 맥락을 읽고 분류 이유까지 적어 줄 수 있다. 그런데 반복되는 문의의 범위가 좁다면 매번 같은 규모의 모델을 써야 하는지 궁금해진다. 잘 처리한 사례를 모아 작은 모델에게 맡길 수는 없을까.
모델 증류는 이 질문에 답하는 학습 방법 중 하나다. 다만 도입하려면 작은 모델의 이름을 고르기 전에 정할 것이 있다. 무엇을 가르치고, 어떤 답을 학습 사례로 남기며, 배운 능력이 실제 업무에서도 유지됐는지 어떻게 확인할 것인가. 큰 모델이 만든 답변을 쌓는 일만으로 이 결정이 끝나지는 않는다.
이 글은 큰 모델이 생성한 출력으로 다른 모델을 학습시키는 증류를 다룬다. 근거 사례는 2025년 1월 공개된 DeepSeek-R1 연구다. 당시 실험을 증류의 작동 방식을 읽는 사례로 사용하며, 현재 모델들의 성능 순위를 주장하지 않는다. 고객 문의 사례와 아래의 운영 절차는 연구팀의 실험이 아닌 필자의 적용 제안이다.
다른 모델에 전해지는 것은 학습 사례다
출력 기반 증류에서는 가르치는 모델을 교사 모델, 배우는 모델을 학생 모델이라고 부른다. 교사는 주어진 질문에 답하고, 학생은 선별된 질문과 답변의 관계를 학습한다. 학생에게 전달되는 것은 교사가 해당 입력에서 보여 준 행동이다. 교사의 모든 지식과 능력이 학습 자료에 담겼다고 전제할 수는 없다.
DeepSeek-R1의 공식 저장소는 증류 모델들이 Qwen과 Llama 계열을 기반으로 하며 R1이 생성한 표본으로 미세조정됐다고 설명한다. 예를 들어 DeepSeek-R1-Distill-Qwen-32B의 기반은 Qwen2.5-32B다. 이름에 R1이 들어가도 원래 R1의 가중치를 그대로 줄여 담은 모델로 읽어서는 안 된다. 교사와 학생의 계보를 구분해야 모델을 비교할 출발점도 맞는다. 공식 모델 문서
이 차이는 기존의 양자화와 나란히 놓으면 이해하기 쉽다. 양자화는 수치를 표현하는 정밀도를 줄이는 방식이고, 여기서 말하는 증류는 출력 사례를 이용해 학생의 가중치를 학습하는 방식이다. 작은 모델을 만들거나 운영하는 데 함께 검토할 수 있지만, 무엇을 바꿨는지에 대한 설명은 서로 달라야 한다.
또한 한 번의 프롬프트에 모범 답안을 넣는 것과 학습 데이터로 모델을 미세조정하는 것도 구분해야 한다. 업무 담당자가 예시 몇 개로 이미 충분한 성능을 얻는다면, 증류가 필요한 이유부터 다시 확인할 수 있다. 증류를 선택하는 순간 데이터 선별, 학습, 버전 관리, 재평가가 운영 업무에 추가되기 때문이다.
연구의 성과는 어디까지 옮겨 읽을 수 있나
원논문은 약 80만 개의 선별된 표본으로 작은 모델들을 학습시켰으며, 공개한 증류 모델에는 지도 미세조정만 적용하고 별도의 강화학습 단계를 넣지 않았다고 설명한다. 표본 구성에는 추론 관련 약 60만 개와 비추론 약 20만 개가 포함됐다. 추론 표본은 여러 응답 중 정답을 선별하고 읽기 어려운 형식을 걸러 만드는 과정을 거쳤다. DeepSeek-R1 원논문 §2.3.3·§2.4
논문의 같은 32B 규모 비교에서 AIME 2024 pass@1은 DeepSeek-R1-Zero-Qwen-32B가 47.0, DeepSeek-R1-Distill-Qwen-32B가 72.6으로 보고됐다. 이는 해당 실험의 강화학습 경로와 증류 경로를 비교한 결과다. 모든 학습 조건과 계산 예산을 통제한 보편 법칙으로 확대해서는 안 된다. 원논문 §4.1·표 6
이 결과에서 업무 설계에 가져올 수 있는 질문은 구체적이다. 학생이 스스로 충분한 정답 사례를 얻기 어려운 과제에서, 더 강한 교사가 만든 선별 사례가 학습을 도울 수 있는가. 반대로 수학 문제의 성과만 보고 한국어 문의 분류, 사내 규정 해석, 도구 호출까지 맡길 수 있다고 결론 내릴 수는 없다. 새로운 업무는 새로운 평가 대상을 만든다.
교사의 답변을 채점 기준으로도 쓰면 또 다른 혼동이 생긴다. 학생이 교사의 선택을 잘 따라 한다는 사실과 두 모델의 선택이 업무 기준에 맞는다는 사실은 별개로 확인해야 한다. 문의의 실제 담당 부서나 문서의 유효한 근거처럼, 모델 밖에서 확인할 수 있는 기준이 필요하다. 이 구분은 AI 심사위원을 쓰는 방식에도 그대로 연결된다.
문의 분류를 가르친다면 무엇을 남길까
가상의 문의 분류 업무에서는 처음부터 “모든 문의를 잘 이해한다”는 목표를 잡기보다, 사람이 인수할 수 있는 결과를 정의하는 편이 낫다. 담당 부서, 분류에 사용한 문장, 추가 확인이 필요한 이유를 결과로 정할 수 있다. 담당 부서가 여러 곳이면 억지로 하나를 고르기보다 사람이 판단할 수 있도록 남기는 것도 유효한 결과다.
학습 사례를 만들 때에는 문의 원문, 적용한 분류 기준의 버전, 교사가 만든 답, 검토 뒤 채택한 답을 구분해 보관하는 방식을 제안한다. 교사의 답을 사람이 수정했다면 두 답의 차이도 남긴다. 그래야 나중에 오류가 발견됐을 때 입력이 모호했는지, 기준이 바뀌었는지, 생성 답변이 잘못됐는지 추적할 수 있다.
자주 들어오는 명확한 문의만 모으면 데이터는 깨끗해 보일 수 있다. 그러나 “배송이 늦었고 결제 금액도 다르다”처럼 부서가 겹치는 사례, 첨부파일 없이는 판단하기 어려운 사례, 이전 정책에서는 맞았지만 새 정책에서는 달라지는 사례도 따로 확보해야 한다. 이는 합성 사례 수를 늘리라는 뜻이 아니다. 실제로 판단을 바꾸는 조건이 학습 자료와 평가 자료에 어떻게 반영되는지 확인하자는 제안이다.
평가 자료는 학습용 사례를 만들기 전에 분리해 둘 수 있다. 같은 문의를 어순만 바꿔 양쪽에 넣으면 새로운 문의를 처리하는 능력과 익숙한 표현을 재현하는 능력을 구별하기 어렵다. 같은 사건에서 파생된 문의는 함께 묶고, 이후에 접수된 문의로 별도 점검하는 식으로 경계를 잡는 것이 좋다.
비교 대상에는 교사 모델과 증류한 학생뿐 아니라, 증류 전 학생에 같은 업무 지시를 준 결과도 포함할 수 있다. 이미 단순한 규칙으로 처리하는 업무라면 그 결과도 비교한다. 정확도 외에 잘못 배정한 문의를 사람이 다시 옮긴 횟수, 보류한 문의의 비중, 근거 문장과 원문의 일치 여부를 함께 기록하면 무엇이 개선됐는지 더 분명해진다.
이때 보류 비중만 줄이는 것을 성과로 삼지 않아야 한다. 어려운 문의까지 자신 있게 배정하면서 오류가 늘 수 있다. 반대로 모든 문의를 사람에게 넘기는 모델도 자동화 목적을 충족하지 못한다. 어느 범위의 문의를 맡겼을 때 오류와 검토 부담이 감당할 만한지를 정하는 것이 평가의 역할이다.
작은 모델의 경제성은 운영에서 확인된다
학생 모델을 운영할 때의 비용에는 추론 외에도 교사 호출, 사례 검토, 학습, 평가, 재학습이 들어간다. 문의 유형이 자주 바뀌면 기존에 만든 데이터의 유지 비용도 커진다. 따라서 건당 호출료만 비교하면 증류 프로젝트가 실제로 절약한 비용을 놓칠 수 있다.
간단한 계산부터 시작할 수 있다. 도입에 든 고정 비용을, 기존 방식과 새 방식의 건당 총비용 차이로 나누면 비용을 회수하는 데 필요한 처리량을 추정할 수 있다. 다만 새 방식의 총비용에는 사람의 재분류와 검토 시간이 포함돼야 한다. 품질 기준을 충족하지 못했거나 건당 차이가 양수가 아니라면, 처리량을 늘리는 것만으로 도입의 근거를 만들 수 없다. 이는 가격 예측이 아니라 실측값을 넣기 위한 계산 틀이다.
응답 속도 역시 실제 요청으로 재야 한다. 모델의 크기와 함께 입력 길이, 생성 길이, 동시에 처리하는 요청 수, 사용 장비를 기록한다. 짧은 부서명 하나를 얻으려는 업무라면 긴 설명을 생성하는 설정이 필요한지도 확인할 수 있다. “작다”는 표현만으로 사용자가 기다리는 시간을 알 수는 없다.
데이터의 버전 관리도 배포 뒤에 남는다. 분류 기준이 바뀌었는데 과거 답변으로 학습한 모델을 계속 쓰면, 일관되게 낡은 결과를 낼 수 있다. 학습 표본에 적용한 기준과 현재 기준을 대조하고, 변경된 문의 유형부터 재평가하는 담당자를 정해야 한다. 문서의 수명을 관리하는 일은 증류 데이터에도 이어진다.
증류를 검토하는 팀이 먼저 완성할 것은 학습 명령보다 맡길 업무의 설명이다. 어느 입력에서 어떤 결과를 기대하고, 무엇을 근거로 채택하며, 언제 사람에게 돌려보낼 것인지 정리해야 한다. 그 설명이 있어야 작은 모델이 배운 능력과 아직 맡기기 어려운 일을 같은 기준으로 볼 수 있다.