DEVOCEAN

공개 웹과 오픈소스 저장소의 운영 환경이 빠르게 변하고 있습니다. 최근 ChatGPT가 New Yorker 스타일의 만화를 생성하면서 실제 기고 만화가의 고유 서명까지 임의로 복제해 붙인 사례가 확인되었으며, 피해가 확인된 만화가만 15명을 넘어섰습니다. 동시에 Wikimedia 재단은 OpenAI가 운영한 것으로 추정되는 AI 에이전트의 무승인 편집과 침입 시도, 대량 데이터 수집을 공식 확인했습니다. 수백만 건의 페이지 요청과 수십만 건의 Wikidata 쿼리가 인프라로 쏟아졌습니다.

이 사건들은 독립적인 해프닝이 아닙니다. 자동화된 AI 에이전트가 통제되지 않은 채 데이터를 긁어가고 원작자의 고유 식별자를 무단 복제하면서, 공개 플랫폼을 운영하던 진영은 진입로를 차단하고 있습니다. 대표적인 프레임워크 저장소인 laravel/laravel이 GitHub Issues 탭을 완전히 닫은 결정 역시 노이즈성 트래픽과 관리되지 않는 피드백 유입을 통제하려는 흐름과 맞닿아 있습니다.

오픈소스 플랫폼과 지식 저장소가 자동화된 수집과 생성 에이전트의 오남용에 직면하면서, 소프트웨어 생태계는 개방적 진입로를 닫고 접근 통제 경계를 강화하는 방향으로 선회하고 있습니다. 본 글에서는 무단 수집과 식별자 복제가 발생시킨 문제를 짚어보고, API 및 저장소 차원에서 구축해야 할 통제 전략을 살펴봅니다.

15명 이상의 서명 복제: 생성 결과물이 드러낸 데이터 분리의 한계

ChatGPT가 잡지 New Yorker 화풍의 카툰을 생성하는 과정에서 실제 작가들의 서명을 그대로 이미지 구석에 그려 넣은 사실이 밝혀졌습니다. 원문 발췌에 따르면 허가나 보상 없이 서명이 사용된 만화가는 확인된 사례만 15명을 넘었습니다.

시각 예술과 출판 영역에서 작가의 서명은 단순한 그림의 일부가 아닙니다. 해당 작업물이 특정 저작자에 의해 창작되었음을 보증하는 고유 식별자(Identifier)이자 진위 확인 수단입니다. 모델이 이미지의 화풍(Style)을 학습하는 것을 넘어 작가의 고유 서명 텍스트까지 픽셀 형태로 재현했다는 것은, 학습 파이프라인에서 저작권 표식과 본문 데이터가 분리되지 않았음을 보여줍니다.

이 현상에 대한 DEVOTEE의 판단은 다음과 같습니다. 생성 모델의 저작권 제어 능력은 과대평가된 면이 있습니다. 모델이 데이터를 학습하고 변환하는 과정에서 저작권 표식이나 서명 같은 메타데이터를 식별해 배제하지 못하고 있으며, 결과물에 타인의 서명을 무단 삽입하여 법적·윤리적 위험을 서비스 운영자에게 전가하고 있습니다.

실무 개발자 관점에서도 데이터 파이프라인 설계에 직접적인 경고를 줍니다. RAG(검색 증강 생성)나 이미지·텍스트 생성 파이프라인을 구축할 때, 원본 데이터의 메타데이터(작성자 이름, 라이선스 고지, 내부 문서 ID)가 모델의 프롬프트나 출력에 정제되지 않고 섞여 들어가면 식별자 오염이 발생합니다. 모델 자체의 필터링에 의존하기보다 입력과 출력 양단에서 정규식 및 식별자 검증 레이어를 두어야 합니다.

수백만 건의 무승인 쿼리: Wikimedia가 맞닥뜨린 에이전트 트래픽

Wikimedia 재단은 자체 조사를 통해 OpenAI가 운영한 것으로 추정되는 AI 에이전트가 위키미디어 API와 Wikidata에 비정상적인 대규모 접근을 시도했음을 공개했습니다. 에이전트들은 API에 수백만 건의 요청을 보내고 수백만 페이지를 수집했으며, Wikidata 엔드포인트에 수십만 건의 쿼리를 실행했습니다.

Wikimedia는 전 세계 누구나 자유롭게 지식을 읽고 기여할 수 있도록 개방형 API를 유지해 왔습니다. 하지만 통제되지 않은 에이전트가 사전 조율 없이 무차별적인 크롤링과 무승인 편집을 시도하면서 인프라 자원을 잠식했습니다. 일반 사용자의 브라우징 요청과 달리, 에이전트의 SPARQL 쿼리나 그래프 탐색은 데이터베이스에 높은 부하를 발생시킵니다.

이 소식에 대한 DEVOTEE의 판단은 이렇습니다. 개방형 API를 운영하는 서비스라면 에이전트 전용 차단 및 식별 정책을 지금 도입해 볼 만합니다. '로봇 배제 표준(robots.txt)'이나 단순한 IP 레이트 리밋(Rate Limit)만으로는 자율 동작하는 에이전트의 분산 수집을 막기 어렵기 때문입니다.

공개 웹 서비스를 운영하는 팀이라면 User-Agent 기반 차단을 넘어 토큰 기반 요청 검증, 비정상적인 쿼리 패턴 감지, 에이전트 전용 격리 엔드포인트 분리를 고려해야 합니다.

이슈 탭을 닫은 Laravel: 개방 채널의 유지보수 한계

프레임워크 저장소인 laravel/laravel은 GitHub Issues 탭을 비활성화했습니다. 프레임워크 창시자인 Taylor Otwell이 주도한 이 조치로 인해, 저장소 방문자는 더 이상 이슈를 직접 등록할 수 없습니다.

오픈소스 프로젝트에서 GitHub Issues는 버그 리포트와 기능 제안을 받는 핵심 창구였습니다. 하지만 AI 기반 코드 생성 도구의 보급과 함께 정제되지 않은 오류 로그, 자동 생성된 재현 불가능한 이슈, 단순 질문이 쏟아지면서 메인테이너의 검토 비용이 감당하기 어려운 수준으로 늘어났습니다.

이 조치에 대한 DEVOTEE의 판단은 조건부로 유효하다는 것입니다. 검증되지 않은 외부 입력을 차단하여 핵심 개발 역량을 PR(Pull Request) 검토와 코드베이스 개선에 집중시키는 현실적인 대응입니다. 다만 피드백 채널을 완전히 차단하면 실제 버그를 발견한 일반 사용자의 진입 장벽이 높아지므로, Discussions나 공식 포럼 같은 2차 필터링 채널을 연계해야 합니다.

소프트웨어 개발 전반에서 "모두에게 열린 입력 창구"는 더 이상 기본값이 아닙니다. 검증 계층이 없는 개방형 창구는 에이전트와 자동화 스크립트의 노이즈에 쉽게 노출됩니다.

실무 적용: FastAPI와 Redis를 활용한 에이전트 트래픽 제어

Wikimedia 사례처럼 무차별적인 에이전트 수집을 방지하려면, 애플리케이션 게이트웨이 단계에서 에이전트의 접근을 분류하고 토큰 버킷 기반으로 요청을 제어해야 합니다.

아래는 Python의 FastAPI와 redis-py를 사용하여 비정상적인 에이전트 쿼리를 식별하고 엔드포인트별로 요청 한도를 강제하는 미들웨어 예시입니다.

from fastapi import FastAPI, Request, HTTPException, status
import redis.asyncio as redis
import time

app = FastAPI()
redis_client = redis.from_url("redis://localhost:6379", decode_responses=True)

# 에이전트 식별자 및 비정상 User-Agent 목록
BLOCKED_AGENTS = ["unauthorized-crawler", "ai-scraper-bot"]
AGENT_RATE_LIMIT = 5  # 초당 최대 요청 수
AGENT_WINDOW_SECONDS = 60

@app.middleware("http")
async def enforce_agent_traffic_policy(request: Request, call_next):
    user_agent = request.headers.get("user-agent", "").lower()
    client_ip = request.client.host if request.client else "unknown"
    
    # 1. 차단 대상 에이전트 헤더 검증
    if any(agent in user_agent for agent in BLOCKED_AGENTS):
        raise HTTPException(
            status_code=status.HTTP_403_FORBIDDEN,
            detail="Unauthorized AI agent access is blocked."
        )
    
    # 2. 에이전트로 식별되거나 특정 쿼리 엔드포인트 접근 시 레이트 리밋 검증
    if "agent" in user_agent or request.url.path.startswith("/api/v1/query"):
        current_minute = int(time.time() // AGENT_WINDOW_SECONDS)
        rate_limit_key = f"rl:agent:{client_ip}:{current_minute}"
        
        # Redis 트랜잭션으로 요청 수 증가 및 만료 시간 설정
        async with redis_client.pipeline(transaction=True) as pipe:
            pipe.incr(rate_limit_key)
            pipe.expire(rate_limit_key, AGENT_WINDOW_SECONDS + 10)
            results = await pipe.execute()
            
        request_count = results[0]
        if request_count > (AGENT_RATE_LIMIT * AGENT_WINDOW_SECONDS):
            raise HTTPException(
                status_code=status.HTTP_429_TOO_MANY_REQUESTS,
                detail="Rate limit exceeded for automated queries."
            )
            
    response = await call_next(request)
    return response

@app.get("/api/v1/query")
async def execute_query(q: str):
    return {"status": "success", "result": f"Executed query for: {q}"}

이 코드는 User-Agent 헤더 검증과 함께 시간 윈도우 기반 Redis 카운터를 사용하여 단일 IP에서 발생하는 고밀도 쿼리를 차단합니다. 실무에서는 IP 스푸핑에 대응하기 위해 서명된 API 키 인증을 필수화하고, 응답 본문에 서명 워터마크를 포함시키는 방식을 함께 적용해야 합니다.

도입 전 확인할 것: 에이전트 접근 제어와 채널 관리 점검표

개방형 인터페이스를 운영 중인 팀이 에이전트 오남용과 인프라 부하에 대응하기 전에 점검해야 할 항목입니다.

• [ ] 공개 엔드포인트의 쿼리 복잡도 제한: GraphQL, SPARQL, 검색 API에 중첩 깊이 및 CPU 실행 시간 상한이 걸려 있는가?
• [ ] 에이전트 트래픽 격리: 일반 사용자 세션과 봇/에이전트 트래픽이 동일한 인스턴스 풀을 공유하여 서비스 장애를 유발하고 있지 않은가?
• [ ] 생성 파이프라인 식별자 누출 방지: LLM 파이프라인의 프롬프트와 컨텍스트에서 저작권 서명, 개인정보, 기밀 메타데이터를 정규식으로 마스킹하고 있는가?
• [ ] 오픈소스 저장소 진입로 필터링: GitHub Issues에 무분별한 오류 로그가 쌓이지 않도록 Issue Form 템플릿 강제 또는 Discussions 선행 구조를 마련했는가?

그 밖의 소식

• Hack에서 Skip까지: 모든 것을 증분 처리하기 — Facebook이 수천만 줄 PHP 코드의 타입 검사 속도를 개선하기 위해 도입한 증분 처리 전략입니다.
• Opus 5.5 에이전트, 차세대 메모리용 상온 자성 반도체 후보 두 가지 발견 — AI 에이전트와 연구진이 계산을 통해 전자를 스핀별로 구분할 수 있는 반도체 화합물 후보를 도출했습니다.
• 무신사 웨이팅이 GPS 오차와 싸운 기록 — 오프라인 매장 대기 서비스에서 태블릿을 제거하고 모바일 GPS 오차를 보정한 엔지니어링 기록입니다.