David.Cheon
UIpac
David.Cheon
전체 방문자
오늘
어제
  • UIpac (648)
    • Planning · PM (227)
      • 프로젝트 · PM (58)
      • UX · Product (49)
      • 서비스 기획 (40)
      • Business · Growth (60)
      • 일하는 방법 (20)
    • AI (65)
      • AI Product (13)
      • AI 활용 · 자동화 (7)
      • AI Technology (11)
      • AI Trend (34)
    • Projects · Tech (2)
      • Toy Project (1)
      • Web · IT (1)
      • Tools (0)
    • Archive (352)
      • Weekly Curation (251)
      • Performing Arts (17)
      • Collection (6)
      • Books (0)
      • Life (78)

블로그 메뉴

  • 홈
  • 방명록

공지사항

인기 글

Tags

  • 벤치마킹
  • 유니티
  • 디자인참고
  • 2014
  • 모바일
  • 트렌드
  • daumkakao
  • 세계 게임시장 규모
  • UI
  • 분석
  • 기획참고
  • 반응형웹
  • 웨어러블
  • 가트너
  • 애플리케이션
  • 트랜드
  • 큐레이션
  • 다음카카오
  • trend
  • 사이트
  • 동향
  • 사물인터넷
  • 인공지능
  • Mreport
  • 기획
  • 디자인
  • Curation
  • Gartner
  • UX
  • 2015

최근 댓글

최근 글

방명록

Uipac
David.Cheon

UIpac

Planning · PM/프로젝트 · PM

생성형 AI 저작권과 윤리, 공부하며 정리한 쟁점

2023. 10. 4. 19:28

 

생성형 AI를 공부하다 보면 기술 이야기만큼 자주 만나는 주제가 저작권과 윤리입니다.
서비스에 AI 기능을 넣는다면 이 문제를 피해갈 수 없을 것 같아서, 기사와 공개된 논의를 읽으며 쟁점을 정리해보았습니다.
먼저 분명히 해둘 점이 있습니다.
저는 법률 전문가가 아니고, 이 글은 공부한 내용을 정리한 메모일 뿐 법률 자문이 아닙니다.
이 분야는 아직 논의 중인 부분이 많아서, 실제 서비스에 적용할 때는 반드시 전문가의 검토와 최신 공식 안내를 확인해야 한다고 생각해요.

 

가장 먼저 눈에 띄는 쟁점은 모델이 무엇으로 학습했느냐입니다.
이미지나 글을 생성하는 모델은 방대한 데이터로 학습하는데, 그 안에 창작자가 만든 작품이 들어 있을 수 있다는 점이 논란의 중심이에요.
창작자 입장에서는 허락 없이 자신의 작품이 학습에 쓰였다는 문제 제기가 가능하고, 개발하는 쪽에서는 학습이 복제와는 다르다는 주장이 있을 수 있습니다.
이 부분은 여러 나라에서 소송과 논의가 진행되고 있다는 소식을 읽었는데, 어떻게 정리될지는 제가 단정할 수 있는 영역이 아니에요.

기획자로서 이 쟁점이 중요한 이유는 서비스가 어떤 모델에 기대는지에 따라 위험이 달라질 수 있기 때문입니다.
모델 제공자가 학습 데이터에 대해 어떤 입장을 밝히는지, 이용약관에 책임 범위가 어떻게 적혀 있는지를 확인하는 습관이 필요하다고 느꼈습니다.

 

두 번째는 AI가 만든 결과물에 누가 어떤 권리를 가지느냐입니다.
사람이 입력한 지시문이 창작이라고 볼 만큼의 기여인지, AI가 거의 혼자 만든 결과물에는 저작권이 인정되는지 같은 질문이에요.
나라마다 접근이 다르고, 사람의 창작적 기여가 어느 정도여야 하는지에 대한 기준도 계속 논의되는 것으로 알고 있습니다.

이 쟁점은 결과물을 상업적으로 쓰려는 사람에게 현실적인 문제가 됩니다.
예를 들어 AI로 만든 이미지를 업장 홍보 이미지로 쓰고 싶은 운영자가 있다고 가정해볼게요.
이 이미지를 다른 사람이 그대로 가져다 써도 막기 어려울 수 있고, 반대로 결과물이 기존 작품과 너무 비슷하게 나왔을 때의 책임이 누구에게 있는지도 분명하지 않을 수 있습니다.
어디까지가 확정된 사실인지 구분하기가 어렵기 때문에, 저는 "아직 정리되지 않은 영역"이라는 전제를 두고 접근하는 게 안전하다고 봅니다.

 

저작권 외에도 윤리 쪽 쟁점이 여럿 있었습니다.
학습 데이터의 편향이 결과물에 반영되는 문제, 실제 사람처럼 보이는 가짜 이미지나 글이 만들어질 수 있다는 문제, 개인정보가 학습이나 입력 과정에서 노출될 수 있다는 문제 등이에요.
또 사용자가 AI와 대화하고 있다는 사실을 알고 있는지, AI가 만든 콘텐츠라는 표시를 해야 하는지도 자주 언급되는 주제입니다.

이 중에서 서비스 기획과 가장 직접 연결되는 것은 투명성이라고 느꼈습니다.
사용자에게 "이 답변은 AI가 생성했습니다"라고 알리는 것은 기술적으로 어렵지 않고, 신뢰 측면에서 효과도 있을 것 같아요.
어떤 형태가 요구될지는 앞으로 규칙이 달라질 수 있어서 지금은 확정적으로 말하기 어렵지만, 기획 단계에서 표시할 자리를 확보해두는 것은 비용이 크지 않다고 생각합니다.

 

공부한 내용을 바탕으로, 예약 서비스에 AI 기능을 넣는다고 가정하고 체크 목록을 만들어봤습니다.
법적 판단이 아니라 기획자가 질문을 놓치지 않기 위한 목록이에요.

먼저 입력 데이터입니다.
고객이 챗봇에 입력한 이름, 연락처, 예약 내용이 외부 모델 제공자에게 전송된다면, 어떤 정보가 나가고 어떻게 처리되는지를 확인해야 합니다.
개인정보는 가능하면 모델에 보내기 전에 가리거나 필요한 만큼만 보내는 방식이 안전하겠다고 생각했어요.
다음은 이용약관입니다.
모델 제공자가 입력 데이터를 학습에 사용하는지, 사용하지 않는다면 어떤 조건에서 그런지가 계약이나 설정에 달려 있을 수 있으니 문서를 읽어봐야 합니다.
세 번째는 결과물의 용도예요.
챗봇의 단순 응답과, 업장 홍보 문구나 이미지처럼 외부에 공개되는 생성물은 위험 수준이 다르기 때문에 용도별로 나눠서 생각하는 편이 낫습니다.
마지막으로 사용자 고지입니다.
AI가 응답하고 있다는 사실과 한계를 알리는 문구, 오답이 있을 수 있다는 안내를 어디에 둘지 정해둡니다.

여기에 하나 더 얹자면, 문제가 생겼을 때의 대응 경로도 미리 생각해두면 좋겠다고 느꼈어요.
예를 들어 챗봇이 부적절한 표현을 내놓았다는 신고가 들어왔을 때 누가 확인하고 어떻게 고칠지, 사용자가 AI 응답에 대해 의견을 남길 방법이 있는지 같은 것들입니다.
사고가 나고 나서 절차를 만들기보다, 작게라도 신고와 확인 경로를 먼저 열어두는 편이 훨씬 수월할 것 같아요.

 

이 주제를 공부하면서 가장 크게 느낀 것은 "정답이 없어서 불편하다"는 감정이었습니다.
기술은 빠르게 움직이는데 규칙은 천천히 정리되고 있어서, 지금 내리는 판단이 몇 달 뒤에는 달라질 수도 있어요.
그래서 저는 확실한 것과 논의 중인 것을 구분해서 적어두고, 불확실한 부분은 보수적으로 설계하는 쪽을 택하려 합니다.
아직 답을 못 찾은 질문도 많아요.
작은 서비스가 현실적으로 어디까지 확인해야 하는지, 결과물에 대한 표시 의무가 생긴다면 어떤 형태가 될지 등을 계속 지켜볼 생각입니다.


다시 한 번 말씀드리면, 이 글은 법률 자문이 아닌 공부 기록이고, 실제 판단은 전문가와 공식 자료를 통해 하시기를 권합니다.

저작자표시 비영리 변경금지 (새창열림)

'Planning · PM > 프로젝트 · PM' 카테고리의 다른 글

Build-Measure-Learn, 작게 돌려보기  (0) 2022.05.17
기능 우선순위 프레임워크 비교, 1인 프로젝트에 ICE·RICE·Kano 적용해보기  (0) 2022.05.10
MVP 범위 자르기 - 기능을 어디까지 빼야 하나  (0) 2022.04.27
린 캔버스로 아이디어 검증하기  (0) 2021.05.23
애자일 팀의 회고(Retrospective) 잘 하는 법  (0) 2021.05.21

    티스토리툴바