Oracle은 왜 OpenJDK의 AI 생성 기여를 막았을까

Oracle은 왜 OpenJDK의 AI 생성 기여를 막았을까

AI 뉴스 썸네일

Oracle이 OpenJDK에 AI가 만든 코드와 문서, 이미지가 들어오는 것을 임시로 막았어요. 사내 개발에는 AI 코딩을 빠르게 도입하면서 공개 프로젝트의 외부 기여에는 더 엄격한 기준을 적용한 셈이에요. 이번 조치는 AI 도구의 사용 자체보다 결과물의 출처와 검증 책임을 어디까지 추적할 수 있느냐에 초점을 맞춰요. 1

핵심 요약

구분	핵심	왜 볼 만한가요
적용 대상	AI가 일부라도 생성한 코드, 텍스트, 이미지의 OpenJDK 기여를 금지해요	소스 코드뿐 아니라 PR, 이메일, 위키, 버그 이슈까지 범위가 넓어요
허용 범위	코드 이해, 디버깅, 리뷰, 연구를 위한 개인적 AI 사용은 허용해요	AI 사용과 AI 결과물 제출을 별도 행위로 나눈 정책이에요
도입 배경	리뷰 부담과 안전, 보안, 지식재산권 위험을 이유로 들었어요	주요 런타임 프로젝트가 생성 코드의 검증 비용을 어떻게 보는지 드러나요
정책 성격	정식 기준을 만드는 동안 적용하는 임시 규칙이에요	향후 허용 조건과 증빙 방식이 달라질 여지가 있어요

1. AI 도구는 쓸 수 있지만 생성 결과물은 제출할 수 없어요

OpenJDK가 공개한 임시 정책은 대규모 언어 모델과 확산 모델 등 딥러닝 시스템이 일부 또는 전부 만든 콘텐츠를 기여물에 포함하지 못하게 해요. 적용 범위에는 소스 코드뿐 아니라 텍스트와 이미지도 들어가요. Git 저장소와 GitHub 풀 리퀘스트, 이메일, 위키 페이지, Java Bug System 이슈도 같은 기준을 받아요. 2

개발자가 AI 도구를 아예 쓰지 못하는 것은 아니에요. 기존 코드를 이해하거나 디버깅하고, 리뷰와 연구를 돕는 개인 도구로는 사용할 수 있어요. 다만 그 과정에서 모델이 만든 출력물을 복사해 공개 기여물에 넣으면 정책을 어겨요. 사용 여부보다 제출물의 생성 주체와 추적 가능성을 기준으로 선을 그은 방식이에요.

728x90

Oracle은 사람이 검토해야 할 작업량이 늘 수 있다는 점을 먼저 들었어요. 생성 코드는 문법적으로 자연스러워 보여도 경계 조건이나 보안 가정을 놓칠 수 있어요. OpenJDK는 여러 조직의 핵심 시스템을 받치는 Java 구현체라서 작은 오류도 넓은 범위에 영향을 줄 수 있어요. 출처가 불분명한 코드가 섞이면 저작권과 라이선스 판단도 어려워져요. 3

이 기준은 Oracle 내부의 AI 코딩 활용과 나란히 놓이면서 더 눈에 띄었어요. Larry Ellison은 2025년 행사에서 개발자가 의도를 설명하면 모델이 프로그램의 절차를 작성하는 개발 방식을 소개했어요. 공동 CEO Mike Sicilia도 더 작은 엔지니어링 팀이 AI 코딩 도구로 더 완성도 높은 결과를 빠르게 낼 수 있다고 말했어요. 사내 코드에는 내부 검토 절차와 책임 주체가 있지만, 공개 프로젝트의 외부 기여는 생성 과정과 권리 관계를 같은 수준으로 확인하기 어렵다는 차이가 있어요. 다만 Oracle은 기사 공개 시점까지 내부 AI 생성 코드를 어떤 절차로 안전하게 검증하는지 구체적으로 밝히지 않았어요. 3

기여자가 확인할 부분

OpenJDK에 참여하는 개발자는 자동완성 한 줄도 모델이 만든 결과인지 구분해야 해요. AI로 문제를 분석한 뒤 사람이 직접 다시 작성한 코드도 생성 과정의 경계를 설명하기 어려울 수 있어요. 현재 규칙은 임시 정책이라서 애매한 사례를 허용한다고 가정하기보다 프로젝트 메일링 리스트와 최종 정책을 확인하는 편이 안전해요.

기업이 사내 오픈소스 기여 지침을 만들 때도 도구 이름만 허용하거나 금지해서는 부족해요. 분석 보조, 코드 생성, 테스트 생성, 문서 작성처럼 사용 단계를 나누고 결과물 제출 가능 여부를 따로 정해야 해요. 작성 이력과 사람의 검토 기록, 라이선스 확인 책임도 함께 남겨야 실제 리뷰 과정에서 기준을 적용할 수 있어요.

왜 중요한가요

OpenJDK의 선택은 AI 코딩 정책이 생산성만으로 정해지지 않는다는 현실을 보여줘요. 유지 관리자는 코드가 빨리 만들어졌는지보다 누가 책임지고 검증했는지, 권리 관계를 확인할 수 있는지를 봐요. 특히 많은 서비스가 의존하는 런타임과 보안 라이브러리는 오류 한 건의 영향 범위가 넓어서 리뷰 비용을 보수적으로 계산할 수밖에 없어요. 2

개발 조직에는 사용 허용과 기여 허용을 분리해서 문서화해야 한다는 숙제가 생겨요. “AI 코딩 도구 사용 가능”이라는 한 줄만 두면 자동완성, 생성 테스트, 문서 초안, 외부 저장소 기여의 기준이 섞여요. 저장소별 규칙과 검토 책임자를 정하고, 모델이 만든 부분을 추적할 방법까지 마련해야 정책이 실제 작업 흐름에서 작동해요.

이번 규칙은 최종안이 아니에요. OpenJDK는 정식 생성형 AI 정책을 작성하는 동안 기본값으로 적용한다고 밝혔어요. 앞으로 제한적 허용, 생성 사실 표시, 사람의 재작성 기준처럼 더 세밀한 조건이 추가될지는 최종 문서를 확인해야 해요. 현재 확인되는 결론은 분명해요. AI를 분석 도구로 쓰는 것은 허용하지만 그 출력물을 OpenJDK 기여물로 제출하는 것은 허용하지 않아요. 1

참고 자료

1. Oracle, 사내 AI 코딩은 장려하면서 OpenJDK에는 AI 생성 코드 기여 금지 — GeekNews
2. OpenJDK Interim Guidance for Generative AI — OpenJDK
3. As Larry Ellison bets the farm, Oracle says it loves AI-written code, just not in OpenJDK — The Register