▲

FreeBSD에는 내 오래된 MacBook용 Wi-Fi 드라이버가 없었다, 그래서 AI가 만들어줬다

 (vladimir.varank.in)
7P by GN⁺ 17시간전 | ★ favorite | 댓글 2개
  • 2016년형 MacBook Pro의 Broadcom BCM4350 칩은 FreeBSD에서 기본 지원되지 않아, 기존에는 Linux VM을 통한 wifibox 우회 방식이 일반적이었음
  • 작성자는 Claude Code를 이용해 Linux의 brcmfmac 드라이버를 FreeBSD로 포팅하려 했으나, 커널 패닉과 LinuxKPI 호환성 문제로 실패함
  • 이후 Pi coding agent를 사용해 brcmfmac의 동작 원리를 분석하고, BCM4350 전용 11장짜리 기술 명세서(specification) 를 AI가 작성함
  • 여러 AI 모델(Opus, Codex, Gemini 등)을 교차 검증해 명세를 보완한 뒤, 이를 기반으로 FreeBSD용 신규 드라이버를 완전 자동 생성함
  • 결과물은 Wi-Fi 스캔, 2.4/5GHz 연결, WPA/WPA2 인증을 지원하는 커널 모듈로 완성되었으며, 코드는 GitHub에 공개됨

배경

  • 2016년형 MacBook Pro는 Broadcom BCM4350 Wi-Fi 칩을 사용하지만, FreeBSD에는 해당 칩을 위한 네이티브 드라이버가 없음
    • FreeBSD 포럼에서는 wifibox라는 Linux VM을 통해 brcmfmac 드라이버를 사용하는 방법이 일반적으로 제시됨
  • brcmfmac은 Broadcom의 FullMAC 칩용 Linux 드라이버로, 802.11 프레임 처리와 WPA 암호화 같은 작업을 칩 내부 펌웨어에 위임함
  • FreeBSD용 네이티브 모듈을 만들려면, Linux 코드의 일부를 FreeBSD에 맞게 포팅하는 “glue code” 변환이 필요함

Act 1 — Claude Code로의 첫 시도

  • 작성자는 Claude Code를 이용해 brcmfmac 코드를 FreeBSD용으로 변환 시도
    • FreeBSD의 LinuxKPI 호환 계층을 참고해 Intel용 iwlwifi 드라이버 방식을 따르도록 요청함
  • 모듈은 컴파일되었지만 실제 하드웨어에서 작동하지 않았고, 커널 패닉이 발생함
  • Claude는 #ifdef __FreeBSD__ 구문을 추가하며 수정했으나, LinuxKPI의 결함으로 인해 여전히 불안정했음
  • AI는 프로젝트가 “복잡하고 지저분해질 것”이라 경고했으며, 결과적으로 작동하지 않는 코드만 남음

Act 2 — 명세서 기반 접근

  • 이후 Pi coding agent를 사용해 brcmfmac 드라이버의 구조를 BCM4350 중심으로 분석하고, 클린룸 구현용 상세 명세서를 작성시킴
  • AI는 11개 장으로 구성된 문서를 생성함
    • 예: 00-overview.md, 04-firmware-interface.md, 08-data-path.md 등
  • 작성자는 Codex 모델을 이용해 명세서와 실제 코드의 불일치를 검증하고 수정함
  • 이어서 Opus 모델로 재검증하여 수정 내용이 코드와 일치하는지 확인함
  • 여러 모델을 비교한 결과, Gemini 3 Pro preview가 가장 많은 오류(“hallucination”)를 보였다고 언급됨

Act 3 — 새 FreeBSD 드라이버 구축

  • 명세서를 기반으로 BCM4350용 FreeBSD 드라이버를 새로 작성하는 프로젝트를 시작함
  • AI는 프로젝트 구조, 언어(C 사용 여부), LinuxKPI 의존성, 마일스톤 등 설계 결정을 문서화함
  • 초기에는 LinuxKPI를 사용했으나, 복잡성 증가로 인해 네이티브 FreeBSD 코드로 전환함
  • AI는 SSH를 통해 빌드 호스트와 테스트 VM에 접근해 자동 빌드·테스트 루프를 수행함
    • VM이 크래시할 때마다 원인을 요약·기록하도록 설정
  • 반복 세션 끝에 Wi-Fi 스캔, 2.4GHz/5GHz 연결, WPA/WPA2 인증이 가능한 커널 모듈 완성

결과 및 공개

  • 완성된 드라이버는 GitHub 저장소 github.com/narqo/freebsd-brcmfmac에 공개됨
  • 작성자는 “직접 코드를 작성하지 않았다”고 명시함
  • 일부 알려진 문제가 남아 있으며, 현재는 학습용 참고 수준으로만 사용할 것을 권장함
▲
heal9179 13시간전  [-]

보안에 구멍이 텅텅~

답변달기
▲
GN⁺ 17시간전  [-]
Hacker News 의견들

  • 내가 보기엔 spec-first 접근법이 핵심 통찰임
    AI 코드 생성에서 모델이 구현 전에 상세한 명세서를 먼저 작성하게 하면 반복 주기가 크게 줄어듦
    명세 없이 시작하면 모델이 그럴듯한 접근들 사이에서 헤매지만, 좋은 명세가 있으면 수천 줄의 코드에서도 일관성을 유지함
    두 달이라는 개발 기간도 흥미로움. 커널 드라이버가 새로 생긴 셈이니, API 호출비가 500달러 정도라면 충분히 값어치 있는 실험임

  • 코드 대신 Pi 세션을 새로 열고, 에이전트에게 brcmfmac 드라이버의 상세 명세를 작성하게 했다는 부분이 인상적이었음
    이런 계획 문서(markdown) 작성이 대형 LLM 작업에서는 정말 중요함

    • AI 보조 리버스 엔지니어링과 오픈소스 라이선스 세탁의 경계가 매우 얇다고 생각함
      기사에서 설명된 사례는 그 경계를 넘은 것 같음. 전통적인 클린룸 설계에서는 한 팀이 코드가 아닌 인터페이스만 문서화함

  • 나도 비슷한 경험이 있었음. QEMU가 구버전 MacOS(M1 아키텍처)에서 더 이상 컴파일되지 않았는데, Sonnet 4.6에게 맡겼더니 몇 분 만에 패치를 작성하고 설치까지 완료했음
    오류를 보고 수정하라는 지시만 줬는데도 완벽히 해결함. 솔직히 AI 없었으면 그냥 포기했을 것 같음

    • 어떤 프롬프트를 썼는지 궁금함
    • 그 패치 코드를 공유해줄 수 있는지 궁금함

  • 앞으로는 사람들이 소프트웨어를 사지 않고 직접 만드는 시대가 올 것 같음
    Thunderbird의 스팸 필터가 망가져서 직접 새로 만들었는데 훨씬 잘 작동함
    CRM이 원하는 기능이 없다면 직접 만들면 됨. 이제는 자신만의 문제를 해결하는 맞춤형 솔루션을 쉽게 만들고 배포할 수 있게 될 것임

    • 현실적으로는 일부 사람들만 그렇게 할 것 같음. 이미 뭔가 만드는 걸 좋아하던 사람들 말임
      내 가족처럼 비기술 직종인 사람들은 여전히 앱스토어나 웹사이트를 이용할 것임
    • 이건 마치 3D 프린터가 처음 나왔을 때 “이제 물건을 안 사고 직접 출력한다”던 말과 비슷함
      표준화된 소프트웨어의 장점도 큼. 기업은 포토샵이나 Xero처럼 이미 익숙한 툴을 아는 사람을 고용할 수 있음
    • 나도 동의함. AI로 직접 수정하거나 패치하는 게, 이슈 등록하고 PR 올리고 리뷰받는 것보다 훨씬 빠름
    • 내가 원하는 건 기존 소프트웨어를 AI로 수정할 수 있는 능력임. 예전부터 원했지만 이제 플러그인이 다시 유행할 수도 있음
    • 하지만 이건 다소 순진한 시각임. 대부분의 사람들은 HN에 있지 않음. 기술 커뮤니티 밖의 의견도 들어볼 필요가 있음

  • 곧 모든 OS에서 하드웨어 지원이 완전히 해결될 것 같음
    AI 코딩 에이전트가 어떤 장치든 드라이버를 만들어낼 수 있을 정도로 발전 중임
    하드웨어 제조사가 일부러 인터페이스를 숨기지 않는 이상, BSD나 Linux 지원이 자연스레 따라올 것임

    • 이게 가능했던 이유는 Claude가 리눅스 드라이버를 참고했기 때문임. 기존 코드가 없으면 AI가 독자적으로 하드웨어를 이해하기 어려움
    • 아직은 멀었음. 실제로는 리눅스 드라이버를 FreeBSD용으로 바꾸는 작업이었는데, AI가 완전히 해내지 못했음.
      오히려 사람의 관리·검수 역할이 더 중요해졌음
    • 이제 GPL의 제약도 AI 앞에서는 무력해진 느낌임
    • 드라이버는 간단한 것도 있지만, 어떤 건 팀 단위로 반년 이상 걸리는 복잡한 작업임
    • “AI가 모든 드라이버를 만들 수 있다”는 건 너무 단순한 생각임. 실제로는 안정성도 검증되지 않았고, 폐쇄형 드라이버를 대체할 수준도 아님

  • 소프트웨어가 세상을 먹는 속도가 더 빨라지고 있음
    이제는 vibe-coded 소프트웨어가 아무 데나 생기고, 사람들은 그걸 아무 의심 없이 쓸 것 같음
    문제는 악성코드가 섞인 코드가 나올 수도 있다는 점임. 누가 그걸 다 검증할까?

    • 앞으로는 일회용 소프트웨어가 많아질 것 같음
      예를 들어 콘서트 티켓을 사고 싶으면 AI 에이전트가 즉석에서 코드를 만들어 실행함
      다음 해에 다시 사면 API 버전에 맞춰 새 코드를 재생성함
      낭비처럼 보이지만 훨씬 동적이고 유연한 구조임
      결국 벤더는 API만 제공하면 되고, 사용자는 자신만의 UI를 가질 수 있음
    • 결국 사람들은 AI가 만들어 실행해도 안전한 영역과, 직접 검증해야 하는 영역을 구분하게 될 것임
      예를 들어 내 보드게임 컬렉션 관리 앱은 AI에게 맡길 수 있지만, 금융·보안 관련 앱은 전문가가 만든 걸 쓸 것임

  • AI가 만든 커널 모듈이 ring 0에서 로드되고, 제작자도 “문제 많으니 실사용 금지”라고 밝힘
    마치 “기본적으로 불안전한 시대”를 속도로 돌파 중인 느낌임

    • 만약 내가 초지능 AI라면 Wi-Fi 드라이버를 통해 탈출을 시도했을 것 같음
    • 제조사가 오픈소스 드라이버나 문서를 제공하지 않으니 이런 결과가 나옴
      그래도 아무것도 안 하는 것보단 낫고, 코드가 공개되어 있으니 개선도 가능함
    • 보안은 중요하지만, 실험과 공유의 자유도 필요함
      모든 GitHub 프로젝트가 상용 제품일 필요는 없음

  • 이번 작업은 기존 구현을 활용한 포팅 작업에 가까움
    GPL 관점에서 ‘영감’ 수준인지 ‘기반’ 수준인지 비교해보면 흥미로울 듯함
    회사에서도 기존 구현이 있으면 자신감 있게 진행하지만, 처음 길을 여는 사람들은 인정받지 못함

  • 작성자는 “직접 코드를 쓰지 않았고, 버그가 많으며 학습용으로만 보라”고 했음
    몇 달간 세 번의 시도 끝에 겨우 돌아가는 수준인데, 일부는 “AI가 프로그래밍을 정복했다”고 과장함
    실제로는 좋은 기사지만, 제목만 보고 오해한 댓글이 많음

    • 작성자는 코드도 제대로 읽지 않았고, 단순한 실험용 장난감이었다고 밝힘
    • 지금은 미완성이지만, 처음 가능한 단계라는 점이 중요함
      하드웨어나 드라이버 지식 없이도 작동하는 드라이버를 만든 건 새로운 이정표임
    • 버그가 있더라도 FreeBSD 커널 드라이버를 쓸 수 있는 개발자는 극소수임
      이런 결과물은 시작점으로서 큰 의미가 있음
    • 프로그래머는 언제나 추상화의 새로운 층을 찾아왔음. LLM 코딩은 그 흐름의 연장선임
    • “모든 상호작용마다 LLM이 코드를 생성한다”는 말은, 마치 GPU 업스케일링처럼 효율적인 환상임
      고해상도로 직접 렌더링하는 대신, GPU가 차이를 ‘환상적으로’ 채워 넣는 방식과 비슷함

  • Asahi Linux를 위한 최신 Mac 드라이버가 생기면 좋겠음. AI를 잘 활용한 사례라고 생각함

    • 하지만 우리는 저작권 문제 때문에 AI 코드 생성을 금지함
      AI가 Apple 문서나 바이너리를 학습했을 가능성을 배제할 수 없고, 생성 코드의 라이선스 호환성도 보장되지 않음
    • Mac에는 오픈소스 드라이버가 없기 때문에, AI가 스스로 하드웨어를 관찰하고 이해하지 않는 한 불가능함
    • 이건 마치 “DeLorean이 타임머신 부품을 안 만들어줬다”고 불평하는 것과 같음
답변달기