오픈소스 프로젝트를 장기 운영 기반으로 채택할 때, 팀이 주로 확인하는 것은 라이선스 종류, 커뮤니티 활성도, 기능 커버리지 정도다. 그런데 최근 몇 년 사이 확인 목록에 추가해야 할 항목이 하나 더 생겼다. 그 프로젝트가 LLM 학습에 코드베이스를 제공했는지, 혹은 AI로 생성된 코드를 병합하고 있는지다.
이것이 단순한 윤리적 선호 문제처럼 보일 수 있지만, 실제로는 라이선스 해석 분쟁, 데이터 계보 추적 불가, 포크 비용 증가라는 세 가지 운영 리스크로 이어진다. 그리고 이 리스크는 프로젝트를 이미 프로덕션에 올린 뒤에 발견하면 걷어내기가 훨씬 어렵다.
LLM이 코드베이스에 진입하는 경로는 하나가 아니다
프로젝트가 AI와 연루되는 방식은 생각보다 다양하다. 가장 명시적인 경우는 메인테이너가 LLM으로 생성한 코드를 직접 병합하는 것이다. 그 외에도 AI 기반 코드 리뷰 도구를 CI/CD 파이프라인에 통합하거나, 이슈 트래커에 AI 요약·분류 기능을 적용하거나, 프로젝트 로고나 문서 삽화에 생성형 이미지를 쓰는 경우도 있다. 어떤 프로젝트는 특정 AI 서비스 제공업체와 스폰서십 계약을 맺고 로고를 노출하기도 한다.
이 각각이 왜 다른 수준의 위험을 만드는지 생각해볼 필요가 있다. 코드 자체에 AI 생성 기여가 섞이면, 저작권 귀속이 불분명한 코드가 프로덕션 시스템에 들어온다는 뜻이다. AI 코드 리뷰 도구가 코드베이스 전체를 학습에 쓸 수 있는 조건으로 연동되어 있다면, 팀이 작성한 코드가 외부로 전송되는 경로가 생긴다. 스폰서십이나 도구 통합을 통해 특정 AI 제공업체에 종속되면, 그 제공업체의 정책이 바뀔 때 프로젝트 운영 방식도 함께 흔들린다.
어느 하나도 벤더 선정 단계에서 명시적으로 검토하지 않으면, 나중에 계약 조건이나 내부 규정과 충돌하는 시점에야 드러난다.
라이선스 위험: 조건이 바뀌면 기존 허락도 다시 읽어야 한다
오픈소스 라이선스는 코드를 공개 시점의 조건으로 사용할 권리를 부여한다. 그런데 그 코드의 일부가 LLM 학습 데이터로 사용되었거나, 반대로 LLM이 생성한 코드가 기여로 병합된 경우, 기존 라이선스 해석이 그대로 적용될 수 있는지는 아직 법적으로 확립된 영역이 아니다.
특히 Copyleft 계열 라이선스(GPL, AGPL 등)는 파생 저작물의 범위를 어떻게 보느냐에 따라 해석이 달라질 수 있다. AI가 해당 라이선스 코드를 학습해 생성한 결과물이 파생 저작물에 해당하는지, 그리고 그 코드를 자신의 프로덕트에 포함시켰을 때 어떤 의무가 생기는지는 현재 여러 법적 분쟁과 논의가 진행 중이다.
실무에서 이것은 어떤 의미인가. 법적 결론이 아직 없다는 것이 오히려 리스크다. 판결이 나오기 전까지는 보수적으로 해석해야 하고, 보수적 해석은 해당 코드를 포함한 제품의 배포 조건에 제약이 생길 수 있다는 뜻으로 읽어야 한다. 기업 환경에서 소프트웨어를 납품하거나 SaaS로 운영한다면, 이 불확실성을 요구사항 문서에 명시하고 법무팀과 미리 정렬해두는 것이 현실적인 대응이다.
데이터 추적 가능성: 어디서 온 코드인지 나중에도 증명할 수 있어야 한다
금융, 의료, 공공 조달 영역에서는 사용 중인 소프트웨어 구성 요소의 출처를 SBOM(소프트웨어 부품 명세서) 형태로 제출해야 하는 요건이 점점 명시화되고 있다. 여기에 AI 생성 코드가 섞여 있으면 문제가 생긴다. AI가 생성한 코드는 어떤 데이터를 학습했는지, 그 데이터에 어떤 라이선스가 걸려 있었는지를 역추적하기가 사실상 어렵기 때문이다.
의존성 분석 도구는 보통 소스 파일의 저자, 커밋 이력, 라이선스 헤더를 기반으로 추적 경로를 만든다. AI 생성 코드는 이 체인에서 '저자가 LLM'이라는 불분명한 노드를 만들고, 이후 감사 요청이 들어왔을 때 추적 경로가 끊긴다. 규제 환경이 엄격한 업종일수록 이 공백이 컴플라이언스 리스크로 직결된다.
채택을 검토하는 프로젝트에 AI 생성 기여가 포함되어 있다면, 그 규모와 범위를 커밋 이력과 릴리스 노트로 확인할 수 있는지 먼저 살펴봐야 한다. 확인이 안 된다면, 해당 프로젝트를 데이터 추적 가능성을 요구하는 시스템의 의존성으로 사용하는 것은 주의가 필요하다.
포크 비용: '가능하다'와 '현실적이다'는 다르다
프로젝트가 요구사항과 맞지 않는 방향으로 바뀌기 시작하면 포크가 선택지로 등장한다. 포크 자체는 오픈소스 생태계에서 자연스러운 일이지만, 포크가 실제로 지속 가능한지는 별개의 판단이다.
포크를 결정하기 전에 확인해야 할 것은 세 가지다.
첫째, AI 기여가 포함되기 이전의 커밋 지점을 특정할 수 있는가. 일부 프로젝트 목록에서는 이른바 "마지막으로 오염되지 않은 커밋(last untainted commit)"을 함께 관리한다. 이 정보가 없으면 포크 기준점 자체를 찾는 데 상당한 시간이 필요하다.
둘째, 그 기준점 이후 업스트림이 얼마나 빠르게 변화했는가. 보안 패치, 버그 수정, API 변경이 빈번한 프로젝트라면, 포크를 유지하면서 이것들을 선별 적용하는 비용이 새 대안을 평가하는 비용보다 클 수 있다.
셋째, 팀 내에 해당 코드베이스를 장기 유지할 역량이 있는가. 포크는 시작이 아니라 유지가 더 어렵다. 메인테이너 부재, 문서화 미비, 커뮤니티 이탈이 예상되는 경우라면 포크보다 대체 프로젝트로의 전환이 현실적으로 낮은 비용일 수 있다.
요구사항 단계에서 묻지 않으면 나중에 기술 부채가 된다
이 세 가지 문제를 요구사항 단계에서 다루기 어렵게 만드는 것은 오픈소스 채택 결정이 대개 기능과 라이선스 종류 확인으로 끝나기 때문이다. AI 관련 정책은 Readme나 기여 가이드에 명시되지 않는 경우가 많고, 이슈 트래커나 릴리스 노트를 직접 확인해야 드러나는 경우가 많다.
벤더 선정 체크리스트에 아래 질문을 추가하는 것이 현실적인 출발점이다.
- 이 프로젝트의 기여 가이드에 AI 생성 코드에 관한 명시적 정책이 있는가.
- 최근 6개월 이내 병합된 PR 중 AI 도구를 사용했음을 명시한 기여가 있는가.
- 프로젝트가 특정 AI 서비스와 스폰서십이나 통합 관계를 맺고 있는가.
- 이슈 트래커나 코드 리뷰 과정에서 AI 도구가 외부로 코드를 전송하는 조건으로 사용되는가.
- SBOM 제출이 필요한 환경이라면, 해당 프로젝트의 기여 이력이 감사 가능한 형태로 유지되고 있는가.
이 질문들에 대한 답을 미리 확보하면, 프로젝트를 도입한 뒤에 방향이 맞지 않는다는 사실을 발견하는 상황을 상당히 줄일 수 있다. 모든 팀이 동일한 기준을 적용할 이유는 없다. 하지만 어떤 기준을 적용하는지 명시하지 않으면, 나중에 그 결정을 되돌아봤을 때 판단 근거를 설명할 수 없다.
상황에 따라 판단 기준이 달라지는 구간
규제 요건이 없고 내부 도구에만 사용하는 경우라면, AI 관련 정책이 없는 프로젝트도 현실적인 선택지일 수 있다. 반면 고객 데이터를 처리하거나, 소스 코드 출처를 납품 조건에 명시해야 하거나, 의료나 금융처럼 감사 추적성이 법적 요건인 시스템이라면 이 판단 기준을 더 엄격하게 적용해야 한다.
프로젝트 초기에 "이 의존성을 장기적으로 교체하거나 포크할 수 있는가"를 가정하고 아키텍처를 설계하는 것도 방법이다. 핵심 기능을 외부 오픈소스에 단단히 결합하지 않고, 교체 가능한 어댑터 구조로 두면 나중에 방향이 바뀌어도 대응 비용이 낮아진다. 이것은 AI 관련 리스크에 한정된 이야기가 아니지만, 지금은 이 리스크가 빠르게 현실화되고 있는 영역이라는 점에서 특히 해당된다.
채택 결정을 내리기 전에 포크 기준점과 대체 프로젝트 목록을 함께 정리해두는 것이 먼저다. 나중에 포크가 필요해졌을 때 그것을 조사하기 시작하면 이미 늦다.
