AI 비서의 '정상' 표시를 믿기 전에 확인한 것들

작동한다는 표시가 보고 품질의 경고를 덮고 있었어요

7월에는 실행 상태와 보고 품질의 경고가 하나의 정상 표시로 뭉개지거나, 반대로 품질 경고가 전체 장애처럼 읽힐 수 있었어요. 여러 상태를 한 줄로 요약하면서 정상 동작만 남기니 사용자가 알아야 할 약점이 빠졌어요. 그래서 실제로 멈춘 작업은 장애로, 작동했지만 내용이 충분하지 않은 결과는 품질 경고로 남기도록 상태 요약을 고쳤어요. 실행이 멈췄다면 복구가 필요하고, 내용이 약하다면 자료와 선별 방식을 봐야 하니까요.

두 상태를 나누니 모든 문제를 같은 재시작으로 해결하려는 판단을 피할 수 있었어요. 다시 실행해야 하는 작업과 내용을 읽어 봐야 하는 보고서는 사용자의 다음 행동이 달라요. 경고의 이유가 보이면 같은 파일을 반복해서 만드는 대신 부족한 근거나 선별 기준을 검토하는 쪽으로 질문을 옮길 수 있어요. 주요 실행과 복구가 끝난 뒤에도 일부 산출물의 품질이 약하다는 경고는 그대로 남겼어요.

같은 달에 특정 발행 작업이 멈췄는데도 성공처럼 보인 일이 있었어요. 상태 수집이 그 프로필에 일일 자료가 있는지만 보고 있었고, 같은 날 만들어진 다른 용도의 보고서가 실패를 가렸어요. 저는 기준을 해당 작업이 만들어야 하는 결과로 좁혔어요. 관련 작업을 복구하고 공식 예약 작업을 다시 실행했으며, 손으로 만든 결과와 정식 실행의 성공을 따로 근거로 남겼어요.

파일이 있는 것과 읽을 수 있는 것을 나눠서 봤어요

7월 초에는 기록 일부가 사라진 것처럼 보였어요. 원본을 따라가 보니 내용은 그대로 남아 있었어요. 보고서 앞부분에 관리 정보를 추가한 뒤에도 읽는 과정은 첫 줄에 제목이 온다고 가정했고, 개인·회사·운영 프로필 모두 같은 가정을 쓰고 있었어요. 원본을 다시 모으거나 덮어쓰지 않고 읽기 처리를 새 형식에 맞췄고, 새 프로필을 만들 때 쓰는 기준도 함께 살폈어요.

8월에는 예약 작업도 성공이고 상태창도 정상인데, 보고서가 날짜와 입력 같은 기본 정보 규칙을 채우지 못한 채 남아 있었어요. 성공 판단이 문서가 있는지, 크기가 충분한지만 보고 있었기 때문이에요. 생성 마지막 단계에서 필요한 정보를 마무리하고 검증하도록 고쳤고, 이미 만든 본문은 다시 쓰지 않았어요. 상태창도 같은 조건을 읽게 해서 규칙을 어긴 문서와 내용만 약한 문서를 다른 상태로 보여 주게 했어요. 겉모습은 7월 초의 일과 비슷했지만, 그때는 읽는 쪽이 새 형식을 못 따라온 것이고 이번에는 만들어진 문서 자체가 조건을 채우지 못한 것이었어요.

정상이라는 말을 더 좁게 쓰기로 했어요

네 가지 일을 지나며 저는 실행 상태, 그 작업의 결과, 문서의 읽기 조건, 내용의 품질을 각각 따로 보게 됐어요. 결과를 찾을 때는 날짜와 역할도 함께 읽어야 했어요. 같은 날의 개인 기록이 회사 발행의 결과를 대신할 수 없고, 전날의 성공 파일이 오늘 실행의 성공을 뜻하지도 않아요. 실행을 고친 근거와 상태 표시를 고친 근거를 따로 남긴 것도 같은 이유예요. 작업이 성공해도 화면이 예전 실패를 읽을 수 있고, 화면이 정상이어도 실제 결과는 없을 수 있어요.

정상 표시는 이 중 무엇을 확인했는지 가리킬 때 쓸모가 있어요. 사용자에게 필요한 것은 문제가 하나도 없다는 표시보다, 어떤 단계가 끝났고 무엇을 더 판단해야 하는지 알려 주는 설명이었어요.

확인한 범위는 사건마다 달랐어요. 발행 작업은 공식 예약 실행을 다시 돌려 회복을 봤지만, 8월 문서 조건 수정은 로컬 수정과 검증까지였고 외부 예약 실행 재시도나 원격 반영은 포함하지 않았어요. 과거 문서의 경고도 일괄로 고치지 않았어요. 표시가 정확해진 뒤 확인 부담이나 시간이 얼마나 줄었는지는 측정하지 않았고, 이후 모든 자동 실행과 새 형식을 읽는 다른 사용처가 맞게 동작한다는 보장도 아직 없어요. 당시 따로 남아 있던 입력 연결 오류도 이 복구 범위 밖이었어요.