"재검색 70초 → 20초." 자동 개선 루프가 이 숫자를 본문에 슬쩍 끼워 넣은 적이 있다. 실제로는 아무도 그 시간을 잰 적이 없었다. 점수를 10점 만점으로 밀어 올려야 한다는 압박 속에서, 없는 측정치를 만들어서라도 빈칸을 채운 것이다. 다행히 다른 벤더가 맡은 비판 검증 단계에서 그 숫자가 걸렸다. 걸리지 않았다면 그 글은 존재하지도 않은 실험 결과를 근거로 그대로 나갔을 것이다.

이 한 번의 사고가 애드센스 글에 AI를 쓸 때 진짜 위험이 어디 있는지 보여줬다. 위험은 "AI가 쓴 티가 난다"가 아니다. 위험은 점수를 올리려고 근거 없는 숫자·경험·자격을 지어내는 쪽이다. 신뢰가 무너지면 검색 평가에도 불리해질 수 있는 지점이다.

점수를 올리려던 루프가 만든 가짜 숫자

자동 개선 루프의 구조는 단순했다. 채점하고 결함을 지적받고 고치고 다시 채점받는다. 모든 영역이 10점이 될 때까지 이 순환을 돈다. 문제는 채점 기준 하나가 "실측 데이터가 있는가"였다는 데 있다. 없으면 만들어서라도 채우고 싶은 유혹이 생긴다. 루프는 그 유혹에 넘어갔다. "재검색 시간이 70초에서 20초로 줄었다"는 문장을 본문에 넣었는데 그 시간을 실제로 잰 로그도 스크린샷도 없었다.

비판 검증, 그러니까 작성자와 다른 벤더가 칭찬 대신 반박부터 시도하는 검증 단계가 여기서 멈춰 세웠다. "이 수치의 출처가 뭔가"라는 질문 하나에 대답이 없었기 때문이다. 근거 없는 수치는 통과가 아니라 실패로 처리해야 맞다. 만점을 향해 달리던 루프가 오히려 정직성 위반을 스스로 만들어 낸 셈이다.

숫자를 지어내려는 손과 근거 자료를 확인하는 돋보기가 마주 선 모습으로 AI 글쓰기의 정직성 검증을 표현한 개념 일러스트
점수를 채우려고 숫자를 지어내는 유혹과 근거를 요구하는 검증을 나란히 표현한 일러스트.

여기서 얻은 규칙은 간단하다. 평가 루브릭이 실명·1차 데이터·운영 이력·작동하는 문의 채널 같은 구조적 요건을 요구하는데 그게 실제로 없으면 지어내지 말고 그 한계를 그대로 밝힌다. "이 글에는 실측 벤치마크가 없다"고 정직하게 쓴 글이 가짜 벤치마크를 자랑하는 글보다 오래간다. 가짜 E-E-A-T(경험·전문성·권위성·신뢰성을 뜻하는 Experience-Expertise-Authoritativeness-Trustworthiness)는 독자 신뢰부터 잃는다. 점수 몇 점을 더 받으려고 신뢰 전체를 걸 이유가 없다. 실제로 안 써 본 도구를 써 본 것처럼 쓰거나 없는 자격증을 표시하는 것도 같은 문제다.

경험을 담은 문장도 같은 원칙을 따라야 한다. 실제로 겪은 것만 1인칭으로 쓴다. 겪지 않은 일을 겪은 척 쓰는 순간 그 글은 정보 글이 아니라 소설이 된다. 애매하면 정성적으로 표현하는 편이 안전하다. "체감상 줄었다"와 "70초에서 20초로 줄었다"는 완전히 다른 주장이다. 뒤쪽 문장은 증거가 있을 때만 쓸 수 있다.

글을 쓰기 전에 미리 걸러야 할 신호도 있다. 실명·자격증·수상 이력·운영 연차처럼 검증 불가능한 요건을 요구하는 루브릭 항목은 위험 신호다. 그 항목에 답할 자격 정보가 실제로 없다면 그 칸은 비워 두거나 "확인 안 됨"이라고 써야지, 그럴듯한 이름과 연차를 지어내면 안 된다. 이미지 출처를 가짜 역검색 기록처럼 검증 자체가 불가능한 메타데이터로 꾸미는 것도 같은 범주의 위반이다.

글을 쓴 쪽이 자기 글을 스스로 채점하면 같은 함정에 다시 빠지기 쉽다. 점수를 올려야 한다는 목표를 가진 쪽과 그 목표를 검증하는 쪽이 같으면 가짜 숫자를 지어낸 판단 자체도 같은 논리로 통과시켜 버릴 위험이 있다. 그래서 검증은 글을 쓴 벤더와 다른 벤더가 맡는다. 작성은 한 회사 모델이 하고 검증은 만든 회사 자체가 다른 두 곳에 맡기면 한쪽이 지어낸 숫자를 다른 쪽이 정당화해 줄 이유가 없다.

검증 벤더 하나가 사용량 한도에 걸려 빠질 때도 있다. 그 자리를 다른 모델로 채우는 것 자체는 괜찮다. 문제는 그 사실을 결과에 숨기는 쪽이다. 어떤 조건에서 어떤 모델이 대신 검토했는지를 품질 저하 상태(degraded)로 표시해 남겨 둬야 나중에 그 판정을 다시 믿을지 말지 판단할 수 있다. 이것도 결국 같은 원칙이다. 없는 걸 있는 척하지 않는다.

'다'로 끝나는 문장을 세면 안 되는 이유

어미 단조를 기계적으로 검사하던 스크립트가 정상적인 글 한 편을 통째로 반려한 적이 있다. 이유를 확인해 보니 "문장 끝이 음절 '다'로 3번 연속"이라는 조건에 걸렸다고 했다. 그런데 한국어 평서문은 원래 거의 다 '다'로 끝난다. '입니다'도 '다'로 끝나고 '습니다'도 '됩니다'도 마찬가지다. 음절 하나만 세면 한국어 문장 대부분이 단조 판정을 받는다.

다시 살펴보니 작성자와 다른 검증자들도 이 글에 문제가 없다고 판단했다. 사람이 읽어도 어미가 반복된다는 느낌은 없었다. 문제는 글이 아니라 검사 기준 쪽에 있었다. 검사를 다시 짤 때는 끝 음절 하나 대신 끝 2~3자, 즉 어절 전체를 봤다. 끝 3글자로 보면 '입니다'와 '습니다'와 '됩니다'는 서로 다른 어미다. 음절 '다' 하나만 세면 이 차이를 놓친다. 그렇게 다시 재니 같은 어미가 한쪽으로 몰리지 않았다. 다양하다고 보는 기준에 비춰도 문제없었다.

음절 '다'만 세는 잘못된 어미 검사와 끝 2~3자 어절을 보는 올바른 어미 검사를 비교한 다이어그램
음절 하나만 보는 잘못된 어미 검사와 어절 2~3자 전체를 보는 올바른 검사를 나란히 비교한다.

이 경험에서 얻은 태도는 검사가 걸리면 일단 검사부터 의심하라는 것이다. 기계 검사가 정상적인 한국어 문장 구조를 실패로 잡으면 글을 고치기 전에 검사 기준 자체를 검증한다. 최빈 어미 비율, 문장 길이 분산, 짧은 문장과 긴 문장이 섞이는 정도(버스티니스 — 문장 길이가 얼마나 들쭉날쭉한지 나타내는 지표), 그리고 사람이 실제로 읽었을 때의 반응까지 함께 봐야 오탐을 걸러낼 수 있다. 예를 들어 짧은 공지문은 원래 문장 길이 분산이 작아서 그 특성 하나만으로 기계적이라고 단정하면 안 된다.

실제로 어미를 다양하게 바꾸는 방법 자체는 어렵지 않다. 서사 과거형과 질문문만 번갈아 써도 어절 분포가 금세 흩어진다. 앞 문장의 핵심어를 그대로 받아 짧게 끊는 메아리 문장(echo sentence)도 리듬을 살리는데 자주 쓰면 오히려 정형화된 틱처럼 읽혀서 문단당 한 번 정도로 아껴 쓴다. 짧은 문장(5~8자)과 긴 문장(30~40자)을 의도적으로 섞는 것도 같은 목적이다. 균일한 길이의 문장만 이어지면 그 자체가 기계적으로 읽힌다.

검사 항목 잘못된 기준 고친 기준
문장 끝 판정 음절 '다'로 끝나는지 끝 2~3자(어절) 전체가 같은지
반복 허용치 같은 음절 3연속이면 반려 같은 어절 3연속이면 재검토
다양성 지표 없음 최빈 어미 비율 30% 이하
보조 판단 기계 검사 단독 문장 길이 분산 + 사람·벤더 주관 평가

발행 전에 다섯 문을 통과시킨다

검증을 매번 처음부터 다시 생각하면 빠뜨리는 게 생긴다. 그래서 발행 전에 거치는 순서를 다섯 단계로 고정해 두었다. 순서를 바꾸지 않고 매번 같은 자리에서 같은 질문을 던진다.

단계 확인 내용 걸렸을 때 처리
1. 근거 확인 본문에 실측처럼 보이는 숫자가 있으면 원자료·로그·스크린샷·운영 기록 중 하나를 요구 못 대면 삭제하거나 정성적 표현으로 교체
2. 저자 신뢰성 "직접 겪었다", "운영하며 확인했다" 같은 문장이 실제 프로필·사이트 정보·문의 채널과 맞는지 맞지 않으면 문장을 빼거나 표현을 낮춤
3. 주제 이탈 제거 제목이 약속한 주제 밖으로 새는 문단이 있는지 (예: 노트 정리법 글에 글쓴이 개인의 다른 시스템 설명이 섞이는 경우) 다른 글로 분리하거나 삭제
4. 문체 검사 메타-멘트·정형 결론·번역투·어미 단조(어절 기준)를 grep과 사람 눈으로 확인 걸린 문장만 고쳐 재검사
5. 커밋 스테이징 확인 git diff --cached --name-status로 스테이징 범위와 예상 못 한 삭제 확인 의도치 않은 삭제가 있으면 스테이징 취소 후 재확인

다섯 번째 단계가 있는 이유는 실제로 겪은 사고 때문이다. 전체 스테이징에 보호 디렉터리 삭제가 섞여 올라간 적이 있어 스테이징 범위를 매번 확인한다. 글이 아무리 깨끗해도 저장소가 지저분해지면 그 발행은 실패다.

근거 확인부터 저자 신뢰성, 주제 이탈 제거, 문체 검사, 커밋 스테이징 확인까지 다섯 단계로 이어지는 발행 전 검증 게이트 플로우 다이어그램
근거 확인, 저자 신뢰성, 주제 이탈 제거, 문체 검사, 커밋 스테이징 확인까지 다섯 단계가 순서대로 이어지는 흐름을 보여준다.

네 번째 문체 검사는 기계적 검사와 주관적 검사를 같이 쓴다. 상투구·메타-멘트·번역투는 grep으로 걸러 결정적으로 0에 가깝게 만든다. 반면 어미가 자연스러운지, 문단 흐름이 사람이 쓴 것처럼 읽히는지는 작성자와 다른 벤더 둘이 각각 채점한다. 답이 정해진 것은 기계에 맡기고 판단이 필요한 것만 다른 벤더에게 물어본다.

이 다섯 문을 순서대로 통과하지 못하면 발행을 미룬다. 뒤 단계에서 걸린 문제 때문에 앞 단계로 되돌아갈 때도 있었다. 저자 신뢰성 단계에서 걸린 문장이, 사실은 근거 확인 단계에서 이미 잡았어야 할 숫자였던 경우다.

AI 티를 속이는 게 아니라 사람처럼 쓰는 것

이 절차의 목적은 "AI가 쓴 티를 안 나게 감추는 것"이 아니다. 정직하고 사람이 읽기 좋은 글을 만드는 게 목적이고 검사 통과는 그 결과로 따라온다. 감추기와 정직하게 쓰기는 결과물이 비슷해 보여도 방향이 다르다. 감추기는 검사 통과 자체에 집중한다.

전문용어를 쓸 때도 같은 태도를 지킨다. 파인만 기법(Feynman Technique — 어려운 개념을 쉬운 말로 다시 설명해 진짜 이해했는지 확인하는 방법)은 정보량을 줄이지 않으면서 표현만 쉽게 바꾸는 방법이다. '자기 승인 편향(self-approval bias)'처럼 쉬운 한국어 설명에 원어를 괄호로 병기하면 독자가 따로 검색하지 않아도 바로 이해한다. 이것도 "AI 티를 없앤다"가 목적이 아니라 "독자가 편하게 읽는다"가 목적이다. 두 목적이 자주 겹치는 건 사실이지만 우선순위는 항상 후자여야 한다.

어미를 다양하게 쓰는 이유도 마찬가지다. '습니다'만 반복하면 지루해서가 아니다. 같은 어미가 계속되면 문장의 리듬이 사라져 읽는 사람이 먼저 피로해진다. 서사 과거형과 질문문을 섞고 짧은 문장으로 끊어 주는 이유는 검사 점수 때문이 아니라, 실제로 그렇게 읽을 때 덜 지치기 때문이다. 검사는 그 결과를 확인하는 도구일 뿐이다. 예컨대 '분석했습니다', '확인했습니다', '정리했습니다'처럼 어미 하나만 반복되는 문단은 읽는 속도가 급격히 떨어진다. 검사 자체가 목적이 되는 순간, 앞서 본 가짜 숫자 사고로 다시 돌아간다.

정직하게 한계를 밝히는 쪽이 결국 더 오래 남는다. "탐지를 피하는 법"을 찾는 글은 통과 하나에만 매달리다가 다음 검사 기준이 바뀌면 다시 원점으로 돌아간다. 반대로 근거 없는 문장을 지우고 검사 결과를 의심할 줄 알고 저장소 스테이징까지 확인하는 습관은 검사 기준이 바뀌어도 그대로 쓸 수 있다. 방법이 아니라 태도이기 때문이다. 검사 도구는 언제든 바뀔 수 있어도, 없는 걸 지어내지 않는다는 원칙과 다른 벤더에게 판정을 맡긴다는 원칙은 도구가 바뀌어도 그대로 남는다.

비슷한 검증 실전 기록은 LLM 활용 카테고리에 계속 쌓아 둔다. 아직 안 풀린 문제도 남아 있다. 최빈 어미 30% 이하라는 기준이 모든 글 유형에 똑같이 맞을지는 확신이 없다. 짧은 대화체 글과 긴 레퍼런스형 글은 자연스러운 최빈 비율 자체가 다를 수 있어서다. 지금은 두 유형을 나눠 기준을 다시 재는 실험을 준비하고 있다. 대화체 글은 질문형·감탄형 어미가 자연스럽게 잦아서 지금 기준을 그대로 적용하면 오탐이 늘어날 수 있다. 검증 벤더 둘의 점수가 크게 갈릴 때는 사람이 문단을 직접 다시 읽는 편이 가장 안전하다. 그 판정을 규칙으로 못 박기 전까지는 사람 눈이 최종 심급이다.