OpenBSD ext4: OpenBSD가 AI 생성 ext4를 거절한 이유

제목: OpenBSD에 ‘AI로 만든 ext4’가 들어가려다 막힌 이유

“AI가 파일시스템 드라이버까지 뚝딱 만들어주는 시대라면, 커널 코드도 이제 프롬프트로 끝나는 걸까요?”
최근 OpenBSD 커뮤니티에서 LLM(대규모 언어 모델)로 생성된 ext4 구현체가 올라왔다가, 예상대로 큰 논쟁과 함께 사실상 거절된 사건이 있었습니다.

1) OpenBSD에 올라온 ext4 드라이버, 무엇이었나

요약하면, 한 개발자가 OpenBSD 메일링 리스트에 ext4 파일시스템 구현 코드를 제출했어요.
제출자는 “읽기/쓰기 모두 지원하고 e2fsck(ext 계열 파일시스템 검사 도구)도 통과하지만, 저널링(journaling)은 미지원”이라고 설명했습니다.

이게 눈에 띄는 이유는 ext4가 단순한 유틸리티가 아니라 **커널 내부의 핵심 코드(파일시스템 드라이버)**이기 때문이에요.
커널 파일시스템은 데이터 손상, 보안 이슈, 장기 유지보수 비용과 직결돼서 “일단 돌아가네요” 수준으로는 받아들이기 어렵습니다.
게다가 OpenBSD는 전통적으로 코드 품질과 라이선스/저작권 명확성에 매우 보수적인 프로젝트로 유명하죠.

2) “리눅스 코드는 안 봤고, ChatGPT/Claude로 만들었다”가 불씨가 됐다

요약은 간단해요. 제출자가 나중에 “이 코드는 리눅스 소스 파일을 읽지 않았고, **순수 AI(ChatGPT, Claude-code)**로 만들었다”고 밝히면서 상황이 폭발했습니다.
즉, ‘클린룸 구현(clean-room reimplementation)’을 주장하지만, 실제 코딩은 LLM이 했고 본인은 리뷰/테스트를 했다는 맥락이었어요.

여기서 문제가 되는 건 “AI로 만들면 편하잖아?”가 아니라, 그 코드의 ‘출처(provenance)’와 ‘권리 상태’가 무엇인지 증명하기 어렵다는 점입니다.
특히 ext4 자체가 리눅스 생태계와 강하게 연결된 구현/문서/관행이 많아서, 결과물이 **GPL 코드의 파생물(derived work)**로 해석될 여지가 있다는 우려가 나왔죠.
OpenBSD 입장에선 GPL 코드 유입은 거의 “금기”에 가깝기 때문에, 초반부터 반응이 날카로울 수밖에 없었습니다.

3) OpenBSD가 특히 민감한 포인트: “저작권이 불명확하면, 배포 권한도 없다”

요약하면 OpenBSD의 핵심 논리는 이거예요: 저작권자가 누구인지 불명확한 코드는 프로젝트에 넣을 수 없다.
Theo de Raadt는 구조/알고리즘 재구현 자체는 저작권법적으로 가능하다고 보면서도, LLM 생성물은 저작권 귀속이 ‘현재 제도에서’ 애매하다고 지적했습니다.

왜 이게 치명적이냐면, 프로젝트에 코드를 합치고 재배포하려면 “우리가 이 코드를 배포해도 된다”는 권리가 명확해야 하거든요.
그런데 LLM 출력물은 “사람이 창작한 저작물인가?”부터 국가별로 해석이 다르고, 저작권이 아예 성립하지 않을 수도 있다는 주장도 있습니다.
저작권이 없다면 오히려 공공재처럼 쓸 수 있지 않냐는 반론도 가능하지만, OpenBSD는 “그렇게 단순화하면 나중에 법이 바뀌었을 때 폭탄이 된다”는 쪽에 더 무게를 둔 거죠.

4) 결론은 사실상 확정: “받을 가능성은 0%”

요약하자면, OpenBSD는 이 코드가 좋은지/나쁜지 이전에 리스크가 너무 크다고 판단했어요.
Theo de Raadt가 “이렇게 수상한 저작권 상황의 새 코드를 받을 가능성은 0”이라고 못 박으면서 결론은 정해졌습니다.

제출자는 이후 “LLM 생성 코드는 제거하고, 본인이 직접 작성한 코드만 남기겠다”고 했지만, 문제는 신뢰입니다.
한 번 “AI가 대부분 쓴 코드”가 공개적으로 밝혀진 뒤에는, 다음 버전이 진짜 사람이 쓴 건지 커뮤니티가 확신하기가 어렵죠.
심지어 제출자는 “OpenBSD를 포크(fork)하는 게 더 쉬울 수도”라고 했는데, 해당 커뮤니티 반응을 보면 현실적으로 쉽지 않은 길입니다.

5) ‘라이선스’만의 문제가 아니다: 유지보수와 폭발하는 중복 코드

요약하면, LLM 코드가 커뮤니티에 들어올 때의 공포는 유지보수 불능이에요.
기사에서도 “원 저자가 코드를 이해하지 못하면 누가 유지보수하나?” 같은 지적이 나왔고, 댓글에서도 “AI는 돌아가는 초안은 만들지만 리팩터링/구조화가 약하다”는 경험담이 이어졌습니다.

특히 파일시스템처럼 복잡하고 위험한 영역에서 “일단 구현 하나 더 만들자”는 접근은 장기적으로 비용이 큽니다.
기존 ext2fs를 확장하는 형태(diffs)로 가는 대신, 독립 구현을 대량 생성해버리면 “복사/붙여넣기/분기(diverge)”가 생기고, 결국 서로 다른 버그와 서로 다른 수정이 쌓여요.
실무에서도 LLM 때문에 “짧은 스크립트로 해결할 일을 수천 줄 프로그램으로 만든다”는 현상이 벌어진다는 지적은, 커널 커뮤니티가 더 예민하게 받아들일 만한 포인트입니다.

6) 실제로 우리가 배울 ‘현실적인’ 사용 시나리오

요약하면, LLM은 ‘제출용 코드 생성기’보다 ‘검토/분석/테스트 보조’에 더 잘 맞는다는 교훈이 큽니다.
OpenBSD가 AI를 싫어해서가 아니라, “프로젝트에 합치려면 법적/기술적 책임을 져야 한다”는 조건이 있기 때문이에요.

현실적인 활용 시나리오는 이런 쪽이 좋아요.

• LLM으로 문서/스펙 요약: ext4의 extents, checksum 같은 개념을 빠르게 정리해 설계 이해 시간을 줄일 수 있어요.
• LLM으로 코드리뷰 체크리스트 생성: 경계값, 엔디안(endian), 오류 처리, 락(lock) 범위를 질문형으로 뽑아두면 리뷰 품질이 올라가요.
• LLM으로 테스트 케이스 아이디어 확장: 파일시스템은 “정상 케이스”보다 “망가지는 케이스”가 중요해서 퍼징(fuzzing)·전원 장애·부분 쓰기 같은 시나리오를 더 촘촘히 만들 수 있어요.
• 반대로, LLM으로 커널 핵심 모듈을 통째로 생성해 기여하는 방식은, 저작권/유지보수/신뢰 모두에서 충돌 가능성이 큽니다.

마무리: AI 코드, “돌아가냐”보다 “책임질 수 있냐”가 먼저예요
이번 OpenBSD-ext4 사건은 결국 AI가 코드를 만들 수 있느냐가 아니라, 그 코드를 커뮤니티가 장기적으로 책임질 수 있느냐의 문제를 드러냈어요. 특히 커널·파일시스템처럼 한 번 사고 나면 피해가 큰 영역일수록, 프로젝트는 보수적으로 움직일 수밖에 없습니다.

여러분이 오픈소스에 기여하거나 사내 레포에 AI 코드를 섞고 있다면, 오늘부터는 “어떻게 만들었는지”를 넘어서 출처 기록(provenance), 라이선스 가정, 유지보수 주체까지 한 번 더 점검해보면 좋겠습니다.