AI가 만든 코드도 출처를 증명해야 하는 시대가 온다

AI 컴플라이언스의 질문이 바뀌고 있음

• 생성형 AI가 산업 전반에 퍼지면서 기업 관심사가 저작권, 오픈소스 라이선스, 학습데이터 관리, 공급망 투명성으로 이동하고 있음

  • AI가 만든 결과물의 법적 책임
  • 학습데이터 출처 검증
  • 글로벌 규제 대응
  • 이 세 가지가 이제 경영 과제로 올라온 상태임

• ‘오픈소스 & AI 컨퍼런스 2026’에서도 핵심 메시지는 비슷했음

  • AI 활용 확대는 피하기 어렵지만, 저작권·데이터 거버넌스·공급망 투명성을 같이 관리해야 한다는 공감대가 형성됨
  • 업계에서는 앞으로 기업 경쟁력이 “무엇을 만들었나”보다 “어떻게 만들었는지 설명할 수 있나”에서 갈릴 수 있다고 봄

AI 산업의 다음 리스크는 법률과 규제

• 임형주 율촌 AI DC센터장은 AI 산업이 기술 경쟁을 넘어 법률·규제 검증 단계로 들어갔다고 봄

  • 가트너 하이프사이클을 언급하며, 현재 AI 산업의 캐즘 원인 중 하나가 기술 자체가 아니라 기존 권리 체계 및 규제와의 충돌이라고 설명함
  • 한국 AI 기본법과 유럽연합(EU) AI Act 같은 규제가 본격 시행되면서 잠재적 리걸 리스크가 현실화되고 있다는 진단임

• AI 저작권 분쟁은 이미 빠르게 늘고 있음

  • 게티이미지와 스태빌리티 AI
  • 뉴욕타임스와 오픈AI
  • 주요 음반사와 AI 스타트업 간 소송이 대표 사례로 언급됨
  • 게티이미지 사례에서는 워터마크가 포함된 이미지가 AI 학습에 쓰였다는 의혹이 논쟁거리로 소개됨

• 미국 법원은 생성형 AI 학습 분쟁에서 공정이용(Fair Use)을 중심으로 판단을 이어가고 있음

  • 핵심 기준은 해당 활용이 원저작물 시장에 실질적 피해를 주는지 여부임
  • 기존 권리자와 경쟁관계에서 시장 잠식 효과가 발생하는지도 중요한 판단 포인트로 제시됨
  • 국내에서도 방송사와 AI 기업 간 소송 결과가 향후 중요한 기준이 될 수 있다고 전망됨

AI가 만든 코드도 라이선스 책임을 피하지 못함

• 마이크 피텐저 Insignary 최고전략책임자는 생성형 AI가 오픈소스 라이선스 관리에 새로운 위험을 만들고 있다고 지적함

  • 오픈소스는 이미 현대 소프트웨어 개발의 표준이 됐고, 대부분의 소프트웨어가 다양한 오픈소스 구성요소에 의존함
  • 문제는 AI 코딩 도구 이후 기존 방식으로 확인하기 어려운 숨겨진 종속성(Hidden Dependencies)이 늘고 있다는 점임

• AI는 학습한 오픈소스 코드를 바탕으로 특정 기능을 수행하는 코드 조각을 다시 생성할 수 있음

  • 이 스니펫은 패키지 관리자나 빌드 파일에 기록되지 않을 수 있음
  • 그러면 기존 소프트웨어 구성 분석(SCA) 도구나 소프트웨어 자재명세서(SBOM)에서도 빠질 수 있음
  • 하지만 코드 조각이 작아도 원 라이선스 의무가 사라지는 건 아님

• 특히 GPL 같은 카피레프트 계열 라이선스 코드가 섞이면 파생저작물 논란으로 이어질 수 있음
  • 단순히 “AI가 만들어준 코드라 몰랐다”는 말로는 리스크를 피하기 어려워질 수 있다는 얘기임
  • 그래서 스니펫 수준까지 가시성을 확보하는 거버넌스와 기술 통제가 필요하다고 강조됨

AI-BOM은 데이터 공급망을 증명하는 장치

• 조정원 LG AI연구원 변호사는 AI 학습데이터 관리의 중요성을 강조함

  • 오픈소스 컴플라이언스는 오랜 기간 표준화가 진행됐지만, AI 학습데이터는 아직 관리 기준이 충분히 정립되지 않았다는 설명임
  • 미국과 유럽의 저작권 분쟁도 결국 데이터 출처와 이용 적법성 문제로 귀결되고 있다고 봄

• 국가마다 AI 학습과 결과물에 대한 판단 기준이 달라질 수 있다는 점도 리스크임

  • 같은 AI 서비스라도 어느 국가 법원이 판단하느냐에 따라 결론이 달라질 수 있음
  • 기업은 데이터 출처, 라이선스, 가공 이력, 재배포 과정을 추적할 수 있는 증빙 체계를 갖춰야 함

• 이 맥락에서 AI-BOM은 단순 문서가 아니라 데이터 공급망을 설명하는 근거 체계로 제시됨

  • 앞으로 기업은 어떤 데이터를 사용했는지
  • 어떤 과정을 거쳐 모델을 만들었는지
  • 그 데이터가 어떤 법적·계약적 조건을 갖는지 입증해야 하는 상황을 맞게 될 수 있음

SBOM 품질이 공급망 신뢰가 되는 흐름

• 소니그룹 오픈소스 수석 전략가는 글로벌 공급망 규제 확산 속에서 SBOM 품질 확보가 중요하다고 강조함

  • 미국 NTIA와 CISA, EU 사이버복원력법(CRA) 등 여러 규제가 등장하면서 기업은 서로 다른 요구사항에 동시에 대응해야 함
  • 과거 SBOM은 사람이 라이선스와 취약점을 확인하는 문서에 가까웠지만, 공급망 규모가 커지면서 수작업 검증만으로는 한계가 왔다는 설명임

• 앞으로 중요한 건 정확한 식별 정보와 추적 가능한 메타데이터임

  • 패키지를 정확히 식별할 수 있어야 하고
  • 공급망 참여자끼리 정보를 원활하게 교환할 수 있어야 하며
  • SBOM의 품질이 곧 공급망 신뢰성으로 이어진다는 메시지임

sequenceDiagram
    participant 개발팀 as 개발팀
    participant AI as 생성형 AI 도구
    participant 저장소 as 코드 저장소
    participant 검증 as SCA/SBOM 검증
    participant 법무보안 as 법무·보안팀

    개발팀->>AI: 기능 구현 요청
    AI-->>개발팀: 코드 스니펫 생성
    개발팀->>저장소: 코드 반영
    저장소->>검증: 의존성과 스니펫 분석
    검증-->>법무보안: 숨겨진 오픈소스·라이선스 리스크 보고
    법무보안-->>개발팀: 수정 또는 증빙 요청

기술 맥락

• AI 생성 코드의 까다로운 점은 출처가 패키지처럼 깔끔하게 남지 않을 수 있다는 거예요. npm이나 Maven 의존성처럼 목록에 잡히면 SCA와 SBOM으로 추적하기 쉬운데, AI가 코드 조각 형태로 재생성하면 빌드 파일에 흔적이 없을 수 있거든요.

• 그래서 기존 SCA만으로 충분하지 않을 수 있다는 얘기가 나와요. 기사에서 언급된 연구처럼 기존 SCA가 전체 종속성의 약 23%만 식별했다면, 기업은 패키지 단위뿐 아니라 스니펫 단위 유사성이나 라이선스 흔적까지 봐야 해요.

• AI-BOM은 이 문제를 데이터 쪽으로 확장한 개념이에요. 모델이 어떤 데이터를 먹었고, 그 데이터가 어떤 권리와 제한을 갖는지 설명하지 못하면 나중에 저작권이나 개인정보 분쟁에서 방어하기 어려워져요.

• 결국 개발팀의 실무도 달라져요. AI 도구로 코드를 빨리 만드는 건 좋지만, 저장소에 들어가는 순간 그 코드는 회사 제품의 일부가 돼요. 그러면 보안팀과 법무팀이 이해할 수 있는 출처, 라이선스, 구성요소 정보가 같이 따라와야 해요.