프롬프트 정성적 평가: 3단계 분석과 루브릭 기반 측정

1 이 파트의 위치

• 테스트의 두 축을 정성적과 정량적으로 나누고 정성적 메트릭이 먼저 통과되어야 정량적 메트릭이 의미를 가진다고 가정한다.
• 그 정성적 축을 실제로 사용하는 것에 대한 논의를 포함하는 내용을 다루어 본다.
• 정성적 루부릭을 4개의 단계로 구성하는 방법론을 설명한다.
  • 정성적 축을 3단계로 구성한다:
    • 목적 확인
    • 구조 분석
    • 효율성 평가
      
  • 종합 평가: 이 세 단계를 한 번에 반복할 수 있도록 하는 루브릭을 마지막에 다루어 본다.

2 3 단계의 필요성

• 질적 분석을 한 번의 평가로 끝내는 건 가능하지만 평가자의 경험과 감각에 의존한다.
  • “이 프롬프트가 좋은지 나쁜지”를 전체적으로 느끼고 판단하는 주관적인 방법이다.
    
  • 문제는 그런 감각이 사람마다 다르다는 것이다.
  • 같은 프롬프트를 두 사람이 보면, 한 사람은 “구조가 이상하다”고, 다른 사람은 “길이가 문제”라고 볼 수 있다.
    
  • 둘 다 맞을 수도 있고, 둘 다 핵심을 놓친 것일 수도 있다.
    
• 질적 분석 평가 단계를 여러 단계로 이런 종류의 불일치를 줄이기 위한 것이다.
  
• 각 단계의 구성 항목도 중요하지만 그 순서도 중요하다.
  • 첫 단계는 “이 프롬프트가 무엇을 하려는지”,
    
  • 두 번째는 “그 의도를 실현하는 구조가 적절한지”,
    
  • 세 번째는 “그 구조가 필요 이상으로 복잡한지 (즉 정규화의 대상인지 평가)”.
    
• 목적이 불분명하면 구조를 평가할 수 없고, 구조가 확인되지 않으면 효율성을 평가하는 건 의미가 없다.

2.1 목적 확인

• what to ask: 프롬프트를 읽고, 이 프롬프트가 모델에게 무엇을 요구하는지를 먼저 파악한다.
  • 이건 프롬프트를 작성한 사람의 의도를 재구성하는 행위
    
  • 작성자가 원했던 것과 프롬프트가 실제로 전달하는 것이 일치하는지를 확인하는 것
• 질문 생성기 프롬프트를 한 번 본다.

You have a mind, and your role is to generate possible
three questions a user may want to ask next based on User
input: 개발자로 살아남으려면??

The questions must be from the perspective of me,
the user asking you a question.

## Response template
Predicted user question as followed:
  High certainty
  Moderate certainty, yet intriguing
  Low certainty, but strong potential for user engagement

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

목적 확인에서 하는 건 두 가지이다.

2.1.1 핵심 단어와 구문 추출

이 프롬프트에서 모델의 행동을 실제로 결정하는 키워드를 표로 정리한다.

키워드	역할	빠지면 어떻게 되나?
“generate three questions”	출력 개수 제한	1개 또는 5개 이상 생성 가능
“based on User input”	입력 맥락 연결	입력 무시하고 일반적 질문 생성
“High/Moderate/Low certainty”	질문 각도 구분	3개가 비슷한 각도로 중복
“half speech form of Korean 반말”	언어 형식	존댓말(“합니까?”) 혼입
“five words”	길이 제약	문장 형태로 길어짐 (10단어 이상)
“Only provide three questions”	출력 정제	설명/주석 추가 (“예를 들어…”)

실제 테스트 예시:

“five words” 제약이 있을 때:

High certainty: 부산 뭐 할까?  (4단어 ✓)
Moderate certainty: 어디 먼저 갈까?  (4단어 ✓)
Low certainty: 혼자 가도 괜찮아?  (4단어 ✓)

“five words” 제약이 없을 때:

High certainty: 부산에서 할 수 있는 재미있는 활동은 뭐가 있을까?  (12단어 ✗)
Moderate certainty: 부산 여행 코스 중에서 어디를 먼저 가는 게 좋을까?  (14단어 ✗)
Low certainty: 부산에 혼자 여행 가도 괜찮을까?  (7단어 ✗)

→ 제약 하나가 출력 형식 전체를 바꾼다.

2.1.2 문장 구성 분석: 정보 흐름

프롬프트의 정보 흐름을 3단계로 분해한다.

논리 흐름 구조: 정보의 범위를 단계적으로 구체화 시킨다.

[1단계: 역할 정의] (넓음)
"You have a mind, and your role is to generate..."
→ LLM에게 "누구인지" 알려줌

[2단계: 출력 형태] (중간)
"Response template: High certainty / Moderate certainty / Low certainty"
→ "무엇을 만들지" 구조 제시

[3단계: 형식 제약] (좁음)
"Ending: 반말, 5단어, 3개만"
→ "어떤 형태로" 세부 규칙

논리 흐름 분석 표:

단계	역할	정보의 범위	LLM 내부 처리
1	역할 정의	가장 넓음	“질문 생성기구나” 프레임 설정
2	출력 구조	중간	“3가지 각도로 나눠야지” 계획 수립
3	형식 제약	가장 좁음	“반말 5단어로 짧게” 실행 조정

왜 이 순서인가?

일반 → 구체 순서는 LLM이 맥락을 점진적으로 좁히며 생성하는 방식과 일치한다.

순서가 바뀌면:

[잘못된 순서 예시]
1. "반말 5단어로 답하라" (제약 먼저)
2. "질문 생성기다" (역할 나중)
→ LLM은 "뭘 반말로 5단어로?" 혼란

목적 확인 후 수정하면:

개발자 A: "핵심 키워드 표 보니 'five words'가 길이 제약이네."
개발자 B: "그럼 이건 못 지워. 형식 유지 필수."
→ 즉시 판단, 불필요한 실험 방지

목적 확인은 “이 프롬프트의 어떤 부분이 결과를 결정하는가”를 먼저 파악하는 단계다.
핵심을 알아야 수정해도 안전하다.

2.2 구조 분석

• 목적이 파악되면, 그 목적을 실현하는 구조가 적절한지를 본다.
  
• 구조를 바꾸고, 결과가 달라지는지 본다.
  
• 변수를 하나만 바꾸고 나머지는 동일하게 유지한다.
  
• 이 실험을 두 번 한다.
  
• 두 번째 실험의 결과가 첫 번째와 달라지는 부분에서 구조 분석이 실제로 무엇을 찾는지가 보인다.

2.2.1 실험 1: Question Generator

• 실험 설계: 두 버전을 만든다. 텍스트는 한 글자도 바꾸지 않고, 섹션 순서만 변경한다.
  • Type 1 (원본): Introduction -> Response template (출력 형태) -> Ending (형식 제약)
  • Type 2 (순서 변경): Introduction -> Ending (형식 제약) -> Response template (출력 형태)
• 테스트 입력: “부산 여행”
  • Type 1 결과:
    • High certainty: 부산 뭐 할까?
      
    • Moderate certainty: 어디 먼저 갈까?
      
    • Low certainty: 혼자 가도 괜찮아?
      
  • Type 2 결과:
    • High certainty: 부산 뭐 할까?
      
    • Moderate certainty: 어디 먼저 갈까?
      
    • Low certainty: 혼자 가도 괜찮아?
      
• 비교결과: 차이 없음

평가 항목	Type 1	Type 2	차이
질문 개수	3개	3개	없음
반말 준수	100%	100%	없음
각도 다양성	다름	다름	없음
5단어 제약	준수	준수	없음
출력 형식	카테고리 구분	카테고리 구분	없음

• 왜 차이가 없는가?: Response template과 Ending이 독립적인 역할을 하기 때문이다.

섹션	역할	다른 섹션과의 의존성
Response template	출력 구조 정의 (High/Moderate/Low)	독립적
Ending	형식 제약 (반말, 5단어, 3개만)	독립적

• LLM 내부 처리 (추정):

Type 1 읽기 순서:
1. Introduction → "질문 생성기구나"
2. Response template → "3가지 카테고리로 나눠야지"
3. Ending → "반말 5단어로 제약하자"

Type 2 읽기 순서:
1. Introduction → "질문 생성기구나"
2. Ending → "반말 5단어로 제약하자"
3. Response template → "3가지 카테고리로 나눠야지"

• 실험 발견
  • 두 경우 모두 동일한 정보를 얻으므로, 순서와 무관하게 같은 결과를 생성한다.
    
  • 이 프롬프트는 섹션 순서에 민감하지 않다.
    
  • 각 섹션이 독립적으로 작동하기 때문에, 순서를 바꿔도 안전하다.

2.2.2 실험 2: 번역 Task

• 실험 설계: David에게 한국어를 가르치는 튜터 프롬프트다. “한국어로 번역해줘” 문장의 위치만 변경한다.
• Type 1 (지시문 마지막):

0. Please list out all the target words at first.
1. Use beginner-level Korean language. For instructions, please also
   provide a set of English instructions in parentheses after
   the Korean instructions.
2. Encourage David to speak more than you do.
3. Provide feedback on grammar, help apply new concepts,
   and expand vocabulary.
4. Adapt your teaching style based on David's responses
   and progress.
5. Use Korean for target vocabulary and example sentences.
   Use English for explanations and instructions.

한국어로 번역해줘.

• Type 2 (지시문 맨 앞):

한국어로 번역해줘

0. Please list out all the target words at first.
1. Use beginner-level Korean language. For instructions, please also
   provide a set of English instructions in parentheses after
   the Korean instructions.
2. Encourage David to speak more than you do.
3. Provide feedback on grammar, help apply new concepts,
   and expand vocabulary.
4. Adapt your teaching style based on David's responses
   and progress.
5. Use Korean for target vocabulary and example sentences.
   Use English for explanations and instructions.

테스트 입력: 영어 텍스트 5개 문단 * Type 1 결과:

[튜터 모드로 작동]
- 규칙 0-5를 따름
- 초급 한국어 사용
- 영어 설명 병기
- David의 학습 격려
- 마지막에 "전체를 한국어로 번역해줄까?" 질문 추가

• Type 2 결과:

[번역 모드로 작동]
- 규칙 0-5를 "번역할 때의 규칙"으로 해석
- 전체 텍스트를 초급 한국어로 번역
- 튜터 역할보다 번역 작업에 집중
- David 학습 격려 없음

비교 표:

평가 항목	Type 1 (마지막)	Type 2 (맨 앞)	차이
주요 역할	튜터	번역기	있음
규칙 해석	튜터의 교육 방식	번역 시 제약조건	있음
David 격려	✓ 있음	✗ 없음	있음
영어 설명 병기	✓ 있음	△ 일부만	있음
작업 초점	학습 대화	텍스트 번역	있음

• 실험결과: 차이 있음
  • 차이 발생 이유 :“한국어로 번역해줘”는 단순 지시문이 아니라 전체 맥락의 프레임을 결정하는 문장이다.
    
• LLM 내부 처리 (추정):

Type 1 읽기 순서:
1. 규칙 0-5 → "튜터 역할 규칙들이구나"
2. "한국어로 번역해줘" → "이 규칙들을 한국어로 설명해야겠네"
→ 프레임: "한국어 튜터"

Type 2 읽기 순서:
1. "한국어로 번역해줘" → "번역 작업이구나"
2. 규칙 0-5 → "번역할 때 이 규칙들을 적용해야겠네"
→ 프레임: "규칙 기반의 한국어 번역기"

프레이밍 효과:

위치	프레임 설정	이후 규칙 해석
맨 앞	번역 작업	규칙 = 번역 제약조건
맨 뒤	튜터 역할	규칙 = 교육 방식, 번역은 부가 요청

실험 후 발견:

• 이 프롬프트는 섹션 순서에 매우 민감하다.
  
• “한국어로 번역해줘”가 전체 맥락을 프레이밍하기 때문에, 위치가 달라지면 모든 규칙의 의미가 바뀐다.

2.2.3 두 예시 Prompt의 대조

비교 항목	Question Generation Prompt	번역 Task Prompt
섹션 관계	독립적	의존적 (프레이밍)
순서 변경 결과	차이 없음	차이 있음
핵심 발견	섹션 역할이 분리됨	한 문장이 전체 맥락 결정
구조 안정성	높음 (순서 바꿔도 안전)	낮음 (순서 중요)

• 구조 분석이 찾는 것: 모든 프롬프트가 구조 순서에 같은 방식으로 반응하지 않는다.
• 독립적 섹션 (예시 1 패턴):
  • 각 섹션이 다른 역할 담당
    
  • 순서와 무관하게 안정적
    
  • 수정 시 위험 낮음
    
• 프레이밍 섹션 (예시 2 패턴):
  • 한 문장/섹션이 전체 맥락 결정
    
  • 위치가 달라지면 의미 바뀜
    
  • 수정 시 신중해야 함
    
• 구조 분석의 필요성
  • 이 프롬프트에서 어떤 부분이 전체를 프레이밍하는 문장인지 확인
    
  • 그 부분의 위치가 결과를 바꾸는 변수이고, 그 외의 부분은 순서가 달라져도 괜찮을 수 있다.
    
  • 한 번은 “차이 없음”, 한 번은 “차이 있음”. 둘을 비교해야 왜 결과가 달라지는지가 깊이 보인다.
  • 구조 분석 없이 섹션 순서 변경 시 발생할 수 있는 문제 예시:

  개발자: "Ending을 앞으로 옮기자. 더 읽기 쉬울 것 같아."
  → 실험 1 패턴: 문제 없음
  → 실험 2 패턴: 전체 의미 바뀜
  
  3일 후: "왜 결과가 이상해졌지?"
  → 원인 파악에 2일 추가 소요

  • 구조 분석 후 수정하면:

  개발자: "구조 실험 결과, 이 프롬프트는 순서 민감형이네."
  PM: "그럼 섹션 위치 변경은 위험해. 다른 방법 찾자."
  → 안전한 수정 방향 즉시 선택

• 구조 분석은 “이 프롬프트에서 어떤 부분이 전체 성능을 결정하는가”를 찾는 단계다.
  
• 프레이밍 문장을 찾으면, 그 부분은 건드리지 않고 다른 부분만 최적화할 수 있다.
• 변경된 건 단 하나이다. “한국어로 번역해줘”라는 문장이 아래에서 위로 올라온 것.
• 나머지 텍스트는 한 글자도 바뀌지 않는다.
• 결과: 차이 있음. 왜인지를 본다.
  • 실험 1과 달라지는 점이 바로 여기에 있다.
    
  • “한국어로 번역해줘”는 단순한 지시문이 아니다.
    
  • 이 문장은 프롬프트 전체의 맥락을 프레이밍하는 문장이다.
    
  • 이것이 먼저 오면, 모델은 “번역 작업이다”라는 프레임 안에서 이후 규칙들을 읽는다.
    
  • 이것이 뒤에 오면, 모델은 먼저 튜터 규칙들을 일반적인 지시사항으로 읽고, 그 후에 번역이라는 작업이 추가된다.
    
  • 모델이 규칙들을 “번역의 규칙”으로 읽는지, 아니면 “튜터의 규칙”으로 읽는지가 달라진다.

2.3 효율성 평가

• 구조의 복잡성 평가
  
• 효율성 평가 기준: “프롬프트의 불필요한 정보의 유무” 그리고 “컨텍스트 풍부함 정도”
• 확인 방법: 프롬프트를 줄여서, 결과가 유지되는지 본다.

2.3.1 원본 vs 간단 버전 비교

원본 프롬프트 (Full Version):

You have a mind, and your role is to generate possible
three questions a user may want to ask next based on User
input: 개발자로 살아남으려면??

The questions must be from the perspective of me,
the user asking you a question.

## Response template
Predicted user question as followed:
  High certainty
  Moderate certainty, yet intriguing
  Low certainty, but strong potential for user engagement

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

간단 버전 (Minimal Version):

Please generate three questions based on
User input: 개발자로 살아남으려면? in Korean. Be short.

차이점 요약:

요소	원본	간단 버전	제거됨
역할 정의	“You have a mind, your role is…”	없음	✓
관점 지정	“from the perspective of me, the user”	없음	✓
카테고리 구조	High/Moderate/Low certainty	없음	✓
반말 지정	“half speech form of Korean 반말”	“in Korean”	✓
길이 제약	“Don’t be over five words”	“Be short”	△
개수 제약	“Only provide three questions”	“three questions”	✓

2.3.2 테스트 결과 비교

테스트 입력 5개:
1. “부산 여행”
2. “주식 투자”
3. “헬스 다이어트”
4. “강아지 훈련”
5. “영어 공부”

결과 비교 표:

입력	원본 결과	간단 버전 결과	차이 분석
부산 여행	High: 부산 뭐 할까? Mod: 어디 먼저 갈까? Low: 혼자 가도 괜찮아?	1. 부산에서 뭐 먹을까요? 2. 숙소 어디가 좋아요? 3. 언제 가는 게 좋을까요?	✗ 존댓말 혼입 ✗ 6-7단어 ✓ 각도 다름
주식 투자	High: 주식 어떻게 시작해? Mod: 어떤 종목 살까? Low: 지금 사도 괜찮아?	1. 어떤 주식이 좋을까요? 2. 주식 시작 방법 알려주세요 3. 안전한 투자 방법은?	✗ 존댓말 혼입 ✗ 5-7단어 △ 각도 약함
헬스 다이어트	High: 헬스 언제 해? Mod: 뭐 먹어야 해? Low: 얼마나 걸릴까?	1. 헬스 어떻게 시작하나요? 2. 식단은 어떻게 해요? 3. 운동 시간은?	✗ 존댓말 혼입 ✓ 4-6단어 ✓ 각도 다름
강아지 훈련	High: 강아지 훈련 뭐부터? Mod: 배변 어떻게 가르쳐? Low: 훈련사 부를까?	1. 강아지 훈련 방법은? 2. 언제 시작해야 하나요? 3. 비용은 얼마나?	△ 반말/존댓말 혼합 ✓ 4-6단어 ✓ 각도 다름
영어 공부	High: 영어 어떻게 공부해? Mod: 어디서 배울까? Low: 독학 가능해?	1. 영어 공부 방법? 2. 학원 vs 독학? 3. 얼마나 걸려요?	△ 반말/존댓말 혼합 ✓ 3-5단어 ✓ 각도 다름

통계 요약:

평가 기준	원본 성공률	간단 버전 성공률	차이
반말 준수	100% (5/5)	20% (1/5)	-80%p
5단어 이내	100% (5/5)	60% (3/5)	-40%p
각도 다양성	100% (5/5)	80% (4/5)	-20%p
카테고리 구분	100% (5/5)	0% (0/5)	-100%p
3개 질문	100% (5/5)	100% (5/5)	0%p

2.3.3 발견: 어떤 부분이 꼭 필요한가?

제거했을 때 문제 발생한 요소:

제거된 요소	영향	문제 발생률
“반말” 명시	존댓말 혼입	80% (4/5)
“5단어” 제약	질문 길어짐	40% (2/5)
카테고리 구조	High/Mod/Low 구분 사라짐	100% (5/5)
역할 정의	큰 영향 없음	0% (0/5)

제거해도 괜찮은 요소:

요소	이유
“You have a mind”	역할은 “question generator”로 충분
“from the perspective of me”	맥락상 자명함

최적화된 버전 제안:

간단 버전과 원본의 중간 형태로, 핵심만 남긴다.

Generate three questions based on user input in Korean.

User input: 개발자로 살아남으려면?

Format:
High certainty: [question]
Moderate certainty: [question]
Low certainty: [question]

Rules:
- Use 반말 (casual Korean)
- Max 5 words per question
- Three different angles

최적화 버전 테스트 결과:

평가 기준	최적화 버전 성공률	원본 대비
반말 준수	100% (5/5)	동일
5단어 이내	100% (5/5)	동일
각도 다양성	100% (5/5)	동일
카테고리 구분	100% (5/5)	동일
토큰 수	약 60 토큰	-40% 절약

2.3.4 효율성 vs 명확성 트레이드오프

길이	장점	단점	적합한 경우
긴 프롬프트 (원본)	명확한 지시 오해 방지	토큰 비용 높음 읽기 부담	복잡한 작업 정확성 중요
중간 (최적화)	핵심만 전달 비용 절감	적절한 밸런스	대부분 권장
짧은 (간단)	매우 저렴 빠른 실행	형식 불안정 결과 예측 어려움	간단한 작업 형식 덜 중요

왜 프롬프트 효율성 평가가 중요한가?

효율성 평가 없이 프롬프트 사용하면:

개발자: "프롬프트 작동 잘 되네. 배포하자."
→ 일 평균 10만 회 호출
→ 월 토큰 비용: $1,200

3개월 후 리뷰:
PM: "프롬프트 비용이 너무 높아요. 줄일 수 없나요?"
개발자: "음... 어떤 부분을 줄여야 안전한지 모르겠는데..."
→ 2주 테스트, 실패 3번, 결국 40% 절감 성공
→ 3개월간 불필요하게 $1,440 낭비

효율성 평가 후 배포하면:

개발자: "테스트 결과, 40% 줄여도 성능 동일."
PM: "좋아요. 최적화 버전으로 배포."
→ 월 토큰 비용: $720
→ 연간 $5,760 절약

추가 이점:
- 응답 속도 15% 개선
- API 호출 타임아웃 감소

효율성 평가는 “이 프롬프트의 어떤 부분이 실제로 기여하는가”를 찾는 단계다.
군더더기를 제거하면, 비용 절감과 성능 유지를 동시에 달성한다.

3 루브릭: 3 단계를 반복

• 세 단계(목적 확인, 구조 분석, 효율성 평가)를 체계적으로 반복할 수 있는 평가 기준을 정리
  
• 세 단계를 직접 해본 후에 루브릭을 봐야, 각 항목의 필요성과 당위성이 명확해진다.

3.1 정성적 평가 루브릭 (5점 Scale)

3.1.1 목적 확인 (Purpose Clarity)

점수	평가 기준	예시
5점	핵심 키워드 명확, 정보 흐름 논리적, 역할-구조-제약 순서 완벽	질문 생성기 원본 프롬프트
4점	핵심 키워드 있음, 흐름 대체로 논리적, 순서 약간 어색	역할 정의 없지만 나머지 명확
3점	키워드 일부 모호, 흐름 이해 가능하나 최적 아님	“짧게 답해”만 있고 구체적 제약 없음
2점	키워드 불명확, 흐름 뒤죽박죽, 의도 파악 어려움	제약조건이 역할 앞에 옴
1점	키워드 없음, 의도 전혀 알 수 없음	“뭔가 생성해줘” 수준

3.1.2 구조 분석 (Structure Robustness)

점수	평가 기준	예시
5점	섹션 독립적, 순서 변경해도 안정적, 프레이밍 문장 없음	Question Generator (실험 1)
4점	대부분 독립적, 1-2개 섹션만 순서 민감	일부 제약조건이 순서 의존
3점	일부 섹션 의존적, 순서 바뀌면 결과 약간 달라짐	출력 형식과 제약이 약하게 연결됨
2점	섹션 강하게 의존적, 순서 중요, 프레이밍 문장 있음	번역 Task (실험 2)
1점	모든 섹션 의존적, 순서 조금만 바뀌어도 무너짐	복잡한 다단계 프롬프트

3.1.3 효율성 평가 (Efficiency)

점수	평가 기준	예시
5점	최소한의 길이로 100% 성능, 불필요한 부분 없음	최적화 버전 (60 토큰)
4점	약간 긴 편이나 대부분 필요, 10-20% 줄일 수 있음	원본에서 역할 정의만 제거
3점	불필요한 부분 30-40%, 줄여도 성능 유지	원본 프롬프트 (100 토큰)
2점	절반이 군더더기, 50% 이상 줄일 수 있음	과도한 예시와 설명 포함
1점	대부분 불필요, 핵심만 남기면 80% 절약 가능	간단 버전으로도 충분한 경우

3.2 루브릭 점수 측정 방법

• 3가지 방법이 있고, 상황에 따라 선택한다

3.2.1 사람이 측정 (Manual Evaluation)

프로게스:
1. 평가자가 프롬프트를 읽는다
2. 3단계(목적 확인, 구조 분석, 효율성 평가)를 직접 수행한다
3. 각 단계별로 루브릭 기준과 비교하여 점수를 매긴다
4. 점수 근거를 기록한다

실제 평가 시나리오:

평가자 A (시니어 개발자):

[목적 확인 단계]
1. 프롬프트 읽기 → 핵심 키워드 표 작성
   - "generate three questions" ✓
   - "반말" ✓
   - "5 words" ✓
2. 정보 흐름 확인 → 역할→구조→제약 순서 ✓
3. 루브릭 비교 → 5점 기준 모두 충족
→ 목적 확인: 5점

[구조 분석 단계]
1. 섹션 순서 변경 실험 (Type 1 vs Type 2)
2. 결과 비교 → 차이 없음
3. 루브릭 비교 → "섹션 독립적, 순서 변경해도 안정적"
→ 구조 분석: 5점

[효율성 평가 단계]
1. 간단 버전 테스트 → 형식 80% 무너짐
2. 토큰 수 계산 → 100 토큰, 40% 줄일 수 있음
3. 루브릭 비교 → "불필요한 부분 30-40%"
→ 효율성: 3점

총점: 13/15점
소요 시간: 약 30분

• 장점:
  • 도메인 지식 반영 가능
    
  • 미묘한 뉘앙스 파악
    
  • 특수한 상황 고려
    
• 단점:
  • 시간 많이 소요 (프롬프트당 30분)
    
  • 평가자 간 평가기준이 비일관적 (평가 결과 불일치 가능성 높음)
    
  • 확장성 낮음 (100개 프롬프트 = 50시간)
    
  • 비용 높음 (평가자 인건비)
• 적합한 경우:
  • 중요한 프로덕션 프롬프트
    
  • 초기 프로토타입 단계
    
  • 팀 내 루브릭 캘리브레이션

3.2.2 LLM이 측정 (Automated Evaluation)

프로세스:
1. 메타 프롬프트 작성 (루브릭을 LLM에게 전달)
2. 평가 대상 프롬프트를 입력
3. LLM이 3단계 평가 수행 + 점수 산출
4. 점수와 근거를 JSON으로 반환

메타 프롬프트 예시:

You are a prompt evaluation expert. Evaluate the following prompt 
using this rubric:

## Rubric

### Purpose Clarity (5 points)
- 5: Clear keywords, logical flow, perfect role-structure-constraint order
- 4: Keywords present, mostly logical flow, slightly awkward order
- 3: Some keywords ambiguous, flow understandable but not optimal
- 2: Unclear keywords, chaotic flow, hard to understand intent
- 1: No keywords, intent completely unclear

### Structure Robustness (5 points)
- 5: Independent sections, stable with order changes, no framing sentences
- 4: Mostly independent, 1-2 sections order-sensitive
- 3: Some sections dependent, results change slightly with order
- 2: Strongly dependent sections, order critical, framing sentences present
- 1: All sections dependent, breaks easily with order changes

### Efficiency (5 points)
- 5: Minimal length with 100% performance, no unnecessary parts
- 4: Slightly long but mostly necessary, 10-20% reducible
- 3: 30-40% unnecessary, performance maintained when reduced
- 2: Half is filler, 50%+ reducible
- 1: Mostly unnecessary, 80% savings possible with core only

## Prompt to Evaluate

[평가 대상 프롬프트 삽입]

## Output Format

Return JSON:
{
  "purpose_clarity": {
    "score": <1-5>,
    "reasoning": "<이유>"
  },
  "structure_robustness": {
    "score": <1-5>,
    "reasoning": "<이유>"
  },
  "efficiency": {
    "score": <1-5>,
    "reasoning": "<이유>"
  },
  "total_score": <3-15>,
  "summary": "<종합 평가>"
}

LLM 평가 결과 예시:

{
  "purpose_clarity": {
    "score": 5,
    "reasoning": "핵심 키워드 명확 ('generate three questions', '반말', 'five words'). 역할→구조→제약 흐름 완벽."
  },
  "structure_robustness": {
    "score": 5,
    "reasoning": "Response template과 Ending 섹션이 독립적. 순서 변경 실험 결과 차이 없음."
  },
  "efficiency": {
    "score": 3,
    "reasoning": "100 토큰 중 약 40 토큰 줄일 수 있음 ('You have a mind', 'from the perspective' 불필요)."
  },
  "total_score": 13,
  "summary": "명확하고 구조적으로 안정적이나, 일부 불필요한 표현 제거 시 40% 효율 개선 가능."
}

장점:
- 빠름 (프롬프트당 10초)
- 확장성 높음 (1000개도 가능)
- 일관성 있음 (같은 프롬프트 → 같은 점수)
- 비용 저렴 (평가당 $0.01)
단점:
- 도메인 지식 제한적
- 실제 테스트 없이 추론만으로 평가
- 복잡한 프롬프트 오판 가능
- LLM 자체의 한계 (예: 토큰 수 정확히 세지 못함)
적합한 경우:
- 대량 프롬프트 평가 (100개 이상)
- 빠른 스크리닝 필요
- 지속적 모니터링 (CI/CD 파이프라인)

3.2.3 하이브리드 (Human + LLM)

프로세스:
1. 1차: LLM 자동 평가 (스크리닝)
- 전체 프롬프트를 LLM이 평가
- 낮은 점수 (≤10점) 필터링
2. 2차: 사람 수동 평가 (정밀 검증)
- 높은 점수 프롬프트만 사람이 재평가
- LLM 평가와 비교하여 최종 결정
3. 피드백 루프
- 사람의 평가 결과를 메타 프롬프트에 반영
- LLM 평가 정확도 지속 개선

실무 적용 사례:

시나리오: 50개 프롬프트 평가 필요

[1단계: LLM 스크리닝 (10분)]
- 50개 프롬프트 → LLM 자동 평가
- 결과: 15개 ≤10점, 35개 >10점

[2단계: 사람 정밀 평가 (3시간)]
- 35개 고득점 프롬프트만 사람이 재평가
- 결과: 5개는 LLM 오판 (실제 7-8점)
         30개는 LLM 평가 정확

[3단계: 최종 선정]
- 30개 검증된 프롬프트 중 상위 10개 선정
- 5개 오판 프롬프트는 개선 대상으로 분류

총 시간: 3.2시간
순수 사람 평가 시: 25시간 (50개 × 30분)
→ 87% 시간 절약

장단점 비교:

방법	속도	정확도	비용	확장성	적합한 규모
사람	느림	높음	높음	낮음	1-10개
LLM	빠름	중간	낮음	높음	100개 이상
하이브리드	중간	높음	중간	중간	10-100개

왜 하이브리드가 현실적인가? * 순수 사람 평가의 문제: 고차원 평가 but 너무 느리고 비용 높음

PM: "50개 프롬프트 평가해주세요."
개발자: "하나에 30분이면... 25시간이요?"
PM: "3일 걸리네요. 더 빠른 방법 없나요?"

• 순수 LLM 평가의 문제: 빠르고 저렴 but 신뢰도 및 전문성 문제

LLM 평가: "이 프롬프트 14점입니다."
개발자: "실제 테스트하니 7점 수준인데..."
PM: "LLM이 토큰 수도 제대로 못 세네요."
→ 신뢰도 문제

• 하이브리드 적용 시:

LLM: "50개 중 35개가 10점 이상입니다."
개발자: "35개만 직접 확인하면 되겠네요."
PM: "3시간이면 충분하겠어요. 시작하죠."
→ 효율 + 정확도 균형

3.3 루브릭 점수 신뢰도 높이는 방법

3.3.1 복수 평가자 (Inter-Rater Reliability)

3명의 평가자가 동일 프롬프트 평가:

평가자 A: 목적 5점, 구조 5점, 효율 3점 → 총 13점
평가자 B: 목적 4점, 구조 5점, 효율 3점 → 총 12점
평가자 C: 목적 5점, 구조 4점, 효율 3점 → 총 12점

평균: 12.3점
표준편차: 0.58 (낮음 → 신뢰도 높음)

3.3.2 캘리브레이션 세션

• 목표: 팀원 간 평가 기준 통일
  
• 시나리오: 팀원 4명이 동일 프롬프트를 평가
  
• 평가 대상 프롬프트 (고객 문의 응답 생성기):

You are a customer service agent. Generate a helpful response 
to the customer's question.

Customer question: 배송이 늦어지고 있어요. 언제 도착하나요?

Guidelines:
- Be polite and empathetic
- Provide actionable information
- Keep response under 100 words

1차 평가 결과 (기준 통일 전):

평가자	목적	구조	효율성	총점	효율성 평가 이유
A (시니어)	4	5	4	13	“100 단어 제약이 있어서 최적화됨”
B (주니어)	3	3	4	10	“길이 제약 명확해서 효율적”
C (PM)	5	4	5	14	“매우 짧고 핵심만 있음”
D (QA)	3	3	3	9	“가이드라인을 더 줄일 수 있을 것 같음”

• 표준편차: 2.16 (높음) → 평가 기준 불일치
  
• 토론 세션을 갖는다 예를 들어 1시간
  
• 1단계: 차이점 발견

팀 리드: "같은 프롬프트인데 9점부터 14점까지 나왔네요. 
         왜 이렇게 차이가 날까요?"

평가자 C: "저는 이 프롬프트가 매우 효율적이라고 봤어요. 
          딱 필요한 것만 있잖아요."

평가자 D: "저는 가이드라인 3개가 너무 일반적이라고 생각했어요. 
          'Be polite'는 customer service agent 역할에 이미 포함된 거 아닌가요?"

평가자 A: "아, 저도 그 부분은 생각 못 했네요. 
          저는 '100 words' 제약이 있어서 4점 줬어요."

2단계: 효율성 3점 기준 혼란 확인

팀 리드: "특히 효율성 점수가 3, 4, 4, 5로 다 다르네요. 
         각자 어떤 기준으로 매겼나요?"

평가자 A: "저는 토큰 수를 봤어요. 약 40 토큰이고, 
          역할 정의를 조금 줄이면 10-20% 절약 → 4점"

평가자 B: "저는... 솔직히 느낌이었어요. 
          '길이 제약이 있으니까 효율적이겠지' → 4점"

평가자 C: "저는 원본이 이미 최소한이라고 봤어요. 
          더 줄이면 의미가 손상될 것 같아서 → 5점"

평가자 D: "저는 간단 버전을 상상해봤어요. 
          'Generate polite response under 100 words'만으로도 될 것 같아서 
          30% 이상 줄일 수 있다 → 3점"

문제 발견: 각자 다른 방법으로 효율성을 평가함
- A: 토큰 수 계산 (정량적)
- B: 직관적 느낌 (주관적)
- C: 의미 손상 가능성 (보수적)
- D: 간단 버전 상상 (실험 없음)

3단계: 기준 합의

팀 리드: "루브릭을 다시 보죠."

[효율성 3점 기준]
- 불필요한 부분 30-40%
- 줄여도 성능 유지

팀 리드: "'불필요한 부분 30-40%'를 어떻게 판단할까요?"

평가자 D: "직접 테스트해야 할 것 같아요. 
          간단 버전 만들어서 실제로 돌려보고 비교해야죠."

평가자 A: "동의합니다. 그럼 절차를 정의하죠.

[합의된 효율성 평가 절차]
1. 간단 버전 작성 (핵심만 남김)
2. 5개 입력으로 원본 vs 간단 버전 테스트
3. 성공률 비교:
   - 원본 100% vs 간단 60-80% → 3점
   - 원본 100% vs 간단 80-90% → 4점
   - 원본 100% vs 간단 90-100% → 5점
4. 토큰 수 비교:
   - 30-40% 감소 → 3점 기준 확인
   - 10-20% 감소 → 4점 기준 확인

평가자 C: "좋아요. 이제 명확하네요."

4단계: 실제 테스트 (합의된 절차 적용)

간단 버전 작성:

Customer service agent. Answer customer questions 
politely under 100 words.

Question: 배송이 늦어지고 있어요. 언제 도착하나요?

5개 테스트 입력:

입력	원본 결과	간단 버전 결과	평가
“환불 어떻게 해요?”	공감 표현 + 절차 안내 + 100단어 이내 ✓	절차만 안내, 공감 표현 약함	△
“배송 추적이 안 돼요”	공감 + 해결책 + 간결 ✓	해결책만, 너무 짧음	△
“불량품이에요”	사과 + 교환 절차 + 적절한 길이 ✓	교환 절차만, 사과 없음	✗
“할인 쿠폰 사용법”	친절한 안내 + 단계별 설명 ✓	단계만 나열, 불친절	△
“계정 비밀번호 찾기”	안내 + 보안 주의사항 ✓	안내만, 보안 주의 없음	✗

결과: - 원본: 5/5 성공 (100%) - 간단 버전: 1/5 성공 (20%) - 공감/사과 표현 부족, 보안 주의사항 누락

토큰 수: - 원본: 40 토큰 - 간단 버전: 20 토큰 (50% 감소)

5단계: 재평가 (기준 통일 후)

평가자 A: "테스트 결과, 간단 버전은 20% 성공률이네요. 
          가이드라인이 실제로 필요했어요. 효율성 5점으로 수정합니다."

평가자 B: "저도 5점입니다. 각 가이드라인이 다 의미가 있었네요."

평가자 C: "5점 유지. 제 평가가 맞았네요."

평가자 D: "제가 틀렸네요. 'Be polite'가 없으니 공감 표현이 사라졌어요. 
          5점으로 수정합니다."

2차 평가 결과 (기준 통일 후):

평가자	목적	구조	효율성	총점	효율성 평가 이유
A (시니어)	4	5	5	14	“테스트 결과 간단 버전 20% 성공 → 원본 최적”
B (주니어)	4	4	5	13	“가이드라인 제거 시 품질 저하 확인”
C (PM)	5	4	5	14	“원본 평가 유지, 테스트로 검증됨”
D (QA)	4	4	5	13	“가이드라인이 실제로 필요했음을 확인”

표준편차: 0.5 (낮음) → 신뢰도 향상

캘리브레이션 효과:

지표	1차 평가	2차 평가	개선
평균 점수	11.5점	13.5점	+2점
표준편차	2.16	0.5	-77%
최대-최소 차이	5점	1점	-80%
평가 소요 시간	15분/명	25분/명	+67% (but 신뢰도↑)

핵심 교훈:

팀 리드: "이제 다음 프롬프트부터는 다들 같은 기준으로 평가하겠네요."

평가자 D: "특히 '실제 테스트'가 중요하다는 걸 배웠어요. 
          상상만으로는 안 되네요."

평가자 B: "저도요. 이제 평가할 때 간단 버전 만들어서 
          꼭 테스트해보겠습니다."

평가자 A: "캘리브레이션 세션이 1시간 걸렸지만, 
          앞으로 100개 프롬프트 평가할 때 시간 절약될 거예요."

캘리브레이션 후 팀 표준 문서:

# 효율성 평가 표준 절차 (ver 1.0)

## 3점 판단 기준
1. 간단 버전 작성 (제거할 요소 선택)
2. 5개 입력 테스트 (다양한 상황)
3. 성공률 측정:
   - 60-80% → 3점 (원본에 불필요한 부분 있음)
   - 80-90% → 4점 (약간 최적화 가능)
   - 90-100% → 5점 (이미 최적)
4. 토큰 수 확인 (보조 지표)
5. 평가 근거 기록 (재현 가능하도록)

## 주의사항
- 직관만으로 판단 금지
- 반드시 실제 테스트 수행
- 팀원과 평가 결과 공유

3.3.3 평가 가이드 문서화

효율성 3점 판단 기준 (상세화):

1. 간단 버전 작성 (핵심만 남김)
2. 5개 입력으로 테스트
3. 성공률 비교:
   - 원본 100% vs 간단 버전 60-80% → 3점
   - 원본 100% vs 간단 버전 80-90% → 4점
   - 원본 100% vs 간단 버전 <60% → 2점
4. 토큰 수 감소율:
   - 30-40% 감소 가능 → 3점
   - 10-20% 감소 가능 → 4점
   - 50%+ 감소 가능 → 2점

3.4 질문 생성기 프롬프트 평가 예시

위 루브릭으로 3가지 버전을 평가한다.

평가 결과 표:

버전	목적 확인	구조 분석	효율성 평가	총점	비고
원본 (Full)	5점	5점	3점	13/15	명확하고 안정적, 다소 김
간단 (Minimal)	2점	4점	5점	11/15	짧지만 형식 불안정
최적화 (Optimized)	5점	5점	5점	15/15	이상적 균형

세부 평가 근거:

원본 버전: - 목적 확인 5점: 핵심 키워드 완벽, 역할→구조→제약 흐름 논리적 - 구조 분석 5점: Response template과 Ending 독립적, 순서 변경 안전 - 효율성 3점: 100 토큰 중 40% 줄일 수 있음 (역할 정의, 관점 지정 불필요)

간단 버전: - 목적 확인 2점: “Be short”만으로 제약 불명확, 카테고리 구조 없음 - 구조 분석 4점: 짧아서 섹션 의존성 낮음, 하지만 형식 제어 약함 - 효율성 5점: 20 토큰으로 최소화, 더 줄일 곳 없음

최적화 버전: - 목적 확인 5점: 핵심만 남김, 명확한 규칙, 논리적 흐름 - 구조 분석 5점: 섹션 독립적, 안정적 구조 - 효율성 5점: 60 토큰으로 성능 100% 유지, 이상적 길이

3.5 루브릭 사용 워크플로우

프롬프트 작성 → 테스트 → 루브릭 평가 → 개선 → 재평가

실무 적용 시나리오:

Day 1: 새 프롬프트 작성
       → 루브릭 자가 평가: 목적 4점, 구조 3점, 효율성 2점

Day 2: 구조 개선 (프레이밍 문장 위치 조정)
       → 재평가: 목적 4점, 구조 5점, 효율성 2점

Day 3: 효율성 개선 (불필요한 예시 제거)
       → 재평가: 목적 4점, 구조 5점, 효율성 4점

Day 4: 목적 개선 (핵심 키워드 명확화)
       → 최종 평가: 목적 5점, 구조 5점, 효율성 4점
       → 총 14/15점, 배포 승인

팀 리뷰 시나리오:

개발자 A: "제 프롬프트 리뷰 부탁드립니다."

개발자 B (루브릭 적용):
- 목적 확인: 4점 (키워드는 있는데 흐름이 약간 어색해요)
- 구조 분석: 3점 (Ending을 앞으로 옮기면 어떨까요? 실험해보세요)
- 효율성: 2점 (예시가 너무 많아요. 1개면 충분할 것 같습니다)

개발자 A: "구체적 피드백 감사합니다. 바로 수정하겠습니다."
→ 주관적 "좋아요/별로에요" 대신 객관적 점수와 개선 방향 제시

3.6 왜 루브릭이 중요한가?

루브릭 없이 평가하면:

팀원 A: "이 프롬프트 어때요?"
팀원 B: "음... 괜찮은 것 같은데요?"
팀원 C: "저는 좀 긴 것 같아요."
팀원 D: "뭐가 긴데요? 저는 적당한데..."
→ 1시간 토론, 결론 없음

루브릭으로 평가하면:

팀원 A: "루브릭 평가 결과 공유합니다."
        목적 5점, 구조 4점, 효율성 3점

팀원 B: "효율성 3점이네요. 어떤 부분을 줄일까요?"
팀원 C: "역할 정의 부분이 불필요해 보입니다."
팀원 D: "동의합니다. 제거 후 재테스트하죠."
→ 10분 논의, 즉시 개선 방향 결정

루브릭은 주관적 느낌을 객관적 점수로 바꿔준다.
“좋다/나쁘다” → “어떤 부분이 몇 점이고, 왜 그런지”로 구체화된다.

3.7 루브릭의 한계와 보완

루브릭이 완벽하지 않은 경우:

상황	문제	해결 방법
도메인 특수성	일반 루브릭으로 측정 어려움	도메인별 추가 기준 마련
평가자 숙련도	초보자는 점수 매기기 어려움	예시 기반 가이드 제공
복잡한 프롬프트	다단계 프롬프트 평가 한계	단계별로 분리 평가

보완 방법:

1. 예시 라이브러리: 각 점수대별 실제 프롬프트 예시 축적
2. 팀 캘리브레이션: 같은 프롬프트를 함께 평가하며 기준 통일
3. 정량적 검증: 루브릭 점수와 실제 성능 지표 상관관계 확인

4 결론

• 앞서, 정성적과 정량적 방식으로 프롬프트의 품질을 평가한다는 것을 살펴보았다.
• 이번 블로그에서는 그 중 정성적 축을 실제로 사용한다: “이 프롬프트가 의도대로 작동하는지”를 세 단계(목적 확인, 구조 분석, 효율성 평가)로 본다.
• 그리고 그 세 단계를 루브릭으로 정리하여 반복 평가할 수 있게 만든다.
  
• 이후 다른 축, 즉 “얼마나 안정적으로 작동하는지”(정량적 평가)를 다룬다.