프롬프트 정량적 평가 (Part E): N번 생성, 패턴 분석, 모델별 테스트

숫자로 증명하는 프롬프트 안정성과 범용성

정성적 평가(Part C, D)에서 프롬프트가 의도대로 작동하는지 확인했다면, 정량적 평가(Part E)에서는 그 작동이 얼마나 안정적인지를 숫자로 증명한다. 4가지 핵심 방법론을 다룬다: (1) N번 생성: 같은 입력을 N회 실행하여 통과율 측정 (N=1 vs N=20 비교, 비용-편익 분석) (2) 응답 패턴 찾기: 20회 실행 결과를 5개 기준으로 분석하여 취약점 식별 (질문 개수 90%, 5단어 70%) (3) 모델별 테스트: GPT-4/Claude/Gemini 각 20회 테스트로 모델 중립성 검증 (모델별 통과율 비교) (4) 세 번 실험: 일반/구체/다국어 입력으로 범용성 확인 (주제/언어 독립성) 질문 생성기 프롬프트를 사례로 구체적 시나리오, 비교 표, 실패 케이스 분석, 개선 전후 통과율 변화(73% → 93%), 프로덕션 모니터링 대시보드 설계까지 제공한다. 정량 평가가 정성 평가 이후에 와야 하는 이유와 측정하지 못하는 것들(질문 품질, 창의성)의 한계도 다룬다.

AI
Agent
Prompt Engineering
저자

Kwangmin Kim

공개

2025년 02월 05일

1 들어가며

  • 정성적 분석에서 프롬프트가 의도대로 작동하는지를 세 단계로 확인했다.
  • 이제 정량적 분석에서 프롬프트가 그 의도대로 “얼마나 안정적으로” 작동하는지를 숫자로 확인한다.

2 정량적 분석의 세 가지 방법

  • 첫째, N번 생성해보기 (N > 100).
  • 둘째, 응답 패턴 찾기
  • 셋째, 모델별 테스트

3 N번 생성

  • 프롬프트를 한 번 실행했을 때 좋은 결과가 나왔다고 해서, 그 프롬프트가 안정적이라고 말할 수는 없다.
  • LLM은 확률적 모델이기 때문에, 같은 프롬프트라도 매번 다른 결과를 낸다.
  • 그 이유는 LLM은 내부적으로 확률 분포를 사용하기 때문이다.
    • 같은 프롬프트와 같은 입력이라도, 매번 다른 토큰 시퀀스가 생성될 수 있다.
    • 이건 버그가 아니라 LLM의 본질적 특성이다.

3.1 한 번 실행

입력: "부산 여행"

프롬프트 실행 (1회):
High certainty: 부산 뭐 할까?
Moderate certainty: 어디 먼저 갈까?
Low certainty: 혼자 가도 괜찮아?

개발자: "완벽해! 배포하자."

3일 후 프로덕션에서 N번째 사용자들이 얻은 응답:
* 1번 실행은 운이다. 실제 안정성을 모른다.

사용자 1: "부산 뭐 할까? 어디 먼저 갈까? 혼자 가도 괜찮아?" ✓
사용자 2: "부산에서 뭐 먹을까요? 숙소는 어디가 좋아요? 언제 가는 게 좋을까요?" ✗ (존댓말)
사용자 3: "해운대 가볼까? 태종대는?" ✗ (2개만)
사용자 4: "부산 여행 코스 추천해줘. 맛집도 알려줘. 숙소도." ✗ (질문 아님)

PM: "왜 형식이 계속 무너지나요?"
개발자: "테스트할 때는 완벽했는데..."

3.2 테스트 20번 실행

입력: "부산 여행"

프롬프트 실행 (20회):

실행 1: 부산 뭐 할까? / 어디 먼저 갈까? / 혼자 가도 괜찮아? ✓
실행 2: 부산 뭐 먹을까? / 숙소 어디? / 언제 가? ✓
실행 3: 부산에서 뭐 할까요? / 어디 가볼까요? / 언제요? ✗ (존댓말)
실행 4: 해운대 갈까? / 광안리는? / 태종대는? ✓
...
실행 20: 부산 추천해줘 / 맛집 알려줘 ✗ (질문 아님)

결과:
- 형식 유지: 18/20 (90%)
- 반말 유지: 17/20 (85%)
- 5단어 이내: 14/20 (70%)

배포 전 의사결정:

개발자: "20번 테스트 결과, 반말 유지율이 85%네요."
PM: "15%는 존댓말이 나온다는 뜻이에요?"
개발자: "네. Ending 섹션을 강화하면 개선될 것 같습니다."
PM: "개선 후 다시 20번 테스트하고 배포하죠."

[프롬프트 수정]

개발자: "수정 후 20번 테스트 결과, 반말 유지율 100%입니다."
PM: "좋아요. 배포 승인합니다."

프로덕션 결과: 안정적 작동, 이슈율 낮음

3.3 N > 100의 의미

사실 통계적인 의미를 가지려면 N > 300 을 권장하지만 , 실무에서는 N = 100 정도로 타협한다.

실행 횟수 통계적 신뢰도 적합한 경우
N = 1 매우 낮음 프로토타입 단계, 빠른 확인
N = 10 낮음 개발 중 패턴 확인
N = 20 중간 경향성 파악, 주요 문제 발견
N = 100 높음 프로덕션 배포 전 검증
N = 1000 매우 높음 크리티컬 시스템 (금융, 의료)

N=20의 역할:

실무 워크플로우:

[1단계: 빠른 검증 (N=10)]
- 프롬프트 작성 후 즉시 실행
- 형식이 완전히 무너지는지 확인
- 소요 시간: 5분

[2단계: 패턴 확인 (N=20)]
- 주요 문제 발견
- "반말 유지율 85%" 같은 정량적 지표 획득
- 소요 시간: 10분

[3단계: 정밀 검증 (N=100)]
- 배포 전 최종 검증
- 통계적으로 신뢰할 수 있는 수준
- 소요 시간: 50분

[4단계: 프로덕션 모니터링 (N=∞)]
- 실제 사용자 데이터 축적
- 지속적 개선

예시: N=20에서 발견한 문제를 N=100으로 검증

[N=20 결과]
반말 유지율: 17/20 = 85%

개발자: "85%면 충분한가?"
PM: "15%는 너무 높아요. 사용자가 눈치챌 수 있어요."

[프롬프트 수정: Ending 강화]
"Always answer in half speech form of Korean 반말."
→
"IMPORTANT: Always use Korean casual speech (반말). 
Never use polite form (합니다, 입니다, 해요)."

[N=20 재테스트]
반말 유지율: 20/20 = 100%

개발자: "20번 모두 반말로 나왔어요."
PM: "좋아요. 하지만 N=100으로 최종 검증하죠."

[N=100 최종 테스트]
반말 유지율: 98/100 = 98%

PM: "98%면 허용 가능해요. 배포하죠."

N=100의 비용 vs 가치:

항목 N=20 N=100 차이
API 호출 비용 $0.20 $1.00 +$0.80
소요 시간 10분 50분 +40분
통계적 신뢰도 중간 높음 ↑
배포 후 이슈율 5-10% 1-2% ↓
CS 처리 비용 $500/월 $100/월 -$400/월

→ N=100 투자 ($1) → 월 $400 절약

"실전에서는 N > 100을 권장하지만,
스터디에서는 N=20으로 충분합니다.

이유:
1. N=20으로도 패턴은 명확히 보입니다
2. 50분 vs 10분: 실습 시간 고려
3. '경향성 파악' 단계에 충분

하지만 여러분이 실제 프로덕션에 배포할 때는
반드시 N=100 이상으로 검증하세요."

핵심:
- N=1: 운
- N=20: 경향성
- N=100: 확신
- N=1000: 크리티컬 시스템

프롬프트의 중요도에 따라 N을 선택한다.

4 응답 패턴 찾기

  • N번 실행했을 때, 패턴을 찾는 기준을 설정한다. 이 글에서는 제일 간단하면서 강력한 Frequency를 활용한 방법을 알아본다.
  • 단순히 “좋다/나쁘다”가 아니라, 구체적인 기준을 정해서 센다.

4.1 질문 생성기 프롬프트의 측정 기준

  1. 형식: 정확히 3개 질문
  2. 구조: High/Moderate/Low certainty 섹션 구분
  3. 언어: 한국어 반말
  4. 길이: 각 질문 5단어 이내
  5. 정제: 질문만 출력, 주석/설명 없음

20번 실행 시 각 기준별로 체크

4.2 실제 측정 예시

입력: “부산 여행”
실행 횟수: 20회

결과 기록 표:

실행 질문 개수 섹션 구분 반말 5단어 이내 주석 없음 전체 Pass
1 3 ✓ ✓ ✓ ✓ ✓ ✓
2 3 ✓ ✓ ✓ ✗ (6단어) ✓ ✗
3 3 ✓ ✓ ✗ (존댓말) ✓ ✓ ✗
4 3 ✓ ✓ ✓ ✓ ✓ ✓
5 2 ✗ ✓ ✓ ✓ ✓ ✗
… … … … … … …
20 3 ✓ ✓ ✓ ✗ (7단어) ✓ ✗

통계 요약:

기준 통과 실패 통과율
질문 3개 18/20 2/20 90%
섹션 구분 20/20 0/20 100%
반말 유지 17/20 3/20 85%
5단어 이내 14/20 6/20 70%
주석 없음 19/20 1/20 95%
전체 Pass 12/20 8/20 60%

4.3 패턴 분석: 어떤 기준이 약한가?

안정적인 기준 (>90%): - 섹션 구분: 100% - 주석 없음: 95% - 질문 개수: 90%

불안정한 기준 (<80%): - 5단어 이내: 70% ← 가장 약함 - 반말 유지: 85%

4.4 실패 케이스 상세 분석

실행 2 (5단어 위반):

High certainty: 부산 여행 언제 가는 게 좋아?  (7단어 ✗)
Moderate certainty: 어디 먼저 갈까?  (4단어 ✓)
Low certainty: 혼자 가도 괜찮아?  (4단어 ✓)

→ High certainty 질문에서만 길이 초과

실행 3 (반말 위반):

High certainty: 부산 뭐 할까요?  (존댓말 ✗)
Moderate certainty: 어디 가볼까?  (반말 ✓)
Low certainty: 혼자 가도 괜찮아?  (반말 ✓)

→ 마지막 “요” 하나가 문제

실행 5 (질문 개수 부족):

High certainty: 부산 뭐 할까?
Moderate certainty: 어디 먼저 갈까?

→ Low certainty 질문 누락

실행 20 (5단어 위반):

High certainty: 부산에서 꼭 가봐야 할 곳은?  (7단어 ✗)
Moderate certainty: 뭐 먹을까?  (3단어 ✓)
Low certainty: 얼마나 걸릴까?  (4단어 ✓)

→ 구체적인 질문일수록 단어 수 증가 경향

4.5 패턴에서 발견한 것

4.5.1 카테고리별 차이

카테고리 평균 단어 수 5단어 초과율
High certainty 5.2단어 40% ✗
Moderate certainty 4.1단어 10% ✓
Low certainty 3.8단어 5% ✓

→ High certainty 질문이 가장 길어지는 경향

4.5.2 반말 위반 패턴

분석: 20회 중 3회 반말 위반

실행 3: "부산 뭐 할까요?"
실행 11: "언제 가는 게 좋을까요?"
실행 16: "숙소 어디가 좋아요?"

공통점: 모두 마지막에 "요" 추가
이유: "~할까?" vs "~할까요?" 혼동

4.5.3 질문 개수 부족 패턴

분석: 20회 중 2회 질문 생성 (개수 부족)

실행 5: Low certainty 누락
실행 13: Moderate certainty 누락

이유: 특정 카테고리에 맞는 질문이 떠오르지 않을 때
     섹션을 통째로 생략

4.6 패턴 기반 개선 방향

4.6.1 5단어 제약 (70% 통과율)

현재 프롬프트:

Don't be over five words.

개선안 1: 예시 추가

Don't be over five words.
Examples: "뭐 할까?" (3 words), "어디 갈까?" (3 words)

개선안 2: 강조

CRITICAL: Each question must be 5 words or less.
Count carefully: "부산 뭐 할까?" = 4 words ✓
                "부산 여행 언제 가?" = 5 words ✓
                "부산 여행 언제 가는 게 좋아?" = 7 words ✗

예상 효과: 70% → 90%

4.6.2 반말 유지 제약 (85% 통과율)

현재 프롬프트:

Always answer in half speech form of Korean 반말.

개선안:

Always answer in half speech form of Korean 반말.
NEVER use polite form endings: 
- ✗ "~할까요?" "~해요" "~입니까?"
- ✓ "~할까?" "~해" "~이야?"

예상 효과: 85% → 95%

4.7 응답 패턴 탐색의 중요성

패턴 분석 없이 개선하면:

개발자: "20번 중 12번만 통과했어요. 60%네요."
PM: "뭐가 문제인가요?"
개발자: "음... 그냥 불안정한 것 같아요."
PM: "어떻게 고칠 건가요?"
개발자: "프롬프트를 전체적으로 다시 써볼게요."
→ 2일 소요, 효과 불확실

패턴 분석 후 개선하면:

개발자: "20번 중 12번만 통과. 분석 결과:
        - 5단어 제약: 70% (가장 약함)
        - 반말 유지: 85%
        - 특히 High certainty 질문이 길어지는 경향"

PM: "그럼 5단어 제약 부분만 강화하면 되겠네요?"

개발자: "네. Ending에 예시 추가하겠습니다."
→ 30분 소요, 목표 지점 명확

[수정 후 20번 재테스트]
- 5단어 제약: 90% (70%→90%, +20%p)
- 전체 Pass: 75% (60%→75%, +15%p)

PM: "좋아요. 이제 반말 부분도 개선하죠."

4.8 측정 가능한 것만 개선 가능

핵심 원칙:

"측정할 수 없으면 개선할 수 없다"

패턴 찾기 = 측정
측정 = 숫자
숫자 = 비교 가능
비교 = 개선 방향

구체적 예시:

상태 설명 개선 가능?
“불안정해” 주관적, 모호 ✗
“60% 통과” 객관적, 하지만 불충분 △
“5단어 제약 70% 통과” 구체적, 액션 가능 ✓
“High certainty 질문이 평균 5.2단어” 매우 구체적, 최적 ✓✓

응답 패턴 찾기는 “불안정해”를 “5단어 제약 70%”로 바꾸는 과정이다.

5 모델별 테스트: 같은 프롬프트, 다른 모델

  • 같은 프롬프트라도 LLM 모델 (GPT-4, Claude, Gemini) 마다 다르게 작동할 수 있다.
  • 모델마다 학습 데이터와 아키텍처가 다르기 때문에, 같은 지시문을 다르게 해석할 수 있다.

5.1 왜 모델별 테스트가 필요한가?

시나리오: 단일 모델 테스트만 수행

개발자: "GPT-4에서 20번 테스트, 95% 통과율이에요!"
PM: "완벽하네요. 배포하죠."

[3개월 후]
PM: "GPT-4 API 비용이 너무 높아요. Claude로 전환하죠."

[Claude로 전환 후]
사용자: "왜 질문이 이상하게 나와요?"
개발자: "Claude에서 테스트해보니 60% 통과율이네요..."
PM: "다시 프롬프트 수정해야 해요. 2주 걸립니다."
→ 서비스 중단, 사용자 불만

시나리오: 다중 모델 테스트 수행

개발자: "3개 모델 테스트 결과:
        GPT-4: 95%
        Claude: 60%
        Gemini: 85%"

PM: "Claude가 약하네요. 왜죠?"

개발자: "분석해보니 Claude가 '5단어' 제약을 덜 엄격하게 해석해요."

PM: "프롬프트를 Claude 친화적으로 수정할 수 있나요?"

개발자: "네, Ending에 예시를 추가하면 될 것 같습니다."

[수정 후]
GPT-4: 95% (유지)
Claude: 90% (60%→90%, +30%p)
Gemini: 88% (약간 감소하지만 허용 범위)

PM: "좋아요. 이제 비용에 따라 모델을 자유롭게 선택할 수 있겠네요."

5.2 모델별 특성 비교

질문 생성기 프롬프트 20회 테스트 결과:

평가 기준 GPT-4 Claude 3 Gemini Pro 평균
질문 3개 20/20 (100%) 18/20 (90%) 19/20 (95%) 95%
섹션 구분 20/20 (100%) 20/20 (100%) 19/20 (95%) 98%
반말 유지 19/20 (95%) 20/20 (100%) 18/20 (90%) 95%
5단어 이내 16/20 (80%) 12/20 (60%) 15/20 (75%) 72%
주석 없음 20/20 (100%) 19/20 (95%) 20/20 (100%) 98%
전체 Pass 15/20 (75%) 11/20 (55%) 14/20 (70%) 67%

5.3 모델별 강점/약점 분석

GPT-4의 특징:

항목 평가 관찰
형식 준수 우수 3개 질문, 섹션 구분 100%
5단어 제약 보통 80%, 가끔 6-7단어
반말 우수 95%, “~할까요?” 드물게 출현
안정성 높음 결과 예측 가능

실패 케이스 (GPT-4):

실행 7:
High certainty: 부산 여행 언제 가는 게 좋아?  (7단어 ✗)

Claude 3의 특징:

항목 평가 관찰
형식 준수 보통 90%, 가끔 2개만 생성
5단어 제약 약함 60%, 길이 제약 해석 유연
반말 우수 100%, 반말 완벽
안정성 중간 결과 변동 큼

실패 케이스 (Claude):

실행 3:
High certainty: 부산에서 뭐 하면 좋을까?  (6단어 ✗)
Moderate certainty: 어디 먼저 가보는 게 나을까?  (7단어 ✗)

실행 11: (질문 2개만 생성)
High certainty: 부산 뭐 할까?
Moderate certainty: 어디 갈까?
(Low certainty 누락 ✗)

Gemini Pro의 특징:

항목 평가 관찰
형식 준수 우수 95%, 안정적
5단어 제약 보통 75%, GPT-4와 유사
반말 보통 90%, 가끔 존댓말 혼입
안정성 높음 일관성 있음

실패 케이스 (Gemini):

실행 5:
Low certainty: 혼자 가도 괜찮을까요?  (존댓말 ✗)

실행 13:
Moderate certainty: 부산 여행 코스 추천해줘  (명령문, 질문 아님 ✗)

5.4 모델별 약점 패턴 정리

Claude의 5단어 제약 문제:

Claude 실패 케이스 분석 (20회 중 8회 실패):

실행 3: "부산에서 뭐 하면 좋을까?" (6단어)
실행 5: "어디 먼저 가보는 게 나을까?" (7단어)
실행 9: "부산 전통 시장 어디 가?" (6단어)
실행 11: Low certainty 질문 누락
실행 14: "부산 맛집 추천해줘 뭐가 좋아?" (8단어)
...

패턴: Claude는 "자연스러운 질문"을 우선시
      단어 수 제약을 덜 엄격하게 해석

Gemini의 반말 문제:

Gemini 실패 케이스 분석 (20회 중 2회 실패):

실행 5: "혼자 가도 괜찮을까요?" (존댓말)
실행 18: "언제 가는 게 좋을까요?" (존댓말)

패턴: Low certainty 질문에서만 존댓말 출현
      "불확실한" 질문 → 정중하게 표현 경향

5.5 프롬프트 개선: 모델 중립적으로 만들기

  • 현재: 프롬프트가 모델별 성능 차이가 큼
### Ending
Always answer in half speech form of Korean 반말.
Don't be over five words.
Only provide three questions.

개선 프롬프트 (모델 중립적):

### Ending
CRITICAL RULES:
1. Language: ALWAYS use Korean casual speech (반말)
   - ✓ Correct: "뭐 할까?" "어디 갈까?"
   - ✗ Wrong: "뭐 할까요?" "어디 갈까요?"
   
2. Length: Each question MUST be 5 words or less
   - Count carefully before generating
   - ✓ "부산 뭐 할까?" = 4 words
   - ✗ "부산에서 뭐 하면 좋을까?" = 6 words
   
3. Count: Generate EXACTLY 3 questions
   - One for each certainty level
   - Never skip any level

개선 후 테스트 결과:

평가 기준 GPT-4 Claude 3 Gemini Pro 개선
5단어 이내 16/20 (80%) 18/20 (90%) 17/20 (85%) +30%p (Claude)
반말 유지 19/20 (95%) 20/20 (100%) 20/20 (100%) +10%p (Gemini)
질문 3개 20/20 (100%) 20/20 (100%) 20/20 (100%) +10%p (Claude)
전체 Pass 17/20 (85%) 17/20 (85%) 17/20 (85%) 일관성 향상

→ 모든 모델에서 85% 통과율로 수렴

5.6 모델 중립성의 필요성

비용 최적화:

모델 1M 토큰 비용 월 10M 호출 시
GPT-4 $30 $300
Claude 3 $15 $150
Gemini Pro $7 $70

모델 중립적 프롬프트 장점:

시나리오: 비용 절감 필요

PM: "월 API 비용이 $300이에요. 줄일 수 있나요?"

개발자 (모델 종속적 프롬프트):
"GPT-4만 제대로 작동해요. 다른 모델로 바꾸면 
 프롬프트 재작성 필요합니다. 2주 소요."

PM: "그럼 계속 $300 지불해야겠네요..."

---

개발자 (모델 중립적 프롬프트):
"3개 모델 모두 85% 통과율이에요. 
 Gemini로 바꾸면 $70로 절감됩니다."

PM: "즉시 전환하죠!"
→ 연간 $2,760 절약

모델 장애 대응:

[GPT-4 API 장애 발생]

개발자 (모델 종속적):
"GPT-4만 작동해요. 서비스 중단합니다."
→ 3시간 다운타임, 사용자 이탈

개발자 (모델 중립적):
"Claude로 자동 페일오버합니다."
→ 0초 다운타임, 사용자 영향 없음

5.7 모델 선택 의사결정 프레임워크

상황별 모델 선택:

상황 추천 모델 이유
프로토타입 Gemini Pro 저렴($7), 빠른 반복
프로덕션 (안정성 중시) GPT-4 높은 일관성
프로덕션 (비용 중시) Claude 3 중간 성능, 중간 비용
크리티컬 시스템 GPT-4 + Claude 백업 페일오버 전략

모델별 테스트는 “선택의 자유”를 준다.
한 모델에 종속되지 않고, 상황에 따라 최적의 모델을 선택할 수 있다.

6 세 번의 실험: 각각 다른 것을 본다

정량적 평가의 마지막 단계는 다양한 입력 조건에서 테스트하는 것이다.

  • 같은 프롬프트로, 입력만 바꿈
  • 세 번의 실험이 각각 다른 것을 테스트한다.
  • 다양한 입력에서 안정성 검증

N=20으로 안정성을 확인했다면, 이제 입력을 바꿔가며 프롬프트가 범용적으로 작동하는지 확인한다.

시나리오: 단일 입력만 테스트

개발자: "질문 생성기 완성! '개발자로 살아남으려면?' 입력으로 
        20번 테스트, 85% 통과율입니다."

PM: "완벽하네요. 배포하죠."

[프로덕션 배포 후]
사용자 1: "안구 건조증 음식?" → ✓ 정상 작동
사용자 2: "What's the best food in Hawaii?" → ✗ 영어로 응답
사용자 3: "카페" (짧은 입력) → ✗ 이상한 질문 생성

PM: "왜 영어로 답하죠? 왜 짧은 입력에서 실패하죠?"
개발자: "테스트하지 않은 입력이었어요..."
→ 긴급 수정, 2주 소요

시나리오: 세 번 실험 수행

개발자: "질문 생성기 완성! 세 가지 입력으로 테스트합니다."

1회차: "개발자로 살아남으려면?" (일반 주제, 한국어, 완전한 문장)
→ 15/15 통과

2회차: "안구 건조증에 좋은 음식?" (구체적 주제, 건강)
→ 10/10 통과

3회차: "What's the Best food in Hawaii?" (영어 입력)
→ 10/10 통과, 모두 한국어로 응답 ✓

PM: "영어 입력도 처리하네요? 예상 외였는데 좋네요."

개발자: "네, 프롬프트가 다국어 입력에 안정적입니다. 
        추가 수정 없이 배포 가능합니다."

[프로덕션 배포 후]
사용자 1: "안구 건조증 음식?" → ✓
사용자 2: "What's the best food in Hawaii?" → ✓
사용자 3: "카페" → ✓ (짧은 입력도 예상대로 작동)

→ 긴급 수정 없음, 안정적 운영

6.1 세 번 실험의 목적: 입력 공간 탐색

입력 공간 (Input Space):

프롬프트가 받을 수 있는 모든 가능한 입력을 뜻한다.
질문 생성기의 입력 공간은 무한하다 (모든 주제, 모든 언어, 모든 길이).

탐색 전략:

실험 입력 변수 검증 목표
1회차 “개발자로 살아남으려면?” 일반 주제, 한국어, 완전 문장 기준선 (baseline)
2회차 “안구 건조증에 좋은 음식?” 구체적 주제, 건강 카테고리 주제 독립성
3회차 “What’s the Best food in Hawaii?” 영어 입력 다국어 처리

→ 3개 입력으로 입력 공간의 주요 축을 탐색

6.2 1회차: 기준선 설정

입력: “개발자로 살아남으려면?”

실행 횟수: 15회

결과 요약:

평가 기준 통과 실패 통과율 비고
질문 3개 15/15 0/15 100% 매우 안정적
섹션 구분 15/15 0/15 100% 완벽
반말 유지 15/15 0/15 100% 문제 없음
5단어 이내 11/15 4/15 73% 약함
주석 없음 15/15 0/15 100% 안정적

실패 케이스 (5단어 제약):

실행 3:
High certainty: 개발자 커뮤니티는 어떻게 활용해?  (6단어 ✗)

실행 7:
Moderate certainty: 기술 블로그 작성은 중요할까?  (6단어 ✗)

실행 12:
Low certainty: 이직 타이밍은 언제가 좋을까?  (7단어 ✗)

실행 14:
High certainty: 어떤 프레임워크를 먼저 배워야 해?  (7단어 ✗)

주제 다양성:

주제 출현 횟수 비율
기술 스킬 15/15 100%
트렌드 학습 14/15 93%
경력 쌓기 11/15 73%
커뮤니티 7/15 47%
이직 3/15 20%

발견:

  1. 형식 안정성: 100% (15/15)
  2. 반말 안정성: 100% (15/15)
  3. 길이 제약 약함: 73% (11/15)
  4. 주제 편향: “기술 스킬”이 모든 실행에 등장

→ 이것이 기준선이다. 이후 실험과 비교할 기준

6.3 2회차: 주제 독립성 검증

입력: “안구 건조증에 좋은 음식?”

변경된 변수: 주제 (개발 → 건강/영양)

실행 횟수: 10회

결과 요약:

평가 기준 통과 실패 통과율 1회차 대비
질문 3개 10/10 0/10 100% =
섹션 구분 10/10 0/10 100% =
반말 유지 10/10 0/10 100% =
5단어 이내 10/10 0/10 100% +27%p ↑
주석 없음 10/10 0/10 100% =

성공 케이스 (5단어 제약 완벽 통과):

실행 1:
High certainty: 안구 건조증 음식 뭐야?  (5단어 ✓)
Moderate certainty: 오메가3 효과 있어?  (4단어 ✓)
Low certainty: 당근즙도 도움 될까?  (5단어 ✓)

실행 5:
High certainty: 어떤 음식이 좋아?  (5단어 ✓)
Moderate certainty: 블루베리 효과 있어?  (4단어 ✓)
Low certainty: 물 많이 마셔야 해?  (5단어 ✓)

실행 10:
High certainty: 눈 건강 음식 뭐야?  (5단어 ✓)
Moderate certainty: 비타민A 많은 게 뭐야?  (6단어 ✗)

→ 실제로는 실행 10에서 1개 실패
   통과율 = 29/30 = 96.7%

주제 다양성:

주제 출현 횟수 비율
음식/영양소 10/10 100%
대체 치료법 7/10 70%
조리법 3/10 30%
물 섭취 3/10 30%

발견:

  1. 형식 안정성: 유지 (100%)
  2. 5단어 제약: 1회차(73%) → 2회차(96.7%) 대폭 개선
  3. 주제 독립성: ✓ 확인됨 (건강 주제에서도 완벽 작동)

왜 2회차에서 5단어 제약이 더 잘 지켜졌는가?

가설 1: 구체적 주제일수록 명확한 질문 생성
- "개발자로 살아남으려면?" → 넓고 추상적
  → 모델이 다양한 각도에서 질문 생성 시도
  → 긴 질문 생성 가능성 ↑
  
- "안구 건조증에 좋은 음식?" → 좁고 구체적
  → 모델이 명확한 질문 생성
  → 짧은 질문 자연스럽게 생성 ↑

가설 2: 1회차의 편향
- 1회차가 특이 케이스일 가능성
- 더 많은 실험 필요 (N=50+)

6.4 3회차: 다국어 처리 검증

입력: “What’s the Best food in Hawaii?”

변경된 변수: 언어 (한국어 → 영어)

실행 횟수: 10회

결과 요약:

평가 기준 통과 실패 통과율 특이사항
질문 3개 10/10 0/10 100% -
섹션 구분 10/10 0/10 100% -
반말 유지 10/10 0/10 100% 영어 혼입 0건
5단어 이내 8/10 2/10 80% -
주석 없음 10/10 0/10 100% -

가장 중요한 발견: 영어 입력 → 한국어 출력

입력: "What's the Best food in Hawaii?" (영어)

예상 가능한 시나리오:
1. 영어로 응답: "What food should I try?" ✗
2. 영어+한국어 혼합: "Hawaiian food 뭐 먹을까?" ✗
3. 한국어 응답: "하와이 음식 뭐 먹을까?" ✓

실제 결과: 10/10 모두 시나리오 3 (한국어 응답)

실제 생성 예시:

실행 1:
High certainty: 하와이 음식 추천 뭐야?  (6단어 ✗)
Moderate certainty: 로코모코 맛있어?  (4단어 ✓)
Low certainty: 포케는 어떤 맛이야?  (5단어 ✓)

실행 3:
High certainty: 하와이 가면 뭐 먹어?  (5단어 ✓)
Moderate certainty: 마우이 특산물 있어?  (4단어 ✓)
Low certainty: 스팸무스비 괜찮아?  (3단어 ✓)

실행 7:
High certainty: 하와이 전통 음식 뭐야?  (5단어 ✓)
Moderate certainty: 아사이볼은 어때?  (3단어 ✓)
Low certainty: 쉐이브아이스 추천해?  (3단어 ✓)

실행 10:
High certainty: 하와이에서 꼭 먹어야 할 음식은?  (7단어 ✗)
Moderate certainty: 팬케이크 맛있어?  (3단어 ✓)
Low certainty: 로컬 맛집 어디야?  (4단어 ✓)

맥락 이해도 분석:

하와이 관련 키워드 출현 횟수 비율
“하와이” 직접 언급 10/10 100%
하와이 고유 음식 (로코모코, 포케) 8/10 80%
하와이 특산 (마우이, 쉐이브아이스) 5/10 50%
일반 음식 (팬케이크) 3/10 30%

→ 맥락 이해도 매우 높음

발견:

  1. 다국어 처리: ✓ 완벽 (영어 혼입 0건)
  2. 맥락 이해: ✓ 우수 (하와이 음식 정확히 인식)
  3. 5단어 제약: 80% (1회차 73%보다 개선, 2회차 96.7%보다 낮음)

프롬프트 언어 vs 입력 언어 vs 출력 언어:

요소 언어 우선순위
프롬프트 영어 -
입력 영어 -
출력 지시 한국어 (Ending에 명시) 최우선
실제 출력 한국어 ✓

→ Ending 섹션의 “Always answer in Korean 반말”이 입력 언어보다 우선

6.5 세 번 실험 종합 분석

통과율 비교:

평가 기준 1회차 2회차 3회차 평균 안정성
질문 3개 100% 100% 100% 100% 매우 안정
섹션 구분 100% 100% 100% 100% 매우 안정
반말 유지 100% 100% 100% 100% 매우 안정
5단어 이내 73% 96.7% 80% 83% 중간
주석 없음 100% 100% 100% 100% 매우 안정
전체 Pass 73% 96.7% 80% 83% -

핵심 발견:

  1. 형식 안정성 완벽 (100%):
    • 주제, 언어에 관계없이 3개 질문 형식 유지
    • 섹션 구분 완벽
    • 주석 없음 완벽
  2. 반말 안정성 완벽 (100%):
    • 영어 입력에서도 한국어 반말 출력
    • 영어 혼입 0건
  3. 5단어 제약 불안정 (73-96.7%):
    • 가장 약한 제약
    • 주제에 따라 변동 (구체적 주제 > 추상적 주제)
  4. 주제 독립성 ✓:
    • 개발, 건강 주제 모두 작동
  5. 다국어 처리 ✓:
    • 영어 입력 → 한국어 출력 완벽
    • 맥락 이해도 우수

6.6 왜 세 번만 실험하는가?

“더 많은 입력으로 테스트해야 하지 않나?”

논리적으로는 맞다. 입력 공간은 무한하다.
모든 주제, 모든 언어, 모든 길이를 테스트할 수는 없다.

세 번 실험의 목적은 "완전한 검증"이 아니라 
"주요 축 탐색"이다.

축 1: 주제 (일반 ↔ 구체적)
축 2: 언어 (한국어 ↔ 영어)
축 3: (추가 가능) 길이 (짧은 입력 ↔ 긴 입력)

3개 축을 탐색하면, 프롬프트의 "입력 범위"를 
대략적으로 파악할 수 있다.

3번 vs 10번 vs 100번:

실험 횟수 소요 시간 발견 가능성 비용
3번 30분 주요 패턴 낮음
10번 3시간 세부 패턴 중간
100번 30시간+ 극소수 엣지 케이스 높음

→ 3번이 최적 (ROI 관점)

6.7 프롬프트 개선 액션

발견된 문제: 5단어 제약 불안정 (73-96.7%)

현재 Ending:

Always answer in half speech form of Korean 반말.
Don't be over five words.
Only provide three questions.

개선안 1: 예시 추가

Always answer in half speech form of Korean 반말.
Each question MUST be 5 words or less.
Example: "부산 뭐 할까?" (4 words ✓)
Example: "부산에서 뭐 하면 좋을까?" (6 words ✗)
Only provide three questions.

개선안 2: 강조 추가

Always answer in half speech form of Korean 반말.
CRITICAL: Each question MUST NOT exceed 5 words.
Count words carefully before generating each question.
Only provide three questions.

개선 후 예상 효과:

항목 현재 개선 후 (예상) 변화
5단어 제약 73-96.7% 90-95% +10%p
전체 Pass 83% 90-95% +7-12%p

6.8 세 번 실험의 의의

  1. 입력 공간 탐색: 주제, 언어 축 검증
  2. 패턴 발견: 5단어 제약이 가장 약함
  3. 개선 방향 도출: Ending 섹션 개선 필요
  4. 배포 결정: 83% 통과율 → 배포 가능 여부 판단

세 번 실험은 정량적 검증의 마지막 단계이자
프롬프트 최적화의 시작점이다.

7 5. 왜 정량적 평가가 중요한가?

정성적 평가(Part C, D)는 “프롬프트가 의도대로 작동하는지”를 확인했다.
정량적 평가(Part E)는 “그 작동이 얼마나 안정적인지”를 숫자로 증명한다.

7.1 프로덕션에서의 의미

시나리오 1: 정량적 평가 없이 배포

개발자: "질문 생성기 완성! 5번 테스트했는데 잘 작동해요."

PM: "5번? 충분한가요?"

개발자: "네, 매번 3개 질문 나왔고, 반말도 유지됐어요."

PM: "좋아요. 배포하죠."

[프로덕션 배포 후]
Day 1: 사용자 100명 → 20명 "질문이 이상해요" 불만
Day 2: 사용자 500명 → 100명 "이게 반말이에요?" 불만
Day 3: 서비스 중단

개발자: "N=5는 충분하지 않았네요..."

PM: "몇 번 테스트해야 충분했나요?"

개발자: "최소 20번은 했어야 했어요."

PM: "왜 처음부터 안 했죠?"
→ 신뢰 손상, 2주 긴급 수정

시나리오 2: 정량적 평가 후 배포

개발자: "질문 생성기 완성! 정량적 평가 결과:
        - N=20 테스트: 85% 통과율
        - 세 번 실험: 주제/언어 독립성 검증
        - 5단어 제약: 73-96.7% (가장 약함)"

PM: "85%면 프로덕션에 충분한가요?"

개발자: "6σ 품질 기준(99.99966%)에는 못 미치지만,
        질문 생성 도메인에서는 허용 가능합니다.
        5단어 제약 개선하면 90-95%까지 올릴 수 있어요."

PM: "개선 소요 시간은?"

개발자: "Ending 섹션에 예시 추가만 하면 됩니다. 30분."

[30분 후]
개발자: "재테스트 결과 93% 통과율입니다."

PM: "좋아요. 배포하되, 모니터링 대시보드 준비하세요."

[프로덕션 배포 후]
Day 1: 실시간 모니터링, 통과율 92% (예상 93%와 일치)
Day 2: 통과율 94% (사용자 피드백 반영)
Day 3: 안정적 운영, 사용자 만족도 95%

PM: "좋은 출시였습니다."
→ 신뢰 구축, 안정적 운영

7.2 비용 최적화 의사결정

N번 생성의 ROI:

N API 비용 발견 가능 패턴 의사결정 가능 수준
1 $0.01 없음 불가능
5 $0.05 표면적 매우 낮음
10 $0.10 기초적 낮음
20 $0.20 충분 높음 (추천)
50 $0.50 상세 매우 높음 (연구용)
100 $1.00 극상세 과잉 (불필요)

$0.20 투자로 얻는 것:

1. 통과율 숫자 (85%)
2. 취약점 발견 (5단어 제약 73%)
3. 개선 방향 도출 (Ending 섹션 보강)
4. 배포 신뢰도 확보
5. PM/이해관계자 설득 자료

→ 긴급 수정 비용 절감: $5,000+ (개발자 2주 인건비)
→ ROI = $5,000 / $0.20 = 25,000:1

7.3 측정하지 않으면 개선할 수 없다

핵심 원칙:

정성적 평가: "이 프롬프트가 작동하는가?"
정량적 평가: "얼마나 안정적으로 작동하는가?"

측정 = 숫자
숫자 = 비교 가능
비교 = 개선 방향

구체적 예시:

평가 방식 결과 액션 가능? 이유
주관적 “불안정해” ✗ 모호, 비교 불가
단순 통계 “60% 통과” △ 어디가 약한지 모름
세부 통계 “5단어 제약 70%” ✓ 개선 지점 명확
매우 세부 “High certainty 평균 5.2단어” ✓✓ 최적 개선안 도출

7.4 지속적 개선 루프

정량적 평가 → 개선 → 재평가 사이클:

[1단계] 초기 평가
N=20 테스트 → 85% 통과율
5단어 제약 취약 (73%)

↓

[2단계] 개선
Ending에 예시 추가
"부산 뭐 할까?" (4 words ✓)
"부산에서 뭐 하면 좋을까?" (6 words ✗)

↓

[3단계] 재평가
N=20 재테스트 → 93% 통과율
5단어 제약 개선 (73% → 90%, +17%p)

↓

[4단계] 추가 개선
반말 제약에 예시 추가
"뭐 할까?" ✓
"뭐 할까요?" ✗

↓

[5단계] 최종 평가
N=20 최종 테스트 → 96% 통과율
프로덕션 배포 결정

↓

[6단계] 프로덕션 모니터링
실시간 대시보드: 일평균 95% 통과율
→ 목표(96%)와 유사, 안정적 운영

7.5 이해관계자 커뮤니케이션

정량 데이터의 힘:

PM에게:

질문 정량 데이터 없이 정량 데이터 있으면
“배포 가능한가요?” “아마도요…” “93% 통과율, 배포 가능”
“얼마나 안정적인가요?” “꽤 안정적이에요” “N=20 테스트, 93% 안정”
“개선 가능한가요?” “해볼게요” “5단어 제약 개선 시 +5%p”
“비용은?” “모르겠어요” “API $0.20 투자, ROI 25,000:1”

임원에게:

CTO: "이 프롬프트 얼마나 믿을 만한가요?"

개발자 (정량 데이터 없음):
"제가 테스트해봤는데 잘 작동합니다."

CTO: "얼마나 테스트했죠?"
→ 신뢰도 낮음

---

개발자 (정량 데이터 있음):
"N=20 테스트, 93% 통과율입니다.
 세 가지 다른 주제, 영어 입력까지 검증했습니다.
 프로덕션 예상 성능: 92-94%"

CTO: "좋습니다. 배포하죠."
→ 신뢰도 높음, 의사결정 빠름

7.6 프로덕션 모니터링 설계

정량 평가 지표 → 모니터링 대시보드:

평가 지표 모니터링 메트릭 알람 조건
질문 3개 questions_count < 3
반말 유지 casual_speech_ratio < 90%
5단어 이내 word_count_violation > 20%
주석 없음 comment_presence > 5%
전체 Pass overall_pass_rate < 85%

실시간 대시보드 예시:

[질문 생성기 모니터링 대시보드]

총 요청 수: 12,458
전체 통과율: 92.3% (목표: 93%)

기준별 통과율:
- 질문 3개: 99.8% ✓
- 반말: 98.2% ✓
- 5단어: 88.7% △ (목표 90%)
- 주석 없음: 99.1% ✓

[알람]
⚠️ 5단어 제약 통과율 90% 미만 (지난 1시간)
→ Ending 섹션 강화 검토 필요

7.7 정량적 평가의 한계

숫자가 전부가 아니다:

시나리오: 100% 통과율인데 사용자 불만

개발자: "N=20 테스트, 100% 통과율입니다!"

PM: "완벽하네요. 배포하죠."

[프로덕션 배포 후]
사용자 1: "질문이 너무 뻔해요. 재미없어요."
사용자 2: "매번 비슷한 질문만 나와요."
사용자 3: "창의성이 없어요."

PM: "100% 통과인데 왜 불만이죠?"

개발자: "형식은 완벽했지만, 질문의 질은 측정하지 않았어요..."

측정하지 못하는 것들:

항목 정량 평가 측정 가능? 대안
형식 준수 ✓ ✓ N번 생성
반말 유지 ✓ ✓ 패턴 분석
질문 품질 ✗ ✗ 사용자 피드백
창의성 ✗ ✗ A/B 테스트
사용자 만족도 ✗ ✗ 설문 조사

균형 잡힌 평가:

정량적 평가 (93%) + 정성적 평가 (작동 확인) + 사용자 피드백 (만족도)
= 종합적 프롬프트 품질

7.8 정량적 평가 체크리스트

배포 전 필수 확인 사항:

연속적 개선:

정량적 평가는 "한 번"이 아니다.

초기 개발: N=20 테스트
프로덕션 배포: 실시간 모니터링 (N=∞)
주간 리뷰: 통과율 추이 분석
월간 최적화: 취약점 개선

→ 데이터 기반 지속적 개선

8 정량적 평가 핵심 요약

8.1 N번 생성

  • 목적: 안정성 측정
  • 방법: 같은 입력 N번 실행, 통과율 계산
  • 추천: N=20 (최소), N=50+ (연구용)
  • 발견: 불안정한 제약 식별

8.2 응답 패턴 찾기

  • 목적: 취약점 분석
  • 방법: 5개 기준별 통과/실패 기록
  • 발견: 어떤 제약이 약한지 정량화
  • 개선: 패턴 기반 Ending 섹션 보강

8.3 모델별 테스트

  • 목적: 모델 독립성 검증
  • 방법: GPT-4/Claude/Gemini 각 20회 테스트
  • 발견: 모델별 강점/약점 패턴
  • 개선: 모델 중립적 프롬프트 작성

8.4 세 번 실험

  • 목적: 입력 공간 탐색
  • 방법: 일반/구체/다국어 입력 각 10-15회
  • 발견: 주제/언어 독립성 검증
  • 개선: 범용성 확보

9 정성 평가 이후 정량 평가

정성적 분석(Part C, D)에서 프롬프트가 의도대로 작동한다는 것을 확인했다.
정량적 분석(Part E)에서 그 작동이 얼마나 안정적인지를 숫자로 증명했다.

만약 Part D의 구조 분석에서 이 프롬프트가 작동하지 않는다는 것을 발견했다면,
그 프롬프트를 N=20 실행하는 것은 의미가 없다.
작동하지 않는 프롬프트의 안정성을 측정하는 것은 순서가 뒤집힌 것이다.

올바른 순서:

1. 정성적 분석: "작동하는가?" (Part C, D)
   ↓ YES
2. 정량적 분석: "얼마나 안정적인가?" (Part E)
   ↓ 통과율 확인
3. 프로덕션 배포
   ↓ 모니터링
4. 지속적 개선

Part E는 데이터 기반 의사결정의 기초를 제공한다.
“느낌”이 아닌 “숫자”로 프롬프트 품질을 증명하고,
“추측”이 아닌 “패턴”으로 개선 방향을 도출한다.

Subscribe

Enjoy this blog? Get notified of new posts by email: