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