5장. 평가와 운영

학습 목표

• 측정 가능한 성공 기준을 정하고, 실제 분포와 경계 사례를 담은 평가 세트를 만든다.
• 기준마다 알맞은 채점 방법을 고르고, LLM 채점기를 사람 채점과 대조해 보정한다.
• 모델 버전을 고정하고, 교체 전 회귀 평가와 단계적 전환 절차를 설계한다.
• 장애 추적에 필요한 로그와 추적 정보를 남기면서 개인정보를 최소화한다.
• 운영 질문에서 출발해 지표, 평소 범위, 경보, 담당 조치를 정의한다.

들어가며

공급자가 더 빠르고 저렴한 새 모델을 발표한 날, 한 회사의 경영진은 다음 주 전환을 지시했습니다. 개발팀은 대표 질문 열 개를 넣어 보고 답이 “비슷하게 좋다”는 결론을 냈습니다. 전환 2주 뒤 고객센터에 항의가 몰렸습니다. 드물게 오는 복합 문의에서 새 모델이 핵심 조건 하나를 자주 빠뜨렸고, 이전 모델 설정에 맞춰 둔 파라미터 하나는 새 모델에서 조용히 무시되고 있었습니다. 열 개의 질문으로는 볼 수 없는 일이었습니다.

LLM 기능은 운영에 들어간 뒤에도 계속 변합니다. 모델은 확률적으로 동작하고, 공급자는 새 모델을 내고 옛 모델을 은퇴시키며, 사용자의 입력도 시간이 지나며 달라집니다. 이 장은 “잘 되는 것 같다”는 느낌 대신 숫자로 판단하는 방법을 다룹니다. 성공 기준과 평가 세트, 채점 방법과 채점기 보정, 결과 해석, 버전 고정과 교체 절차, 로그와 추적, 개인정보, 운영 지표, 기능별 비용 관리 순서로 갑니다.

핵심 개념

운영은 계기판 비행이다

구름 속을 나는 조종사는 창밖이 아니라 계기판을 봅니다. 감각은 속기 쉽고 계기는 정해진 것을 정직하게 보여 주기 때문입니다. LLM 기능도 마찬가지입니다. 몇 개의 답을 읽어 보고 내린 판단은 선택 편향에 휘둘리고, 드문 실패를 놓칩니다. 운영의 계기판은 두 종류입니다. 변경 전에 돌리는 오프라인 평가와, 운영 중 계속 보는 지표입니다. 둘 다 같은 성공 기준에서 출발해야 서로 비교할 수 있습니다.

성공 기준부터 정한다

Anthropic 문서는 좋은 성공 기준의 조건으로 구체적일 것, 측정 가능할 것, 달성 가능할 것, 목적과 관련될 것을 듭니다. “성능이 좋아야 한다” 대신 “문의 분류 정확도”처럼 대상을 좁히고, 정량 지표나 잘 정의된 척도로 잽니다. 대부분의 기능은 여러 차원을 함께 봐야 합니다.

기준마다 합격선을 미리 적습니다. 결과를 본 뒤에 합격선을 정하면 원하는 결론에 숫자를 맞추게 됩니다.

평가 세트를 만든다

평가 세트는 운영 기능의 회귀 테스트입니다. 고정된 입력, 기대 결과(또는 채점 기준), 채점 방법의 묶음입니다.

1. 실제 분포를 반영한다. 운영 로그에서 표본을 뽑아 업무 유형, 길이, 언어의 비율을 맞춘다. 개인정보는 뒤에 다룰 방법으로 먼저 처리한다.
2. 경계 사례를 넣는다. Anthropic 문서는 관련 없거나 존재하지 않는 입력, 지나치게 긴 입력, 유해한 입력, 모호한 입력을 예로 든다. 여기에 우리 업무의 고위험 구간(금액이 큰 건, 위기 신호가 있는 상담)을 더한다.
3. 실패 비용으로 가중한다. 드물지만 피해가 큰 구간은 표본을 늘리고 따로 집계한다.
4. 개발용과 검증용을 나눈다. 프롬프트를 고치며 계속 보는 입력과, 최종 판단에만 쓰는 입력을 분리해야 평가 세트에 과적합하지 않는다.
5. 버전을 관리한다. 입력, 기대 결과, 채점 코드를 저장소에 함께 두고 바꿀 때마다 기록한다.

Anthropic 문서는 사람이 공들여 채점한 소수 문항보다 자동 채점이 가능한 다수 문항이 낫다고 권합니다. 규모가 있어야 작은 회귀도 보입니다.

채점 방법을 고른다

채점은 가장 빠르고, 믿을 수 있고, 확장 가능한 방법부터 고릅니다. Anthropic 문서의 정리는 이렇습니다.

같은 문서는 기준별 지표의 예도 듭니다. 정답과의 정확 일치(분류), 문장 임베딩 유사도(비슷한 질문에 대한 답의 일관성), ROUGE-L(모범 요약문이 있는 세트에서 요약의 핵심 정보 포착), LLM의 1~5점 척도(말투), LLM의 이진 판정(개인정보 포함 여부)입니다. 기준 하나에 방법 하나를 짝지으면 어떤 차원이 나빠졌는지 바로 보입니다.

LLM 채점기를 보정한다

LLM 채점기는 편리하지만 그 자체가 모델이라 오류와 편향이 있습니다. 쓰기 전에 보정합니다.

1. 채점 기준표(루브릭)를 구체적으로 쓴다. “첫 문장에 조치 일정이 없으면 불합격”처럼 판정 조건을 적는다.
2. 출력을 좁힌다. “합격/불합격”이나 1~5점처럼 정해진 값만 내게 한다. 서술형 평가는 대량으로 비교하기 어렵다.
3. 점수 전에 추론하게 한다. Anthropic 문서는 사고 기능을 켠 채점 모델을 쓰면 복잡한 판단에서 채점 성능이 좋아진다고 설명한다.
4. 생성 모델과 다른 모델로 채점한다. Anthropic 문서의 예시 코드도 이를 권장 관행으로 적는다.
5. 사람 채점 표본과 대조한다. 50~100건을 사람이 채점하고 일치율을 잰다. 합격·불합격이 한쪽으로 치우친 세트라면 우연 일치를 보정한 지표(예: 코헨 카파)나 등급별 정밀도·재현율도 본다. 기준에 못 미치면 루브릭을 고친다.
6. 알려진 편향을 점검한다. 답이 길수록 점수를 후하게 주거나, 두 답을 비교할 때 먼저 나온 답을 선호하는 경향이 있는지 순서를 바꿔 확인한다.
7. 채점 모델과 루브릭의 버전을 고정한다. 채점기가 바뀌면 점수의 의미도 바뀐다.

결과를 해석한다: 변동과 구간

평가 결과를 읽을 때 흔히 세 가지를 놓칩니다.

• 변동. 같은 입력도 실행마다 결과가 다를 수 있습니다(1장). 입력 100건에서 1건은 1%p입니다. 1~2%p 차이는 우연일 수 있으므로, 같은 세트를 여러 번 돌려 흔들림의 폭을 먼저 잽니다.
• 짝지은 비교. 두 설정의 평균을 따로 비교하기보다 같은 입력끼리 결과를 맞대어, 새 설정이 이기고 진 사례를 셉니다. 진 사례를 읽어 보면 원인이 보입니다.
• 구간. 평균이 올라도 중요한 구간이 나빠질 수 있습니다. 업무 유형, 길이, 고위험 여부별로 따로 집계하고, 고위험 구간에는 별도 합격선을 둡니다.

모델 버전을 고정한다

운영 앱은 특정 모델 버전에 고정합니다. OpenAI 문서는 운영 애플리케이션을 특정 모델 스냅샷에 고정해 동작을 일관되게 유지하라고 권합니다. Anthropic 모델 목록에 따르면 4.6 세대부터는 날짜가 없는 ID를 포함해 모든 Claude 모델 ID가 고정된 스냅샷이고, 그 이전 모델의 별칭은 날짜가 붙은 ID를 가리키는 편의용 이름입니다. 모델마다 은퇴 시점(“이 날짜보다 이르지 않게”)이 공개되므로, 고정은 영원한 보장이 아니라 교체를 계획할 시간을 버는 장치입니다.

모델 ID만 고정해서는 결과 변화를 설명할 수 없습니다. 재현 가능한 설정 묶음으로 관리합니다.

모델 교체 전 회귀 평가

교체는 “더 좋아 보인다”가 아니라 미리 정한 기준을 넘는지로 판단합니다.

1. 기준을 먼저 적는다. 전체 합격선, 고위험 구간 합격선, 지연·비용 상한, 중단 조건과 책임자.
2. 같은 평가 세트로 기존 설정과 후보를 비교한다. 검증용 세트를 쓰고, 짝지은 비교로 진 사례를 읽는다.
3. 파라미터를 다시 맞춘다. 이전 설정을 그대로 옮기지 않는다. 추론 강도는 평가 세트로 다시 재고, 새 모델이 거부하거나 무시하는 설정(샘플링 파라미터, 프리필, 강제 도구 선택)을 찾아 지운다. 토큰 수도 새 모델로 다시 센다.
4. 그림자 실행을 한다. 운영 트래픽 일부를 후보에도 보내되 결과는 사용자에게 보여 주지 않고 비교만 한다. 변경 작업이 있는 도구는 실행하지 않는다.
5. 단계적으로 전환한다. 일부 트래픽부터 옮기고 지표를 지켜본다. 중단 조건에 닿으면 즉시 되돌린다.
6. 기록을 남긴다. 비교 결과, 결정, 설정 묶음을 저장해 다음 교체의 기준으로 쓴다. 평가 실행을 배포 파이프라인에 넣어 합격선 미달이면 배포를 막는 관문으로 쓰면 프롬프트 수정 때도 같은 절차가 지켜진다.

로그와 추적

장애를 조사하려면 특정 요청을 다시 찾을 수 있어야 합니다. Claude API는 모든 응답에 고유한 request-id 헤더를 주고, 오류 본문에도 request_id를 담으며, Python과 TypeScript SDK에서는 응답 객체의 _request_id로 읽을 수 있습니다. 공급자에 문의할 때 이 ID가 필요합니다.

사용자 요청 하나가 모델 호출 여러 번과 도구 실행으로 이어진다면 호출별 로그만으로는 흐름이 보이지 않습니다. 업무 하나에 추적 ID(trace ID)를 붙이고, 모델 호출과 도구 실행을 각각 하위 구간(span)으로 기록합니다. OpenTelemetry 같은 분산 추적 표준과 생성형 AI용 규약을 쓰면 도구 사이에서 형식을 맞추기 쉽습니다.

원문 프롬프트와 응답은 기본으로 남기지 않습니다. 필요하면 짧은 보관 기간, 접근 통제, 마스킹을 함께 정합니다.

개인정보를 다룬다

개인정보는 사용자의 입력에서 시작해 공급자 전송, 로그, 평가 세트, 배치 파일, 캐시까지 여러 곳으로 복제됩니다. 이름 하나를 가리는 것으로는 부족하고, 흐름 전체를 관리해야 합니다.

법의 원칙. 「개인정보 보호법」(2026년 9월 11일 시행) 제3조는 처리 목적에 필요한 범위에서 최소한의 개인정보만 수집하고, 사생활 침해를 최소화하며, 익명처리로 목적을 이룰 수 있으면 익명으로, 그럴 수 없으면 가명으로 처리하도록 정합니다. 제2조는 가명처리를 개인정보의 일부를 삭제하거나 대체해 추가 정보 없이는 특정 개인을 알아볼 수 없게 하는 처리로 정의합니다. 건강 정보 같은 민감정보는 제23조에 따라 별도 동의 등 예외에 해당할 때만 처리할 수 있습니다. 제26조는 개인정보 처리 업무를 위탁할 때 문서로 하고 위탁 업무와 수탁자를 공개하도록 하며, 제28조의8은 국외로 제공·처리위탁·보관하려면 법이 정한 요건 중 하나를 갖추도록 합니다. 별도 동의가 대표적이고, 계약 이행에 필요한 처리위탁·보관은 이전 사항을 처리방침에 공개하거나 알리는 방법도 있습니다(제1항 제3호). 제29조는 내부 관리계획과 접속기록 보관 같은 안전조치를 요구합니다. 실제 적용은 개인정보 담당자·법무와 함께 확인합니다.

공급자 쪽 보관. 정책은 공급자와 계약마다 다르므로 문서로 확인합니다.

사용자 식별자. 남용 탐지를 위해 사용자 식별자를 보낼 때는 불투명한 값을 씁니다. Anthropic은 metadata.user_id에 이름, 이메일, 전화번호를 넣지 말고 UUID나 해시를 쓰라고 하며, OpenAI는 사용자명이나 이메일을 해시한 safety_identifier를 권합니다. 정책 위반이 생겼을 때 조직 전체가 아니라 해당 사용자로 추적할 수 있게 해 줍니다.

운영 지표를 정의한다

지표는 모으는 데서 끝나면 장애가 끝난 뒤에야 열어 보는 기록장이 됩니다. 운영 질문에서 출발해 지표, 평소 범위, 경보, 담당 조치를 한 줄로 묶습니다.

기술 지표(오류율, 지연)와 업무 지표(자동 처리율, 사람 수정률)를 함께 둡니다. 응답이 모두 200이고 빨라도 사람이 매번 고쳐 쓴다면 기능은 실패한 것입니다.

기능별로 비용과 한도를 나눈다

여러 기능이 한 계정을 함께 쓰면, 한 기능의 폭주가 다른 기능을 멈추게 하고 청구서만으로는 원인을 알 수 없습니다. 공급자의 분리 단위를 씁니다. Anthropic은 워크스페이스마다 지출 한도와 레이트 리밋을 조직 한도보다 낮게 정할 수 있게 합니다(기본 워크스페이스에는 설정할 수 없고, 조직 한도는 항상 적용). 응답의 anthropic-workspace-id 헤더로 어느 워크스페이스에 집계됐는지 확인할 수 있습니다. OpenAI는 조직과 프로젝트 단위로 레이트 리밋을 둡니다. 여기에 로그의 기능·고객 태그를 더하면 기능별, 고객사별 원가를 계산할 수 있습니다.

깊이 읽기

평가 도구에 묶이지 않는 법

평가 데이터와 채점 기준은 회사의 자산이지만, 특정 플랫폼 안에만 두면 그 플랫폼의 수명에 묶입니다. 실제 예가 있습니다. OpenAI 문서에 따르면 OpenAI Evals 플랫폼은 2026년 10월 31일부터 기존 사용자에게 읽기 전용이 되고, 11월 30일에 종료될 예정입니다. OpenAI는 대시보드의 재사용 프롬프트 객체도 지원을 중단하고 있으며, 운영 프롬프트는 애플리케이션 코드에 저장하라고 권합니다.

교훈은 공급자를 가리지 않습니다. 평가 입력, 기대 결과, 채점 코드와 루브릭, 프롬프트, 설정 묶음을 저장소에서 버전 관리하고, 평가 실행기는 공급자 어댑터만 바꾸면 돌아가게 만듭니다. 관리형 평가 도구는 실행과 시각화에 쓰되 원본은 저장소에 둡니다. 그래야 모델을 교체하는 날, 교체 전후를 같은 기준으로 비교한 기록을 끊김 없이 남길 수 있습니다.

피드백을 평가 세트로 되돌리는 순환

운영에서 발견한 실패가 다음 평가 세트의 문항이 되어야 같은 실패가 반복되지 않습니다.

1. 신호를 모은다. 명시적 피드백(좋아요·싫어요, 신고)과 암묵적 신호(답을 다시 생성, 상담원이 초안을 대부분 고침, 바로 창을 닫음)를 기록한다.
2. 분류한다. 실패 사례를 원인별(사실 오류, 형식, 말투, 도구 오사용)로 나눈다.
3. 문항으로 만든다. 개인정보를 처리한 뒤 기대 결과를 붙여 평가 세트에 추가하고 버전을 올린다.
4. 정기적으로 돌린다. 설정을 바꾸지 않아도 주기적으로 평가를 돌리면 입력 분포 변화나 예상치 못한 동작 변화를 일찍 알아챌 수 있다.

실무 장면

해담복지재단: 평균은 올랐는데 놓친 것이 늘었다

사회복지 법인 ‘해담복지재단’은 상담원이 쓴 상담일지를 요약하고 위기 징후(자해 언급, 학대 의심, 급박한 생계 위기)를 표시하는 기능을 운영한다. 비용을 줄이려 더 저렴한 모델로 교체를 검토했고, 정보시스템 담당 염 팀장이 회귀 평가를 맡았다.

평가 세트는 지난 반년 일지에서 뽑은 320건이었다. 가명처리를 거쳤고, 위기 징후가 있는 일지 70건을 일부러 많이 넣었다. 요약 품질은 LLM 채점기가 1~5점으로, 위기 징후 표시는 사회복지사가 붙인 정답과 코드로 비교했다. 채점기는 후보와 다른 모델을 썼고, 사회복지사 두 명이 채점한 60건과 대조해 일치율 0.86을 확인한 뒤에 썼다.

결과는 엇갈렸다. 요약 품질 평균은 4.1점에서 4.3점으로 올랐지만, 위기 징후 재현율은 96%에서 88%로 떨어졌다. 짝지은 비교로 놓친 사례를 읽어 보니 새 모델은 돌려 말한 표현(“요즘 다 내려놓고 싶다”)을 자주 놓쳤다. 미리 정한 고위험 구간 합격선은 95%였다.

염 팀장은 전면 교체를 보류하고 두 갈래를 제안했다. 위기 징후 판정은 기존 모델에 남기고, 요약 생성만 새 모델로 옮긴다. 그리고 놓친 표현 유형을 평가 세트에 추가해 다음 후보 평가에 쓴다. 평균 점수만 보고 교체하자는 의견과, 채점기 점수만으로 판단하자는 의견은 모두 기각됐다. 부분 전환으로 비용은 35% 줄었고 위기 징후 재현율은 그대로 유지됐다.

고운빨래: 수거 메모에 적힌 현관 비밀번호

세탁 수거 앱 ‘고운빨래’는 고객이 남긴 수거 메모를 요약해 기사에게 전달하고 요청 유형을 분류한다. 보안 점검에서 문제가 드러났다. 고객들이 메모에 현관 비밀번호와 연락처를 적고 있었고, 그 원문이 애플리케이션 로그에 90일, 평가 세트 CSV에 무기한 남아 있었다. 평가 세트는 외부 품질 검수 업체와도 공유되고 있었다.

개인정보 담당 하 매니저와 개발 리드 기 책임은 먼저 데이터 흐름도를 그렸다. 메모는 앱 → 주문 DB → 모델 API → 로그·평가 세트·주간 배치 파일로 복제되고 있었다. 조치는 다음과 같았다.

1. 입구에서 가린다. 메모를 모델에 보내기 전에 전화번호와 비밀번호 형태의 숫자열을 자리표시자로 바꾸고, 요약 결과에 자리표시자가 그대로 남았는지 검사한다. 기사 앱에는 주문 DB의 원문을 권한 있는 기사에게만 보여 준다.
2. 로그는 원문 대신 메타데이터만 남긴다. 추적 ID, 공급자 요청 ID, 모델 ID, 토큰 수, 분류 결과, 검증 결과다.
3. 평가 세트는 가명처리한 표본으로 다시 만들고 보존 기한을 정한다. 기존 CSV와 공유본은 회수·삭제하고, 평가 세트에 개인정보 패턴이 있으면 실패하는 검사를 CI에 넣는다.
4. 공급자 쪽 설정과 계약을 확인한다. 대화 상태 저장을 끄고, 처리방침의 위탁 사항을 갱신하며, 국외 이전에 해당하는지 법무와 검토한다.

시스템 프롬프트에 “개인정보를 출력하지 말라”를 넣자는 안은 입력이 로그와 평가 세트로 복제되는 문제를 해결하지 못해 기각했다. 로그를 전부 끄자는 안은 장애 추적이 불가능해져 채택하지 않았다. 한 달 뒤 재점검에서 원문 개인정보가 남은 복제본은 운영 DB 하나뿐이었다.

자주 틀리는 지점

• 최신 모델을 가리키는 별칭을 쓰면 자동으로 좋아진다. 검증 없이 동작이 바뀔 수 있습니다. 운영은 고정된 버전으로 하고, 교체는 평가로 합니다.
• 버전을 고정하면 영원히 같은 모델을 쓸 수 있다. 은퇴 일정이 있습니다. 고정은 교체를 계획할 시간을 버는 장치입니다.
• 대표 질문 몇 개로 충분하다. 드문 고위험 사례와 경계 사례의 회귀를 놓칩니다. 분포를 반영한 고정 세트가 필요합니다.
• 평균 점수가 오르면 교체해도 된다. 중요한 구간이 나빠질 수 있습니다. 구간별 합격선을 따로 둡니다.
• LLM 채점기는 그대로 믿어도 된다. 사람 채점 표본과 대조해 보정하고, 편향과 버전을 관리해야 합니다.
• 디버깅을 위해 원문을 모두 오래 보관한다. 개인정보 위험이 커집니다. 메타데이터 위주로 남기고 원문은 필요한 범위·기간만 보관합니다.
• 공급자가 학습에 쓰지 않으니 개인정보 문제는 없다. 보관, 남용 모니터링, 위탁, 국외 이전, 우리 쪽 로그와 평가 세트는 별개의 문제입니다.

한눈에 정리

• 성공 기준: 구체적·측정 가능·달성 가능·관련성. 합격선은 결과를 보기 전에 정한다.
• 평가 세트: 실제 분포 + 경계 사례 + 고위험 구간 가중, 개발용·검증용 분리, 저장소에서 버전 관리.
• 채점: 코드 → LLM → 사람 순으로 고르되, LLM 채점기는 사람 표본과 대조해 보정한다.
• 해석: 변동 폭 측정, 짝지은 비교, 구간별 집계.
• 버전: 스냅샷 고정 + 설정 묶음. Anthropic 4.6 세대부터 모든 ID가 고정 스냅샷.
• 교체: 기준 먼저 → 같은 세트 비교 → 파라미터 재조정 → 그림자 실행 → 단계적 전환 → 기록.
• 로그: 추적 ID, 공급자 요청 ID, 설정 버전, 사용량, 중단 사유. 원문은 기본으로 남기지 않는다.
• 개인정보: 최소 수집과 가명처리, 공급자 보관 정책 확인, 위탁·국외 이전 검토, 불투명한 사용자 식별자.
• 지표: 질문 → 지표(분모) → 평소 범위 → 경보 → 담당 조치. 업무 지표를 함께.

공식 문서로 확인하기

• Anthropic — Define success criteria and build evaluations: 성공 기준, 평가 설계 원칙, 채점 방법과 LLM 채점 요령을 읽는다.
• Anthropic — Models overview: 모델 ID와 스냅샷, 은퇴 시점, Models API를 확인한다.
• Anthropic — API and data retention: ZDR 범위와 기능별 적용 여부를 확인한다.
• OpenAI — Data controls in the OpenAI platform: 학습 이용, 보관 기간, ZDR, 데이터 저장 지역을 읽는다.
• 국가법령정보센터 — 개인정보 보호법: 제2조, 제3조, 제23조, 제26조, 제28조의8, 제29조를 읽는다.

셀프 체크

5-1. 좋은 성공 기준의 네 가지 조건을 들고, “답변 품질이 좋아야 한다”라는 기준을 그 조건에 맞게 두 개 이상의 측정 가능한 기준으로 고쳐 쓰라.

5-2. LLM 채점기를 운영 평가에 투입하기 전에 거쳐야 할 보정 절차를 순서대로 쓰라.

5-3. Anthropic 문서 기준으로 4.6 세대 이후 모델 ID와 그 이전 모델의 별칭이 각각 어떤 성격인지 쓰고, 버전을 고정해도 교체 계획이 필요한 이유를 설명하라.

5-4. 「개인정보 보호법」의 가명처리 정의를 쓰고, LLM 기능의 평가 세트를 만들 때 이 개념을 어떻게 적용할 수 있는지 설명하라.

5-5. 교체 후보 모델이 평가 세트 평균 점수는 높였지만 고위험 구간의 점수를 떨어뜨렸다. 어떤 절차로 판단하고 어떤 선택지가 있는지 쓰라.

5-6. 운영 중인 LLM 기능 하나를 골라 운영 질문 다섯 개를 정하고, 질문마다 지표(분모 포함), 평소 범위, 경보 조건, 담당자와 첫 조치를 표로 설계하라.

실습 과제