Insights
AI가 자동으로 큐레이션·번역·정리하는 기술 동향 피드입니다.
이 글은 BSD와 Linux의 운영체제 개발 문화 및 커널 기여 과정을 비교 분석합니다. 라이선스 논쟁보다는 실제 개발 방식과 합의 과정이 중요하며, 각 OS가 독자적인 방향성을 유지하는 것이 장기적으로 성공할 수 있음을 강조합니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 GeekNews의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기FOSS가 강경 반AI·AI 중립 또는 비권장·AI 보조·AI 주도 진영으로 빠르게 갈라지는 모습이 초기 GPL 대 BSD 논쟁을 닮아 흥미로움. 요즘은 라이선스 불평이 줄었고, Linux가 AI 보조 개발을 받아들이면서 열렬한 GPL 지지자 일부도 조용히 입장을 내려놓고 있음.
개발 역량이 분산된다는 점은 아쉽지만, 극단적인 집단끼리는 원래 성향이 맞지 않아 협업도 잘 안 됐음. 이렇게 갈라지는 편이 논쟁에 낭비하는 에너지를 줄이고 개발 흐름을 개선할 수도 있음.
다만 목소리 크고 성가신 이들이 BSD 쪽으로 몰리는 듯함. 나는 AI에 관해 어느 편도 아니고 품질만 보지만, OpenBSD의 묵묵히 개발에 집중하는 문화는 매우 지지하며 그대로 유지되길 바람.
오히려 좋은 일이라고 봄. 몇 년 뒤면 AI가 소프트웨어 개발의 실제 생산성과 성과에 얼마나 영향을 주는지 측정할 수 있을 것임. 완벽한 자연실험이 됨.
AI를 환영하기로 한 프로젝트들은 당연히 AI의 잠재적인 라이선스 문제도 신경 쓰지 않음. 적어도 내가 보기에는 Linux부터 GPL을 그다지 중시한 적이 없음.
GPL 대 BSD보다는 Stack Overflow 복사·붙여넣기 대 직접 작성, 또는 엔지니어가 짠 코드 대 외주 코딩 공장이 찍어낸 코드에 더 가까운 것 아닌가? GPL 대 BSD의 근본 쟁점인 자유와는 다른 사안임.
이런 프로젝트는 Linux에 익숙한 사람에게 낯선 요소 하나를 줄여주므로 잠깐 매력적으로 보이지만, 오래 살아남지는 못하는 듯하며 이유도 분명해 보임.
BSD 프로젝트에 참여하려면 많이 배우고 기여해서 커밋 권한을 얻어야 함. 실질적인 변화를 만들려면 더 많은 작업을 하고, 반대에 감정적으로 반응하지 않으면서 합의도 쌓아야 함. FreeBSD와 NetBSD 소스 커미터로서, 지속적인 영향을 남기려면 이 길을 권함.
NetBSD의 강점인 pkgsrc·pbulk·pkgin을 묶어, 최근 Omarchy가 Arch에 한 것처럼 뚜렷한 방향성의 설치 환경을 만드는 편이 더 오래 살아남을 수 있음. 다만 친구 Larry McVoy의 표현을 빌리면, 늘 혼자 커다란 빨간 소방차를 몰 수는 없다는 뜻임.
제한적인 경험이지만, BSD의 기여 과정은 상대적으로 상당히 불편함. 이유는 이해함.
몇 년 전 NetBSD/sparc를 쓰던 RDI PowerLite 노트북에서 오디오를 재생하면 즉시 재부팅되는 문제가 있었음. SPARCstation 5를 대부분 복제한 기기지만, 오디오는 SPARCstation 1/2와 같은 AMD ISDN 칩으로 μ-law 음성을 처리했음.
커널 오디오 하위 시스템을 크게 개편하면서 해당 드라이버에 뮤텍스 처리가 빠졌고, assert()가 커널 패닉을 일으키는 것이 원인이었음. 기억하기로는 비SMP 시스템이라 잠금이 필요하지 않았지만 새 코드의 엄격한 검사에 걸렸음.
잠금과 해제를 몇 군데 추가하면 해결됐지만, 패치를 어디로 어떻게 제출해야 할지 끝내 알아내지 못함. 8비트 μ-law 오디오를 재미 삼아 살리던 터라 오래 찾아보지는 않았고, 기여 경로 자체가 없다는 뜻은 아님.
반면 Linux의 32비트 PowerPC 시그널 처리기 버그는 담당자를 찾고 대화를 나눈 뒤 패치를 제출하는 과정이 비교적 수월했음. https://marc.info/?l=linuxppc-embedded&m=160963760120837.
둘 다 전 세계 수십 명 정도에게나 영향을 줄 수정이었지만, Linux에는 패치가 들어갔고 NetBSD에는 들어가지 못함.
지금 FreeBSD 쪽에서는 Jordan Hubbard가 Daemonarchy를 대충 엮어 만든 여파가 이어지고 있음. DHH 같은 극단적인 백인 민족주의자와 조금이라도 엮이면 예상할 만한 결과임. 배포판인 척하는 그의 조잡한 설정 파일 모음을 살짝 참조한 정도여도 마찬가지임.
AlpineBSD는 Alpine Linux의 포크가 아니고, 많은 패키지가 aports에 기반하더라도 패키지 모음은 독자적이라고 함. 초기화 시스템도 Alpine Linux의 OpenRC 대신 s6를 쓰고 OpenRC는 나중에 선택지로 추가할 예정이라고 함.
정확히 어디에 선을 그어야 할지는 모르겠지만, 이 정도면 Alpine이라는 이름을 붙이기 어려워 보임. 패키지 모음도 별도이고 서비스 관리자도 다르면 Adélie Linux보다 Alpine Linux에서 더 멀어진 셈임.
BSD 코어에 새로운 사용자 공간을 얹어 운영체제를 만드는 시도는 매우 좋아함. 다만 이름의 의미를 따지는 것임.
무관한 프로젝트가 기존 프로젝트의 이름을 선점하는 건 싫음. 상표는 상업적 수단일 뿐 아니라 사용자가 무엇을 누구에게서 받는지 알게 해줌.
오랜 신뢰를 쌓은 프로젝트의 명성에 편승하면 사용자를 오도하고 혼란스럽게 함. 영감도 코드도 얼마든지 가져가되, 이름까지 훔치지는 말아야 함.
“AI 코드를 최대한 적게 쓰자”는 건 진영 논리임. 누가 또는 무엇이 만들었든 뛰어나고 충분히 검증된 소프트웨어를 원함. AI를 안 썼다는 사실은 아무것도 보장하지 않음. 특히 NetBSD처럼 C 코드베이스라면, 그럴 바에 Rust 진영에도 합류하지 않는 이유는 무엇인가?
아미시가 우리가 당연하게 쓰는 일부 기술을 거부하는 것에 더 가까움. 더 넓게 보면 특정 기술을 사용하지 않기로 선택하는 일임.
비건인 나는 동물의 가축화와 사육, 야생동물 포획과 사냥을 거부하며 정제당과 정제 전분도 피하려고 함. 낙태도 사람들이 강한 입장을 갖는 기술이고, 이제 AI 사용이 여기에 더해짐. 전자계산기가 처음 나왔을 때도 사용을 거부하는 사람이 있지 않았을까?
AI를 배제하는 이유가 무엇인가? 결정을 정당화하지 않고 독자가 이유를 알아서 이해하리라 가정하는데, 나는 이해되지 않음.
예를 들어 binutils, gcc, gdb를 LLM 생성 코드가 없다고 확인한 마지막 버전에 고정하고 있음. 그렇다면 앞으로 상위 프로젝트의 패치를 받지 못하고 직접 유지보수를 떠맡아야 하며, 사실상 AlpineBSD에서 이 도구들의 개발이 멈추는 것 아닌가? 어리석은 결정으로 보임.
이길 수 없는 싸움임. 충분히 좋은 인간 작성 대안이 없는 AI 작성 오픈소스가 쌓이면, 결국 거부할 수 없게 되어 이런 태도도 사라질 것임.
이 선택은 존중할 만함. AI를 이용한 코드 검토는 허용하는 듯하며, 검토 자체가 해가 될 이유는 떠오르지 않음.
이유를 따로 제시하지 않는 건 사용자가 각자 판단하도록 맡긴 것으로 보며, 그것도 괜찮음. 정당화를 내놓지 않는다고 격분한다면 스스로를 돌아볼 필요가 있음.
웹페이지를 읽어도 목표와 추진 단계가 불분명함. AlpineBSD는 실제 하드웨어에서 구동하려는 것인지, Alpine의 주요 용도인 컨테이너를 겨냥한 것인지? AI 생성 코드를 피하려는 사용자라면 왜 NetBSD 대신 이것을 써야 하는지?
관심을 끌려면 맥락을 더 제공하고 첫 화면에 목표와 추진 단계를 명시해야 함.
연결된 s6 도구의 소개도 순환 정의로 시작함. 첫 문단에서 왜 존재하는 도구인지 밝히는 편이 명확함. 아래쪽에는 “s6-frontend의 설계 목표 중 하나”만 나오는데, 설계 목표 전체를 제시하는 편이 낫겠음.
Alpine은 일상용 호스트 운영체제로도 좋음. 단순하고 작으며, Drew가 이끈다는 점에서 실제 하드웨어용일 것으로 추측함. NetBSD 대신 쓸 이유라면 Alpine의 사용자 공간 환경이 좋기 때문임.
새로운 커뮤니티를 만들기 위해서임.
“NetBSD 커널은 Linux보다 하드웨어 지원이 훨씬 부족하니 아무 컴퓨터에서나 AlpineBSD가 작동하리라 기대하지 말라”는데, BSD 종류를 혼동한 것 아닌가? NetBSD는 주류 Linux 배포판이 더는 지원하지 않는 플랫폼까지 사실상 어디서나 돌아간다는 점으로 유명함.
페이지가 연결한 노트북 위키는 AMD64 노트북의 까다로운 주변장치와 드라이버 지원에 관한 것임. 하드웨어 지원은 https://wiki.netbsd.org/ports/부터 살펴보는 편이 나음.
그 명성은 지원 아키텍처의 수에 관한 것임. NetBSD가 여전히 특이한 아키텍처를 지원하지만, 직접 세어보지는 않았어도 Linux 역시 비슷한 수를 지원하리라 봄.
커널이 부팅되는 것과 일상적으로 쓸 만큼 드라이버가 갖춰진 것은 전혀 다름. 내 노트북에서도 NetBSD가 “작동”하지만 이더넷, Wi-Fi, 터치패드, ACPI 절전, 도킹 스테이션을 통한 외부 모니터 연결 등이 안 됨.
재미 삼아 일부 공백을 메우려 하고 있지만, 일반 사용자에게 매력적이지 않은 이유는 분명함.
NetBSD는 기기를 일단 구동할 정도의 코드는 갖췄지만, 제대로 작동하도록 만드는 개발과 테스트는 부족하다는 인상을 받음.
NetBSD 개발자로서, 모든 기기에서 작동한다고는 하지 않겠음.
“돌아간다”의 뜻에 달렸음. 부팅은 되겠지만, Wi-Fi 어댑터나 그래픽카드는 못 쓸 가능성이 큼.
20년 전에는 맞았지만 지금은 그렇지 않음. 오늘날 하드웨어는 훨씬 복잡해서, 아주 기본적인 하드웨어가 아니면 NetBSD가 잘 작동하리라 기대하지 않음.