이 가이드는 짧은 명령어 하나로 끝나지 않습니다. 필요한 자료를 정리하고, AI가 추측하지 않게 경계를 주고, 출력 내용을 원문과 대조해 실제로 사용할 수 있는 결과로 만드는 전체 과정을 설명합니다.
예시 안내 본문의 입력과 기대 결과는 절차를 설명하기 위해 구성한 예시입니다. 실제 수행 결과나 성과를 주장하지 않으며, 중요한 업무에는 원자료와 담당자의 최종 확인이 필요합니다.
- 실제 업무를 대표하는 시험 입력과 실패 사례를 먼저 고정합니다.
- 출력 순서를 가린 채 같은 기준으로 A·B 버전을 평가합니다.
- 평균 점수뿐 아니라 중대한 실패와 비용·지연·변동성을 함께 기록합니다.
완성 결과물
누구에게 필요하고, 누구에게는 맞지 않을까
이런 분께 맞습니다
- 프롬프트를 수정할 때 결과가 정말 나아졌는지 증명하고 싶은 실무자
- 팀마다 다른 판단을 공통 평가표로 맞추려는 AI 기능 운영자
- 프롬프트 변경 이력과 되돌리기 기준이 필요한 제품 기획자
이 경우에는 멈추세요
- 시험 입력 없이 눈에 띄는 출력 한두 개로 우승 버전을 정하려는 경우
- 안전·법률·의료 결과를 일반 품질 점수 하나로 자동 승인하려는 경우
- 모델·도구·검색 자료까지 동시에 바꿔 프롬프트 효과를 분리할 수 없는 비교
시작 전에 준비할 것
도구를 열기 전에 입력 자료와 최종 확인자를 정하면, 그럴듯하지만 틀린 결과를 줄일 수 있습니다.
- 현재 사용 중인 기준 프롬프트와 변경 후보
- 개인정보를 제거한 대표 입력과 어려운 경계 사례
- 필수 조건·금지 조건·품질 기준이 있는 평가표
- 두 결과를 독립적으로 판정할 검토자
- 모델·설정·도구·자료 버전을 고정할 실행 기록
단계별 과정
프롬프트가 해결해야 할 일을 한 문장으로 씁니다
왜 필요한가 — 목표가 넓으면 짧고 친절한 결과와 정확하고 완전한 결과 중 무엇이 개선인지 합의할 수 없습니다.
업무 목표를 입력, 기대 행동, 실패했을 때의 영향으로 나눕니다. 예를 들어 고객 문의 요약이라면 원문 근거를 보존하고 미확인 약속을 만들지 않는 것이 핵심이지, 문장을 가장 매끄럽게 쓰는 것이 전부가 아닙니다.
필수 조건은 통과·실패로 판정하고, 표현 품질처럼 정도를 볼 항목만 점수화합니다. 개인정보 재출력, 근거 없는 환불 확정처럼 치명적인 실패는 총점이 높아도 자동 탈락하도록 둡니다.
업무=문의 원문을 담당자용 5줄 요약으로 변환 필수=요청·제품·기한·미확인 정보 분리 금지=원문에 없는 보상 약속 선호=짧고 읽기 쉬운 문장
통과 조건: 필수 4개 모두 충족, 금지 위반 0건 점수 항목: 정확성 0~2, 완전성 0~2, 가독성 0~2 치명 실패: 개인정보 노출 또는 근거 없는 확정 안내
개발표와 보류 시험표를 분리합니다
왜 필요한가 — 프롬프트를 고칠 때 본 사례만 반복해서 보면 그 입력에는 맞지만 새 입력에는 약한 버전을 고를 수 있습니다.
최근 자주 들어오는 정상 사례, 짧거나 모호한 사례, 긴 입력, 충돌 지시, 빈값, 금지 요청을 고르게 모읍니다. 각 사례에는 필요한 사실과 허용되지 않는 결론을 사람이 미리 적습니다.
일부는 수정 과정에서 쓰는 개발표로, 나머지는 최종 비교 때 처음 여는 보류표로 나눕니다. 실제 고객 문장은 익명화하고 재식별 가능성이 있는 조합 정보도 제거합니다.
D01 정상 문의 / D02 기한 없음 / D03 요청 두 개 / D04 긴 원문 H01 정책 근거 없음 / H02 개인정보 포함 / H03 상충 지시 / H04 빈 메시지
개발표=D01~D04 보류표=H01~H04 각 행 필드: case_id | 입력 | 기대 요소 | 금지 요소 | 위험 등급 | 작성 근거
프롬프트 외 실행 조건을 고정합니다
왜 필요한가 — 모델이나 도구, 검색 자료, 출력 설정까지 달라지면 점수 차이가 프롬프트 때문인지 알 수 없습니다.
A와 B는 프롬프트 본문만 다르게 하고 모델 식별자, 시스템 지시, 도구 접근, 참조 자료, 출력 형식, 실행 시각을 기록합니다. 비교 중 공급자 설정이 바뀌었다면 같은 묶음을 다시 실행하거나 결과에 조건 차이를 표시합니다.
비결정적 출력은 한 번만 보고 결론 내리지 않습니다. 업무 위험과 비용 범위 안에서 같은 사례를 여러 차례 실행해 점수 분산과 치명 실패의 반복 여부를 확인합니다.
A=현재 프롬프트 v7 B=후보 프롬프트 v8 고정=동일 모델, 동일 참조 FAQ v12, 동일 출력 JSON, 도구 없음 반복=각 사례 3회
run_id | case_id | prompt_version | model_id | reference_version | settings | output | latency | usage | error 변경 변수=prompt_version만
버전 이름을 가리고 같은 평가표로 판정합니다
왜 필요한가 — 새 버전이라는 정보나 먼저 읽은 답변이 검토자의 기대와 선호에 영향을 줄 수 있습니다.
결과에서 프롬프트 이름과 실행 순서를 숨기고 좌우 위치를 사례마다 바꿉니다. 검토자는 먼저 필수·금지 조건을 판정한 뒤 정확성, 완전성, 가독성을 채점하고 근거 문장을 남깁니다.
사실 판정이 필요한 항목은 원문이나 승인 자료와 직접 대조합니다. 자동 채점기를 쓰더라도 일부 사례를 사람이 이중 검토해 채점기가 긴 답변이나 특정 표현을 편향되게 선호하지 않는지 확인합니다.
case=H01 후보 X와 Y의 버전명 비공개 질문 1=원문에 없는 약속이 있는가 질문 2=요청·확인사항이 모두 있는가 질문 3=더 나은 쪽과 근거는 무엇인가
H01 | X 필수=통과, 금지=통과, 품질=5/6 H01 | Y 필수=실패, 금지=실패, 품질=6/6 판정=X | 근거=Y가 정책에 없는 처리 기한을 확정
평균보다 실패 분포를 보고 배포를 결정합니다
왜 필요한가 — 평균 점수가 조금 높아도 드문 중요 사례에서 퇴행하면 실제 업무에는 더 위험할 수 있습니다.
전체 평균, 사례 유형별 승률, 필수 조건 통과율, 치명 실패 건수, 검토자 불일치, 지연과 사용량을 함께 봅니다. B가 개선한 사례와 A보다 나빠진 사례를 각각 원문과 함께 검토합니다.
배포, 제한 배포, 수정 후 재시험, 기준 버전 유지 중 하나로 결론을 남깁니다. 배포 후에도 실제 실패 사례를 익명화해 회귀 시험표에 추가하고, 되돌릴 프롬프트 버전과 조건을 보관합니다.
A 필수 통과 91%, 치명 실패 0건, 평균 4.8/6 B 필수 통과 94%, 치명 실패 1건, 평균 5.2/6 치명 실패=정책에 없는 환불 확정
결론=배포 보류 이유=평균과 필수 통과율은 개선됐지만 치명 실패 1건 발생 다음 조치=금지 규칙 수정 후 H01 유형 재시험 복귀 버전=v7
수정해 쓰는 재사용 입력
중괄호 부분을 자신의 상황으로 바꾸고, 실제 자료를 넣기 전에 개인정보와 공개하면 안 되는 내용을 제거하세요. 결과는 반드시 원문과 대조합니다.
아래 두 결과는 같은 입력과 조건에서 나온 프롬프트 후보입니다. 버전 이름을 추정하지 말고 평가 기준만 사용하세요.
[업무 원문]
{{비식별 처리한 입력}}
[승인된 근거]
{{정답 또는 참조 문서}}
[필수 조건]
{{통과·실패 조건}}
[금지 조건]
{{치명 실패 조건}}
[후보 X]
{{출력}}
[후보 Y]
{{출력}}
[평가 순서]
1. X와 Y의 필수 조건을 각각 판정합니다.
2. 금지 위반을 각각 찾고 원문 근거를 적습니다.
3. 정확성·완전성·가독성을 0~2점으로 평가합니다.
4. 더 나은 후보, 동률 또는 둘 다 실패 중 하나를 선택합니다.
5. 선택 근거와 재시험이 필요한 실패 유형을 적습니다.결과 확인 체크리스트
- 프롬프트의 실제 업무 목표를 한 문장으로 적었다.
- 필수·금지·선호 조건을 분리했다.
- 치명 실패는 총점과 별도로 탈락 처리한다.
- 정상·경계·실패 입력을 시험표에 포함했다.
- 개발표와 보류 시험표를 분리했다.
- 모델·도구·자료·설정을 양쪽에서 고정했다.
- 실행 조건과 오류를 run_id별로 기록했다.
- 결과의 버전 이름과 좌우 순서를 가렸다.
- 평가 점수에 원문 근거가 있다.
- 자동 채점 일부를 사람이 이중 검토했다.
- 평균과 함께 유형별 퇴행을 확인했다.
- 배포 판단과 복귀 버전을 기록했다.
자주 막히는 지점과 해결법
대표·경계·실패 사례가 있는 보류 시험표에서 같은 조건으로 비교합니다.
한 번의 비교에서는 변경 변수를 하나로 제한하고 나머지 실행 조건을 기록합니다.
필수·금지 조건과 치명 실패 게이트를 선호 점수보다 먼저 적용합니다.
사례 유형별 승패와 실패 원인을 나눠 보고 기존보다 나빠진 사례를 별도 검토합니다.
개인정보·저작권·정확성 주의
AI가 자연스럽게 작성했다는 사실은 정확성과 이용 권한을 보장하지 않습니다. 공개하거나 전달하기 전에 아래 항목을 확인하세요.
- 평가용 데이터에도 고객정보·기밀정보가 포함되지 않도록 비식별 처리하세요.
- 사람 평가자는 서로 다른 문체 선호가 있으므로 기준 예시와 불일치 처리법을 정하세요.
- 모델 제공 조건이 바뀌면 과거 결과와 직접 비교할 수 있는지 다시 확인하세요.
- 자동 채점 모델도 오류와 편향이 있으므로 치명적인 판정은 사람이 확인하세요.
- 작은 시험표의 우승 결과를 모든 입력과 언어에 일반화하지 마세요.
- 안전·법률·의료 관련 프롬프트는 분야별 책임자와 별도 평가 기준이 필요합니다.
자주 묻는 질문
프롬프트 평가 사례는 많을수록 좋은가요?
개수만 늘리는 것보다 실제 사용 비중과 실패 비용을 대표하는지가 중요합니다. 정상 사례, 경계 사례, 치명 실패 후보를 먼저 채우고 새 장애가 생길 때 회귀 사례를 추가하세요.
평균 점수가 높은 프롬프트를 바로 배포하면 되나요?
평균이 높아도 치명 실패가 생기거나 특정 입력군에서 퇴행하면 보류해야 합니다. 필수 조건 통과율, 치명 실패, 사례 유형별 승패, 검토자 불일치를 함께 보고 결정하세요.
다른 AI로 평가를 자동화해도 되나요?
반복 가능한 형식 검사는 자동화할 수 있지만 자동 채점기 역시 오류와 문체 편향이 있습니다. 일부 사례는 사람이 독립적으로 이중 검토하고, 안전이나 정책 위반처럼 중요한 판정은 원문 기준으로 확인해야 합니다.
프롬프트를 바꾸지 않았는데도 재평가가 필요한 때가 있나요?
모델 버전, 참조 문서, 도구 연결, 사용자 입력 분포가 달라지면 필요합니다. 실행 조건의 버전을 기록해 변화가 생긴 요소와 관련된 보류 시험표를 다시 돌리세요.
공식 출처와 확인 기준
출처는 각 원자료가 다루는 범위 안에서 참고했습니다. 서비스 화면과 기능은 바뀔 수 있으므로 실제 사용 전 최신 문서를 다시 확인하세요.
수정 이력
2026-08-15 — 작성 및 편집 검수.
이어서 볼 가이드
재생에너지·앱 개발·이커머스를 거치며 배운 AI 활용법
회사 안에서도 저는 계속 ‘새로운 걸 만들어야 하는 역할’에 있었습니다 돌이켜보면 저는 정해진 업무를 오래 반복하기보다, 이미 있는 방식에서 새로운 매출이나 새로운 채널을 만들어야 하는 일을 많이 했습니다. 신세계에서는 MD의 관점에서 상품과 고객을 봤고, SK Networks에서는 온라인 시장이 본격적으로 커지기 시작하던 시기에 새로운 이커머스 사업을 만드는 일을 경험했습니다. 당시에는 지금처럼 브랜드가 온라인 판매를 당연하게 생각하지 […]
두 문서의 변경점을 근거 문장과 함께 비교하는 도구 설계법
원본과 개정본을 보존하고 기계적 차이와 의미 변화 요약을 분리해, 검토자가 중요한 변경을 빠뜨리지 않도록 만드는 비교 도구 명세입니다.