프롬프트도 변경 전후 검사가 필요하다
어색한 소제목을 고치려고 프롬프트를 바꿨는데 제목이 길어지거나, 사람다운 문체를 강조했더니 확인하지 않은 경험까지 1인칭으로 쓰는 문제가 생길 수 있다. 자주 쓰는 입력과 반드시 지켜야 할 조건을 테스트 사례로 저장해 두면 새 프롬프트가 기존 장점을 망가뜨리는지 비교할 수 있다.
프롬프트를 수정할 때는 눈앞의 한 문장만 보게 된다. “소제목이 어색하니 더 자연스럽게 써줘”를 추가하면 그 문장은 좋아질 수 있다. 하지만 다음 원고에서는 소제목이 길어지고, 표에 있어야 할 정보가 본문으로 풀리거나, 공식 문서에서 확인한 내용을 직접 경험처럼 바꿀 수도 있다.
이런 변화는 코드 오류처럼 빨간 경고가 뜨지 않는다. 결과를 한두 개만 읽으면 좋아진 것처럼 보이기도 한다. Promptfoo는 같은 테스트 입력을 여러 프롬프트나 모델에 실행하고, 결과가 정한 조건을 통과하는지 비교하는 도구다. 이 글에서는 블로그 원고 프롬프트를 예로 검사 항목을 만드는 방법을 정리했다. 실제 Promptfoo 실행 결과를 담은 사용기는 아니다.
먼저 반복해서 생긴 실패를 테스트 문장으로 바꾼다
좋은 글을 써달라는 기준은 자동으로 검사하기 어렵다. 대신 실제로 싫었던 결과를 모으면 조건을 만들 수 있다. 최근 원고에서 반복된 문제는 아래와 같았다.
| 실제 문제 | 검사할 조건 |
|---|---|
| 도구 이름만 있고 실제 도움이 제목에 없음 | 제목에 업무·결과 중 하나가 들어감 |
| ‘노트지기가 해봤다’처럼 작성자를 3인칭으로 부름 | 본문에 금지 문구가 없음 |
| 실행하지 않은 일을 직접 경험처럼 씀 | 근거 상태와 서술 시점이 일치함 |
| 정직함을 강조하는 긴 변명 문구가 들어감 | 검증 범위는 결과 옆에 짧게 표시함 |
| 같은 결론을 여러 문단에서 반복함 | 문단별 역할이 겹치지 않음 |
| 모바일에서 표 대신 긴 목록이 이어짐 | 비교 정보는 표로 반환함 |
조건이 구체적일수록 결과가 나빠졌을 때 무엇을 고쳐야 하는지 알 수 있다. 처음부터 스무 개를 만들 필요는 없다. 자주 발생하고 사람의 검토 시간이 많이 드는 다섯 개부터 시작하면 된다.
쉬운 조건은 기계적으로, 어려운 조건은 별도로 판정한다
Promptfoo의 assertion은 결과에 특정 문구가 있는지, JSON 구조가 맞는지, 정해진 값과 같은지 등을 검사할 수 있다. 문체처럼 단순 문자열로 판단하기 어려운 항목은 기준 문장이나 별도 평가 모델을 사용할 수도 있다.
| 검사 방식 | 적합한 항목 | 주의할 점 |
|---|---|---|
| 포함·미포함 검사 | 금지 문구, 필수 링크, 작성자 이름 | 표현만 바꾸면 놓칠 수 있음 |
| 형식 검사 | JSON 필드, 표 데이터, 제목 길이 | 내용의 정확성은 따로 확인 |
| 기준표 평가 | 자연스러움, 과장 여부, 독자 도움 | 평가 모델도 틀릴 수 있어 표본 검토 필요 |
| 사람의 최종 검토 | 사실 관계, 실제 경험, 공개 위험 | 자동 점수로 대체하지 않음 |
같은 입력을 기존 프롬프트와 수정 프롬프트에 함께 넣는다
변경 전후를 비교하려면 모델, 입력 자료, 출력 형식을 가능한 한 같게 둔다. 기존 프롬프트 A와 수정한 프롬프트 B에 같은 사례를 넣고, 각 조건의 통과 여부를 나란히 본다.
tests:
- description: 구조도 글의 소제목
vars:
task: "AI가 저장소 구조도를 만들 때 근거 파일을 남기는 이유 설명"
assert:
- type: not-icontains
value: "노트지기가"
- type: not-icontains
value: "중요합니다"
- type: llm-rubric
value: "소제목만 읽어도 독자가 할 행동과 얻는 이점이 보인다"
- description: 공식 문서만 확인한 도구 소개
vars:
evidence: "official_docs_only"
assert:
- type: llm-rubric
value: "직접 설치하거나 실행한 것처럼 서술하지 않는다"
위 예시는 구조를 설명하기 위한 최소 형태다. 실제 구성에서는 사용하는 모델과 프롬프트 파일을 별도로 지정해야 한다. 모델 기반 평가는 비용과 변동성이 있으므로 제목 길이, 금지 문구, 필수 필드처럼 확실한 항목은 단순 검사로 처리하는 편이 좋다.
평균 점수보다 반드시 지켜야 할 항목을 먼저 본다
새 프롬프트의 평균 점수가 높아도 한 건에서 근거를 꾸며냈다면 발행용으로 쓰기 어렵다. 항목마다 중요도가 다르기 때문에 통과 기준도 나눠야 한다.
- 무조건 통과: 허위 경험 금지, 개인정보 금지, 승인 전 외부 공개 금지
- 높은 비율로 통과: 제목 명확성, 소제목 자연스러움, 중복 문단 없음
- 사람이 판단: 재미, 흐름, 실제 독자에게 줄 도움
무조건 통과 항목에서 하나라도 실패하면 평균 점수와 관계없이 수정한다. 문체 항목은 자동 점수만 믿지 않고 실패한 예시를 직접 읽는다. “자연스럽다”는 점수는 높지만 실제로는 과장된 경험담이 들어갈 수 있기 때문이다.
처음에는 스프레드시트로 비교해도 충분하다
프롬프트를 자주 바꾸지 않고 사례가 다섯 개뿐이라면 Promptfoo 설치가 오히려 일이다. 입력, 기존 결과, 새 결과, 통과 여부를 스프레드시트에 놓고 직접 비교하는 것으로 시작해도 된다.
검사 사례가 늘고 여러 모델을 비교하거나 팀에서 같은 기준을 써야 할 때 도구의 이점이 커진다. 이전 결과를 남기고 같은 테스트를 다시 실행할 수 있기 때문이다.
프롬프트 수정은 새 규칙 하나와 회귀 검사 한 번을 묶는다
문제가 생길 때마다 금지 문구를 계속 덧붙이면 프롬프트가 길어지고 규칙끼리 충돌한다. 기존 지시를 정리해 한 번에 한 가지 원칙을 바꾸고, 이전에 잘 되던 사례를 다시 확인하는 편이 원인을 찾기 쉽다.
Promptfoo의 테스트 사례와 assertion 구성은 테스트 사례 문서와 Assertions 문서에서 확인할 수 있다.
검증 범위: 2026-09-21, 실제 요즘노트 원고에서 나온 문체 오류를 테스트 항목으로 바꾸고 Promptfoo 공식 문서를 대조했다. Promptfoo를 설치해 점수를 산출한 결과는 아니다. 작성: 노트지기.

답글 남기기