MLOPS / 90번째 글

과제 특화 증류 — 큰 모델의 답을 작은 모델에 옮긴다

범용 성능이 아니라 우리 과제 하나만 잘하는 작은 모델을 만드는 방법입니다. 교사에게 무엇을 받아야 하는지, 데이터를 어떻게 모으고 거르는지, 손익 분기가 어디인지를 정리합니다.

PALDYN Team2026.09.0315 MIN READ

지난 글에서 학습된 모델을 잘라 작게 만드는 이야기를 했다. 마지막에 덧붙였듯이, 가지치기는 큰 모델의 구조를 억지로 줄이는 일이라 잃는 것이 있다. 다른 길이 있다 — 작은 모델을 처음부터 따로 두고, 큰 모델이 내놓은 답을 보고 배우게 하는 것이다. 이것을 증류(distillation)라 부르고, 큰 쪽을 교사, 작은 쪽을 학생이라 부른다.

여기서 다룰 것은 그중에서도 과제 특화 증류다. 교사의 범용 능력을 통째로 옮기려는 것이 아니라, 우리 서비스가 실제로 하는 일 하나만 골라 그것만 잘하는 작은 모델을 만든다. 이 구분이 중요한 이유는 목표가 훨씬 현실적이기 때문이다. 프런티어 모델의 전 영역을 7B 모델에 담는 것은 안 되지만, "고객 문의를 12개 유형 중 하나로 분류하기"를 담는 것은 잘 된다.

파이프라인은 단순하다

절차 자체는 복잡하지 않다. 어려운 것은 각 단계에서 무엇을 챙기느냐다.

과제 특화 증류의 네 단계

이 그림에서 눈여겨볼 것은 교사의 가중치가 등장하지 않는다는 점이다. 교사 모델의 내부를 열어 볼 필요가 없고, API로만 접근 가능한 상용 모델도 교사가 될 수 있다. 필요한 것은 우리 입력에 대한 교사의 출력뿐이다.

다만 그렇기 때문에 이용 약관을 먼저 확인해야 한다. 어떤 제공자는 자사 모델의 출력으로 경쟁 모델을 학습시키는 것을 명시적으로 금지한다. 조건이 제공자마다 다르고 시기에 따라 바뀌므로, 시작하기 전에 지금 시점의 약관을 직접 읽는다.

무엇을 입력으로 쓸 것인가

첫 칸이 결과의 절반을 정하는데도 가장 대충 넘어가는 자리다.

가장 좋은 것은 실제 서비스 트래픽이다. 우리 사용자가 실제로 보내는 문장의 분포를 그대로 갖고 있기 때문이다. 공개 데이터셋이나 모델에게 생성시킨 예문으로 시작하면, 학생이 배운 분포와 배포된 뒤 마주치는 분포가 어긋난다. 앞서 드리프트를 다룬 글에서 말한 문제를 시작부터 안고 가는 셈이다.

실제 트래픽을 쓸 수 없거나 양이 모자란 경우에는 생성으로 보충하는데, 이때 요령이 있다.

실제 입력 몇십 건을 예시로 주고 비슷한 것을 만들게 한다. 아무 조건 없이 만들라고 하면 교과서 같은 문장만 나온다
모자란 구간을 지목해 채운다. 전체를 균등하게 늘리는 것보다, 실제 데이터에서 드물지만 중요한 유형을 집어 그것만 늘리는 편이 효과가 크다
일부러 어렵고 지저분한 것을 넣는다. 오타, 중간에 끊긴 문장, 두 가지를 한꺼번에 묻는 질문. 실제 트래픽에는 이런 것이 늘 있다

그리고 입력을 모을 때 중복을 제거한다. 실제 트래픽에는 거의 같은 문장이 대량으로 반복되는데, 그것을 그대로 학습에 넣으면 흔한 유형에만 과하게 맞춰진다.

교사에게서 무엇을 받을 것인가

답만 받아도 학습은 된다. 하지만 답보다 많이 받을수록 학생이 잘 배운다.

확률 분포를 통째로 받는 방식이 원래의 증류다. 분류라면 "이 문장은 3번 유형"이 아니라 "3번 62%, 7번 24%, 나머지 14%"를 받는다. 이 분포에는 "3번과 7번이 헷갈릴 만하다"는 정보가 들어 있고, 정답 하나만 받을 때보다 훨씬 풍부하다. 다만 이 방식은 교사가 확률을 내주고 교사와 학생의 어휘 집합이 같아야 쓸 수 있어서, 상용 API를 교사로 쓸 때는 대개 못 쓴다.

추론 과정을 받는 방식이 요즘 실무의 주류다. 교사에게 답만 말하게 하지 말고 왜 그렇게 판단했는지를 함께 쓰게 한 다음, 학생이 그 과정까지 따라 쓰도록 학습시킨다. 작은 모델이 한 번에 정답으로 점프하지 못하는 문제도 중간 단계를 밟으면 풀리는 경우가 많다.

여러 번 물어 다수결로 정하는 방식은 라벨 품질을 올린다. 교사를 온도를 올려 서너 번 호출하고, 답이 갈리면 그 항목은 버리거나 사람에게 보낸다. 교사도 틀린다는 사실을 다루는 가장 값싼 방법이다.

받는 것	필요 조건	효과
정답 라벨만	없음	기본선. 데이터가 아주 많으면 이것만으로도 된다
확률 분포	교사 접근 권한, 같은 어휘 집합	가장 정보량이 많지만 조건이 까다롭다
추론 과정	없음	상용 API 교사에서도 쓸 수 있고 효과가 크다
여러 번 호출한 결과	호출 비용 증가	라벨 잡음이 줄어든다

걸러 내는 단계가 성능을 정한다

증류에서 가장 과소평가되는 단계가 생성한 데이터를 거르는 일이다. 교사가 만든 것이라고 다 옳지 않다. 그리고 틀린 라벨 하나는 옳은 라벨 하나보다 훨씬 크게 해를 끼친다.

거를 수 있는 방법이 몇 가지 있다.

형식 검증 — 정해진 유형 목록 밖의 값, 깨진 JSON, 길이가 비정상인 출력을 버린다. 가장 싸고 가장 많이 걸러진다
자기 일관성 — 같은 입력을 여러 번 물었을 때 답이 갈리는 항목을 뺀다. 교사가 헷갈리는 것을 학생에게 시킬 이유가 없다
검증 가능한 것은 검증한다 — 코드라면 실행해 보고, 계산이라면 다시 계산해 보고, 추출이라면 원문에 실제로 있는지 확인한다. 가능한 과제라면 이것이 압도적으로 효과가 좋다
사람 표본 검사 — 200건쯤 뽑아 직접 본다. 전수 검사는 못 해도 이 표본에서 오류율이 나오면 나머지의 상태를 짐작할 수 있다

4번을 건너뛰면 안 된다. 오류율이 3%인 데이터셋과 25%인 데이터셋은 학습 결과가 완전히 다른데, 표본을 안 보면 그 차이를 모른 채로 진행하게 된다.

학생을 어디서 고를 것인가

학생 모델은 작을수록 좋지만, 너무 작으면 아무리 가르쳐도 안 된다. 실용적인 접근은 여러 크기로 같은 데이터를 돌려 보는 것이다. 데이터를 한 번 만들어 두면 학생을 바꿔 다시 학습시키는 비용은 크지 않다.

그리고 학생의 출발점을 지시 학습이 끝난 모델로 잡는다. 사전학습만 된 기반 모델에서 시작하면 지시를 따르는 능력부터 가르쳐야 해서 훨씬 많은 데이터가 필요하다.

평가에서 자주 저지르는 실수가 하나 있다. 학생을 교사와만 비교하는 것이다. 실제로 필요한 비교는 셋이다.

교사 대비 — 얼마나 따라잡았는가
같은 크기의 원본 모델 대비 — 증류가 실제로 뭔가를 더했는가
기존 운영 방식 대비 — 규칙 기반이든 기존 모델이든, 지금 돌고 있는 것보다 나은가

두 번째가 특히 중요하다. 같은 크기의 모델을 그냥 프롬프트로 썼을 때와 성능이 비슷하다면 증류 파이프라인 전체가 헛돈 것이다.

언제 할 만한가

증류는 공짜가 아니다. 데이터를 만드는 교사 호출 비용, 학습 비용, 그리고 새 모델을 서빙하는 운영 비용이 든다. 이것이 회수되려면 호출량이 있어야 한다.

호출량에 따른 누적 비용

그림의 값은 예시지만 모양은 일반적이다. 초기 비용이 고정으로 먼저 나가고, 호출당 비용의 차이가 그것을 갚아 나간다. 그래서 호출량이 적은 기능에 증류를 하면 순손해다.

정리하면 이런 자리에서 할 만하다.

할 만한 조건	왜
과제가 하나로 좁고 안 바뀐다	좁을수록 작은 모델에 담긴다. 자주 바뀌면 매번 다시 만들어야 한다
호출량이 많다	고정비를 갚을 수 있다
지연이 중요하다	작은 모델은 응답이 빠르다. 비용과 무관하게 이것만으로 값어치가 있는 경우가 있다
데이터를 밖으로 못 내보낸다	사내에서 도는 작은 모델이 유일한 답인 경우
출력 형식이 엄격하다	좁은 형식을 반복하는 일은 작은 모델이 특히 잘 배운다

반대로 과제가 계속 바뀌거나 범위가 넓으면 하지 않는 편이 낫다. 프롬프트 한 줄로 대응하던 변경이 데이터 재생성과 재학습으로 바뀐다. 그 유지 비용이 절감액을 넘는 경우가 실제로 흔하다.

그리고 증류한 학생을 배포할 때는 교사로 되돌아갈 길을 남긴다. 학생이 자신 없어 하는 입력이나 형식 검증에 걸린 출력은 교사로 넘기는 구성이면, 비용의 대부분을 아끼면서 품질의 하한을 교사 수준으로 잡을 수 있다. 전부를 학생에게 맡기는 것보다 이 절충이 대개 낫다.