제9부 사업·전략·법·윤리

9.3 법·규제·저작권·프라이버시

법을 다루는 장에서 가장 먼저, 가장 크게 명시해야 할 문장이 있다. 이 장은 법률 자문이 아니다. 여기 적힌 어떤 문장도 "이렇게 하면 합법"이라는 보증이 아니며, 그렇게 읽는 순간 이 장은 위험한 문서가 된다. 이 장의 목적은 하나다 — LLM 시스템을 만들고 운용하는 엔지니어·창업자·아키텍트가 법적 리스크가 어디에 얼마나 걸려 있는지 지도를 그리고, 무엇을 자격 있는 변호사·법무·컴플라이언스에게 물어야 하는지를 알게 하는 것. 구체적 판단은 반드시 관할(jurisdiction)의 자격 있는 변호사에게 받아야 한다.

왜 이렇게까지 조심하는가. 이 분야에는 확정된 답이 드물기 때문이다. 같은 행위라도 어느 나라 법을 적용하느냐에 따라 합법과 침해가 갈리고, 몇 달 단위로 판례·규제가 바뀌며, 지금 세계 각지에서 다수의 소송이 진행 중이라 결론 자체가 미확정이다. 그래서 이 장은 특정 판결·조문·과징금 숫자를 골격으로 삼지 않는다. 이 글을 읽는 시점에 그 숫자는 이미 달라졌을 가능성이 높다. 골격으로 삼는 것은 변하지 않는 리스크의 구조 — 어느 단계에서 무슨 종류의 노출이 켜지고, 무엇을 문서화해 두면 방어 가능성이 높아지는가 — 이다. 개별 사실은 반드시 현재 시점의 1차 자료와 법률 자문으로 확인하라. 이 문장을 이 장은 여러 번 되풀이할 것이다. 지겨울 만큼 되풀이하는 것이 정직한 태도이기 때문이다.

엔지니어에게 법은 흔히 "출시 직전에 튀어나오는 장애물"로 보인다. 실제로는 정반대다. 저작권·프라이버시·규제는 데이터를 처음 수집하는 순간부터 로그를 파기하는 순간까지 라이프사이클 전 구간에 스며 있는 설계 변수다. 나중에 붙이려 하면 이미 학습한 모델과 이미 쌓인 로그를 되돌릴 수 없어 훨씬 비용이 커진다 — 사전학습 데이터에서 본 "필터는 사후에 되돌릴 수 없다"의 법률판이다(2.1). 그래서 이 장은 주제별("저작권", "프라이버시")이 아니라 라이프사이클별로 리스크를 읽는 렌즈부터 세운다.

9.3.1 라이프사이클 법적 리스크 지도

리스크를 저작권·프라이버시·규제·계약처럼 주제별로만 나눠 보면 실무에서 자꾸 놓친다. 이유는 단순하다 — 같은 데이터 한 조각이 네 축에 동시에 걸리기 때문이다. 크롤로 긁어 온 뉴스 기사 하나는 저작권(기자·언론사의 권리)이면서, 그 기사에 실린 인물의 개인정보(프라이버시)이면서, 사이트 약관 위반(계약)이면서, 그것으로 학습한 모델이 고위험 용도에 쓰이면 규제 대상이다. 주제별 체크리스트로는 이 겹침이 안 보인다.

더 쓸모 있는 렌즈는 데이터가 시스템을 통과하는 각 단계에서 새로 켜지는 노출을 묻는 것이다.

파이프라인 자체는 밋밋하다. 중요한 것은 각 화살표를 지날 때마다 새로운 법적 축이 켜진다는 것, 그리고 화살표 하나가 앞으로만 가지 않는다는 것이다. ⑤ 로그가 ②로 되돌아가는 재학습 플라이휠(8.1)이 이 장에서 가장 위험한 지점이다. 사용자 프롬프트를 재학습에 쓰는 순간, 서비스 단계의 프라이버시·동의 문제가 학습 데이터의 저작권·PII 문제와 합선된다. 서비스팀이 "로그를 모아 모델을 개선하자"고 무심코 켠 스위치 하나가, 법적으로는 새 학습 데이터셋을 무동의로 구축한 것과 같아질 수 있다.

이 표는 각 항목의 합법·불법 판정이 아니라 어디에 무엇이 걸리는가의 유형 지도다. 같은 행위라도 관할·사실관계·시점에 따라 결론이 갈린다는 단서는 표의 모든 칸에 붙어 있다고 보면 된다. 이제 각 단계를 심층 분석하되, 늘 "이것은 미확정이고 관할에 따라 다르다"를 전제로 삼고 간다.

9.3.2 "공개돼 있음"은 라이선스가 아니다 — 학습 데이터 저작권의 구조

가장 격렬한 전선이다. 저작권 있는 텍스트·이미지·코드를 허락 없이 학습에 쓰는 것이 침해인가. 이 질문에 전 세계적으로 합의된 답은 없다. 그런데 엔지니어들 사이에는 이 질문을 아예 지워 버리는 통념이 널리 퍼져 있다 — "웹에 공개돼 있으니 써도 된다."

이 통념은 정확히 틀렸고, 왜 틀렸는지가 이 절의 핵심이다. 공개는 라이선스가 아니다. 블로그 글, 뉴스 기사, 사진, 오픈소스 코드는 대부분 저작권으로 보호된다. 누군가 글을 웹에 게시했다는 것은 "사람이 브라우저로 읽을 수 있게 뒀다"는 뜻이지, "복제해서 학습시켜도 된다"고 허락한 것이 아니다. 저작권은 대다수 관할에서 창작과 동시에 자동으로 발생한다 — 등록도, ⓒ 표시도 필요 없다. 그래서 크롤러가 긁어 온 텍스트의 절대다수에는 누군가의 권리가 이미 붙어 있고, "권리 없음"이 아니라 "권리자를 특정하기 어려움"일 뿐이다. 이 둘은 법적으로 전혀 다르다. 권리자를 못 찾겠다는 사실이 권리가 없다는 뜻이 되지는 않는다.

학습이 저작권과 부딪히는 지점을 물리적으로 따라가 보면 최소 세 곳에서 복제가 일어난다. 첫째, 수집 단계에서 크롤·다운로드는 그 자체로 원저작물의 복제다 — 서버의 바이트를 내 디스크로 옮기는 순간 복제권에 닿는다. 둘째, 학습 파이프라인 중간에서 정제·중복제거·토큰화를 거치며 저작물이 재차 복제·변환된다. 셋째, 출력 단계에서 모델이 학습 데이터를 암기(2.1)해 거의 그대로 출력하면, 이번엔 산출물이 2차적 침해가 된다. 논쟁의 초점은 주로 첫째·둘째의 대량 복제가 정당화되는가에 있지만, 셋째 — 산출물이 원본을 재현하는 경우 — 는 별개의 문제로 뒤(9.3.6)에서 다시 켜진다.

여기서 방향이 갈린다. 관할마다 이 세 복제를 정당화하는 장치가 다르고, 그 장치의 이름과 작동 방식이 미국과 EU에서 근본적으로 다르다. 그래서 "학습이 합법이냐"는 질문은 관할을 특정하지 않으면 애초에 성립하지 않는다.

9.3.3 미국 공정이용 — 판결이 아직 없는 전선

미국법의 초점은 공정이용(fair use)이다. 저작권자의 허락 없이도 특정한 이용을 허용하는 예외이고, 법원은 대략 네 가지 요소를 비교 평가해 판단한다. 이 네 요소는 조문에 열거돼 있지만 가중치는 판례로 형성되며, AI 학습이라는 새 맥락에서 그 가중치가 어떻게 정해질지가 바로 지금 다투어지고 있다.

첫째, 이용의 목적과 성격 — 특히 그 이용이 "변형적(transformative)"인가, 즉 원저작물과 다른 목적·의미·표현을 만들어 내는가. 둘째, 저작물의 성격 — 사실적 저작물인가 창작적 저작물인가(창작적일수록 보호가 두텁다). 셋째, 이용한 양과 실질성 — 얼마나, 그리고 핵심 부분을 가져왔는가. 넷째, 그리고 실무에서 가장 크게 작용하는 원저작물 시장에 미치는 영향 — 이 이용이 원본의 시장을 대체해 잠식하는가.

AI 학습을 옹호하는 쪽은 이렇게 논증한다. 학습은 개별 저작물을 복제해 그대로 되파는 것이 아니라 통계적 패턴을 추출하는 것이라 고도로 변형적이고, 완성된 모델은 특정 기사·그림 하나의 대체재가 아니라는 것이다. 반대쪽은 이렇게 받아친다. 이것은 상업적 목적의 대량 복제이고, 산출물이 실제로 뉴스·삽화·스톡이미지·코드의 시장을 직접 대체하며(넷째 요소), 모델이 원본을 재현할 수 있다는 사실 자체가 "패턴만 배웠다"는 항변을 약화시킨다는 것이다.

두 논증 중 어느 쪽이 이기는가. 이 책은 그 질문에 답하지 않는다. 저자·언론사·이미지 권리자·프로그래머 등이 주요 AI 기업을 상대로 제기한 여러 소송이 여러 관할에서 진행 중이고, 초기 판단들은 "어떤 데이터를, 어떻게 얻어, 무엇을 출력했는가"라는 구체적 사실관계에 크게 의존해 서로 다른 방향을 가리킨다. 확정된 일반 규칙은 없다. 그리고 설령 어느 하급심 판결이 한쪽 손을 들어 줬더라도, 그것으로 "이제 학습은 합법(또는 불법)으로 정리됐다"고 말하는 것은 위험하다 — 판결은 항소로 뒤집히고, 입법으로 무력화되며, 사실관계가 조금만 달라도 결론이 갈린다. 누가 이겼다는 식의 서술을 이 장이 하지 않는 이유다. 최신 상태는 반드시 현재 시점의 1차 자료와 관할 변호사로 확인해야 한다.

엔지니어에게 실무적으로 중요한 것은 승패의 예측이 아니라 넷째 요소가 설계에 주는 함의다. 산출물이 원본 시장을 직접 대체할수록 공정이용 방어가 어려워진다면, "학습 데이터에 있는 특정 저작물을 거의 그대로 재현하는" 시스템은 법적으로 가장 취약한 형태다. 그래서 암기·재현을 줄이는 기술적 조치(중복제거, 출력 필터)는 품질 문제일 뿐 아니라 법적 리스크 완화이기도 하다. 반대로 "유명 작가 스타일로", "이 캐릭터를 그려" 같은 프롬프트를 조장하는 제품은 스스로 넷째 요소의 함정에 빠지게 만든다.

9.3.4 EU TDM·opt-out과 관할별 지형

유럽은 완전히 다른 틀을 쓴다. 미국이 사후에 법원이 네 요소를 비교 평가하는 판례법 방식이라면, EU는 성문 규정으로 텍스트·데이터 마이닝(Text and Data Mining, TDM) 예외를 미리 정해 두었다. EU 저작권 지침(DSM Directive)은 적법하게 접근한 저작물에 대한 데이터 마이닝을 일정 조건에서 허용한다. 그런데 핵심 반전이 있다 — 상업적 TDM의 경우 권리자가 기계 판독 가능한 방식으로 opt-out(이용 유보)을 선언하면 그 저작물을 제외할 수 있다. 연구 목적의 TDM에는 별도의 더 넓은 예외가 있고, 조건·해석의 세부는 계속 다듬어지는 중이다.

이 opt-out 장치가 EU에서 실무 쟁점 전체를 바꾼다. 미국에서는 "이 이용이 변형적인가"를 사후에 다투지만, EU에서는 "권리자가 학습 거부 의사를 기계가 읽을 수 있게 밝혔는가"가 앞선다. 그래서 EU를 겨냥한 데이터 파이프라인은 수집 단계에서 opt-out 신호(예: robots.txt, TDM 유보를 나타내는 메타데이터·헤더)를 탐지하고 존중하며 그 사실을 기록하는 것이 방어의 핵심이 된다. 그 신호의 정확한 형식·범위가 무엇으로 인정되는지는 아직 논쟁적이라, "무엇이 유효한 opt-out인가" 자체가 다투어진다.

관할별 성격을 한눈에 비교하면 아래와 같다. 다만 이 표의 모든 칸은 일반화된 개관이고, 정확한 조문·조건·최신 개정은 관할별로 확인해야 한다 — 특히 AI 관련 조항은 지금 이 순간에도 개정되는 중이다.

여기서 한 가지 함의가 곧장 나온다. 학습과 서비스를 어느 관할에서 하느냐가 허용 범위를 바꾼다. 일본에서 적법하게 학습한 것이 EU 권리자의 opt-out을 무시했다면 EU에서 문제가 될 수 있고, 미국 공정이용에 기댄 학습이 한국에서 같은 방어를 못 받을 수 있다. 데이터 파이프라인(2.1)을 설계할 때 이미 "이 데이터셋을 이 관할에서 학습에 쓰는 것의 리스크"를 따져야 하는 이유다 — 학습이 끝난 모델에서 특정 데이터의 영향을 사후에 빼내는 것은 뒤(9.3.8)에서 보듯 사실상 불가능에 가깝기 때문이다.

9.3.5 라이선스·크롤·데이터베이스권 — 저작권 옆의 축들

저작권법만 넘으면 끝이라고 생각하기 쉽지만, 학습 데이터에는 저작권과 독립한 최소 세 개의 축이 겹쳐 있다. 저작권상 문제가 없어도 이 축들 중 하나에서 걸릴 수 있고, 실무에서는 오히려 이쪽이 더 명확하게 위반으로 분류된다.

첫째는 라이선스다. 오픈소스 코드와 공개 데이터셋에는 라이선스(MIT·Apache·GPL·CC-BY·CC-BY-NC 등)가 붙는다. "오픈 = 무엇이든 가능"이 아니다. 라이선스는 귀속 표시(attribution), 카피레프트(파생물의 소스 공개 의무), 비상업 제한 같은 조건을 건다. GPL 코드로 학습한 모델과 그 산출물에 카피레프트가 전파되는지는 아직 다투어지는 미확정 문제이고, CC-BY-NC(비상업) 데이터로 상업 모델을 학습하는 것은 라이선스 조건과 정면으로 충돌할 여지가 있다. 라이선스 생태계의 상세는 9.2에서 다뤘지만, 요점은 "공개돼 있음"과 "그 라이선스가 이 용도를 허용함"이 별개라는 것이다.

둘째는 사이트 약관과 크롤 신호다. 웹사이트 이용약관이 스크래핑을 금지하거나, robots.txt가 크롤러를 배제하거나, 학습 opt-out 신호를 낼 수 있다. 이를 무시한 수집은 저작권과 무관하게 계약 위반·부정경쟁·전산망 무단 이용 관련 법의 문제를 별도로 낳을 수 있다(구체적 성립 여부는 관할별로 다르다). robots.txt를 지키는가는 저작권 판단과 상관없이 그 자체로 법·윤리 양면의 쟁점이고, EU에서는 앞서 봤듯 opt-out 존중이 TDM 예외의 조건이기도 하다.

셋째는 데이터베이스권이다. EU의 sui generis 데이터베이스권처럼, 개별 저작물이 아니라 DB를 구축한 투자·편집을 따로 보호하는 권리가 있다. 개별 항목에 저작권이 없어도(예: 순수 사실의 모음) DB 전체를 대량 추출하면 이 권리에 닿을 수 있다. 또 API로 받은 데이터나 구매한 데이터셋은 공급 계약의 사용 제한(재학습 금지, 용도 제한)에 묶인다 — 이것은 아예 저작권 이전에 계약의 문제다.

이 축들에 공통으로 대응하는 실무는 하나로 수렴한다 — 출처와 처리 이력을 기록하는 것이다. 어느 관할에서 다투게 되든, "우리는 무엇을, 어떻게 얻어, 어떤 신호를 존중하며 수집했다"를 데이터 카드·계보로 남긴 팀이 그렇지 않은 팀보다 방어 가능성이 높다. 기록이 없으면 "몰랐다"조차 증명하지 못하고, 성실성을 주장할 근거가 사라진다.

# 데이터 출처 기록(provenance)의 최소 형태 — 사후의 법적 방어·감사를 위해 남긴다 (8.3 데이터 거버넌스)
dataset_record:
  source_id: "web-crawl-2026Q1"
  acquisition: "common-crawl WARC 재추출"       # 어떻게 얻었나
  license: "mixed / unknown"                     # 라이선스 상태 — 불명이면 불명이라 정직하게 기록
  robots_txt_respected: true                     # 크롤 배제 신호 존중 여부
  opt_out_signals_checked: ["robots.txt", "tdm-reservation-meta"]
  pii_filtering: "regex+ner, recall<100%"        # 한계까지 정직하게 (2.1)
  jurisdiction_of_training: "확인 필요 — 법무 검토"  # 어느 관할에서 학습했나
  notes: "저작권 민감 콘텐츠 혼재 가능 — 법무 검토 대상"

이 기록은 "이렇게 하면 합법"이라는 보증이 결코 아니다. 리스크를 낮추고, 분쟁이 났을 때 성실성을 보이는 실무일 뿐이다. 적법한 이용 근거가 있는지의 최종 판단은 여전히 관할 변호사의 몫이다.

9.3.6 산출물 — 저작권·소유·침해·표절이 뒤섞이는 곳

입력(학습)만큼 까다로운 것이 출력이다. 산출물을 둘러싼 논의에서 사람들은 서로 다른 네 개의 질문을 하나로 뭉쳐 혼동하는데, 이것을 분리하지 않으면 "AI 생성물은 저작권이 없다더라" 같은 위험한 반쪽 명제에 도달한다. 넷을 하나씩 떼어 놓는다.

질문 1 — AI 생성물에 저작권이 생기는가. 통념은 "AI 생성물은 저작권이 없다"이다. 정확히 말하면 이것은 관할·사안에 따라 다르며, 전체로는 틀린 단순화다. 여러 관할의 저작권 제도는 인간의 창작적 기여(human authorship)를 보호 요건으로 본다. 그래서 대략 스펙트럼이 관찰된다. 사람이 "고양이 그려줘" 한 줄만 입력한 순수 기계 생성물은 인간 저작자성이 약해 보호를 못 받을 수 있고(일부 저작권 당국은 인간 저작자성 부재를 이유로 등록을 거부한 사례가 있다), 반대로 사람이 선택·편집·배열·상당한 창작적 개입을 더한 경우 그 인간 기여 부분은 보호될 여지가 있다. 관할에 따라 "컴퓨터 생성 저작물"에 별도 규정을 둔 곳도 있다. 즉 정확한 명제는 "저작권이 없다"가 아니라 "인간의 창작적 기여가 없으면 보호가 약하거나 없을 수 있다"이다. 실무 함의는 크다 — AI가 만든 로고·문구를 자산으로 독점 판매하려는 사업은, 그 산출물이 저작권으로 보호되지 않아 남이 그대로 베껴도 막지 못할 리스크를 안는다.

질문 2 — 산출물이 남의 저작권·상표를 침해하는가. 방향이 정반대인 리스크다. 모델이 학습 데이터를 암기하거나 스타일을 근접 재현하면, 산출물이 기존 저작물을 침해할 수 있다. 산출물이 특정 저작물과 실질적으로 유사하면 저작권 침해가 될 수 있고(스타일 자체는 대개 보호 대상이 아니지만, 구체적 표현의 복제는 다르며 그 경계는 사안 의존이다), 브랜드명·로고·슬로건을 넣으면 상표권·부정경쟁 문제가, 실존 인물의 측면·목소리를 재현하면(딥페이크·음성 클론) 초상권·퍼블리시티권·인격권 문제가 켜진다. 멀티모달 서비스(6.8)는 이 세 번째 리스크에 특히 노출된다. 그리고 "사용자가 프롬프트를 넣었으니 사용자 책임"이라고 제공자가 자동으로 면제되지 않는다 — 서비스 설계와 필터가 침해를 조장했는지도 함께 따진다.

이 두 질문을 나란히 놓으면 최악의 조합이 보인다. 보호는 약하면서 침해 리스크는 있는 상태가 가능하다. 내 산출물은 저작권으로 지키기 어려운데(질문 1), 동시에 그 산출물이 남의 권리를 침해할 수는 있다(질문 2). "AI가 만든 거니 저작권이 없어서 자유롭다"와 "AI가 만든 거니 침해가 아니다"는 둘 다 틀렸고, 방향까지 반대다.

질문 3 — 산출물의 소유·이용권은 누구에게 있는가. 이것은 저작권 존부와 별개의 계약 문제다. 폐쇄 API를 쓰면 "생성된 출력을 누가 어떻게 쓸 수 있는가"는 벤더 이용약관이 정한다(벤더·시점마다 다르다). 어떤 약관은 사용자에게 출력의 폭넓은 이용권을 주고, 어떤 약관은 특정 용도(예: 경쟁 모델 학습)를 금지한다(9.3.11). "저작권이 없으니 아무나 자유롭게"도, "내가 뽑았으니 내 것"도 아니다 — 약관이 우선 규율한다.

질문 4 — 표절·허위·명예훼손. 표절(plagiarism)은 저작권 침해와 다른, 출처 미표기라는 윤리·학문·직업 규범의 문제다. 법 위반이 아니어도 학계·저널리즘·교육에서 제재 대상이다(9.4). 허위·명예훼손은 별개다 — 모델이 실존 인물·기업에 대해 거짓 사실(환각, 1.1)을 생성하고 그것을 서비스로 공표·전파하면 명예훼손·허위사실 문제가 될 수 있다. "AI가 지어낸 것"은 자동 면책이 아니며, 그 산출물을 공표한 주체의 책임이 문제된다.

9.3.7 프라이버시 — PII가 스며드는 세 곳과 두 체제

저작권이 "누구의 창작물인가"라면 프라이버시는 "누구의 개인정보인가"다. 완전히 별개의 법적 축이고, 위반 시 제재가 크며(다음 절에서 실제로 계산한다), LLM 시스템에서는 개인정보(Personally Identifiable Information, PII)가 저작권과 다른 지점으로 스며든다. 셋을 구분해야 어디를 막아야 할지가 보인다.

첫째, 학습 데이터 속 PII다. 크롤에 섞인 이름·연락처·주민번호·의료·성향 정보가 그대로 학습 코퍼스에 들어가고(2.1), 모델이 이를 암기해 재생할 수 있다(7.4). 둘째, 프롬프트 속 PII다. 사용자가 대화에 자기 개인정보를 입력하거나, 더 까다롭게는 제3자의 개인정보(고객 명단, 동료 이력서)를 넣는다. 셋째, 로그·피드백 속 PII다. 프롬프트·대화를 저장·분석·재학습에 쓰면(7.6·8.1) 그 저장·처리의 전 구간이 개인정보 처리로 규율된다. 이 셋 중 실무에서 가장 자주 방치되는 것이 세 번째다 — 서비스팀이 디버깅·품질 개선을 위해 프롬프트 전체를 로깅하는 순간, 개인정보 처리자가 되어 버린다.

대표적인 두 체제를 나란히 보면 축이 드러난다. 다만 아래는 일반화된 개관이고, 정확한 조문·요건·과징금 상한·최신 개정은 반드시 확인해야 한다. 특히 자동화된 결정과 AI 관련 조항은 두 체제 모두에서 강화·개정되는 중이다.

두 체제의 공통 골격은 "정당한 근거 없이 개인정보를 처리하지 마라, 정보주체에게 통제권을 줘라, 국경을 넘길 땐 안전장치를 둬라"이다. 그런데 LLM은 이 골격의 몇 지점에서 기존 소프트웨어보다 훨씬 다루기 어려운 문제를 만든다. 그중 가장 어려운 하나 — 삭제권 대 학습된 모델 — 는 절을 따로 떼어 값까지 매겨 본다.

9.3.8 삭제권 대 학습된 모델 — 그리고 재학습의 값

GDPR과 PIPA 모두 정보주체가 자기 정보의 삭제를 요구할 수 있다. 데이터베이스 레코드라면 이 요구는 기술적으로 쉽다 — DELETE FROM users WHERE id = ?. 문제는 개인정보가 모델 가중치에 흡수된 경우다. 학습 데이터셋 파일에서 그 사람의 문장을 지우는 것과, 이미 그 문장으로 학습을 끝낸 모델에서 그 영향을 제거하는 것은 완전히 다른 일이다. 가중치는 수십억 개 숫자의 뒤섞인 합이라, "이 사람의 정보가 여기 있다"고 지목해 지울 곳이 없다.

"머신 언러닝(machine unlearning)"은 바로 이 문제를 겨냥한 활발한 연구 주제이지만, 완전하고 검증 가능한 삭제는 여전히 어렵다. 그래서 실무는 재학습, 출력 필터, 특정 정보 차단 같은 우회로 대응하는데, 이것들이 법적 삭제 요구를 완전히 충족하는지는 미확정이다. 이 긴장이 얼마나 심각한지는 "정직하게 대응하려면 얼마가 드는가"를 계산해 보면 몸으로 온다.

한 사람의 삭제 요구를 가장 확실하게 이행하는 방법은 그 데이터를 뺀 코퍼스로 처음부터 다시 학습하는 것이다. 그 비용을 산정해 보자. 트랜스포머의 학습 연산은 대략 $C \approx 6ND$ FLOPs로 근사된다($N$ 은 파라미터 수, $D$ 는 학습 토큰 수, 순전파 $2N$·역전파 $4N$ 을 합쳐 토큰당 약 $6N$; 2.2·2.3). 8B 모델($N = 8\times10^9$)을 2조 토큰($D = 2\times10^{12}$)으로 학습했다면,

$$C \approx 6 \times (8\times10^9) \times (2\times10^{12}) = 9.6\times10^{22}\ \text{FLOPs}$$

이것을 시간으로 바꾼다. 데이터센터 GPU 한 장이 실효로 400 TFLOP/s($4\times10^{14}$ FLOP/s, 유효 활용률을 반영한 개략값)를 낸다고 하면,

$$\frac{9.6\times10^{22}}{4\times10^{14}} = 2.4\times10^8\ \text{GPU-초} \approx 6.7\times10^4\ \text{GPU-시간}$$

시간당 2달러로 가정하면 약 13만 달러, 1,000장 클러스터로 병렬화해도 벽시계로 약 2.8일이다. 이것이 삭제 요구 단 한 건을 완전 재학습으로 이행하는 값이다. 연간 100건이 들어오고 매번 재학습한다면 산술적으로 1,300만 달러와 수백 GPU-일이 든다 — 명백히 지속 불가능하다. 그래서 아무도 요구당 재학습을 하지 않으며, 바로 이 경제적 장벽이 "삭제권 대 학습된 모델"을 미해결로 남겨 두는 실제 이유다. 실무는 파인튜닝 기반 우회(전체가 아닌 부분 재학습)·출력 차단·데이터셋에서의 제거 후 다음 정기 재학습 반영 같은 절충으로 가지만, 이것이 법적 요구를 얼마나 충족하는지는 관할·감독당국의 해석에 달려 있고 확정되지 않았다. 이 값 계산 하나가 2.1의 "PII 재현율 100%는 불가능하다"가 왜 법적으로도 폭탄인지를 설명한다 — 애초에 안 들어가게 막는 것이 유일하게 확실한 방법이기 때문이다.

삭제권 말고도 프라이버시가 LLM에서 특히 어려운 지점이 세 개 더 있다. 정당한 처리 근거의 문제 — 크롤 데이터로 학습하거나 프롬프트를 재학습에 쓰려면 어떤 근거로 처리하는가? 동의를 받았는가, 아니면 "정당한 이익"으로 방어할 수 있는가? 이는 강하게 다투어지는 지점이다. 제3자 정보의 입력 — 사용자가 타인의 개인정보를 프롬프트에 넣으면(고객 데이터로 요약 요청) 그 처리 책임이 서비스 제공자에게도 미칠 수 있어, B2B에서는 처리자·컨트롤러 관계와 DPA가 필요해진다(9.3.11). 그리고 데이터 레지던시와 국외 이전 — 개인정보를 어느 나라 서버에서 처리·저장하는지가 규율되며, 특정 관할·산업은 국내 보관을 요구하거나 국외 이전에 동의·안전장치를 요구한다. 폐쇄 API로 데이터를 국외 벤더에 보내는 것 자체가 규제 대상일 수 있고, 이것이 온프레미스·프라이빗·리전 격리 배포(8.4)를 택하는 핵심 이유 중 하나다.

9.3.9 과징금은 얼마인가, 그리고 어떻게 덜 쌓나

프라이버시 위반의 무게를 감으로만 두지 말고 숫자로 확정해 보자. GDPR의 과징금은 두 단계 구조이고, 상위 단계 위반의 상한은 2,000만 유로 또는 전 세계 연매출의 4% 중 더 큰 쪽이다(하위 단계는 1,000만 유로 또는 2%; 정확한 단계 구분·적용은 확인 필요, 실제 부과는 비례 원칙에 따라 상한보다 훨씬 낮은 경우가 많다). 여기서 "더 큰 쪽(whichever is higher)"이라는 한 단어가 직관을 뒤집는다.

$$\text{상한} = \max\big(20\,\text{M€},\ 0.04 \times \text{전 세계 연매출}\big)$$

두 종류의 회사를 넣어 보자. 연매출 10억 유로의 대기업이면 $0.04 \times 1{,}000\,\text{M€} = 40\,\text{M€}$ 로 4% 항이 지배해 상한이 4,000만 유로다. 반대로 연매출 1,000만 유로의 스타트업이면 $0.04 \times 10\,\text{M€} = 0.4\,\text{M€}$ 에 불과하지만, "더 큰 쪽" 규칙 때문에 상한은 2,000만 유로 고정 항이 된다 — 회사 연매출의 두 배다. "우린 작으니까 벌금도 작겠지"라는 직관이 여기서 정확히 깨진다. 작은 회사일수록 매출 비례 항이 작아 오히려 고정 상한(2,000만 유로)이 지배하고, 그 상한이 회사의 존립을 넘어설 수 있다. 한국 PIPA도 최근 개정으로 매출액 기반 과징금 산정으로 이동하는 흐름이며, 정확한 산정식·상한은 확인이 필요하다.

실제 부과액은 상한이 아니라 위반의 성격·규모·고의성·완화 노력에 비례해 정해진다는 점이 중요하다 — 그리고 바로 그 "완화 노력"이 엔지니어가 미리 바꿔 놓을 수 있는 변수다. 그 가장 실용적인 형태가 데이터 최소화: 필요 없는 개인정보를 애초에 쌓지 않는 것이다. 안 받은 것은 유출될 수도, 삭제 요구를 받을 수도, 재학습에 잘못 들어갈 수도 없다.

# 로깅·보존 정책의 최소 형태 — 프라이버시-바이-디자인 (7.6 관측성과 연결)
logging_policy:
  redact_before_store: ["email", "phone", "national_id", "card", "api_key"]  # 저장 전 비식별화
  raw_prompt_retention_days: 30            # 원문 최소 보존 후 파기
  training_use:
    default: "opt-out"                     # 재학습 사용은 기본 제외 — 동의·설정 기반만
    requires_consent: true
  data_residency: "region-locked (EU→EU)" # 레지던시 요건 반영 (8.4)
  deletion_request_sla_days: 30           # 삭제 요구 처리 기한
  access_control: "role-based, audited"

네 가지 원칙이 이 정책을 뒷받침한다. 수집을 최소화하고, 저장 전에 비식별화(마스킹·해싱)하고, 목적과 보존기간을 제한하고(무기한 보관 금지), 재학습 사용은 명시적 근거로만 켠다(기본은 opt-out — 8.1의 플라이휠을 함부로 가동하지 않기). 이것들은 법 준수인 동시에 7.4의 데이터 유출 공격면을 줄이는 보안 조치이기도 하다. 다만 이 정책 역시 "이렇게 하면 GDPR·PIPA 준수"라는 보증이 아니다. 적법한 처리 근거, 개인정보 영향평가(Data Protection Impact Assessment, DPIA)나 개인정보보호책임자(DPO) 지정의 필요 여부, 국외이전 안전장치는 관할·처리 규모·데이터 종류마다 다르고 법률 자문이 필요하다.

9.3.10 AI를 직접 겨냥한 규제 — EU AI Act와 관할의 다양성

지금까지는 기존 법(저작권·프라이버시)을 AI에 적용하는 이야기였다. 그것과 별개로, AI 시스템 자체를 직접 겨냥한 신규 규제가 등장했다. 대표는 EU AI Act로, AI를 위험 수준별로 차등 규제한다. 세부 요건·발효 시점·기준값(모델 규모·연산량 임계 등)은 단계적으로 적용되고 개정되므로 이 글을 읽는 시점엔 이미 달라졌을 수 있지만, 위험 등급이라는 골격은 알아 둘 가치가 있다 — 이 골격은 잘 바뀌지 않고, 다른 관할의 AI 규제도 대체로 이 발상을 변주한다.

등급의 개략을 파악해 보자. 허용 불가(unacceptable) 등급은 특정 용도(정부의 무차별 사회적 점수화, 특정 조작적·감시 용도)를 아예 금지할 수 있다. 고위험(high-risk)은 채용·신용평가·교육 입시·의료·법집행·핵심 인프라처럼 사람의 권리·안전에 큰 영향을 주는 용도이고, 위험관리·데이터 거버넌스·문서화·인간 감독·정확성·로깅 같은 엄격한 의무가 붙을 수 있다. 제한적 위험(limited)은 투명성 의무가 핵심이다 — 챗봇은 "지금 AI와 상호작용 중"임을 알리고, 생성·조작된 콘텐츠(딥페이크·합성 이미지)는 AI 생성물임을 표시해야 할 수 있다. 대화형 서비스 대부분이 여기에 닿는다. 최소 위험(minimal)은 대부분의 일반 용도로, AI 규제상 특별한 의무는 적지만 저작권·프라이버시 등 다른 법은 여전히 그대로 적용된다.

여기서 반드시 붙잡을 통찰이 하나 있다. 등급을 정하는 것은 모델이 아니라 용도다. 같은 8B 모델이라도 잡담용 챗봇이면 제한적 위험에, 채용 심사에 쓰이면 고위험에 떨어진다. 당신이 파는 것이 "모델"이 아니라 "그 모델이 무엇에 쓰이는 서비스인가"라는 점에서, 위험등급은 아키텍처가 아니라 제품 결정에서 나온다. 여기에 별도의 축으로, 대형 범용(General-Purpose AI, GPAI)·기반모델 제공자에게 기술문서·학습데이터 요약·저작권 정책 같은 투명성 의무가 위 등급과 병렬로 부과되는 흐름이 있다(9.2의 오픈 웨이트 논의와 이어진다).

규제는 EU만의 일이 아니다. 미국은 연방 차원의 단일 포괄법보다 분야별 규제·행정지침·주법이 혼재하는 경향이라, 채용·신용·의료 등 기존 분야 규제가 AI에 적용되는 형태다. 한국은 AI 관련 입법·가이드라인이 정비되는 중이며 개인정보 보호법·신용정보법 등 기존 법이 AI 처리에 적용된다. 중국 등은 생성형 AI 서비스에 별도 관리 규정·심사·표시 요건을 둔다. 그리고 AI 전용법과 별개로 금융·의료·아동·광고·소비자 보호 같은 도메인 규제가 겹겹이 적용된다 — "AI 법을 봤으니 끝"이 아니라, 당신의 도메인 규제를 함께 봐야 한다는 뜻이다. AI 규제는 이 장 전체에서 가장 빠르게 변하는 영역이므로, 여기서 가져갈 것은 "위험 등급 × 용도 × 관할"이라는 구조이지 특정 수치가 아니다.

9.3.11 법이 아니라 계약이 묶을 때 — 약관·증류 제한·DPA

법(law)과 완전히 별개로, 계약(contract)이 당신을 구속한다. 남의 모델·API 위에 서비스를 구축한다면(9.1의 buy 경로) 벤더 이용약관(Terms of Service, ToS)이 사실상의 규칙서다. 여기서 엔지니어가 가장 흔히 저지르는 개념 혼동을 명시해야 한다 — 저작권상 문제가 없어도 약관 위반은 별개로 성립한다. 저작권이 "이 이용이 법적으로 허용되는가"라면, 약관은 "이 벤더가 나에게 허락했는가"다. 둘은 다른 질문이고, 후자를 어기면 저작권과 무관하게 계정 정지·계약 해지·손해배상의 근거가 된다.

폐쇄 API 약관에서 특히 주의할 조항이 몇 유형 있다(제공자·시점마다 문구가 다르니 각 벤더 약관을 직접 확인해야 한다). 가장 대표적인 것이 경쟁 모델 개발·학습 금지다 — 자사 모델의 출력으로 경쟁 모델을 학습·증류하는 것을 막는 조항이 흔하다. 이것이 3.9에서 다룬 "폐쇄 API 출력으로 학생 모델을 SFT"의 직접적 계약 장벽이다. 출력물의 저작권이 누구에게 있느냐와 무관하게, 약관 위반 자체가 제재 근거가 된다. 그 밖에 불법·유해·특정 고위험 용도를 막는 허용 사용 정책(Acceptable Use Policy, AUP; 7.3의 정책과 연결), 당신의 입력·출력을 벤더가 자사 모델 개선에 쓰는지와 옵트아웃 가능 여부(이것은 당신의 프라이버시 의무(9.3.7)와 직결되므로 반드시 확인), 속도·용량·재판매 제한과 귀속 표시 요건 등이 있다.

기업 고객에게 LLM 서비스를 팔거나 살 때, 개인정보가 오가면 데이터 처리 부속계약(Data Processing Agreement, DPA)이 필요하다. 핵심은 역할 배분이다. 개인정보 처리의 목적·수단을 정하는 컨트롤러(controller)와 그 지시로 처리만 하는 처리자(processor)는 의무가 다르고, LLM 서비스 제공자가 어느 쪽인지가 책임 범위를 가른다. 당신이 뒤에서 폐쇄 API 벤더를 쓰면 그 벤더는 하위 처리자(sub-processor)가 되어, 고객에게 이를 고지·승인받을 의무가 생길 수 있다. 국외이전·레지던시·보안조치·통지 의무·감사권을 DPA에 명시해 두는 것이 나중의 분쟁을 줄인다.

오픈 웨이트 모델이라고 계약에서 자유롭지 않다. 모델 라이선스(9.2)가 상업 사용·파생물·재배포·사용자 수·용도를 제한할 수 있고, 일부 "오픈" 모델은 순수 오픈소스 정의를 만족하지 않는 커스텀 라이선스다. "오픈 = 무엇이든 가능"이 아니라 "그 라이선스가 허용하는 범위 안에서 가능"이다. 결국 약관·라이선스는 읽으라고 있는 문서다 — 쓰는 모든 모델·API의 약관을 실제로 읽고, 경쟁 모델 학습·데이터 학습 사용·용도 제한 조항을 특히 확인하고, 약관은 개정되므로 변경 이력을 추적하는 것. 이 셋이 최소한의 실무다.

9.3.12 책임·면책, 그리고 잔여 리스크의 관리

리스크를 지도로 그렸으면 다음 질문은 "누가 책임지고, 어떻게 관리하는가"다. 모델이 틀린 조언(잘못된 의료·법률·금융 정보), 명예훼손적 허위, 침해 산출물, 유해 콘텐츠를 내고 그것이 피해로 이어지면 책임은 누구에게 가는가. 정해진 단일 답은 없고 여러 주체·여러 법리가 얽히며, 관할·사실관계에 따라 갈린다. 서비스 제공자는 제품 결함·과실·소비자보호·명예훼손 등으로 책임이 물어질 수 있어 "모델이 한 것"이 자동 면책이 되지 않고, 사용자는 오용·금지 용도 위반이면 책임이 커지며, 모델 벤더는 약관에서 책임을 강하게 제한·면책하는 경우가 많다(현상태 제공 "as-is", 손해배상 상한). 그래서 buy 경로에서는 벤더가 지지 않는 리스크가 당신에게 남는다는 점을 계약에서 확인해야 한다.

B2B 계약의 면책 조항(indemnification)은 "제3자가 저작권·프라이버시 침해로 소를 제기하면 누가 방어·배상하나"를 정한다. 일부 대형 벤더는 특정 조건에서 저작권 침해에 대한 면책을 제공하기도 하지만, 조건·상한·예외가 많다(예: 벤더의 필터를 껐거나 금지 용도로 썼으면 면책 제외). 면책은 계약서에 쓰인 대로만 유효하다 — "면책해 준다더라"는 마케팅 문구가 아니라 조항의 조건·상한·예외를 봐야 한다.

리스크는 없앨 수 없고 관리한다. 그 관리를 정량으로 사고하는 간단한 프레이밍이 있다.

$$\mathbb{E}[\text{연간 손실}] \;=\; \Pr(\text{사건 발생}) \times \text{영향} \;-\; \text{완화 효과}$$

숫자를 넣어 개략을 파악해 보자. 어떤 저작권 클레임의 연간 발생 확률이 5%, 발생 시 영향(합의금·소송비·평판 손실)이 200만 유로라면, 대응 없이 기대되는 연간 손실은 $0.05 \times 2\,\text{M€} = 100{,}000\ \text{€}$ 다. 이제 출처·계보 문서화와 opt-out 존중 같은 완화를 넣으면 두 항이 함께 내려간다 — 성실성이 입증되어 발생 확률이 3%로, 방어가 쉬워져 영향이 120만 유로로 준다면 기대 손실은 $0.03 \times 1.2\,\text{M€} = 36{,}000\ \text{€}$ 다. 완화의 가치는 연 64,000유로. 그 완화를 만드는 컴플라이언스 프로그램이 연 40,000유로면 순이득이 명확하다. 이 계산은 물론 확률·영향을 정확히 알 수 없어 개략일 수밖에 없지만, 문서화가 왜 비용이 아니라 투자인지를 숫자로 보여 준다 — 문서화는 발생 확률과 영향을 동시에 낮추는 몇 안 되는 조치다.

완화 효과를 만드는 것이 컴플라이언스 프로그램이다. 조직 규모에 맞게 조절하되, 골격은 순환이다.

핵심은 문서화와 반복이다. 규제·판례가 바뀌므로 한 번의 검토가 아니라 법 개정을 추적하며 갱신하는 순환이어야 한다 — LLMOps의 데이터 플라이휠(8.1)에 법·컴플라이언스 루프를 하나 더 붙인 셈이다. 다만 이 프로그램도 리스크를 낮출 뿐 없애지 못하며, 조직 규모에 비례해야 한다. 초기 스타트업이 대기업 수준의 법무를 갖출 수는 없다. 현실적 출발점은 셋이다 — 어떤 데이터로 무엇을 만들었는지 기록하고, 명백한 위험 요소(경쟁 모델 학습 약관 위반, 무동의 PII 재학습, 위험등급을 안 본 고위험 용도)를 피하고, 출시 전 자격 있는 변호사에게 한 번은 검토받는 것.

9.3.13 라이프사이클로 따라가는 출시 전 점검

지금까지 세운 지도를 하나의 구체적 상황에 적용해 직접 따라가 보자. 가상의 팀이 "고객지원 챗봇 SaaS"를 EU·한국 고객에게 출시한다. 라이프사이클 순서(9.3.1)로 각 단계에서 무엇을 법무에 가져가야 하는지를 훑는다. 아래 답들은 예시이며, 실제 판단은 관할 변호사의 몫이다.

학습·튜닝 데이터 단계에서 팀이 물어야 할 것은 이렇다. 어떤 데이터로 파인튜닝했는가 — 크롤인가, 구매인가, 고객 데이터인가, 그리고 그 출처·라이선스·계보가 기록돼 있는가. robots.txt와 opt-out 신호를 존중했는가. 저작권에 민감한 소스(뉴스·책)를 넣었다면 관할별 리스크를 검토했는가. 데이터에 PII가 있고, 비식별화·필터를 거쳤으며, 그 재현율이 100%가 아님을 인지하는가. 이 단계의 실수는 학습이 끝나면 되돌리기가 앞서 계산한 것처럼 극도로 비용이 크다는 점을 기억해야 한다.

모델·가중치 단계. 폐쇄 API 출력으로 증류·합성했다면 경쟁 모델 학습 금지 약관을 위반하지 않았는가(9.3.11). 오픈 웨이트를 썼다면 그 라이선스가 상업·SaaS 사용을 허용하는가(9.2). 이 모델이 규모·용도상 범용모델(GPAI) 규제 의무에 닿는가.

출력 단계. 침해·유해·허위 산출물을 걸러낼 가드레일·필터가 있는가(7.3). 산출물의 소유·이용권을 사용자에게 어떻게 고지하는가(9.3.6). "AI가 생성함" 표시 의무가 이 서비스에 적용되는가(9.3.10의 투명성).

서비스 단계. 이 챗봇의 용도가 고위험(채용·신용·의료 등)에 닿는가 — 닿으면 엄격한 의무가 켜진다. "지금 AI와 대화 중"임을 사용자에게 알리는가(투명성 의무). 도메인 규제(소비자보호·광고·아동)가 겹치는가.

로그·피드백 단계. 프롬프트·대화를 저장하는가, 그렇다면 보존기간·비식별화·접근통제가 있는가(9.3.9). 로그를 재학습에 쓰는가 — 쓴다면 동의·처리 근거가 있는가(플라이휠을 함부로 가동하지 않기). 데이터를 어느 리전에 저장하며, EU 데이터가 국외로 나간다면 레지던시·이전 안전장치가 있는가(8.4). 삭제 요구와 정보주체 권리를 처리하는 절차와 기한(SLA)이 있는가.

이 점검표는 완전하지 않다 — 도메인·관할·규모마다 항목이 달라지고, 여기 없는 위험 요소가 당신의 서비스엔 있을 수 있다. 목적은 "빠짐없이"가 아니라 엔지니어가 무엇을 법무에 가져가야 하는지를 구조화하는 것이다. 그리고 이 장 전체를 관통하는 한 문장으로 마무리한다. 이 장은 지도일 뿐, 결정이 아니다. 이 분야에서 "확실히 합법"이라고 느껴지는 지점일수록 관할·시점·사실관계를 다시 의심해야 하며, 확신은 대개 정보 부족의 신호다. 최종 판단은 반드시 현재 시점의 자격 있는 변호사에게 받아라.

다음 장(9.4)은 여기서 한 겹 위로 올라간다. 이 장이 "무엇이 합법인가"를 — 그것도 미확정인 채로 — 다뤘다면, 9.4은 "무엇이 옳은가"를 다룬다. 둘은 겹치지만 같지 않다. 약관은 다 지키면서 이용자를 조작하는 합법적 비윤리가 있고, 정당한 사용이 규제 공백에 걸리는 윤리적 위법 아님이 있다. 이 장의 법적 리스크 지도 위에, 다음 장은 가치와 거버넌스의 층을 추가한다.