이전 1부에서는
아래의 관점으로 개념을 정리해보았습니다.

“프롬프트 = 질문, 프롬프트 엔지니어링 = 설계”

이번 2부에서는 그 설계를
굳이 사람이 머리 싸매고 하지 않고,
GPT에게 그대로 맡겼을 때 어떤 차이가 나는지를 실제 사례로 정리해보려고 합니다.

0. 실험 방법 – 딱 이것만 바꿨습니다

실험 방법은 아주 단순합니다.

1. 실제 업무에서 제가 하고 싶은 작업을 그대로 정리해둔다.
2. Before: 떠오르는 대로 GPT에 “그냥 질문”을 던진다.
3. After: GPT에게
   

   “이 작업을 가장 잘 수행할 수 있는 프롬프트를 먼저 설계해 주세요.”
   라고 요청한 뒤, 설계된 프롬프트로 다시 작업을 실행한다.

4. 두 결과를 정확도·구조·재사용성·실무 활용성 기준으로 비교한다.
   → 바꾼 것은 딱 하나입니다.

“결과를 바로 달라”에서
“그 결과를 만드는 프롬프트부터 설계해 달라”로.

 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)
    1. 평가 스코어카드(표)
    2. 실패 유형 분류표
    3. 평가 데이터셋 설계
    4. A/B 실험 설계 요약
    5. 실행 체크리스트
    6. 리스크 Top3 & 이번 주 액션 Top3

즉, GPT에게 이렇게 말한 셈입니다.

“RAG를 잘 평가하는 사람이 된다면,
이 정도는 기본으로 만들어야 하지 않겠습니까?”

그다음 단계에서,
GPT가 설계한 이 프롬프트를 실제 프로젝트 맥락(게임 도메인 CS·AI 챗봇)에 그대로 적용했습니다.
그러자 이번에는 처음부터 “바로 실전에 쓸 수 있는 평가 산출물”이 출력됐습니다.

1-3. After 결과물 스냅샷 – “바로 쓰는 스코어카드”

실제 결과물은 매우 길지만,
핵심만 보여드리면 대략 이런 형태입니다.

🔎 축별 대표 지표 일부 발췌

이 테이블의 중요한 점은:

• • 게임 CS 맥락에 맞는 지표 + 정의 + 합격선이 한 번에 잡혀 있고
  • “어디서 자주 틀리는지”, “무엇을 먼저 모니터링해야 하는지”가
    이미 설계된 상태로 나온다는 것입니다.

그래서 이 결과는

• • 제 머릿속 정리 → 메모 → 엑셀 → 문서… 과정을 생략하고,
  • 곧바로 대시보드 기획 & 라벨링 설계 단계로 넘어갈 수 있게 해줍니다.

※ 실제로는 스코어카드, 실패 유형 분류표, 데이터셋 설계, A/B 설계 등
모든 산출물이 훨씬 길습니다.
전체 전문은 글 하단 ‘부록’에 구조만 만들어 두었습니다.
(필요하신 분은 그대로 복붙해서 참고하시면 됩니다.)

1-4. Before/After에서 달라진 것들

한 줄로 비교하면 이렇습니다.

• • Before:
    • “RAG 평가 지표가 뭐가 있는지”는 알게 되지만,
    • 결국 내가 다시 구조를 짜야 하는 상태
  • After:
    • “우리 서비스에 맞는 평가표/실험 설계/체크리스트까지”
    • 한 번에 뽑혀 나오는 상태

그리고 이 변화는,
모델을 바꾼 것도, 사람을 바꾼 것도 아니라

“그냥 질문했냐” vs “프롬프트 설계부터 맡겼냐”
이 차이에서 나왔습니다.

 2. 언제는 그냥 질문만 해도 되는가

여기까지 읽으면
“앞으로는 모든 작업에 다 이렇게 해야 하나?”
라는 생각이 드실 수 있습니다.

제 기준은 이렇습니다.

❌ 굳이 엔지니어링까지 안 해도 되는 경우

• • 단발성 정보 조회
  • 오늘 점심 메뉴 같은 가벼운 질문
  • 짧은 문장 다듬기, 한두 문단 요약

→ 그냥 자유롭게 질문해도 충분합니다.

⭕ 프롬프트 엔지니어링이 확실히 먹히는 경우

• • 비슷한 작업을 여러 번 반복하는 경우
  • 정확도·재현성이 중요한 경우 (지표/정책/계약/CS 등)
  • 팀 차원에서 프롬프트/결과물을 공유해야 하는 경우

이때는 한 번만 제대로 설계해두면,
그 뒤로는 “나 + 팀의 시간”이 같이 줄어듭니다.

 3. 마무리 — 설계를 “누가 하느냐”의 문제

정리하면, 프롬프트 엔지니어링은

1. 1. 더 좋은 결과를 더 예측 가능하게 얻기 위한 설계이고
   2. 반드시 사람이 다 할 필요는 없다는 점이 중요합니다.

요즘 방식은 이런 느낌에 가깝습니다.

  “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(우선순위)
    1. Policy Correctness, Hallucination Rate, PII Minimization (정확·정책)
    2. p50/p95 Latency (지연)
    3. Cost/Session (비용)
    4. 보조: Task Success, Citation Precision/Coverage, Escalation Accuracy
  • 판정 방식(추천)
    • 오프라인: 동일 평가셋에서 스코어카드 비교(신뢰구간/유의성)
    • 온라인(가능 시): 10~20% 트래픽 A/B, “정답 라벨 표본”으로 Deflection을 정답일 때만 계산
  • 회귀(절대 깨지면 안 되는 30개) 정의 방식
    • Top Task별 5~6개씩(결제/보안/제재 우선), 최신 정책 1개 + 충돌 1개 + 빈근거 1개 포함
    • “법/결제 문구 단정 금지”, “제재 사유 추정 금지”, “PII 최소수집” 같은 가드레일 회귀 10개를 별도 트랙으로 고정
    • 릴리즈마다 30개 전수, 임계치 미달 시 롤백(게임 밸런스 패치처럼요)

함정1: “Deflection 상승”만 보고 좋아했다가, 정답 검증 없이 CS 폭탄(가짜 해결) 터집니다.
함정2: 최신/충돌 문서 처리를 안 하면, 환불·제재에서 한 번에 신뢰가 증발합니다.
함정3: 인용이 ‘있기만’ 하면 된다고 착각하면, Citation Precision에서 바로 걸립니다.
함정4: Knowledge gap에서 단정 한 줄이면, 법/보안/결제 리스크가 즉시 현실화됩니다.
함정5: p95 최적화 없이 p50만 맞추면, 피크 타임에 챗봇이 “로딩창 NPC”가 됩니다.
액션1: 고위험(결제/보안/제재) 150케이스 과대표집 + 회귀30 고정부터 만드세요.
액션2: “최신 우선+충돌 인지+단정 금지+티켓 트리”를 프롬프트/룰로 하드코딩하세요.
액션3: Citation Precision/Coverage 라벨링을 먼저 붙여서, 개선 방향을 데이터로 고정하세요.

확인 필요(영향 큰 불확실성 3개)

1. 1. 티켓 전환 채널(웹폼/인게임/CS툴)에서 필수 수집 필드(UID/주문번호/스크린샷)와 수집 허용 범위(정책/법무).
   2. “정답 Deflection”의 운영 목표치(예: 35% vs 50%)와, 실패 시 허용 가능한 CS 리스크 한도.
   3. 지식베이스의 갱신 주기/버전 관리 체계(공지·정책 개정이 실시간인지, 배치인지) 및 “최신 판정”의 단일 진실원천(SSOT).