Claude 워터마킹과 AI 텍스트 탐지 — 생성된 글은 어디까지 추적 가능한가

AI가 쓴 글을 알아낼 수 있을까?

이 질문은 오래전부터 있었지만, 최근에는 조금 더 구체적인 형태로 바뀌고 있다. 단순히 “AI 탐지기를 만들 수 있나?”가 아니라 “모델이 글을 생성하는 순간부터 식별 가능한 통계적 신호를 남길 수 있나?”가 된 것이다.

Anthropic은 Claude의 미래 모델 출력에 텍스트 워터마킹을 적용하겠다고 설명했다. Sebastian Raschka도 이 내용을 바탕으로 Claude 워터마킹의 작동 방식을 짧은 글과 긴 영상 강의로 풀었다. 같은 시기에 그는 AI 텍스트 탐지기를 직접 만드는 글도 올렸다.

이 세 글은 같이 읽어야 한다. 워터마킹은 “모델이 생성할 때 신호를 심는 방식”이고, AI 탐지기는 “이미 나온 텍스트에서 생성 흔적을 추정하는 방식”이다. 둘은 비슷해 보이지만 실무에서의 신뢰도와 사용처가 꽤 다르다.

핵심 요약

Claude 워터마킹의 아이디어는 텍스트에 보이지 않는 문자를 숨기는 것이 아니다. 별도 메타데이터를 붙이는 것도 아니다. 모델이 다음 토큰을 고를 때, 후보 토큰들 사이의 선택 확률에 아주 미세한 편향을 주고, 그 편향이 긴 텍스트 전체에 통계적 패턴으로 남도록 만드는 방식이다.

Anthropic 설명에 따르면 이 방식은 다음 특성을 목표로 한다.

사람이 읽을 때 watermarked text와 unwatermarked text가 구분되지 않는다.
텍스트 안에 hidden character나 별도 식별자를 넣지 않는다.
추가 토큰 비용이 들지 않는다.
특정 사용자, 조직, 대화로 추적 가능한 정보는 담지 않는다.
EU AI Act 대응 맥락에서 여러 AI provider가 비슷한 방향을 준비하고 있다.

하지만 여기서 바로 결론을 내리면 안 된다. 워터마킹은 “Claude가 관여했을 가능성”을 통계적으로 말해주는 장치에 가깝다. 법적 증거처럼 개인을 특정하거나, 모든 편집 이후에도 영원히 남는 디지털 서명으로 보면 안 된다.

워터마킹은 어떻게 작동하나

LLM은 한 번에 완성된 문장을 쓰지 않는다. 지금까지의 문맥을 보고 다음 토큰 후보들의 확률 분포를 만든 뒤, 그중 하나를 선택한다.

예를 들어 “오늘 날씨는 춥고...” 다음에는 “흐렸다”, “바람이 불었다”, “쌀쌀했다” 같은 후보가 자연스럽다. 반대로 전혀 어울리지 않는 단어는 확률이 낮다.

일반적인 sampling에서는 top-k, top-p, temperature 같은 설정이 다음 토큰 선택을 조절한다. 워터마킹은 여기에 하나의 조건을 더 넣는다.

secret key + 최근 토큰 문맥
-> pseudorandom seed
-> 후보 토큰별 pseudorandom score
-> sampling 과정에 미세한 편향 추가
-> 여러 위치에 반복되며 통계적 패턴 형성

중요한 점은 편향이 너무 크면 글 품질이 떨어지고, 너무 작으면 탐지가 어려워진다는 것이다. 그래서 워터마킹은 사람이 읽는 품질을 거의 건드리지 않으면서도, 긴 텍스트 전체에서는 우연히 나오기 어려운 상관관계를 만들려 한다.

Raschka의 설명에서 좋은 비유는 “한두 단어가 아니라 많은 토큰 위치에서 반복되는 통계적 선택 패턴”이라는 점이다. 개별 단어 하나만 보고는 알 수 없다. 하지만 충분히 긴 텍스트에서 특정 key-dependent 선택이 반복되면, detector는 그 패턴이 우연인지 아닌지를 판단할 수 있다.

왜 짧은 문장에서는 어렵나

워터마킹은 기본적으로 통계 문제다. 표본이 적으면 신호를 안정적으로 보기 어렵다.

짧은 문장 하나, 댓글 한 줄, 제목 몇 개만 보고 “이건 Claude가 썼다”고 말하기는 어렵다. 토큰 수가 적으면 우연히 watermark-like pattern이 나올 수도 있고, 반대로 실제 watermarked text인데도 신호가 약하게 보일 수 있다.

그래서 워터마킹은 긴 글에서 더 강하다. 보고서, 에세이, 블로그 초안, 긴 이메일처럼 token position이 충분히 많은 경우에는 반복 패턴을 볼 여지가 생긴다.

실무적으로는 이 지점이 중요하다. 짧은 텍스트에 AI 탐지기를 들이대고 확정 판단을 내리는 것은 위험하다. 탐지 점수는 언제나 텍스트 길이와 편집 이력을 같이 봐야 한다.

편집하면 워터마크는 사라질까

사라질 수 있다. 정확히는 약해질 수 있다.

Raschka도 지적하듯, moderate to severe editing이나 다른 non-watermarking LLM을 이용한 rephrasing은 watermark signal을 제거하거나 약하게 만들 수 있다. 워터마크가 특정 단어 몇 개에 박혀 있는 것이 아니라 토큰 선택 패턴 전체에 분산되어 있기 때문이다.

다만 완전히 공짜는 아니다. 어떤 위치가 watermark에 중요한지 모르는 상태에서 신호를 지우려면 꽤 많은 부분을 바꿔야 한다. 그러면 글의 문체, 의미, 품질이 달라질 수 있다. 즉 워터마킹 우회는 가능하지만, 원문을 보존하면서 티 안 나게 지우는 것은 별도의 작업이 된다.

이건 보안 시스템과 비슷하다. 완벽한 방어가 아니라 우회 비용을 높이는 장치다.

AI 텍스트 탐지기는 다른 문제다

워터마킹과 AI detector는 자주 섞여서 이야기되지만, 출발점이 다르다.

워터마킹은 생성 시점에 신호를 심는다. 탐지기는 사후적으로 텍스트의 특징을 보고 “AI가 썼을 가능성”을 추정한다.

Raschka의 “Building an AI Text Detector From Scratch” 글은 이 차이를 이해하는 데 좋다. 그는 Substack의 AI detector 기능을 계기로, 작은 모델을 이용해 AI detector를 직접 구현하는 프로젝트를 소개한다. 이 프로젝트의 목적은 단순히 탐지기를 만드는 것이 아니라, detector가 어떻게 scorer 또는 verifier로 쓰일 수 있는지 보여주는 데 있다.

탐지기는 대략 이런 신호를 볼 수 있다.

특정 모델이 자주 쓰는 표현 패턴
token distribution의 자연스러움 또는 과도한 매끄러움
인간 글에서 흔한 불규칙성의 부재
문장 길이, 반복, 연결어 사용 패턴
perplexity나 classifier embedding 기반 특징

하지만 이런 신호는 모델이 바뀌거나, 사람이 고치거나, 다른 LLM이 rewrite하면 쉽게 흔들린다. 그래서 일반 AI detector는 워터마킹보다 더 불안정하다. 특히 “AI스럽게 잘 다듬어진 인간 글”과 “사람처럼 살짝 거칠게 만든 AI 글”을 구분하는 것은 어렵다.

탐지기를 어디에 쓰면 좋은가

나는 AI detector를 “판사”가 아니라 “보조 신호”로 써야 한다고 본다.

예를 들어 다음 용도에는 쓸 수 있다.

스팸성 대량 생성 콘텐츠 필터링
synthetic data 정제
내부 문서 품질 관리
LLM 출력이 너무 generic해졌는지 확인
verifier를 붙인 LLM 응용 실험

반대로 다음 용도에는 매우 조심해야 한다.

학생 과제 부정행위 단정
채용 과제 탈락 근거
작성자 징계
저작권 또는 책임 소재의 단독 증거

false positive가 치명적인 영역에서는 탐지 점수 하나로 결론을 내리면 안 된다. 특히 글쓰기 도구로 문법 교정만 받은 인간 글이 “AI generated”로 잡힐 수 있다는 점은 현실적인 문제다. Raschka도 detector를 “내 글을 polish하되 AI처럼 보이지 않게 유지하는 verifier”로 활용할 수 있다고 언급한다. 이 관점이 더 건강하다.

제품 관점에서 보면 watermark와 detector는 역할이 다르다

서비스를 만드는 입장에서 둘은 다른 레이어에 놓인다.

Watermark는 provider 책임에 가깝다

모델 제공자가 generation 단계에서 적용해야 한다. 사용자는 보통 이 과정을 직접 통제하지 않는다. Claude처럼 closed model을 쓰는 경우, provider가 어떤 방식으로 watermark를 넣고 어떤 detector를 제공하는지가 중요해진다.

Detector는 downstream operator의 도구다

플랫폼, 블로그, 교육기관, 기업 내부 시스템이 detector를 붙일 수 있다. 하지만 detector는 정책과 함께 설계해야 한다. 임계값을 어디에 둘지, 사람이 review할지, appeal process를 둘지, 짧은 텍스트는 제외할지 같은 운영 규칙이 필요하다.

Verifier는 agent 시스템에도 연결된다

Raschka의 detector 프로젝트에서 흥미로운 부분은 detector를 verifier로 써서 작은 언어 모델이 detection을 피하는 텍스트를 만들도록 학습시키는 아이디어다. 이건 AI detector 자체보다 더 넓은 주제다.

요즘 LLM 응용에서는 scorer나 verifier가 점점 중요해지고 있다.

답변이 정책을 어겼는지 확인하는 verifier
코드가 테스트를 통과하는지 보는 verifier
검색 결과와 답변이 일치하는지 보는 verifier
사람이 쓴 듯한 문체를 유지하는 style verifier

AI detector는 이런 verifier-based LLM application의 좋은 예제다. 정답이 하나로 고정된 수학 문제가 아니어도, 어떤 목표에 맞게 출력을 평가하고 다시 개선하는 루프를 만들 수 있다.

실무에서 가져갈 기준

나는 이 주제를 볼 때 세 가지 기준을 세우는 게 좋다고 본다.

1. 식별과 책임 추적을 구분한다

워터마킹은 “이 텍스트가 특정 모델 계열에서 나왔을 가능성”을 말할 수 있다. 하지만 “누가, 어떤 프롬프트로, 어떤 목적으로 만들었는가”까지 말해주지는 않는다.

Anthropic도 watermark가 특정 사용자, 조직, chat을 식별하지 않는다고 설명한다. 따라서 watermark는 provenance signal이지 accountability system 전체가 아니다.

2. 탐지 점수는 항상 confidence와 함께 본다

AI detector가 80점이라고 해서 곧바로 “AI가 썼다”가 아니다. 텍스트 길이, 도메인, 편집 여부, 사용한 문법 교정 도구, 모델 종류, threshold calibration을 같이 봐야 한다.

탐지기를 운영한다면 점수만 보여주기보다 아래 정보를 같이 남기는 게 낫다.

텍스트 길이
detector version
threshold
confidence interval 또는 uncertainty
사람이 review했는지 여부
최종 판단과 detector 점수의 관계

3. 우회 가능성을 전제로 설계한다

워터마킹도 detector도 우회 가능하다. 그러면 쓸모없다는 뜻이 아니다. spam filtering이나 abuse detection도 완벽해서 쓰는 게 아니다. 우회 비용을 높이고, 대량 악용을 줄이고, 사람이 봐야 할 후보를 좁히기 위해 쓴다.

AI 텍스트 탐지도 같은 위치에 둬야 한다. 완벽한 진실 판별기가 아니라, 운영 비용을 낮추는 signal이다.

내 결론

Claude 워터마킹은 꽤 흥미로운 방향이다. 텍스트에 눈에 보이는 표식을 넣지 않고도 generation process 자체에서 통계적 흔적을 남긴다는 점에서, 단순 AI detector보다 더 principled한 접근이다.

하지만 이걸 과대평가하면 안 된다. 편집과 rephrasing으로 약해질 수 있고, 짧은 텍스트에서는 신호가 불안정할 수 있으며, 사용자나 대화를 특정하는 장치도 아니다.

AI detector 역시 마찬가지다. 기술적으로 만들 수 있고 유용한 상황도 많지만, 사람을 처벌하거나 책임을 단정하는 단독 근거로 쓰기에는 위험하다.

내가 가져갈 실무적 결론은 이렇다.

AI 텍스트 탐지는 판정 시스템이 아니라 risk signal이다. 워터마킹은 그 signal을 더 안정적으로 만들 수 있지만, 정책과 human review 없이 혼자서 진실을 말해주지는 않는다.

앞으로 이 주제는 더 중요해질 것이다. AI-generated content가 늘어날수록 “무엇이 AI가 만든 것인가”보다 “그 사실을 어떤 의사결정에 써도 되는가”가 더 큰 문제가 되기 때문이다.