AI 오류 기록이란, 반복되는 실패를 재현하고 고치는 방법

오류라고 부를 근거부터 마련한다

오류를 기록하려면 기대한 동작이 먼저 있어야 한다. 사용자가 원한 것과 다르다는 이유만으로 모두 같은 실패가 되지는 않는다. 요청에 분명히 적은 규칙을 어겼는지, 입력이 부족했는지, 문체 취향이 맞지 않았는지 구분한다.

예를 들어 가상의 물품 목록을 보관 장소별로 묶는 작업을 가정한다. 입력에는 물품 이름과 장소가 있고 장소가 비어 있는 항목도 있다. 빈 항목을 어떻게 처리할지 정하지 않았다면 결과가 예상과 달라도 곧바로 규칙 위반이라고 부르기 어렵다.

빈 장소는 미분류로 남긴다는 요구를 명시했다면 판단 기준이 생긴다. 도구가 문맥을 보고 임의의 장소를 채웠을 때 해당 응답과 위반한 조건을 연결할 수 있다. 오류 설명은 틀렸다는 평가보다 어떤 규칙을 벗어났는지를 중심으로 쓴다.

기록에 사용할 자료는 민감한 업무 원문 대신 가상 자료로 구성할 수 있다. 이때 문제가 생긴 구조는 유지해야 한다. 중복된 이름 때문에 오류가 났다면 이름을 바꾸더라도 중복 관계는 남겨야 같은 문제를 살필 수 있다.

다시 확인할 수 있는 단위로 남긴다

기본 기록에는 작업 목적, 입력 자료, 실제 요청문, 대화 상태, 응답 원본을 담는다. 오류가 있는 문장만 잘라 보관하면 앞선 조건이 사라질 수 있다. 해당 부분을 찾기 쉽게 표시하되 원래 맥락도 함께 남긴다.

기대 결과는 가능한 한 구체적으로 쓴다. 미분류 항목이 유지되어야 한다거나 원래 항목이 빠지면 안 된다는 식이다. 결과물의 모양까지 하나로 정할 필요는 없지만, 통과 여부를 판단할 규칙은 다른 사람이 읽어도 알 수 있어야 한다.

실제 결과에는 관찰한 현상을 적는다. 분류를 잘 못한다는 넓은 평가 대신 빈 항목에 임의의 장소가 들어갔다고 쓴다. 원인에 대한 생각은 별도 메모로 두어 관찰과 추정이 섞이지 않게 한다.

오류의 영향을 설명할 때는 사용 지점을 기준으로 한다. 보기 불편한 정렬 문제인지, 원래 항목이 사라져 후속 작업을 바꾸는 문제인지 구별한다. 놀라운 사례를 강조하기보다 어떤 검토가 필요한지 알 수 있게 적는다.

재현을 시도할 때는 처음 조건을 그대로 사용한다. 요청을 다듬은 뒤 결과가 달라졌다고 원래 문제가 재현되지 않았다고 말하면 안 된다. 같은 조건을 다시 확인하는 과정과 개선안을 적용하는 과정은 순서와 기록을 나눈다.

수정 효과는 원래 실패와 함께 읽는다

같은 조건에서 문제가 다시 나타났다면 반복 관찰로 남긴다. 다시 나타나지 않았다면 그 사실도 기록한다. 한 번 더 실행한 결과만으로 언제나 발생한다거나 완전히 사라졌다고 결론내리지 않는다.

수정은 확인하려는 항목을 중심으로 진행한다. 빈 항목 처리 지시를 추가하면서 출력 형식과 자료 순서까지 한꺼번에 바꾸면 무엇이 영향을 주었는지 알기 어렵다. 작업상 여러 조건을 바꿨다면 그 범위를 빠짐없이 적는다.

개선 후에는 원래 오류뿐 아니라 보존해야 할 조건도 살핀다. 미분류 항목은 살아났지만 다른 항목이 합쳐졌다면 해결이 끝난 것이 아니다. 문제를 고치는 과정에서 새로 생긴 누락이나 왜곡까지 확인해야 한다.

수정의 성격도 구분한다. 요청을 명확히 해서 해결한 경우와 사람이 직접 결과를 고친 경우는 다르다. 직접 편집한 결과를 도구의 재응답처럼 남기지 않는다. 사람의 개입이 필요한 위치를 보여주는 것도 오류 기록의 역할이다.

개별 사례를 모을 때는 겉모양보다 위반한 규칙을 기준으로 묶는다. 원문에 없는 값 추가, 항목 누락, 지정 형식 위반처럼 분류하면 다음 검토 항목으로 연결하기 쉽다. 서로 다른 원인을 단지 답이 이상했다는 범주에 넣지 않는다.

오류 기록 자체가 틀어지는 경우를 경계한다

처음 응답을 덮어쓰는 일은 피한다. 고친 결과만 남으면 어떤 문제가 있었고 얼마나 손봤는지 확인할 수 없다. 원본 응답, 추가 요청, 최종 결과가 이어지는 순서를 보존해야 수정 과정을 설명할 수 있다.

기억으로 요청문을 복원하는 것도 한계가 있다. 비슷한 표현이라도 조건의 의미가 달라질 수 있다. 실제 요청문을 남기지 못했다면 재구성한 내용이라고 표시하고 원래 상황과 완전히 같은 재현으로 취급하지 않는다.

성공한 재시도만 보관하면 수정 효과를 과장할 수 있다. 반대로 실패한 장면만 모으면 작업 전체를 판단하기 어렵다. 어떤 시도를 기록 대상으로 삼았는지 기준을 정하고, 그 안에서 성공과 실패를 함께 남긴다.

원인을 도구 탓으로 너무 빨리 돌리지 않는다. 입력 파일의 누락, 잘못된 기대 결과, 불명확한 지시도 확인해야 한다. 다만 원인을 찾지 못했다고 관찰한 오류를 지울 필요는 없다. 현상은 확인됐지만 원인은 모른다고 구분하면 된다.

비슷한 오류가 다른 작업에서도 보였다는 이유로 같은 문제라고 단정하지 않는다. 항목 누락이라는 현상은 같아도 자료를 읽지 못한 경우와 정리 과정에서 빠뜨린 경우는 다를 수 있다. 확인한 수준까지만 묶고 나머지는 열어 둔다.

다음 작업에 반영하는 마무리 점검

오류 기록은 다음 행동으로 이어져야 한다. 빈 항목을 임의로 채운 사례라면 이후 작업에 빈칸 처리 원칙을 명시하고 결과에서 해당 항목을 대조한다. 기록을 쌓는 일보다 검토 절차가 어떻게 바뀌었는지를 확인하는 것이 중요하다.

자주 보는 작업에는 필요한 점검 항목만 추려 둔다. 모든 과거 오류를 매번 긴 요청문으로 붙이면 현재 업무의 목적이 흐려질 수 있다. 입력 조건을 보완할 문제와 사람이 결과에서 확인할 문제를 나누어 적용한다.

마지막으로 해결 상태를 과장하지 않는다. 특정 입력에서 수정안을 확인한 것인지, 다른 형태의 자료에서도 살핀 것인지 범위를 남긴다. AI의 답은 틀릴 수 있으므로 중요한 업무에서는 오류 기록을 참고하되 최종 결과를 사람이 확인해야 한다.