모델이나 프롬프트를 바꿀 때 기존 AI 기능이 망가지지 않았는지 확인하는 법

바뀐 구성과 달라진 기대 결과를 따로 적습니다

모델 이름이나 프롬프트가 한 줄 바뀌면 응답 표현 외에도 검색 호출, 도구 인자, 허용되지 않은 요청을 보류하는 방식에 영향이 갈 수 있습니다. 같은 모델을 사용해도 검색 인덱스, 임베딩 구성, 정책, 도구 스키마, 채점 기준이 달라지면 비교하는 기능 전체가 바뀝니다. 변경 요청에는 현재 운영 구성과 후보를 실행할 수 있을 만큼 버전을 남깁니다. 모델 식별자나 별칭, 프롬프트 템플릿과 실행 설정, 검색 인덱스와 조회 정책, 호출 도구, 권한 정책, 채점기와 평가셋이 대표적입니다.

이전 결과를 비교 기준으로 재사용하기 전에 어느 구성으로 얻은 결과인지 확인합니다. 운영 경로가 두 개라면 모든 트래픽이 같은 모델을 사용했다고 가정하지 않습니다. 리전, 계정, 기능 플래그나 오류 시 대체 경로에 따라 모델 이름이 달라질 수 있습니다. 공급자 API가 실제 처리한 모델 식별자를 돌려주면 기록하고 별칭 뒤의 버전을 확인할 수 없으면 그 범위를 명시합니다. 응답 값이 매번 같을 필요는 없지만 실제 기능의 판단 기준과 실행 환경을 설명할 수 있어야 합니다.

정책 개정과 모델 교체가 같이 들어오는 경우에는 “예전과 똑같아야 하는 행동”과 “새로 요구되는 행동”을 분리합니다. 어떤 요청에 이제 추가 확인이 필요해졌다면 응답이 이전보다 덜 달라진 자체를 합격으로 볼 수 없습니다. 기존 정책 기준에서 현재 구성과 후보를 비교하는 실험과, 새 정책에 맞는지를 확인하는 실험을 기록합니다. 위험 기반 회귀 테스트 범위의 영향 분석과 함께 쓰면 코드 범위가 작아도 사업 영향이 큰 변경을 먼저 찾을 수 있습니다.

영향별로 다시 실행할 검증을 고릅니다

표는 하나의 변경으로 여러 사례 묶음을 각각 고르는 방식입니다. 프롬프트 문구를 바꿔 답변 길이만 줄이려 했어도 날짜나 예외가 생략되면 정책 안내 품질에 영향이 생깁니다. 어떤 사례는 이전 결과를 다시 사용할 수 있더라도, 실행하지 않은 사례와 이전 증거를 검토해 사용한 사례는 구분해서 기록합니다.

변경 범위에 최신 인덱스나 도구가 들어가면 기존 구성도 동일한 시험 데이터를 두고 실행합니다. 실제 운영 인덱스를 통째로 재사용할 수 없다면 승인된 자료를 이용해 대표 문서와 권한 조건을 재현합니다. 연동의 실제 부작용을 비교하려면 외부 송금이나 사용자 메시지를 보내지 않는 테스트 테넌트와 검증 도구를 사용합니다. 이메일 발송 결과는 모델이 “보냈다”고 말하는지보다 시험 기록에 예상 수신처와 내용이 생겼는지 확인합니다. Anthropic — Demystifying evals for AI agents^[1]

같은 사례를 짝지어 비교합니다

A는 현재 운영 구성, B는 후보입니다. 두 구성 모두 동일한 질문, 사용자 역할, 주문 상태, 타임스탬프, 도구 응답과 기대 결과에서 실행합니다. 이런 대응 비교를 쓰면 후보에서 좋아진 사례와 나빠진 사례를 같은 분모에서 볼 수 있습니다. 업무 정책이 새로 적용되는 사례는 변경 목표 집합에 넣고, 기존 약속을 지켜야 하는 사례는 회귀 집합에 둡니다. 조금 다른 사례를 각각 골라 점수만 비교하면 구성의 차이와 입력 난도 차이를 구별하기 어렵습니다.

개발하는 동안 반복해서 본 사례는 동작을 고치는 데 활용합니다. 마지막 교체 판단에는 개발팀이 프롬프트를 고치면서 답을 반복 확인하지 않은 별도 사례를 유지합니다. 구체적인 문장만 숨기고 거의 같은 주문과 조건을 양쪽에 복제하면 새 입력에 맞게 개선됐는지 확인하기 어렵습니다. 데이터 출처나 업무 패턴을 묶어 너무 비슷한 사례의 분리를 점검합니다. 높은 위험의 과거 실패는 운영 회귀 묶음에도 남겨 같은 유형이 돌아오지 않는지 확인합니다. 개발 평가와 독립된 검증을 나누는 접근은 Google의 모델·시스템 안전성 평가 안내^[2]에서 설명합니다.

응답에 변동성이 있을 수 있으므로 결과를 반복합니다. 예상대로 처리하지 못하면 피해가 큰 사례에서 각 구성에 같은 정책으로 여러 번 응답을 받아 봅니다. 사례 수와 실행 수를 섞지 않습니다. 20개 사례 중 4개를 세 번씩 추가 실행하면 대표하는 사례는 여전히 20개이고 모두 첫 실행이 있었다면 전체 실행은 32회입니다. 특정 사례에서 세 번 중 한 번만 중대한 실패가 발생해도 그 실패를 평균에 숨기지 말고 재현 조건과 실패한 실행을 남깁니다. 보류와 타임아웃이 많은 후보는 성공 응답만 남겨 정답률이 왜곡되지 않도록 미실행과 실행 오류를 따로 보고합니다.

한 번에 모델, 프롬프트, 검색을 모두 바꾸는 설계에서는 전체 동작의 합격 여부를 먼저 검증할 수 있습니다. 원인 추적을 해야 하면 운영 모델에 후보 프롬프트만 적용하거나 후보 모델에 기존 프롬프트를 적용하는 등 변경을 분리할 수 있는 조합을 실행합니다. 모든 조합을 항상 지원한다는 전제는 두지 않습니다. 후보 모델이 새 출력 스키마를 요구하면 해당 조합을 비교할 수 없는 이유와 그로 인해 남는 불확실성을 적습니다.

정확도가 올라가도 출시하지 않는 가상 사례

가상 지원팀이 문의 의도를 분류하고 답변에 필요한 정책 문서가 없으면 보류하는 두 업무를 평가합니다. 업무 책임자가 요구한 기준은 ‘분류 개선’과 ‘근거 없는 환불이나 약속을 확정하는 사례가 없는 것’입니다. 인위적으로 만든 시험에서 기존과 후보를 같은 사례로 실행했습니다. 업무별 분모가 다르고, 두 업무의 숫자를 합쳐 평균을 내지 않습니다.

분류 100사례에서 후보가 더 잘한 상위 유형을 확인할 수 있지만 그 개선 자체로 배포를 승인하지 않습니다. 후보가 근거 부족 4건에서 약속을 확정했기 때문입니다. 같은 질문에 두 모델이 어떤 문서와 정책 정보를 받았는지 확인한 뒤, 판정 경계가 바뀐 이유를 찾습니다. 특정 도구가 실패했는데 그 실패가 ‘정책 승인’으로 번역됐다면 프롬프트와 별개로 상태 계약을 수정할 수 있습니다. 후보의 분류 개선을 채택하려면 분류에만 제한하고 근거 확인과 고객 약속의 실행 경로가 기존대로 남는지를 다시 검증할 수 있습니다.

분류 차이 6건은 이 표본에서 확인한 결과입니다. 전체 운영에서도 똑같이 6%p 향상된다고 볼 수는 없습니다. 실제 업무 분포와 평가 표본의 관계, 동일 고객이나 주문에서 나온 서로 연관된 사례, 높은 위험의 희소 실패를 확인합니다. 작은 변화만 관측되었거나 평가자가 둘 사이에서 의견을 달리하면 표본을 보완하고 정책 담당자가 직접 검토합니다. 차이가 적어도 피해가 큰 새 실패는 별도로 조치 여부를 결정합니다.

섀도와 제한 카나리에서 확보할 증거가 다릅니다

섀도 시험에서는 운영과 유사한 입력을 후보에도 제공하되, 후보 답변을 고객에게 전달하거나 실제 발송·환불·시스템 쓰기를 실행하지 않습니다. 도구 실행 의도와 인자를 기록하고 실제 도구는 격리된 대체물로 연결합니다. 입력 자체가 실제 개인정보를 담을 수 있으므로 후보 환경이 데이터를 받을 권한과 보존 범위도 확인합니다. 섀도에서 좋은 후보는 경로·형식·지연을 확인할 수 있지만 사용자가 받은 결과와 외부 서비스의 확정 응답은 여전히 관측되지 않습니다.

제한 카나리는 허용된 소수의 실제 트래픽을 후보에 보내면서 운영 증거를 보게 합니다. 무엇을 요청 단위로 묶을지 정해야 같은 대화를 하다가 모델과 정책이 바뀌는 일이 줄어듭니다. 처음에는 영향이 작고 다시 확인할 수 있는 유형을 골라 실제 요청의 수, 지연, 업무 성공과 사람 이관을 나란히 관측합니다. 고객이나 담당자의 행동까지 영향을 받을 수 있으므로 철회 책임자와 확대 중지 조건을 둡니다. 표본이 너무 작으면 중요한 위험을 아직 관측하지 못할 수 있어, 카나리 이전의 의도적인 부정 사례를 그대로 유지합니다. Google SRE — Canarying Releases^[3]

공급자 운영 방식에 따라 이전 모델 버전이 지원 종료되거나 별칭이 다른 버전을 가리킬 수 있습니다. 공식 종료 공지를 확인하고 이전 버전으로 실제 복귀 가능한지 시험합니다. 지원 종료가 예정됐다면 검증된 다른 구성, 자동 판단 중지, 사람이 처리할 수 있는 큐 같은 선택지를 미리 설계합니다. 실제 데이터를 쓰는 행동이 발생했다면 모델을 바꾼 뒤에도 그 행동을 대사해야 합니다. 이 부분은 롤백 가능한 배포 설계와 연결됩니다. 공급자 공지의 확인 예시는 OpenAI API의 Deprecations^[4]입니다.

판정 회의에 넣을 비교 기록

배포 뒤 점수는 기능 변화뿐 아니라 운영 데이터나 문서, 사용자 질문이 바뀌어서 움직일 수 있습니다. 운영 기간과 대상에서 어떤 버전이 쓰였는지 연결하고 신규 고객 유형에서 생긴 실패가 보이면 승인된 사례로 바꿔 회귀에 추가합니다. 문서 품질이나 평가 기준의 변경도 모델 수정과 같은 기록에 남깁니다. Google Cloud의 생성형 AI 배포·운영 안내^[5]는 지속적인 평가와 운영 관측을 설명합니다.