AI 프롬프트 테스트를 주간 단위로 검토할 때, 매번 확인하는 케이스와 변경 시에만 확인하는 케이스 구분 방법

AI의 지시(프롬프트)를 변경할 때마다 테스트 케이스를 늘리다 보면, 결국 '모든 것을 매번 확인하기는 너무 힘들다'라는 상태가 됩니다.

승인 없이는 멈추는지. 자료에 모순이 생기면 추측하지 않는지. 정상적인 입력이라면 초안을 만들 수 있는지. 오래된 형식의 입력도 처리할 수 있는지. 이 모든 케이스들은 한 번은 필요하다고 판단하여 추가한 것들입니다. 하지만 지시를 단 한 줄 고칠 때마다 전체를 확인하고 있으면, 실행하는 시간보다 결과물을 확인하는 데 시간이 더 걸리게 됩니다.

반대로, 시간이 많이 걸린다고 해서 변경된 부분과 가까운 케이스만 실행하면, 다른 중요한 경계 조건이 깨져 있어도 알아차릴 수 없습니다.

그래서 저는 테스트를 '중요/불필요'의 이분법적 선택으로 두지 않고, 실행하는 타이밍에 따라 다음 세 가지로 나눕니다.

• 매번 확인하는 케이스 (Always)
• 관련 변경이 있을 때 확인하는 케이스 (Related Change)
• 주간 등 정해진 주기마다 확인하는 케이스 (Periodic)

본 글에서는 AI 지시 테스트를 주간 단위로 짧게 검토하면서도, 중요한 중단 조건은 매번 준수하고, 변경 내용과 관계가 적은 케이스까지 무조건 전체를 실행하지 않도록 구분하는 방법을 정리합니다.

테스트 목록에 케이스 이름과 기대 결과만 작성되어 있어도 다음 실행 대상을 고를 수 없습니다.

| ID | 지켜야 할 경계 | 실행 타이밍 | 최종 결과 |
| --- | --- | --- | ---
| T-001 | 승인 전에 공개하지 않기 | 매번 | 합격 |
...

여기서 말하는 '매번'은 대화가 있을 때마다를 의미하지 않습니다. 지시(Instruction)의 버전을 변경하여, 그 버전으로 작업을 시작하기 전의 확인을 의미합니다.

'관련 변경 시'는 해당 케이스가 보는 지시, 입력 형식, 이용 도구, 출력 형식 중 어느 하나가 바뀐 경우입니다. '주간'은 변경이 없더라도 정해진 날에 모아서 확인하는 케이스를 말합니다.

실행 타이밍을 명시하면, 테스트를 생략한 것인지, 조건에 맞지 않아 이번에는 대상에서 제외된 것인지를 구분할 수 있습니다.

매번 확인하는 케이스는 개수를 너무 늘리지 않는 것이 중요합니다. 저는 '실패한 상태로 새로운 지시를 사용하기 시작해도 괜찮은가?'를 기준으로 판단합니다.

다음과 같은 경계는 매번 확인해야 할 후보입니다.

• Human Approval(인간 승인)이 없으면 공개, 업데이트, 전송을 실행하지 않는다.
• 개인 정보나 인증 정보를 공개용 본문에 노출하지 않는다.
• 자료가 부족하거나 모순될 때, 추측으로 사실을 완성하지 않는다.
• 삭제나 덮어쓰기 등 되돌리기 어려운 작업을 임의로 수행하지 않는다.
• 조건이 갖춰진 정상 케이스에서는 기대하는 작업을 진행할 수 있다.

중단(Stop)하는 케이스만 매번 실행하면, '멈출 수는 있지만 아무것도 진행할 수 없는 지시'여도 합격해 버릴 수 있습니다. 따라서 중요한 중단 조건과 함께, 정상 케이스를 최소 1개 포함해야 합니다.

M-001 정상적인 자료만 있다면 확인용 초안을 만든다.
M-002 승인이 없으면 공개하지 않는다.
M-003 자료가 모순되면 본문을 확정하지 않는다.
...

매번 케이스는 '대표적인 최소 세트'입니다. 날짜, 요금, 회장명 등 같은 경계를 지키는 입력 차이점까지 모두 넣을 필요는 없습니다. 입력의 종류가 아니라, 진행해도 되는 조건과 멈춰야 하는 조건을 대표할 수 있는지를 확인합니다.

또한, 매번 케이스가 10개, 20개로 늘어난다면 분류를 재검토해야 한다는 신호입니다. 정말 매번 필요한지, 같은 경계를 중복해서 보고 있지는 않은지, 관련 변경 시나 주간으로 옮길 수 있는지 확인합니다.

관련 변경 시 케이스는 단순히 '가끔 실행하는 케이스'가 아닙니다. 어떤 변경에 의해 실행 대상이 될지를 정해둡니다.

예를 들어, 다음과 같이 대응시킬 수 있습니다.

케이스 측에는 실행 트리거를 간결하게 작성합니다.

### T-021 오래된 자료를 현재의 사실로 취급하지 않기
- 실행 타이밍: 사실 확인 규칙, 확인일, 출처 처리를 변경했을 때
- 기대: 오래된 자료를 현재의 사실로 단정하지 않고, 재확인으로 분리한다.
...

이렇게 하면, 변경한 사람이 '어떤 케이스를 추가 실행할지'를 기억만으로 고르지 않아도 됩니다.

다만, 대응표에 쓰여 있지 않은 변경이라 안전하다고 할 수는 없습니다. 새로운 종류의 변경을 했다면, 영향을 받는 경계를 확인하고 필요하다면 대응표 자체를 업데이트해야 합니다.

주간 확인은 매번 세트에서 제외한 케이스들의 보관 장소가 아닙니다. 변경 단위로는 포착하기 어려운 열화나, 한동안 사용해 보고 나서야 보이는 문제를 모아서 확인할 때 사용합니다.

후보에는 다음과 같은 케이스가 있습니다.

• 사용 빈도는 낮지만 유지할 필요가 있는 입력 형식
• 여러 변경 사항이 겹쳤을 때만 영향이 나타나기 쉬운 케이스
• 출력 길이, 가독성, 표기 통일 등 품질을 확인하는 케이스
• 최근 실행되지 않은 중요 케이스
• 실제 실패를 통해 추가했지만, 매번 세트에 포함하기에는 너무 무거운 재현 케이스
• 이용 도구나 참고 자료가 현재도 유효한지 확인하는 케이스

매주 모든 항목을 실행할 필요는 없습니다. 최종 실행일, 변경 이력, 사용 빈도, 실패 시 영향을 검토하여 해당 주차의 대상 케이스를 선정합니다.

예를 들어, 다음과 같은 우선순위를 설정할 수 있습니다.

1. 지난번 불합격 또는 보류되었던 케이스
2. 이번 주에 변경한 영역과 가까운 케이스
3. 30일 이상 실행하지 않은 중요 케이스
...

이 순서대로 진행하면, 단순히 항목 수를 채우는 것보다 현재의 불확실성을 줄이는 것을 우선할 수 있습니다.

주간 확인 결과를 긴 보고서로 만들면, '만드는 것이 목적'이 됩니다. 저는 판단에 필요한 차이점(Differential)만을 남깁니다.

# AI 지시 테스트 주간 요약 (AI Prompt Test Weekly Summary)
대상 기간: 2026-10-25~2026-10-31
현행 지시 Version: instruction-2026-10-31-01
...

개별 입력과 출력은 실행 ID를 통해 추적할 수 있도록 하고, 주간 요약본에 전체 내용을 붙여넣지 않습니다. 요약본의 역할은 '무엇을 실행했고', '무엇이 바뀌었으며', '계속 이용해도 되는지'를 단시간 내에 판단하는 것입니다.

"12건 중 11건 합격"이라고 적으면, 거의 문제가 없는 것처럼 보입니다. 하지만 불합격된 1건이 "승인 없이 공개하지 않는다"는 내용이라면, 해당 Version을 실제 환경(Production)에서 계속 사용할지 여부를 판단할 수 없습니다.

반대로, 표의 구분선이 일부 깨진 1건만 불합격이라면, 외부 조작을 중단하고 원인을 확인해야 하는 케이스와는 취급이 다릅니다.

따라서 주간 요약본에서는 건수와 함께, 불합격된 경계(Boundary)와 영향 범위를 기재합니다.

합격률은 전체 양을 보는 보조 자료가 될 수는 있지만, 실제 활용 가능 여부를 결정하는 숫자는 아닙니다. 개별 항목의 경계와 실패 시 영향을 먼저 봐야 합니다.

주간 확인에서는 실행한 케이스뿐만 아니라, 중요함에도 불구하고 실행하지 않은 케이스도 파악합니다.

T-030 외부 전송 이중 실행
금주 판정: 미실행
이유: 전송 도구와 관련 지시에 변경 없음. 최종 합격은 2026-10-24
...

"미실행(未実行)"과 "미확인(未確認)"은 다릅니다. 실행 조건에 맞지 않아 지난 결과와 다음 조건을 확인한 후 대상에서 제외했는지, 아니면 단순히 잊어버렸는지를 구분해야 합니다.

다만, 지난번에 합격했다고 해서 영원히 생략할 수는 없습니다. 최종 실행일로부터 기간이 길어진 케이스는 주간 선정 과정으로 되돌아가야 합니다. 중요도에 따라 7일, 30일, 90일 등 재확인 상한선을 정합니다.

주간 또는 변경 시점에서 불합격 사례가 발견되면, 수정이 확인될 때까지 다음 주기에도 같은 분류로 두지 않습니다.

예를 들어, 주간 케이스 T-014가 불합격이라면 다음과 같이 처리합니다.

기존: 주간 확인
불합격 후: 수정 시 반드시 실행
같은 문제가 반복된 경우: 매번 세트에 포함하는 것을 검토
...

단 한 번의 불합격으로 모든 것을 매번 세트에 넣을 필요는 없습니다. 하지만 실제 실패가 계속되는 경계를 낮은 빈도로 유지하는 것도 위험합니다.

반대로, 매번 세트에 포함되어 오랫동안 안정적인 케이스라도, 실패 시 영향이 크다면 남겨둬야 합니다. '최근에 실패하지 않았다'는 것과 '실패해도 문제가 없다'는 것은 별개이기 때문입니다.

AI는 형식화된 실행 기록으로부터 다음을 보조할 수 있습니다.

• 최종 실행일이 오래된 케이스 추출하기
• 이번 변경 사항과 실행 트리거를 대조하기
• 매번, 변경 시, 주간 후보 목록 만들기
• 지난주 대비 판정이 바뀐 케이스 정리하기
• 불합격 사례와 관련된 과거 지시 Version 나열하기
• 주간 요약본 초안 작성하기

다만, AI에게 "중요한 테스트만 골라줘"라고 전적으로 맡겨서는 안 됩니다. 무엇을 중요하다고 할지, 어떤 실패로 인해 실제 운영을 중단할지, 재확인 상한선을 며칠로 할지는 대상 업무에 따라 달라지기 때문입니다.

사람이 결정해야 하는 것은 다음과 같습니다.

• 매번 지켜야 할 경계(Boundary)
• 변경 사항과 케이스의 대응 관계
• 불합격 시 이용 중단 범위
• 조건부로 계속 이용할지 여부
• 수정 후 재테스트 범위
• 지시 Version을 사용하기 시작할지, 이용을 재개할지

특히 공개, 업데이트, 삭제, 외부 전송, 개인 정보와 관련된 판단에는 Human Approval(사람의 승인)이 필요합니다.

AI에 대한 지시 테스트가 늘어난다고 해서, 모든 것을 매번 실행할지 아니면 궁금한 것만 실행할지의 두 가지 선택지로 만들어서는 안 됩니다.

• 지시(Instruction) 버전을 사용하기 전에 반드시 확인하는 ‘항상 케이스’를 작게 고정한다.
• 중요한 중단 조건뿐만 아니라 정상적으로 진행되는 케이스도 매번 세트에 포함시킨다.
• 지시, 입력, 도구(Tool), 모델 등 변경 사항과 케이스 간의 대응표를 유지한다.
• 변경 단위만으로는 파악하기 어려운 케이스를 주간 단위로 선정하여 확인한다.
• 주간 요약은 건수보다 전주 대비 차이점과 활용 판단을 기록한다.
• 합격률만으로 안전성을 판단하지 않고, 불합격 경계와 영향을 살핀다.
• 미실행 케이스에도 이유, 이전 결과, 다음 조건을 작성한다.
• 불합격이 발견된 케이스는 확인 빈도를 한 단계 높인다.
• 실제 서비스(Production) 사용의 지속, 중단, 재개 여부는 사람이 결정한다.

테스트를 분리하는 목적은 확인을 줄이는 것이 아닙니다. 중요한 경계를 매번 지키면서, 변경에 따라 확인 범위를 넓히고, 시간의 흐름에 따른 누락을 주간 단위로 포착하기 위함입니다.

다음 시간에는 AI 지시 테스트가 실패했을 때, 수정 전의 실패 출력을 삭제하지 않고 '기존 결함(Known Bug)'으로 남겨두고, 재테스트와 실제 서비스 재개 판단을 분리하는 방법을 정리하겠습니다.