1. 워터마크는 보이지 않는 문자가 아니라 단어 선택의 패턴이다
OpenAI는 2026년 10월 5일 텍스트 출처 확인을 위한 워터마킹 접근을 공개했습니다. 공식 설명에 따르면 textGrain은 문장 안에 숨은 공백이나 특수문자를 삽입하는 방식이 아닙니다. 모델이 다음 단어나 토큰을 고를 때의 확률을 조정해 긴 글 전체에 통계적 패턴을 만들고, 같은 설정과 비밀 정보를 가진 탐지기가 그 패턴이 우연보다 자주 나타나는지 살핍니다.
따라서 복사해 붙여넣는 것만으로 신호가 사라지는 구조는 아니지만, 신호를 눈으로 볼 수도 없습니다. 모델이 선택할 수 있는 표현이 충분히 많을 때 패턴을 넣기 쉬우며, 수학 답이나 코드처럼 가능한 다음 표현이 제한된 글에서는 신호가 약해질 수 있습니다. 짧은 글도 관찰할 토큰이 적어 탐지가 어렵습니다.
발표 시점 기준으로 API 고객은 지원 모델에서 텍스트 워터마킹을 선택해 켤 수 있고 기본값은 꺼짐으로 안내됐습니다. EU의 ChatGPT와 Codex 적격 텍스트에는 단계적으로 적용될 예정이며, 탐지기 접근은 초기에는 승인된 연구자와 전문 기관으로 제한됩니다. 사용 범위와 제품 설정은 바뀔 수 있으므로 실제 구현 때 최신 공식 문서를 다시 확인해야 합니다.
근거 자료 · OpenAI · Our approach to EU text provenance rules · OpenAI Help · Provenance signals in OpenAI-generated content
2. 탐지 결과는 정답표가 아니라 불확실한 측정이다
워터마크 탐지에는 두 가지 기본 오류가 있습니다. 사람이 쓴 글이나 신호가 없는 글에서 워터마크를 찾았다고 판단하는 오탐, 워터마크가 있는 글을 찾지 못하는 미탐입니다. 탐지 기준을 민감하게 만들면 더 많은 신호를 찾지만 오탐도 늘 수 있고, 엄격하게 만들면 오탐은 줄어도 미탐이 늘 수 있습니다.
OpenAI가 공개한 평가 예에서는 목표 오탐률 1% 조건에서 일반적인 심리학 주제의 200토큰 글은 약 80%, 400토큰 글은 약 95%가 탐지됐습니다. 같은 길이라도 표현 선택이 제한적인 수학 내용은 탐지율이 더 낮았습니다. 이 수치는 발표에 포함된 특정 평가 조건의 결과이며 모든 언어, 모델, 주제와 편집 방식에 그대로 적용되는 보장값이 아닙니다.
‘탐지됨’은 해당 시스템이 글의 일부를 생성하거나 처리했을 가능성을 보여 주는 신호입니다. 누가 사용했는지, 사람이 얼마나 고쳤는지, 글의 소유권이 누구에게 있는지, 내용이 사실인지는 알려 주지 않습니다. 반대로 탐지되지 않았다고 사람이 썼다는 증거도 되지 않습니다.
| 탐지 결과 | 실제 신호 있음 | 실제 신호 없음 |
|---|---|---|
| 탐지됨 | 참양성: 출처 신호를 찾음 | 거짓양성: 오탐 가능성 |
| 탐지 안 됨 | 거짓음성: 짧은 글·편집 등으로 미탐 | 참음성: 신호를 찾지 못함 |
3. 같은 오탐률도 사용 환경에 따라 의미가 달라진다
탐지기의 오탐률만 보고 결과를 해석하면 기저율을 놓칩니다. 기저율은 검사 대상 가운데 실제로 워터마크가 있는 글의 비율입니다. 예를 들어 워터마크 글이 매우 드문 환경에서는 낮은 오탐률도 많은 사람 글에 잘못된 경고를 만들 수 있습니다.
교육용 가상 사례로 글 1만 개 가운데 실제 워터마크 글이 100개라고 가정합니다. 탐지율이 80%, 오탐률이 1%라면 워터마크 글 80개를 찾지만 나머지 9,900개 가운데 약 99개도 탐지될 수 있습니다. 이 조건에서는 ‘탐지됨’ 179개 중 실제 신호가 있는 글은 약 80개입니다. 수치는 설명을 위한 계산이며 공개 제품의 실제 운영 결과가 아닙니다.
이 때문에 탐지 결과 하나로 학생의 부정행위나 문서의 진위를 확정하면 안 됩니다. 작성 이력, 초안, 인용과 출처, 과제의 구두 설명, 버전 기록처럼 독립적인 근거를 함께 검토해야 합니다. 탐지기는 조사할 대상을 좁히는 하나의 신호로 다루는 편이 안전합니다.
| 가상 조건 | 계산 결과 | 해석 |
|---|---|---|
| 실제 신호 100개 | 탐지 80개 | 20개는 미탐 |
| 신호 없음 9,900개 | 오탐 약 99개 | 사람 글에도 경고 발생 |
| 전체 탐지 179개 | 실제 신호 약 80개 | 탐지 결과만으로 확정 불가 |
# 교육용 기저율 계산 예시
total = 10_000
watermarked = 100
detection_rate = 0.80
false_positive_rate = 0.01
true_positive = watermarked * detection_rate
false_positive = (total - watermarked) * false_positive_rate
precision = true_positive / (true_positive + false_positive)
print(true_positive, false_positive, precision)4. 편집과 번역은 신호를 약하게 만들 수 있다
텍스트 워터마크는 표현 선택의 누적 패턴이므로 단어를 바꾸거나 번역하면 패턴이 달라질 수 있습니다. OpenAI의 400토큰 영어 평가에서는 단어의 10%를 동의어로 바꿨을 때 탐지율이 약 92%에서 66%로, 25%를 바꿨을 때 17%로 낮아졌다고 보고했습니다. 이 역시 해당 실험 조건의 결과이며 모든 편집 도구와 언어에 같은 비율을 적용할 수는 없습니다.
내용을 편집했다는 사실 자체가 잘못은 아닙니다. 사람은 초안을 고치고 번역하며 공동 작성합니다. 워터마크가 약해졌다는 관찰은 편집량, 작성자의 기여, 최종 내용의 정확성이나 책임을 자동으로 판정하지 않습니다. 출처 확인과 내용 검증을 서로 다른 문제로 나눠야 합니다.
이미지와 오디오에서는 파일에 출처 메타데이터를 붙이거나 매체 자체에 신호를 넣는 방식도 쓰입니다. 메타데이터는 도구와 시점 같은 자세한 정보를 담을 수 있지만 변환이나 스크린샷 과정에서 사라질 수 있습니다. 내장 워터마크는 일부 변형을 견딜 수 있지만 담을 수 있는 정보가 제한되고 강한 편집에서 약해질 수 있습니다. 여러 신호를 함께 쓰는 이유입니다.
| 방법 | 장점 | 한계 |
|---|---|---|
| 텍스트 워터마크 | 복사 후에도 표현 패턴이 남을 수 있음 | 짧은 글·코드·번역·재작성에 약함 |
| 파일 메타데이터 | 도구·생성 이력 등 상세 정보 표현 | 변환·복사·스크린샷에서 제거 가능 |
| 눈에 보이는 표시 | 사람이 즉시 맥락을 이해 | 표시가 분리되거나 잘못 붙을 수 있음 |
| 작성·감사 기록 | 프로젝트 내부의 구체적 근거 보존 | 외부 공개 글만으로 확인하기 어려움 |
근거 자료 · OpenAI · Our approach to EU text provenance rules · OpenAI Help · Provenance signals in OpenAI-generated content
5. 서비스에서는 탐지값보다 근거와 이력을 저장한다
Java 백엔드에서 출처 확인 기능을 만든다면 boolean 하나로 ai_generated=true를 저장하지 않는 편이 좋습니다. 어떤 탐지기 버전이 어떤 시점에 어떤 길이의 텍스트를 검사했는지, 결과가 ‘신호 발견’, ‘신호 없음’, ‘판정 불가’ 중 무엇인지, 원문 해시와 처리 오류가 무엇인지 함께 기록해야 나중에 결과를 재검토할 수 있습니다.
SQL 테이블은 document_id, content_hash, detector_name, detector_version, checked_at, outcome, score, threshold, text_length, error_code 같은 열을 둘 수 있습니다. 원문 전체를 중복 저장하면 개인정보와 보존 비용이 늘 수 있으므로 목적에 맞는 최소 정보와 접근 권한을 정해야 합니다. 모델과 탐지기 버전이 바뀌면 이전 결과를 덮어쓰지 않고 새 검사 사건을 추가합니다.
API 응답도 ‘AI가 작성함’처럼 단정적인 문장보다 ‘지원되는 OpenAI 워터마크 신호가 탐지됨’처럼 관찰 범위를 표시해야 합니다. 신호가 없을 때는 ‘사람 작성’이 아니라 ‘지원되는 신호를 찾지 못함’으로 표현합니다. 탐지 서비스가 실패한 경우와 정상적으로 검사했지만 신호가 없는 경우도 구분합니다.
-- 교육용 감사 이력 설계 예시
CREATE TABLE provenance_checks (
check_id uuid PRIMARY KEY,
document_id uuid NOT NULL,
content_hash text NOT NULL,
detector_name text NOT NULL,
detector_version text NOT NULL,
outcome text NOT NULL CHECK (outcome IN ('detected','not_detected','inconclusive','error')),
score numeric, threshold numeric, text_length integer NOT NULL,
checked_at timestamptz NOT NULL, error_code text
);6. 규정 준수와 기술 탐지는 같은 문제가 아니다
유럽연합 집행위원회는 AI 생성 콘텐츠의 투명성과 탐지를 다루는 실천규약과 Article 50 관련 지침을 제공합니다. 기술 제공자는 기계가 읽을 수 있는 표시를 구현하고, 콘텐츠를 배포하는 쪽에는 상황에 따른 표시 의무가 있을 수 있습니다. 다만 적용 범위와 예외는 사용 사례와 역할에 따라 달라지므로 워터마크 결과만으로 법적 의무를 결정할 수 없습니다.
서비스 설계에서는 기술 신호, 사용자에게 보이는 설명, 조직의 검토 절차를 나눕니다. 워터마크 검사는 기계 신호를 제공하고, 화면의 라벨은 사용자가 그 의미를 이해하게 하며, 감사 기록은 결정 과정을 남깁니다. 어떤 공개 표시가 필요한지에 대한 판단은 최신 공식 지침과 조직의 법률·정책 검토를 따라야 합니다.
정확한 출처 표시가 있어도 내용 검증은 별도로 필요합니다. 워터마크가 있는 문장도 틀릴 수 있고, 사람 글도 부정확할 수 있습니다. 뉴스 날짜, 통계 원자료, 코드 실행 결과와 인용 링크를 다시 확인하는 절차가 출처 신호를 보완합니다.
근거 자료 · European Commission · Code of Practice on Transparency of AI-generated Content · European Commission · Guidelines on AI transparency obligations
7. Python·SQL·Java로 재현하는 1주 학습 프로젝트
아래 실습은 실제 textGrain 탐지기를 복제하거나 공개 서비스의 성능을 측정하는 실험이 아닙니다. 공식 탐지기 접근이 제한되어 있으므로, Python에서 정해 둔 탐지율·오탐률·기저율을 바꾸며 혼동행렬과 양성예측도를 계산하는 통계 시뮬레이션을 만듭니다. 글 길이와 편집률에 따라 가상의 탐지율을 바꾸되 그 값이 가정임을 화면에 표시합니다.
SQL에는 입력 조건과 결과를 사건별로 저장하고, detector_version별 오탐·미탐 수를 집계합니다. Java API는 POST /checks로 시뮬레이션을 요청하고 GET /checks/{id}로 결과와 한계 설명을 반환합니다. 클라우드 배포에서는 원문을 로그에 남기지 않고 해시와 길이만 기록하며, 민감한 텍스트를 수집하지 않는 구성을 먼저 선택합니다.
평가는 계산 정확성뿐 아니라 표현의 정확성을 봅니다. 탐지되지 않은 결과를 사람 작성으로 표시하지 않았는지, 가상 수치와 공식 발표 수치를 구분했는지, 기저율을 바꿨을 때 결과 해석이 달라지는지, 탐지기 오류와 신호 없음이 별도 상태인지 확인합니다. AI를 이용해 설명 문장을 만들었다면 원본 계산값과 일치하는지도 테스트합니다.
- 오탐·미탐·참양성·참음성을 각각 계산했는가
- 기저율을 1%·10%·50%로 바꿔 양성예측도를 비교했는가
- 공식 평가 수치와 교육용 가정을 화면에서 구분했는가
- SQL 이력에 탐지기 버전과 검사 시각을 남겼는가
- 결과 문구가 저자·정확성·책임을 단정하지 않는가
학생이 이 이슈에서 확인할 것
- 텍스트 워터마크가 숨은 문자 대신 통계적 단어 선택 패턴이라는 점을 설명할 수 있나요?
- 오탐률과 기저율을 함께 사용해 탐지 결과를 해석했나요?
- 탐지 신호와 저자·정확성·소유권 판단을 구분했나요?
- 서비스가 결과뿐 아니라 탐지기 버전·시각·한계를 기록하나요?
Python으로 기저율·탐지율·오탐률을 바꾸는 출처 신호 시뮬레이터를 만들고, SQL에 검사 이력을 저장하며 Java API로 결과와 한계 설명을 반환하세요. 공식 수치와 가상 조건을 분리하고 원문 최소 수집 원칙을 문서화하세요.
관심 기술을 대학의 프로젝트로 연결하세요.
전공의 학습 흐름을 이해하고 학생이 직접 만든 결과를 확인한 뒤, 자신에게 맞는 입학 계획을 세워 보세요.