NLnet Labs는 AI 오픈소스 기여와 보안 리포트 급증으로 부담이 커졌다
NLnet Labs가 최근 1년 동안 LLM이 자사 오픈소스 작업에 미친 영향을 정리한 글을 공개했다. 요지는 두 갈래다. AI가 만들어낸 코드 기여와, AI가 찾아낸 보안 리포트. 둘 다 양적으로 폭발했지만, 결과적으로 메인테이너의 검토 부담을 키우는 방향으로 작동했다는 것이 이들의 진단이다.
NLnet Labs는 DNS, BGP, RPKI 같은 인터넷 표준 구현을 25년째 만들어 온 조직이다. Unbound, NSD, Routinator, Cascade 같은 프로젝트를 C와 Rust로 개발한다. 사용자층이 좁고 언어도 특수해서, 다수의 개인 기여자가 자연스럽게 모여드는 일반적인 오픈소스 구조와는 거리가 있다. 상용 회사처럼 로드맵과 릴리스 일정을 두고 소수의 전담 팀이 유지보수를 맡는다.
그래서 지난 25년간 외부 기여는 오타나 자잘한 버그 수정 수준이 대부분이었다. 큰 PR이 들어오는 경우는 특정 조직이 자사 용도로 고친 코드를 업스트림에 반영해 달라고 요청할 때였다. 이때도 NLnet Labs는 아키텍처 정합성, 장기 유지보수성, 코딩 스타일을 놓고 기여자와 논의했다. 경우에 따라 코어 팀이 처음부터 다시 구현하거나, 공식 배포본이 아닌 contrib 폴더행으로 정리하기도 했다. Unbound의 Serve Stale 기능은 합의된 비용을 받고 내부에서 구현한 사례다.
최근 12개월 사이 풍경이 달라졌다. 최신 프런티어 모델을 앞세운 기여자들이 등장한 것이다. RFC 9432의 Catalog Zones를 Cascade에 구현하라고 에이전트에 지시하면, 커피 한 잔 마시고 돌아왔을 때 테스트와 매뉴얼 페이지까지 갖춘 4,000줄짜리 그럴듯한 코드가 나온다. RFC에 명시되지 않은 세부 설계는 논외로 치더라도, 겉보기에는 완성된 기여물이다.
문제는 그다음이다. 메인테이너는 코드를 넘겨받는 순간 수년간의 유지보수 책임도 함께 떠안는다. 그래서 설계 선택의 이유를 기여자와 함께 따져 묻는 과정이 필수인데, AI가 만든 PR에서는 "잘 모르겠다, Claude가 그렇게 만들었다"는 답이 대부분 돌아온다. 리뷰 프로세스 자체가 성립하지 않는 셈이다.
보안 쪽은 상황이 더 복잡하다. NLnet Labs가 소스를 공개하는 이유는 공동 개발보다는 검증과 취약점 발견을 가능하게 하려는 데 있다. 덕분에 대학원생부터 전문 보안 연구자까지 코드를 들여다봤고, 릴리스마다 견고해졌다. 불과 1년 전만 해도 커뮤니티는 의미 없는 AI 슬롭 리포트에 시달렸다. 무시할 수 없는 게, 그중 하나가 실제 치명적 취약점일 수 있기 때문이다.
지금은 슬롭 문제는 해결됐지만 다른 문제가 왔다. 리포트 정확도는 크게 올라갔고 재현 절차와 수정안까지 딸려 온다. 대신 한 번에 수백 건씩 쏟아진다. 팀이 리포트가 무엇을 말하는지 파악하는 데만 하루를 다 쓰는 일이 생긴다. Routinator에 들어온 LLM 리포트 제목에는 "Round-trip infidelity", "K-file storm pins validation", "Linear-scan burn via block sort" 같은 것들이 섞여 있다.
배경에는 비대칭이 있다. 코드 생성 비용은 거의 0에 가까워졌지만, 그 코드를 이해하고 유지하는 비용은 사람에게 그대로 남는다. 기여자 입장에서는 몇 분 만에 만들어 보낸 패치가, 메인테이너에게는 몇 년짜리 부담이 될 수 있다.
개발자에게 주는 실무적 시사점은 분명하다. AI로 만든 코드를 업스트림에 올릴 계획이라면 최소한 자신이 설명할 수 있는 범위로 줄이고, 설계 선택의 근거를 PR 설명에 담아야 한다. 보안 리포트를 보낼 때도 재현 절차와 영향 범위를 명확히 적는 것이 트리아지 시간을 줄이는 가장 확실한 방법이다. 메인테이너의 리뷰 용량은 유한한 자원이라는 점을 전제로 움직이는 게 좋다.
다만 이 글은 NLnet Labs라는 특수한 맥락 위에 서 있다. 사용자층이 좁고 소수 전담 팀이 장기 유지보수를 맡는 구조라서, 기여자 풀이 넓은 프로젝트에 그대로 적용되는 결론은 아니다. AI 기여를 일괄 거부하자는 주장도 아니다. 핵심은 코드의 출처가 아니라, 그 코드에 대해 책임질 사람이 있는지다.