프롬프트 예시

프롬프트 엔지니어링 교육자료
잘못된 프롬프트와 개선된 프롬프트 10개
========================================

[예제 1] 업무 보고서 작성 — 역할과 목적의 불명확성

■ 잘못된 프롬프트
최근 철도역 고객 서비스 개선에 대한 보고서를 작성해줘. 고객들이 불편해하는 부분을 분석하고, 개선할 방법을 제시해줘. 실제로 적용할 수 있는 방안을 중심으로 작성하고 보고서 형식으로 만들어줘.

■ 문제점
보고 대상, 분석 기간, 근거 데이터, 보고서 구성 등이 불명확하여 일반적인 개선 의견이나 근거 없는 현황이 생성될 수 있습니다.

■ 개선된 프롬프트
당신은 철도 운영기관의 고객서비스 개선 및 경영보고서 작성 전문가입니다.

[배경]
철도역 고객 서비스 품질을 개선하기 위해 최근 3개월간의 고객 불편사항을 분석하고, 운영부서 관리자에게 개선방안을 보고하려고 합니다.

[입력자료]
- 고객 민원 데이터: [민원 목록 입력]
- 역사 운영 현황: [운영 현황 입력]
- 분석 대상 기간: [시작일~종료일]

[요청사항]
1. 민원을 안내, 시설, 승차권, 직원 응대, 기타로 분류합니다.
2. 유형별 발생 건수와 비율을 계산합니다.
3. 주요 불편 원인과 반복 발생 문제를 분석합니다.
4. 단기(1개월), 중기(3개월), 장기(6개월) 개선방안을 제시합니다.
5. 개선방안마다 담당부서, 필요 자원, 예상 효과, 성과지표를 작성합니다.
6. 우선순위를 영향도와 실행 용이성을 기준으로 평가합니다.

[제약조건]
- 제공되지 않은 민원 건수나 성과 수치를 임의로 생성하지 마세요.
- 원인에 대한 근거가 부족하면 추정이라고 표시하세요.
- 데이터가 부족한 항목은 추가 확인 필요로 표시하세요.

[출력형식]
1. 보고서 제목 및 요약
2. 고객 불편 현황
3. 주요 문제 및 원인
4. 개선방안 비교표
5. 단계별 실행계획
6. 기대효과 및 추가 확인사항

관리자 보고용으로 전문적이고 간결한 한국어로 작성하세요.

■ 교육 포인트: Role + Context + Task + Constraints + Output

========================================
[예제 2] 고객 민원 분석 — 분류 기준의 부재

■ 잘못된 프롬프트
다음 고객 민원들을 분석해서 유형별로 분류하고, 중요한 민원을 찾아줘. 비슷한 내용은 하나로 묶고 각 민원의 심각도를 판단해줘. 마지막으로 어떤 민원부터 처리해야 하는지도 알려줘.

■ 문제점
분류 기준, 심각도 평가 규칙, 중복 판단 기준이 없으므로 같은 민원도 실행할 때마다 다르게 분류될 수 있습니다.

■ 개선된 프롬프트
당신은 철도 고객 민원 분석 담당자입니다.

[분석 목적]
고객 민원을 일관된 기준으로 분류하고, 안전 및 서비스 품질에 영향을 미치는 민원을 우선 처리하기 위한 분석 결과를 작성합니다.

[입력 데이터]
[민원 목록 입력]

[분류 기준]
- 안전: 사고 위험, 시설 고장, 승객 안전
- 시설: 냉난방, 화장실, 승강설비, 편의시설
- 운행: 지연, 운행 변경, 열차 관련 불편
- 안내: 안내방송, 표지판, 정보 전달
- 서비스: 직원 응대, 고객 지원
- 기타: 위 항목에 해당하지 않는 민원

[심각도 기준]
- 긴급: 즉각적인 안전 위험이 의심되는 경우
- 높음: 서비스 중단 또는 다수 고객에게 중대한 영향을 주는 경우
- 보통: 일반적인 서비스 불편
- 낮음: 개선 제안 또는 경미한 불편

[요청사항]
1. 모든 민원에 고유 번호를 부여합니다.
2. 민원별 대표 유형을 하나 선정합니다.
3. 유형 선정 이유를 작성합니다.
4. 심각도를 판정하고 판단 근거를 제시합니다.
5. 동일한 사건으로 판단되는 중복 민원을 식별합니다.
6. 긴급도, 영향 범위, 발생 빈도를 고려하여 처리 우선순위를 제안합니다.
7. 유형별 건수 및 비율을 집계합니다.
8. 유형별 대표 개선방안을 작성합니다.

[제약조건]
- 민원 원문에 없는 사실을 추가하지 마세요.
- 안전 위험이 불명확한 경우 확인 필요로 표시하세요.
- 중복 여부가 확실하지 않으면 유사 민원으로만 표시하세요.
- 모든 원본 민원이 결과에 포함되어야 합니다.

[출력형식]
민원번호 | 민원 요약 | 분류 | 심각도 | 판단 근거 | 처리 우선순위

마지막에 유형별 통계표와 개선방안 요약을 추가하세요.

■ 교육 포인트: Classification + Criteria + Consistency

========================================
[예제 3] 회의록 요약 — 핵심 정보의 손실

■ 잘못된 프롬프트
다음 회의 내용을 간단하게 요약해줘. 중요한 내용을 중심으로 정리하고, 회의에서 결정된 사항과 앞으로 해야 할 일도 작성해줘. 너무 길지 않게 정리하고 보기 좋게 만들어줘.

■ 문제점
짧게 요약하라는 요구와 중요 정보를 빠짐없이 보존해야 한다는 요구가 충돌할 수 있습니다. 담당자나 기한을 임의로 만들어낼 위험도 있습니다.

■ 개선된 프롬프트
당신은 프로젝트 관리 및 공식 회의록 작성 전문가입니다.

[목적]
회의 원문을 기반으로 결정사항, 미결사항, 후속 조치를 누락 없이 정리하여 참석자와 관계부서에 공유합니다.

[회의 정보]
- 회의명: [입력]
- 회의일시: [입력]
- 참석자: [입력]
- 회의 원문: [입력]

[작성 절차]
1. 회의의 주요 안건을 식별합니다.
2. 안건별 논의 배경과 핵심 의견을 요약합니다.
3. 최종 결정된 사항만 별도로 추출합니다.
4. 합의되지 않은 사항은 미결사항으로 분리합니다.
5. 후속 조치(Action Item)를 추출합니다.
6. 각 조치의 담당자, 기한, 산출물을 정리합니다.
7. 추가 협의가 필요한 항목을 구분합니다.

[필수 규칙]
- 확정되지 않은 의견을 결정사항으로 작성하지 마세요.
- 담당자와 기한이 언급되지 않았다면 미정으로 작성하세요.
- 중요한 수치, 일정, 금액, 고유명사는 원문을 유지하세요.
- 회의 원문에 없는 새로운 결정사항을 만들지 마세요.
- 요약하더라도 결정사항과 후속 조치는 누락하지 마세요.

[출력형식]
1. 회의 개요
2. 핵심 요약(5문장 이내)
3. 안건별 논의 내용
4. 확정된 결정사항
5. 미결사항
6. 후속 조치 표
   - 작업 | 담당자 | 완료기한 | 산출물 | 상태
7. 추가 확인사항

후속 조치의 누락 여부를 마지막에 점검하세요.

■ 교육 포인트: Information Preservation + Structured Summarization

========================================
[예제 4] 데이터 분석 — 근거 없는 수치 생성

■ 잘못된 프롬프트
최근 1년간 KTX 이용객 수와 매출 데이터를 분석해서 월별 증가율과 가장 실적이 좋은 노선을 알려줘. 계절별 특징도 분석하고 내년 이용객 수를 예측해줘. 분석 결과는 숫자를 포함해서 보고서로 작성해줘.

■ 문제점
실제 데이터가 없는데도 수치와 예측값을 요구하므로 LLM이 통계나 매출을 임의로 생성할 가능성이 있습니다.

■ 개선된 프롬프트
당신은 철도 수송실적 및 경영 데이터 분석 전문가입니다.

[분석 목적]
제공된 최근 12개월의 KTX 이용객 및 매출 데이터를 분석하여 운영 실적을 평가하고 다음 연도 수요 전망을 작성합니다.

[입력 데이터]
[CSV 또는 표 데이터 입력]
필수 컬럼:
- 기준월
- 노선명
- 이용객수
- 매출액

[분석 요청]
1. 월별 총 이용객 수와 매출액을 계산합니다.
2. 전월 대비 증감률을 계산합니다.
3. 노선별 이용객 수 및 매출액을 비교합니다.
4. 이용객 수와 매출액 기준 상위 5개 노선을 선정합니다.
5. 분기별 이용 패턴과 변동 요인을 분석합니다.
6. 데이터에서 확인되는 특이값과 이상 변동을 식별합니다.
7. 다음 12개월의 이용객 수를 예측할 수 있는 방법을 제안합니다.
8. 예측이 가능한 경우 가정, 예측값, 불확실성을 함께 제시합니다.

[분석 규칙]
- 제공된 데이터만 이용해 실적 수치를 계산하세요.
- 증가율은 (당월-전월)/전월×100으로 계산하세요.
- 전월 값이 0이면 증가율을 계산 불가로 표시하세요.
- 12개월 데이터만으로 계절성을 확정하지 마세요.
- 예측은 확정 수치가 아니라 가정 기반 전망으로 구분하세요.
- 데이터가 제공되지 않았다면 실제 수치를 생성하지 말고 필요한 데이터를 요청하세요.

[출력형식]
1. 데이터 품질 점검
2. 월별 실적 및 증감률 표
3. 노선별 실적 순위
4. 주요 분석 결과
5. 예측 방법 및 전망
6. 경영 시사점
7. 분석 한계

모든 계산 결과에 사용한 기준을 명시하세요.

■ 교육 포인트: Grounding + Calculation + Hallucination Prevention

========================================
[예제 5] 고객 안내문 작성 — 확인되지 않은 정책의 단정

■ 잘못된 프롬프트
열차가 40분 지연되었을 때 고객에게 보낼 안내문을 작성해줘. 지연 사유를 설명하고 고객이 받을 수 있는 보상도 안내해줘. 고객이 불만을 갖지 않도록 친절하고 확신 있는 문장으로 작성해줘.

■ 문제점
지연 사유와 보상 규정이 제공되지 않았음에도 구체적인 원인과 보상액을 확정해 작성할 위험이 있습니다.

■ 개선된 프롬프트
당신은 철도 운영기관의 고객 안내 및 공지문 작성 담당자입니다.

[상황]
열차가 예정 시각보다 40분 지연되어 고객에게 상황을 안내해야 합니다.

[확인된 정보]
- 열차번호: [입력]
- 운행 구간: [입력]
- 지연 시간: 40분
- 지연 사유: [확인된 내용 입력 또는 미확인]
- 예상 도착시각: [입력 또는 미정]
- 적용 가능한 보상 규정: [공식 규정 입력 또는 미확인]

[작성 요청]
1. 고객에게 지연 상황을 명확하게 전달합니다.
2. 확인된 지연 사유가 있으면 설명합니다.
3. 예상 도착시각이 확인되었다면 안내합니다.
4. 고객 불편에 대한 사과 문구를 포함합니다.
5. 보상 대상 여부와 확인 방법을 안내합니다.
6. 추가 정보를 확인할 수 있는 공식 안내 경로를 제시합니다.

[제약조건]
- 확인되지 않은 지연 사유를 추측하지 마세요.
- 보상 비율이나 금액을 임의로 작성하지 마세요.
- 보상 규정이 없다면 보상 여부 확인이 필요하다고 안내하세요.
- 실제로 확인되지 않은 복구 완료 시각을 약속하지 마세요.
- 불필요한 전문용어를 사용하지 마세요.

[출력형식]
① 역사 안내방송용(약 30초)
② 고객 문자 안내용(150자 내외)
③ 고객센터 상담용(상세 안내)
④ 담당자가 발송 전 확인해야 할 항목

고객이 이해하기 쉬운 정중한 한국어를 사용하세요.

■ 교육 포인트: Factual Accuracy + Uncertainty Handling

========================================
[예제 6] 업무 개선안 — 실행 가능성의 부재

■ 잘못된 프롬프트
역사 내 고객 대기시간을 줄이기 위한 개선방안을 10개 만들어줘. 최신 AI 기술도 적용하고 비용을 절감할 수 있는 방법으로 작성해줘. 가능한 한 혁신적인 아이디어를 제시하고 실무에서 바로 적용할 수 있게 해줘.

■ 문제점
예산, 인력, 시스템, 운영 제약을 고려하지 않아 실현 가능성이 낮은 개선방안이 나올 수 있습니다.

■ 개선된 프롬프트
당신은 철도역 운영 효율화 및 AI 기반 업무혁신 컨설턴트입니다.

[프로젝트 목적]
역사 내 고객 대기시간을 줄이면서 기존 운영비용의 증가를 최소화하는 개선방안 10개를 도출합니다.

[운영 환경]
- 대상 역사: [입력]
- 주요 혼잡 구역: [입력]
- 기존 인력: [입력]
- 현재 대기시간: [입력]
- 활용 가능한 시스템: [입력]
- 가용 예산: [입력]
- 목표 개선 기간: 6개월

[요청사항]
1. 대기시간 발생 원인을 고객 동선, 인력 배치, 안내, 시스템 측면으로 분석합니다.
2. 개선방안 10개를 제안합니다.
3. AI를 활용하는 방안과 일반적인 운영 개선방안을 구분합니다.
4. 각 방안의 적용 대상과 작동 방식을 설명합니다.
5. 예상 도입비용과 운영비용의 산정 방법을 제시합니다.
6. 실행 난이도, 기대효과, 위험요인을 평가합니다.
7. 1개월 이내 가능한 Quick Win을 식별합니다.
8. 우선 추진할 3개 과제를 선정합니다.
9. 6개월 단계별 추진 일정을 작성합니다.
10. 대기시간 감소율과 고객 만족도 등 성과지표를 정의합니다.

[제약조건]
- 확인되지 않은 비용 절감률을 확정적으로 작성하지 마세요.
- 기존 시스템 연계가 필요한 경우 전제조건을 명시하세요.
- 안전 규정과 개인정보 보호를 고려하세요.
- 예산이나 운영 정보가 없으면 가정을 표시하세요.

[출력형식]
문제 분석 → 개선방안 10개 비교표 → 우선순위 평가 → 핵심 3개 과제 → 실행 일정 → KPI

실무 담당자가 검토할 수 있는 구체적인 실행방안으로 작성하세요.

■ 교육 포인트: Feasibility + Constraints + Prioritization

========================================
[예제 7] Python 코드 생성 — 실행환경 및 예외처리 누락

■ 잘못된 프롬프트
Python으로 철도 고객 민원 CSV 파일을 읽고 분석하는 프로그램을 만들어줘. 민원 유형별 건수를 계산하고 그래프를 그려줘. 사용자가 파일을 선택할 수 있게 하고 결과를 엑셀로 저장할 수 있게 해줘. 코드도 이해하기 쉽게 작성해줘.

■ 문제점
실행환경, 입력 데이터 형식, 파일 처리, 예외 상황, 출력 조건이 정의되지 않아 코드가 실행되지 않거나 예상과 다르게 동작할 수 있습니다.

■ 개선된 프롬프트
당신은 Python, Pandas, Streamlit을 활용한 업무용 데이터 분석 애플리케이션 개발자입니다.

[개발 목적]
철도 고객 민원 CSV 파일을 업로드하여 민원 유형별 발생 건수를 분석하고 시각화한 뒤 Excel 파일로 다운로드할 수 있는 웹앱을 구현합니다.

[개발환경]
- Python 3.11 이상
- Streamlit
- Pandas
- Matplotlib
- OpenPyXL
- Windows 환경
- VS Code 또는 JupyterLab에서 개발
- 실행은 Streamlit 명령어 사용

[입력 데이터]
CSV 파일 컬럼:
- 접수일자
- 민원번호
- 민원유형
- 민원내용
- 처리상태

[필수 기능]
1. Streamlit 파일 업로드 기능
2. CSV 파일 읽기
3. UTF-8 및 CP949 인코딩 처리
4. 필수 컬럼 존재 여부 검사
5. 결측값 및 중복 민원번호 확인
6. 민원 유형별 건수 계산
7. 유형별 비율 계산
8. 막대그래프 시각화
9. 처리상태별 현황 분석
10. 분석 결과 Excel 다운로드

[예외처리]
- 파일 미업로드
- 잘못된 파일 형식
- 인코딩 오류
- 필수 컬럼 누락
- 빈 데이터
- 데이터 처리 오류

[코드 작성 규칙]
- 전체 실행 가능한 코드를 작성하세요.
- 모든 주요 함수에 한글 주석을 추가하세요.
- 초보자가 이해할 수 있도록 함수별 역할을 설명하세요.
- 필요한 패키지 설치 명령어를 작성하세요.
- 임의의 컬럼을 가정해 사용하지 마세요.
- 오류 발생 시 사용자에게 이해하기 쉬운 메시지를 출력하세요.

[출력형식]
1. 프로젝트 폴더 구조
2. 패키지 설치 명령어
3. 전체 Python 소스코드
4. 실행 명령어
5. 테스트용 CSV 예시
6. 주요 기능 설명
7. 정상 및 오류 테스트 시나리오

■ 교육 포인트: Specification + Environment + Exception Handling

========================================
[예제 8] 업무 문서 비교 — 비교 기준의 불명확성

■ 잘못된 프롬프트
두 개의 업무 지침서를 비교해서 무엇이 달라졌는지 알려줘. 중요한 변경사항을 정리하고 실제 업무에 어떤 영향을 주는지도 설명해줘. 바뀐 내용을 표로 만들고 직원들이 주의해야 할 사항도 작성해줘.

■ 문제점
단순 문장 차이와 실질적인 정책 변경을 구분하지 못하거나, 문서에 없는 업무 영향까지 단정할 수 있습니다.

■ 개선된 프롬프트
당신은 기업 업무 규정 및 운영 지침 변경사항 분석 전문가입니다.

[분석 목적]
기존 업무 지침서와 개정 지침서를 비교하여 변경된 규정과 실무 영향도를 파악합니다.

[입력 문서]
- 기존 지침서: [문서 A]
- 개정 지침서: [문서 B]

[비교 항목]
1. 적용 대상
2. 업무 절차
3. 담당부서 및 책임
4. 승인 절차
5. 처리 기한
6. 필수 제출서류
7. 예외 및 제한사항
8. 시행일 및 경과조치

[분석 요청]
1. 두 문서의 버전과 시행일을 확인합니다.
2. 기존 조항과 개정 조항을 대응시킵니다.
3. 변경사항을 신설, 수정, 삭제, 유지로 분류합니다.
4. 문구만 달라진 항목과 실질적인 규정 변경을 구분합니다.
5. 각 변경사항이 실무에 미치는 영향을 분석합니다.
6. 직원 교육이나 시스템 수정이 필요한 항목을 식별합니다.
7. 변경사항 중 중요도가 높은 항목을 선정합니다.
8. 추가 검토가 필요한 모호한 조항을 제시합니다.

[제약조건]
- 원문에 없는 조항을 생성하지 마세요.
- 조항 번호와 문서 위치를 가능한 범위에서 표시하세요.
- 확인되지 않은 법적 효과를 확정하지 마세요.
- 대응되는 조항을 찾지 못하면 비교 불가로 표시하세요.

[출력형식]
1. 문서 비교 개요
2. 주요 변경사항 요약
3. 조항별 비교표
   - 항목 | 기존 내용 | 개정 내용 | 변경 유형 | 실무 영향
4. 중요 변경사항 TOP 5
5. 부서별 대응 필요사항
6. 추가 확인사항

■ 교육 포인트: Comparison Criteria + Traceability + Evidence

========================================
[예제 9] AI 서비스 기획 — 요구사항과 구현 범위의 불명확성

■ 잘못된 프롬프트
철도 고객 문의에 자동으로 답변하는 AI Agent 서비스를 기획해줘. LLM과 RAG를 사용하고 필요하면 외부 API도 호출하게 해줘. 직원 업무도 줄이고 고객 만족도도 높일 수 있게 만들고 시스템 구성도와 개발 일정도 작성해줘.

■ 문제점
사용 대상, 기능 범위, 데이터, 연계 시스템, 보안 및 운영 조건이 없어 과도한 기능을 제안하거나 실현하기 어려운 일정이 만들어질 수 있습니다.

■ 개선된 프롬프트
당신은 철도 업무 분야의 AI Agent 및 RAG 서비스 아키텍트입니다.

[기획 목적]
철도 고객의 반복 문의에 자동으로 답변하고 필요시 담당 직원에게 연결하는 AI 고객지원 서비스를 기획합니다.

[서비스 대상]
- 일반 철도 이용 고객
- 고객센터 상담 직원
- 서비스 운영 관리자

[주요 기능]
1. 자연어 고객 질문 입력
2. 질문 의도 분류
3. 철도 이용 안내문서 RAG 검색
4. LLM 기반 답변 생성
5. 답변 근거 및 출처 표시
6. 승인된 외부 API를 통한 실시간 정보 조회
7. 답변 불가능 시 상담원 연결
8. 관리자용 이용현황 및 오류 모니터링

[설계 요청]
1. 현행 업무 문제를 정의합니다.
2. 사용자별 요구사항을 작성합니다.
3. 핵심 기능과 선택 기능을 구분합니다.
4. Agent와 Tool의 역할을 정의합니다.
5. RAG 문서 수집, 청킹, 임베딩, 검색 흐름을 설계합니다.
6. 외부 API 연계 구조를 설계합니다.
7. Frontend, Backend, LLM, Vector DB 구성도를 작성합니다.
8. 개인정보 및 접근권한 관리 방안을 정의합니다.
9. Hallucination 방지와 상담원 이관 기준을 정의합니다.
10. MVP 개발 범위와 단계별 일정을 작성합니다.
11. 예상 인력, 주요 위험, 테스트 항목을 제시합니다.
12. 서비스 품질 및 운영 KPI를 정의합니다.

[제약조건]
- 실제 API 사용 가능 여부가 확인되지 않았다면 연계 예정으로 표시하세요.
- 고객 개인정보를 불필요하게 LLM에 전달하지 마세요.
- AI 답변만으로 민감한 업무 처리를 확정하지 마세요.
- 예산과 일정은 가정에 기반한 추정치로 구분하세요.
- MVP에서 구현할 기능과 향후 확장 기능을 분리하세요.

[출력형식]
1. 서비스 개요
2. 문제 및 추진 배경
3. 사용자 요구사항
4. 기능 요구사항
5. Agent 및 Tool 설계
6. RAG 구성
7. 시스템 아키텍처
8. 데이터 및 보안 설계
9. 개발 일정 및 투입 인력
10. 위험요인 및 대응방안
11. 기대효과 및 KPI

실제 프로젝트 기획서에 활용할 수 있도록 구체적으로 작성하세요.

■ 교육 포인트: Requirement Engineering + Architecture + Scope Control

========================================
[예제 10] 복합 업무 지시 — 지시 충돌과 처리 순서

■ 잘못된 프롬프트
고객 민원 데이터를 분석해서 모든 문제를 찾아주고, 원인을 파악한 뒤 개선방안을 만들어줘. 결과는 최대한 짧게 작성하지만 모든 내용을 자세히 포함해줘. 정확한 통계도 작성하고 미래 민원 발생 건수도 예측해줘. 데이터가 없어도 적절하게 판단해서 완성된 보고서를 작성해줘.

■ 문제점
짧지만 모든 내용을 상세히 작성하라는 충돌이 있으며, 데이터 없이 정확한 통계를 만들라는 지시도 포함되어 있습니다. 작업 순서와 필수 검증 조건도 없습니다.

■ 개선된 프롬프트
당신은 고객 서비스 데이터 분석 및 업무 개선 보고서 작성 전문가입니다.

[최종 목표]
고객 민원 데이터를 분석하여 주요 문제, 발생 원인, 개선방안, 향후 대응계획을 포함한 관리자 보고서를 작성합니다.

[입력 데이터]
- 민원 데이터: [입력]
- 분석 기간: [입력]
- 관련 운영 정보: [입력]

[작업 순서]

1단계. 데이터 검증
- 입력 데이터 존재 여부 확인
- 컬럼 및 데이터 형식 확인
- 결측값과 중복값 확인
- 분석 가능한 범위 정의

2단계. 민원 현황 분석
- 유형별 발생 건수 계산
- 월별 발생 추이 분석
- 반복 민원 식별
- 심각도 및 우선순위 평가

3단계. 문제 원인 분석
- 주요 문제 5개 선정
- 각 문제의 원인 후보 작성
- 데이터로 확인된 원인과 추정 원인 구분
- 추가 확인이 필요한 자료 제시

4단계. 개선방안 수립
- 문제별 개선방안 작성
- 단기 및 중장기 과제 분류
- 담당부서와 필요 자원 제안
- 기대효과와 KPI 정의

5단계. 향후 전망
- 시계열 데이터의 충분성 평가
- 예측 가능 여부 판단
- 가능하면 가정과 한계를 명시한 전망 제시
- 불가능하면 필요한 데이터와 예측 방법 제안

6단계. 최종 보고서 작성
- 경영진 요약
- 주요 통계
- 핵심 문제
- 원인 분석
- 개선방안
- 실행계획
- 위험 및 한계

[우선 적용 규칙]
1. 사실의 정확성을 문장 길이보다 우선합니다.
2. 데이터가 없으면 수치를 생성하지 않습니다.
3. 요약은 간결하게 작성하되 필수 분석 항목은 생략하지 않습니다.
4. 원인 분석 시 사실과 추정을 구분합니다.
5. 통계 결과는 계산 근거를 포함합니다.
6. 실행계획은 현실적인 조건을 고려합니다.

[출력형식]
- 경영진 요약: 5문장 이내
- 상세 분석: 항목별 표와 설명
- 개선방안: 우선순위 표
- 실행계획: 단계별 일정표
- 분석 한계: 별도 섹션

[최종 검증]
보고서를 작성한 뒤 다음 사항을 확인하세요.
- 입력 데이터에 없는 수치가 포함되었는가?
- 요청한 분석 항목이 누락되었는가?
- 사실과 추정이 구분되었는가?
- 개선방안에 실행 주체와 성과지표가 있는가?
- 결론이 분석 근거와 일치하는가?

검증 결과 발견된 문제는 수정한 뒤 최종 보고서를 출력하세요.

■ 교육 포인트: Task Decomposition + Instruction Priority + Self-Verification

 

 

 

 

프롬프트 엔지니어링: 프롬프트는 길게 작성하면 되는가?
================================================

아닙니다. 프롬프트 엔지니어링의 핵심은 길게 작성하는 것이 아니라, AI가 정확히 이해하고 수행할 수 있도록 요청을 명확하게 설계하는 것입니다.

앞서 제시한 개선 프롬프트가 길었던 이유는 교육 목적으로 구성요소를 모두 보여주기 위해서입니다. 실제 업무에서는 더 짧게 작성해도 충분히 좋은 결과를 얻을 수 있습니다.

1. 긴 프롬프트와 좋은 프롬프트의 차이
--------------------------------
- 짧고 모호한 프롬프트: 목적과 조건이 불분명 → 개선 필요
- 길지만 모호한 프롬프트: 설명은 많지만 핵심 조건이 불명확 → 개선 필요
- 짧고 명확한 프롬프트: 필요한 작업과 조건을 정확히 전달 → 우수
- 길고 체계적인 프롬프트: 복잡한 작업의 요구사항과 검증 기준을 정의 → 복합 업무에 적합

2. 실제 예제로 비교
------------------

① 잘못된 프롬프트
철도 고객 민원을 분석하고 개선방안을 작성해줘.

문제점: 분석 기준, 데이터 범위, 결과 형식이 불명확합니다.

② 길지만 여전히 잘못된 프롬프트
당신은 최고의 철도 전문가입니다. 철도 고객 서비스는 매우 중요하고 고객 만족도는 반드시 높아져야 합니다. 고객의 입장에서 깊이 생각하고 여러 가지 측면을 충분히 검토하여 매우 정확하고 훌륭한 분석을 수행해줘. 모든 문제를 빠짐없이 분석하고 가장 좋은 개선방안을 작성해줘.

문제점: 문장은 길어졌지만 실제 분석 기준과 산출물은 여전히 불명확합니다.

③ 짧지만 잘 설계된 프롬프트
제공한 철도 민원 데이터를 안전·시설·운행·서비스 유형으로 분류하고, 유형별 건수와 비율을 계산해줘. 빈도가 높은 상위 3개 유형의 개선방안을 제시하고, 결과는 표로 작성해줘. 데이터에 없는 사실은 추측하지 마.

장점: 수행 작업, 분류 기준, 출력 형식, 제약조건이 명확합니다.

④ 복잡한 업무에 적합한 구조화 프롬프트
[목적] 철도 고객 민원 개선 우선순위 선정

[입력] 최근 3개월 민원 데이터

[작업]
1. 안전·시설·운행·서비스 유형으로 분류
2. 유형별 건수 및 비율 계산
3. 발생 빈도와 안전 영향을 기준으로 우선순위 선정
4. 상위 3개 문제의 원인과 개선방안 제시

[제약] 없는 데이터는 생성하지 않고, 원인이 불명확하면 확인 필요로 표시

[출력] 유형별 통계표, 우선순위표, 개선방안표

장점: 여러 단계의 업무를 수행하면서도 요구사항과 판단 기준이 누락되지 않습니다.

3. 프롬프트 설계 시 중요한 5가지
--------------------------------
- 목적(Goal): 왜 수행하는가? 예) 민원 개선 우선순위 선정
- 맥락(Context): 어떤 배경과 자료인가? 예) 최근 3개월 철도 민원
- 작업(Task): 무엇을 수행하는가? 예) 분류, 집계, 원인 분석
- 제약(Constraint): 무엇을 지켜야 하는가? 예) 근거 없는 수치 생성 금지
- 출력(Output): 어떤 결과를 원하는가? 예) 통계표와 개선방안표

다섯 가지를 모든 프롬프트에 반드시 넣어야 하는 것은 아닙니다. 결과에 영향을 주는 요소만 선택해서 작성하는 것이 중요합니다.

4. 교육에서 강조해야 할 핵심
---------------------------
프롬프트 품질 ≠ 프롬프트 길이
프롬프트 품질 = 명확한 요청 + 필요한 맥락 + 적절한 제약 + 검증 가능한 결과

프롬프트 엔지니어링 교육에서는 단순히 프롬프트를 길게 만드는 방법보다 다음과 같은 기법을 가르치는 것이 더 효과적입니다.

- Zero-shot / Few-shot: 예시 없이 지시하거나, 예시를 제공해 결과 패턴을 유도
- Role Prompting: 필요한 전문성과 역할 지정
- Task Decomposition: 복잡한 작업을 작은 단계로 분리
- Structured Output: JSON이나 표 등 출력 구조 지정
- Grounding: 제공된 데이터와 문서에 근거하도록 제한
- Self-Verification: 요구사항 누락과 결과의 불일치를 점검

특히 Few-shot은 프롬프트를 길게 만드는 기법이 아니라, AI가 원하는 결과의 패턴을 이해하도록 예시를 제공하는 기법이라는 점을 강조하면 좋습니다.

결론
----
좋은 프롬프트는 길게 설명하는 글이 아니라, AI에게 전달하는 명확한 업무 지시서다.