기사의 오류를 수정하고 공개 페이지까지 확인했다면, 그 대응은 일단 완료된 것입니다.
하지만 수정 기록을 남기는 것만으로는 다음 기사가 자동으로 안전해지는 것은 아닙니다. 같은 종류의 오류가 다음 달에도 발생하고 있다면, 기록이 보관되어 있어도 제작 과정에는 반영되지 않은 상태입니다.
반면에, 수정 사항이 나올 때마다 체크 항목을 추가하면 공개 전 검토 과정은 계속 길어집니다. 항목이 너무 많으면 모든 것에 동일한 주의를 기울일 수 없어, 정말 중요한 확인 사항이 묻히게 됩니다. AI에 대한 지침도 길어지고, 기사와 관련 없는 금지사항까지 포함하게 됩니다.
그래서 저는 공개 후의 수정 기록을 한 달에 한 번 모아서 검토하고, 다음 세 가지로 되돌립니다.
- 모든 기사에 공통으로 사용되는 체크리스트
- 특정 기사에서만 사용하는 기사별 체크
- AI에게 전달하는 요청문과 기계적으로 검사하는 규칙
이 글에서는 수정 건수의 많고 적음만으로 판단하지 않고, 원인, 발견 시점, 영향, 현재 탐지 방법을 보고 체크리스트와 AI 지침을 개선하는 방법을 정리합니다.
수정 기록을 보면 '누가 잘못했는지'에 초점이 맞춰지기 쉽습니다. 하지만 월별 검토로 확인하고 싶은 것은 담당자의 실수가 아니라, 오류가 제작 과정의 어느 단계를 통과했는지입니다.
같은 오류라도 발생한 이유와 발견된 장소에 따라 개선책은 달라집니다.
오류: 이벤트 개최일을 하루 잘못 기재함
발생: 오래된 배포 자료를 AI에게 전달함
놓친 부분: 공개 전에 공식 페이지와 대조하지 않음
...
이 경우, '날짜에 주의하라'는 경고만으로는 부족합니다. 필요한 것은 사용한 자료의 버전을 확인하고, 날짜/시간을 공식 정보와 대조하며, 기사에서 만든 SNS까지 영향 범위에 포함하는 시스템입니다.
월별 검토에서는 개별 수정문을 읽어보는 것뿐만 아니라, 발생-놓침-발견-영향의 흐름을 건별로 갖추게 합니다. 기록 작성 방식이 매번 다르면 월말에 비교할 수 없습니다. 최소한 다음 항목들을 갖춥니다.
| 항목 | 기록 내용 |
|---|
| 대상 | 기사 URL, 공개일, 기사 종류 |
| ... | |
'AI가 틀렸다', '확인 부족이었다'만으로는 분류할 수 없습니다. AI가 존재하지 않는 숫자를 만들었는지, 오래된 자료를 정확하게 요약했는지, 사람이 올바른 후보 중 잘못된 것을 채택했는지를 구분합니다.
원인이 확정되지 않았다면 억지로 하나로 결정하지 않습니다.
확정된 사실: 오래된 자료가 입력에 포함되어 있었음
미확정: AI가 신구(新舊)를 판별할 수 없었던 이유
확인 불가능한 것: 공개 시 담당자가 어떤 화면을 보고 있었는지
모르는 부분을 추측으로 채우면, 잘못된 대책을 공통 규칙으로 만들어 버립니다.
월별 검토에서는 수정 건수가 많은 순서만으로 우선순위를 정하지 않습니다. 저는 다음 4가지 관점에서 봅니다.
- 같은 원인이 반복되고 있는지
- 공개 전에 탐지할 수 있는지
- 독자의 판단이나 안전에 얼마나 영향을 미치는지
- 다른 기사나 SNS로 확산되기 쉬운지
예를 들어, 조사(助詞) 오류가 5건 있고 개최일시 오류가 1건이었다고 해도, 날짜/시간 오류를 먼저 다룰 때가 있습니다. 빈도는 낮더라도 독자의 행동을 바꾸고 여러 매체로 복사될 수 있기 때문입니다.
반대로, 매달 발생하더라도 문서 교정 도구(文章校正ツール)로 확실하게 탐지할 수 있는 것은 자동 검사 영역으로 옮길 수 있습니다. 인간의 최종 승인으로 매번 처음부터 찾을 필요는 없습니다.
간단한 우선순위표를 만들면 판단하기 쉽습니다.
| 재발성 | 영향 | 우선 개선 방안 |
|---|
| 높음 | 높음 | 제작 과정을 변경하고 공통 체크에 추가 |
| ... | | |
원인과 우선순위를 확인했다면, 대책을 어디에 둘지 결정합니다. 모든 것을 공통 체크리스트에 추가하지 않는 것이 중요합니다.
많은 기사에 나타나고 공개 전에 인간이 판단해야 하는 항목들입니다.
- 숫자, 날짜/시간, 요금, 장소를 1차 정보와 대조했는지
- 인명, 단체명, 직책의 표기 여부를 확인했는지
- 직접 인용과 AI에 의한 요약을 구분했는지
- 공개 범위, 개인정보, 미공개 정보를 확인했는지
- 공개 후 SNS나 다른 기사로 재활용되는 범위를 파악했는지
다만, 같은 의미의 항목이 이미 있다면 추가가 아니라 통합합니다. '날짜를 확인', '시간을 확인', '개최 기간을 확인' 등을 기사 종류에 따라 '날짜/시간을 1차 정보와 대조'로 묶을 수 있는 경우가 있습니다.
특정 종류의 기사에만 필요한 항목은 공통 체크에서 제외합니다.
- 이벤트 기사: 중지/연기/신청 마감일
- 매장 기사: 영업일, 가격, 게재 허가
- 취재 기사: 직접 인용, 화자, 사진의 공개 가능 여부
- 기술 기사: Version, 실행 환경, 재현 조건
기사 종류를 선택하면 필요한 체크만 나오도록 하면, 확인량을 줄이면서 중요 항목을 눈에 띄게 할 수 있습니다.
문자열이나 형식으로 판별할 수 있는 항목은 AI의 주의력이나 인간의 기억에만 의존하지 않습니다.
- 작성 중 메모나 보류 마커가 남아있지 않은지
- 이미지 URL이 공개 URL인지
- 태그 수가 상한선 이내인지
- 제목과 예정된 제목이 일치하는지
- 같은 날짜에 공개 후보가 여러 개가 아닌지
자동 검사가 성공했다고 해도, 내용 자체가 정확하다는 보장은 없습니다. 자동 검사는 형식 확인을 담당하고, 인간은 의미와 공개 가능 여부를 판단하는 역할을 분리해야 합니다.
수정이 발생한 후에도 AI 요청문에 “정확하게 작성해 주세요”, “날짜를 틀리지 않게 해 주세요”와 같은 문구를 추가한다고 해서, 확인 방법이 없다면 재발 방지가 되지 않습니다.
개선 전의 지침은 다음과 같아지기 쉽습니다.
글을 정확하게 작성해 주세요.
날짜나 고유명사를 틀리지 않게 해 주세요.
개선 후에는 입력(Input), 출력(Output), 그리고 중단 조건(Stop Condition)을 명시합니다.
입력으로 제공된 자료만을 사용해 주세요.
날짜, 요금, 고유명사, 직접 인용문을 표로 추출하고,
각각의 출처명과 확인일을 기재해 주세요.
...
중요한 것은 AI에게 정확성을 약속받게 하는 것이 아닙니다. 어떤 자료를 사용할지, 무엇을 별도로 표로 만들지, 어느 상태에서 멈출지, 그리고 인간에게 무엇을 반환할지를 결정하는 것입니다.
또한, 과거의 수정 내용은 매번 그대로 프롬프트에 붙여넣지 않습니다. 개인 정보나 비공개 정보를 포함할 가능성이 있으며, 너무 긴 기록은 이번 판단을 모호하게 만듭니다. 수정 기록에서 일반화된 확인 절차만을 필요한 기사 유형별 요청문에 반영합니다.
월간 검토는 항목을 늘리는 회의가 아닙니다. 추가와 동시에 통합, 이동, 삭제도 진행합니다.
각 항목에 대해 다음을 확인합니다.
이 항목이 방지하는 오류는 무엇인가?
지난 3개월 동안 같은 오류가 있었나?
공통 항목으로 존재할 필요가 있는가?
...
대응되는 오류를 설명할 수 없는 항목은 남길 이유를 재검토합니다. 특정 기사에만 필요한 경우 기사별로 옮기고, 기계적으로 확인할 수 있다면 자동 검사 단계로 이동시킵니다.
체크리스트나 AI 지침을 변경했다면, 변경 전 내용을 삭제하지 않고 사유와 적용일을 기록해야 합니다.
## 월간 개선 기록 2026년 10월
- 근거가 된 수정: 날짜 오류 1건, 구 자료 사용 1건
- 변경: 날짜를 일차 정보와 대조하는 항목을 공통 체크에 추가
...
다음 달에는 단순히 수정 건수가 줄었는지만 보지 않습니다.
- 추가한 항목으로 공개 전에 오류를 감지할 수 있었는가?
- 확인 시간이 너무 늘어나지는 않았는가?
- AI가 중단 조건을 지키고, 불명확한 점을 반환했는가?
- 다른 곳으로 오류가 이동하지 않았는가?
- 검사된 증거가 남아있는가?
수정이 '0'이라 하더라도, 단순히 대상 기사가 없었을 수도 있습니다. 반대로 공개 전 감지 건수가 늘었다면, 공개 후의 오류를 막았을 가능성이 있습니다. 결과뿐만 아니라, 어느 단계에서 발견되었는지를 봅니다.
# 수정 기록 월간 검토
## 대상
- 대상 기간:
...
공란이 남는 경우, AI는 임의로 원인이나 승인자를 보완하지 않습니다. 개선안은 초안으로 제출할 수 있지만, 공통 규칙에 반영하는 것은 인간이 확인한 후에 진행합니다.
수정 기록은 단순히 저장만 한다고 해서 재발 방지가 되지 않습니다. 한 달에 한 번, 제작 과정으로 돌아가 시간을 만들어야 합니다.
- 수정 발생 → 놓침 → 발견 → 영향의 흐름으로 정리한다.
- 누가 틀렸는가가 아니라, 어떤 과정을 거쳤는가를 본다.
- 건수뿐만 아니라, 재발성, 영향도, 감지 가능성, 확산 범위를 우선순위로 둔다.
- 개선할 곳을 공통 체크, 기사별 체크, 자동 검사, AI 지침으로 나눈다.
- AI 지침을 주의문이 아닌, 입력(Input), 출력(Output), 중단 조건(Stop Condition)을 포함하는 검증 절차로 만든다.
- 새로운 항목을 추가할 뿐만 아니라, 중복 항목을 통합하고 불필요한 항목을 줄인다.
- 변경 사유, 적용일, 인간 승인(Human Approval)을 남긴다.
- 다음 달에는 수정 건수뿐만 아니라, 공개 전에 감지했는지를 확인한다.
AI는 수정 기록의 분류, 유사 원인 추출, 체크 항목 후보 생성에 도움을 줄 수 있습니다. 그러나 어떤 리스크를 공통 규칙으로 할지, 검토 부담을 어디까지 받아들일지, 실제로 규칙을 변경할지는 인간이 결정합니다.
수정 기록을 반성문으로 끝내지 않고, 다음 제작 과정을 조금씩 변화시키는 것. 그 순환을 매월 지속한다면, 체크리스트는 길이가 아니라 실제로 막아낼 수 있는 오류에 의해 업데이트되게 됩니다.
다음에는 AI 지침을 변경한 후, 기대했던 대로 멈추고 확인 사항을 반환하는지 작은 테스트로 점검하는 방법을 정리하겠습니다.