오픈 소스 프로젝트 AI 코드 기여 정책 확인 방법

AI 지원 코드를 업스트림에 제출하기 전에 수행할 작업

오픈 소스 프로젝트들은 이제 AI 지원 코드에 관한 정책을 발표하고 있으며, 이러한 정책들은 서로 일치하지 않습니다. 따라서 습관은 간단합니다. 패치를 작성하기 전에 정책을 확인하고, 제출할 때 정확하게 공개하십시오. 모든 정책의 기저에는 하나의 규칙이 있습니다. 검토 과정에서 설명할 수 없는 코드는 절대 제출하지 마십시오.

프로젝트가 생성된 코드를 금지하거나 코드의 출처를 숨긴 경우, 올바른 패치라도 거부될 수 있습니다. 나중에 유지보수자가 누락 사실을 발견하면 귀하의 나머지 이력까지 신뢰할 이유가 없으므로, 그 대가는 귀하의 이름에 남게 됩니다. 정책에서 사용하는 용어들을 먼저 정리하겠습니다. LLM(large language model)은 코딩 에이전트의 기반이 되는 모델입니다. GitHub의 PR(pull request)은 GitLab의 MR(merge request)과 같으며, 아래의 모든 내용은 두 경우 모두에 적용됩니다. DCO(developer certificate of origin)는 커밋 메시지 하단의 서명 라인이며, 이것이 전체 논쟁의 핵심이 됩니다.

AI 코드에 대한 오픈 소스 정책의 현주소

프로젝트들은 네 가지 범주로 자리를 잡았습니다. 아래의 모든 예시는 날짜가 명시되어 있는데, 이는 관련 정책이 계속 변하기 때문입니다.

금지. Gentoo 위원회는 2024년 4월 14일, "자연어 처리 인공지능 도구의 도움을 받아 생성된 콘텐츠를 Gentoo에 기여하는 것을 명시적으로 금지한다"고 의결했습니다. NetBSD의 커밋 가이드라인은 LLM의 출력물을 "오염된 코드(tainted code)"로 규정하며, "핵심 개발자의 사전 서면 승인 없이는 커밋할 수 없다"고 명시합니다. 2026년 8월 기준, QEMU의 코드 출처 문서에는 여전히 "AI가 생성한 콘텐츠를 포함하거나 그로부터 파생된 것으로 판단되는 모든 기여를 거부한다"고 적혀 있습니다.

분석 전용. 대부분의 금지 정책은 표면적인 내용보다 범위가 좁습니다. QEMU의 문서는 해당 정책이 "API나 알고리즘 연구, 정적 분석, 디버깅 등 AI의 다른 활용 사례에는 적용되지 않으며, 단, 그 결과물이 기여 내용에 포함되어서는 안 된다"고 밝히고 있습니다. 에이전트를 사용하여 코드를 읽는 것은 가능합니다. 하지만 에이전트가 작성한 내용을 배포해서는 안 됩니다. 이러한 구분은 대부분의 제한적인 프로젝트 내부에서 작동하는 기준이며, 사람들이 흔히 간과하는 부분이기도 합니다.

공개 의무화. Fedora 위원회는 2025년 10월 AI 지원 기여에 관한 정책을 승인했습니다. 이 정책은 도구 사용을 허용하되 그 책임을 개인에게 지웁니다. 기여자가 곧 저자이며 전체 기여 내용에 대해 전적인 책임을 집니다. 또한 기여 내용의 상당 부분이 수정 없이 도구에 의해 생성된 경우 이를 반드시 공개해야 합니다. Linux 커널은 2025년 12월 프로세스 문서에 코딩 보조 도구 페이지를 추가했으며, 도구 기록을 위한 꼬리말과 누가 서명(sign-off)할 수 있는지에 대한 엄격한 규칙을 마련했습니다.

문서화되지 않음. 여전히 가장 흔한 사례입니다. 2026년 5월의 한 사전 인쇄 논문(preprint)은 1,000개의 인기 GitHub 저장소를 조사한 결과, AI 정책이 문서화된 곳은 118개에 불과하다고 밝혔습니다. 침묵이 곧 허용을 의미하지는 않습니다. 패치를 작성하기 전에 이슈 트래커에 한 문장으로 질문하십시오. 그 답변은 나중에 근거로 제시할 수 있는 공적인 기록이 됩니다.

메인테이너들이 이러한 규칙을 작성한 이유

첫 번째 이유는 리뷰 부담이며, 산술적으로 한 방향으로만 작용합니다. 에이전트는 1분 만에 그럴듯한 400줄짜리 머지 리퀘스트를 생성합니다. 해당 요청을 제대로 검토하려면 메인테이너의 오후 시간이 소요되는데, 대부분의 메인테이너는 자원봉사자입니다. 제출 비용은 거의 0에 가까워졌지만, 검토 비용은 전혀 줄어들지 않았습니다.

curl은 이 곡선의 끝을 보여줍니다. Daniel Stenberg는 2025년 중반, 프로젝트의 버그 바운티를 통해 들어오는 보안 보고서의 약 5분의 1이 그가 'AI 슬롭(AI slop)'이라 부르는 것들이라고 보고했습니다. 이는 실제 함수와 코드 경로를 언급하고 그럴듯한 공격 방식을 설명하지만, 실제로는 아무런 내용이 없는 보고서입니다. 프로젝트는 쏟아지는 보고서에 계속 자금을 지원하기보다 2026년 초에 바운티를 종료했습니다. 이는 패치가 아닌 보고서였지만, 메인테이너가 이미 지친 상태로 귀하의 PR을 열게 만드는 것과 동일한 메커니즘입니다.

GNOME Calendar는 이 문제를 라벨로 정의했습니다. 2026년 6월, 해당 프로젝트는 "코드 생성 시 인공 '지능'에 대한 주요하거나 전적인 의존"을 보이는 머지 리퀘스트에 대해 "확률적 자동화(Probabilistically Automated)"라는 라벨을 도입했습니다. 그리고 그 증상을 정확히 명시했습니다. "보통 적절한 테스트가 결여되어 있으며, 코드의 정확성이 아닌 이론적인 의도된 동작을 기반으로 패치를 마무리함"이라는 내용입니다. 마지막 문장을 두 번 읽어보십시오. 코드는 작동할 것처럼 보입니다. 하지만 아무도 실제로 작동하는지 확인하지 않았습니다.

두 번째 이유는 출처, 즉 코드가 어디서 왔으며 어떤 라이선스를 따르는지에 대한 문제입니다. QEMU는 이 갈등을 명확히 밝히고 있습니다. 서명(sign-off)은 귀하가 기여하는 콘텐츠의 "저작권 및 라이선스 상태를 완전히 이해함"을 보증하는 것인데, 모델 출력물의 저작권 상태는 아직 불분명합니다. Gentoo 위원회도 품질 및 윤리 문제와 더불어 동일한 이유를 제시했습니다. 귀하가 법적 해석에 동의할 필요는 없습니다. 하지만 이것은 귀하가 아닌 메인테이너가 결정할 사안임을 인지해야 합니다.

프로젝트의 AI 정책은 어떻게 찾습니까?

다음 위치를 순서대로 확인하십시오.

• 저장소 루트의 CONTRIBUTING.md, 그 다음 .github/CONTRIBUTING.md, 그리고 그 옆에 있는 DCO 파일을 확인합니다.
• 개발자 문서를 확인합니다. QEMU는 docs/devel/code-provenance.rst에 규칙을 보관하며, 커널은 Documentation/process/coding-assistants.rst에 보관합니다.
• 프로젝트 웹사이트나 위키를 확인합니다. Gentoo의 정책은 위키의 의회(council) 페이지에 있으며, NetBSD의 정책은 커밋 가이드라인에 있습니다.
• 이슈 트래커와 메일링 리스트 아카이브를 확인합니다. 정책은 보통 저장소에 기록되기 수개월 전부터 이곳에 존재합니다.

체크아웃한 디렉터리 내부에서 다음 grep 명령을 실행하면 대부분의 내용을 확인할 수 있습니다.

grep -rniE '(llm|copilot|chatgpt|generative|ai-generated|ai-assisted)' CONTRIBUTING.md docs/ .github/ 2>/dev/null | head -20

그다음 프로젝트의 자체 기록을 읽어보십시오. 커밋된 관례가 어떤 요약보다 우선하기 때문입니다.

git log --format='%(trailers:key=Assisted-by,valueonly)' | grep . | sort | uniq -c
git log --format='%(trailers:key=AI-used-for,valueonly)' | grep . | sort | uniq -c

트레일러 값 옆의 개수는 해당 프로젝트가 실제로 사용하는 형식을 알려줍니다. 결과가 비어 있다면 해당 형식으로 공개된 내용이 없다는 뜻이며, 이 또한 중요한 정보입니다. 프로젝트가 GitHub에 있고 워크플로우 자체가 생소하다면, GitHub에서 풀 리퀘스트와 포크가 작동하는 방식에서 이 섹션이 전제로 하는 메커니즘을 다룹니다.

커밋 트레일러에 명시하고 주석에는 남기지 마십시오

트레일러는 커밋 메시지의 마지막 문단에 위치한 Key: value 형식의 줄입니다. Git은 이미 Signed-off-by: 및 Co-authored-by:을 위해 이 형식을 사용하고 있으며, 도구들이 이를 파싱하므로 코드와 함께 트리로 이동하는 유일한 공개 방식입니다.

net: release the buffer on the error path

The error path returned before releasing the buffer, so every failed
setup leaked one page.

Assisted-by: Claude:claude-3-opus coccinelle sparse
Signed-off-by: Your Real Name <you@example.com>

커널 문서에서는 해당 형식을 Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2]로 정의하며, 줄의 제한 사항을 다음과 같이 명확히 합니다: "AI 에이전트는 Signed-off-by 태그를 추가해서는 안 됩니다. 오직 사람만이 법적으로 DCO(Developer Certificate of Origin)를 인증할 수 있습니다." 에이전트의 이름은 Assisted-by에 기재합니다. 귀하의 이름은 Signed-off-by에 기재합니다. 도구가 두 번째 항목을 작성하게 두지 마십시오. 또한 누구의 것도 아닌 Co-authored-by 주소를 도구가 임의로 생성하게 해서도 안 됩니다.

이름은 다양하므로 임의로 생성하지 말고 로컬에 있는 이름을 복사하십시오. 2026년 5월 QEMU 메일링 리스트에 게시된 패치는 기계적인 변경, 테스트, 문서화, 20줄 이하의 버그 수정에 대해 해당 프로젝트의 금지 조항을 완화하고 AI-used-for: tests, docs과 같은 트레일러로 기록할 것을 제안했습니다. 2026년 8월 기준으로 이는 메일링 리스트상의 제안일 뿐이며, 커밋된 문서는 여전히 생성된 콘텐츠를 거부하고 있습니다. 한 프로젝트는 2023년에서 2026년 사이에 입장을 두 번 변경했습니다. 다음 변화는 귀하를 기다려주지 않을 것이며, 이것이 바로 목록보다 방법론이 더 중요한 이유입니다.

git commit -s --trailer "Assisted-by: Claude:claude-3-opus" -m "net: release the buffer on the error path"
git log -1 --format='%(trailers:key=Assisted-by,valueonly)'

--trailer은 Git 2.32 이상이 필요합니다. 두 번째 명령은 값을 그대로 출력해야 합니다. 빈 줄이 출력된다면 Git이 트레일러를 파싱하지 못한 것입니다. 이는 거의 항상 메시지 하단의 트레일러 블록 내부에 빈 줄이나 일반 문장이 포함되어 있기 때문입니다. 이미 작성한 커밋 시리즈의 경우, git rebase --signoff origin/main은 모든 커밋에 sign-off를 추가하며, git interpret-trailers --in-place --trailer "Assisted-by: Claude:claude-3-opus" msg.txt는 메시지 파일을 수정합니다.

두 가지 실패 유형에 대비해야 합니다. 스쿼시 머지(squash merge)는 커밋 메시지를 다시 작성하므로, 스쿼시를 수행하는 프로젝트라면 메인테이너가 확인하는 PR 설명에 공개 내용을 반복해서 기재하십시오. 리뷰 주석은 기록이 아닙니다. 주석은 수정될 수 있으며 Git 히스토리에 남지 않기 때문입니다.

정확성은 양면성을 가집니다. 직접 작성한 커밋에 Assisted-by을 남기는 것은 노이즈일 뿐이며, 실제 공개 사항의 가치를 떨어뜨립니다. 에이전트가 작성한 커밋에서 이를 누락하는 것은 관계를 종료시키는 원인이 됩니다.

Signed-off-by는 실제로 무엇을 보증하는가?

DCO는 developercertificate.org에 게시된 버전 1.1의 짧은 텍스트로, 커널, QEMU 및 기타 여러 프로젝트에서 사용합니다. Signed-off-by: Your Name <you@example.com>을 추가하는 것은 귀하가 이를 인증한다는 의미입니다. 대부분의 사람은 읽지도 않고 서명하지만, 무엇을 인증하는지 반드시 읽어보아야 합니다.

(a)항은 기여물이 "전부 또는 일부가 본인에 의해 작성되었으며, 파일에 명시된 오픈 소스 라이선스에 따라 제출할 권리가 있음"을 명시합니다. (b)항은 귀하가 수정하여 배포할 권리가 있는 기존 오픈 소스 코드를 기반으로 한 작업을 다룹니다. (c)항은 동일한 내용을 인증한 사람으로부터 전달받은 코드를 다룹니다. (d)항은 기여물과 서명에 포함된 개인 정보가 공개되며 영구적으로 보관된다는 점을 이해하고 있음을 명시합니다.

무엇이 빠졌는지 주목하십시오. DCO는 귀하가 모든 문자를 직접 입력했다고 말하지 않습니다. 단지 해당 라이선스에 따라 코드를 제출할 권리가 있다고 말할 뿐입니다. 이것이 생성된 코드가 이 맥락에서 모호하게 취급되는 이유입니다. 핵심은 저작권 여부가 아니라, 코드의 출처를 보증할 수 있는지 여부입니다. 서명을 요구하는 대부분의 프로젝트는 실명을 요구하므로, 가명은 검증을 통과할 수 없습니다. git commit -s를 사용하여 해당 줄을 추가하십시오. 이 명령은 귀하의 git 설정에서 user.name과 user.email를 읽어옵니다. DCO 봇이 PR을 거부하고 해당 줄이 누락된 커밋을 지목한다면, git rebase --signoff origin/main를 실행하고 브랜치에 강제 푸시(force push)하여 해결할 수 있습니다.

커밋 서명과 Sign-off는 서로 다릅니다

git commit -s은 텍스트 한 줄을 추가합니다. git commit -S은 GPG 또는 SSH 키를 사용하여 커밋 객체에 암호화 서명을 생성합니다. 두 기능은 서로 다른 목적을 가집니다. 서명은 해당 커밋이 키 소유자로부터 생성되었으며 이후 변경되지 않았음을 보증합니다. 서명은 코드의 출처에 대해서는 아무것도 보장하지 않으므로, 공개되지 않은 생성 코드가 포함된 커밋이라도 서명만 되어 있다면 정책 위반이 될 수 있습니다. Sign-off는 출처에 대한 주장이며, 서명은 신원에 대한 주장입니다. 두 가지 모두를 요구하는 프로젝트는 양쪽 모두를 요청할 것입니다.

설명할 수 없는 코드는 제출하지 마십시오

이것은 테스트이며, 단순히 정직함에 관한 문제가 아닙니다. 코드의 모든 줄에 대해 다음을 자문하십시오. 이 코드는 무엇을 위한 것인가? 이것이 없으면 무엇이 고장 나는가? 두 질문 중 하나라도 답할 수 없다면 패치는 준비되지 않은 것입니다. 리뷰 의견이 달릴 것이고, 당신의 답변은 또 다른 생성 과정을 거쳐야 하기 때문입니다. 리뷰어는 이를 알아차립니다. 바로 그 순간 기여자는 프로젝트의 비용이 됩니다. 경계 조건, 빈 입력, 실패 경로, 두 번째 호출자에 대해서도 동일한 질문을 던지십시오.

코드를 실행하십시오. 빌드하고, 프로젝트의 테스트 스위트를 실행하며, 수정하려는 버그를 재현할 수 있는 코드를 작성하십시오. 커널 문서에서는 정직한 대안을 다음과 같이 명확히 밝히고 있습니다. "수정을 빌드하거나 테스트할 수 없거나, 재현 코드를 만들 수 없다면 이를 명시적으로 밝히십시오. 관리자들은 검증되지 않은 보고서와 테스트되지 않은 수정 사항을 분석하는 데 너무 많은 시간을 낭비하고 있습니다." "실제 하드웨어에서 테스트할 수 없었습니다"라고 적는 것은 당신에게 아무런 손해가 되지 않습니다. 테스트를 완료했다고 암시하는 것은 프로젝트에서의 신뢰를 잃게 만듭니다.

리뷰 의견에는 본인의 언어로, 본인의 시간에 직접 답변하십시오. 의견이 달린 지 30초 만에 다섯 문단으로 내용을 재진술하는 답변은 관리자에게 무슨 일이 일어났는지 정확히 알려줍니다. diff의 크기도 작게 유지하십시오. 완전히 이해하고 있는 40줄의 코드가, 감독만 한 400줄의 리팩토링보다 프로젝트에 훨씬 가치 있습니다. 만약 당신의 에이전트가 요청한 것보다 더 많은 코드를 계속 내놓는다면, 작동하는 최소한의 변경 사항만 유지하는 기술을 사용하여 패치를 한 줄 한 줄 방어할 수 있는 수준으로 유지하십시오.

에이전트 지침을 리포지토리에 보관하기

에이전트에게 전달하는 지침은 툴체인의 일부이므로 코드처럼 다루어야 합니다. 일반적으로 AGENTS.md이라는 이름으로 리포지토리 루트에 위치한 파일에는 빌드 명령, 테스트 명령, 커밋 메시지 형식, 서명 요구 사항 및 프로젝트에 이미 문서화된 스타일 규칙이 포함됩니다. 이 파일은 버전 관리가 가능하고 검토할 수 있으며, 오늘과 내일 동일하게 유지됩니다. 세션마다 기억에 의존해 지침을 다시 입력하면 세션마다 다른 패치가 생성되며, 어떤 세션에서 거부된 패치가 생성되었는지 알 수 없게 됩니다. 에이전트와 사람이 모두 읽을 수 있는 AGENTS.md 작성하기에서 해당 파일 자체에 대해 다룹니다.

타인의 리포지토리에 기여할 때 주의할 점이 있습니다. 본인이 관리하지 않는 프로젝트에 에이전트 지침 파일을 추가하는 것을 첫 번째 기여로 삼지 마십시오. 이는 외부에서 프로젝트의 도구 정책을 설정하려는 시도로 비춰질 수 있으며, 관리자들이 이미 피로감을 느끼는 요소와 귀하의 계정이 연관되는 지름길이 됩니다. 누군가 요청하기 전까지는 해당 파일을 본인의 포크(fork)에만 보관하십시오.

에이전트를 실행하는 위치도 같은 이유로 중요합니다. 본인이 제어하는 샌드박스 내부에서 프로젝트를 빌드하고 테스트를 실행할 수 있는 에이전트는 실제로 검증된 패치를 제공합니다. 이것이 바로 도움을 받았음을 밝히는 것과 추측을 밝히는 것의 차이입니다. 자신의 VPS에서 코딩 에이전트 실행하기에서 해당 설정을 다루며, Claude Code, Cursor, Codex, Copilot의 실질적인 차이점에서 도구 간의 일상적인 차이를 다룹니다.

정책 변경 시의 절차

1. 무엇을 작성하기 전에 저장소, 개발자 문서, 웹사이트, 이슈 트래커 등에서 명시된 정책을 찾습니다.
2. 정책이 없다면 이슈에 한 문장으로 질문하고 그 답변을 보관합니다.
3. 프로젝트가 사용하는 양식에 맞춰 공개하고, 커밋 트레일러에 기재하며, 프로젝트가 스쿼시(squash) 방식을 사용한다면 PR 본문에도 반복해서 기재합니다.
4. 해당 라인이 코드 제출 권리에 대한 주장임을 인지하고 본인의 실명으로 서명(sign-off)합니다.
5. 마치 낯선 사람이 작성한 것처럼 자신의 패치를 검토하십시오. 실제로도 그렇기 때문입니다.

이 페이지에 언급된 모든 프로젝트는 독자가 이 글을 읽을 시점에는 이전되었을 것입니다. 하지만 이 5단계 절차는 변하지 않습니다.

FAQ

AI 코딩 에이전트를 사용했음을 밝혀야 합니까?

프로젝트마다 정책이 다르므로 해당 프로젝트의 규정을 확인하십시오. Fedora는 기여의 상당 부분이 도구에 의해 생성되었고 수정이 가해지지 않은 경우 이를 명시하도록 요구합니다. Linux 커널은 Assisted-by 트레일러를 요구합니다. 2026년 8월 기준으로 Gentoo와 QEMU는 AI가 생성한 기여를 아예 받지 않습니다. 명문화된 규정이 없는 경우에도 커밋 트레일러에 명시하는 것이 좋습니다. 나중에 관리자가 이를 알게 될 경우, 도구 사용 자체보다 누락 사실에 대해 더 부정적으로 반응할 수 있으며, 이는 귀하가 보낸 다른 모든 기여에 대한 신뢰도에 영향을 미칩니다.

AI가 생성한 코드를 금지하는 오픈 소스 프로젝트는 어디입니까?

2026년 8월 기준 현황은 다음과 같습니다. 2024년 4월부터 금지한 Gentoo, LLM 출력을 핵심 승인이 필요한 오염된 코드로 간주하는 NetBSD, 생성된 콘텐츠에서 파생된 기여를 거부하는 QEMU, 그리고 Loupe와 Calendar를 포함한 일부 GNOME 애플리케이션이 있습니다. 이 목록은 시간이 지나면 변경될 수 있으므로 반드시 각 프로젝트의 공식 문서를 직접 확인하십시오. 대부분의 프로젝트가 공통으로 허용하는 예외 사항이 있습니다. API 조사, 정적 분석 실행, 디버깅 보조를 위해 모델을 사용하는 것은 일반적으로 괜찮으며, 모델의 출력이 패치에 직접 포함되지 않는다면 문제가 되지 않습니다.

Signed-off-by와 서명된 커밋(signed commit)의 차이점은 무엇입니까?

Signed-off-by은 git commit -s에 의해 추가되는 일반 텍스트 라인입니다. 이는 개발자 원본 증명(Developer Certificate of Origin)을 인증하는 것으로, 귀하가 해당 코드를 프로젝트 라이선스에 따라 제출할 권리가 있음을 의미합니다. git commit -S을 사용하여 생성하는 서명된 커밋은 GPG 또는 SSH 키를 사용하여 커밋 객체에 암호학적 서명을 하는 것입니다. 이는 해당 커밋이 귀하의 키에서 생성되었으며 변조되지 않았음을 증명합니다. 원본 증명과 신원 증명은 별개의 문제이므로, 서명된 커밋이라 하더라도 AI 정책을 위반할 수 있습니다.

커밋 메시지 대신 풀 리퀘스트 설명에 명시해도 됩니까?

커밋 메시지에 포함하십시오. 커밋 메시지는 git 기록에 남으며, 나중에 저장소를 복제하는 모든 사람에게 전달되는 기록이기 때문입니다. 풀 리퀘스트 설명은 나중에 수정될 수 있으며 호스팅 플랫폼에만 존재합니다. 프로젝트가 squash merge를 사용하는 경우에는 PR 본문에도 내용을 추가하십시오. squash 과정에서 커밋 메시지가 다시 작성되면서 트레일러가 삭제될 수 있기 때문입니다.

AI가 생성했다는 이유로 풀 리퀘스트가 닫혔습니다. 어떻게 해야 합니까?

해당 스레드에서 정책에 대해 논쟁하지 마십시오. 풀 리퀘스트를 닫은 사람은 정책을 단독으로 만든 것이 아니며, 스레드는 정책을 변경하는 장소가 아닙니다. 정책 문서를 읽고 귀하가 이를 준수할 수 있는지 판단하십시오. 프로젝트가 생성된 패치를 금지하더라도, 재현 가능한 명확한 버그 리포트를 패치 없이 제출하는 것은 여전히 환영받으며, 종종 더 유용한 기여가 되기도 합니다. 다시 코드를 제출할 때는 한 줄 한 줄 설명할 수 있는 작은 변경 사항부터 시작하십시오.