AI 탐지 리포트를 점수만으로 끝내지 않는 설계 메모

AI 탐지 도구의 UI를 생각할 때, 가장 위험한 것은 "AI스러움의 점수"를 그대로 결론처럼 보여주는 것이라고 생각합니다. Detector de IA를 만드는 과정에서 의식했던 것은, 탐지 모델에 대한 이야기보다 사용자가 입력, 추출, 판정, 확인, 저장까지 어떻게 오해 없이 진행할 수 있는가였습니다. 여기서는 구현 상세가 아니라, 프로덕트 경계로서 정리한 내용을 작성합니다.

입력 입구를 두 가지로 나누기

이런 종류의 도구에서는 텍스트를 붙여넣는 사용자와 파일을 가지고 있는 사용자가 섞여 있습니다. 입구를 하나로 통합하면 설명은 짧아지겠지만, 실제로는 다루는 실패 조건이 다릅니다. 붙여넣기 텍스트의 경우, 너무 짧은 입력을 피하기 위해 300자 이상, 너무 긴 입력을 피하기 위해 100,000자 이하라는 경계를 명시합니다. 문서 업로드에서는 PDF, DOCX, TXT, MD, Markdown, plain text를 대상으로 하며, 파일 크기는 12MB 미만으로 합니다. 이 제한은 단순한 유효성 검사(Validation)가 아닙니다. 탐지 결과를 읽기 전에, 샘플 양이나 추출 조건이 결과에 영향을 미친다는 것을 보여주기 위한 전제입니다.

문서 추출은 형식별로 책임을 분리하기

PDF나 DOCX는 브라우저 측에서 텍스트를 추출한 뒤 탐지로 넘기는 편이 사용자에게 "지금 무엇을 보내려고 하는가"를 설명하기 쉽습니다. 반면, TXT나 MD는 그대로 텍스트로 다루기 쉬우므로 업로드 후의 처리도 단순합니다. 이 부분을 모호하게 하여 "문서 대응"이라고만 적으면, 파일을 던지기만 하면 무엇이든 같은 정밀도로 읽을 수 있는 것처럼 보입니다. 실제로는 추출된 텍스트의 양, 줄 바꿈, 표, 제목, 본문 이외의 혼입 등에 따라 후속 탐지 결과의 읽는 방식이 달라집니다.

리포트는 결론이 아니라 확인 자료로 만들기

AI 탐지의 출력은 하나의 라벨만으로는 부족합니다. 적어도 verdict(판결), risk(리스크), AI스러움의 점수, 인간스러움의 점수, evidence strength(증거 강도), 분석 메모, 문장 단위의 하이라이트를 나누어 표시하는 편이 사용자가 "어디를 다시 읽어야 할지" 판단하기 쉽습니다. 특히 문장 단위의 하이라이트는 중요합니다. 전체 점수만 있다면 왜 그런 결과가 나왔는지 독자가 확인할 수 없습니다. 문장별 시그널을 제공함으로써, 지나치게 균일한 표현, 설명의 밀도, 문체의 흔들림 등을 인간이 재확인하는 입구가 됩니다.

제한 사항은 본문 끝이 아니라 UI의 일부로 만들기

이 워크플로우에서는 탐지 결과를 저자 증명, 표절 판정, 부정행위의 증거, AI 이용의 단정으로 취급하지 않는다는 점을 명시할 필요가 있습니다. 오탐(False Positive)과 미탐(False Negative)도 발생할 수 있으므로, 학업, 고용, 법무, 징계 등의 중요한 판단에서 유일한 근거로 삼아서는 안 됩니다. 또한, 무료 도구라고 해서 무제한, 완전 로컬 처리, 제로 기록, 제로 보유와 같은 약속은 할 수 없습니다. 운영상의 로그, 속도 제한(Rate Limit), 외부 탐지 프로바이더의 가용성 등 사용자가 너무 큰 기대를 하지 않도록 하는 경계도 필요합니다.

요약

AI 탐지 리포트를 만들 때는 점수를 강력하게 보여주는 것보다, 그 점수를 어떻게 읽어야 하는지를 먼저 설계하는 편이 안전합니다. 입력 조건, 문서 추출, 문장 단위의 시그널, 복사나 인쇄용 리포트, 확률적인 주의 사항을 동일한 흐름에 배치합니다. 그렇게 하면 도구는 "판정기"가 아니라, 리뷰 작업을 진행하기 위한 보조선이 됩니다. 이번 설계 메모에서 예로 든 페이지는 여기입니다. Detector de IA