오라클 창업자 래리 앨리슨은 몇 달 전 “오라클이 작성하는 코드는, 사실 오라클이 쓰는 게 아니다. 우리 AI 모델이 쓴다”고 자랑했습니다. 그런데 정작 오라클이 관리하는 세계 최대 오픈소스 프로젝트 OpenJDK는 정반대 길을 택했습니다. AI가 만든 코드를 아예 받지 않기로 한 겁니다.
이 모순된 결정 하나가, 왜 한국 개발자의 커리어 전략에도 신호가 될까요? 후배님이 요즘 PR에 AI 생성 코드를 얼마나 섞어 쓰고 계신지부터 한번 떠올려 보시면서 읽어보시면 좋겠습니다.
무슨 일이 있었나 — OpenJDK의 AI 코드 전면 금지
OpenJDK는 최근 생성형 AI에 대한 잠정 정책(Interim Policy on Generative AI)을 공식 승인했습니다. 대규모 언어모델이나 디퓨전 모델 등 딥러닝 시스템이 부분적으로라도 만든 콘텐츠는 기여물로 받지 않는다는 내용입니다. 소스 코드뿐 아니라 문서, GitHub PR, 이메일, 위키 페이지, 버그 시스템(JBS) 리포트까지 전부 포함됩니다.
금지 범위는 생각보다 넓다
흥미로운 건 기준의 엄격함입니다. AI가 만든 100줄 중 10줄만 사람이 고쳐 써도, 그 기여물은 여전히 “부분적으로 AI가 생성한 콘텐츠”로 간주돼 금지 대상입니다. 코드를 조금 다듬었다는 변명이 통하지 않는 구조인 셈이죠.
그래도 허용되는 것
다만 개인적으로 코드를 이해하거나 디버깅, 리뷰, 연구 목적으로 AI를 활용하는 것 자체는 막지 않습니다. 에디터의 맞춤법 검사나 자동완성처럼 LLM 기반이 아닌 보조 기능도 그대로 허용됩니다. 요컨대 “참고는 되지만, 기여물 자체에 AI 흔적이 남으면 안 된다”는 선을 그은 겁니다.
금지 이유 3가지 — 오라클이 밝힌 명분
OpenJDK 측이 밝힌 근거는 크게 세 가지입니다.
- 리뷰어 부담: 그럴듯해 보이지만 실제로는 틀리거나 유지보수하기 어려운 코드가, 한정된 리뷰어의 시간을 갉아먹는다는 문제.
- 안전성·보안: JDK는 전 세계 미션 크리티컬 시스템의 기반이라, 검증되지 않은 코드가 들어갈 때의 위험이 훨씬 큽니다.
- 저작권 분쟁 소지: AI 생성물의 저작권이 기여자에게 있는지 자체가 아직 소송이 진행 중인 사안이라, 프로젝트 차원의 법적 리스크로 이어질 수 있습니다.
이 배경은 The Register 보도와 관련 뉴스 피드에서도 비중 있게 다뤄졌습니다. 오픈소스 프로젝트 하나의 결정이지만, 대형 재단·기업이 잇따라 유사한 정책을 검토할 가능성이 있다는 점에서 파급력이 작지 않습니다.
앨리슨의 발언과 정면으로 부딪히는 정책
“오라클이 작성하는 코드는, 사실 오라클이 쓰는 게 아닙니다. 우리 AI 모델이 씁니다. 우리는 그저 모델에게 원하는 걸 말해주고, AI가 그걸 실행할 단계별 절차를 알아서 만들어냅니다.”
Larry Ellison, Oracle AI World 2025
공동 CEO 마이크 시칠리아 역시 AI 도구 덕분에 더 적은 인원으로 더 빠르게 제품을 내놓고 있다고 밝힌 바 있습니다. 그런데 같은 회사가 관리하는 OpenJDK는 정반대 규칙을 세웠습니다. 대외적으로는 “AI가 다 쓴다”고 홍보하면서, 정작 전 세계가 의존하는 핵심 인프라에는 AI 코드를 들이지 않겠다는 겁니다. 사내 폐쇄형 워크플로와 불특정 다수가 기여하는 오픈소스 프로젝트는 검증 구조 자체가 다르기 때문이라는 해석이 나오지만, 오라클이 직접 그렇게 설명한 적은 없어 정확한 내부 판단 근거는 확인이 필요합니다.
한국 개발자 커리어에 주는 신호
Stack Overflow 2025 개발자 설문에 따르면, AI 도구를 이미 쓰고 있거나 곧 쓸 계획이라고 답한 개발자는 84%였습니다. 그런데 같은 설문에서 AI 결과물을 신뢰한다고 답한 비율은 29%에 그쳤고, 이는 2024년 조사 대비 11%p 낮은 수치입니다. AI를 쓰는 사람은 늘어나는데, 그 결과물을 믿는 사람은 오히려 줄고 있다는 뜻이죠.
이 간극이 바로 OpenJDK가 정책으로 못 박은 지점이고, 한국 개발팀에도 곧 닥칠 질문입니다. AI가 코드를 더 많이 쓸수록, 역설적으로 “그 코드를 검증하고 책임질 사람”의 가치는 떨어지지 않는다는 신호로 읽을 수 있습니다.
코드 리뷰 역량이 다시 몸값이 된다
저도 최근 팀 코드리뷰에서 AI가 만든 티가 나는 PR을 받은 적이 있는데, 정작 작성자 본인이 왜 그런 구조를 택했는지 설명하지 못해 반려한 적이 있습니다. 그럴듯한 코드와 정확한 코드를 구분해내는 능력, 그리고 그 근거를 팀에 설명하는 능력은 AI가 대신해주지 못하는 영역이거든요. 채용 공고에서 “코드 리뷰 경험”이나 “설계 근거 설명 능력”을 별도로 명시하는 사례가 늘고 있다면, 이런 흐름과 무관하지 않을 가능성이 있습니다.
책임 소재를 설명할 수 있는 사람
OpenJDK처럼 “AI 기여 여부를 명시하라”는 정책을 도입하는 조직이 늘어난다면, 이력서나 면접에서도 “AI 도구를 어떻게, 어디까지 썼는가”를 구체적으로 설명해야 하는 순간이 올 거예요. 후배님이 지금 준비할 수 있는 건 AI를 안 쓰는 게 아니라, AI가 만든 결과물에 대해 본인 이름을 걸고 설명할 수 있는 습관을 만드는 일입니다.
지금 점검해볼 체크리스트
- 내가 제출하는 PR에서 AI 생성 여부를 팀에 투명하게 공유하고 있는가
- 리뷰할 때 “그럴듯함”과 “정확함”을 구분해서 판단하고 있는가
- 우리 조직에도 OpenJDK 같은 AI 기여 가이드라인이 필요하지 않은가
- 이력서·면접에서 AI 도구 활용 경험을 구체적으로 설명할 준비가 되어 있는가
정답이 정해진 체크리스트는 아니지만, 이 네 가지에 바로 답이 안 나온다면 지금이 점검해볼 타이밍일 수 있습니다.
관련 글
- AI 코드 리뷰 자체가 개발자를 지치게 만든다는 지적도 있습니다 — AI 코드 리뷰가 개발자를 더 지치게 만드는 이유와 착시 지표
- 규제 대응 관점에서 SBOM 논의를 다룬 글도 참고해보세요 — EU CRA는 SBOM 깊이를 요구하지 않습니다
- AI 시대에 오히려 값이 오르는 역량이 궁금하다면 — 도메인 전문성이 AI 시대 시니어 개발자의 무기인 이유
- 채용 관점의 “베팅 기준” 변화가 궁금하다면 — 시스템 사고형 인재, 넷플릭스가 전문가 대신 베팅하는 이유
📌 함께 보시면 좋은 글
이직·퇴사·연봉 협상을 혼자 판단하기 어렵다면
1:1 개발자 커리어 상담 신청하기 →
※ 본 글은 AI(Claude)의 초안을 기반으로 편집자 검수를 거쳐 발행되었습니다. (한국 AI기본법 대응 고지)
이직·퇴사, 지금 움직여도 될지 헷갈리시나요?
막연히 불안한 건지, 정말 시점이 온 건지 판단이 어려울 때가 있습니다.
5분 체크리스트로 지금 상태를 먼저 정리해보세요.
결론을 대신 내리기보다, 스스로 판단할 기준을 잡는 데 도움을 드립니다.
아직 확신이 없다면, 지금이 ‘고민 단계’인지부터 먼저 점검해보세요