AI 글쓰기, 탐지 대신 QA로

편집장이 원고를 훑다가 한 줄에서 멈춘다. 문장은 매끈하다. 말투는 균일하고 확신이 강하다. 출처가 없고, 사실 확인 흔적도 없다. 독자는 이를 “AI 티”로 받아들이고 페이지를 닫는다.

생성형 AI가 글을 “써주는” 환경에서 경쟁력은 생성 자체보다 품질관리(QA) 쪽에 걸린다. 프롬프트를 조금 바꾼다고 문제가 사라지지 않는다. 문체 동질화, 진정성 결핍, 환각(허위 주장)이 함께 나타나며 신뢰를 깎는다. 필요한 건 ‘탐지기’가 아니라 편집·검증·책임을 공정처럼 고정하는 운영 설계다.

세 줄 요약

무슨 변화/핵심이슈인가? 생성형 AI 콘텐츠의 거부감(‘AI 티’)은 문체만의 문제가 아니다. 검증·편집·책임 체계 부재가 함께 작동하며 문제를 키운다.
왜 중요한가? 신뢰성은 “AI를 썼냐”보다 “사실 주장(클레임)을 어떻게 측정·검증했냐”에서 갈린다. 환각은 클레임 오류 비율이나 응답 중 중대한 오류 포함 비율 같은 지표로 다룬다는 설명이 공식 문서에 나온다.
독자는 뭘 하면 되나? 탐지기 결과로 단정하지 말아야 한다. 글을 클레임 단위로 쪼개 출처를 연결하고, 리뷰·기록·재측정까지 포함한 QA 파이프라인을 문서화해야 한다.

현황

AI 글쓰기 품질관리에서 먼저 분리할 건 두 가지다. (1) 독자가 “티 난다”고 느끼는 문체·태도 문제와 (2) 실제로 위험을 만드는 사실 오류/근거 부재다. 둘은 같이 나타날 수 있다. 하지만 대응은 다르다. 문체는 편집으로 손볼 수 있다. 사실성은 검증 공정이 없으면 반복해서 무너진다.

공식 평가 프레임워크들은 환각을 “그럴듯한 문장”이 아니라 사실 주장(claim)의 오류로 다룬다. 예를 들어 OpenAI의 시스템 카드(안전 허브)는 사실성 측정에서 **“환각률(사실 주장 중 경미/중대 오류가 있는 비율)”**을 보고, 동시에 **“응답 단위로 중대한 오류 주장 1개 이상 포함한 비율”**도 본다고 적는다. 문서 전체가 ‘대체로 맞는지’만 보지 않는다. 큰 오류를 별도 항목으로 세는 방식이다.

“AI 탐지기”는 해결책처럼 보인다. 하지만 연구 결과는 사용에 신중할 필요가 있음을 말한다. NIST의 ‘2024 NIST GenAI (Pilot Study): Text-to-Text Evaluation Overview and Results’(NIST AI 700-1, 2025년 6월 25일 발행)는 T2T 평가에서 탐지기 성능이 시스템별로 크게 달라지며, 일부 생성기는 대부분의 탐지기를 속일 수 있고 일부 탐지기는 거의 모든 생성기 출력을 탐지할 수 있다고 요약한다. ‘AI가 쓴 글’이 아니라 ‘사람이 쓴 글을 AI로 다듬은 글’에서는 오탐 문제가 더 커진다는 연구도 있다. ‘Almost AI, Almost Human’(arXiv:2502.15666, v2)은 APT‑Eval 데이터셋이 14.7K 샘플이며, AI 텍스트 탐지기들이 최소한으로 폴리싱된 텍스트조차 AI 생성으로 자주 플래그한다고 보고한다.

분석

“AI 티”는 기술 자체보다 편집 결핍이 만드는 반복 패턴과 연결된다. 같은 도구를 써도 스타일 가이드와 교정 규칙이 있으면 글은 저자 톤을 회복한다. 반대로 조직이 “프롬프트 잘 쓰는 사람”만 찾고, 원고를 검증 가능한 주장 묶음으로 다루지 않으면 결과가 비슷해지기 쉽다. 매끈한 문장, 강한 확신, 출처 없는 일반론이 반복되고 독자는 이를 ‘기계 같은 글’로 읽는다.

여기서 실무에 해가 되는 오해가 있다. “탐지기가 걸러주겠다”는 기대다. NIST와 여러 연구가 다루듯 탐지기는 조건에 따라 흔들리고 오탐/미탐이 함께 생긴다. 특히 폴리싱처럼 현실적인 사용 형태에서 인간 글을 AI로 오해할 수 있다. 그래서 기준은 바뀌어야 한다. AI 사용 여부를 맞히는 게임이 아니라, 콘텐츠를 증거 기반으로 만드는 절차가 필요하다. NIST AI RMF는 Measure 기능에서 배포 전과 운영 중 정기 테스트, 불확실성 포함 보고, 벤치마크 비교, 공식화된 보고·문서화 같은 TEVV(시험·평가·검증·유효성확인) 접근을 권고한다. 글쓰기 QA도 같은 구조를 가져오면 된다.

실전 적용

핵심은 원고를 “문장”이 아니라 클레임(검증 가능한 주장) 리스트로 바꾸는 데 있다. 그리고 각 클레임에 (1) 근거 링크/자료, (2) 확인자, (3) 상태(확인/보류/삭제)를 붙인다. 이 과정을 자동화하거나 템플릿화하면 프롬프트 조정보다 변화가 크다. 이 단계가 없으면 모델이 바뀌어도 문제가 반복된다.

예: 어떤 팀은 AI로 초안을 만든 뒤 문장만 다듬는다. 읽기 좋지만 근거가 비어 있다. 다른 팀은 초안을 받은 뒤 주장을 먼저 목록으로 뽑고, 확인 가능한 것만 남긴다. 두 글의 ‘티’는 문체보다 책임의 밀도에서 갈린다.

오늘 바로 할 일 체크리스트

원고를 제출받으면 먼저 사실 주장(클레임)을 문장 단위가 아니라 항목 단위로 추출해라.
각 클레임에 **근거(출처/데이터/원문)와 확인 상태(확인·보류·삭제)**를 붙여 편집 로그로 남겨라.
운영 단계에서 **정기 재측정과 문서화(변경 이력, 리뷰어, 불확실성 표기)**를 팀 규칙으로 고정해라.

FAQ

Q1. ‘AI 티’는 프롬프트로 없앨 수 있나?
A. 줄일 수는 있다. 다만 한계도 있다. 문체 동질화는 프롬프트뿐 아니라 스타일 가이드·편집 규칙·검증 공정 부재와도 맞물린다. 톤은 편집으로, 신뢰는 검증으로 나눠 다뤄야 한다.

Q2. AI 탐지기를 쓰면 신뢰 문제가 해결되나?
A. 탐지기 단일 결과로 단정하면 리스크가 커질 수 있다. NIST 평가 요약처럼 성능 편차가 크고, 일부 생성기는 많은 탐지기를 속일 수 있다. 폴리싱된 인간 글을 AI로 오분류할 수 있다는 연구도 있다. 탐지는 참고 신호로 두고, 핵심은 출처·작성 이력·SME 리뷰 같은 다중 증거로 설계해야 한다.

Q3. 사실성은 어떻게 측정해야 하나?
A. 공식 문서들이 제시하는 방향은 “클레임 오류” 기반이다. 예컨대 시스템 카드는 **환각률(사실 주장 중 오류 비율)**과 응답 중 중대한 오류 포함 비율 같은 응답/클레임 이중 지표를 함께 본다고 말한다. 콘텐츠 QA에서도 원고를 클레임으로 쪼개 확인하고, 결과를 로그로 남기면 같은 접근을 적용할 수 있다.

결론

AI 글쓰기에서 품질은 “더 그럴듯하게 쓰기”보다 덜 틀리게 만들기에 가깝다. 탐지기 논쟁에만 기대기보다, 클레임 기반 검증과 문서화된 편집 공정으로 저자 책임을 복원하는 쪽이 신뢰를 얻는다. 앞으로의 쟁점은 하나다. 조직이 AI 도입을 “도구 구매”로만 보느냐, 아니면 TEVV형 운영 체계 구축으로 보느냐에 달려 있다.

Aionda

AI 글쓰기, 탐지 대신 QA로

세 줄 요약

현황

분석

실전 적용

FAQ

결론

다음으로 읽기

참고 자료

업데이트 받기