<aside>
주요 평가 지표의 측정방법
| 구분 | 평가 지표 | 측정방법 |
|---|---|---|
| 1. 정확성 | 생성된 테스트가 요구사항을 정확하게 반영하는 정도 | 생성된 테스트 케이스가 요구사항을 모두 커버하는가? |
| 2. 완전성 | 모든 필요한 테스트 시나리오를 포함하는지 여부 | 요구사항과 예상 시나리오가 일치하는가? |
| 3. 정밀도 | 실제로 유용한 테스트 케이스의 비율 | 생성된 결과물이 작업과 관련성이 높고 불필요한 정보가 없는가? |
| 4. 맥락 적합성 | 도메인 특화 요구사항 충족도 | 출력물이 소프트웨어의 도메인 특화 요구사항에 부합하는가? (예: 이커머스 결제 시스템) |
| 5. 다양성 | 일반 및 엣지 케이스를 포함한 시나리오 범위 | 엣지 케이스를 포함한 다양한 시나리오를 반영하는가? |
| 6. 실행 성공률 | 오류 없이 실행 가능한 테스트 비율 | 생성된 테스트 스크립트가 구문 오류 없이 성공적으로 실행되는가? |
| 7. 시간 효율성 | 수동 작업 대비 시간 절약 정도 | 수동 작업 대비 시간 절약 효과가 있는가? |
| </aside> |
<aside>
프롬프트 품질 개선 프로세스 절차 ① 반복적 수정 → ② A/B 테스트 → ③ 오류 분석 → ④ 사용자 피드백 통합 → ⑤ 길이와 구체성 조정
</aside>
<aside>
프롬프트 품질 개선 절차 상세 내용
| 구분 | 설명 | 기대효과 |
|---|---|---|
| 1. 반복적 프롬프트 수정 | 기본 프롬프트에서 시작해 결과에 따라 점진적으로 개선 | 맥락 추가와 단어 선택 조정을 통한 구체성 향상 |
| 2. 프롬프트 A/B 테스트 | 여러 버전의 프롬프트 생성 및 성능 비교 | 사전 정의된 지표를 기반으로 최적 버전 선택 |
| 3. 오류 분석 | 부정확성이나 일관성 부족 패턴 분석 | 동일 오류 재발 방지를 위한 프롬프트 개선 |
| 4. 사용자 피드백 통합 | QA 엔지니어와 테스터의 실무 피드백 수집 | 실제 테스팅 요구사항을 반영한 프롬프트 개선 |
| 5. 프롬프트 길이와 구체성 조정 | 다양한 길이와 상세 수준 실험 | 맥락과 일반화 사이의 균형점 찾기 |
| </aside> |
<aside>
기대 성과
</aside>
프롬프트 엔지니어링 실행 프로세스
본 프로세스는 순환적(iterative)으로 반복되며, 각 단계의 결과를 바탕으로 지속적으로 개선됩니다.
단계별 실행 방법
| 단계 | 실행 방법 | 적용 예시 |
|---|---|---|
| 1단계: 초기 프롬프트 작성 | 테스트 목적과 범위를 명확히 정의하여 기본 프롬프트 작성 | "이커머스 결제 시스템의 결제 실패 시나리오에 대한 테스트 케이스 생성" |
| 2단계: 결과 평가 | 위의 7가지 평가 지표를 활용하여 생성 결과 평가 | 정확성 85%, 완전성 70% → 개선 필요 영역 식별 |
| 3단계: 프롬프트 개선 | 평가 결과를 바탕으로 프롬프트 수정 및 재실행 | 맥락 추가: "PG사 API 타임아웃, 네트워크 오류 포함" |
| 4단계: 검증 및 배포 | 개선된 프롬프트로 여러 차례 테스트 후 실무 적용 | 3회 이상 반복 테스트 후 템플릿으로 저장 |
💡 Prompt Engineering Lifecycle 시각화
아래 다이어그램으로 전체 프로세스를 확인할 수 있습니다:
graph LR
A["프롬프트 작성"] --> B["결과 생성"];
B --> C["평가 및 분석"];
C --> D{"목표 달성?"};
D -- 아니오 --> E["프롬프트 개선"];
E --> A;
D -- 예 --> F["배포 및 모니터링"];
F --> G["피드백 수집"];
G --> A;
주요 용어 설명