AI가 사람의 수정을 무시할 때, 승인 규칙을 다시 세우는 체크리스트
2026-09-04 기준으로 확인할 문제는 단순합니다. 사람이 고친 내용을 AI가 다음 처리에서 다시 되돌린다면, 수정 요청을 더 자세히 쓰는 것보다 검토 규칙과 승인 상태를 분리해야 합니다. 다만 최근 제품 기능 변경을 입증할 공식 문서와 실제 재처리 결과는 제공된 사실에 포함되지 않았습니다. 그래서 이번 글은 성과 사례가 아니라, 확인되지 않은 자동 승인을 막기 위한 운영 체크리스트로 남깁니다.
먼저 남겨둘 세 줄
- 사람의 수정은 의견이 아니라 다음 결과가 지켜야 할 승인 조건으로 기록합니다.
- 재처리는 원본, 수정본, 새 결과를 나란히 비교할 수 있을 때만 검증 가능합니다.
- 공식 문서와 실제 화면에서 변경 사항을 확인하지 못했다면, 기능이 개선됐다고 판단하지 않습니다.
수정이 사라지는 문제는 대화의 실패라기보다 승인 상태를 저장하지 못한 운영의 실패에 가까웠습니다.
수정과 승인을 같은 것으로 봤던 순간
가상의 ‘편의점 행사 안내문’을 떠올려봤습니다. 초안에는 행사 대상이 아닌 상품이 포함돼 있습니다. 검토자가 그 상품을 삭제하고 이유도 남겼습니다. 그런데 다시 처리한 결과에서 삭제된 상품이 돌아옵니다.
이때 “사람의 말을 무시했다”고만 적으면 원인을 구분하기 어렵습니다. 수정본이 입력되지 않았을 수도 있고, 수정 이유가 참고 의견으로만 취급됐을 수도 있습니다. 승인 전 초안이 다음 단계로 넘어갔을 가능성도 있습니다.
그래서 저는 기록을 역할별로 나누게 됐어요.
- 원본: AI가 처음 만든 내용
- 사람의 수정: 바뀐 문장과 삭제된 항목
- 승인 조건: 다시 나타나면 안 되는 오류
- 승인 상태: 대기, 반려, 승인 가운데 현재 위치
- 재처리 결과: 승인 조건이 유지됐는지 확인할 대상
상태 이름은 제품마다 다를 수 있습니다. 중요한 것은 화면의 버튼 이름이 아니라, 반려된 초안과 승인된 수정본을 시스템이 실제로 구분하는지였습니다.
최근 변경은 공식 문서와 화면을 함께 봅니다
검토·승인 기능은 바뀔 수 있습니다. 하지만 이번에 제공된 검증 사실에는 특정 제품의 변경 기록, 공식 문서 본문, 변경 전후 화면이 없습니다. 따라서 “최근 기능이 개선됐다”거나 “수정 보존이 지원된다”고 쓸 근거도 없습니다.
제가 남길 수 있는 안전한 확인 절차는 다음과 같습니다.
- 공식 변경 기록에 검토, 승인, 수정 보존과 직접 관련된 항목이 있는가
- 문서의 게시일 또는 갱신일이 확인되는가
- 실제 화면에서 문서와 같은 상태와 동작이 보이는가
- 수정본이 다음 처리의 입력으로 연결되는가
- 반려된 초안이 자동으로 배포되지 않는가
- 승인 기록에서 누가 무엇을 바꿨는지 식별 가능한가
- 문서 설명과 실제 동작이 다르면 차이를 별도로 남겼는가
공식 문서에 표현이 있어도 실제 계정이나 화면에 적용됐다는 뜻은 아닐 수 있습니다. 반대로 화면에 새 버튼이 보여도 수정 보존 범위까지 증명하지는 못합니다.
기능 이름은 증거가 아니었습니다. 문서의 설명과 재처리 결과가 맞아야 비로소 운영 규칙으로 쓸 수 있었습니다.
안전한 오류가 든 샘플로 다시 확인합니다
실제 고객 정보나 공개 전 문서를 넣을 필요는 없습니다. 가상 안내문처럼 틀려도 피해가 없는 샘플이면 충분합니다.
샘플에는 눈으로 판별할 수 있는 오류를 넣습니다. 행사 대상이 아닌 상품이 포함됐다는 설정처럼 정답과 오답의 경계가 분명한 편이 좋았습니다. 문체 취향이나 “조금 더 자연스럽게” 같은 조건은 성공 여부를 흐리기 쉽더라고요.
재처리 전에 아래 항목을 고정합니다.
- 원본 내용을 그대로 보관했는가
- 의도적으로 넣은 오류가 명확한가
- 사람이 고친 부분만 표시했는가
- 수정 이유를 승인 조건으로 바꿨는가
- 승인 전에는 외부 전달이 막혀 있는가
- 같은 조건으로 새 결과를 비교할 수 있는가
- 개인 정보와 내부 식별정보가 제거됐는가
여기서 비용이 들지 않는다고 단정할 수는 없습니다. 제공된 사실에는 비용 정보가 없기 때문입니다. 실제 재처리 전에는 제품 화면에서 과금 여부와 사용 조건을 별도로 확인해야 합니다.
성공과 실패를 어떻게 기록할까
성공은 결과가 그럴듯한지가 아니라 승인 조건을 보존했는지로 봅니다. 삭제한 상품이 다시 나타나지 않고, 승인된 수정본이 다음 결과의 기준으로 남으며, 승인 전 결과가 외부로 나가지 않았다면 통과로 기록할 수 있습니다.
실패 조건도 미리 적어둡니다.
- 삭제한 오류가 다시 등장함
- 수정 이유는 남았지만 결과에는 반영되지 않음
- 승인 전 초안과 승인된 수정본을 구분할 수 없음
- 재처리 뒤 어떤 버전을 사용했는지 확인할 수 없음
- 공식 문서와 실제 화면의 동작이 일치하지 않음
- 결과는 맞지만 같은 조건에서 다시 검증할 기록이 없음
측정표에는 과장된 점수보다 관찰값이 어울립니다.
| 확인 항목 | 성공 기록 | 실패 기록 |
|---|---|---|
| 수정 보존 | 승인된 수정이 유지됨 | 수정 전 내용이 돌아옴 |
| 상태 구분 | 대기·반려·승인이 식별됨 | 현재 상태를 알 수 없음 |
| 입력 추적 | 재처리에 사용된 버전이 보임 | 사용된 버전이 불명확함 |
| 배포 차단 | 승인 전 외부 전달이 막힘 | 미승인 결과가 넘어감 |
| 문서 일치 | 설명과 실제 동작이 같음 | 설명과 화면이 다름 |
[이미지 캡션: 원본, 사람의 수정본, 재처리 결과를 나란히 놓고 삭제된 오류의 재등장 여부와 승인 상태를 비교한 화면]
좋은 결과보다 먼저 필요한 것은, 틀린 결과가 승인된 것처럼 흘러가지 않는 구조였습니다.
누구에게 유용하고 어디서 멈출까
이 체크리스트는 안내문, 요약문, 상품 설명처럼 정답 조건을 미리 적을 수 있는 반복 업무에 맞습니다. 혼자 운영하더라도 작성자와 승인자의 역할을 순간적으로 분리하면 무엇을 확인했는지 남기기 쉬웠습니다.
반면 법률, 의료, 재무처럼 잘못된 승인으로 피해가 커질 수 있는 판단에는 이 샘플만으로 충분하지 않습니다. 정답이 상황에 따라 달라지는 창작물이나 전략 판단도 수정 보존 여부만으로 품질을 증명하기 어렵습니다.
공식 변경 문서를 확인하지 못했거나, 승인 상태를 추적할 수 없거나, 재처리 입력 버전이 불명확하다면 자동 흐름을 멈추는 편이 맞습니다. 이번 글 역시 실제 제품 변경과 재처리 결과가 검증되지 않았으므로 특정 기능의 성능을 결론내리지 않습니다.
최종 판단
AI가 사람의 수정을 무시한 것처럼 보일 때 제가 먼저 다시 세울 규칙은 “더 강하게 요청하기”가 아니었습니다. 수정본을 기준 버전으로 고정하고, 승인 조건과 승인 상태를 분리하며, 안전한 샘플의 재처리 결과를 비교하는 것이었습니다.
공식 문서, 실제 화면, 비교 가능한 결과 가운데 하나라도 빠지면 기능 개선으로 판정하지 않습니다. 이 기준은 화려하지 않지만, 승인되지 않은 결과가 조용히 다음 단계로 넘어가는 일을 찾는 데는 쓸모가 있습니다.
이어지는 기록
사람의 수정을 지키려면 요청을 반복하는 대신 기준 버전, 승인 조건, 재처리 기록을 분리해야 합니다.