운영 환경에서의 모니터링과 지속 개선

출시는 끝이 아니라 관찰의 시작이다

LLM 서비스는 배포한 순간부터 새로운 데이터가 쌓인다. 사용자는 우리가 예상하지 못한 질문을 하고, 모델은 특정 상황에서 반복적으로 실패한다. 그래서 운영의 핵심은 "모델이 잘 돌아가는가"를 막연히 보는 것이 아니라, 어떤 조건에서 실패하는지 계속 기록하고 개선하는 것이다.

파인튜닝된 모델도 완성품이 아니다. 학습 데이터는 과거의 문제를 반영할 뿐이고, 실제 서비스에는 새로운 표현, 새로운 업무 규칙, 새로운 예외 상황이 계속 들어온다. 좋은 운영 체계는 이 변화를 감지해 다시 데이터로 만들고, 평가하고, 다음 모델에 반영한다.

무엇을 모니터링할 것인가

운영 지표는 크게 품질, 안전, 성능, 비용으로 나눌 수 있다.

품질 지표는 응답 실패율, 무응답률, 지시 불이행률, 형식 오류율을 포함한다. 예를 들어 JSON 형식으로 답해야 하는 모델이 자주 일반 문장으로 답한다면, 이는 서비스 장애에 가깝다. RAG를 함께 쓰는 경우에는 검색 문서를 제대로 활용했는지, 출처와 답변이 맞는지도 확인해야 한다.

안전 지표는 환각, 금칙어, 개인정보 노출, 정책 위반 응답을 추적한다. 환각은 단순히 틀린 답변이 아니라 사용자가 믿고 행동할 수 있는 위험한 오류다. 따라서 "모름"이라고 답해야 할 상황에서 그럴듯한 답을 지어내는 비율을 별도로 봐야 한다.

성능 지표는 지연시간, 타임아웃, 토큰 생성 속도, 동시 요청 처리량이다. 모델이 정확해도 응답이 너무 늦으면 사용자는 이탈한다. 비용 지표도 중요하다. 요청당 입력 토큰, 출력 토큰, GPU 사용량, 캐시 적중률을 보면 어떤 기능이 비용을 많이 쓰는지 파악할 수 있다.

사용자 피드백을 학습 데이터로 바꾸기

사용자 피드백은 그대로 학습 데이터가 되지 않는다. "별로예요"라는 평가는 개선의 단서일 뿐, 무엇이 틀렸는지 알려주지는 않는다. 따라서 피드백은 수집, 분류, 검수, 승인 단계를 거쳐야 한다.

먼저 사용자의 질문, 모델 응답, 참고 문서, 선택한 피드백, 세션 맥락을 함께 저장한다. 단, 개인정보나 민감정보는 저장 전에 마스킹하거나 제외해야 한다. 다음으로 실패 유형을 붙인다. 예를 들어 사실 오류, 형식 오류, 과도한 거절, 부족한 설명, 업무 규칙 위반처럼 분류한다.

그다음 사람이 검수해 올바른 답변을 작성하거나, 기존 응답 중 더 나은 답변을 선택한다. 이때 중요한 것은 한 번의 불만을 그대로 반영하지 않는 것이다. 자주 반복되는 실패인지, 특정 고객의 특수한 요구인지, 정책상 반영해도 되는지 확인해야 한다. 최종 승인된 데이터만 재학습 후보 데이터셋에 들어간다.

LLMOps로 개선 과정을 남기기

지속 개선에는 기록이 필요하다. 어떤 모델을 어떤 데이터로 학습했는지, 어떤 설정을 썼는지, 평가 결과가 어땠는지 남기지 않으면 성능이 좋아져도 이유를 알 수 없고, 나빠져도 되돌리기 어렵다.

LLMOps는 LLM 운영을 위한 관리 체계다. 기본 구성은 세 가지다. 첫째, 모델 버전 관리다. 베이스 모델, 파인튜닝 어댑터, 프롬프트, 추론 설정을 함께 버전으로 묶어야 한다. 둘째, 데이터 버전 관리다. 학습 데이터, 평가셋, 제외된 데이터, 검수 기준을 남겨야 한다. 셋째, 실험 추적이다. 학습률, 에폭, LoRA 설정, 평가 점수, 비용, 실패 사례를 한곳에서 비교할 수 있어야 한다.

이 기록은 감사나 보고를 위한 문서가 아니다. 다음 실험을 더 작고 정확하게 만들기 위한 도구다.

A/B 테스트와 롤백 전략

새 모델이 오프라인 평가에서 좋아 보여도 바로 전체 사용자에게 배포하면 위험하다. 평가셋에 없던 질문에서 실패할 수 있고, 특정 기능에서 지연시간이 늘어날 수도 있다.

안전한 방법은 일부 트래픽에만 새 모델을 적용하는 것이다. 예를 들어 5% 사용자에게 새 모델을 노출하고, 기존 모델과 응답 품질, 오류율, 비용, 지연시간, 사용자 만족도를 비교한다. 중요한 기능이라면 내부 사용자나 특정 고객군부터 시작하는 단계적 배포가 좋다.

롤백 기준도 미리 정해야 한다. 환각 신고가 일정 비율을 넘거나, 평균 지연시간이 기준을 초과하거나, 금칙어 응답이 발생하면 자동으로 이전 모델로 되돌릴 수 있어야 한다. 롤백은 실패가 아니라 운영 안정성을 지키는 장치다.

개선 루프를 작게 유지하기

지속 개선은 거대한 재학습 프로젝트가 아니다. 운영 로그에서 반복 실패를 찾고, 원인을 분류하고, 작은 데이터셋으로 보강한 뒤, 평가하고, 제한적으로 배포하는 과정의 반복이다.

좋은 LLM 서비스는 한 번에 완벽해지지 않는다. 사용자와 만나는 과정에서 더 정확해지고, 더 안전해지고, 더 빠르고 저렴해진다. 출시 이후의 데이터 흐름을 설계한 팀만이 파인튜닝의 효과를 오래 유지할 수 있다.