AI 에이전트 파이프라인에 출처 추적이 필요한 이유

워터마크가 편집 한 번에 사라진다. OpenAI는 EU AI Act 준수를 위해 ChatGPT와 Codex 텍스트에 보이지 않는 워터마크를 심겠다고 밝혔는데, 동시에 "편집이 많아지면 마크를 탐지하기 어려워진다"고 스스로 인정했다.

이 뉴스의 진짜 시사점은 EU 규제 이야기가 아니다. LLM 에이전트를 실무 파이프라인에 붙여 돌리는 팀이라면 다른 질문으로 읽어야 한다. 당신의 에이전트가 만든 결과물 — 6개월 뒤에 다시 꺼냈을 때 무엇이 AI 생성이고 무엇이 사람 편집인지 구분할 수 있는가?

해법은 단순하다. 모델명, 프롬프트 버전, 검수 상태. 이 세 가지를 기록하면 된다. 다만 "기록만 하면 끝"이 아니다. 어느 시점에 어떤 형태로 남기느냐에 따라, 나중에 쓸 수 있는 증거가 되기도 하고 그냥 쌓여 있는 로그 더미가 되기도 한다.

에이전트를 붙이고 나서 맞닥뜨리는 첫 번째 벽

LLM 에이전트를 업무에 처음 연결할 때 집중하는 건 늘 같다. 프롬프트 품질, 출력 속도, API 비용. 그러면서 "이 출력이 나중에 어떻게 추적될 것인가"는 설계 밖으로 밀려난다.

어떤 모델이 어떤 프롬프트로 언제 이 텍스트를 만들었는지 — 이 정보가 없으면 오류를 재현할 수가 없다. 단건으로 보면 그냥 "이상한 글" 하나지만, 생성 이력이 있으면 "이 프롬프트 버전이 나간 날부터 반복되는 패턴"으로 읽힌다. 패턴을 잡아야 고칠 수 있다.

소규모 팀일수록 이 문제가 빨리 터진다. 엔지니어가 1~2명이라 에이전트에 많은 것을 맡기는데, 에이전트가 무엇을 어떻게 처리했는지 기록이 없으면 운영이 아니라 운에 맡기는 거다.

OpenAI 워터마킹이 실제로 알려주는 것

EU AI Act는 고위험 AI 시스템에 "AI 생성 콘텐츠임을 표시"할 의무를 부과한다. OpenAI의 방식은 텍스트에 통계적 패턴을 심는 것 — 단어 선택 분포를 미묘하게 조정해 눈에 보이지 않는 마크를 남긴다.

문제는 탐지율이다. 원문 그대로라면 탐지가 가능하지만, 번역·요약·패러프레이징이 한 번 들어가면 마크가 흐려진다. 2024년 Maryland 대학의 연구에서 패러프레이징 공격 하나만으로 워터마크 탐지율이 92%에서 27%로 떨어졌다. OpenAI가 스스로 인정한 "편집에 취약하다"는 말과 정확히 맞닿아 있다.

이건 단순한 기술적 한계가 아니다. 에이전트 파이프라인 설계에 대한 신호다. 텍스트 안에 증거를 숨기는 방식은 구조적으로 취약하다. 신뢰할 수 있는 추적 수단은 콘텐츠 외부에, 파이프라인 레벨에서 별도로 남겨야 한다.

우리가 실제로 겪은 추적 불가 상황

우리 팀도 콘텐츠 자동화 파이프라인을 운영하면서 비슷한 벽을 만났다. 여러 사이트에 LLM이 생성한 글을 자동 발행하는 구조인데, 초기엔 발행 후에 어떤 모델이 어떤 프롬프트로 해당 글을 만들었는지 추적이 안 됐다.

처음엔 "글이 잘 나오면 됐지"라고 생각했는데, 특정 유형의 오류가 며칠 간격으로 반복되는 걸 보면서 생각이 바뀌었다. 문제가 터지면 발행 이력 전체를 뒤지고, 어떤 프롬프트 변경이 그 패턴을 만들었는지 역추적하는 데 한참 걸렸다. 기록이 아예 없어서가 아니라, 기록이 파이프라인의 엉뚱한 시점에 남겨져 있어서였다.

지금은 Discord 검수 루프를 거치며 각 글의 생성 모델·프롬프트 버전 해시·검수 타임스탬프가 DB에 남는다. 문제가 생기면 해당 글의 생성 조건을 5분 안에 재현할 수 있고, 어느 단계에서 내용이 바뀌었는지도 확인이 된다. 이 구조를 갖추기 전과 후는 운영 밀도가 완전히 다르다.

파이프라인에 출처 추적을 심는 실전 방법

복잡하게 설계할 필요 없다. 세 가지 기록이면 충분하다.

생성 시점 메타데이터: LLM 호출 결과를 저장할 때 모델명, 프롬프트 버전(해시 또는 태그), 생성 타임스탬프를 반드시 함께 기록한다. DB 테이블에 컬럼 세 개를 추가하는 것으로 끝이다. 이 세 가지가 있으면 6개월 뒤에도 재현이 된다.

사람 개입 시점 표시: 에이전트 출력을 사람이 수정했다면 "편집됨" 상태를 명시적으로 기록한다. OpenAI 워터마킹이 편집에 취약한 이유가 여기에도 있다 — 편집이 일어났다는 사실 자체가 의미 있는 정보다. 콘텐츠 내부에 증거를 숨기는 것보다 파이프라인 메타데이터가 훨씬 신뢰할 수 있는 출처 증거다. "AI 생성 → 검수 완료 → 편집됨" 세 단계 상태값만 있어도 이력 재구성이 가능하다.

검수 단계를 파이프라인의 일부로 공식화: "에이전트가 빠르게 뽑으니까" 검수를 생략하면 속도는 나오지만 감사 이력이 남지 않는다. 검수 단계 자체가 "이 시점에 사람이 확인했다"는 로그다. 빠르게 돌리는 것과 감사 가능한 구조는 서로 배타적이지 않다.

지금 바로 실행할 수 있는 것

EU AI Act는 당장 한국 팀에 직접 적용되지 않는다. 하지만 AI 생성 콘텐츠에 대한 표시·추적 의무가 EU에서 시작해 어떤 형태로든 확산될 거라는 방향은 이미 정해졌다.

가장 빠른 첫 단계는 이렇다. LLM 출력을 저장하는 테이블에 컬럼 두 개를 추가한다. ai_model VARCHAR(50), prompt_version VARCHAR(20). 기존 로직은 건드리지 않고, 마이그레이션도 없다. 이 두 컬럼이 있고 없고는 6개월 뒤 오류 대응 속도에서 체감으로 차이가 난다.

그다음은 상태값이다. 워터마킹이 편집 한 번에 흐려지듯, 콘텐츠 내부에만 의존하는 추적은 구조적으로 취약하다. 파이프라인 외부에 상태를 명시적으로 남기는 것 — 그게 OpenAI가 텍스트에 마크를 심으면서도 결국 해결하지 못한 부분을 우리가 직접 채우는 방법이다.

원문: AI News & Artificial Intelligence | TechCrunch