요약
NetBSD 커널에 Alpine Linux식 도구를 얹고 AI 생성 코드를 최대한 뺀 운영체제가 나왔습니다.
AlpineBSD 프로젝트 위키의 소개 글입니다. AI가 만든 소프트웨어를 되도록 적게 쓰는 것을 목표로 내세웠고, 아직 개발 중이라고 밝혔습니다.
왜 중요한가
- AI 생성 코드를 받지 않으려는 쪽이 기존 프로젝트를 넘어 운영체제를 따로 꾸리기 시작했습니다.
- 사용자는 AI 생성물이 섞인 패키지를 쓸지 저장소 단위로 직접 고를 수 있습니다.
핵심 내용
- 기본 시스템과 main 저장소에는 LLM 출력물이 없고, 기여자도 생성형 AI 도구를 쓸 수 없습니다.
- AI 생성물이 조금이라도 섞인 패키지는 tainted(오염) 저장소로 분리해, 사용자가 직접 켜야 설치됩니다.
- gcc, gdb, perl 등은 AI 생성물이 섞이기 전의 마지막 버전으로 고정했습니다.
- 패키지 관리자 apk-tools와 busybox를 쓰지만, Alpine Linux의 포크가 아니라 독자적인 패키지 모음을 갖췄습니다.
- 설치 프로그램이 아직 없고, NetBSD의 하드웨어 지원이 리눅스보다 고르지 않아 노트북은 지원 목록부터 보라고 안내합니다.
HN 반응
- 오픈소스가 AI 반대·활용 진영으로 갈라진다는 평가에, NetBSD는 AI 결과물에 GPL이 적용될 위험 때문에 막는다는 보충이 붙었습니다.
- BSD 커미터라는 이용자는 이런 파생 프로젝트가 오래가지 못한다고 봤고, BSD는 기여 절차가 어렵다는 경험담도 나왔습니다.
FOSS가 "강경" 반AI, AI 중립~기피, AI 보조, AI 주도 진영으로 빠르게 쪼개지는 모습이 흥미롭습니다. 초창기 GPL 대 BSD 논쟁을 보는 듯합니다. 갑자기 라이선스 불만이 별로 안 보이고, 골수 GPL 지지자 일부는 리눅스가 AI 보조 개발을 받아들이는 와중에 말없이 그 입장을 접고 있습니다.
한편으로는 개발자들의 노력이 분산될 수 있어 아쉬운 일입니다. 하지만 다른 한편으로, 가장 극단적인 집단들은 어차피 성향이 맞지 않아 함께 일을 잘 못 했습니다. 이렇게 알아서 갈라지는 게 오히려 개발 속도를 높이고 말싸움에 쓰는 에너지를 줄여 줄 수도 있습니다.
단점은 시끄럽고 피곤한 사람들이 상당수 BSD 쪽으로 몰리는 것 같다는 점입니다. 저는 AI에 대해서는 어느 쪽도 아니고(품질만 신경 씁니다), OpenBSD의 묵묵히 집중하는 개발 문화를 아주 좋아합니다. 그게 바뀌지 않기를 바랍니다.
NetBSD가 AI 사용을 일체 거부하는 이유는, GPL 코드로 학습한 LLM의 출력물도 라이선스의 전염 조항 때문에 GPL을 따라야 한다는 판결이 나중에 나올까 봐 우려하기 때문입니다.
와, 그렇게 되면 정말 끝내주겠네요. 사실상 모든 소프트웨어가 자유롭게 풀린다니, 얼마나 멋진 일입니까?
끝내주겠죠. 실직 상태로 그 소프트웨어를 실컷 가지고 놀 시간이 넘쳐날 테니까요.
모든 게 GPL이 되면 우리 모두 실직한다는 말씀입니까?
지금도 거의 모든 소프트웨어를 AI로 리버스 엔지니어링할 수 있습니다. 그러니 해자는 어차피 무너집니다. 지저분한 카피레프트든 아니든 상관없이요.
시스템을 합법적으로 리버스 엔지니어링하는 건 AI에 던져 넣는 것보다 훨씬 어렵습니다. 적어도 이 일로 법정에 불려 갈 수 있다고 생각한다면 말입니다.
에이, 저는 바리스타로 열심히 일하고 있을걸요. 취업은 확실히 했죠.
대신 코드는 전부 공짜겠지만요.
소프트웨어가 아닌 직업도 있고, 자유 소프트웨어를 지원하고 개발하는 유급 일자리도 있습니다.
어차피 AI가 등장하면 우리 중 상당수는 직업을 바꿔야 할 겁니다.
미국 법원이 그렇게 판단할 가능성은 사실상 0입니다. 다른 시장이라면 모를까요...
Apple 대 OpenAI 소송의 일부 쟁점이 LLM을 거치면 저작권이 사라지는지에 대한 판결로 이어질 수 있다고 생각합니다.
저작권이 유지된다고 확정되면, 다른 누군가가 GPL 문제를 이어서 제기할 수 있겠죠.
다행히 미국 외 나머지 세계에는 수백 개의 다른 나라가 있고, 미국은 분열해서 스스로를 갈가리 찢어놓으려고 있는 힘껏 최대한 빠르게 달려가고 있으니까요.
...아니면 상용 소프트웨어 업체들이 VCS를 몇 년 전 시점으로 되돌려서 거기서부터 다시 시작할 수도 있고요.
그렇긴 한데, 그래도 되돌리기 직전에 배포한 마지막 버전의 소스 코드는 공개해야 할 테고, 그걸 포크할 수 있겠죠.
보통 법원은 코드를 오픈소스로 공개하도록 강제하기보다는 저작권 침해에 벌금을 부과해 왔습니다. 코드가 오픈소스로 공개된 경우는 대개 벌금을 피하려는 합의의 결과였고요.
법원을 설득해 특정 이행을 명령하게 하기는 어렵고, 이 사건은 그렇게 될 가능성이 조금이라도 있는 종류가 아닙니다.
비허용적(non-permissive) 라이선스 전반과 법적 문제가 이유 아닐까 싶은데요? 카피레프트만 문제로 본다는 건 지나치게 반사회적으로 들려서, 대표적인 예 하나를 골라 말씀하신 거라고 생각합니다. (그게 아니라면 저는 NetBSD를 멀리해야겠네요.)
맥락상 코드의 소유권이 명확한지를 우려하는 것으로 보입니다. 라이선스나 소유권이 불분명할 수 있는 코드를 제출하지 말라는 규칙과 한데 묶여 있거든요. NetBSD 커밋 가이드라인의 해당 부분은 이렇습니다.
GitHub/Microsoft의 Copilot, OpenAI의 ChatGPT, Facebook/Meta의 Code Llama 같은 대규모 언어 모델 또는 유사 기술로 생성한 코드는 오염된 코드로 간주하며, 코어 팀의 사전 서면 승인 없이 커밋해서는 안 됩니다.
저는 좋은 일이라고 생각합니다. 몇 년 뒤면 AI가 소프트웨어 개발의 생산성과 영향력에 실제로 얼마나 기여했는지(혹은 기여하지 못했는지)를 분명히 측정할 수 있을 겁니다. 완벽한 "자연 실험"이니까요.
그 사람들은 생산성 때문에 그러는 게 아닙니다. 반LLM 동기를 정리한 글이 Sourcehut의 이용약관 변경 공지에 있습니다: https://sourcehut.org/blog/2026-08-27-tos-changes-and-llms/
생산성 때문이 아닌 건 맞지만, 몇 년 뒤면 누가 더 생산적이었는지는 어차피 분명해질 겁니다.
생산성을 측정하는 방법은 지금도 있습니다. 그냥 과시하고 싶은 게 아니라면 AI가 측정 대상을 바꾸지는 않습니다. "10만 줄, 전부 AI가 짠 코드"라는 말을 볼 때마다, 그 정도의 일은 아마 훨씬 적은 코드로도 할 수 있었겠다는 생각이 듭니다. 생산성을 그런 식으로 재면 항상 실패하게 됩니다. CTO로 일할 때 제 신조는 "나는 시간이 아니라 성과에 돈을 낸다"였습니다. AI 코딩 도구는 말 그대로 도구일 뿐이고, 이에 대한 제 관점은 달라지지 않았습니다. 저는 특히 로컬에서 LLM으로 상당한 힘든 작업을 맡기며 일하는 게 즐겁습니다. 저는 토큰에 돈을 내는 게 아니라 성과에 돈을 내는 겁니다.
오픈소스 소프트웨어의 생산성을 측정하는 방법이 어떤 게 있나요? 그쪽 도구는 대부분 여전히 코드 줄 수와 순환 복잡도에 초점을 맞추고 있는데요.
내세우는 이념이 현실과 딱 맞지는 않으니, 그렇지 않습니다.
AI가 쓴 코드를 감시자가 팔에 매달려 일거수일투족을 지켜보지 않는 이상 가려내는 건 여전히 연구 주제입니다...
...그리고 지난 FSF/GNU 행사에 열 번쯤 다녀온 사람으로서 말씀드리면, 그 커뮤니티에도 컴퓨팅 세계 다른 곳만큼 라이선스를 어기는 사기꾼과 불한당이 있습니다. 다만 대체로 좋은 쪽으로 기우는 경향이 있을 뿐이죠. 마이크로소프트 직원이 전부 유아의 피를 마셔야 하는 건 아니지만(분기 실적에 보기 좋긴 하겠죠) 그런 것과 비슷합니다.
비교가 성립하려고 AI 0% 대 AI 100%일 필요는 없습니다.
말하자면 IT계의 아미시네요.
마차에서 자동차로 넘어가는 것과 같은 변화고요.
이런 프로젝트들은 처음에는 반짝 매력을 끄는 경향이 있습니다. 특히 리눅스에 익숙한 사람들에게는 낯섦이 한 단계 줄어들기 때문인데, 제가 보기에는 뻔한 이유로 오래 가지 못하는 것 같습니다.
BSD 프로젝트 같은 곳에 참여하기는 어렵습니다. 배워야 할 게 많고, 커미터 권한을 받을 만큼 노력도 들여야 하니까요. 그리고 판을 바꾸고 싶다면 더 많은 일을 하고, 의견이 갈려도 감정적으로 흐르지 않으면서 합의를 끌어내야 합니다. 그래도 장기적으로 영향력을 남기고 싶다면 이 길을 권하고 싶습니다. FreeBSD와 NetBSD src 커미터로서 경험에서 하는 말입니다.
또 pkgsrc는 NetBSD의 강점 중 하나이고 pbulk, pkgin과 함께 쓰입니다. 이걸 전부 하나로 묶어 주관이 뚜렷한 설치판으로 만들면(최근 Omarchy가 Arch에 한 것처럼) 훨씬 오래 살아남는 시도가 될 겁니다. 하지만 제 친구 래리 맥보이가 말하곤 했듯이, 커다란 빨간 소방차를 항상 혼자 몰 수는 없다는 뜻이기도 합니다.
BSD 쪽 기여 경험이 상대적으로 형편없는 건 사실입니다. 이유는 이해하지만요. 물론 제 경험은 아주아주 제한적입니다.
몇 년 전에 NetBSD/sparc에서 오디오 재생 문제를 만난 적이 있습니다. 제가 쓴 건 RDI PowerLite 노트북인데, SPARCstation 5 호환기를 노트북 섀시에 욱여넣은 물건으로 80%는 같습니다. 다른 20% 중 하나가 오디오 칩이었는데, SPARCstation 1/2에 쓰인 것과 같은 AMD ISDN 칩으로 mu-law 오디오를 처리합니다.
오디오를 재생하기만 하면 노트북이 즉시 리셋됐습니다. 응? 이상하네. 알아보니 최근 누군가 커널의 오디오 드라이버 서브시스템을 대대적으로 개편했는데, 해당 오디오 드라이버에 뮤텍스 연산이 빠져 있어서 assert()가 커널 패닉을 일으키고 있었습니다.
SMP가 아닌 시스템에서는 락이 필요 없었을 겁니다(제 기억으로는). 그런데 새 코드가 더 엄격하게 검사하는 바람에 커널 패닉이 난 거죠.
패치는 꽤 쉬웠습니다. 락과 언락 몇 줄을 추가하면 됐으니까요. 하지만 그 패치를 그 뒤로 어떻게 해야 하는지는 끝내 알아내지 못했습니다.
그냥 제가 멍청한 것일 수도 있습니다. 방법이 없다는 뜻은 아니고, 제가 못 찾았을 뿐입니다. 오래 시도한 것도 아닙니다. 8비트 mu-law 오디오를 돌려 보는 건 그냥 재미로 하던 엉뚱한 짓이었으니까요.
그런데 비교하자면, 32비트 PowerPC의 시그널 핸들러에서 버그를 찾았을 때는 패치를 만드는 과정이 꽤 명쾌했던 걸로 기억합니다. 담당 메인테이너를 찾아 대화를 열고, 결국 패치를 제출했죠: https://marc.info/?l=linuxppc-embedded&m=160963760120837
두 수정 모두 결국 크게 중요하진 않았고, 지구 전체에서 영향받는 사람도 기껏해야 수십 명이었을 겁니다. 그래도 리눅스는 패치를 받았고, NetBSD는 못 받았네요...
패치를 담아 개발자 메일링 리스트에 이메일을 보내면 됩니다. 리눅스, Git 자체, 그 밖의 많은 프로젝트와 똑같습니다.
요즘 FreeBSD는 선택지가 너무 많습니다. GitHub PR, Phorge PR, Bugzilla 패치, Phabricator 패치, 메일링 리스트 패치... 코드를 공유하는 건 어려운 부분이 아닙니다. NetBSD는 Gnats PR이나 메일링 리스트에 패치 또는 링크를 올리는 방식이 여전히 정석입니다.
실제로 뭔가를 해 줄 수 있고 해 줄 사람의 관심을 끄는 건, 그게 누군지 모르면 여전히 어렵습니다. 제가 리눅스 메일링 리스트에 보낸 패치가 답을 못 받고 묻혔을 때도 똑같은 문제였고, 기업 소속 메인테이너들에게 개별 연락을 해 봐도 구체적인 피드백이나 앞으로 진행할 방법은 전혀 받지 못했습니다.
네, 제 일화에 너무 큰 무게를 실은 것 같습니다. 저는 아주 오래 찾아보진 않았고, 리눅스 쪽은 코드가 몇몇 사람이 만든 작은 패치 묶음의 일부였던 데다, Michael Ellerman이 정말 친절했고 IRC에서 소통도 잘해 줬고 아주 틈새의 괴상한 패치들을 기꺼이 받아줘서 더 수월했던 겁니다.