같은 회사 두 프로젝트가 AI 기여에 정반대 결론을 낸 이유

• 같은 회사, 같은 기여자 협약, 정반대 정책
• OpenJDK가 금지한 것과 허용한 것
• 10줄만 고쳐도 안 되는 이유는 IP 조항에 있습니다
• 탐지가 불가능하다는 것을 정책이 스스로 인정합니다
• GraalVM은 같은 위험을 책임으로 옮깁니다
• 리눅스 커널은 세 번째 답을 냅니다
• 세 정책을 가르는 진짜 축
• 우리 리포의 정책을 쓸 때 결정해야 하는 네 가지
• 참고 자료

같은 회사, 같은 기여자 협약, 정반대 정책

오픈소스 프로젝트에 패치를 하나 보내려고 합니다. 작업 중에 코딩 어시스턴트를 켜 뒀습니다. 이 패치를 보내도 되는지 확인하려고 프로젝트 문서를 열었더니, 프로젝트마다 답이 다릅니다. 그것도 같은 회사가 후원하는 두 프로젝트 사이에서 정반대입니다.

OpenJDK의 잠정 정책은 2026년 4월 9일자로, 생성형 AI가 만든 내용이 기여에 포함되어서는 안 된다고 못박습니다. GraalVM의 정책 파일은 기여자가 AI 코딩 어시스턴트를 사용할 수 있다고 명시합니다. 둘 다 오라클 기여자 협약을 씁니다.

이 차이를 "한쪽은 보수적이고 한쪽은 전향적"으로 요약하면 아무것도 얻지 못합니다. 세 문서를 실제로 읽으면 다른 그림이 나옵니다.

OpenJDK가 금지한 것과 허용한 것

원문은 범위를 아주 넓게 잡습니다. 금지 대상은 소스 코드에 한정되지 않고, 저장소의 텍스트와 이미지, GitHub 풀 리퀘스트, 메일, 위키 문서, 이슈 트래커까지 포함합니다. 커밋 메시지도, PR 설명도, 메일링 리스트 답장도 해당됩니다.

동시에 허용 범위도 분명합니다. 기여자는 생성형 AI 도구를 사적으로 사용해 코드를 이해하고, 디버깅하고, 검토하고, 프로젝트 관련 조사를 할 수 있습니다. 그렇게 만들어진 내용을 기여하지만 않으면 됩니다.

FAQ는 이 구분을 더 밀어붙입니다. 초안 JEP나 문서를 AI로 검토받는 것은 괜찮습니다. 텍스트를 본인이 다 썼다면 검토는 명백히 허용 영역이기 때문입니다. 편집기의 맞춤법 검사와 자동 완성도 대규모 언어 모델 기반이 아니라면 계속 써도 됩니다.

10줄만 고쳐도 안 되는 이유는 IP 조항에 있습니다

가장 자주 인용되는 FAQ 항목은 이것입니다. AI로 100줄을 만들고 그중 10줄을 직접 고쳤다면 기여할 수 있느냐는 질문에 대한 답은 안 된다는 것입니다. 여전히 부분적으로 AI가 생성한 코드를 포함하기 때문입니다.

이 답이 지나치게 엄격해 보인다면, 그 이유가 코드 품질이 아니라 계약에 있다는 점을 보면 이해가 쉬워집니다. 오라클 기여자 협약은 기여자가 각 기여의 지식재산권을 보유하고 그 권리를 제한 없이 오라클에 넘길 수 있을 것을 요구합니다. 그리고 원문은 생성형 AI 도구 사용자가 그 산출물에 대해 지식재산권을 갖는지 여부가 현재 소송이 진행 중인 사안이라고 적습니다.

권리가 불확실한 부분이 1퍼센트라도 섞이면 "제한 없이 넘긴다"는 확인은 성립하지 않습니다. 그래서 비율 기준이 나올 수 없고, 이분법이 됩니다.

이 점을 이해하면 흔한 반론 하나가 힘을 잃습니다. "그럼 IDE 자동 완성은 어떻게 하느냐"는 질문인데, 원문은 그 경계를 도구의 종류가 아니라 기술로 긋습니다. 대규모 언어 모델이나 유사한 딥러닝 시스템에 기반하지 않은 맞춤법 검사와 자동 완성은 계속 써도 된다고 적혀 있습니다. 기준은 편의성이 아니라 권리 귀속이 다투어지는 학습 방식이냐입니다.

탐지가 불가능하다는 것을 정책이 스스로 인정합니다

정책에서 가장 솔직한 대목은 검토자 책임에 관한 부분입니다. 원문은 사람이 만든 내용과 AI가 만든 내용을 신뢰할 수 있게 구분하는 것은 일반적으로 불가능하다고 명시합니다.

그럼에도 정황이 보이면 기여자에게 알릴 책임이 검토자에게 있다고 하고, 그 정황의 예시까지 나열합니다. 커밋 트레일러에 특정 도구가 공동 저자로 남아 있는 경우, 평소 문체와 다르게 수다스럽고 장황한 경우, 제목이 여러 개 달린 과도하게 구조화된 코멘트, 불필요한 주석, 필요 이상으로 방어적인 코드, 이모지 사용 같은 것들입니다. 원문은 이 단서들이 오늘 유효하더라도 내일은 아닐 수 있다고 스스로 덧붙입니다.

그래서 집행은 탐지가 아니라 신고에 걸립니다. Skara가 풀 리퀘스트 본문에 체크박스를 추가하고, 기여자가 이 정책을 준수했음을 직접 확인하게 만드는 방식입니다. 실질적으로는 정직성 선언 체계입니다.

GraalVM은 같은 위험을 책임으로 옮깁니다

GraalVM 문서는 같은 위험 목록을 다르게 처리합니다. 사용을 허용하되, 제출한 사람이 AI가 만든 부분을 포함해 기여 전체에 대해 책임을 진다고 규정합니다.

기대되는 행동도 구체적입니다. 제출한 코드와 테스트와 문서와 커밋 메시지를 읽고 이해할 것, 변경이 정확하고 필요하며 프로젝트 기준에 맞는지 검증할 것, 검토자의 질문에 도구를 핑계 삼지 않고 답할 것, 그리고 검토와 유지보수 기간 동안 그 기여를 책임질 것입니다. 문서는 기여자가 AI 보조 변경을 설명하거나 방어하거나 유지할 수 없다면 그 기여는 거절될 수 있다고 적습니다.

출처 표기는 권장이지만 필수가 아니고, 특정 모델 이름을 밝힐 필요도 없습니다. 유지보수자에게는 AI 보조 여부가 정확성의 추정 근거가 되지 않는다는 점을 명시합니다.

리눅스 커널은 세 번째 답을 냅니다

GraalVM 문서가 참고했다고 밝힌 리눅스 커널의 AI 코딩 어시스턴트 문서는 또 다른 축을 씁니다. 허용하되 흔적을 남기게 하는 방식입니다.

핵심 규칙 하나가 인상적입니다. AI 에이전트는 Signed-off-by 태그를 붙이면 안 됩니다. 개발자 원본 증명을 법적으로 확인할 수 있는 것은 사람뿐이기 때문입니다. 대신 별도 태그를 씁니다.

Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2]

예: Assisted-by: Claude:claude-3-opus coccinelle sparse

버그를 찾아 고치는 절차도 문서에 단계로 못박혀 있습니다. 사소하지 않은 버그는 재현 코드를 만들어 실재를 확인할 것, 고치는 것까지 할 것, 빌드 경고를 추가하지 않고 checkpatch 검사를 통과할 것, 그리고 하지 못한 것을 명시적으로 밝힐 것입니다. 재현 코드를 못 만들었거나 테스트를 못 했으면 그렇게 적으라는 요구입니다. 검증되지 않은 보고서를 분석하는 데 유지보수자의 시간이 너무 많이 낭비되고 있다는 이유가 문서에 그대로 적혀 있습니다.

세 정책을 가르는 진짜 축

세 문서를 나란히 놓으면 축이 보입니다. AI를 얼마나 신뢰하는가가 아니라, 검토 부담을 누구에게 청구하는가입니다.

OpenJDK가 가장 엄격한 것은 검토자 풀이 좁고 대체 불가능하며 결과물이 미션 크리티컬 시스템의 바닥에 깔리기 때문입니다. 원문이 안전과 보안을 이유로 든 자리가 여기입니다. 반대로 GraalVM은 같은 협약 아래서도 개별 책임으로 감당 가능하다고 판단했습니다. 같은 회사가 다른 답을 낸 것은 모순이 아니라 프로젝트마다 병목이 다르기 때문입니다.

우리 리포의 정책을 쓸 때 결정해야 하는 네 가지

이 축을 알면 사내 리포의 정책도 짧게 쓸 수 있습니다. 남의 정책을 복사하는 대신 네 가지만 정하면 됩니다.

AI 보조 기여 정책 — 예시 골격

1. 범위: 코드만인가, PR 설명과 이슈 코멘트까지인가
2. 책임: 제출자가 설명하지 못하는 변경은 거절되는가
3. 기록: 표기를 의무로 할 것인가 권장으로 할 것인가, 어떤 태그로 남길 것인가
4. 집행: 탐지에 기대는가, 선언과 리뷰에 기대는가

기본 권장: 범위는 코드와 PR 설명, 책임은 제출자 전적,
기록은 커밋 트레일러 권장, 집행은 선언 + 통상 리뷰.

세 번째 항목만 부연하면, 표기를 의무화할 때 얻는 것은 감시가 아니라 데이터입니다. 6개월 뒤에 AI 보조 변경의 사후 결함률을 따로 볼 수 있게 되고, 그러면 정책을 감이 아니라 숫자로 조정할 수 있습니다. 지금 이 논쟁이 대체로 감으로 진행되는 이유는 그 숫자를 가진 조직이 거의 없기 때문입니다.

마지막으로 하나. OpenJDK 문서는 제목부터 잠정이라고 붙어 있고, 오라클이 정식 정책을 거버닝 보드에 제안할 예정이라고 본문에 적혀 있습니다. 지금의 금지는 최종 결론이 아니라 시간을 버는 조치입니다. 이 점을 빼고 인용하면 원문이 하지 않은 말을 하게 됩니다.

참고 자료

• OpenJDK Interim Policy on Generative AI — openjdk.org, 2026-04-09 — 금지 범위, 사적 사용 허용, 세 가지 위험, 100줄 중 10줄 FAQ, Skara 체크박스, 검토자 책임과 단서 목록이 모두 이 문서에 있습니다.
• GraalVM Coding Assistants — oracle/graal 저장소 — 허용 범위, 기여자 책임, 선택적 표기, 유지보수자 검토 원칙.
• AI Coding Assistants — 리눅스 커널 문서 — 서명 금지, Assisted-by 태그 형식, 버그 수정 절차.
• 위 비교표와 정책 골격은 세 원문을 읽고 제가 정리한 것이며 어느 문서에도 그대로 나오지 않습니다.