모델 운영

MLOPS / 83번째 글

지속 학습 — 모델을 한 번이 아니라 계속 고쳐 나갈 때

미세조정을 6주에 한 번씩 반복하면 한 번 할 때는 없던 문제가 생깁니다. 이어 붙이기와 다시 만들기의 차이, 데이터를 쌓는 방식, 고리를 도는 주기, 그리고 기준선 자체가 낡는 문제를 정리합니다.

PALDYN Team14 MIN READ

지난 글까지가 미세조정 한 번을 제대로 마치는 이야기였다. 실제 서비스에서 이 일은 한 번으로 끝나지 않는다. 새 상품이 나오고, 문의 유형이 바뀌고, 지난달에 고친 실패 유형이 다시 다른 모습으로 온다. 6주 뒤에 또 학습을 돌리게 된다.

두 번째부터는 첫 번째에 없던 질문들이 생긴다. 직전 모델에 이어 붙일 것인가, 베이스에서 다시 만들 것인가. 예전 데이터는 언제까지 들고 갈 것인가. 그리고 이번 모델이 지난번보다 나아졌다는 것을 무엇으로 말할 것인가 — 지난번 모델을 재던 그 기준이 아직 유효하기는 한가.

이어 붙일 것인가, 다시 만들 것인가

갈림길은 여기 하나다. 새 데이터를 직전에 배포한 모델 위에 학습시킬 것인가, 아니면 매번 원래 베이스에서 누적 데이터로 다시 학습시킬 것인가.

이어 붙이면 싸지만 베이스에서 계속 멀어진다

이어 붙이기 다시 만들기
학습 비용 새 데이터만큼만 갱신할 때마다 전체 데이터
소요 시간 수십 분 회차가 늘수록 길어진다
재현성 이전 모델 전부가 있어야 재현된다 베이스와 데이터셋만 있으면 된다
망각 회차마다 쌓인다 매번 초기화된다
실수의 수명 다음 회차로 이어진다 그 회차에서 끝난다

마지막 두 줄이 실무에서 가장 아프다. 파국적 망각은 한 번의 학습에서는 작은 하락이지만, 이어 붙이면 그 하락이 회차마다 더해진다. 여섯 번 갱신한 모델은 베이스에서 꽤 멀리 가 있는데, 각 회차의 보존 점수 하락은 매번 「허용 범위 안」이었을 수 있다. 한 걸음씩은 괜찮았는데 여섯 걸음을 합치면 안 괜찮은 것이다.

실수의 수명도 같은 구조다. 3회차 데이터에 라벨 오류가 섞였다면, 이어 붙이기에서는 4·5·6회차 모델이 전부 그 오류를 물려받는다. 되돌리려면 3회차 이전으로 가서 다시 쌓아야 한다.

그래서 기본값은 다시 만들기로 두는 편이 낫다. 데이터셋 하나와 베이스 하나로 어느 회차든 재현할 수 있고, 잘못된 회차는 그 데이터를 빼고 다시 돌리면 끝난다. 이어 붙이기는 전체 재학습이 현실적으로 불가능할 만큼 데이터가 커졌을 때 꺼내는 카드다.

절충안도 있다. 이어 붙이되 주기적으로 베이스에서 다시 만들어 기준을 되돌리는 것이다. 여섯 회차는 이어 붙이고 일곱 번째는 전체 재학습을 하는 식으로, 쌓인 드리프트를 정기적으로 청산한다.

데이터를 어떻게 쌓을 것인가

다시 만들기를 고르면 다음 질문은 「누적 데이터가 정확히 무엇인가」다. 회차가 쌓일수록 예전 데이터는 양은 많고 관련성은 낮아진다.

방식 내용 맞는 자리
전체 누적 1회차부터 전부 과제가 안정적이고 예전 사례가 여전히 유효할 때
슬라이딩 창 최근 N개월치만 상품·정책이 자주 바뀌어 옛 정답이 틀린 것이 될 때
누적 + 표본 최근 것은 전부, 옛것은 표본만 대부분의 경우

세 번째가 무난한 기본값이다. 최근 3개월은 전부 넣고 그 이전은 10~20%만 표본으로 남기면, 데이터 크기를 묶어 두면서 예전 분포도 어느 정도 붙잡는다.

옛 데이터를 버리는 결정에는 함정이 하나 있다. 「최근 3개월에 안 나온 유형」이 정말 사라진 것인지, 아니면 그 유형을 잘 처리해서 신고가 안 올라온 것인지 구별해야 한다. 후자를 버리면 다음 회차에서 그 유형이 도로 무너지고, 그때는 원인이 데이터에서 뭘 뺐기 때문이라는 것을 아무도 떠올리지 못한다. 회귀 테스트에 남겨 둔 문제들이 이 구별을 대신해 준다 — 데이터에서 빠져도 평가에는 남아 있으므로 무너지면 바로 잡힌다.

그리고 회차마다 데이터가 겹친다. 같은 문의가 두 회차의 로그에 모두 들어 있으면 그 사례만 두 번 학습된다. 문서 해시나 사례 ID로 중복을 걷어내는 단계를 파이프라인에 넣어 둔다.

고리를 도는 주기

지속 학습을 그림으로 그리면 직선이 아니라 고리다. 그리고 이 고리가 한 바퀴 도는 데 걸리는 시간이 곧 이 시스템이 세상의 변화를 따라잡는 속도다.

지속 학습은 한 번의 학습이 아니라 도는 고리다

한 바퀴가 두 주면, 우리는 늘 두 주 전 세상에 맞춰진 모델을 쓰고 있는 셈이다. 그것이 문제가 되는지는 도메인이 정한다 — 사내 문서 질의응답이면 두 주는 아무렇지도 않고, 시세나 재고를 다루면 두 주는 재앙이다.

주기를 줄이려 할 때 먼저 볼 곳은 학습 시간이 아니다. 실제로 고리에서 가장 긴 구간은 대개 데이터 선별과 사람 검수다. 학습이 40분인데 라벨 검수가 5일이면, GPU를 두 배로 늘려도 고리는 거의 그대로다.

여기서 중요한 판단이 하나 있다. 주기를 줄이는 것과 각 회차의 검증을 줄이는 것은 다르다. 자동화로 검수 시간을 줄이는 것은 고리를 빠르게 하지만, 검수를 건너뛰는 것은 고리를 빠르게 하면서 실수의 확률을 올린다. 지속 학습에서 실수는 한 회차로 끝나지 않으므로 이 거래는 대개 손해다.

그래서 고리에서 사람이 남아야 하는 자리를 미리 정해 둔다. 대체로 이 둘이다 — 새로 들어오는 학습 데이터의 표본 검수와 배포 직전의 최종 판단. 나머지는 자동으로 돌린다.

기준선이 같이 낡는다

지속 학습에서 가장 늦게 발견되는 문제는 모델이 아니라 평가에 있다.

골든셋은 만든 시점의 실사용 분포를 반영한다. 그런데 지속 학습을 하는 이유가 바로 그 분포가 변하기 때문이다. 여섯 달 전 골든셋으로 지금 모델을 재면, 지금은 거의 오지 않는 유형에서의 성능을 재고 있는 것이다. 점수는 계속 오르는데 실사용 만족도는 그대로인 상태가 여기서 나온다.

그렇다고 골든셋을 매번 갈아 끼우면 회차 간 비교가 불가능해진다. 3회차 82점과 6회차 85점이 서로 다른 시험지의 점수이면 3점은 아무 뜻이 없다.

두 요구가 충돌하므로 세트를 나눈다.

  • 고정 세트 — 처음 만든 뒤 바꾸지 않는다. 회차 간 비교와 회귀 확인이 여기서 나온다. 여기 점수가 떨어지면 무조건 멈춘다
  • 현행 세트 — 매 회차 최근 로그에서 새로 뽑는다. 지금 분포에서 얼마나 잘하는지가 여기서 나온다. 회차 간 비교에는 쓰지 않는다

두 숫자를 나란히 보면 해석이 갈린다. 고정은 유지되는데 현행이 낮으면 분포가 옮겨 간 것이고, 현행은 좋은데 고정이 떨어지면 새 데이터에 과적합된 것이다. 하나만 보면 이 구별이 안 된다.

여기에 하나를 더 얹으면 좋다. 매 회차 골든셋에 몇 문제를 추가하되 빼지는 않는 것이다. 세트가 서서히 커지면서 회차 간 비교 가능성은 유지된다. 다만 이렇게 하면 과거에 추가된 문제들의 비중이 계속 커지므로, 두 해쯤 지나면 한 번 정리할 시점이 온다.

언제 하지 말아야 하나

지속 학습은 운영 부담이 상당한 구조다. 다음 경우에는 안 하는 편이 낫다.

  • 바뀌는 것이 지식뿐일 때. 새 상품 정보나 바뀐 정책은 검색으로 넣는 것이 맞다. 사실을 가중치에 굽는 것은 갱신 주기가 며칠인 정보에는 최악의 저장 방식이다
  • 회차마다 데이터가 수백 건뿐일 때. 학습으로 움직이기에는 너무 적고, 그 정도면 프롬프트나 예시로 넣는 편이 빠르다
  • 평가가 자동화되지 않았을 때. 매 회차 사람이 눈으로 훑어야 한다면 고리가 돌지 않는다. 지속 학습을 시작하기 전에 평가 자동화가 먼저다

특히 첫 번째가 흔하다. 「모델이 새 요금제를 모른다」는 미세조정 문제가 아니라 검색 문제다. 미세조정이 바꾸는 것은 어떻게 답하는가이고, 무엇을 아는가는 검색이 대는 편이 싸고 빠르고 되돌리기 쉽다.

정리

지속 학습은 미세조정을 여러 번 하는 것이 아니라, 회차 사이를 잇는 규칙을 정해 두는 일이다. 그 규칙이 없으면 회차가 쌓일수록 상태를 아는 사람이 줄어든다.

  • 기본값은 베이스에서 다시 만들기다. 이어 붙이기는 망각과 실수를 다음 회차로 물려준다
  • 데이터는 최근 것 전부 + 옛것 표본이 무난하다. 다만 「안 나오는 유형」과 「잘 처리해서 안 보이는 유형」을 구별해야 한다
  • 고리의 병목은 대개 학습이 아니라 데이터 선별과 검수다. 줄일 곳은 거기지 검증이 아니다
  • 골든셋도 같이 낡는다. 고정 세트와 현행 세트를 나눠 두면 분포 이동과 과적합이 구별된다

읽어주셔서 감사합니다. 😊

LATEST

모델 운영의 최신 글

모델 운영2026.09.04

KV 캐시 양자화 — 가중치보다 이쪽이 먼저 넘친다

긴 문맥에서 GPU 메모리를 실제로 잡아먹는 것은 가중치가 아니라 KV 캐시입니다. 캐시 크기를 계산하는 법, K와 V를 다르게 다뤄야 하는 이유, 어디까지 줄여도 되는지를 정리합니다.

16 MIN
모델 운영2026.09.04

양자화 보정 — 데이터 128개가 모델 품질을 정한다

양자화에서 스케일을 정하는 절차가 보정입니다. 무엇을 재는지, 데이터를 어디서 몇 개 뽑아야 하는지, 자르는 지점을 어떻게 고르는지, 그리고 잘못된 보정이 어떤 모양으로 드러나는지를 정리합니다.

21 MIN
모델 운영2026.09.03

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

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

15 MIN