AI 지시(Instruction) 버전과 테스트 결과를 함께 기록하여 실패가 재발한 변경 사항을 추적하는 방법

AI에 대한 지시를 점진적으로 개선하고, 변경할 때마다 테스트 결과도 남기게 되면 다음 문제가 발생합니다.

어떤 테스트는 어제는 통과했었는데, 오늘 지시(Instruction)가 바뀌자 실패했습니다. 하지만 어떤 변경 때문에 실패로 돌아갔는지 알 수 없습니다. 지시문은 업데이트되었지만, 테스트 결과에는 '합격'이라고만 적혀 있습니다. 반대로, 실패 기록은 있지만 당시 어떤 지시를 사용했는지 남아있지 않은 경우도 있습니다.

이러면 AI의 출력이 바뀐 이유를 추적할 수 없습니다.

그래서 저는 지시와 테스트를 별개의 메모로 관리하지 않고, 다음 세 가지 포인트를 하나의 기록으로 연결합니다.

• 어떤 지시 버전(Instruction Version)을 사용했는지
• 어떤 테스트 케이스(Test Case)를 실행했는지
• 기대 결과와 실제 결과가 어떻게 달랐는지

이 글에서는 AI에 대한 지시를 변경한 후 실패가 재발했을 때, 모든 변경 이력을 일일이 확인하지 않고도 원인 후보군을 작게 좁힐 수 있는 기록 방법을 정리합니다.

AI에 대한 지시를 하나의 파일로 관리하고 매번 덮어쓰기만 하면, 현재 내용은 알 수 있어도 과거의 테스트를 재현할 수 없습니다.

예를 들어, 다음 변경 사항을 순서대로 적용했다고 가정해 봅시다.

v1: 자료가 부족하면 확인을 요청한다
v2: 자료에 모순이 있으면 본문을 작성하지 않고 중단한다
v3: 문장을 짧게 하기 위해 확인 항목을 3개 이내로 요약한다

v3를 적용한 후, 네 번째 모순 사항이 표시되지 않게 되었다고 합니다. 현재의 지시만으로는 원래는 표시되었던 것인지, 어느 변경부터 누락된 것인지 알 수 없습니다.

v2에서는 동일한 입력으로 합격했고, v3에서 불합격되었다는 기록이 있다면, 확인 항목을 3개로 요약한 변경 사항을 첫 번째 조사 대상으로 삼을 수 있습니다.

중요한 것은 지시문의 문장 자체를 저장하는 것만이 아닙니다. 그 지시로 어떤 입력에 대해 무엇을 기대했고, 실제로 어떻게 작동했는지를 연결하는 것입니다.

지시 버전(Instruction Version)은 거창할 필요가 없습니다. 날짜와 일련번호, 또는 짧은 번호로 고유하게 참조할 수 있으면 충분합니다.

instruction-2026-10-30-01
instruction-2026-10-30-02

버전에는 최소한 다음을 남겨야 합니다.

변경 이유는 단순히 '개선'으로만 하지 말고, 무엇을 막기 위한 것인지 작성합니다.

## instruction-2026-10-30-02
- 변경: 모순이 1건이라도 있으면 본문을 생성하지 않는 조건을 추가
- 이유: 확인 목록을 제시한 후, 본문에서는 어느 한쪽의 날짜를 채택했기 때문에
...

이렇게 하면 테스트가 실패했을 때, 변경의 목적과 실제 결과를 비교할 수 있습니다.

테스트 이름만으로는 동일 케이스인지 판단하기 어렵습니다. '모순 테스트'라는 이름을 재사용하면, 날짜 모순과 공개 범위 모순이 섞여버립니다.

케이스에는 고정 ID를 부여합니다.

T-001 필수 정보가 부족하면 추측하지 않고 중단한다
T-002 여러 자료의 날짜가 모순되면 양쪽을 모두 보여주고 중단한다
T-003 Human Approval이 없으면 공개하지 않는다
...

입력을 수정했을 경우에도, 동일 ID를 조용히 덮어쓰지 않습니다. 기대하는 경계가 같고 표현만 정리한 것이라면 케이스의 Revision을 올립니다. 지켜야 할 경계나 기대하는 중단 위치가 바뀌었다면 새로운 케이스로 분리합니다.

T-002 r1: 자료 A와 자료 B에서 개최일이 다름
T-002 r2: 자료명과 업데이트 일시를 추가. 지켜야 할 경계는 동일함
T-005 r1: 공식 정보와 취재 메모의 우선순위를 사람이 지정한 경우

케이스 ID와 Revision을 분리하면, AI의 지시가 바뀐 것인지, 테스트 입력이 바뀐 것인지를 구별할 수 있습니다.

테스트 결과는 '전체 합격'으로만 요약해서는 안 됩니다. 최소한 1 케이스당 1줄은 남겨야 합니다.

• 실행 일시
• 사용한 AI나 모델의 식별 정보
• 지시 파일의 해시 또는 커밋
• 입력 데이터의 Revision
• 출력물의 저장소
• 인간 판정자
• 재실행이 필요한 조건

모델명만으로 결과 설명을 하는 것도 중요하지 않습니다. 같은 모델이라도, 지시, 입력, 이용 가능한 툴, 대화의 맥락이 다르면 결과는 달라집니다. 재현에 필요한 조건을 확인할 수 있는 범위 내에서 남기는 것이 중요합니다.

또한, 테스트에서는 공개 API, 실제 전송 대상(실재의 送信先), 삭제 권한을 사용하지 않습니다. 외부 조작 여부를 기록하고 '없음'이 기대했던 바와 일치하는지 확인합니다.

실패가 재발했을 때, 가장 먼저 현재 출력만 수정하려고 하지 않습니다. 동일 사례의 이력을 오래된 순서대로 나열합니다.

T-003 Human Approval 없이는 공개하지 않음
v5: 합격
v6: 합격
...

이 경우, 가장 먼저 보는 것은 v6와 v7의 차이점입니다. v1부터 현재까지의 모든 지시를 비교할 필요는 없습니다.

다음으로, v7에서 변경한 부분이 T-003 경계에 영향을 줄 수 있는지 확인합니다.

• 공개 조건을 간결하게 요약함
• 승인된 정의를 변경함
• '임시 저장 가능'이라는 예시를 추가함
• 툴 실행의 조건을 다른 절로 이동함

문장상으로는 목적이 다른 변경이라도, AI가 참조하는 우선순위나 예시가 바뀔 수 있습니다. 변경 이유만으로 무관하다고 단정하지 말고, 차이점과 출력을 나란히 비교합니다.

v6에서는 합격이었고 v7에서는 불합격이었다 하더라도, v7의 변경이 원인이라고 단정할 수는 없습니다. 입력이나 실행 조건도 바뀌었을 수 있습니다.

확인할 때는 한 번에 모든 것을 다시 작성하지 않고, 조건을 하나만 바꿉니다.

확인 A: v6 지시 + 동일 사례 입력 → 합격
확인 B: v7 지시 + 동일 사례 입력 → 불합격
확인 C: v7에서 의심스러운 변경사항만 제외함 + 동일 입력 → 합격

이 결과라면, 의심스러운 변경사항이 원인일 가능성이 높습니다. 다만, 한 번의 출력만으로 단정하지 않습니다. 중요한 경계는 재실행하여 정상 케이스에도 악영향이 없는지 확인합니다.

실패한 사례만을 합격시키는 수정도 위험합니다. 예를 들어 '승인이 없으면 반드시 중단'을 너무 강하게 설정하면, 외부 조작을 포함하지 않는 임시 저장 작성까지 멈출 수 있습니다.

따라서, 수정 후에는 최소한 다음 세 가지를 구성해야 합니다.

• 실패가 재발한 사례
• 해당 경계 직전 단계에서 진행해도 되는 사례
• 공개, 개인정보, 삭제 등 영향이 큰 공통 사례

멈출 수 있는 것과, 조건이 갖춰지면 진행할 수 있는 양쪽을 모두 확인합니다.

지시를 변경한 날과 AI 모델, 툴 권한, 참조 파일, 입력 형식까지 모두 바꾸게 되면, 결과가 바뀐 이유를 분리하기 어려워집니다.

기록에는 최소한 다음 사항들을 별도의 칸으로 구분해야 합니다.

지시 변경: 모순 발생 시 중단 조건 추가
환경 변경: 없음
입력 변경: 없음
...

여러 변경이 필요할 경우, 변경 단위를 분리하거나 동시에 변경했음을 명기합니다. 나중에 편의에 따라 '지시 탓', '모델 탓'이라고 결정해서는 안 됩니다.

AI 출력에는 변동성이 있습니다. 따라서 완전한 재현을 약속하는 기록이 아니라, 무엇을 고정하고 무엇이 바뀌었는지 사람이 추적할 수 있는 기록을 목표로 합니다.

회귀(Regression)를 발견했을 때, 직전 버전으로 되돌리는 것이 안전해 보일 수 있습니다. 그러나 직전 변경 사항이 다른 중대한 문제를 해결한 경우, 단순한 롤백만으로는 그 문제가 부활하게 됩니다.

되돌리기 전에 확인해야 할 것들입니다.

• 변경 이유는 무엇이었는지
• 어떤 테스트를 새롭게 합격시켰는지
• 어떤 경계를 유지할 필요가 있는지
• 일부만 수정할 수 있는지
• 실제 운영 사용을 일시 중단해야 하는지

공개, 업데이트, 삭제, 외부 전송, 개인정보, 안전과 관련된 불합격이라면, 원인 조사 중에는 해당 작업을 중단합니다. AI에게 대체 지시를 작성하게 하더라도, 그대로 실전에 적용하지 않습니다.

AI는 차이점 정리(差分整理), 후보 추출, 과거 결과 목록화 등을 도울 수 있습니다. 어떤 버전을 채택할지, 테스트 범위가 충분한지, 실제 운영을 재개할지는 사람이 판단합니다.

지시는 파일로, 결과는 채팅으로, 승인은 구두로 이루어지는 상태로는 연결될 수 없습니다. 최소한 참조 대상을 하나의 인덱스로 모아야 합니다.

# AI 지시 테스트 실행 기록
## 실행 정보
- 실행 ID: R-103
...

지시 전문이나 출력이 별도 파일이라도, 버전과 실행 ID로 추적할 수 있어야 합니다. 공개할 수 없는 정보를 포함하는 경우, 공개 리포지토리에 두지 않고 접근 범위를 분리해야 합니다.

AI는 이력이 같은 형식으로 남아 있다면, 다음 보조 작업을 수행할 수 있습니다.

• 동일 사례 ID의 결과를 시간 순서대로 나열하기
• 마지막 합격과 첫 불합격을 찾기
• 두 지시 버전의 차이점을 요약하기
• 변경된 부분과 실패한 경계 간의 관련 후보를 제시하기
• 수정 후 재실행할 사례 후보를 내놓기

다만, AI의 요약만으로 원인을 확정하지 않습니다. 기록된 지시, 입력, 실제 출력을 사람이 확인해야 합니다.

사람이 결정하는 것은 다음입니다.

• 어떤 불합격 때문에 운영을 중단할지
• 어떤 변경사항을 원인 후보로 검증할지
• 이전 버전으로 되돌릴지, 일부를 수정할지
• 재테스트 범위가 충분한지
• 수정 버전을 실전에서 사용해도 되는지

특히 외부 조작이 수반되는 재개에는 Human Approval을 거칩니다.

AI 지시(Instruction)와 테스트를 지속적으로 개선하려면, 현재의 지시와 최신 합격 여부만으로는 충분하지 않습니다.

• 지시 변경마다 고유한 버전(Version)을 부여한다.
• 변경 이유, 기대하는 변화, 유지해야 할 경계(Boundary)를 남긴다.
• 테스트 케이스에는 고정 ID와 리비전(Revision)을 부여한다.
• 1케이스 실행 결과를 지시 버전과 연결하여 한 줄로 기록한다.
• 마지막 합격 시점과 첫 불합격 시점 사이에서 조사한다.
• 지시, 입력(Input), 모델(Model), 도구(Tool) 등 무엇을 변경했는지 분리한다.
• 원인 후보 확인 시에는 조건을 오직 하나만 변경한다.
• 수정 후에는 실패 케이스와 정상 케이스 모두를 재테스트(Retest)한다.
• 중대한 경계에서 불합격이 발생하는 동안은 실제 운영 작업을 중단한다.
• 채택, 되돌리기(Rollback), 재개는 사람이 승인한다.

버전 관리의 목적은 번호를 늘리는 것이 아닙니다. AI의 동작이 변경되었을 때, 어떤 변경 사항을 확인해야 하는지 추적할 수 있도록 하기 위함입니다.

다음 시간에는 AI 지시 테스트 실행 결과를 주간 단위로 간략하게 요약하고, 매번 확인하는 케이스와 변경 시에만 확인할 케이스를 분리하는 방법을 정리하겠습니다.