오라클이 자바 오픈소스 프로젝트인 OpenJDK에 인공지능이 생성한 코드를 제출하는 행위를 금지했다. 프로젝트 관리 주체로서 오라클이 내세운 근거는 세 가지다. 안전성, 보안, 그리고 지식재산권(IP) 리스크다. 새 방침에 따르면 개발자가 대규모언어모델(LLM)을 개인적인 용도로, 즉 코드를 디버깅하거나 검토하는 데 활용하는 것 자체는 막지 않는다. 다만 그 결과물을 저장소나 풀 리퀘스트, 그 밖의 프로젝트 채널에 직접 밀어 넣는 것은 허용하지 않는다. 도구로 쓰는 것과 산출물을 커밋 이력에 남기는 것 사이에 선을 그은 셈이다.
왜 하필 오픈소스에서 선을 긋나
이 구분은 얼핏 보수적으로 보이지만, 커뮤니티가 유지하는 공용 코드베이스의 속성을 생각하면 논리가 분명하다. 오픈소스 프로젝트에서 한 번 병합된 코드는 수많은 기업 제품 속으로 흘러 들어가고, 그 안에 저작권 귀속이 불분명한 학습 데이터의 흔적이 섞여 있을 경우 훗날 라이선스 분쟁의 뇌관이 될 수 있다. 자바처럼 광범위하게 쓰이는 런타임에서는 이런 위험이 개별 회사가 아니라 생태계 전체로 번진다. 기여자 개개인은 LLM이 어떤 코드를 근거로 특정 구현을 뱉어냈는지 증명하기 어렵고, 프로젝트 입장에서는 그 불확실성을 통째로 떠안게 된다. 안전성과 보안을 함께 언급한 것도 검증되지 않은 자동 생성 코드가 미묘한 결함을 남길 수 있다는 우려로 읽힌다.
주목할 대목은 이 방침이 오라클 자신의 대내적 행보와 정면으로 어긋난다는 점이다. 공동 창업자 래리 엘리슨은 최근 AI 모델이 이제 오라클의 코드를 작성한다고 공언했고, 공동 최고경영자 마이크 시칠리아는 AI 도구 덕분에 더 작은 엔지니어링 팀이 더 빠르게 결과물을 낸다고 평가했다. 한쪽에서는 사내 생산성의 핵심 동력으로 AI 코드 생성을 내세우면서, 자신이 관리하는 오픈소스에서는 같은 방식의 산출물을 문 앞에서 막아선 것이다.
모순이 아니라 책임 소재의 문제
이 간극을 단순한 위선으로 볼 수도 있지만, 실무 관점에서는 오히려 책임 소재의 차이로 해석하는 편이 정확하다. 사내 제품에서 AI가 쓴 코드는 오라클이라는 단일 법인이 통제하고, 문제가 생기면 그 회사가 책임진다. 반면 커뮤니티 프로젝트의 코드는 익명에 가까운 다수가 기여하고, 사후에 출처를 되짚거나 법적 책임을 물리기가 훨씬 까다롭다. 통제 범위와 배상 주체가 명확한 곳과 그렇지 않은 곳에서 같은 기술을 다르게 다루는 것은, 모순이라기보다 리스크 관리의 현실적 귀결에 가깝다.
한국의 개발 조직에도 시사하는 바가 크다. 많은 팀이 이미 코파일럿류 도구를 일상적으로 쓰고 있지만, 그 산출물을 사내 저장소에 커밋할 때와 외부 오픈소스에 기여할 때 적용해야 할 잣대는 같지 않다. 오라클의 방침은 'AI를 쓰지 말라'가 아니라 'AI를 보조 도구로 쓰되 최종 기여물의 출처와 책임은 사람이 진다'는 원칙으로 요약된다. 사내 기여 정책을 세울 때, 개인적 활용과 공개 제출을 분리하고 기여자에게 저작권 귀속을 확인하도록 하는 것은 곧바로 참고할 만한 틀이다.
한편 이 소식은 오라클을 둘러싼 재무적 긴장과도 겹쳐 있다. 오라클은 올해 데이터센터 확장에 700억 달러를 투입하고 있는데, 이 대규모 지출을 두고 신용평가사 S&P는 투자 대비 회수가 불확실하다는 이유로 오라클의 신용등급을 정크 등급 한 단계 위인 BBB-로 낮췄다. AI 인프라에 막대한 자본을 쏟아부으면서 정작 AI 산출물의 유입은 특정 영역에서 차단하는 구도는, 이 회사가 AI를 성장 동력으로 삼는 동시에 그 위험을 신중히 격리하려 한다는 이중적 태도를 드러낸다.
다만 이번 발표는 정책의 방향을 제시할 뿐, 실효성에는 한계가 남는다. AI가 생성한 코드는 사람이 손본 코드와 겉으로 구별하기 어렵고, 기여 단계에서 이를 기술적으로 걸러낼 확실한 방법은 아직 없다. 결국 이 금지 조치는 자동 탐지보다 기여자의 자기 신고와 프로젝트의 신뢰에 기댈 수밖에 없다. 그럼에도 자바 생태계를 이끄는 주체가 공식 규범을 명문화했다는 사실 자체가 다른 오픈소스 프로젝트와 기업 내부 정책의 기준점이 될 가능성이 크다.