리눅스 커널 기여에 AI를 써도 될까? — 커널 공식 문서가 정한 AI 사용 가이드라인

리눅스 커널에도 AI 가이드라인이 생겼어요

요즘 AI 코딩 어시스턴트 — GitHub Copilot, Claude, ChatGPT 같은 도구들 — 안 쓰는 개발자를 찾기가 더 어려울 정도잖아요. 그런데 오픈소스 세계에서 가장 중요하고 까다로운 프로젝트 중 하나인 리눅스 커널에 기여할 때, 이런 AI 도구를 써도 되는 걸까요?

이 질문에 대해 리눅스 커널 프로젝트가 공식 문서를 통해 답을 내놓았어요. Linus Torvalds가 관리하는 공식 리눅스 저장소의 Documentation/process/coding-assistants.rst 파일에 AI 코딩 어시스턴트 사용에 대한 가이드라인이 추가된 건데요, 이건 세계에서 가장 크고 오래된 오픈소스 프로젝트가 AI 시대에 어떻게 대응하는지를 보여주는 중요한 이정표예요.

가이드라인의 핵심은 뭔가요?

문서의 핵심 메시지를 한마디로 요약하면 이래요: "AI를 쓰는 건 괜찮지만, 제출하는 코드에 대한 모든 책임은 온전히 당신에게 있다."

이게 뭔 뜻이냐면, AI가 생성한 코드를 커널에 기여할 때 "이건 AI가 쓴 거라서 잘 모르겠어요"라는 변명이 통하지 않는다는 거예요. 리눅스 커널에 패치를 제출할 때는 DCO(Developer Certificate of Origin)라는 것에 서명해야 하는데, 이건 "이 코드는 내가 작성했거나, 내가 라이선스 조건을 이해하고 제출할 권한이 있다"는 걸 증명하는 서명이에요. AI 도구를 사용했더라도 이 서명의 의미와 무게는 달라지지 않아요.

문서에서 특히 강조하는 포인트들이 있어요.

첫째, 라이선스 문제예요. AI 모델이 학습한 데이터에 GPL이 아닌 라이선스의 코드가 포함되어 있을 수 있거든요. 리눅스 커널은 GPLv2 라이선스인데, AI가 생성한 코드가 다른 라이선스의 코드를 무의식적으로 재현한 거라면 라이선스 충돌이 생길 수 있어요. 이런 리스크를 이해하고 검증하는 건 코드를 제출하는 사람의 책임이에요.

둘째, 코드 품질이에요. 커널 코드는 수십억 대의 기기에서 돌아가는 만큼, 품질 기준이 엄격하기로 유명해요. AI가 생성한 코드는 겉보기에는 그럴듯하지만 엣지 케이스를 놓치거나, 커널 특유의 코딩 컨벤션을 따르지 않거나, 동시성(concurrency) 이슈를 잘못 처리하는 경우가 많거든요. 리뷰어들에게 "AI가 짠 거라 이 부분은 잘 모르겠다"는 식의 태도는 오히려 신뢰를 잃는 지름길이에요.

셋째, AI가 생성한 코드임을 밝힐 필요는 없지만, 그만큼 완전히 자기 것으로 소화해야 한다는 점이에요. 즉 AI 도구를 사용하는 것 자체는 문제가 아니지만, 마치 자동완성이나 컴파일러처럼 "도구"로 쓰되, 최종 결과물에 대해서는 100% 이해하고 책임져야 한다는 거예요.

왜 이 가이드라인이 중요한 걸까요?

리눅스 커널은 오픈소스 생태계의 "헌법" 같은 존재거든요. 커널이 세우는 규칙과 관행은 다른 수많은 오픈소스 프로젝트에 영향을 미쳐요. 커널이 AI 사용에 대해 공식 입장을 정했다는 건, 앞으로 다른 대형 오픈소스 프로젝트들도 비슷한 가이드라인을 만들 가능성이 높다는 뜻이에요.

실제로 이미 비슷한 움직임들이 있어요. 일부 오픈소스 프로젝트는 AI 생성 코드를 아예 금지하는 방침을 세웠고, 반대로 어떤 프로젝트는 AI 사용을 적극 권장하기도 해요. 리눅스 커널의 입장은 이 스펙트럼에서 현실적인 중간 지점 — "금지하지 않되, 책임은 명확히 한다" — 을 잡은 셈이에요.

이 접근법은 사실 상당히 합리적이에요. AI 도구의 사용을 금지하는 건 현실적으로 불가능하기도 하고(누가 AI를 썼는지 확인할 방법이 없으니까요), 그렇다고 무분별하게 허용하면 코드 품질이 떨어질 위험이 있으니까요. "도구는 자유롭게 쓰되, 결과에 대한 책임은 사람이 진다"는 원칙이 현재로서는 가장 실용적인 접근이라고 볼 수 있어요.

커널 메인테이너들의 시각

리눅스 커널 메인테이너들 사이에서도 AI에 대한 의견은 다양해요. 일부는 AI 도구가 보일러플레이트 코드 작성이나 문서화에 유용할 수 있다고 보는 반면, 다른 메인테이너들은 AI가 생성한 저품질 패치가 리뷰 부담을 가중시킬 것을 우려하고 있어요.

특히 후자의 우려는 이미 현실화되고 있는 측면이 있어요. 오픈소스 프로젝트에 AI로 생성한 수정 사항을 대량으로 제출하는 사례가 늘고 있는데, 이런 패치들은 종종 피상적인 수정(변수명 변경, 불필요한 리팩토링 등)에 그치면서 메인테이너들의 시간만 빼앗는 경우가 많거든요. 이른바 "AI 스팸 패치" 문제인데, 이 가이드라인은 이런 문제에 대한 간접적인 경고이기도 해요.

한국 개발자에게 주는 시사점

이 가이드라인은 리눅스 커널 기여자가 아니더라도 새겨볼 내용이 많아요. 우리가 일상적으로 AI 도구를 쓸 때도 같은 원칙이 적용되거든요.

회사에서 AI가 생성한 코드를 프로덕션에 넣을 때, 그 코드에 버그가 있으면 "AI가 짰으니까"라는 건 이유가 안 되잖아요. 코드 리뷰를 할 때도 AI가 생성한 코드인지 아닌지보다, 코드 자체의 품질과 논리를 꼼꼼히 검증하는 습관이 중요해요.

또 오픈소스에 기여하고 싶은 분들이라면, AI를 활용하더라도 제출하는 코드를 한 줄 한 줄 완전히 이해하고 있어야 한다는 점을 명심하세요. 커널뿐 아니라 대부분의 건강한 오픈소스 프로젝트에서 이건 기본 예의이기도 하고요.

팀 리더나 CTO 입장이라면, 우리 팀에서도 AI 도구 사용에 대한 가이드라인을 만드는 걸 고려해볼 시점이에요. 리눅스 커널의 접근법 — 사용은 허용하되 책임은 명확히 — 은 좋은 출발점이 될 수 있어요.

마무리

핵심 한줄: 리눅스 커널의 AI 가이드라인은 "AI는 도구일 뿐, 코드의 주인은 사람"이라는 원칙을 공식화한 것이에요.

여러분 팀에서는 AI 코딩 도구 사용에 대한 규칙이 있나요? 있다면 어떤 기준을 적용하고 있는지, 없다면 필요하다고 느끼시는지 궁금해요!