데비안, AI 기여를 금지하지 않기로 했다…개발자가 끝까지 책임져야 하는 이유

AI를 활용하여 생성한 이미지입니다.

Debian 프로젝트는 생성형 AI를 사용한 기여를 전면 금지하지 않기로 했습니다. 그러나 이 결정은 AI가 만든 코드를 검토 없이 제출해도 된다는 허가가 아닙니다. 공식 결의의 핵심은 도구의 사용 여부와 관계없이 기여물이 Debian의 품질·정확성·유지보수성·법적 기준을 통과해야 하며, 제출자가 그 결과에 책임져야 한다는 데 있습니다.[1]

이번 결의가 실제로 정한 범위

이번 사안은 Debian 헌법에 따른 일반 결의 절차로 다뤄졌습니다. Debian 헌법은 개발자가 비기술적 정책 문서와 입장문을 발행·대체·철회할 수 있는 절차를 정하고 있습니다.[2] 투표 일정과 정정된 투표지는 Debian 개발자 메일링리스트에 공개됐습니다.[3] 최초 제안은 LLM 도움을 받은 기여를 금지하자는 문제의식에서 출발했습니다.[4]

채택된 선택지는 Responsible Use of Generative AI입니다. 공식 문구는 Debian에서 소프트웨어의 개발·유지보수·문서화, 패키징과 미디어 제작에 생성형 AI를 사용할 수 있는지에 대해 찬성도 반대도 하지 않는다고 설명합니다.[1] 따라서 모든 작업에 AI를 사용하라는 뜻도, 모든 하위 프로젝트가 같은 도구나 공개 절차를 따라야 한다는 뜻도 아닙니다.

저작권과 라이선스부터 확인하기

Debian 사회계약과 Debian 자유 소프트웨어 지침은 자유로운 소프트웨어 배포와 소스 코드·수정물의 취급에 관한 원칙을 제시합니다.[5] Debian Policy는 패키지가 배포 라이선스의 원문 사본을 포함하도록 요구합니다.[6] AI 서비스가 출력물의 권리 상태를 자동으로 보증하지 않는다면, 최종 제출자가 Debian에 넣어도 되는 이유를 설명할 수 있어야 합니다.

1. AI가 제안한 코드와 문서를 사람이 직접 읽고 실제 채택한 범위를 변경 기록에 남깁니다.
2. 특정 프로젝트의 코드나 문장이 거의 그대로 복제된 것처럼 보이는 부분을 찾아 원 출처·저작권 표시·라이선스를 확인합니다.
3. 새 의존성의 이름·버전·라이선스·재배포 조건을 확인하고 debian/copyright와 패키지 메타데이터를 실제 배포물과 대조합니다.
4. 모델이 제시한 출처나 라이선스 문구를 사실로 간주하지 말고 원문을 직접 확인합니다.
5. 권리 상태를 합리적으로 설명할 수 없는 부분은 제거하거나 담당자·법률 검토를 거친 뒤 제출합니다.

“AI 출력물은 저작권이 없다”거나 “모델이 학습한 코드의 라이선스가 자동으로 따라온다”고 단정할 근거는 이번 결의에 없습니다. 법적 상태가 관할마다 논의 중이라는 점을 결의가 인정했으므로, 불확실성을 기록하고 보수적으로 처리해야 합니다.[1]

품질과 정확성은 기존 절차로 검증하기

문법적으로 실행되는 코드와 Debian에 유지보수 가능한 코드는 다릅니다. 요구사항을 한 문장으로 다시 쓰고, 생성된 변경이 그 요구사항을 해결하는지 줄 단위로 확인하세요. 사용하지 않는 코드, 프로젝트 관례와 맞지 않는 설정, 오류를 숨기는 예외 처리는 사람이 걷어내야 합니다.

• 기존 테스트와 새 회귀 테스트를 실행하고 실패한 결과를 숨기지 않습니다.
• 린터·정적 분석·타입 검사·패키지 빌드를 조건에 맞춰 수행합니다.
• 빈 값, 잘못된 형식, 큰 입력, 네트워크 단절과 권한 부족에서 실패 방식이 안전한지 확인합니다.
• 설치·업그레이드·제거 뒤에도 파일과 설정이 남지 않는지 패키지 관점에서 살핍니다.
• debian/changelog에 변경 이유와 범위를 프로젝트 방식에 맞게 기록합니다.[6]

외부 보도도 핵심 통제가 AI 전용 관문이 아니라 기존의 사람 검토에 남아 있다고 정리했습니다.[7] 모델이 만든 줄을 읽고 실행하고 고치는 과정을 생략하면 개발 속도가 아니라 검토 부채가 됩니다.

보안과 비공개 정보

공식 결의는 비공개 문서, 사적인 대화, 공개하지 않은 취약점 정보, 암호화 키와 자격 증명을 승인 없이 제3자 AI 서비스에 보내지 않도록 주의합니다. 여러 패키지에 영향을 주는 대량 버그 보고·패치·자동 변경은 시작 전에 적절한 채널에서 논의하고, 자동화 결과를 책임지는 사람이 감독해야 합니다.[1]

코드 조각을 외부 서비스에 입력하기 전 비밀값과 내부 주소를 제거하고, 서비스의 보관·학습·접근 정책을 확인하세요. 인증·권한·암호화·셸 명령·파일 경로는 높은 위험 영역으로 분류해 별도 검토합니다. 취약점이 의심되면 공개 메일링리스트에 세부 내용을 붙여 넣지 말고 Debian의 보안 절차를 따르세요.[8]

유지보수자의 입장에서 다시 읽기

제출 당시 통과한 코드보다 중요한 것은 몇 달 뒤 다른 기여자가 이유를 설명하고 고칠 수 있는가입니다. 모델이 만든 복잡한 추상화를 프로젝트 관례에 맞게 단순화하고, 의도를 보여 주는 테스트와 문서를 남기세요. AI 사용 사실을 공개하면 검토자가 출처와 위험 지점을 질문할 기회가 생기지만, 공개는 검토의 대체물이 아닙니다.

제출 전 10분 점검표

1. 변경의 요구사항과 범위를 한 문장으로 설명할 수 있나요?
2. 생성된 모든 줄을 읽고 이해했나요?
3. 테스트·린터·빌드·설치·제거를 실제로 실행했나요?
4. 실패 입력과 권한·보안 경계를 확인했나요?
5. 의존성·저작권 표시·라이선스 원문이 맞나요?
6. debian/copyright와 changelog의 근거가 일치하나요?
7. 비공개 정보가 외부 서비스로 전송되지 않았나요?
8. 대량 자동화라면 사전 논의와 사람의 감독이 있나요?
9. 다음 유지보수자가 몇 달 뒤 이 변경을 고칠 수 있나요?

자주 묻는 질문

Debian이 AI 기여를 공식 승인한 것인가요?

무조건 승인한 것이 아닙니다. 생성형 AI 사용 여부에 중립적 입장을 취하면서 기존 품질·법적·유지보수 기준을 그대로 적용한 것입니다.[1]

AI 사용 사실을 반드시 공개해야 하나요?

결의는 공개를 권장하지만 의무로 만들지는 않았습니다. 다만 공개 여부와 관계없이 제출자가 결과를 이해하고 검증할 책임은 남습니다.[1]

AI가 만든 라이선스 파일을 그대로 넣어도 되나요?

안 됩니다. 모델이 말한 라이선스와 저작권 문구를 원문과 대조하고, 의존성과 배포 조건을 확인해야 합니다.

보안 취약점 코드를 AI에 물어봐도 되나요?

비공개 취약점 정보와 자격 증명을 승인 없이 외부 서비스에 보내면 안 됩니다. Debian 보안 절차와 서비스 정책을 먼저 확인하세요.[8]

정리

Debian의 결정은 AI 사용을 면허처럼 허용한 것이 아니라 도구 중립적인 책임 원칙을 확인한 것입니다. 개발자는 무엇을 사용했는지보다 무엇을 제출하는지, 출처·라이선스·테스트·보안·유지보수 과정을 설명할 수 있어야 합니다. 설명할 수 없는 출력물은 더 검토하거나 사용하지 않는 편이 안전합니다.

기여 유형에 따라 달라지는 검토 지점

작은 문서 수정과 패키지의 실행 코드 변경은 위험의 모양이 다릅니다. 문서라면 사실 관계와 인용, 명령어가 현재 Debian 환경에서 안전한지를 확인해야 합니다. 실행 코드라면 입력 검증과 오류 처리, 회귀 테스트가 우선입니다. 패키징 변경이라면 새 파일이 실제 소스 패키지에 포함되는지, 설치·제거 뒤 남는 파일이 없는지, 저작권과 라이선스 문서가 배포물과 일치하는지를 확인하세요.

AI가 제시한 여러 대안을 한 번에 병합하는 것도 피하는 편이 좋습니다. 먼저 최소 변경으로 요구사항을 해결하고, 각 변경의 이유와 검증 결과를 분리해 기록하세요. 그러면 나중에 문제가 생겼을 때 어떤 제안이 채택됐고 어떤 테스트가 그 선택을 뒷받침했는지 설명할 수 있습니다. 이 기록은 AI 사용 공개 여부와 별개로 유지보수자에게 필요한 근거입니다.

작업을 중단해야 하는 신호

테스트가 실패했는데 원인을 설명하지 못하거나, 라이선스 출처가 확인되지 않거나, 비공개 자료를 외부 서비스에 보냈을 가능성이 있다면 제출을 멈추세요. 결의의 중립성은 이런 위험을 대신 승인해 주지 않습니다.

관련 글: AI 모델 피로감, 일주일에 새 버전이 쏟아질 때 개발자가 확인할 것

Sources

1. [1] Debian, General Resolution: LLM usage in Debian — Responsible Use of Generative AI 결의의 범위와 책임.
2. [2] Debian Constitution — 일반 결의와 프로젝트 의사결정 절차.
3. [3] Debian debian-vote, General resolution: LLM usage in Debian: corrected ballot — 투표 공지와 정정된 투표지.
4. [4] Debian debian-vote, Re: GR: Ban LLM contributions from Debian — AI 기여 금지 제안의 배경.
5. [5] Debian Social Contract and Debian Free Software Guidelines — 자유 소프트웨어와 배포 원칙.
6. [6] Debian Policy Manual, Source packages — 소스 패키지·라이선스·changelog 정책.
7. [7] Help Net Security, Debian developers rejected an LLM ban and left disclosure voluntary — 결의의 외부 해설.
8. [8] Debian Security Information — Debian 보안 취약점 신고와 대응 안내.