다양한 LLM을 활용한 도구 호출 에이전트

1 이 글을 읽기 전에

프롬프트를 작성하면 끝이라고 생각하는 사람은 많다.
하지만 프롬프트 엔지니어링의 실질적인 난이도는 “작성”이 아니라 “작성한 프롬프트가 실제로 제대로 작동하는지 확인하는 것”에 있다.
이 파트는 그 확인 과정, 즉 프롬프트 테스트가 왜 필요한지, 그리고 왜 단순하지 않은지를 다룬다.

2 테스트는 별도의 단계가 아니다

프롬프트 테스트를 처음 접하면 자연스럽게 이런 이미지가 떠올린다:
“프롬프트를 완성 -> 테스트 실행 -> 통과하면 끝.” 하지만 이 이미지는 현실과 꽤 멀다.

Microsoft의 LLM 개발 가이드라인에서 제시한 프롬프트 개발 프로세스를 보자.

1단계: Design & Development  
  - 프롬프트를 작성하고, 소규모 데이터로 실행해본다.  
  - 결과가 만족스럽지 않으면? -> 프롬프트를 수정하여 다시 실행.  
  - 만족스럽지 않은 루프가 끝날 때까지 반복.  
  
2단계: Evaluation & Refinement  
  - 1단계를 통과한 프롬프트를 이번엔 대규모 데이터로 평가한다.  
  - 평가 기준: 품질, 관련성, 안전성 등 다중 차원(요인).  
  - 여기서도 불만족이면 1단계로 돌아간다.  
  
3단계: Optimization & Production  
  - 2단계를 통과한 프롬프트를 최적화하여 배포한다.  
  - 배포 후에도 실제 사용자 피드백을 수집하여 루프를 유지한다.  

이 프로세스에서 눈에 띄는 구조가 있다.
“If satisfied”라는 판단 포인트가 두 번 등장하고, 둘 다 불만족이면 이전 단계로 돌아간다.

테스트는 프롬프트 개발의 “마지막 단계”가 아니라, 개발 자체와 분리 불가능한 반복 루프의 일부이다.
이 인식이 없으면 이후로 나오는 모든 테스트 방법론이 “추가 작업”으로 느껴질 수 있다.
하지만 실제로는 테스트 없이는 프롬프트가 완성되지 않는다.

3 프롬프트 테스트의 세 가지 어려움

테스트 자체가 왜 어려운지를 이해하면, 나중에 나오는 아홉 가지 규칙과 다양한 테스트 방법이 왜 그런 형태로 설계되었는지가 납득된다.
강사는 어려움을 세 가지로 정리한다.

3.1 프롬프트는 텍스트이다

이건 자명해 보이지만, 여기에 핵심이 숨어 있다.
코드는 실행 결과가 결정적(deterministic)이다. 같은 입력 -> 같은 출력.

하지만 프롬프트는 LLM에게 넘기는 것이고, LLM은 확률적(stochastic)으로 응답한다.
같은 프롬프트를 두 번 실행해도 결과가 달라질 수 있다.

이는 테스트 자체의 신뢰성을 흔든다.
“한 번 실행해서 좋은 결과가 나왔다”는 것은 “이 프롬프트는 항상 좋은 결과를 준다”를 보장하지 못한다.
나중에 N번 반복 생성(N > 300)이 정량적 테스트의 기본 수단이 되는 이유가 바로 이것이다.

3.1.1 왜 100번을 초과해서 반복 테스트하나?

통계학적으로 큰수의 법칙(또는 중심극한정리)을 적용하면 n≥30이면 충분할 것 같지만, LLM 프롬프트 테스트에서 100번 이상을 요구하는 데는 다음과 같은 이유가 있다:

희귀하지만 치명적인 오류 탐지

프롬프트 테스트의 핵심은 “평균적으로 잘 작동하는가”가 아니라 “극단적 상황에서도 안전한가”이다.

프롬프트를 100번 실행하면 1번 정도 심각한 문제(환각, 유해 콘텐츠, 완전히 잘못된 답변)가 발생한다고 가정한다. 이런 “100번 중 1번 꼴로 나타나는 문제”를 테스트에서 거의 확실하게(95% 확률로) 한 번이라도 발견하려면 충분한 횟수의 테스트를 진행해야한다.

즉, 1% 확률로 발생하는 심각한 오류(환각, 유해 콘텐츠, 완전히 잘못된 답변)를 95% 신뢰도로 최소 1번 관찰하려면:
- 수식: 1 - 0.99^n ≥ 0.95
- 필요한 테스트 횟수: n ≈ 300번

직관적으로 설명하면, 99%가 정상인 상황에서 나쁜 1%를 찾으려면 훨씬 많은 시도가 필요하다. 30번만 테스트하면 그 희귀한 문제를 놓칠 가능성이 74%나 된다. 복권에 당첨될 확률이 1%일 때, 30장만 사면 당첨을 한 번도 못 볼 가능성이 높은 것과 같은 원리다.

3.2 다차원 평가의 복합성

위에서 언급한 “다차원적 평가”가 핵심이다:

• 품질(Quality)
• 관련성(Relevance)
  
• 안전성(Safety)
• 일관성(Consistency)
• 형식 준수(Format Compliance)

각 차원을 독립적으로 평가하려면 각각 충분한 샘플이 필요하다. 5개 차원이면 실질적으로 각 차원당 20개 샘플밖에 안 된다.

예를 들어 100번 테스트를 한다고 가정할 때, 평가해야 할 차원이 5개(품질, 관련성, 안전성, 일관성, 형식 준수)라면 각 차원별로 독립적인 사례(샘플)를 충분히 확보해야 한다는 뜻이다. 하지만 100번을 5개 차원에 “균등하게” 나누면, 각 차원별로 평균 20개 샘플만 평가하게 된다. 실제로는 한 번의 테스트 결과가 여러 차원에 동시에 평가될 수도 있지만, 각 차원별로 충분한 통계적 신뢰도를 확보하려면 20개로는 부족하다.

각 차원별로 최소 30~50개(혹은 그 이상)가 필요하다고 보는 이유는 통계적 신뢰성과 실무적 경험 모두에서 근거가 있다.
- 통계학에서 n≥30이면 표본평균이 정규분포에 근사한다고 본다.
- 표본 수가 30 미만이면 결과의 변동성이 크고, 신뢰구간도 넓어진다.
- 30~50개 이상이면 평균, 비율, 분산 등 주요 통계량의 신뢰도가 크게 높아진다.

실무적 근거(품질관리, A/B 테스트 관행, 등):
- 품질관리, 설문조사, A/B 테스트 등 다양한 분야에서 “최소 30~50개”를 경험적 기준으로 삼는다.
- 너무 적으면 우연에 의한 결과(노이즈)에 민감해져, 실제 품질이나 문제를 놓칠 수 있다.

LLM의 높은 변동성
- LLM 응답은 분산이 크고, 극단값(아주 좋은/나쁜 결과)이 자주 나타난다.
- 적은 샘플로는 이런 변동성을 포착하기 어렵다.

다차원 평가의 특성
- 각 차원(품질, 안전성 등)마다 분포와 문제 유형이 다르다.
- 한 차원에서만 드물게 발생하는 문제(예: 안전성 이슈)는 더 많은 샘플이 필요하다.

3.3 분산의 분산 문제

Temperature 설정이 0.7~1.0일 때 LLM 출력의 변동성은 일반적인 통계 분포보다 훨씬 크다:

• 일반 통계: 정규분포 가정 가능
• LLM 출력: 다중 모드 분포, 긴 꼬리 분포 가능
• 어떤 실행에서는 3문장, 어떤 실행에서는 10문장에서 답변 스타일이 극단적으로 달라질 수 있음

이런 복잡한 분포 특성을 파악하려면 30개로는 부족하다.

3.4 프로덕션 환경 시뮬레이션

실제 서비스에서 프롬프트는 수천~수만 번 실행된다:

• 30번 테스트 = 0.3% 샘플링
  • 실제로는 10,000번 정도 프롬프트가 실행될 수 있는데, 그 중 30번만 테스트하면 전체의 0.3%만 확인하는 셈이다.
• 100번 테스트 = 1% 샘플링
  • 10,000번 중 100번을 테스트하면 전체의 1%를 미리 점검하는 것.
• 1000번 실행 중 가장 나쁜 1%를 미리 경험하려면 100번 이상 필요
  • 만약 실제 서비스에서 1000번 프롬프트가 실행된다면, 그 중 가장 나쁜 1% (즉, 10번 정도 발생할 수 있는 문제 상황)를 테스트 단계에서 미리 경험하려면 최소 100번 이상은 테스트해야 한다
    
  • 즉, 테스트 횟수가 적으면 실제 서비스에서 드물게 발생하는(1% 확률) 문제를 사전에 발견하지 못할 수 있다는 뜻이다.

4 통계적 검정력(Statistical Power)

두 프롬프트 A와 B의 성능을 비교할 때:

• Cohen’s d = 0.5 (중간 효과 크기: 두 그룹간의 차이 크기가 중간 정도)를
• 80% 검정력(Power, 두 그룹간의 실제로 차이가 있을 때 그 차이를 “놓치지 않고” 잡아낼 확률)과
• 95% 신뢰수준(결과가 우연이 아닐 확률이 95%라는 의미, 오차 가능성 5%) 으로 탐지하려면
• 각 그룹당 최소 64개 샘플 필요, 총 128개

30개로는 검정력이 47% 수준으로 떨어져, 실제 차이가 있어도 감지 못할 확률이 53%나 된다.

결론:

통계학의 큰 수의 법칙은 “평균의 안정성”에 관한 것이지만, 프롬프트 테스트는: - 희귀 사건 탐지 - 최악의 경우(worst case) 파악 - 다차원 동시 평가 - 높은 분산 환경

을 다뤄야 하므로, 30개는 “평균을 아는 것”에는 충분하지만, “안전성을 보장하는 것”에는 부족하다.

100번이 절대적 기준은 아니지만, 실무적으로 비용과 신뢰성의 균형점으로 자리잡은 것이다.

4.1 프롬프트에는 정답이 없다

단위 테스트에서는 예상 출력값을 미리 정의할 수 있다.
프롬프트 테스트에서는 그것이 불가능하다.

예를 들어 “부산의 맛있는 음식 추천”이라는 프롬프트가 있을 때,
한국어로 답하는 것도 좋고, 영어로 답하는 것도 나쁜 건 아니다.
밀면을 추천하든 해물탕을 추천하든, 둘 다 정답일 수 있다.
하지만 일본어로 답하거나 존재하지 않는 음식을 추천하면 그건 문제이다.

따라서 테스트 기준은 “정답과 일치하는가?”가 아니라 다차원적 평가가 될 수밖에 있다.
정성적 루브릭과 정량적 패턴 분석을 병용하는 이유가 바로 여기서 온다.
- 정성적 루브릭 (채점표): 사람이 직접 답변을 보고 “좋다/나쁘다”, “적절하다/부적절하다” 등 주관적 기준(체크리스트, 평가표)으로 평가하는 방법.
- 예: 답변이 논리적인가? 문법 오류가 없는가? 맥락에 맞는가?
- 정량적 패턴 분석: 답변의 길이, 특정 키워드 출현 빈도, 형식 일치율, 오류 발생률 등 수치로 측정 가능한 지표를 활용해 평가하는 방법.
- 예: 100개 중 5개가 금지어를 포함, 평균 답변 길이 120자 등

프롬프트의 “정답”이 명확하지 않기 때문에, 수치로만 평가하면 놓치는 부분(논리, 맥락, 창의성 등)이 있고 사람의 주관적 평가만으로는 일관성과 객관성이 부족하다. 그래서 두 방법을 “병용”해야 프롬프트의 품질을 다차원적으로, 더 신뢰성 있게 평가할 수 있다는 의미다.

4.2 LLM은 빠르게 변한다

GPT-3.5에서 GPT-4로, GPT-4에서 GPT-5로 모델이 업데이트되면 동일한 프롬프트의 응답 품질과 패턴이 달라질 수 있다.
어제까지 잘 작동하던 프롬프트가 오늘 모델 패치 후 이상하게 작동하는 것은 실제로 일어나는 일이다.

이는 단순한 불편이 아니라 구조적 문제이다.
프롬프트의 수명은 모델의 수명보다 짧을 수 있다.
그러면 프롬프트는 한 번 완성하고 끝이 아니라, 지속적으로 재검증해야 하는 것이다.
이 세 번째 어려움이 버전 관리와 반복 테스트가 강조되는 근본적 이유이다.

5 세 어려움이 수렴하는 곳

세 어려움을 하나의 결과로 수렴시킬 수 있다: 일관성과 품질 안정성.

확률적 응답 + 정답 없음 + 모델 변화 = 프롬프트의 출력이 불안정하다.
이 불안정성을 통제하는 것이 테스트 방법론의 존재 이유이다.

이후 파트에서 나오는 아홉 가지 규칙, 정성적 분석, 정량적 분석, 루브릭 등 모든 수단은
이 하나의 문제 “어떻게 프롬프트의 품질을 일관하게 유지할 수 있는가?”에 대한 답변이다.