프롬프트 수정은 같은 입력과 성공 기준을 다시 실행해 기존 품질이 나빠지지 않았는지 확인한 뒤 배포해야 합니다.
결과가 “더 좋아 보인다”는 느낌만으로 배포하면, 한 항목은 좋아졌지만 다른 항목이 빠지는 회귀를 놓치기 쉽습니다. 이 글에서는 모호한 버전 A와 독자·근거·출력·한계를 명시한 버전 B를 같은 다섯 기준으로 비교하고, 실제 화면과 작동 영상을 공개합니다.
프롬프트 수정에도 회귀 테스트가 필요한 이유
생성형 AI 출력은 확률적이고 모델이나 시스템 구성에 따라 달라질 수 있습니다. OpenAI의 평가 모범 사례는 실제 사용 사례에 맞춘 평가를 일찍 시작하고 자주 반복하며, 일반적인 입력뿐 아니라 경계 사례와 적대적 사례도 포함하라고 권합니다. 프롬프트를 바꿀 때도 같은 입력과 같은 성공 기준을 다시 적용해야 어떤 조건이 좋아지고 나빠졌는지 알 수 있습니다.
“문장을 길게 썼다”, “역할을 부여했다”, “예시를 추가했다”는 사실은 성공 기준이 아닙니다. 중요한 것은 실제 업무에서 필요한 결과가 나오는지입니다. 뉴스 요약이라면 공식 근거, 기준일, 독자 수준, 출력 구조, 불확실성 표시가 필요할 수 있습니다. 고객 지원이라면 금지 답변, 사람에게 넘길 조건, 개인정보 처리, 정확한 정책 링크가 더 중요할 수 있습니다.
OpenAI의 evals 안내는 평가 데이터와 테스트 기준을 정의하고, 여러 실행 결과를 비교해 시스템 성능을 추적하는 흐름을 설명합니다. 대규모 평가 플랫폼을 바로 도입하지 않아도 작은 표부터 시작할 수 있습니다. 고정 입력 5개, 기대 조건 5개, 실패 시 처리 1개만 있어도 “느낌”보다 재현 가능한 변경 기록을 만들 수 있습니다.
이번 실험에서 고정한 다섯 기준
- 독자와 작업 목표: 누구를 위해 어떤 결과를 만드는지 한 문장에 드러나는가?
- 공식 근거 범위: 사용할 출처의 종류와 최소 개수가 명시됐는가?
- 출력 구조: 분량, 섹션, 표나 목록 등 검수 가능한 형식이 있는가?
- 직접 확인 절차: 독자가 따라 하거나 검수자가 재현할 행동이 포함됐는가?
- 불확실성 처리: 모르는 내용, 계정별 차이, 추정을 어떻게 표시할지 정했는가?
버전 A는 “AI 신제품 출시를 소개하는 블로그 글을 작성해줘”라는 한 줄 요청입니다. 작업 주제는 있지만 독자, 허용 출처, 분량, 검증 절차, 한계 표시가 없습니다. 버전 B에는 초보 실무자, 공식 출시 문서 2개, 800자, 핵심 변화·직접 확인 절차·적용 한계의 H2, 확인하지 못한 내용은 추정 표시라는 조건을 넣었습니다.
이 다섯 기준은 모든 프롬프트에 통용되는 절대 점수가 아닙니다. 이번 뉴스형 글쓰기 사례에서 누락을 찾기 위한 고정 검사입니다. 실제 업무에서는 정확성, 지연 시간, 비용, 안전, 브랜드 표현처럼 목적에 맞는 기준을 추가하거나 바꿔야 합니다.
직접 실행한 프롬프트 회귀 테스트
테스트 날짜: 2026년 9월 10일. 환경: Windows 11, Chrome 기반 브라우저, localhost 정적 페이지. 입력: 버전 A와 B의 샘플 프롬프트. 기대 결과: 같은 다섯 기준을 두 버전에 적용해 누락 조건을 표시하고 버전별 통과 수를 계산.
실제 모델 API는 호출하지 않았고 프롬프트 문장에 필요한 조건이 존재하는지만 브라우저 내부에서 결정적으로 검사했습니다. 따라서 결과가 모델 답변 품질을 보증하지 않습니다. 계정 정보, API 키, 고객 자료, 외부 네트워크 전송도 사용하지 않았습니다.
실행 전 화면에는 두 프롬프트와 고정 평가 매트릭스가 보입니다. 모든 행은 대기, 버전 A와 B의 점수는 0/5입니다. 어떤 결과도 미리 성공으로 표시하지 않았습니다.
“5개 시나리오 실행” 버튼을 한 번 누르자 각 행의 A와 B 판정이 순서대로 나타났습니다. 버전 A는 독자·목표와 직접 확인 절차가 부분 충족, 나머지 세 항목이 실패해 2/5로 표시됐습니다. 버전 B는 다섯 항목이 모두 통과해 5/5가 됐습니다. 이 결과는 문장 조건의 포함 여부를 비교한 것이며 실제 모델 응답의 사실성이나 문체를 평가한 것은 아닙니다.
정지 화면은 1200×675 WebP 두 장, 동작 기록은 1200×674 VP9 WebM 5초입니다. 세 파일의 SHA-256을 manifest에 저장해 업로드 전에 동일 파일인지 확인합니다. 시작·중간·완료 상태가 모두 남아 있어 완료 화면만 나중에 만든 것이 아니라 같은 세션에서 상태가 바뀌었음을 확인할 수 있습니다.
실무에서 만드는 최소 회귀 테스트 세트
첫 단계는 실제 실패 사례를 모으는 것입니다. 예쁜 데모 입력만 쓰면 배포 뒤의 문제를 찾지 못합니다. 날짜가 없는 요청, 서로 충돌하는 자료, 지나치게 긴 문서, 잘못된 URL, 답을 거부해야 하는 민감 질문처럼 업무에서 실제로 만난 입력을 익명화해 포함합니다. 각 입력에는 “좋은 답변 예시”보다 먼저 통과해야 할 조건과 절대 나오면 안 되는 조건을 적습니다.
둘째, 평가를 결정적 검사와 사람 판단으로 나눕니다. 링크 개수, JSON 형식, 금지 문자열, 필수 제목은 자동으로 확인하기 쉽습니다. 설명의 유용성, 어조, 근거의 적절성, 모호한 질문을 제대로 되물었는지는 사람이 표본을 읽는 편이 낫습니다. 자동 점수 하나로 모든 품질을 대표하지 않습니다.
셋째, 기준선을 저장합니다. 프롬프트 버전, 모델 식별자, 실행 날짜, 입력 집합, 온도와 도구 설정, 결과 점수를 함께 남깁니다. 출력 원문 전체를 보관하기 어렵다면 실패 유형과 대표 예시라도 기록합니다. 다음 수정에서 같은 세트를 실행해야 변화 방향을 비교할 수 있습니다.
넷째, 통과 기준과 배포 조건을 분리합니다. 평균 점수가 올라도 개인정보 누출이나 잘못된 링크처럼 중요한 실패가 하나 있으면 배포를 막아야 합니다. 반대로 사소한 문장 길이 차이 때문에 모든 변경을 막지 않도록 필수 차단 항목과 개선 권고 항목을 구분합니다.
프롬프트 버전을 비교하는 기록 양식
기록표에는 프롬프트 버전, 변경 이유, 입력 세트 해시, 모델 버전, 실행 시각, 항목별 점수, 실패 예시, 검수자, 배포 여부를 둡니다. “B가 더 좋음” 대신 “공식 출처 누락 4건이 0건으로 감소했고, 응답 길이는 평균 12% 늘어남”처럼 관찰 가능한 차이를 적습니다. 비용과 지연 시간도 실제 서비스에서는 품질의 일부입니다.
변경은 한 번에 하나가 이상적입니다. 독자, 출력 형식, 예시, 도구 사용 지침을 동시에 바꾸면 어떤 수정이 결과에 영향을 줬는지 알기 어렵습니다. 꼭 여러 조건을 함께 바꿔야 한다면 변경 묶음을 하나의 버전으로 고정하고 되돌릴 수 있도록 이전 프롬프트를 남깁니다.
OpenAI 프롬프트 엔지니어링 안내는 지침과 컨텍스트를 명확히 구성하고, 모델별 권장 방식과 예시를 실제 작업에 맞춰 적용하는 방법을 설명합니다. 특정 문구를 주문처럼 복사하기보다 업무 목표와 평가 기준을 함께 설계해야 변경 효과를 확인할 수 있습니다.
테스트 데이터가 좋아야 점수도 의미가 있다
회귀 테스트 입력은 실제 트래픽의 분포를 반영해야 합니다. 정상 질문만 100개 넣고 가장 위험한 예외를 빼면 높은 점수가 안전을 의미하지 않습니다. 자주 들어오는 정상 입력, 드물지만 비용이 큰 실패, 길이와 언어가 다른 입력, 도구가 실패했을 때의 입력을 구분해 표본을 구성합니다.
정답이 하나로 고정되지 않는 작업에는 비교 평가가 유용할 수 있습니다. 두 결과 중 어느 쪽이 더 명확한지, 근거가 더 직접적인지, 독자의 작업을 실제로 끝내 주는지를 같은 기준으로 비교합니다. 다만 평가자가 프롬프트 버전을 알면 기대가 판단에 섞일 수 있으므로 중요한 변경은 버전 이름을 가리고 검토합니다.
테스트 세트도 버전 관리합니다. 새 실패가 발견되면 재현 입력을 추가하고, 더 이상 존재하지 않는 제품 기능이나 오래된 정책을 다루는 항목은 이유를 남긴 뒤 갱신합니다. 테스트가 늘어날수록 모두 매번 실행하기 어렵다면 핵심 차단 세트와 정기 전체 세트로 나눕니다.
흔한 실패와 안전한 처리
평균 점수만 봅니다. 100개 중 99개가 좋아도 한 개의 심각한 개인정보 노출이 있으면 배포하면 안 됩니다. 항목별 최저 기준과 즉시 차단 조건을 둡니다.
프롬프트와 모델을 동시에 바꿉니다. 원인을 분리할 수 없으므로 가능한 한 한 요소씩 비교합니다. 동시에 바꿨다면 새 기준선으로 명시하고 이전 버전과 직접 동등 비교라고 표현하지 않습니다.
같은 예시만 반복해 과적합합니다. 테스트 문장을 프롬프트에 그대로 넣으면 점수는 오르지만 새로운 입력에 약할 수 있습니다. 개발 세트와 최종 확인 세트를 분리하고, 실제 운영에서 발견된 새 실패를 추가합니다.
자동 평가자를 정답으로 취급합니다. 문자열 검사는 빠르지만 의미의 타당성을 놓칠 수 있고, 모델 평가자도 편향과 변동이 있습니다. 중요한 표본은 사람이 원문과 함께 확인합니다.
실패 후 결과만 고칩니다. 한 번의 답변을 손으로 수정하는 데서 끝내지 말고 같은 실패가 다시 나오지 않도록 테스트 케이스를 추가합니다. 그래야 다음 프롬프트 변경에서 회귀를 발견할 수 있습니다.
이번 실험의 한계
이번 화면은 프롬프트 문장에 다섯 필수 조건이 있는지 확인하는 로컬 매트릭스의 동작을 보여 줍니다. 실제 OpenAI API, ChatGPT 응답, 토큰 비용, 지연 시간, 모델별 정확도를 측정하지 않았습니다. 버전 B가 5/5라는 결과는 모델 출력이 항상 정확하다는 뜻이 아니라 입력 지침의 누락이 줄었다는 뜻입니다.
실제 모델 평가는 같은 프롬프트를 여러 입력과 여러 실행에 적용해야 합니다. 모델 출력은 달라질 수 있으므로 한 번의 성공 예시만으로 일반화하지 않습니다. 모델 스냅샷과 시스템 구성도 기록하고, 제공자의 현재 문서와 변경 내역을 확인합니다.
이 사이트에서 사용하는 프롬프트 작성 기본 구조는 프롬프트로 타이머 웹앱을 만든 실전 기록에서 확인할 수 있습니다. 직접 실행한 화면·결과·실패 조건을 공개하는 편집 원칙은 소개 페이지에 정리했습니다.
바로 적용하는 일곱 단계
- 실제 업무에서 자주 들어오는 입력 3개와 실패 비용이 큰 입력 2개를 고릅니다.
- 좋은 결과의 조건과 절대 허용하지 않을 실패를 분리합니다.
- 현재 프롬프트와 모델 설정을 기준선으로 저장합니다.
- 변경 이유 하나를 정하고 프롬프트 버전을 올립니다.
- 같은 입력과 같은 평가 기준으로 두 버전을 실행합니다.
- 자동 점수와 사람 표본 검수를 함께 기록합니다.
- 차단 실패가 없을 때만 배포하고 새 실패는 테스트 세트에 추가합니다.
작은 표로 시작해도 괜찮습니다. 중요한 것은 프롬프트 문구를 많이 모으는 것이 아니라, 어떤 입력에서 어떤 조건이 실패했고 다음 버전에서 재발했는지를 확인할 수 있는 기록입니다. 배포 전 한 번, 모델이나 도구가 바뀔 때 한 번, 실제 실패가 들어올 때 한 번 같은 세트를 반복합니다.
출처와 기준일
기준일은 2026년 9월 10일입니다. 실제 사용 사례를 반영해 평가를 일찍·자주 수행하고 자동 점수와 사람 판단을 함께 쓰는 원칙은 OpenAI 평가 모범 사례, 평가 데이터와 실행 흐름은 OpenAI evals 안내, 지침과 컨텍스트 구성 방법은 OpenAI 프롬프트 엔지니어링 안내에서 확인했습니다. 제품과 권장 방식은 바뀔 수 있으므로 실제 적용 전 현재 문서를 다시 확인해야 합니다.