프롬프트 테스트와 개선 절차: 한 번에 하나만 바꾸기

🤔 고쳤더니 좋아진 것 같은데 확신이 없을 때

분류 프롬프트가 자꾸 틀려서 역할 문장을 바꾸고 예시를 둘 더 넣고 형식도 손질했습니다. 다시 돌리니 좋아진 것 같습니다. 그런데 며칠 뒤 다른 자료에서 또 틀리고, 이번에는 무엇을 고쳐야 할지 모릅니다. 지난번에 무엇이 효과를 냈는지 남아 있지 않기 때문입니다.

프롬프트를 고치는 일은 느낌이 아니라 측정으로 해야 다음에 쓸 수 있는 지식이 남습니다. 앤트로픽 공식 문서는 프롬프트 엔지니어링 가이드의 첫머리에 성공 기준과 그것을 재는 방법과 첫 초안, 이 세 가지가 먼저 있어야 한다고 전제합니다.

🔑 프롬프트 테스트와 개선의 정의

프롬프트 테스트와 개선은 성공 기준을 먼저 정하고 같은 입력 묶음으로 결과를 잰 뒤 프롬프트를 한 번에 한 곳만 바꿔 전후를 비교하는 절차입니다. 세 요소가 다 있어야 합니다. 기준이 없으면 좋아졌는지 판단할 수 없고, 입력 묶음이 매번 다르면 비교가 안 되며, 여러 곳을 한 번에 바꾸면 무엇이 효과를 냈는지 나눌 수 없습니다.

광고 소재를 하나씩 바꿔 가며 반응을 재는 AB 테스트와 같은 원리입니다. 변수 하나를 바꾸고 나머지는 고정해야 차이의 원인이 그 변수라고 말할 수 있습니다.

🎯 성공 기준을 먼저 정하기

앤트로픽 공식 문서가 성공 기준에 요구하는 조건은 네 가지입니다. 구체적이고, 측정 가능하고, 달성 가능하고, 업무와 관련이 있어야 합니다. "좋은 성능"은 기준이 아니고 "문의 분류 정확도 90% 이상"이 기준입니다.

같은 문서가 드는 기준의 종류를 실무에 맞게 옮기면 다음과 같습니다.

기준을 하나만 두지 않는 편이 안전합니다. 정확도만 재면 정확하지만 세 배 긴 답이 통과하고, 형식만 재면 모양은 맞는데 내용이 틀린 답이 통과합니다. 문서의 예시도 정확도와 안전성, 오류 심각도, 응답 시간을 함께 놓습니다.

🧪 입력 묶음과 채점 방식

기준을 정했으면 같은 입력 묶음으로 잽니다. 앤트로픽 문서가 평가 설계에서 강조하는 것은 세 가지입니다.

• 실제 작업을 닮게 만듭니다. 실제로 들어오는 자료의 종류와 비율을 반영하고, 관련 없는 입력과 지나치게 긴 입력과 애매한 사례 같은 경계 사례를 반드시 넣습니다
• 자동으로 채점할 수 있게 만듭니다. 객관식이나 문자열 일치, 코드 채점, 모델 채점이 가능한 형태로 짭니다
• 양을 우선합니다. 사람이 공들여 채점한 소수보다 신호가 조금 약해도 많은 문항이 낫다고 문서는 설명합니다

채점은 기준에 따라 방법이 다릅니다.

모델에 채점을 맡길 때 조건이 하나 있습니다. 결과물을 만든 세션에 맡기지 않습니다. 모델이 자기가 만든 문장에 더 높은 점수를 주는 편향이 연구로 확인되어 있어서, 채점은 다른 세션이나 다른 모델에 기준 문서와 함께 맡깁니다. 근거는 AI 자기 검수의 한계에 있습니다.

처음에는 입력 열 건과 사람이 매긴 정답 열 개로 시작해도 됩니다. 스프레드시트 한 장에 입력과 기대 결과와 실제 결과와 통과 여부 네 열이면 충분하고, 문항은 틀린 사례가 나올 때마다 추가합니다.

🔁 한 번에 하나만 바꾸는 비교표

측정할 준비가 되면 고치기 시작합니다. 원칙은 하나입니다. 프롬프트에서 한 곳만 바꾸고 같은 입력 묶음으로 다시 잽니다. 결과가 좋아졌으면 남기고 나빠졌으면 되돌린 뒤 다음 곳을 바꿉니다.

바꾼 내역은 표로 남깁니다. 값은 설명용 가상 수치입니다.

v4가 이 표의 쓸모를 보여 줍니다. 역할을 늘리는 것이 도움이 될 것 같았지만 수치가 내려갔고, 한 곳만 바꿨기 때문에 원인이 역할 문장이라는 것을 알 수 있습니다. 세 곳을 한 번에 바꿨다면 v3의 12%포인트 상승과 v4의 하락이 섞여 무엇이 효과였는지 남지 않았을 것입니다.

무엇부터 바꿀지는 순서가 있습니다. 결과가 흐릿하면 자료 위치와 지시의 명확성부터, 범위가 넓으면 제약부터, 형식이 일정하지 않으면 예시와 출력 형식부터 봅니다. 구글 제미나이 문서가 권하는 반복 개선 방법도 같은 방향입니다. 같은 뜻을 다른 표현으로 바꿔 보고, 지시를 따르지 않으면 같은 결과를 내는 다른 작업으로 바꿔 보고, 예시와 자료와 입력의 순서를 바꿔 봅니다. 프롬프트의 각 요소가 무엇인지는 프롬프트 구조 설계에 있습니다.

🔄 초안, 검토, 다듬기로 나누는 사슬

프롬프트 하나를 고치는 것과 별개로 작업 자체를 나누는 방법이 있습니다. 앤트로픽 문서는 가장 흔한 연결 방식으로 자기 교정을 듭니다. 초안을 만들고, 그 초안을 기준과 대조해 검토하게 하고, 검토 결과로 다듬는 세 호출로 나누면 중간 결과를 기록하고 평가하고 어느 단계에서든 갈아탈 수 있다는 설명입니다.

이 방식은 테스트에도 쓸모가 있습니다. 세 단계로 나누면 어느 단계에서 틀렸는지가 보입니다. 초안 단계에서 사실이 틀렸는지, 검토 단계에서 놓쳤는지, 다듬기에서 새로 망가졌는지를 따로 재면 고칠 곳이 정해집니다. 검토 단계를 다른 세션에 맡기면 앞에서 말한 자기 채점 편향도 줄어듭니다.

📆 다시 재야 하는 때

한 번 통과한 프롬프트도 다시 재야 하는 시점이 있습니다.

• 모델이 바뀔 때: 앤트로픽 문서는 특정 모델에서 잰 기법을 다른 모델에 적용하기 전에 자기 평가로 다시 확인하라고 적고, 이전 세대에서 필요했던 강한 지시가 새 모델에서는 과하게 작동하기도 한다고 설명합니다
• 입력 자료의 성격이 바뀔 때: 문의 유형이 늘거나 자료 형식이 바뀌면 입력 묶음부터 갱신합니다
• 추론 모드나 effort 설정을 바꿀 때: 같은 프롬프트라도 설정에 따라 결과가 달라지므로 켜고 끄고 두 번 잽니다. 기준은 생각의 사슬과 추론 모드에 있습니다
• 틀린 사례가 새로 나올 때: 그 사례를 입력 묶음에 넣고 프롬프트를 고친 뒤 기존 문항이 여전히 통과하는지 함께 봅니다

마지막 항목이 실무에서 가장 자주 빠집니다. 새 사례만 고치고 기존 사례를 다시 재지 않으면 한쪽을 고치다 다른 쪽이 망가진 것을 놓칩니다.

⚠️ 자주 하는 실수

• 기준 없이 고칩니다: 좋아졌는지 판단할 근거가 없어 느낌으로 결정하게 됩니다
• 매번 다른 입력으로 시험합니다: 프롬프트가 아니라 입력이 달라서 결과가 달라진 것일 수 있습니다
• 여러 곳을 한 번에 바꿉니다: 무엇이 효과였는지 남지 않습니다
• 정확도 하나만 잽니다: 길이와 형식과 비용이 함께 나빠져도 보이지 않습니다
• 초안을 만든 세션에 채점을 맡깁니다: 자기 문장에 후한 편향이 점수에 들어갑니다
• 새 사례만 고치고 기존 문항을 다시 재지 않습니다: 한쪽을 고치다 다른 쪽이 망가집니다

❓ 자주 묻는 질문

입력 묶음은 몇 건이 필요한가요?

앤트로픽 문서는 정해진 수 대신 양을 우선하라고만 적고 있습니다. 시작은 열 건이면 됩니다. 중요한 것은 관련 없는 입력과 긴 입력과 애매한 사례가 섞여 있는지이고, 문항은 틀린 사례가 나올 때마다 늘립니다. 채점을 자동화해 두면 문항이 늘어도 재는 비용이 늘지 않습니다.

채팅 화면에서도 테스트할 수 있나요?

됩니다. 같은 프롬프트에 같은 입력 열 개를 차례로 넣고 결과를 시트에 적으면 됩니다. 다만 대화가 이어지면 앞 결과가 뒤 결과에 영향을 주므로 문항마다 새 대화를 여는 편이 정확합니다. 프롬프트를 템플릿으로 만들어 두면 입력만 바꿔 넣기 쉽습니다.

결과가 매번 조금씩 달라서 비교가 안 됩니다

같은 입력에 같은 프롬프트를 넣어도 답이 조금씩 다른 것은 정상입니다. 그래서 한 건으로 판단하지 않고 묶음의 통과 비율로 판단합니다. 같은 문항을 세 번 돌려 분류가 같은 비율을 일관성 기준으로 따로 재는 방법도 있습니다.

모델에게 채점을 맡겨도 되나요?

어조나 관련성처럼 정답이 하나가 아닌 기준은 모델 채점이 실용적이고 앤트로픽 문서도 그 방식을 예시로 듭니다. 조건은 두 가지입니다. 채점 기준을 문장으로 적어 함께 주고, 결과물을 만든 세션이 아닌 곳에 맡깁니다. 숫자만 출력하게 해 두면 시트에 바로 붙일 수 있습니다.

📋 3줄 요약

1. 프롬프트 테스트와 개선은 성공 기준을 먼저 정하고 같은 입력 묶음으로 결과를 잰 뒤 프롬프트를 한 번에 한 곳만 바꿔 전후를 비교하는 절차이고, 앤트로픽 공식 문서는 프롬프트를 고치기 전에 성공 기준과 그것을 재는 방법부터 갖추라고 안내합니다.

2. 성공 기준은 구체적이고 측정 가능하며 달성 가능하고 업무와 관련 있어야 하며, 채점은 정답이 있으면 일치 비교로 하고 어조처럼 주관적인 항목은 다른 모델에 1~5점 척도로 매기게 하되 입력 묶음에는 관련 없는 입력과 긴 입력과 애매한 사례를 섞습니다.

3. 비교표에는 바꾼 곳 하나와 전후 점수와 판단을 한 줄로 남기고, 결과가 나쁠 때는 자료 위치와 제약과 예시와 형식 순서로 하나씩 바꾸며 같은 프롬프트라도 모델이 바뀌면 처음부터 다시 잽니다.

📚 참고 자료

• Define success criteria and build evaluations, Claude Platform Docs
• Prompt engineering overview: Before prompt engineering, Claude Platform Docs
• Prompting best practices: Chain complex prompts, Claude Platform Docs
• Prompt design strategies: Prompt iteration strategies, Gemini API Docs
• AI 자기 검수의 한계, 준이아빠블로그

2026년 9월 28일 기준으로 공식 문서를 확인했습니다.