래리 엘리슨은 'AI가 코드 짠다'고 했는데, OpenJDK는 AI 코드를 금지했습니다

같은 회사에서 정반대 메시지가 나오면 보통 둘 중 하나입니다. 조직이 엇박자를 내고 있거나, 아니면 둘 다 진심인데 적용되는 무대가 다르거나요. 오라클과 OpenJDK 사이에서 벌어진 일이 딱 그렇습니다. 한쪽에서는 “이제 사람이 코드를 안 짠다"고 말하는데, 다른 쪽에서는 “AI가 짠 코드는 받지 않겠다"고 못을 박았습니다.

먼저 짚고 갈 게 있는데요. 이 주제는 커뮤니티에서 아직 크게 불붙지 않았습니다. 최근 한 달간 레딧에서 유의미한 스레드를 찾기 어려웠습니다. 그래서 오늘 글은 실시간 여론 중계가 아니라, 오픈소스 기여 정책과 AI 코드 저작권이라는 구조적인 문제를 짚는 쪽에 가깝습니다.

오라클은 정말 코드를 안 짜게 될까

래리 엘리슨이 반복해온 이야기의 골자는 단순합니다. AI가 애플리케이션을 만들고 사람은 그 결과를 검토하며 방향을 잡는다는 겁니다. 실제로 오라클은 자사 클라우드와 데이터베이스 제품군 전반에 AI 코드 생성 기능을 붙이는 데 공을 들여왔습니다.

이건 마케팅 수사만은 아닙니다. 사내 개발이든 고객사 개발이든, AI가 초안을 뽑고 사람이 다듬는 방식은 이미 현실입니다. 문제는 이 방식이 모든 코드베이스에 똑같이 통하느냐입니다.

OpenJDK가 문을 닫은 이유

OpenJDK는 자바 표준 구현체입니다. 전 세계 수백만 개의 서비스가 이 위에서 돌아갑니다. 은행 시스템이 그렇고, 안드로이드 생태계도 상당 부분 그렇습니다. 대기업 백엔드도 마찬가지고요.

이런 코드베이스에 기여하려면 OCA(Oracle Contributor Agreement)에 서명해야 합니다. 핵심은 이 문장입니다. “내가 제출하는 코드는 내가 직접 작성했고, 제3자의 권리를 침해하지 않는다.”

여기서 AI 생성 코드가 걸립니다. 대형 언어 모델은 GPL, AGPL, 상용 라이선스가 섞인 거대한 코드 더미를 학습했습니다. 모델이 뱉어낸 코드 조각이 어디서 왔는지는 기여자 본인도 모릅니다. 그러니 “내가 작성했다"는 서약에 서명할 수가 없습니다. 서명하면 거짓말이 되고, 안 하면 기여를 못 합니다.

진짜 문제는 저작권이 아니라 ‘누가 책임지는가’

법적 리스크만 놓고 보면 확률은 낮습니다. AI가 만든 열 줄짜리 유틸리티 함수가 특정 GPL 프로젝트 코드와 정확히 일치할 가능성은 크지 않으니까요.

하지만 OpenJDK 같은 프로젝트에서 중요한 건 확률이 아니라 추적 가능성입니다. 10년 뒤에 어떤 코드 조각의 출처를 두고 분쟁이 생기면, 프로젝트는 “이건 누가, 언제, 어떤 근거로 넣었다"고 답할 수 있어야 합니다. 기여자가 AI에게 물어봤고 AI가 이렇게 답했다는 건 답이 안 됩니다.

오라클 입장에서 자바는 이미 여러 차례 법정에 다녀온 자산입니다. 구글과의 API 저작권 소송은 대법원까지 갔습니다. 이 조직이 코드 출처 문제에 유독 보수적인 데는 그만한 이유가 있습니다.

모순이 아니라 ‘무대의 차이’

그래서 저는 이걸 앞뒤가 안 맞는 이야기라기보다 영역별로 규칙이 갈리기 시작한 신호로 봅니다.

기업이 자기 서버에서 굴리는 내부 애플리케이션이라면 AI가 코드를 대량으로 뽑아내도 괜찮습니다. 문제가 생기면 회사가 책임지면 되니까요. 반면 전 세계가 공유하는 기반 인프라, 그것도 라이선스 계보가 명확해야 하는 코드베이스는 다릅니다. 여기서는 코드의 품질보다 출처를 먼저 따져야 합니다.

리눅스 커널이나 주요 암호화 라이브러리, 결제 인프라 코드에도 같은 논리가 통합니다. 이미 여러 오픈소스 프로젝트가 비슷한 고민을 시작했습니다.

개발자에게 실질적으로 남는 질문

당장 실무자가 부딪히는 문제는 이겁니다. 내가 지금 커밋하려는 코드는 어느 무대에 올라가는가.

사내 프로젝트라면 AI를 적극적으로 쓰는 게 합리적입니다. 반면 오픈소스에 PR을 보낼 거라면 그 프로젝트의 기여 가이드를 먼저 읽어야 합니다. AI 사용 여부를 명시하라는 항목이 늘고 있습니다. 무심코 복사한 자동완성 결과가 프로젝트 전체를 법적 회색지대로 끌고 들어갈 수 있으니까요.

기술 도입 속도와 법적 안전성은 원래 같이 가기 어렵습니다. 오라클은 그 둘을 다른 조직, 다른 문서로 나눠서 관리하기로 했습니다.

AI 코딩 도구를 둘러싼 이야기가 생산성에서 라이선스와 책임 쪽으로 옮겨가고 있습니다. 코드를 빨리 만드는 일보다 그 코드가 어디서 왔는지 설명하는 일이 더 중요해집니다. 어제 커밋한 코드의 출처를 5년 뒤에 설명할 수 있으신가요?