LLMOps

LLMOps이란?

LLMOps가 실제로 바꾸는 것은 배포 기준입니다. 일반 소프트웨어는 테스트가 통과하면 내보내지만, LLM 서비스는 같은 질문에도 출력이 매번 달라져 통과·실패가 아니라 점수로 판정해야 합니다. 그래서 릴리스 게이트가 '빌드 성공'에서 '평가셋 점수가 직전 버전보다 떨어지지 않음'으로 옮겨가고, 형상 관리 대상도 프롬프트·검색 설정·모델 버전의 조합으로 확장됩니다. 코드는 그대로인데 서비스 품질만 달라지는 상황을 다루는 일이기 때문입니다.

평가는 한 덩어리로 만들지 말고 세 층으로 쌓는 편이 현실적입니다. JSON 형식 준수나 금칙어처럼 기계가 판정할 수 있는 항목은 전수 검사로, 어조나 근거 인용 여부처럼 애매한 항목은 LLM 채점으로, 최종 품질은 사람이 표본만 봅니다. 아래로 갈수록 정확하지만 비싸기 때문입니다. 평가셋은 처음부터 클 필요가 없어서, 실제로 클레임이 났던 실패 사례 50~100건이면 회귀 테스트로 충분히 작동합니다. 출력이 비결정적이라 같은 입력을 3~5회 반복 실행해 평균과 편차를 함께 봐야 한 번의 운을 실력으로 착각하지 않습니다.

비용과 지연도 프롬프트 관리와 같은 줄에 놓입니다. 토큰 단가 협상보다 호출 구조가 지출을 좌우해서, 문의 유형별로 소형·대형 모델을 나누는 라우팅과 반복 질문 캐싱만으로 지출이 절반 아래로 떨어지는 경우가 흔합니다. 지연은 전체 응답 시간보다 첫 글자가 나오기까지의 시간이 체감 품질을 가르므로, 스트리밍 여부와 검색 단계 지연을 따로 계측해야 병목이 보입니다.

현장에서 가장 흔한 어긋남은 평가셋 없이 도구부터 도입하는 순서입니다. 대시보드에 토큰 사용량과 지연은 예쁘게 찍히는데 '답이 맞았는지'는 아무도 못 보니, 모델 공급사가 버전을 올린 날 품질이 무너져도 고객 클레임이 올라온 뒤에야 압니다. LLM 채점기를 맹신하는 것도 위험해서, 채점 기준 자체를 사람이 주기적으로 검증하지 않으면 말만 번듯하고 사실은 틀린 답변에 높은 점수가 붙습니다. 가드레일을 프롬프트 끝의 '개인정보는 말하지 마세요' 한 줄로 대신하는 관행도 마찬가지인데, 시스템 프롬프트는 요청일 뿐 차단 장치가 아니라서 출력단 필터와 상담사 이관 규칙을 따로 두지 않으면 사고가 그대로 고객에게 나갑니다.