▲

Claude Code가 작성한 코드의 소유자는 누구인가?

 (legallayer.substack.com)
3P by GN⁺ 3시간전 | ★ favorite | 댓글 1개
  • AI 보조 코드의 저작권은 인간의 의미 있는 창작 기여가 있는지에 달려 있으며, AI가 주로 만들고 인간이 거의 손대지 않은 결과물은 보호를 받지 못할 수 있음
  • 핵심 판단 기준은 meaningful human authorship이며, 목표만 지시하는 수준보다 아키텍처를 정하고 결과를 걸러내고 코드를 다시 구성하는 창작 결정이 더 중요하게 작용함
  • 코드의 저작권 성립 여부와 별개로, work-for-hire doctrine이나 넓은 IP 양도 조항이 있으면 회사 시간·장비·프로젝트·회사 라이선스 도구로 만든 AI 보조 코드도 회사 소유로 돌아갈 가능성이 큼
  • 소유권이 있더라도 오픈소스 라이선스 오염은 별도 문제이며, 특히 GPL 계열 코드를 실질적으로 그대로 복제한 출력물은 라이선스 위반으로 이어질 수 있음
  • 지금 비교적 분명한 축은 인간 저작성 부재 시 비보호, 고용계약에 따른 권리 귀속, GPL 축어적 복제의 위험이며, 실제 실무에서는 법원 판단보다 기록 보존과 라이선스 스캔이 더 먼저 중요해짐

저작권 기준과 미해결 구간

  • 저작권 보호는 인간이 만든 저작물에만 적용되며, AI가 주로 생성하고 인간의 의미 있는 창작 기여가 없는 결과물은 현행 기준에서 보호 대상이 아닐 수 있음
  • Thaler 사건 이후에도 대법원이 본안을 판단한 것은 아니며, DC Circuit 판결은 유지됐지만 AI 보조 코딩 결과물에 그대로 적용된 직접 판례는 아직 없음
  • 법원이 직접 다루지 않은 핵심 구간은 AI 보조 작업물에서 인간 개입이 얼마나 있어야 하는지임
    • 순수 AI 생성 그림처럼 인간 개입이 0인 경우와 달리, 코드는 인간이 일부 방향을 정하고 승인하는 경우가 많아 경계가 더 흐려짐
    • 코드 분야에는 아직 인간 저작성 원칙을 AI 코딩 출력물에 직접 적용한 판결이 없음
  • AI가 만든 코드를 거의 수정 없이 받아들였다면 누구도 저작권을 주장하지 못할 가능성이 있으며, 경쟁사가 그대로 복제해도 대응 수단이 약해질 수 있음
  • 판단 기준의 핵심은 meaningful human authorship이며, 목표만 적어 주는 것보다 구조를 정하고 결과를 걸러내고 설계를 다시 짜는 창작 판단이 중요하게 다뤄짐

인간 저작성 입증 방식

  • 의미 있는 인간 기여는 비율이나 수정 횟수로 딱 잘라 계산되지 않으며, 인간이 실제로 창작 결정을 내렸는지가 중요함

    • 아키텍처 선택

      • 초안 중 무엇을 거절할지 결정해야 함
      • 특정 설계에 맞게 결과를 재구성해야 함
      • "API용 rate limiting 모듈을 만들어라" 같은 짧은 지시 뒤에 도구가 여러 파일을 만들고 반복 수정한 경우, 인간의 기여가 법정에서 충분한지에 대한 명확한 결론은 아직 없음
      • 상당히 방향을 바꿔가며 손본 모듈은 인간 저작성을 인정받을 가능성이 더 크지만, 그대로 수용한 코드는 반대 방향으로 해석될 수 있음
      • Allen v. Perlmutter는 600개가 넘는 프롬프트와 Photoshop 편집이 있었어도 AI가 만든 기본 요소는 등록이 거절된 사건으로, 인간 개입의 충분성을 가르는 중요한 분기점으로 남아 있음
      • Zarya of the Dawn에서는 인간이 쓴 텍스트만 등록되고 Midjourney가 만든 이미지는 제외됐으며, 이 원칙은 AI 보조 코드베이스에서도 인간이 직접 만든 요소를 분리 보호하는 방향과 맞닿아 있음
      • 설계 문서는 근거가 됨
      • 커밋 메시지에 남긴 설계 판단도 근거가 됨
      • ADR도 근거가 됨
      • 의도적으로 방향을 바꾼 흔적이 담긴 프롬프트 로그도 도움이 됨
      • 보호 가능한 부분을 넓히려면 무엇을 직접 결정했고 어떻게 바꿨는지 기록해 두는 편이 유리함

고용계약이 먼저 가르는 소유권

  • 코드가 저작권 보호 대상인지 따지기 전에, 그 권리가 애초에 누구에게 귀속되는지부터 확인해야 함
  • 일반적인 고용계약은 업무 범위 안에서 만든 산출물을 회사 소유로 돌리며, 이는 work-for-hire doctrine으로 설명됨
  • 회사 업무 시간, 회사 프로젝트, 회사 장비, 회사가 제공한 AI 코딩 도구를 써서 만든 결과물은 수동 작성 코드와 AI 보조 코드 모두 회사 소유로 처리될 가능성이 큼
  • 실제 계약서는 보통 기본 법리보다 더 넓게 써 두며, 다음 문구가 있으면 AI 보조 코드까지 포괄할 가능성이 큼
    • 회사 장비나 자원을 사용해 만든 작업물도 포함될 수 있음
    • 고용 기간 중 만든 발명이나 개발물도 포함될 수 있음
    • 회사가 라이선스한 도구의 도움으로 만든 소프트웨어도 포함될 수 있음
  • 특히 company-licensed tools 문구는 개인 프로젝트까지 번질 수 있음
    • 회사가 Claude Code, Cursor, Copilot를 팀용으로 도입했고
    • 같은 도구를 개인 시간의 사이드 프로젝트에도 썼다면
    • 넓은 IP 양도 조항 아래서 회사가 권리를 주장할 여지가 생김
  • 회사 코드가 IDE 안에서 열려 있었고 AI가 이를 볼 수 있었다는 이유만으로 출력물이 회사 IP의 파생저작물이 된다는 주장은 법적으로 그대로 성립한다고 보기 어렵다고 적혀 있음
  • 다만 계약 문구가 넓으면, AI가 실제로 무엇을 했는지와 별개로 겉보기 주장 가능성은 생길 수 있음
  • 사이드 프로젝트를 분리하려면 개인 계정, 개인 장비, 개인이 비용을 내는 도구로 워크플로를 완전히 나누는 편이 안전함

오픈소스 라이선스 오염 위험

  • AI가 만든 코드를 소유하더라도, 그 코드가 보이지 않는 오픈소스 라이선스 의무를 끌고 왔을 가능성은 별도 문제임
  • AI 코딩 도구는 공개 코드, 그중에서도 GPL, LGPL 같은 copyleft 라이선스 코드를 포함한 대규모 데이터로 학습됨
  • copyleft 라이선스는 해당 코드의 파생저작물 배포 시 동일 라이선스 공개 의무를 따라오게 만듦
    • GPL 코드의 파생물이라면 자신의 소스도 같은 라이선스로 공개해야 함
    • 라이선스를 몰랐다는 사정은 방어가 되지 않음
  • 법적 위험의 기준은 기능 유사성이 아니라 실질적이고 상당한 축어적 복제에 있음
    • GPL 코드처럼 동작하는 결과물과
    • GPL 코드를 거의 그대로 재현한 결과물은 다른 문제임
  • 위험은 축어적 복제 쪽에 몰려 있지만, 현재 코드베이스가 어느 쪽인지 스캔 없이는 알기 어려움
  • 2026년 초 chardet community dispute에서는 Claude로 chardet를 다시 작성해 MIT 라이선스로 재배포한 일이 있었고, 이를 clean room 구현으로 볼 수 있는지를 두고 충돌이 있었음
    • 이 사안은 법원 소송이 아니라 커뮤니티 분쟁이었고, 법적으로 결론이 난 것은 아님
    • 다만 GPL 계열 코드를 그대로 복제하면 라이선스 위반이 된다는 점 자체는 이미 확립돼 있음
  • 아직 확정되지 않은 부분은 AI 출력이 학습 데이터 패턴을 재현했을 때 그것을 축어적 복제로 볼 수 있는지임
  • 기업 인수합병 자문 현장에서는 이 위험을 실제 이슈로 보고 있으며, AI 코드베이스 라이선스 스캔이 실사 항목으로 들어가고 있음
  • Doe v GitHub는 Copilot가 라이선스된 코드를 출처 없이 재현하는지를 다투고 있으며, 2026년 4월 기준 Ninth Circuit에서 계속 진행 중임
    • 1심은 대부분의 청구를 기각했지만 항소는 살아 있음
    • 소송 결과와 무관하게 GitHub는 duplicate detection filters를 추가했고 업계 실무도 바뀌고 있음

실무적으로 바로 할 일

  • 라이선스 스캔 실행

    • AI 보조 코드베이스에는 오픈소스 라이선스 스캔을 먼저 돌리는 편이 중요함
    • FOSSA — 엔터프라이즈에서 널리 쓰이는 종합형 도구
    • Snyk Open Source — GitHub 연동이 좋아 개발팀 워크플로에 맞기 쉬움
    • Black Duck — M&A 실사에서 표준적으로 쓰이는 편임
    • 이런 도구들은 코드베이스를 스캔해 알려진 오픈소스 라이브러리와의 일치 여부와 연결된 라이선스를 찾아줌

  • 인간 창작 기여 기록

    • 의미 있는 인간 저작성을 입증하는 자료는 평소 엔지니어링 과정에서도 이미 만들어지지만, 의도적으로 보존해야 효력이 커짐
    • 커밋 메시지는 AI가 생성한 결과 자체보다 무엇을 왜 바꿨는지를 남겨야 함
      • "Restructured Claude’s module architecture, rejected initial state management approach, rewrote error handling from scratch" 같은 기록은 근거가 됨
      • "Add rate limiting module" 같은 기록만 남으면 인간 기여를 드러내기 어려움
    • Claude Code와 Cursor의 상호작용 기록도 내보내기나 스크린샷으로 보관해 두는 편이 좋음
    • 생성 코드보다 먼저 작성된 설계 문서, ADR, 메모는 사람이 구조를 먼저 정했다는 흔적으로 쓰일 수 있음

  • 고용계약 IP 조항 확인

    • 계약서에서 intellectual property, IP assignment, work product 항목을 직접 확인해야 함
    • "근무 시간 중 만든 작업물"은 "회사 자원을 사용해 만든 작업물"보다 좁음
    • "회사 사업과 관련된 것"은 "모든 소프트웨어 개발"보다 좁음
    • company-licensed tools 문구는 개인 프로젝트에도 AI 도구 사용 흔적을 연결할 수 있음
    • 독립 프로젝트를 하려면
      • 시작 전에 서면 carveout을 협의해야 함
      • 완전히 개인 장비, 개인 시간, 개인 도구로 분리해야 함
      • 회사 주장 가능성을 감수하고 진행해야 할 수도 있음

  • Anthropic 약관 유형 확인

    • 상업용 출시에 앞서 anthropic.com/legal을 확인하고 consumer terms와 commercial terms 차이를 봐야 함
    • free / Pro는 출력물 권리를 사용자에게 넘기지만, IP indemnification 범위가 더 좁음
    • API / enterprise는 출력물 권리 양도와 함께, 승인된 사용과 출력물로 인한 저작권 침해 주장에 대해 방어 범위를 더 넓게 둠
    • 다만 이런 면책도 코드베이스 내부의 GPL 오염 문제까지 대신 해결해 주지는 않음
    • 그 부분은 라이선스 스캔과 내부 거버넌스로 직접 관리해야 함

지금 확정된 것과 아직 열려 있는 것

  • 이미 비교적 분명한 축은 세 가지임
    • 인간 저작성이 없는 저작물은 저작권 보호를 받지 못함
    • work-for-hire doctrine은 코드가 어떤 방식으로 생성됐는지와 무관하게 적용될 수 있음
    • GPL 코드의 축어적 복제는 라이선스 위반이 됨
  • 아직 법원이 명확히 가르지 않은 축은 두 가지임
    • agentic 워크플로에서 얼마나 많은 인간 지시와 수정이 있어야 충분한 저작성이 되는지
    • AI 출력이 학습 데이터 패턴을 재현했을 때 그것이 축어적 복제로 평가되는지
  • 가까운 시일 안에 이런 쟁점이 대규모 소송으로 번질지는 순수한 추측 영역으로 남아 있음
  • 실제로 이 불확실성이 가장 빨리 현실 문제가 되는 곳은 법정보다 M&A 실사와 기관 투자 심사임
  • 인수자와 투자자는 이미 거래 종결 조건으로 이런 질문을 던지고 있으며, 지금 당장 그런 상황이 아니더라도 기록과 스캔을 미리 갖춰 두는 편이 유리함

함께 보면 좋은 글 β

▲
GN⁺ 3시간전  [-]
Hacker News 의견들

  • 이건 이미지 생성 판례와 같은 형태로 봐야 함
    Zarya of the Dawn에서 이미 정리됐듯이, 사람이 쓴 요소는 보호되지만 AI가 생성한 이미지는 보호되지 않았고, 사람이 선택·프롬프트·큐레이션한 캐릭터 디자인도 저작권을 못 받았음
    코드는 다르지 않다고 봄. Claude에 함수를 만들라고 시키는 건 내가 직접 함수를 쓰는 것보다 Midjourney에 프레임을 뽑게 하는 쪽에 더 가까움
    엔지니어들이 다르게 느끼는 이유는 보통 컴파일러 비유를 떠올리기 때문인데, 컴파일러는 같은 입력이면 같은 출력이 나오는 결정론적 도구이고 LLM은 그렇지 않음. Copyright Office가 긋는 선도 바로 여기고, 이미지 쪽이 먼저 그 결론에 도달했음

    • 그렇다면 사람이 자기 이름으로 저작권 등록을 신청하는 걸 막는 게 실제로 있나 궁금함
      누군가 같은 프롬프트를 다시 써서 비슷하게 재현할 수 있다는 사실이 그 사람의 권리 주장 자체를 무효로 만드는지도 애매함

  • cert denial은 법을 확정하는 게 아님
    대법원이 상고허가를 거부하는 이유는 본안과 무관할 수도 많아서, 그 자체로 쟁점을 전국적으로 settled 시키진 못함

    • TFA에도 원래는 이렇게 적혀 있었음
      대법원이 Thaler appeal을 심리하지 않았다고 해서 하급심 논리를 승인하거나 전국적 결론을 낸 건 아니고, 다만 DC Circuit 판결은 살아남고 Copyright Office 입장은 유지되며 아직 반대 판결을 낸 법원은 없다는 취지였음
      그런데 지금 인용한 문구는 더 이상 TFA에 없음
    • 이 결론을 정면으로 시험한 사례법이 아직 부족하다고 봄
      나열된 요소들 중 무엇이 저작자성을 인정하기에 충분한지 확인해 준 판례가 떠오르지 않음
      특히 결과를 계속 거절하고 다른 방향으로 유도한 행위가 인간 저작으로 인정된 적이 있는지 알고 싶음
      현재 분명한 건 사람이 쓰지 않은 코드 부분은 disclaim할 수 있고, 실제로 Copyright Office도 공개와 disclaimer를 요구한다는 사실임. 더 인용 가능한 자료가 있으면 보고 싶음
    • 그래도 항소법원 판례 효력은 유지되는 것 아닌가 싶음
      그 판결을 뒤집었을 때의 핵심 법적 효과가 바로 그 선례 효력 상실 아닌가
      대법원 심리를 거치지 않은 판례는 이론상 언제든 다툴 수 있지만, 실제로는 대부분 그대로 법처럼 작동하다가 뒤집힐 때까지 유지됨. 이 경우도 크게 다르지 않아 보임
    • meaningful human authorship가 정확히 어떻게 정의되는지 모르겠음
      내가 코드 리뷰한 건 meaningful한가
      생성된 코드를 내가 수정하고 편집한 건 인간 저작으로 잡히나
    • 맞는 지적이라서 글을 수정했음
      cert denial은 대법원이 사건을 안 들은 것이지, 하급심 논리를 승인하거나 전국적으로 결론 낸 게 아님
      DC Circuit 판결은 살아 있고 Copyright Office 입장도 일관되지만, 이건 대법원이 확정한 법이라기보다 안정된 doctrine에 더 가까움

  • 에이전트를 지시한 사람이 결과물의 저작권을 가져야 한다고는 보지만, 애초에 그 에이전트가 만들 수 있게 된 기반 자체는 도용된 IP에 기대고 있다고 봄
    특히 OSS에서는 이런 방식이 copyright washing을 가능하게 하는 게 걱정되고, 그래서 OSS 개발자라면 자신이 감당 가능한 범위에서 가장 강한 copyleft 라이선스로 공개하는 편이 맞다고 생각함
    https://jackson.dev/post/moral-ai-licensing/

    • 저작권 업계가 copyright infringement를 슬쩍 stealing이라는 비난어로 바꿔치기한 게 재밌음
      원본을 여전히 가지고 있다면 대체 무엇이 도난당한 건가
      Dowling v. United States, 473 U.S. 207 (1985) 에서도 무단 판매가 National Stolen Property Act상 "stolen, converted or taken by fraud" 재산은 아니라고 봤음
    • copyright laundering은 환상에 가깝다고 봄
      LLM 출력이 법원에서 충분히 파생적이라고 판단되면, 특히 그 LLM이 침해된 원본으로 학습됐다면 더더욱, 그 파생 출력을 재배포한 사람이 저작권 침해 책임을 지게 됨
      LLM을 만드는 행위는 변형적일 수 있어도, 침해하는 출력 자체는 그렇지 않음
    • 저작권은 자연 상태의 권리가 아니라 정부가 science and useful arts의 진보를 촉진하려고 부여한 제도임
      그래서 저작권이 오히려 발전을 막는다면 예외를 두는 게 충분히 타당하다고 봄
    • 에이전트를 지시한 사람이 저작권을 가진다는 데에 정말 법적 근거가 있나 싶음
      Community for Creative Non Violence v. Reid(https://en.wikipedia.org/wiki/Community_for_Creative_Non-Violence_v._Reid)를 보면, 일을 발주하고 방향을 제시했다고 해서 발주자가 저작자가 되진 않고 실제로 작업한 사람이 저작자가 됨
      계약으로 권리 양도는 가능하지만, 원숭이 셀카 같은 사건들 이후로 저작권은 인간에게만 부여된다는 점도 굳어졌음
      LLM은 인간이 아니니 저작권을 가질 수 없고, 법적 저작권이 없다면 그 권리를 너에게 양도할 권한도 없음
    • 이 태도가 왜 이렇게 널리 퍼져 있는지 솔직히 이해가 잘 안 됨
      내가 코드를 쓸 때도 교육과 커리어 내내 본 수많은 소스코드의 영향을 받았고, LLM도 본 코드를 바탕으로 이후 출력을 다듬는다는 점에선 비슷함
      "그 코드는 읽을 권리가 없었다"는 반론이 바로 나오지만, 그 논리도 납득이 잘 안 됨. 내가 배운 대부분의 코드에는 저작권이 붙어 있었고, 내 개인 코드가 아닌 이상 권리는 대개 남의 것이었음. NDA나 국방 관련 기밀 코드조차 이후 내 코딩 방식에 영향을 줬음
      예술도 마찬가지임. 사진은 Ansel Adams, 그림은 Bob Ross와 여러 스승들의 영향을 받았고, 남의 작업에서 본 조각들을 내 시각과 섞어 다른 무언가를 만들었음
      그렇다고 그 영향 관계만으로 내 결과물에 대해 누가 권리를 주장할 수 있다고 보진 않음
      내 후배들도 내 코드에서 배웠고, 내가 쓴 소프트웨어 개발 책도 있음. 언젠가 내 미술 작업도 누군가 흡수할 만한 가치가 생기길 바람
      LLM이 나오기 훨씬 전부터도 내 작업이 나와 함께 봉인되고 아이디어가 무덤까지 따라오길 바란 적은 없음
      결국 우리는 모두 거인의 어깨 위에 서 있고, 선행 작업을 흡수하지 않고서는 지금 이룬 것의 극히 일부도 못 했을 것임
      몇십 년 뒤면 나는 죽고 이름도 금방 잊히겠지만, 내가 만든 소프트웨어나 사진, 그림이 시간 속에 잔물결을 남긴다면 그건 작은 불멸처럼 느껴짐

  • 생성 댓글을 HN에 그만 올려달라고 하고 싶음
    규정상 허용되지 않고, 이미 30번 넘게 그런 패턴이 보임
    물론 100% 확신할 순 없지만 소프트웨어 판단과 전체 패턴을 보면 꽤 설득력 있음
    https://news.ycombinator.com/newsguidelines.html#generated 및 https://news.ycombinator.com/item?id=47340079를 보면 됨

    • 그 지적은 맞고 사과함
      답글에 AI assistant를 썼고, 앞으로는 쓰지 않겠음

  • 이 질문은 지적 유희로는 재밌지만, 현실에선 결국 돈 가진 쪽이 가져갈 가능성이 높다고 봄
    Claude가 썼다는 이유만으로 Anthropic이 Claude Code를 못 가진다고 기대하는 건 희망 섞인 생각처럼 보임

    • 게다가 나라마다 답이 다를 가능성이 큼
      모든 국가가 돈 많은 쪽 편을 암묵적으로 드는 것도 아니니 결과를 예단하긴 어려움
    • genAI 아트는 저작권이 안 되고 genAI 코드는 된다는 식으로 흘러가면 정말 Almighty Dollar가 작동하는 셈임
    • 직감상 Anthropic이 소유할 거라는 쪽은 사실 work-for-hire doctrine이 더 잘 설명함
      Claude가 썼는지보다, 그것을 지시한 엔지니어들의 고용계약 때문에 회사가 권리를 갖는 쪽이 더 그럴듯함
      반면 DMCA 삭제 요청 문제는 더 흥미로운데, DMCA는 청구인이 저작권 소유를 선의로 주장해야 함
      나중에 법원이 코드베이스가 주로 AI가 쓴 것이어서 저작권 대상이 아니라고 보면, 그 8,000건 takedown은 bad faith DMCA 청구로 다툴 수 있음
      소유권보다 이쪽이 더 분리 가능하고 현실적인 법적 쟁점임
    • 그건 희망사항이 아니라서, 소유권이 자동으로 정해진 것도 아님
      미국 법체계에서 모델은 사람이 아니고 따라서 재산을 소유할 수도 없으며, 자신이 갖지도 못한 지식재산을 계약으로 다시 양도할 수도 없다는 건 비교적 분명해 보임
    • 악성 코드나 불법 코드, 범죄에 쓰인 코드는 기업들이 굳이 소유하고 싶어 하지 않을 것 같음
      그런데도 수사기관이 grok이 CSAM이나 revenge porn 같은 불법물을 만든다는 문제엔 별 관심이 없어 보여서, 결국 좋은 것만 소유하고 나쁜 책임은 회피하는 식이 될까 봐 이상하게 느껴짐

  • 회사들 입장에선 꽤 영악한 접근처럼 보임
    일단 claude code를 써서 만들고, 그다음에야 그 코드가 누구 것인지 고민하겠다는 식임
    지금 주변에서 벌어지는 gold rush는 경영진의 근시안을 드러낸다고 봄. 우리 회사 EM들도 최대한 빨리 Claude를 쓰라고 밀어붙임
    첫째, Claude Code에 너무 의존하면 코드베이스에 대한 이해를 잃게 됨
    둘째, XP나 코드 리뷰 같은 좋은 개발 습관이 무너짐. 이제는 Claude가 Claude의 코드를 리뷰하는 셈임
    셋째, 팀워크를 망침. 원래 FE 팀과 BE 팀이 나뉘어 있던 일을 한 개발자가 백엔드부터 프론트엔드까지 전부 몰아서 처리하는 게 더 쉽고 싸지기 때문임
    넷째, 원래는 코드 자체가 문서라며 주석을 무시했는데, 이제는 컨텍스트 한계 때문에 Claude를 위해 다시 설명을 달아야 함. 사람이 이해 못 하면 그 사람 탓이었는데, Claude의 좁은 컨텍스트를 위해선 갑자기 퇴보를 받아들이는 게 불공평하게 느껴짐
    더 말할 수 있지만, 이런 문화 변화의 동력은 결국 돈임. 그래서 이 상황을 goldrush라 부르고 팝콘 들고 지켜보는 중임

    • 사람들이 너무 빨리 잊은 것 같음
      Copilot이 처음 나왔을 때는 라이선스 귀속 문제 때문에 회사 코드엔 쓰지 말라는 경고가 분명 있었음
      지금 달라진 게 뭔가. Anthropic이 법적 방어와 indemnify를 해주겠다고 해서 분위기가 바뀐 건가
    • 다른 부분은 대체로 동의하지만, FE와 BE를 한 사람이 함께 설계하는 건 원래 더 나은 경우가 많았음
      백엔드와 프론트엔드는 서로 맞물리게 설계해야 해서, 팀이 분리돼 있으면 오히려 조정 비용이 더 커짐
    • 장기적으로는 잘못된 추상화를 도입하기가 너무 쉬워 보임
      인간의 머릿속 모델이 점점 굶주리듯 사라지면, 장애가 났을 때 어떻게 동작하는지와 앞으로의 계획을 책임 있게 설명하기도 어려워짐
      잘못된 일반화가 들어가더라도 AI들이 코드도 리뷰도 승인도 모두 통과시킬 수 있는데, 그럼 실제로 누가 운전대를 잡고 있는 건지 모르겠음
    • #3은 드물게만 더 나은 결과를 냄
      보통은 요구사항과 함정을 팀이 함께 논의하되, 구현 책임은 한 사람이 맡는 쪽이 더 낫다고 봄

  • EU AI Act가 여기에 한 겹을 더 얹음
    Article 50은 AI가 생성하거나 조작한 콘텐츠를 최종 사용자에게 공개하라고 요구하고, 이건 모델 제공자가 아니라 deployer에게 걸리는 투명성 의무임
    그래서 저작권 문제가 인간 프롬프터에게 유리하게 정리되더라도, AI 보조 결과물을 대규모로 배포하는 회사는 별도의 공개 의무를 짐
    대부분은 아직 이걸 제대로 안 하고 있음
    소유권 문제와 공개 의무는 서로 독립적인데, 조직들은 자주 둘을 섞어버림

    • 그런데 코드가 content인가 싶음
      이 조항은 내부 애플리케이션 코드보다는, AI가 만든 걸 실제처럼 속이는 영상 같은 쪽에 더 맞아 보임

  • 원하는 코드의 명세를 도구에 줬다면, 이미 창작적 입력을 준 것이라고 보는 편이 분명해 보임
    결국 컴파일러도 비슷하지 않나 싶음. LLM agent는 전통적 컴파일러보다 훨씬 고도화되어서, 훨씬 덜 상세한 명세만으로도 결과를 내는 도구처럼 보임

    • 하지만 인간 계약자에게 원하는 코드의 명세를 줬다고 해서 법원은 반복해서 그걸 저작권상 창작적 입력으로 보지 않았음
      그 코드를 소유하려면 계약자가 권리를 명시적으로 양도해야 했음
    • 명세가 항상 창작적 입력은 아님
      예를 들어 "Python으로 rate limiter를 써줘"라고만 프롬프트를 넣으면, API도 요청 버킷 알고리즘도 카운터 저장 위치도 내가 결정하지 않았음
      사실만 말했을 뿐이고, 사실 자체는 본질적으로 창작적이지 않음
      컴파일러는 결과 바이너리가 별도의 저작물로 취급되지 않는다는 점도 다름. 이미지 포맷을 PDF로 바꿔도 같은 저작물인 것과 비슷함
      반면 LLM은 그렇지 않음. 입력은 저작권 대상이 아닐 수도 있고, 출력은 기계적 변환이 아니라 선택이 개입됨
      실제 사용에서도 같은 프롬프트를 10번 돌리면 의미 있게 다른 결과가 10개 나올 수 있음
      그래서 어느 수준의 프롬프팅이든 충분한 창작성으로 인정될 거라고는 의심스러움
    • 컴파일러 비유는 적절한 출발점이지만, Copyright Office도 그 점을 직접 다뤘음
      핵심은 입력을 줬느냐가 아니라 출력의 창작적 표현이 인간 저작을 반영하느냐임
      전통적인 컴파일러에선 프로그래머가 소스의 모든 표현을 저작하지만, LLM에선 프로그래머는 의도만 주고 구조·이름·패턴·구현 같은 표현적 결정은 모델이 내림
      이 차이가 법적으로 중요한지는 Allen v. Perlmutter가 현재 다투는 중이고, 2026년 초 summary judgment 브리핑도 끝나서 다음 이정표 판결이 될 수 있음
    • 내게는 이게 결국 컴파일러가 만든 바이너리의 소유권을 묻는 것과 비슷하게 느껴짐

  • 이 모든 건 이론으로는 흥미롭지만, 실제로는 대체로 중요하지 않다고 봄
    거의 아무도 자기 코드가 강한 moat가 된다고 진지하게 믿지 않고, 저작권 대상이라는 감각도 현장에선 약함
    나도 여러 고용주 밑에서 비슷한 코드 조각을 반복해서 썼고, 대부분의 엔지니어도 그랬을 것임. Stack Overflow 같은 데서 가져온 코드도 귀속을 엄밀히 따지지 않고 쓰는 경우가 흔함
    이 이슈는 보통 앙심 섞인 싸움에서 튀어나옴. 예를 들어 Oracle이 Android에서 자사 API를 너무 비슷하게 흉내 냈다고 Google을 소송한 건 그 전형이고, 대법원은 결국 fair use로 봤음
    고빈도 헤지펀드가 퇴사 직원을 상대로 소송하는 경우도 있었고, 미국에선 누구든 어떤 이유로든 소송을 걸 수 있음
    그래서 Ellison이 Page와 Brin을 상대로 대법원까지 가는 식의 싸움은 가능하지만, 99.9%의 경우 실제 현장에선 별 영향이 없다고 느낌
    https://www.supremecourt.gov/opinions/20pdf/18-956_d18f.pdf

    • 비기술 경영진 쪽으로 가면 놀랄 정도로 다르게 생각함
      코드를 엄청난 IP이자 영업비밀로 보는 경우가 아주 많음
      CTO로서 "일반적으로 코드는 그렇게 대단한 비밀이 아니다"라고 말하면 종종 충격받은 표정을 봄
      한 회사는 NDA 하의 소스코드 공개를 요구하는 큰 계약을 거의 포기할 뻔했는데, 왜 그게 과한 반응인지 설명하자 이해하긴 했음
      그래도 그런 오래된 사고방식은 여전히 강하게 남아 있음
    • 아무도 convergence를 얘기하지 않는 게 이상함
      지금 바로 그 convergence를 말하고 있는 셈인데, 써야 할 코드의 모든 문자가 필요한 API들에 의해 사실상 미리 정해진다면 거기엔 예술적 표현도 저작권도 없음
      하지만 완전히 새로운 API를 설계한다면 그쪽은 보호를 받을 수 있음
    • 모든 오픈소스 라이선스는 코드가 저작권 대상이라는 전제 위에 세워져 있음
    • "코드는 저작권 대상이 아니다"라는 생각은 꽤 이례적이라고 봄
      네가 든 짧은 조각은 아닐 수 있어도, 더 큰 단위에선 회사와 개인 모두 코드가 저작권법상 지식재산이라고 대체로 믿음
      코드가 저작권 대상이 아니라면 GPL은 어디서 힘을 얻나
      예컨대 Microsoft 코드가 ReactOS에 섞였을 수 있다는 의심만으로도 왜 프로젝트가 몇 달, 몇 년씩 locked-down review mode에 들어가야 하나
      고용계약에서 왜 회사들이 코드 저작권 소유를 명시하겠나
      오히려 API나 상호운용성, 너무 사소한 구현을 빼면 거의 모두가 코드의 저작권성을 인정하고 있다고 봄
    • 그렇지 않다면 왜 clean room implementation이 필요하겠나 싶음
      에뮬레이터 개발자나 ReactOS 개발자들에게 물어보면 됨
      https://reactos.org/forum/viewtopic.php?t=21740

  • "Claude Code나 Cursor가 생성했고 네가 의미 있게 수정하지 않은 코드는 누구에게도 저작권이 없을 수 있다"는 말에도 예외는 있음
    그 코드가 기존 저작물의 상당한 발췌를 그대로 되뇌었다면, 원저작자는 여전히 자기 저작권을 주장할 수 있고 곧바로 침해 문제로 이어짐

답변달기