최근 List-KR 이슈 #1095를 읽었다. 이 이슈에는 List-KR의 GitHub 조직과 저장소를 관리하는 fifoqueue와 AdGuard 직원이자 List-KR의 핵심 기여자였던 piquark6046 사이의 갈등이 2025년부터 2026년까지 어떻게 이어졌는지가 정리되어 있다.
이 글에서는 이슈에 공개된 이메일과 커밋 기록을 바탕으로 두 차례 갈등의 경과를 되짚고, 그 과정에서 드러난 프로젝트 거버넌스 문제를 살펴보려고 한다. 공개되지 않은 대화나 다른 당사자의 설명이 있을 수 있으므로 누구의 의도를 단정하지는 않는다.
이 글은 공개된 자료를 바탕으로 작성한 저의 개인적인 소견일 뿐이며, 새로운 분쟁을 일으키거나 특정 개인·조직을 비난하기 위한 글이 아닙니다. 또한 fifoqueue, piquark6046, AdGuard를 비롯한 어느 당사자의 공식 입장도 대변하지 않습니다.
1차 분쟁은 어떻게 시작됐을까?
2026년 8월의 재충돌을 이해하려면 2025년 9월의 1차 분쟁부터 살펴볼 필요가 있다. 당시 fifoqueue는 애니플러스가 접속자의 지역을 확인할 때 사용하는 요청을 차단하는 규칙을 List-KR에 추가했다. piquark6046는 해당 규칙의 효과를 물은 뒤, 광고나 안티 애드블록 외의 방해 요소까지 List-KR에서 처리하는 것이 기존 범위에 맞는지를 문제 삼았다.
논쟁은 곧 AdGuard의 필터 정책을 List-KR에 어디까지 적용할 것인지로 번졌다. piquark6046는 비슷한 규칙을 언어별 광고 필터가 아니라 AdGuard의 팝업 필터에서 처리하라는 AdGuard CTO의 권고를 전했다. fifoqueue는 List-KR이 AdGuard뿐 아니라 uBlock Origin에도 제공되는 독립 프로젝트이며, 그 권고를 따를 의무는 없다고 반박했다. 이 과정에서 List-KR을 AdGuard의 관리 아래 둘 의사가 없다는 입장도 밝혔다.
같은 날 piquark6046가 유저스크립트 등을 담은 일부 저장소를 List-KR 조직에서 별도의 FilteringDev 조직으로 옮기면서 갈등은 권한 문제로 확대됐다. piquark6046는 자신이 List-KR 조직에서 제거되더라도 이용자가 유저스크립트 업데이트를 계속 받을 수 있게 하려는 조치였다고 설명했다. 반면 fifoqueue는 사전 통보 없는 저장소 이전을 권한 남용으로 판단해 piquark6046의 접근 권한을 제거하고 이슈 #1005를 공개했다.
두 사람은 이후 이메일로 대화를 이어갔고, 이슈 #1005는 당사자 간 협의로 문제가 해결됐다는 설명과 함께 닫혔다. piquark6046의 List-KR 접근 권한도 복구됐으며, 옮겨진 유저스크립트 저장소는 FilteringDev에서 계속 관리하기로 했다.
따라서 1차 분쟁의 결론은 결별이 아니라 협업을 이어가기 위한 합의였다. 다만 2026년 8월, 변경 권한과 사전 협의를 둘러싼 갈등이 다시 드러났다.
2차 분쟁은 무엇으로 시작됐을까?
직접적인 계기는 2026년 8월 13일 fifoqueue가 연달아 올린 두 커밋이었다. 오전 10시 38분에는 나무위키의 파워링크를 제거하는 EXPERIMENTAL: namu.wiki 규칙을 추가했고, 12분 뒤에는 카카오뱅크 관련 도메인 규칙 하나를 제거했다.
piquark6046는 나무위키의 DOM 구조가 바뀌면 해당 규칙이 정상 콘텐츠까지 가릴 수 있고, 이미 NamuLink가 같은 문제를 처리하고 있다는 점을 들어 이의를 제기했다. fifoqueue는 여러 환경에서 규칙을 테스트했고 NamuLink는 별도 프로젝트이므로, 같은 기능이 있다는 이유만으로 List-KR에서 해당 규칙을 제외할 필요는 없다고 답했다. 카카오뱅크 규칙에 대해서는 fifoqueue가 해당 도메인이 광고용이 아니라는 제보와 규칙을 삭제해도 광고가 나타나지 않는다는 테스트 결과를 근거로 제거했고, piquark6046는 필터 정책과 변경 절차에 문제가 있다고 보았다.
논의는 곧 개별 규칙의 정확성보다 누가 변경을 결정하고 누구와 미리 협의해야 하는가에 관한 문제로 번졌다. 공개된 이메일에 따르면 piquark6046는 같은 날 오후 7시 3분경 List-KR 기여를 중단하고, AdGuard Filters Registry에 등록된 한국어 필터의 기반을 별도 포크 저장소로 옮기겠다고 fifoqueue에게 알렸다. 이후 fifoqueue는 이슈 #1095를 공개했고, piquark6046도 커뮤니티에 포크 이전을 공지했다.
기여량과 소유권은 같은 것일까?
piquark6046가 List-KR에 많은 기여를 했고 오랫동안 실질적인 유지보수를 맡았다는 점은 분명해 보인다. 프로젝트를 유지하는 데 들인 시간과 노력은 충분히 인정받아야 한다.
다만 이 글에서 말하는 ‘소유권’은 코드 전체의 저작권을 한 사람이 가진다는 뜻이 아니다. GitHub 조직과 저장소, 프로젝트 이름, 공식 배포 경로를 누가 관리하고 대외적으로 대표하는지에 관한 운영상의 지위를 가리킨다.
오픈소스 프로젝트에서는 처음 프로젝트를 관리하던 사람보다 다른 기여자가 더 많은 코드를 작성할 수 있다. 협업 과정에서 저장소 관리 권한을 받거나 GitHub 조직의 Owner가 되는 일도 자연스럽다. 그러나 관리 권한을 받았다는 사실만으로 프로젝트의 이름과 공식 배포 경로까지 자동으로 그 기여자에게 넘어가지는 않는다.
기여는 프로젝트 안에서 공로와 영향력을 만든다. 하지만 운영상의 소유권이나 대표권을 이전하려면 당사자 사이의 명시적인 합의가 필요하다. 이 둘을 같은 것으로 취급하면 기여자의 공로와 프로젝트를 공식적으로 대표할 권한의 경계가 흐려진다.
회사 직원의 기여와 회사의 소유는 다르다
AdGuard와 List-KR의 관계는 두 차례 분쟁에서 서로 다른 방식으로 등장했다. 2025년 1차 분쟁에서는 AdGuard의 필터 정책을 List-KR에 어디까지 적용할지가 쟁점이었고, 2026년 재충돌은 AdGuard에서 사용하는 한국어 필터의 기반을 포크 저장소로 옮기겠다는 결정으로 이어졌다.
하지만 AdGuard 직원인 piquark6046가 List-KR에 기여했다는 사실과 AdGuard가 List-KR을 소유하거나 대표한다는 것은 별개의 문제다. 직원 개인이 업무의 일부로 오픈소스 프로젝트에 기여할 수는 있지만, 그 기여만으로 기존 프로젝트의 운영권과 대표성이 회사에 이전되지는 않는다.
fifoqueue는 대표성 문제가 두 차례 분쟁 전부터 쌓여 왔다고 주장한다. 2022년 11월 README에는 List-KR이 애드블록 커뮤니티와 AdGuard에 의해 유지보수된다는 문구가 추가됐다. 2023년에는 community.list-kr.com이 커뮤니티 주소로 연결됐고, 이후 npm에는 프로젝트 이름을 딴 @list-kr 조직이 만들어져 필터 배포에 사용됐다. fifoqueue는 이슈 #1095에서 이러한 변경을 사전에 충분히 통보받지 못했다고 밝혔다.
community.list-kr.com과 @list-kr는 이용자에게 List-KR의 공식 채널로 보이기 쉽다. 이슈 #1095가 공개될 당시 fifoqueue는 두 인프라에 대한 권한이 없다고 설명했다. 다만 이슈가 공개된 뒤에는 piquark6046가 npm @list-kr 조직의 Owner 권한을 fifoqueue에게 넘겼다. 따라서 과거에 제기된 권한 문제와 현재의 관리 상태는 구분해서 볼 필요가 있다.
별도 인프라를 만든 행위 자체가 문제라는 뜻은 아니다. 다만 프로젝트의 공식 채널로 인식될 수 있는 도메인과 패키지 배포 경로를 누구와 합의하고 누가 관리할지는 거버넌스의 문제다. 핵심은 직원 개인의 기여를 회사의 소유로 간주할 수 있는지가 아니라, 어느 채널과 배포물을 공식 List-KR로 볼지 당사자 사이에 충분한 합의가 있었는지에 있다.
포크의 자유와 원 프로젝트의 정체성
List-KR은 GPLv3 라이선스로 배포되므로 코드를 복제하고 수정해 별도 프로젝트로 배포할 수 있다. 원 프로젝트의 동의를 받아야만 포크할 수 있는 것은 아니며, 이는 오픈소스 라이선스가 보장하는 핵심적인 자유다.
하지만 코드를 포크할 권리와 원 프로젝트의 이름이나 공식적인 지위를 그대로 이어받을 권리는 같은 개념이 아니다.
포크가 원본의 코드를 사용할 수 있다고 해도 원본과 같은 프로젝트로 받아들여지면 이용자는 둘을 구분하기 어렵다. 특히 기존 프로젝트와 같은 이름이나 도메인, 조직 명의, 주요 배포 경로를 사용한다면 어느 쪽이 원본이고 어느 쪽이 포크인지 명확히 알릴 필요가 있다.
따라서 2026년 포크 논란의 핵심은 포크 자체의 허용 여부보다 List-KR이라는 이름과 공식성을 누가 결정할 수 있었는가에 있다고 본다. 코드는 라이선스에 따라 공유되지만, 프로젝트의 정체성과 대표성은 별도의 합의가 필요한 거버넌스 문제다.
실질적인 유지보수자의 입장도 생각해볼 필요가 있다
piquark6046의 입장에서 이해할 수 있는 부분도 있다. fifoqueue가 저장소를 적극적으로 관리하지 않았던 기간 동안 piquark6046가 실질적인 유지보수를 맡아 왔으므로, 프로젝트의 운영 방향에 강한 책임감을 느꼈을 수 있다. 많은 문제를 처리하고 배포 경로까지 관리해 왔다면 의사 결정에 충분히 참여해야 한다고 생각했을 가능성도 있다.
이러한 공로는 운영 방향에 더 큰 발언권을 요구할 근거가 될 수 있다. 그러나 그 사실만으로 프로젝트의 공식 대표를 정하거나 프로젝트를 특정 회사의 소유로 규정할 권한까지 자동으로 생기지는 않는다.
장기간의 유지보수로 운영 구조가 사실상 달라졌다면 필요한 것은 암묵적인 소유권 이전이 아니라 역할과 권한을 명문화하는 합의였다. 저장소, 도메인, 패키지와 배포 경로를 누가 관리할지 미리 정했다면 두 사람이 서로 다른 전제를 가진 채 같은 프로젝트를 운영하는 상황을 줄일 수 있었을 것이다.
일부 이용자는 왜 포크를 받아들였을까?
일부 이용자에게 이 갈등은 소유권보다 기여의 문제에 가까웠다. 누가 GitHub 조직과 저장소를 관리하는지보다 누가 오랫동안 필터를 유지하고 문제를 해결해 왔는지가 더 중요하다는 것이다. fifoqueue의 활동은 눈에 잘 띄지 않았던 반면, piquark6046는 커뮤니티 운영자이자 이용자가 직접 접할 수 있는 유지보수자였다. 이런 경험의 차이가 두 사람에 대한 평가에도 영향을 주었을 것이다.
piquark6046의 AdGuard 입사도 이용자들에게 반드시 부정적인 요소는 아니었을 것이다. 오랫동안 이어 온 기여를 회사가 인정한 결과로 보는 이용자도 있었고, AdGuard가 사용하는 한국어 필터를 해당 직원이 계속 관리하는 일을 자연스럽게 여기는 이용자도 있었을 것이다. 이들에게 포크는 원 프로젝트를 빼앗는 행위라기보다 기존 저장소에서 이어가기 어려워진 유지보수를 계속하기 위한 선택으로 보일 수 있다.
이런 관점에서 보면 일부 이용자가 piquark6046의 선택에 우호적이었던 이유도 이해할 수 있다. 그러나 기여자가 쌓은 운영상의 신뢰와 fifoqueue가 가진 GitHub 조직·저장소의 관리 권한은 같은 것이 아니다. 이 신뢰와 관리 권한의 관계를 미리 합의하지 못한 점이 이번 갈등을 키운 원인에 가깝다.
공개된 기록을 어떻게 봐야 할까?
이슈 #1095는 한쪽 당사자가 작성한 설명이지만, 관련 커밋과 README 변경 내역, 이메일, 인프라와 배포 경로의 변화처럼 독자가 직접 확인할 수 있는 기록도 함께 제시한다. 따라서 이 이슈를 단순히 한쪽의 감정적인 주장으로만 치부하기는 어렵다.
작성자는 자신에게 불리할 수 있는 내용도 인정한다. 프로젝트를 적극적으로 관리하지 않았던 시기가 있었고, piquark6046가 실질적인 유지보수의 상당 부분을 맡았으며, 이메일에서 자신이 공격적인 표현을 사용했다고 직접 밝혔다.
이 기록들은 fifoqueue가 왜 상황을 부당하다고 받아들였는지를 이해하는 데 도움이 된다. 다만 공개된 사실이 그의 평가와 결론까지 모두 입증하는 것은 아니다.
자료의 선택과 설명은 대부분 fifoqueue가 정리한 것이고, piquark6046나 AdGuard가 공개하지 않은 맥락도 있을 수 있다. 따라서 확인되지 않은 동기를 단정하거나 공개 기록만으로 특정 개인과 조직의 잘못을 확정해서는 안 된다.
오픈소스에서 우리는 무엇을 소유하는가?
List-KR의 두 차례 분쟁을 보며 다시 느낀 것은 오픈소스에서 다음 세 가지를 구분해야 한다는 점이다.
- 코드를 사용할 권리: 라이선스가 정한 범위에서 복제하고 수정하고 배포할 수 있는 권리
- 프로젝트를 운영할 권한: 저장소 병합, 릴리스, 정책 결정 등에 참여할 수 있는 권한
- 프로젝트의 소유권과 대표성: 저장소와 이름, 공식 채널을 최종적으로 관리하고 대외적으로 대표하는 지위
많은 기여를 한 사람의 공로는 존중받아야 한다. 실질적인 유지보수자에게 충분한 권한과 의사 결정 참여가 보장되는 것도 중요하다. 그러나 그 공로와 프로젝트를 공식적으로 대표할 권한은 같은 것이 아니다.
운영 방향이 맞지 않을 때는 라이선스가 허용하는 범위에서 포크할 수 있다. 이때 원본과 포크의 이름과 공식 채널을 명확히 구분하는 편이 이용자와 양쪽 프로젝트 모두에게 더 건강하다.
두 차례 분쟁을 되짚고 나면 한 가지 질문이 남는다. 코드를 포크할 수 있었는데도 왜 List-KR의 이름과 공식성을 둘러싼 갈등까지 이어졌을까.
이는 List-KR만의 문제는 아닐 것이다. GitHub 조직과 저장소를 관리해 온 사람과 실질적인 유지보수를 가장 많이 맡은 사람이 다르고, 핵심 기여자가 기업의 직원으로 프로젝트에 참여하면 역할과 대표성의 경계는 쉽게 흐려질 수 있다.
코드는 열려 있어도 프로젝트의 거버넌스가 저절로 정해지는 것은 아니다. 그래서 권한과 대표성에 대한 합의는 기여가 커질수록 더 일찍, 더 명확하게 이루어져야 한다.