프롬프트 평가의 필요성과 정당성

1 들어가며

프롬프트 엔지니어링을 실무에 적용하다 보면 ’정답이 없는 프롬프트’를 평가 해야하는데 생각보다 쉽지 않다.

전통적인 소프트웨어 개발에서는 상대적으로 명확한 평가 기준이 있다. * 명확한 테스트 케이스와 예상 출력값이 있다.
* 따라서, 함수에 특정 입력을 넣었을 때 특정 출력이 나와야 한다는 것이 분명하다.
* 예를 들어, 2 + 2는 4여야 하고, 사용자 인증 함수는 올바른 비밀번호에 대해 true를 반환해야 한다.
* 이런 명확성 덕분에 structured test(unit test, integration test, system level test)를 수행하고, 코드가 의도대로 작동하는지 기계적으로 검증할 수 있다.

하지만 생성형 AI를 다루는 프롬프트 엔지니어링은 근본적으로 다른 세계다. * 같은 질문에도 무수히 많은 “괜찮은” 답변이 확률적으로 출력된다.
* 예를 들어 “Python 리스트를 정렬하는 방법” 질문에 대해, 어떤 답변은 sorted() 함수를 소개하고, 어떤 답변은 .sort() 메서드를 설명하고, 어떤 답변은 두 가지를 비교하며 설명한다.
* 어느 것이 “정답”인가? 맥락에 따라 다르다. 초보자에게는 단순한 설명이, 숙련자에게는 비교 분석이 더 나을 수 있다.

프롬프트 평가는 본질적으로 불완전하지만, 불완전함을 인식한 상태에서라도 반드시 해야 하는 실무적 필수 요소다.

그렇다면 프롬프트의 성능을 어떤 기준으로 평가해야 하는가?

1.1 평가 기준의 모호성: 텍스트 vs 의미

“답변이 텍스트 형태이므로 텍스트 자체를 기준으로 평가해야 할까?”

• 텍스트의 표면적 특성을 측정
• 답변의 길이의 적절성
• 전문 용어의 사용 빈도
• 문장/문단 구조의 복잡도
• 특정 키워드가 포함 유무

이런 표면적 지표만으로는 품질을 제대로 파악하기 어렵다. 예를 들어, 답변이 500단어라는 사실 자체는 좋고 나쁨을 말해주지 않는다. 어떤 질문에는 50단어면 충분하고, 어떤 질문에는 1000단어도 부족하다. 전문 용어 사용도 마찬가지다. 의학 전문가에게는 정확한 의학 용어를 쓰는 것이 신뢰를 주지만, 일반인에게는 쉬운 설명이 더 효과적이다.

더 심각한 문제는 텍스트 지표가 hallucination(환각)을 잡아내지 못한다. 문법적으로 완벽하고 구조도 훌륭한 500단어 답변이 사실은 완전히 틀린 정보일 수 있다.

“답변이 질문에 얼마나 정확하게 답했는지를 기준으로 평가해야 할까?”

• “정확성” 평가도 생각보다 복잡하다.
• 정확성에는 여러 층위가 있다. 이를테면, :
  • 사실적 정확성(Factual Accuracy): 답변에 포함된 정보가 객관적으로 맞는가? “지구는 태양 주위를 돈다”는 맞고, “태양이 지구 주위를 돈다”는 틀리다.
    
  • 의도 정확성(Intent Accuracy): 답변이 사용자가 정말로 원하는 것을 제공하는가? 사용자가 “파이썬 리스트 정렬”이라고 물었을 때, 코드 예제를 원하는 건가 개념 설명을 원하는 건가? 맥락을 제대로 파악해야 한다.
    
  • 절차적 정확성(Procedural Accuracy): 답변이 실행 가능한가? 특히 코드나 레시피 같은 절차적 지시를 다룰 때, 단계가 빠지거나 순서가 잘못되면 “정확”하더라도 쓸모없다.
    
• 만약 사용자가 애매하거나 불완전한 질문을 던진다면?
  • 예를 들어 “어제 본 그 영화 제목이 뭐였지?”라고 물으면, AI는 당연히 모른다.
  • 이때 AI는 “모른다” 또는 환각을 내뱉는다. 하지만 사용자 입장에서는 어느 것도 도움이 되지 않는다.
    
  • 더 나은 답변은 함께 질문을 구체화 시키는 제안 또는 대안을 제시하는 것이다.
  • 하지만, 이것도 “정확한” 답변은 아니다. 단지, 더 유용할 뿐이다.
    
• 이러한 질문들은 단순히 기술적인 문제가 아니라 철학적이고 실용적인 문제에 가깝다.

프롬프트 평가는 결국 “AI가 생성한 텍스트의 품질을 어떻게 정의하고 측정할 것인가”라는 근본적인 물음으로 귀결된다. 그리고 이 물음에 대한 답은 사용 사례, 사용자 특성, 상황 맥락에 따라 달라진다.

1.2 평가의 실무적 딜레마

실무에서는 이런 철학적 질문이 매우 구체적인 의사결정 문제로 나타난다. 예를 들어:

• A/B 테스트 상황: 두 가지 프롬프트 버전이 있는데, 어느 것을 배포할 것인가? 판단 기준이 필요하다.
• 모델 업데이트 후: 새 버전의 LLM이 나왔는데, 기존 프롬프트가 여전히 잘 작동하는가? 퇴화(regression)를 감지해야 한다.
• 비용 최적화: 프롬프트를 짧게 만들어 토큰 비용을 줄이고 싶은데, 품질 손실은 얼마나 되는가? 트레이드오프를 측정해야 한다.
• 팀 협업: 여러 사람이 프롬프트를 작성할 때, “이게 더 좋다”는 주장을 어떻게 뒷받침할 것인가? 공통 언어가 필요하다.

이 모든 상황에서 체계적인 평가 방법론이 없으면 주관적 판단에 의존하게 되고, 결과적으로 품질이 들쭉날쭉해진다.

2 프롬프트 평가의 4 가지 핵심 가치

이 네 가지는 각각 독립적이면서도 서로 긴밀하게 연결되어 있으며, 실무에서 구체적인 비즈니스 가치로 전환되는데 도움이 될 수 있다.

2.1 품질 보증 (Quality Assurance)의 체계화

• 실무에서 프롬프트가 만들어진 후 끊임없이 변화하는 환경에 노출된다.
  
• LLM의 모델 업데이트로 같은 프롬프트가 다른 결과를 낼 수 있다. OpenAI의 GPT-4가 GPT-4 Turbo로 업데이트되었을 때, 많은 개발자들이 기존에 잘 작동하던 프롬프트가 갑자기 이상한 답변을 내놓는 것을 경험했다.
  
• 체계적인 평가 기준이 없으면 이런 변화를 감지조차 할 수 없다.
• 평가 체계가 있다면 구체적으로 문제를 진단할 수 있다.
  
• 회귀 테스트(regression testing)를 가능하게 한다.
  • 회귀 테스트: 전통적인 소프트웨어 개발에서 새로운 코드 변경 후에도 여전히 올바르게 작동하는지 확인
    
  • 프롬프트를 수정할 때도 다른 측면에서 품질 저하가 없는지 확인해야 한다.
    
  • 예를 들어, 프롬프트를 짧게 줄여서 비용을 절감했는데, 알고 보니 정확도가 크게 떨어졌을 때 평가 시스템이 없으면 이를 배포 후에야 사용자 불만으로 알게 된다.

품질 보증은 또한 팀 협업의 기반이 된다. 공통된 평가 기준이 없기 때문에 발생하는 논쟁의 예를 보면:

• A: “이 프롬프트가 더 나은 것 같은데요.”
  
• B: “저는 이전 버전이 더 명확한 것 같은데요.”
  
• A: “하지만 제 버전이 더 자연스러워요.”
  
• B: “자연스러움보다는 정확성이 중요하지 않나요?”

하지만, 합의를 통해 “명확성 8점, 자연스러움 7점, 정확성 9점”처럼 구체적인 지표가 있다면, 데이터 기반 의사결정을 할 수 있다.

2.2 성능 최적화의 과학화

• 프롬프트 엔지니어링은 종종 예술처럼 여겨지지만, 과학적인 최적화 과정으로 만든다.
• 평가 지표가 있어야 최적화를 “측정 가능한” 작업으로 만들어 A/B 테스트를 수행할 수 있다.
• 예를 들어, 당신이 고객 지원 챗봇의 응답 시간을 줄이고 싶다고 하자.
  • 버전 A(역할 지시 없음): 평균 정확도 85%, 명확성 7.5점
    
  • 버전 B(역할 지시 있음): 평균 정확도 88%, 명확성 8.2점
    
  • 역할 지시가 3%p의 정확도 향상과 0.7점의 명확성 향상을 가져온다.
  • 이는 재현 가능한 패턴이 되고, 다른 프롬프트에도 적용할 수 있는 전략이 된다.
    
• 더 정교한 다차원 최적화도 가능하다:
  • 역할 지시(role)의 유무와 내용
    
  • 출력 형식(format) 지정
    
  • 예시(examples) 제공 여부
    
  • 사고 과정(chain-of-thought) 유도
    
  • 제약 조건(constraints) 명시
    
• 각 차원의 조합을 체계적으로 평가하면, 어떤 요소가 어떤 상황에서 효과적인지 데이터로 파악할 수 있다.
• 예를 들어, “우리 사용 사례에서는 few-shot 예시가 정확도를 12% 향상시키지만, 응답 길이를 30% 증가시킨다”처럼 트레이드오프를 정량화할 수 있다.
  
• 성능 최적화는 감이나 직관이 아니라, 데이터 기반의 체계적인 개선 과정으로 프롬프트 엔지니어링을 “엔지니어링”답게 만드는 핵심이다.
  
• 성능 최적화는 반복적 개선 프로세스를 가능하게 만들기 때문이다:
  1. 초기 프롬프트 작성
     
  2. 평가 지표로 성능 측정
     
  3. 약점 파악 (예: 정확도는 높지만 명확성이 낮음)
     
  4. 약점을 개선하는 방향으로 수정
     
  5. 다시 평가하여 개선 효과 확인
     
  6. 반복

2.3 비용 효율성의 정량화

• 생성형 AI를 운영하는 데는 실제 비용이 발생한다.
• API는 토큰 단위로 과금되고 긴 프롬프트와 긴 응답은 더 많은 비용을 발생시킨다.
  
• 만약 당신의 프롬프트가 평균 1,000 토큰이고, 응답이 평균 500 토큰이라면, 한 번의 호출에 약 $0.025가 든다.
• 하루에 10만 건의 요청을 처리한다면 하루 $2,500, 연간 약 $900,000이다. 10억 원이 넘는다.
  
• 이런 처리 수준은 더 이상 프롬프트 최적화 수준이 아닌 비즈니스 문제가 된다.
• 만약 프롬프트를 50%로 줄일 수 있다면 입력 비용이 50% 감소하여 연간 약 1억 8천만 원을 절감할 수 있다.
• 하지만, 여기서 중요한 핵심은 품질은 유지의 유무이다.
  
• 평가 시스템이 없으면 이 질문에 답할 수 없다. 하지만 평가 체계가 있다면:
  • 1,000 토큰 프롬프트: 정확도 90%, 명확성 8.5점
    
  • 500 토큰 프롬프트: 정확도 87%, 명확성 8.0점
    
• 이 비용과 성능의 Trade-off를 명확히 가늠하여 의사결정을 할 수 있다.
  • 고객 서비스 관련 기능이면 신중해야 한다.
  • 하지만 내부용 서비스라면 충분히 받아들일 만한 트레이드오프일 수 있다.
    
• “충분히 좋은” 수준의 정의
  • 모든 응답이 완벽할 필요는 없다.
  • Pareto 원칙(80/20 법칙): 80점짜리 답변을 생성하는 데는 적은 비용이 들지만, 95점짜리 답변을 만들려면 몇 배의 비용이 든다.
  • 사용 사례가 80점으로 충분하다면 오버엔지니어링하지 말아야 한다.
    
  • 평가 시스템은 이 “충분함”의 임계값을 찾는 데 도움을 준다.

2.4 사용자 경험 (UX)의 측정 가능화

• 모든 프롬프트는 사용자에게 가치를 제공하기 위해 존재한다.
• 사용자가 만족 여부의 측정이 궁극적인 평가 기준이다.
  • 전통적인 방법: 직접 피드백 수집 (각 응답에 thumbs up/down 버튼을 제공, 주기적 설문조사, 등)
  • 하지만 전통적인 방법에는 여러 가지 한계가 있다:
    1. 낮은 응답률: 대부분의 사용자는 피드백을 주지 않는다. 극단적으로 만족하거나 불만족할 때만 반응한다.
       
    2. 지연된 발견: 문제를 사용자가 경험한 후에야 알 수 있다.
       
    3. 확장성 부족: 모든 응답마다 피드백을 받을 수는 없다.
       
    4. 맥락 손실: “나쁨”이라는 평가만 있고, 왜 나쁜지 알 수 없다.
       
  • 프롬프트 평가 체계: 전통적 평가 방법을 보완하는 대리 지표(proxy metric) 역할을 한다.
    • 사용자가 만족할 만한 응답의 특성을 정의하고 (예: 명확성, 정확성, 공감, 정중함, 완성도), 이를 자동으로 측정한다.
      
    • 물론 자동 평가가 실제 사용자 만족도와 100% 일치하지는 않는다.
      
    • 하지만 연구에 따르면 80% 이상의 상관관계를 보인다면, 충분히 유용한 선행 지표가 된다.
      1. “Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena” (2023)
         • 저자: Lianmin Zheng et al. (UC Berkeley, LMSYS)
           
         • 출판: NeurIPS 2023 Datasets and Benchmarks Track
           
         • arXiv: 2306.05685
           
         • 핵심 결과: GPT-4를 judge로 사용했을 때 인간 평가와 80% 이상의 일치율(agreement)을 달성했다고 보고
           
         • 요약: “strong LLM judges like GPT-4 can match both controlled and crowdsourced human preferences well, achieving over 80% agreement, the same level of agreement between humans”
         • GitHub: FastChat LLM Judge
           
      2. “G-Eval: NLG Evaluation using GPT-4 with Better Human Alignment” (2023)
         • 저자: Yang Liu et al. (Microsoft Research)
           
         • 출판: arXiv preprint
           
         • arXiv: 2303.16634
           
         • 핵심 결과: GPT-4 기반의 G-Eval이 텍스트 요약 작업에서 인간 평가와 Spearman correlation 0.514를 달성하여, 기존의 모든 자동 평가 방법을 크게 능가
         • 방법론: Chain-of-Thought와 form-filling 패러다임 사용
           
         • GitHub: G-Eval Code
           
• 실시간 모니터링 가능
  • 품질 지표를 지속적으로 추적하면서, 특정 임계값 아래로 떨어지면 알림을 받을 수 있고 문제가 확산되기 전에 대응할 수 있다.
  • 예를 들어:
    • “지난 1시간 동안 명확성 점수가 평균 7.2에서 5.8로 떨어졌습니다”
      
    • “특정 유형의 질문(기술 지원)에서 완성도 점수가 유독 낮습니다”
      
• 사용자 세그먼트 및 Personalization 서비스의 발판 마련
  • 모든 사용자가 같은 것을 원하지 않는다:
    • 전문가 vs 초보자: 전문가는 정확하고 간결한 답변을, 초보자는 친절하고 자세한 설명을 선호
      
    • 급한 상황 vs 여유로운 상황: 긴급 문의는 즉각적인 해결책을, 탐색적 질문은 포괄적인 정보를 원함
      
    • 문화적 차이: 직접적인 의사소통을 선호하는 문화권 vs 간접적이고 공손한 표현을 중시하는 문화권

3 4 가지 가치의 상호작용

• 이 4가지는 독립적이지 않다. 서로 긴밀하게 연결되어 있고, 때로는 충돌하기도 한다.
  • 품질과 비용의 트레이드오프: 최고 품질을 추구하면 비용이 증가한다. 비용을 최소화하면 품질이 하락할 수 있다. 평가 시스템은 이 균형점을 찾는 데 도움을 준다.
    
  • 성능과 사용자 경험의 정렬: 기술적으로 최적화된 프롬프트가 항상 사용자가 선호하는 것은 아니다. 때로는 약간 덜 효율적이지만 더 친근한 답변이 사용자 만족도를 높일 수 있다.
    
  • 품질 보증과 혁신의 균형: 너무 엄격한 품질 기준은 실험과 혁신을 막을 수 있다. 평가 시스템은 “안전한 실험 공간”을 제공한다. 새로운 프롬프트를 작은 사용자 그룹에 테스트하고, 평가 지표로 성능을 확인한 후 점진적으로 확대할 수 있다.

4 평가의 딜레마: 객관화할 수 없는 것을 측정하는 것에 대한 어려움

4.1 기준의 주관성 문제

• ’좋은 답변, 충분한 등’의 수학적 명제가 아닌 표현은 주관적인 표현이므로 참/거짓 및 정량화하기 어렵다
• 예를 들어, 의료 AI Chatbot을 개발한다 했을 때 환자가 “머리가 아파요”라고 입력한다면:
  • 시나리오 1 - 긴급 상황 판단이 필요한 경우: “머리 통증과 함께 다음 증상이 있나요? (1) 시야 흐림 (2) 구토 (3) 목 경직. 이 증상들은 응급 상황일 수 있습니다”
    
  • 시나리오 2 - 일반적인 안내가 필요한 경우: “두통의 원인은 다양합니다. 스트레스, 수면 부족, 탈수, 긴장성 두통 등이 흔한 원인입니다. 충분한 수분 섭취와 휴식을 권장합니다”
    
  • 시나리오 3 - 즉각적인 행동 유도가 필요한 경우: “근처 병원이나 약국 위치를 찾아드릴까요? 아니면 예약 가능한 의사를 찾아드릴까요?”

어느 것이 “좋은” 답변인가? 맥락에 달려 있다. 환자의 증상 심각도, 의료 시스템 접근성, 시간대, 환자의 의료 지식 수준 등 여러 요인이 영향을 미친다. 하나의 절대적인 “정답 답변”은 존재하지 않는다.

4.2 정답 데이터셋의 부재

• 전통적인 기계학습에서는 레이블된 데이터셋이 있다.
• 하지만 생성형 AI의 경우, 무한히 많은 “괜찮은 답변”이 존재한다.
• 예를 들어, “파이썬에서 리스트를 역순으로 만드는 방법”이라는 질문에 대해:

# 방법 1: reverse() 메서드
my_list.reverse()

# 방법 2: reversed() 함수  
new_list = list(reversed(my_list))

# 방법 3: 슬라이싱
new_list = my_list[::-1]

# 방법 4: 반복문
new_list = []
for i in range(len(my_list)-1, -1, -1):
    new_list.append(my_list[i])

• 이 4가지 방법 모두 정확하다. 어떤 답변이 “최선”인가? 사용자의 파이썬 숙련도, 코드 가독성 선호도, 성능 요구사항에 따라 다르다.
  • 초보자에게는 방법 1이 가장 직관적이지만
  • 원본 리스트를 보존해야 한다면 방법 2나 3이 낫다.
  • 교육 목적이라면 방법 4처럼 기본 원리를 보여주는 것이 가치있을 수 있다.

그렇다면 무엇과 비교해서 평가해야 하는가? 미리 만들어둔 “완벽한 답변”과 비교할 수 없다. 왜냐하면 완벽한 답변 자체가 맥락에 따라 달라지기 때문이다.

4.3 평가자의 평가: 누가 평가자를 판단하는가

• 더 근본적인 문제는 “평가 기준 자체를 누가 평가하는가”이다.
• “명확성”이라는 평가 기준을 만들었을 때 “명확성” 개념이 실제 사용자의 “명확성” 개념과 일치한다는 보장이 있는가?
• 실제로 이런 난이도 높은 불일치 문제는 자주 발생한다.
  • 개발팀은 “기술적으로 정확한” 답변을 명확하다고 생각하지만, 비전문가 사용자는 “이해하기 쉬운” 답변을 명확하다고 느낀다.
  • 전자는 “OAuth 2.0의 인증 플로우는 Authorization Code Grant 방식을 사용합니다”라고 설명하는 것을 선호하지만,
  • 후자는 “로그인 버튼을 누르면 권한을 요청하는 창이 뜨고, 승인하면 앱이 당신의 정보에 접근할 수 있게 됩니다”라는 설명을 선호한다.

4.4 맥락 의존성의 함정

• 또 다른 난점: 맥락 의존성
• 같은 프롬프트라도 다른 맥락에서는 다르게 평가되어야 한다.
  
• 고객 지원 챗봇을 다시 예로 들면:

상황 A - 오전 9시, 일반 문의:
사용자: “환불 정책이 어떻게 되나요?”
AI: “환불은 구매 후 30일 이내에 가능합니다. 제품이 미개봉 상태여야 하며, 영수증이 필요합니다. 환불 신청은 웹사이트의 ’주문 내역’에서 하실 수 있습니다.”
→ 이 답변은 완벽하다. 명확하고, 완전하고, 실행 가능하다.

상황 B - 새벽 2시, 긴급 문의:
사용자: “환불 정책이 어떻게 되나요?”
AI: “환불은 구매 후 30일 이내에 가능합니다. 제품이 미개봉 상태여야 하며, 영수증이 필요합니다. 환불 신청은 웹사이트의 ’주문 내역’에서 하실 수 있습니다.”
→ 이 답변은 불충분할 수 있다. 새벽 시간에 문의한다는 것은 급한 상황일 가능성이 높다. “고객센터는 평일 오전 9시에 시작되며, 긴급 상황이시라면 24시간 이메일 지원(support@…)으로 문의해주세요”라는 추가 정보가 필요하다.

같은 답변이 맥락에 따라 우수할 수도, 부족할 수도 있다. 평가 시스템이 이런 맥락을 포착할 수 있어야 한다.

4.5 순환 논리의 위험

• “AI로 AI를 평가한다”는 접근에는 순환 논리의 위험이 있다.
• GPT-4가 생성한 답변을 GPT-4가 평가한다면? 모델의 편향(bias)이 평가에도 반영될 수 있다.
• 예를 들어, GPT-4가 특정 스타일의 답변을 선호한다면, 그 스타일의 답변에 높은 점수를 줄 것이다. 하지만 그 스타일이 실제로 사용자에게 좋은지는 별개의 문제다.
  
• 이는 특히 다양성(diversity)과 창의성(creativity) 평가에서 문제가 된다.
• 모델이 “안전하고 예측 가능한” 답변을 선호하도록 학습되었다면, 창의적이지만 예상 밖의 답변에 낮은 점수를 줄 수 있다.
• 하지만 어떤 사용 사례에서는 바로 그 창의성이 가치있을 수 있다.

5 딜레마를 넘어서: LLM-as-a-Judge의 실용적 접근

• 이 모든 딜레마에도 불구하고, 우리는 여전히 프롬프트를 평가해야 한다.
• 완벽한 평가 시스템을 기다릴 수 없다.
• 비즈니스는 계속되고, 의사결정은 매일 내려져야 한다.

5.1 “LLM-as-a-Judge”** 방법론 등장

• AI를 평가하는 데 AI를 사용한다.
  
• 이는 완벽하지 않다는 것을 인정하면서도, 실용적으로 충분히 유용하다는 것을 입증한 접근법이다.
  
• 언뜻 순환 논리처럼 보이지만, 실제로는 매우 합리적이다.
  • 인간도 다른 인간의 글쓰기를 평가한다.
    
  • 선생님이 학생의 에세이를 평가하고,
    
  • 편집자가 작가의 원고를 평가한다.
    
• 핵심은 검증(validation)
  • 평가자와 피평가자가 같은 종류의 지능을 가졌다고 해서 평가가 무의미한 것은 아니다.
  • 오히려 같은 종류의 지능이기 때문에 더 정교한 평가가 가능할 수 있다.
    
  • LLM의 평가가 인간 전문가의 평가와 얼마나 일치하는지 측정하고, 충분한 일치도(예: 80% 이상)가 확인되면 대규모로 사용하는 것이다. 완벽하지 않지만, 수동 평가보다 훨씬 빠르고 저렴하며 확장 가능하다.

프롬프트 평가는 완벽할 수 없다. 하지만 그렇다고 평가하지 않을 수도 없다. 우리가 할 수 있는 최선은, 평가 방법의 한계를 인식하면서도, 지속적으로 개선해나가는 것이다. 그 구체적인 방법을 찾아야한다.