AI 기초

GUIDE / 10번째 글

AI 워터마킹: AI 생성 콘텐츠를 추적하는 기술

토큰 편향·의미론적·주파수 도메인 등 AI 워터마킹 기법을 분류하고, Kirchenbauer의 LLM 워터마크 원리와 Google SynthID를 코드와 함께 설명합니다.

PALDYN Team31 MIN READ

지난 글에서 LLM 탈옥 공격과 방어를 다뤘다. 탈옥이 "모델에게 하면 안 되는 말을 시키는" 문제였다면, 이번 글은 그렇게 나온 결과물이 세상에 풀린 뒤의 문제다. 딥페이크 이미지가 선거 여론을 흔들고, LLM이 쓴 원고가 사람 이름으로 학술지에 들어가고, 생성된 음성이 전화 사기에 쓰인다. 그때마다 같은 질문이 돌아온다. "이건 누가 만들었나."

AI 워터마킹은 생성하는 순간에 사람이 알아채지 못할 신호를 결과물 안에 심어 두었다가, 나중에 그 신호를 다시 읽어 내는 기술이다. 사후에 결과물만 보고 통계적으로 짐작하는 "AI 탐지기"와는 출발점이 다르다. 탐지기는 남이 만든 물건을 밖에서 뜯어보는 쪽이고, 워터마킹은 만드는 쪽이 미리 표식을 남겨 두는 쪽이다. 표식을 남길 수 있는 자리에 있다는 것이 이 기술의 유일한 밑천이자, 동시에 가장 큰 한계다.

탐지·귀속·출처

기술 이야기를 하기 전에 무엇을 증명하려는지부터 갈라야 한다. 이 자리가 흐리면 "워터마크가 있으니 AI가 만든 것"이라는, 실제로는 성립하지 않는 문장을 아무렇지 않게 쓰게 된다.

세 가지 주장

탐지(detection)는 "이건 어떤 생성 모델이 만들었다"는 주장이다. 어느 모델인지는 묻지 않는다. 귀속(attribution)은 "이건 특정 모델, 특정 사업자의 출력이다"까지 좁힌 주장이다. 출처(provenance)는 한 걸음 더 나아가 "이 파일이 언제 어떤 도구에서 만들어졌고 그 뒤 누가 어떻게 고쳤는가"라는 이력 전체를 말한다.

셋은 난이도가 다르다. 탐지는 신호가 있느냐 없느냐만 보면 되지만, 귀속은 그 신호가 다른 모델의 신호와 구별돼야 한다. 출처는 신호 하나로는 아예 안 되고 파일에 붙는 별도 기록이 있어야 한다. 그래서 뒤에서 볼 워터마킹은 앞의 둘을 맡고, C2PA 같은 메타데이터 표준이 셋째를 맡는다.

증거의 강도

가장 자주 뒤집히는 방향은 이쪽이다. 워터마크가 검출됐다는 것은 꽤 센 증거다. 뒤에서 계산하겠지만 우연히 그 패턴이 나올 확률은 십만분의 일 수준으로 떨어뜨릴 수 있다. 반대로 워터마크가 검출되지 않았다는 것은 거의 아무 증거도 아니다. 워터마크를 안 넣는 모델로 만들었을 수도 있고, 넣은 뒤 지웠을 수도 있고, 글이 짧아 신호가 안 설 수도 있다.

증거의 방향이 한쪽으로만 강하다는 성질은 실무에서 결정적이다. "워터마크가 없으니 사람이 쓴 글"이라는 결론은 낼 수 없다. 낼 수 있는 결론은 "워터마크가 있으니 이 모델을 거쳤을 가능성이 매우 높다" 하나뿐이다.

탐지·귀속·출처 세 주장과 증거의 비대칭

표시 의무

EU AI 법은 AI가 만든 콘텐츠에 기계가 읽을 수 있는 형태로 표시를 남기도록 요구한다. 사람 눈에 보이는 라벨과 별개로, 프로그램이 자동으로 확인할 수 있는 표식을 요구한다는 점이 워터마킹·C2PA 같은 기술을 밀어 올린 배경이다.

다만 의무의 방향을 오해하면 안 된다. 규제는 만드는 쪽에 표시를 남기라고 요구한다. 유통되는 콘텐츠를 보고 AI 여부를 판정할 능력을 누구에게도 부여하지 않는다. 표식이 없는 콘텐츠가 온 세상에 널려 있다는 사실은 규제가 있든 없든 그대로다. 규제 지형 전반은 다음 글에서 따로 다룬다.

토큰 편향 워터마크

2023년 John Kirchenbauer 등이 제안한 방법이 지금도 텍스트 워터마킹의 기준선이다. 아이디어 자체는 한 문장으로 요약된다. 모델이 다음 낱말을 고를 때, 비밀 키로 미리 정해 둔 절반쪽 낱말에 슬쩍 가산점을 준다.

초록 목록과 빨강 목록

생성기는 토큰 하나를 낼 때마다 직전 토큰을 씨앗으로 삼아 어휘 전체를 두 덩이로 가른다. 가산점을 받는 쪽이 초록 목록(green list), 못 받는 쪽이 빨강 목록(red list)이다. 어휘의 몇 할을 초록으로 둘지가 γ\gamma 이고 보통 0.5를 쓴다. 가산점의 크기는 δ\delta 이고 로짓에 그대로 더한다.

로짓에 2를 더한다는 것이 얼마나 센 조작인지 감을 잡아 두는 편이 좋다. 소프트맥스는 로짓 차이를 지수로 바꾸므로, δ=2\delta = 2 는 그 토큰이 뽑힐 승산을 e2≈7.4e^2 \approx 7.4 배로 올린다. 원래 확률이 1%였던 초록 토큰은 7% 근처가 되고, 원래 40%였던 빨강 토큰은 10% 남짓으로 밀린다. 문장 하나 안에서는 어색함이 눈에 띄지 않지만, 수백 토큰을 쌓으면 초록 비율이 확실히 기운다.

# 토큰 편향 워터마크 개념 구현
import hashlib
import torch

def get_green_list(prev_token_id, secret_key, vocab_size, gamma=0.5):
    """이전 토큰으로 Green 목록 결정"""
    seed = int(hashlib.sha256(
        f"{secret_key}{prev_token_id}".encode()
    ).hexdigest(), 16) % (2**32)
    rng = torch.Generator()
    rng.manual_seed(seed)
    # 어휘의 gamma 비율을 Green으로 지정
    perm = torch.randperm(vocab_size, generator=rng)
    green_count = int(vocab_size * gamma)
    return set(perm[:green_count].tolist())

def watermarked_generate(logits, prev_token_id, secret_key, delta=2.0):
    """Green 토큰 logit을 delta만큼 증가"""
    green_list = get_green_list(prev_token_id, secret_key, len(logits))
    logits_copy = logits.clone()
    for idx in green_list:
        logits_copy[idx] += delta
    return logits_copy

def detect_watermark(text_tokens, secret_key, vocab_size, gamma=0.5):
    """Green 토큰 비율로 워터마크 검출"""
    green_count = 0
    for i in range(1, len(text_tokens)):
        green_list = get_green_list(
            text_tokens[i-1], secret_key, vocab_size, gamma
        )
        if text_tokens[i] in green_list:
            green_count += 1

    green_ratio = green_count / (len(text_tokens) - 1)
    # 인간 작성: ~0.5, 워터마크: ~0.5 + delta 효과
    return green_ratio, green_ratio > 0.6  # 임계값

검출 쪽 코드가 생성 쪽과 대칭인 점을 보면 된다. 같은 비밀 키로 같은 순서를 따라가며 초록 목록을 다시 만들고, 실제 토큰이 그 안에 들었는지 센다. 모델도 필요 없고 확률 분포도 필요 없다. 키와 토크나이저만 있으면 된다.

AI 워터마킹 기법

토큰 편향 워터마크 작동 원리

검출 통계량

위 코드는 "초록 비율 0.6 넘으면 워터마크"라는 고정 임계값을 썼지만, 실제로는 글 길이를 반영하는 통계량을 쓴다. 토큰 TT 개 중 초록이 ss 개 나왔을 때의 z 점수다.

z=s−γTTγ(1−γ)z = \frac{s - \gamma T}{\sqrt{T\gamma(1-\gamma)}}

워터마크가 없는 글이라면 초록 목록은 키로 무작위하게 정해진 절반이므로, 토큰마다 초록에 걸릴 확률이 γ\gamma 다. 그래서 사람이 쓴 글의 초록 개수는 평균 γT\gamma T 근처에 모이고 z는 0 주변을 오간다.

숫자를 한 번 넣어 보자. γ=0.5\gamma = 0.5, 토큰 200개 글이면 분모는 200×0.25≈7.07\sqrt{200 \times 0.25} \approx 7.07 이다. z가 4를 넘으려면 초록이 100+4×7.07≈128100 + 4 \times 7.07 \approx 128 개, 즉 64%여야 한다. 정규분포에서 z가 4를 넘을 확률은 대략 십만분의 세 번이므로, 사람이 쓴 200토큰 글이 우연히 이 선을 넘을 일은 거의 없다. 고정 임계값 0.6이 아니라 z를 쓰는 이유가 여기 있다. 비율 0.6은 200토큰에서는 z 2.8이지만 20토큰에서는 z 0.9밖에 안 된다. 같은 비율이 길이에 따라 전혀 다른 강도의 증거가 된다.

엔트로피와 길이

이 방식이 실을 수 있는 신호의 양은 모델이 실제로 망설인 자리의 개수에 비례한다. "대한민국의 수도는 서울"에서 마지막 토큰은 거의 확률 1이라, 로짓에 2를 더하든 말든 뽑히는 토큰이 안 바뀐다. 이런 자리는 초록·빨강 중 어디에 걸리든 우연이고 신호를 하나도 담지 못한다.

그래서 워터마크가 잘 서는 글과 안 서는 글이 갈린다. 자유롭게 풀어 쓴 산문은 매 자리마다 후보가 여럿이라 신호가 잘 쌓인다. 반대로 코드, 수식 전개, 정해진 서식의 문서, 인용문은 선택의 여지가 적어 신호가 잘 안 쌓인다. 번역도 원문이 답을 거의 정해 버려 사정이 비슷하다.

길이 문제는 더 직접적이다. 25토큰짜리 짧은 답변에서 z 4를 넘기려면 분모가 25×0.25=2.5\sqrt{25 \times 0.25} = 2.5 이므로 초록이 12.5+10=22.512.5 + 10 = 22.5 개, 25개 중 23개가 초록이어야 한다. 이런 편향은 δ\delta 를 아무리 올려도 문장이 망가지기 전에는 안 나온다. 한두 문장짜리 챗봇 답변에는 텍스트 워터마크를 심을 수 없다. 이건 구현 문제가 아니라 정보량의 한계다.

품질과 세기의 맞바꿈

δ\delta 를 올리면 검출은 쉬워지고 글은 나빠진다. 가산점이 커질수록 모델은 자기가 원래 고르려던 낱말 대신 초록 목록에 든 낱말을 고르게 되고, 그 자리에 딱 맞는 표현이 빨강에 있으면 두 번째로 맞는 표현이 나간다. 짧게는 티가 안 나지만 문단이 길어지면 어휘가 미묘하게 겉돌기 시작한다.

구글이 Gemini 출력에 적용한 SynthID는 이 맞바꿈을 다르게 푼다. 로짓을 직접 밀어 올리는 대신, 후보 토큰들을 키에서 나온 값으로 토너먼트처럼 겨루게 해 이기는 쪽을 뽑는다. 원래 분포에서 뽑을 확률을 크게 흔들지 않으면서 키를 아는 쪽만 알아볼 수 있는 편향을 남기는 방식이다. 구글은 텍스트 쪽 구현을 공개 라이브러리로 내놓았고 Hugging Face transformers와 붙여 쓸 수 있다.

# SynthID 텍스트 워터마크 (Google 공개 라이브러리)
from synthid_text import logits_processing, hashing

# 워터마크 설정
config = {
    "ngram_len": 5,      # n-gram 컨텍스트 길이
    "keys": [654, 400],  # 여러 레이어의 비밀 키
    "sampling_table_size": 2**16,
    "sampling_table_seed": 0,
    "context_history_size": 1024,
}

# 생성 시 자동 적용 (Hugging Face transformers 통합)
from transformers import AutoModelForCausalLM, AutoTokenizer

model = AutoModelForCausalLM.from_pretrained("google/gemma-2b")
# SynthID LogitsProcessor를 추가해 워터마크 삽입

설정에서 눈여겨볼 것은 ngram_len과 keys다. 앞의 값은 초록 목록을 정할 때 직전 토큰 하나가 아니라 n-gram을 씨앗으로 쓴다는 뜻이다. 씨앗이 길수록 같은 문맥이 되풀이될 때 같은 목록이 반복되는 일이 줄어 신호가 고르게 퍼진다. 뒤의 값이 여러 개인 것은 서로 다른 키의 편향을 층으로 겹쳐 검출을 안정시키기 위해서다.

잠재 공간 워터마크

이미지·오디오·비디오는 텍스트와 사정이 다르다. 이산 토큰을 고르는 자리가 없는 대신, 사람 감각이 둔한 성분이 넉넉하다.

화소와 잠재 공간

가장 소박한 방법은 화소값을 조금씩 건드리는 것이다. 최하위 비트에 신호를 숨기는 식이다. 눈에 안 보인다는 점은 좋지만 JPEG로 한 번만 다시 저장해도 그 비트가 통째로 날아간다. 손실 압축이 하는 일이 정확히 "사람 눈에 안 중요한 성분 버리기"이기 때문이다. 눈에 안 보이는 자리에 숨겼다는 것이 곧 압축이 버릴 자리에 숨겼다는 뜻이 된다.

그래서 실제 시스템은 잠재 공간(latent space)에 심는다. 확산 모델이 이미지를 만들 때 거치는 압축된 표현 공간을 말한다. 이 공간의 좌표는 화소 하나가 아니라 이미지 전체의 구조에 퍼져 나가므로, 신호가 화면 곳곳에 얇게 흩어진다. 그 결과 다시 압축하거나, 일부를 잘라 내거나, 색을 손봐도 남은 부분에서 신호를 되찾을 수 있다.

SynthID

SynthID 이미지 워터마크가 이 방식이다. 구글은 Gemini와 자사 이미지 생성 모델의 출력에 이 워터마크를 넣고, 별도 검출기로 확인한다. 픽셀 도메인이 아니라 잠재 공간에서 작동하기 때문에 압축·크롭·색상 조정에 견딘다.

핵심은 "견딘다"가 이분법이 아니라는 점이다. 검출기는 있다·없다가 아니라 신뢰도를 함께 낸다. 원본 그대로면 확신, 심하게 잘리고 다시 압축된 이미지면 "아마도" 수준으로 내려간다. 변형이 누적될수록 판정이 흐려지는 것은 설계가 잘못돼서가 아니라 남은 신호가 실제로 줄었기 때문이다.

오디오와 비디오

오디오는 파형을 그대로 건드리지 않고 주파수 표현으로 옮겨 신호를 심은 뒤 되돌리는 쪽이 유리하다. 사람 귀는 큰 소리 근처의 작은 소리를 잘 못 듣는데, 그 가려지는 구간이 신호를 숨기기 좋은 자리다. 심어 놓으면 재생하고 다시 녹음해도 상당 부분 살아남는다.

비디오는 프레임마다 이미지 워터마크를 넣는 것이 기본이지만, 프레임이 많다는 점이 오히려 유리하다. 한 프레임에서 신호가 깨져도 다른 프레임에서 읽으면 되기 때문이다. 반대로 짧은 클립으로 잘라 내고 화질을 크게 떨어뜨리면 텍스트에서 본 것과 같은 문제, 즉 신호를 실을 자리 자체가 모자라는 상황이 온다.

제거 공격과 견고성

워터마크는 지우려는 사람이 있다는 전제 위에 있다. 방어의 강도를 말할 때는 공격자가 무엇을 아는지부터 정해야 한다.

의역 공격

텍스트 워터마크를 지우는 가장 값싼 방법은 의역(paraphrase)이다. 워터마크가 든 글을 다른 모델에 넣어 "같은 뜻으로 다시 써 줘"라고 시키면, 토큰 선택이 통째로 다시 이뤄지므로 초록 편향이 사라진다. 문장 순서를 바꾸고 동의어로 갈아 끼우는 정도만으로도 z 점수가 크게 떨어진다.

방어 쪽은 편향을 낱말이 아니라 의미 단위에 걸어 의역에 견디게 만들려고 하지만, 근본적인 비대칭이 있다. 공격자는 뜻만 지키면 되고 방어자는 표현까지 지켜야 한다. 뜻을 지키는 변형의 공간이 훨씬 넓다.

재인코딩과 크롭

이미지 쪽에서 가장 흔한 제거는 악의 없이 일어난다. 스크린샷을 찍고, 메신저로 보내면서 자동 압축되고, 편집 앱에서 잘리고, 스티커가 얹힌다. 이 과정을 서너 번 거친 이미지는 공격을 당한 적이 없는데도 신호가 상당히 깎여 있다.

의도적인 공격은 여기에 노이즈 주입과 미세한 기하 변형을 더한다. 몇 도 돌리고, 1~2% 늘이고, 약한 필터를 씌운다. 사람 눈에는 같은 이미지지만 잠재 표현은 꽤 움직인다. 검출기는 이런 변형을 되돌리려 시도하지만, 되돌릴 변형의 종류를 미리 알고 있어야 한다는 점에서 늘 한 발 뒤에 있다.

공격자의 지식

같은 워터마크라도 공격자가 무엇을 아느냐에 따라 난이도가 달라진다. 알고리즘만 아는 경우, 검출기를 마음껏 호출해 볼 수 있는 경우, 같은 모델의 워터마크된 출력을 대량으로 모은 경우가 다 다르다.

특히 위험한 쪽은 검출기를 마음대로 두드릴 수 있는 상황이다. 결과물을 조금씩 고쳐 가며 검출 점수가 떨어지는 방향을 찾으면, 알고리즘을 몰라도 경사를 더듬어 내려가듯 워터마크를 깎아 낼 수 있다. 그래서 검출기를 아무에게나 공개 API로 열어 주는 설계는 위험하다. 공개하면 검증이 쉬워지고 닫으면 공격이 어려워지는 맞바꿈이 여기 있다.

위조 공격

지우는 것보다 덜 알려졌지만 더 고약한 쪽이 위조(spoofing)다. 사람이 쓴 글에 워터마크 패턴을 심어 "이건 AI가 만든 것"으로 보이게 만드는 공격이다. 워터마크된 출력을 많이 모아 어떤 낱말이 초록에 자주 걸리는지 통계를 내면, 키를 몰라도 초록 쪽 낱말을 골라 쓰는 식으로 흉내 낼 여지가 생긴다.

이 공격이 성립하면 워터마크의 쓸모가 뒤집힌다. 남의 글을 AI 생성물로 몰아 신뢰를 떨어뜨리는 데 쓸 수 있기 때문이다. 검출이 강한 증거라는 앞의 이야기는 "키가 새지 않았고 위조가 어렵다"는 전제 위에서만 성립한다.

워터마크를 지우는 공격과 심는 공격

C2PA 출처 메타데이터

워터마킹이 결과물 자체에 신호를 넣는다면, 다른 길은 파일에 이력을 붙이는 것이다.

매니페스트와 서명

C2PA(Coalition for Content Provenance and Authenticity)는 Adobe, Microsoft, Google 등이 참여하는 미디어 출처 표준이다. 파일에 매니페스트를 붙이는데, 그 안에는 어떤 도구가 만들었는지, 어떤 모델을 썼는지, 그 뒤 어떤 편집이 있었는지가 항목으로 들어가고 전체에 디지털 서명이 걸린다.

{
  "c2pa": {
    "assertions": [{
      "label": "c2pa.ai.generative",
      "data": {
        "prompt": "a photorealistic cat in space",
        "model": "stable-diffusion-xl-1.0",
        "generator": "Adobe Firefly",
        "timestamp": "2026-05-25T10:30:00Z"
      }
    }],
    "signature": {
      "algorithm": "ES256",
      "cert": "...(Adobe 인증서)..."
    }
  }
}

서명이 있으므로 내용이 한 글자라도 바뀌면 검증이 깨진다. 편집을 하면 새 매니페스트가 앞의 것을 참조하며 얹혀, 원본에서 지금까지의 사슬이 만들어진다. Photoshop, Premiere Pro, Bing Image Creator 등에서 이미 붙어 나온다.

사슬의 단절

문제는 이 사슬이 파일 밖에 있는 정보에 의존하지 않는다는 데서 온다. 매니페스트는 파일에 얹힌 부가 데이터라 떼어 내기가 쉽다. 스크린샷을 찍으면 화면의 화소만 남고 사라진다. 메타데이터를 벗겨 내는 업로드 파이프라인을 지나도 사라진다. 이미지를 다른 형식으로 다시 저장하는 것만으로도 끊긴다.

더 나쁜 것은 끊긴 상태와 원래 없던 상태가 구별되지 않는다는 점이다. 매니페스트가 없는 이미지를 보고 "AI가 만들었는데 지웠다"인지 "사람이 찍은 사진이라 원래 없다"인지 알 수 없다. 워터마크의 비대칭과 똑같은 문제가 여기서도 반복된다. 있으면 강한 증거, 없으면 아무 증거도 아니다.

워터마크와의 결합

그래서 두 기술은 경쟁 관계가 아니라 짝이다. 메타데이터는 풍부한 이력을 담을 수 있지만 잘 떨어져 나가고, 워터마크는 담을 수 있는 정보가 훨씬 적지만 콘텐츠에 붙어 다닌다. 둘을 같이 쓰면 매니페스트가 떨어져 나간 파일에서도 워터마크로 "이건 어느 계열의 출력"까지는 되찾고, 그 실마리로 원래 이력을 다시 이어 붙일 수 있다.

C2PA 매니페스트 사슬과 단절

여기에 하나 더 얹는 방식이 지문(fingerprint)이다. 콘텐츠 자체의 특징을 계산해 원본 데이터베이스와 대조하는 것이라, 심는 것이 아니라 대조하는 방식이다. 세 갈래를 겹쳐 두면 하나가 깨져도 나머지가 남는다. 다만 어느 조합도 "표식을 남길 위치에 있는 사업자"의 출력만 덮는다는 근본 제약은 그대로다.

운용의 한계

기술의 정밀도보다 이 절이 실무에서 더 중요하다. 워터마크는 대개 성능이 모자라서가 아니라 쓰는 방식이 틀려서 사고를 낸다.

오탐의 비용

워터마크 없이 통계만으로 AI 생성을 판정하는 탐지기는 오탐이 고질이다. OpenAI가 자사 AI 텍스트 탐지기를 서비스 종료한 이유도 정확도가 실사용을 못 견뎠기 때문이다. 특히 모국어가 아닌 사람이 쓴 글, 형식이 정형화된 문서, 짧은 답변에서 사람 글을 AI로 잘못 짚는 일이 잦았다.

워터마크 검출은 훨씬 정밀하지만 규모를 곱하면 얘기가 달라진다. 앞에서 z 4의 오탐률을 십만분의 삼으로 잡았다. 학교 하나가 한 학기에 과제 10만 건을 돌리면 기대 오탐이 세 건이다. 그 세 건이 "표절 의심 통보"로 나가면 세 사람이 자기가 안 한 일을 해명해야 한다. 통계적으로 훌륭한 수치가 사람에게는 그렇지 않다.

그래서 임계값은 기술이 아니라 결과가 정한다. 콘텐츠에 라벨을 붙이는 용도라면 z 3쯤에서 넓게 잡아도 되지만, 징계나 계정 정지처럼 되돌리기 어려운 조치에 쓸 것이라면 훨씬 보수적으로 잡고 사람의 확인을 끼워야 한다.

판정과 추정

문구 하나가 실제로 중요하다. "AI가 생성한 콘텐츠입니다"와 "이 콘텐츠에서 특정 모델의 워터마크가 검출됐습니다"는 다른 문장이다. 앞의 것은 판정이고 뒤의 것은 관측이다. 시스템이 내보내도 되는 것은 뒤쪽이다.

앞의 문장을 쓰는 순간 두 가지 책임이 따라온다. 워터마크가 없는 AI 콘텐츠를 "AI 아님"으로 잘못 통과시킨 책임과, 오탐 한 건에 대해 판정 주체가 된 책임이다. 관측을 관측으로 적어 두면 이 둘 다 애초에 발생하지 않는다. 안전 장치 설계에서 반복되는 원칙이며 AI 안전 개요에서 다룬 것과 같은 맥락이다.

기술과 제도의 간격

정리하면 지금 워터마킹으로 할 수 있는 일은 좁다. 워터마크를 넣는 사업자의, 충분히 긴 출력이, 크게 변형되지 않은 채 도착했을 때, 그것이 그 사업자를 거쳤다는 것을 높은 확신으로 말할 수 있다. 그 밖의 경우는 전부 모른다.

한편 제도가 요구하는 것은 "AI 콘텐츠에 표시하라"는, 훨씬 넓은 문장이다. 이 간격은 기술이 조금 더 좋아진다고 메워지지 않는다. 워터마크를 안 넣는 공개 가중치 모델이 계속 나오고, 그 모델을 자기 컴퓨터에서 돌리는 사람에게 표식을 강제할 방법이 없기 때문이다.

그래서 현실적인 위치는 이렇다. 워터마킹은 완벽한 탐지 수단이 아니라 책임 추적의 도구다. 대형 사업자의 출력에 꼬리표를 붙여 두면 문제가 생겼을 때 어디서 나왔는지 되짚을 수 있고, 그 사업자가 자기 모델의 오남용을 확인할 수 있다. 세상의 모든 AI 콘텐츠를 걸러 내는 그물이 아니라, 표식을 남기기로 한 쪽이 자기 몫을 증명하는 장치로 이해하는 편이 맞다.


읽어주셔서 감사합니다. 😊

LATEST

AI 기초의 최신 글

AI 기초2026.08.19

가드레일을 테스트한다는 것

가드레일 테스트는 단위 테스트와 성질이 다릅니다. 세트를 두 벌로 나누는 이유, 통과 기준을 절대값 대신 기준선으로 잡는 법, 세트가 오염되는 경로, 표본 크기가 결정에 미치는 영향을 정리합니다.

43 MIN
AI 기초2026.08.19

거절도 설계한다: 안 된다고 말하는 법

거절은 안전 장치의 마지막 동작이면서 사용자가 제품을 평가하는 순간입니다. 켜고 끄는 스위치 대신 다섯 칸 사다리를 쓰는 법, 좋은 거절 문구의 조건, 과잉 거절을 재는 방법을 정리합니다.

41 MIN
AI 기초2026.08.19

콘텐츠 조정: 정책을 판정 가능한 것으로 만들기

정책 문서가 있어도 판정은 안 됩니다. 두 사람이 같은 라벨을 붙일 수 있게 정책을 쪼개는 법, 임계값을 둘로 두는 이유, 검토 큐가 터지지 않게 설계하는 법, 라벨마다 따로 봐야 하는 지표를 정리합니다.

50 MIN