제가 보는 대부분의 프롬프트 반복 작업 개발자들은 다음과 같이 행동합니다: 플레이그라운드(playground)에 프롬프트를 붙여넣고, 단어를 수정하고, 출력을 눈으로 확인하고, 다시 수정합니다. 한 시간 뒤면 API 호출에 실제 돈을 쓰게 되지만, 여전히 가장 중요한 질문에는 답할 수 없습니다: 이 변경 사항이 실제로 도움이 되었는가?

문제는 모델이 아닙니다. 측정 수단이 없다는 것입니다. 테스트 없이 코드 변경 사항을 배포하지는 않겠지만, 프롬프트는 끊임없이 YOLO(You Only Live Once) 방식으로 운영 환경에 투입됩니다.

이 포스트에서는 Python으로 작성된 작고 재사용 가능한 프롬프트 테스트 하네스(test harness)와, 실험 단계에서 비용이 전혀 들지 않도록 무료 모델 액세스를 대상으로 이를 실행하는 워크플로우를 소개합니다. 결과적으로 프롬프트 버전 간에 차이(diff)를 비교할 수 있는 합격/불합격(pass/fail) 보고서를 얻게 될 것입니다.

핵심 아이디어: 프롬프트는 코드입니다, 코드처럼 테스트하세요

프롬프트 테스트는 세 가지 부분으로 구성됩니다:

1. 고정된 입력 세트 (A fixed input set) — 까다로운 엣지 케이스(edge cases)를 포함한 현실적인 사례들.
2. 어설션 (An assertion) — 키워드 존재 여부, JSON 유효성, 길이 제한, 정규 표현식(regex) 일치와 같이 저렴하고 자동화된 무언가.
3. 러너 (A runner) — 모든 (프롬프트 버전 × 입력 × 어설션) 조합을 실행하고 보고서를 출력합니다.

단순하게 유지하세요. 화려한 LLM-as-judge 스코어링은 나중에 해도 됩니다. 대부분의 프롬프트 퇴보(regression)는 지루한 어설션만으로도 잡아낼 수 있습니다.

하네스 (The harness)

엔지니어가 아닌 사람도 편집할 수 있도록 테스트 케이스를 JSON으로 저장하세요:

// cases.json
[
  {
...

러너(Runner). 환경 변수를 통해 OpenAI 호환 엔드포인트(endpoint)를 지정하면, 동일한 하네스를 유료 API, 로컬 모델, 또는 무료 호스팅 모델에 모두 사용할 수 있습니다:

# harness.py
import json, os, sys, time
from openai import OpenAI
...

사용법:

pip install openai
LLM_BASE_URL="https://your-endpoint/v1" \
LLM_API_KEY="your-key" \
...

이제 프롬프트 반복 작업은 다음과 같이 진행됩니다: prompt_v3.txt를 수정하고, 다시 실행하고, 보고서를 읽습니다. v4 버전에서 "이메일이 포함되지 않음" 케이스가 퇴보한다면, 단순히 출력이 나빠졌다는 막연한 느낌이 아니라 어떤 케이스가 깨졌는지 정확히 알 수 있습니다.

무료 컴퓨팅의 활용

프롬프트 작업에서 비용이 많이 드는 부분은 바로 규모(volume)입니다. 수십 개의 테스트 케이스 × 수십 번의 프롬프트 수정 × 몇 가지 후보 모델을 조합하면 유료 API 비용은 빠르게 불어납니다. 저렴한 해결책은 이 전체 반복 루프(iteration loop)를 무료 모델 액세스를 통해 수행한 다음, 마지막 단계에서 최종 게이트(gate)로서 프로덕션 모델(production model)을 대상으로 테스트 하네스(harness)를 한 번 실행하는 것입니다.

고지 사항: 이 기사는 MonkeyCode의 제품 홍보의 일환으로 작성되었습니다.

이러한 무료 티어(free tier)를 위한 한 가지 옵션은 MonkeyCode입니다. MonkeyCode는 무료 모델 액세스와 더불어 실행 환경(runner environment)으로 사용할 수 있는 무료 서버 옵션을 제공합니다. 이는 테스트 하네스를 노트북에서 실행하거나 CI 분(minutes)을 소모하고 싶지 않은 경우 매우 유용합니다. 위에서 설명한 테스트 하네스는 엔드포인트에 구애받지 않으므로(endpoint-agnostic), LLM_BASE_URL과 LLM_MODEL을 해당 환경에서 사용 가능한 값으로 설정하기만 하면 워크플로우는 변하지 않습니다. 유사한 루프를 구축하고 있다면, 무료 반복 단계(iteration phase)를 실행하기에 합리적인 장소입니다.

무료 티어 결과를 신뢰해야 하는 시점에 대한 결정 테이블

원칙: _차이(differential)_에 관한 질문("v4가 v3보다 나은가?")에는 무료 모델을 사용하고, _절대적(absolute)_인 질문("이것을 출시하기에 충분히 좋은가?")에는 유료/프로덕션 모델을 사용하십시오.

솔직한 한계점

• 티어 간의 모델 드리프트 (Model drift). 무료 모델에 맞춰 튜닝된 프롬프트는 프로덕션 모델에서 다르게 동작할 수 있습니다. 배포하기 전에 항상 실제 모델에서 전체 스위트(suite)를 다시 실행하십시오. 이것은 형식적인 절차가 아니라 반드시 거쳐야 하는 게이트(gate)입니다.
• 어설션(Assertions)의 얕은 깊이. contains 체크 방식은 미묘한 품질 저하(regression)를 잡아내지 못합니다. 사용자에게 노출되는 기능이라면, 상위 몇 개의 실패 사례에 대해 인간의 검토(human review) 단계를 추가하십시오.
• 무료 티어의 변동성. 모든 무료 서비스의 가용성, 속도 제한(rate limits), 모델 선택 사항은 예고 없이 변경될 수 있습니다. 특정 서비스에 의존하는 CI 파이프라인을 구축하지 마십시오. 이를 편의를 위한 계층(convenience layer)으로 취급하십시오.
• 동시성(Concurrency) 문제. 이 테스트 하네스의 규모를 키운다면, 무료 엔드포인트가 보통 가장 먼저 속도 제한(throttle)을 걸 것입니다. 테스트 스위트를 작고 순차적으로 유지하십시오.

누가 이 과정을 건너뛰어도 되는가

만약 일주일에 프롬프트를 몇 번 정도만 실행한다면, 플레이그라운드 (Playground)를 사용하는 것만으로도 충분합니다. 이 경우 테스트 하네스 (Test Harness)를 구축하는 것은 오히려 오버헤드 (Overhead)가 됩니다. 하지만 여러 사람이 프롬프트를 편집하거나, 프롬프트가 제품에 내장되어 있거나, 사용자가 발견하기 전에 회귀 (Regression)를 포착해야 하는 상황이라면 테스트 하네스는 그 가치를 발휘합니다.

더 넓은 관점에서 중요한 점은 특정 제공업체 (Provider)에 관한 것이 아닙니다. 측정 (Measurement) 없는 프롬프트 반복 (Iteration)은 그저 비용만 많이 드는 추측일 뿐이라는 점입니다. 지루하더라도 테스트 하네스를 한 번 작성해 두고, 가능한 한 무료 컴퓨팅 자원을 활용해 실행하십시오. 그리고 유료 호출 (Paid calls)은 실제로 결정이 필요한 순간을 위해 아껴두십시오.