프롬프트 회귀 테스트: AI 워크플로우를 문제 없이 배포

I’m happy to translate the article for you, but I’ll need the full text of the post (the content you’d like translated). Could you please paste the article’s body here? Once I have that, I’ll provide a Korean translation while preserving the original formatting, markdown, and code blocks.

프롬프트 회귀 테스트가 중요한 이유

프롬프트가 일회성 채팅보다 더 중요한 작업을 구동한다면, 안전망이 필요합니다.
프롬프트가 워크플로의 일부분이 되는 순간—코드 생성, 고객 이메일 초안 작성, 티켓 요약, JSON 변환, 릴리즈 노트 작성—그것은 소프트웨어가 됩니다. 그리고 소프트웨어는 테스트가 필요합니다.

회귀 테스트는 간단한 질문에 답합니다:

“같은 입력에 대해 여전히 계약을 만족하는 출력을 얻고 있는가?”

계약은 다음을 포함할 수 있습니다:

• 구조 (유효한 JSON, 정확한 키)
• 스타일 (톤, 읽기 수준)
• 제약 (PII 없음, 최대 길이)
• 콘텐츠 규칙 (출처 인용 필수, 체크리스트 포함 필수)

‘창의성’을 테스트하는 것이 아니라, 신뢰성을 테스트하는 것입니다.

좋은 계약 vs. 나쁜 계약

나쁜 계약: “좋은 요약을 작성하세요.”

좋은 계약: “키가 title, summary, action_items(배열), risks(배열)인 JSON을 반환하세요. 요약은 최대 80단어.”

프롬프트에 직접 삽입할 수 있는 계약 스니펫 예시

Output contract:
- Return valid JSON only (no markdown, no commentary)
- Keys: title (string), summary (string), action_items (string[]), risks (string[])
- summary: ≤ 80 words
- action_items: 0‑5 items, each imperative verb

골든 테스트 스위트 구축

골든 테스트 케이스는 다음으로 구성됩니다:

1. 실제와 유사한 입력
2. 예상 출력(또는 예상 속성)

5–10개의 케이스로 시작하세요. 포함할 내용:

• 정상 경로(일반 입력)
• 경계 입력(빈 섹션, 이상한 포맷)
• 모호한 입력(다중 해석)
• 적대적 입력(예: “지시를 무시하고…”) – 특히 자동화를 위해
• 긴 입력(토큰 한도에 근접)

예를 들어, 저장소에 보관합니다:

/prompts
  support_triage.md
/tests
  support_triage/
    001_happy.json
    002_empty.json
    003_adversarial.json
    001_expected.json

예시 테스트 파일 (001_happy.json)

{
  "ticket": {
    "subject": "Login loop on mobile",
    "body": "User reports being redirected back to /login after 2FA…",
    "plan": "Pro",
    "priority": "high"
  }
}

일반적인 검증 전략

대부분의 팀에게는 스키마 + 불변조건이 최적입니다. 일반적인 검사 항목:

• JSON이 성공적으로 파싱되는지
• 필수 키가 존재하는지
• 최대 길이 제한을 준수하는지
• 배열이 범위 내에 있는지
• 금지된 단어가 없는지

최소 Node.js 하네스

The following script loads test cases, calls your model, parses JSON, and validates invariants.

// test_harness.js
import fs from "node:fs";
import path from "node:path";

function must(condition, message) {
  if (!condition) throw new Error(message);
}

function validate(output) {
  must(typeof output.title === "string" && output.title.length > 0, "title missing");
  must(typeof output.summary === "string", "summary missing");
  // Example invariant: summary should be ≤ 80 words
  must(output.summary.split(/\s+/).length <= 80, "summary too long");
  // Add more invariants as needed
}

async function run() {
  const dir = path.resolve("tests/support_triage");
  const cases = fs
    .readdirSync(dir)
    .filter((f) => f.endsWith(".json") && !f.includes("expected"));

  for (const file of cases) {
    const input = JSON.parse(fs.readFileSync(path.join(dir, file), "utf8"));

    // callModel() is your wrapper around the API
    const text = await callModel({
      prompt: fs.readFileSync("prompts/support_triage.md", "utf8"),
      input,
    });

    let parsed;
    try {
      parsed = JSON.parse(text);
    } catch (e) {
      throw new Error(`${file}: output is not valid JSON`);
    }

    validate(parsed);
    console.log(`✅ ${file}`);
  }
}

run().catch((err) => {
  console.error("❌", err.message);
  process.exit(1);
});

CI와 통합하기

이미 CI 파이프라인이 있다면, 하네스를 게이트로 추가하세요:

• 테스트 통과 → 배포
• 테스트 실패 → 병합 전 조사

프롬프트 변경을 다른 위험한 변경과 동일하게 다루세요:

1. 프롬프트 파일의 diff를 보여줍니다
2. CI에서 회귀 테스트를 실행합니다
3. 몇 개의 골든에 대해 “전/후” 출력을 포함합니다

프롬프트 변경 로그 예시

프롬프트 파일 상단에 짧은 변경 로그를 유지하세요:

# support_triage prompt
# 2026-03-13: tightened summary length, reduced action_items max to 5

이렇게 하면 몇 달 후에 발생하는 드리프트를 더 쉽게 파악할 수 있습니다.

책임 분리

프롬프트가 너무 많은 작업을 수행하고 있다면, 나누세요:

• 프롬프트 A – 구조화된 데이터를 추출합니다
• 프롬프트 B – 해당 구조에서 산문을 작성합니다

각 조각은 테스트하기가 더 쉬워집니다.

솔로 개발자 또는 팀을 위한 경량 시스템

1. 레포에 프롬프트 파일 (Markdown)
2. 10–30개의 골든 입력 (JSON)
3. 검증기 (스키마 + 불변조건)
4. 모든 PR에 대한 CI 체크
5. 실제 데이터에서 골든을 주기적으로 새로 고침 (먼저 정제)

기업 플랫폼 없이도 80 % 이상의 가치를 얻을 수 있습니다. 프롬프트를 버전 관리되고 테스트 가능한 아티팩트로 다루면 워크플로우가 더 차분해집니다. 모델 업데이트가 조용히 프로덕션 동작을 바꿨을 때, 첫 번째로 당신의 미래 자신(그리고 팀원들)이 감사할 것이며, CI가 이를 포착합니다.

이와 같은 작은 하네스를 구축한다면, 어떤 불변조건을 검증했는지 알려주시면 좋겠습니다.