AI 회귀 테스트, 프롬프트를 고친 뒤 무엇을 다시 확인해야 할까?

안녕하세요. 사랑받는 IT 프로덕트의 첫걸음, 똑똑한개발자입니다.

오늘의 인사이트 요약

• 자주 들어오는 질문과 담당자가 고쳐 쓴 답변부터 모읍니다.

• 이전 버전과 새 버전에 같은 질문과 자료를 넣어 비교합니다.

• 배포 전에는 새로 틀린 답변과 되돌릴 방법을 확인합니다.

AI 답변이 너무 길어 프롬프트를 고쳤다고 가정해 보겠습니다. 문장은 짧아졌는데, 이전에는 잘 붙던 출처가 사라졌습니다. 답변 길이만 확인했다면 개선됐다고 판단했겠지만, 업무 담당자는 근거를 찾느라 다시 시간을 써야 합니다.

이럴 때는 운영 중인 AI를 수정할 때는 이런 변화까지 살펴야 하는데요.

새로 요청한 일을 잘하는지 확인하면서, 기존에 맡기던 일도 계속 처리하는지 검사하는 것입니다. 이를 회귀 테스트라고 합니다. 거창한 평가 도구를 고르기 전에, 우리 팀이 어떤 답변을 계속 믿고 쓸 수 있어야 하는지 정하는 데서 시작할 수 있습니다.

첫 번째, 자주 쓰는 질문부터 테스트 자료로 모읍니다.

첫 자료는 시연용 질문보다 실제 업무에서 찾는 편이 좋습니다.

매주 확인하는 사내 규정, 반복해서 요청하는 문서 요약, 담당자가 자주 고쳐 쓰는 안내문을 살펴보세요. 사용 빈도가 높은 질문이 바뀐 뒤에도 잘 처리되는지부터 확인하면, 테스트와 실제 업무가 멀어지는 것을 줄일 수 있습니다.

질문만 복사해 두면 나중에 결과를 비교하기 어렵습니다. 당시 참고한 문서와 답변에 꼭 들어가야 하는 내용도 함께 남깁니다. 문서가 자주 바뀐다면 파일 이름뿐 아니라 사용한 버전도 구분해야 합니다. 테스트 자료에 민감한 정보가 포함돼 있다면 필요한 부분만 남기고 접근 권한을 정합니다.

여기에 실제로 답변을 고쳤던 질문을 더합니다. 예를 들어 사내 정책을 안내하는 AI라면 근거 문서가 없는 질문, 서로 다른 규정이 검색되는 질문을 포함할 수 있습니다. 이때 기대하는 답은 무조건 완성된 안내문이 아닐 수 있습니다. 자료가 부족하다고 알리거나 담당자 확인을 요청해야 하는 상황도 있기 때문입니다.

테스트 항목마다 모범 답안을 길게 쓸 필요는 없습니다.

‘시행일을 포함할 것’, ‘문서에 없는 금액을 추측하지 않을 것’처럼 통과 조건을 적어도 됩니다. 똑똑한개발자팀은 답변에서 꼭 지켜야 할 조건을 실제로 그 답변을 사용하는 사람이 정해야 한다고 생각합니다.

두 번째, 매끄러운 문장보다 업무에 필요한 내용을 확인합니다.

읽기 좋은 답변과 그대로 사용할 수 있는 답변은 다를 수 있습니다.

숫자를 추출하는 업무라면 값과 단위가 맞는지, 고객 안내문이라면 필수 안내가 빠지지 않았는지를 봐야 합니다. 문장이 자연스럽다는 인상만으로 통과시키면 이런 누락이 남습니다.

참고 문서를 사용하는 AI라면 출처도 따로 확인합니다. 링크가 붙었다는 사실만으로 답변의 근거가 확보되지는 않습니다. 연결된 문서가 실제 내용을 뒷받침하는지, 다른 시점의 규정을 가져오지는 않았는지 읽어봐야 합니다. 형식처럼 자동으로 확인할 수 있는 항목과 사람이 판단할 항목을 나누면 검토할 일이 분명해집니다.

모든 항목을 하나의 점수로 합치기보다 실패했을 때의 영향을 먼저 생각해 보세요.

반드시 들어가야 하는 정보가 빠졌다면 배포를 보류할 수 있습니다. 반면 문장 길이나 표현은 업무에 지장이 없는 범위에서 개선 추이를 살필 수 있습니다. 평균 점수가 높아져도 중요한 질문 하나가 새로 틀렸다면 그 원인을 확인해야 합니다.

응답 시간과 비용도 비교 대상입니다. 다만 모든 회사가 같은 합격선을 쓸 수는 없습니다. 사용자가 기다리는 화면인지, 밤사이 처리하는 작업인지에 따라 허용할 시간이 달라집니다. 정확도와 속도를 함께 살피되 실제 사용 상황에 맞춰 판단합니다.

세 번째, 같은 조건으로 비교하고 변경 이유를 남깁니다.

이전 버전과 새 버전에는 같은 질문 묶음과 같은 참고 자료를 넣습니다.

한쪽에만 최신 문서를 주면 답변 차이가 프롬프트 때문인지 자료 때문인지 알기 어렵습니다. 검색 결과까지 사용하는 서비스라면 비교할 때 어떤 자료가 전달됐는지도 기록하는 편이 좋습니다.

프롬프트와 모델, 검색 설정을 한꺼번에 바꾸면 원인을 찾는 일이 더 복잡해집니다. 가능하면 변경 범위를 나눠 확인합니다. 여러 요소를 함께 바꿔야 했다면 무엇이 달라졌는지 남겨두세요. 답변이 매번 달라지는 질문은 한 번 잘 나왔다는 이유로 통과시키기보다 반복해서 확인할 필요가 있습니다.

비교할 때는 문구가 똑같은지보다 앞서 정한 조건을 지켰는지 봅니다.

새로 실패한 질문을 따로 모으고, 어떤 이유로 배포하거나 보류했는지 적습니다. 똑똑한개발자팀은 테스트 결과만큼이나 배포를 결정한 이유를 남기는 일이 중요하다고 봅니다. 담당자가 바뀌어도 어떤 오류를 확인했고 왜 배포했는지 이해할 수 있어야 하기 때문입니다.

문제가 생겼을 때 되돌릴 프롬프트와 설정도 보관합니다. 참고 데이터까지 바꿨다면 설정만 되돌려도 복구되는지 확인해야 합니다. 배포 후 발견한 오류는 재현할 조건과 함께 다음 테스트에 추가하고, 업무 규정이 바뀌어 오래된 정답이 틀리게 됐다면 기대 답변도 수정합니다. 테스트 자료 역시 운영하면서 관리할 대상입니다.

AI 회귀 테스트는, 업무 담당자와 개발자가 함께 판단해야 합니다.

개발자는 반복 실행과 결과 기록을 준비하고, 업무 담당자는 반드시 지켜야 할 내용과 예외를 정합니다. 양쪽이 같은 실패 사례를 보며 이야기해야 ‘기술적으로 정상’이라는 판단과 ‘업무에 쓸 수 있다’는 판단의 차이를 좁힐 수 있기 때문인데요.

똑똑한개발자는 업무 분석부터 AX 전략, PoC, 시스템 개발과 운영 개선까지 하나의 팀에서 진행합니다. 내부 업무에도 AI와 자동화를 적용하고 사람이 최종 판단하는 방식으로 운영해온 경험을 바탕으로, 어떤 일을 맡기고 어디서 검토할지 함께 살펴봅니다.

실제 업무에 맞는 AI 적용 범위와 구축 이후 운영 방식을 설계하거나, 운영 중인 AI를 개선할 필요가 있다면 아래 똑똑한개발자 링크로 문의해 주세요! 감사합니다.