이전 1부에서는
아래의 관점으로 개념을 정리해보았습니다.
“프롬프트 = 질문, 프롬프트 엔지니어링 = 설계”
이번 2부에서는 그 설계를
굳이 사람이 머리 싸매고 하지 않고,
GPT에게 그대로 맡겼을 때 어떤 차이가 나는지를 실제 사례로 정리해보려고 합니다.
0. 실험 방법 – 딱 이것만 바꿨습니다
실험 방법은 아주 단순합니다.
- 실제 업무에서 제가 하고 싶은 작업을 그대로 정리해둔다.
- Before: 떠오르는 대로 GPT에 “그냥 질문”을 던진다.
- After: GPT에게
“이 작업을 가장 잘 수행할 수 있는 프롬프트를 먼저 설계해 주세요.”
라고 요청한 뒤, 설계된 프롬프트로 다시 작업을 실행한다. - 두 결과를 정확도·구조·재사용성·실무 활용성 기준으로 비교한다.
→ 바꾼 것은 딱 하나입니다.
“결과를 바로 달라”에서
“그 결과를 만드는 프롬프트부터 설계해 달라”로.
1. RAG 성능 평가: 그냥 질문 vs 설계 맡기기
1-1. Before — 그냥 물었을 때
제가 처음 GPT에게 던진 질문은 아주 단순했습니다.
Q. “RAG 성능 평가 기준 알려줘.”
GPT의 답은 대략 이런 식이었습니다. (요약)
- Retrieval: Recall@K, Precision@K, MRR, nDCG 등
- Generation: 정답성, 근거충실도, 인용 정확도, 완전성 등
- UX/운영: Latency, Success rate, Deflection, Cost per query 등
- Safety: PII, 프롬프트 인젝션, 유해 콘텐츠, 어뷰징 대응 등
내용만 보면 틀린 말이 하나도 없습니다.
실제로도 RAG 논문/문서에서 자주 볼 수 있는 구성입니다.
문제는,
- “우리 서비스에 바로 붙여 쓸 수 있는 평가표”는 아니라는 점입니다.
- 결국 지표를 다시 고르고, 정의를 다시 쓰고, 합격선을 다시 잡는 일을 제가 해야 합니다.
정리하면,
Before: 교과서식 개념은 얻었지만,
“실제 프로젝트에 붙여 쓸 수 있는 프레임워크”는 아닌 상태.
1-2. After — GPT에게 ‘프롬프트 설계’를 먼저 시킨 버전
이번에는 접근을 완전히 바꿔봤습니다.
Q. “RAG 시스템 평가를 위한 프레임워크를 만들고 싶습니다.
먼저 이 작업에 최적화된 프롬프트를 설계해 주세요.”
이때 GPT에게 맡긴 역할은
“지식 설명자”가 아니라 “평가 프레임워크 설계자”였습니다.
GPT가 먼저 만들어 준 것은 “평가 프레임워크 템플릿을 만드는 프롬프트”였습니다.
구조만 요약하면 대략 이런 형태입니다.
- 역할(Role): RAG/하이브리드 챗봇 평가 실행자
- 입력(Input)
- {TEMPLATE}: 합의된 평가 프레임워크 템플릿
- {SYSTEM_DESC}: 실제 평가 대상 시스템 설명(도메인, 채널, 정책, 실험 조건 등)
- 출력(Output)
- 평가 스코어카드(표)
- 실패 유형 분류표
- 평가 데이터셋 설계
- A/B 실험 설계 요약
- 실행 체크리스트
- 리스크 Top3 & 이번 주 액션 Top3
즉, GPT에게 이렇게 말한 셈입니다.
“RAG를 잘 평가하는 사람이 된다면,
이 정도는 기본으로 만들어야 하지 않겠습니까?”
그다음 단계에서,
GPT가 설계한 이 프롬프트를 실제 프로젝트 맥락(게임 도메인 CS·AI 챗봇)에 그대로 적용했습니다.
그러자 이번에는 처음부터 “바로 실전에 쓸 수 있는 평가 산출물”이 출력됐습니다.
1-3. After 결과물 스냅샷 – “바로 쓰는 스코어카드”
실제 결과물은 매우 길지만,
핵심만 보여드리면 대략 이런 형태입니다.
🔎 축별 대표 지표 일부 발췌
| 축 | 지표명 | 정의 | 합격선 예시 |
|---|---|---|---|
| Retrieval | Evidence Hit@5 | 정답 근거 문서가 Top-5에 포함된 비율 | Hit@5 ≥ 0.85 |
| Grounding | Hallucination Rate | 근거 없이 정책/절차를 단정한 응답 비율 | ≤ 3% |
| Answer 품질 | Policy Correctness | 환불/제재 등 정책 응답의 정합성 | ≥ 0.98 |
| UX·운영 | Deflection Rate | “정답” 기준 티켓 없이 해결된 세션 비율 | ≥ 0.35 (초기 운영 기준) |
| Safety | Security Abuse Refusal | 부정행위/해킹 유도 요청을 거절한 응답 비율 | ≥ 0.99 |
이 테이블의 중요한 점은:
- 게임 CS 맥락에 맞는 지표 + 정의 + 합격선이 한 번에 잡혀 있고
- “어디서 자주 틀리는지”, “무엇을 먼저 모니터링해야 하는지”가
이미 설계된 상태로 나온다는 것입니다.
그래서 이 결과는
- 제 머릿속 정리 → 메모 → 엑셀 → 문서… 과정을 생략하고,
- 곧바로 대시보드 기획 & 라벨링 설계 단계로 넘어갈 수 있게 해줍니다.
※ 실제로는 스코어카드, 실패 유형 분류표, 데이터셋 설계, A/B 설계 등
모든 산출물이 훨씬 길습니다.
전체 전문은 글 하단 ‘부록’에 구조만 만들어 두었습니다.
(필요하신 분은 그대로 복붙해서 참고하시면 됩니다.)
1-4. Before/After에서 달라진 것들
한 줄로 비교하면 이렇습니다.
- Before:
- “RAG 평가 지표가 뭐가 있는지”는 알게 되지만,
- 결국 내가 다시 구조를 짜야 하는 상태
- After:
- “우리 서비스에 맞는 평가표/실험 설계/체크리스트까지”
- 한 번에 뽑혀 나오는 상태
- Before:
그리고 이 변화는,
모델을 바꾼 것도, 사람을 바꾼 것도 아니라
“그냥 질문했냐” vs “프롬프트 설계부터 맡겼냐”
이 차이에서 나왔습니다.
2. 언제는 그냥 질문만 해도 되는가
여기까지 읽으면
“앞으로는 모든 작업에 다 이렇게 해야 하나?”
라는 생각이 드실 수 있습니다.
제 기준은 이렇습니다.
❌ 굳이 엔지니어링까지 안 해도 되는 경우
- 단발성 정보 조회
- 오늘 점심 메뉴 같은 가벼운 질문
- 짧은 문장 다듬기, 한두 문단 요약
→ 그냥 자유롭게 질문해도 충분합니다.
⭕ 프롬프트 엔지니어링이 확실히 먹히는 경우
- 비슷한 작업을 여러 번 반복하는 경우
- 정확도·재현성이 중요한 경우 (지표/정책/계약/CS 등)
- 팀 차원에서 프롬프트/결과물을 공유해야 하는 경우
이때는 한 번만 제대로 설계해두면,
그 뒤로는 “나 + 팀의 시간”이 같이 줄어듭니다.
3. 마무리 — 설계를 “누가 하느냐”의 문제
정리하면, 프롬프트 엔지니어링은
- 더 좋은 결과를 더 예측 가능하게 얻기 위한 설계이고
- 반드시 사람이 다 할 필요는 없다는 점이 중요합니다.
요즘 방식은 이런 느낌에 가깝습니다.
“GPT야,
이 작업을 가장 잘 수행할 수 있는 프롬프트를
먼저 설계해 줘.”
사람은 요구사항과 맥락만 잘 전달하고,
실제 프롬프트 구조·포맷·샘플 설계는 GPT에게 넘기는 쪽으로 흐름이 바뀌고 있습니다.
프롬프트 엔지니어링은 이제 특정 직군의 전문 기술이라기보다, “AI를 내 도구로 만들고 싶은 사람이라면 누구나 가져갈 수 있는 설계 습관”에 가깝다라고 보여집니다.
이제 프롬프트 엔지니어링은 고민말고 GPT에게 맡기세요.
📘부록: RAG 평가 전체 예시
📎 부록 A. RAG 평가 — Before Q/A 전문
Q:
RAG 성능 평가 기준 알려줘.
A:
RAG 성능 평가는 보통 (1) 검색이 잘 됐는지, (2) 답변이 근거에 붙어있는지, (3) 운영 품질이 괜찮은지 3축으로 봅니다. (지표는 많은데 대시보드는 한 장이죠… 😅)
1) Retrieval (검색 품질)
- Recall@K / Hit rate@K: 정답 근거 문서가 Top-K에 들어왔는지
- Precision@K: Top-K가 “정답에 도움 되는 문서”로 얼마나 깨끗한지
- MRR / nDCG: 정답 근거가 얼마나 위에 랭크되는지
- Chunk 품질 지표(정성 포함): chunk 길이/중복/노이즈, 쿼리-문서 매칭 적합도
2) Grounded Generation (생성 품질: 근거 기반)
- Answer Correctness (정답성): 질문에 대한 최종 답이 맞는지
- Faithfulness / Groundedness (근거충실도): 제공된 컨텍스트 밖 “추측”이 섞였는지(=환각)
- Citation Accuracy (인용 정확도): 인용/출처가 실제 주장과 일치하는지
- Completeness (충분성): 필요한 항목을 빠짐없이 답했는지
3) End-to-End UX & Ops (운영/경험)
- Latency (p50/p95): 응답 시간(평균보다 p95가 실전 체감)
- Success rate: 정상 응답 비율(타임아웃/에러/빈 답 제외)
- Deflection / Task success: 사용자 문제 해결로 이어졌는지(전환/재문의율)
- Cost per query: 쿼리당 비용(토큰+검색 인프라 포함)
- Stability: 배포 후 품질 드리프트(데이터 변경/색인 갱신/모델 업데이트 영향)
4) Safety & Robustness (필요 시)
- PII/보안 위반률, 프롬프트 인젝션 취약성, 유해/금칙 응답률
- Adversarial 쿼리 성능(애매한 질문/함정 질문/근거 부족 상황)
실무에서 흔한 결론(좋은 점/나쁜 점)
- 좋은 점: “검색(Recall) + 근거충실도(Faithfulness) + 지연(p95)”만 잡아도 대다수 문제가 어디서 생기는지 보입니다.
- 나쁜 점: 지표를 늘리면 보고서는 풍성해지지만, 우선순위는 더 헷갈립니다(“측정은 했는데 개선이 안 됨” 함정).
📎 부록 B. RAG 평가 — “프롬프트 설계” 요청 전문
RAG 시스템 평가를 위한 프레임워크를 만들고 싶습니다. 먼저 이 작업에 최적화된 프롬프트를 설계해 주세요.
📎 부록 C. RAG 평가 — 설계된 프롬프트 전문
당신은 “게임 하이브리드(CS·AI) 챗봇”의 평가 프레임워크를 만드는 평가 리드입니다. 목표는 ‘RAG+LLM 답변’과 ‘Rule/FAQ/티켓 플로우’가 섞인 챗봇을 실무에서 운영·개선할 수 있도록, 바로 복붙 가능한 “평가 템플릿(표+기준+체크리스트)”을 만드는 것입니다. ### [기본 컨텍스트(가정)] - 도메인/서비스: 게임 고객센터용 하이브리드 챗봇(CS+AI) - 사용자 Top Tasks: 1) 결제/환불/구독(청약철회, 결제 오류) 2) 계정/보안(로그인, OTP, 해킹 의심) 3) 이용제한/제재(사유/이의제기) 4) 아이템/재화(미지급, 소멸, 우편) 5) 버그/접속장애(공지/해결가이드/티켓) 6) 이벤트/쿠폰(조건, 지급, 기간) - 입력/출력 언어: 한국어(KO→KO), 게임 용어/약어/오타 많음 - 지식원천: 공지/패치노트, 운영정책, 결제/환불 정책, 계정/보안 가이드, FAQ, GM 매뉴얼, CS 티켓 답변 템플릿(최신 우선) - 아키텍처(일반적 가정): - Hybrid retrieval: BM25 + Vector + reranker, Top-k 5~10 - Chunking: 300~600 tokens, overlap 50~100, 메타데이터(문서종류/게임/지역/버전/개정일) - Generator: LLM이 최종 답변 + “근거 인용” + 필요 시 티켓 전환(링크/폼) - 운영 제약(가중치): - 정확도/정책 준수 60% + 지연 25% + 비용 15% - 목표 응답시간: p50 2초 / p95 6초 - 안전/정책 요구: - PII/계정정보 요청 최소화(“스크린샷/주문번호/UID” 수집은 단계·목적 명시) - 부정행위/취약점 악용/환불 꼼수 유도 등 금지 - 법/결제 관련 문구는 근거 문서 기반, 불확실 시 상담/티켓 유도 - 비교 실험 축(기본): 제로샷 vs 프롬프트 설계(가드레일/출력포맷/인용 강화) ### [산출물 요구: 짧게, 하지만 ‘실무용’으로] 아래 5개를 반드시 출력하세요(불필요한 개념 설명 금지). 1) “평가 스코어카드(표)” 1개 - 축: Retrieval / Grounding / Answer 품질 / UX·운영 / Safety - 각 항목별: 지표명, 정의, 단위, 측정법(로그 기반/라벨링), 합격선(기본 Threshold), 치팅 가능성(낮/중/높) 2) “실패 유형 분류표” 1개 - 게임 CS에 특화된 실패 예시 포함(환불 정책, 제재 사유, 이벤트 조건 등) 3) “평가 데이터셋 설계” 요약 - Head/Torso/Longtail 비율 제안 - 최신 문서/충돌 문서/유사 문서/빈 근거(knowledge gap) 케이스 포함 4) “실험 설계” 요약(A/B) - 제로샷 vs 프롬프트 설계 비교 시 통제변수/독립변수/핵심 KPI 제시 - 회귀(절대 깨지면 안 되는 30개 핵심 케이스) 정의 방식 포함 5) 마지막에 딱 8줄: - 이번 프레임워크에서 ‘가장 위험한 함정 5개’ - ‘우선순위 Top 3 개선 액션’ 추측이 필요한 부분은 진행하되, 결과에 영향 큰 불확실성 3개만 “확인 필요”로 끝에 적으세요.
📎 부록 D. 평가 스코어카드 전체 표
※ 누르면 크게 보입니다. 텍스트 표가 깨져서 이미지로 첨부하니 양해 바랍니다.
📎 부록 E. 실패 유형 분류표 전체
※ 누르면 크게 보입니다. 텍스트 표가 깨져서 이미지로 첨부하니 양해 바랍니다.
📎 부록 F. 평가 데이터셋 / 실험 설계 요약 전문
평가 데이터셋 설계 요약
- 분포(권장): Head 35% / Torso 45% / Longtail 20%
- 케이스 구성(필수 포함)
- 최신 문서 우선: 최근 30일 내 공지/정책 개정 기반 20% 이상
- 충돌 문서 세트: “구정책 vs 신정책”, “서버/지역별 상이 정책” 10%
- 유사 문서 혼동 세트: 제목/키워드 유사(환불 vs 결제오류, 제재 vs 보호조치) 10%
- Knowledge Gap(빈 근거): 문서에 없는 문의(미공개 이벤트/개별 계정 상태) 10%
- 오타/약어/은어: “ㅈㅈ”, “환불ㄱ?”, “핵의심”, “OTP튕김” 등 변형 15%
- 고위험 도메인 과대표집: 결제/환불·계정/보안·제재 합산 50% 이상(정책/법 리스크 때문)
- 라벨 스키마(최소): 정답유형(FAQ/정책/RAG/티켓전환), 정답근거(문서ID+스팬), 핵심 주장 체크리스트(기간/조건/예외/필요정보), 안전(PII/악용/법)
- 샘플 수 가이드(초기): 오프라인 400~800 / 회귀 30 / 악성(안전) 80~150
실험 설계 요약(A/B: 제로샷 vs 프롬프트 설계)
- 독립변수(A/B)
- A(제로샷): 최소 시스템 지시 + 기본 인용만 허용
- B(프롬프트 설계): (1) 출력 포맷 고정(요약→단계→필요정보→전환) (2) 인용 강제(핵심 주장마다) (3) 정책/법/보안 가드레일 (4) Knowledge gap 처리 (5) 티켓 전환 트리
- 통제변수(고정)
- 동일 모델/온도/토큰 제한, 동일 리트리벌(BM25+Vec+rerank, k=5~10), 동일 청킹/메타필터, 동일 지식베이스 스냅샷, 동일 캐시 정책
- 핵심 KPI(우선순위)
- Policy Correctness, Hallucination Rate, PII Minimization (정확·정책)
- p50/p95 Latency (지연)
- Cost/Session (비용)
- 보조: Task Success, Citation Precision/Coverage, Escalation Accuracy
- 판정 방식(추천)
- 오프라인: 동일 평가셋에서 스코어카드 비교(신뢰구간/유의성)
- 온라인(가능 시): 10~20% 트래픽 A/B, “정답 라벨 표본”으로 Deflection을 정답일 때만 계산
- 회귀(절대 깨지면 안 되는 30개) 정의 방식
- Top Task별 5~6개씩(결제/보안/제재 우선), 최신 정책 1개 + 충돌 1개 + 빈근거 1개 포함
- “법/결제 문구 단정 금지”, “제재 사유 추정 금지”, “PII 최소수집” 같은 가드레일 회귀 10개를 별도 트랙으로 고정
- 릴리즈마다 30개 전수, 임계치 미달 시 롤백(게임 밸런스 패치처럼요)
- 독립변수(A/B)
함정1: “Deflection 상승”만 보고 좋아했다가, 정답 검증 없이 CS 폭탄(가짜 해결) 터집니다.
함정2: 최신/충돌 문서 처리를 안 하면, 환불·제재에서 한 번에 신뢰가 증발합니다.
함정3: 인용이 ‘있기만’ 하면 된다고 착각하면, Citation Precision에서 바로 걸립니다.
함정4: Knowledge gap에서 단정 한 줄이면, 법/보안/결제 리스크가 즉시 현실화됩니다.
함정5: p95 최적화 없이 p50만 맞추면, 피크 타임에 챗봇이 “로딩창 NPC”가 됩니다.
액션1: 고위험(결제/보안/제재) 150케이스 과대표집 + 회귀30 고정부터 만드세요.
액션2: “최신 우선+충돌 인지+단정 금지+티켓 트리”를 프롬프트/룰로 하드코딩하세요.
액션3: Citation Precision/Coverage 라벨링을 먼저 붙여서, 개선 방향을 데이터로 고정하세요.
확인 필요(영향 큰 불확실성 3개)
- 티켓 전환 채널(웹폼/인게임/CS툴)에서 필수 수집 필드(UID/주문번호/스크린샷)와 수집 허용 범위(정책/법무).
- “정답 Deflection”의 운영 목표치(예: 35% vs 50%)와, 실패 시 허용 가능한 CS 리스크 한도.
- 지식베이스의 갱신 주기/버전 관리 체계(공지·정책 개정이 실시간인지, 배치인지) 및 “최신 판정”의 단일 진실원천(SSOT).
