Lobsters

Maintaining the love for coding in the time of AI

AI 시대, 코딩에 대한 애정을 지키기 — NLnet Labs가 LLM 정책을 도입한 이유

DNS·BGP·RPKI 같은 인터넷 핵심 인프라용 오픈소스(Unbound, Routinator 등)를 개발하는 NLnet Labs가 AI 시대의 변화를 진단합니다. AI로 작성된 대규모 기여 코드와, LLM으로 발견된 수백 건의 보고서가 쏟아지면서 12명의 개발팀이 트리아지에 매몰되었고, 결국 모든 코드와 문서 기여를 사람이 작성해야 한다는 LLM 정책을 발표하게 된 배경을 설명합니다.

본문

네덜란드의 NLnet Labs는 Unbound, NSD, Routinator 같은 DNS·BGP·RPKI 소프트웨어를 25년간 개발해 온 비영리 재단입니다. 이 글은 지난 1년간 프론티어 AI 모델의 등장이 이들의 오픈소스 작업에 미친 두 가지 변화 — 커뮤니티 기여와 보안 보고 — 를 다루며, 왜 사람이 작성한 기여만 받는 LLM 정책을 도입할 수밖에 없었는지를 설명합니다.

틈새 중의 틈새, 그래서 더 엄격한 리뷰 문화

NLnet Labs가 만드는 소프트웨어는 인터넷 표준을 다루는 데다 C와 Rust로 작성되어, 저자는 '틈새 중의 틈새'라고 부릅니다. 일반적인 오픈소스의 커뮤니티 협업 모델과 달리 로드맵과 정기 릴리스를 가진 소규모 전담 팀이 상용 회사처럼 운영하며, 외부 기여는 25년간 오타·버그 수정 수준에 그쳤습니다. 가끔 들어온 대규모 PR도 자체 패치를 새 버전마다 재적용하기 싫은 조직이 업스트림에 병합하려는 경우가 대부분이었습니다. 팀은 아키텍처·장기 유지보수성·코딩 스타일을 내부에서도 줄 단위로 여러 차례 리뷰하며, 덕분에 Unbound는 20년 가까이 전면 재작성 없이 진화할 수 있었습니다. 외부 기여가 맞지 않으면 코어 팀이 유료로 처음부터 다시 구현하거나(Serve Stale 사례) /contrib 폴더로 보내는 선택지도 있었습니다.

AI 시대의 기여: '공짜 강아지' 문제

최근 12개월 사이 AI 에이전트에게 'RFC 9432의 Catalog Zones을 Cascade에 구현하라. 테스트가 모두 통과할 때까지 멈추지 마라'고 지시하면, 커피 한 잔 마시고 돌아오는 사이 그럴듯해 보이는 4,000줄의 코드가 나옵니다. 기여자 입장에서는 'free as in beer'이자 'free as in speech'로 느껴지겠지만, 수용하는 쪽에는 '공짜 강아지'와 같아서 앞으로 수년간 큰 책임이 따릅니다. RFC에 명시되지 않은 세부 설계 결정은 AI가 임의로 내렸을 것이고, 이를 검토·유지보수하는 비용은 고스란히 팀의 몫입니다.

보안 연구의 '눈사태'

NLnet Labs가 오픈소스를 하는 이유는 커뮤니티 공동 프로젝트가 아니라 투명성과 검증 가능성 때문이며, 그 덕에 연구자들의 취약점 사냥터가 되어 릴리스마다 더 견고해졌습니다. 불과 1년 전만 해도 엉터리 'AI 슬롭' 버그 보고가 한 달에 몇 건 오는 수준이었지만, 진짜 취약점일 가능성 때문에 무시할 수 없었습니다. 지금은 정반대입니다. 보고서는 재현 절차와 수정 제안까지 갖춰 매우 정확해졌지만, 한 번에 수백 건씩 쏟아집니다. 문제는 재현 절차가 있어도 이슈 설명이 여전히 모호하다는 점입니다. Routinator에 들어온 최신 보고서에는 'Round-trip infidelity', 'K-file storm pins validation', 'Linear-scan burn via block sort position' 같은 제목이 붙어 있고, 팀이 실제 문제를 파악하는 데 하루를 통째로 쓰기도 합니다. 올해 초 이후 신기능이 없었던 이유가 바로 이것이며, 새 AI 모델이 나올 때마다 눈사태가 반복되고 일부는 다른 벤더와 공조해 릴리스를 조율해야 했습니다.

선택의 기로와 LLM 정책

재단은 결국 모든 코드와 문서 기여를 사람이 작성해야 한다는 LLM 정책을 발표했고, LLM으로 발견된 취약점 보고는 계속 받습니다. 숙련된 C·Rust 개발자가 AI 도움을 받아 코드 전체에 책임질 수도 있지만, 실제 경험은 그렇지 않았으며 윤리·지식재산권 고려도 결정에 작용했습니다. 더 근본적인 문제는 규모입니다. 직원 15명 중 개발자 12명인 재단은 인력을 늘릴 재정이 없고, LLM으로 트리아지하면 'LLM이 만든 보고서를 LLM이 트리아지·수정·릴리스'하는 구조가 되어 재단의 신념과 정면충돌합니다. 저자는 개발자를 움직이는 원동력이 '복잡한 문제를 우아하게 푸는 즐거움'인데 몇 달째 트리아지만 하느라 일의 재미가 사라졌다고 토로하며, 메모리 안전 언어 논쟁처럼 'LLM 테스트 없이 배포하는 것이 무책임하다'는 주장이 곧 나올 것을 예상하면서도, 무료 오픈소스용 LLM 테스트 CI/CD 도구를 주시하겠다고 마무리합니다.

Lobsters 반응

  • @reidrac — 'LLM은 그저 도구일 뿐'이라는 주장은 사용 책임을 전부 개발자에게 돌리는데, 인용된 문장은 결국 대부분의 사람들이 언어 경험이나 도메인 지식 부족으로 도구를 잘못 쓴다는 뜻이라고 지적합니다. 자신은 생성형 AI 사용자는 아니지만, 그것이 곧 '숙련자가 아니면 책임 있는 기여가 불가능하다'는 결론으로 이어진다고 봅니다.

원문: NLnet Labs Blog / 번역·요약: Trawling