OpenJDK AI 금지, 오픈소스의 새 방화벽

Oracle은 AI를 밀지만 OpenJDK는 막는다

OpenJDK의 Interim Policy on Generative AI는 간결하지만 파급력이 크다. 정책은 OpenJDK Community 기여자가 생성형 AI 도구를 개인적으로 사용해 코드를 이해하고, 디버그하고, 리뷰하는 것은 허용한다. 그러나 대형 언어 모델, diffusion 모델, 유사 딥러닝 시스템이 전부 또는 일부 생성한 콘텐츠를 OpenJDK 저장소, GitHub pull request, 메일, wiki, JBS 이슈에 포함해서는 안 된다고 못박는다. The Register와 InfoQ가 2026년 8월 초 이 정책을 다시 조명하면서 논쟁이 커졌다.

겉으로 보면 모순처럼 보인다. Oracle은 클라우드와 데이터센터에서 AI 인프라를 강하게 밀고 있고, 기업 제품에는 AI 기능을 적극 붙인다. 그런데 회사가 후원하는 OpenJDK에서는 AI 생성 기여를 막는다. 하지만 이 긴장은 오히려 현실적이다. 내부 제품 개발에서 AI를 쓰는 것과 수십 년 유지될 공개 플랫폼에 출처가 불명확한 코드를 받아들이는 것은 다른 문제다. Codex Security 오픈소스, 보안 리뷰의 새 기준이 보여주듯 AI가 보안 검토를 돕는 일과 AI 산출물이 검토 책임을 흐리는 일은 분리해서 봐야 한다.

금지의 핵심은 저작권보다 운영 비용이다

OpenJDK 정책은 저작권, 라이선스, 특허, 품질, 유지보수 가능성을 모두 건드린다. 생성형 AI가 어떤 학습 데이터에서 어떤 코드를 끌어왔는지 기여자가 설명하지 못하면, 프로젝트는 나중에 법적 또는 기술적 비용을 떠안을 수 있다. 자바 표준 라이브러리와 JVM은 수많은 기업 시스템의 기반이므로 작은 불확실성도 크게 확산된다. OpenJDK가 임시 정책이라는 표현을 쓴 것도 기술과 법적 환경이 아직 안정되지 않았기 때문이다.

더 실무적인 문제는 리뷰 비용이다. AI가 만든 패치는 그럴듯해 보이지만, 엣지 케이스와 장기 유지보수 맥락을 놓치기 쉽다. 리뷰어는 코드뿐 아니라 생성 과정과 프롬프트, 사람이 이해했는지 여부까지 의심해야 한다. LLM 코딩은 10배가 아니라 2배에 가깝다가 강조한 피드백 루프가 오픈소스에서는 더 비싸다. 유지관리자는 무료 QA 인력이 아니며, AI 패치가 늘수록 사람 리뷰의 희소성이 더 커진다.

다른 오픈소스는 같은 결론에 도달하지 않을 수 있다

흥미로운 점은 OpenJDK의 선택이 보편 규칙은 아니라는 것이다. arXiv의 AI Policy, Disclosure, and Human in the Loop 연구는 인기 GitHub 저장소 1,000개에서 발견한 AI 정책 118개를 분석했고, 그중 다수는 AI 보조 기여를 허용하되 공개와 사람 검토를 요구하는 방향이었다고 보고한다. 즉 오픈소스 생태계의 기본값은 하나로 정해지지 않았다. 프로젝트의 위험도, 사용자 규모, 법적 노출, 리뷰어 여력에 따라 정책이 갈린다.

한국 기업이 운영하는 공개 SDK나 사내 오픈소스 프로그램도 같은 결정을 해야 한다. 모든 AI 기여를 막으면 생산성 기회를 잃고, 모두 받으면 유지보수 비용이 폭증할 수 있다. 특히 금융, 공공, 보안 제품처럼 감사 추적이 필요한 영역에서는 OpenJDK식 강한 정책이 더 설득력 있다. 반대로 실험적 프레임워크나 문서 중심 프로젝트는 AI 사용 공개와 테스트 의무를 결합하는 방식이 현실적일 수 있다.

코딩 에이전트 시대의 기여 규칙

코딩 에이전트가 발전할수록 기여의 단위는 사람이 직접 친 코드에서 사람과 에이전트가 함께 만든 변경 묶음으로 바뀐다. 이때 프로젝트는 세 가지 질문에 답해야 한다. 첫째, AI 사용 사실을 반드시 공개하게 할 것인가. 둘째, 생성 산출물의 라이선스와 출처에 대해 기여자가 어떤 보증을 해야 하는가. 셋째, 리뷰어가 확인할 수 있는 테스트와 설명을 어떤 수준까지 요구할 것인가.

SimpleEnglish, 에이전트 문서 품질의 작은 표준는 에이전트가 읽기 쉬운 문서의 중요성을 다뤘다. 같은 논리가 기여 정책에도 적용된다. 사람이 읽고 검증할 수 없는 AI 산출물은 공동체 자산이 아니라 부채가 된다. GitHub Actions 장애, AI 배송망의 숨은 단일 실패점처럼 자동화 의존도가 높아질수록 공급망의 작은 약점이 크게 보인다.

시각 자료 기획

• 오픈소스 AI 기여 정책 스펙트럼: 전면 허용, 공개 의무, 사람 검토, 전면 금지를 위험도별로 배치
• AI 패치 리뷰 비용 흐름도: 생성, 제출, provenance 확인, 테스트, 장기 유지보수까지의 비용 항목 표시

자주 묻는 질문

Q1: OpenJDK는 AI 도구 사용 자체를 금지하나요?

A: 아니다. 개인적으로 코드를 이해하거나 디버그하거나 리뷰하는 데 쓰는 것은 허용한다. 제출물에 AI 생성 콘텐츠를 포함하는 것을 금지한다.

Q2: 왜 임시 정책인가요?

A: 생성형 AI의 법적, 기술적 환경이 빠르게 변하고 있어서 장기 정책을 만들기 전 위험을 줄이려는 성격이 강하다.

Q3: 한국 개발자는 무엇을 조심해야 하나요?

A: 해외 오픈소스에 AI 보조 패치를 보낼 때 프로젝트별 정책을 먼저 확인해야 한다. AI 사용 사실을 숨기면 신뢰 문제가 될 수 있다.

Q4: 회사 내부 코드에도 같은 금지가 필요할까요?

A: 핵심 플랫폼, 규제 산업, 장기 유지보수 코드에는 강한 제한이 맞을 수 있다. 일반 업무 자동화에는 공개와 검토 기준을 두는 절충이 더 현실적이다.

Q5: 코딩 에이전트 시장에는 어떤 영향이 있나요?

A: 에이전트가 만든 코드의 provenance, 테스트 증거, 사람 승인 기록을 남기는 기능이 제품 차별화 요소가 된다.