성격 충돌, 부재한 창립자, 그리고 논란이 된 리디자인이 어떻게 Python의 가장 인기 있는 프로젝트 중 하나를 분열시켰는지 살펴봅니다.
링크가 복사되었습니다!
성격 충돌, 부재한 창립자, 그리고 논란이 된 리디자인이 어떻게 Python의 가장 인기 있는 프로젝트 중 하나를 분열시켰는지.
Florian Maas 작성·2026년 3월 22일·15분 읽기
2026년 3월 9일, MkDocs의 전 유지관리자 중 한 명이 PyPI 저장소의 통제권을 가져가고 원 저자의 권한을 제거했습니다. 원 저자는 곧바로 다음과 같이 응답했습니다:
도대체 뭐야? 내가 저자이자 라이선스 보유자인데.
이제 PyPI 변경 사항을 되돌리고 꺼져.
이후 그들은 PyPI 지원 티켓을 제출해 PyPI 저장소의 통제권을 되찾았습니다.
MkDocs는 GitHub 프로젝트 9만 개가 넘는 문서를 구동하고 있으며, 그 대부분은 @squidfunk가 만든 테마인 Material for MkDocs에 의존합니다. 이 테마는 MkDocs 자체보다 더 많은 스타를 받을 정도로 인기가 높습니다.
하지만 PyPI 장악은 더 깊은 문제의 가장 눈에 띄는 증상일 뿐이었습니다. 오늘날 Material for MkDocs를 사용하는 사람이라면 누구나 터미널에서 다음 경고를 보게 됩니다:
│ ⚠ WARNING – MkDocs 2.0 is incompatible with Material for MkDocs
│
│ MkDocs 2.0 introduces backward-incompatible changes:
│
│ [...]
MkDocs는 18개월이 넘도록 사실상 아무런 실질적 개발이 없었습니다. Material for MkDocs는 유지보수 모드에 들어갔습니다. 그리고 한때 함께 작동하던 두 개의 지배적인 도구가 있던 자리에, 이제는 그것들을 대체하려 경쟁하는 여러 도구가 있습니다: ProperDocs, MaterialX (“mkdocs-material의 차세대”), 그리고 Zensical (“Material for MkDocs의 제작자들이 만든 현대적인 정적 사이트 생성기”).
어떻게 여기까지 오게 되었을까요? 전체 이야기를 이해하려면 시간을 조금 거슬러 올라가야 합니다…
2014년 1월 11일
MkDocs의 탄생
2014년 1월 11일, Mia Kimberly Christie (@lovelydinosaur)가 이후 MkDocs가 될 프로젝트에 첫 커밋을 푸시합니다. 메시지는 “Hell yeah”였습니다. 이어서 다음 몇 달 동안 커밋이 빗발칩니다.
이 활동의 폭발은 그리 오래가지 않습니다. 2014년 중반이 되자 저장소에서의 그들의 활동은 완전히 멈춥니다.
@d0ugal, @waylan 같은 다른 이들이 프로젝트에 합류합니다. @lovelydinosaur는 비활성 상태로 남고, 2016년 7월부터 2021년 7월 사이에는 @waylan이 프로젝트의 사실상 유일한 유지관리자였던 것으로 보입니다.
프로젝트는 점점 더 인기를 끌게 되었고, 2022년 중반에는 GitHub에서 훨씬 14,000개가 넘는 스타를 모았습니다.
2020년 4월 27일
oprypin이 프로젝트에 합류
2020년 4월 27일, 새로운 기여자 @oprypin이 프로젝트에 대한 첫 기여를 합니다. 제안된 버그 수정이었습니다. @waylan은 변경 사항에 동의했고
이건 간과한 부분이었던 것 같습니다. 제보와 작업에 감사드립니다.
PR을 머지했습니다. 첫 기여 이후 @oprypin은 약 반년 동안 프로젝트에 관여하지 않았지만, 그 이후에는 오랜 기간 빈번한 활동이 이어졌습니다. 버그 수정, 기능 추가, 없는 게 없었습니다.
@oprypin과 @waylan 사이에는 꽤 많은 마찰이 있었던 것으로 보입니다. 예를 들어, 이곳에서는 @oprypin이 자신의 Pull Request에 적용한 변경 사항에 대해 응답을 받지 못했을 때 다음과 같이 말합니다:
당신이 요청한 모든 것과 가능한 모든 것을 다 했습니다. 제발 이 문제를 함께 풀어주세요. 왜 이것을 일축하는지 전혀 모르겠습니다.
혹은 @waylan이 @oprypin이 제안한 잠재적인 성능 개선안에 동의하지 않는 사례도 있습니다:
This pull request now 100% exactly matches the implementation at master.
그 말은, 이득도 없이 유지보수 부담만 더한다는 뜻입니다.
This change, now compared to master, still cuts off 9% of build times for a site with 142 pages.
글쎄요. 우선순위가 아닙니다. 그 정도 이득은 추가 부담을 감수할 가치가 없습니다.
내가 왜 이런 대우를 받아야 하는지 모르겠습니다 — 당신은 내가 하는 말을 전부 그냥 흘려버리네요. 사실로 완벽하게 뒷받침된 내 말조차도 당신의 의견, 심지어 감정만으로 즉시 무시됩니다.
2021년 5월 16일
waylan이 물러나다
@oprypin의 좌절은 점점 커졌고, 결국 “MkDocs 유지관리 체계에 대한 우려” 라는 제목의 토론 스레드를 열기에 이릅니다. 이 긴 글에서 그는 @waylan이 프로젝트를 게이트키핑하고 있으며 기술적 정당성 없이 기여를 일축한다고 비난했고, 단일 유지관리자에게 책임이 덜 집중되는 대안적 유지관리 모델을 제안했습니다.
[…] MkDocs라는 프로젝트가 그 유지관리자의 주된 활동이 모든 요청에 “당신은 MkDocs가 이걸 하게 되기를 바라선 안 된다”라고 응답하는 것처럼 보이는 탓에 순전히 정체되어 있다는 좌절감 때문에 여기 왔습니다. […]
그는 저장소 자신의 포크에 그 스레드의 사본도 게시합니다. 두 스레드 모두에서 활동은 많지 않았지만, 사실과 의견을 구분하기는 어렵더라도 이 글이 불필요하게 개인적이라는 데 대체로 의견이 모였습니다. 이는 프로젝트의 원저자이자 대부분 비활성 상태였던 작성자도 언급한 바입니다:
그러니까, 이건 좀 불필요하게 개인적인 것 같네요. 단순히 MkDocs 아래에서 프로젝트를 앞으로 밀어줄 새로운 유지관리 체계를 보고 싶다고 토론을 제기했으면 충분했을 겁니다. 어쨌든요.
@oprypin이 토론을 만든 바로 그날, @waylan은 프로젝트에서 떠나겠다고 발표합니다:
내가 한 모든 일은 [..] 다른 사람들을 위해 그것을 더 좋게 만들기 위한 것이었습니다. […] 1.2가 출시되면 이 프로젝트에 대한 기여를 중단할 것입니다. 앞으로 개인적인 상황이 바뀌면 돌아올 수도 있겠지만, 현재로서는 그럴 가능성이 높아 보이지 않습니다.
2021년 6월 7일
oprypin이 넘겨받다
이제 @waylan이 더 이상 프로젝트의 유지관리자가 아니었기 때문에, 새로운 유지관리자가 필요했습니다. @lovelydinosaur는 유지관리 상황에 대한 제안을 요청하는 토론을 엽니다. @oprypin은 프로젝트 유지관리를 맡을 의향이 있다고 밝히며 곧바로 뛰어듭니다.
저는 이미 4월 7일에 @waylan에게 MkDocs 유지관리를 넘겨받겠다고 제안했었습니다. 여기서 다시 제안합니다.
@lovelydinosaur는 즉시 그 제안을 받아들이지는 않았지만, @oprypin은 프로젝트 개발을 계속하고 싶어 했고, 그래서 몇 주 뒤 다시 스레드로 돌아옵니다:
다시 한 번… 제발 제가 MkDocs에서 일하게 해주시겠어요? 실제로 아무 일도 일어나지 않고 있고 사람들은 수정 사항만 기다리고 있습니다.
한동안 @lovelydinosaur가 @oprypin에게 프로젝트 쓰기 권한을 주는 데 다소 주저하는 듯 보였고 응답도 느린 편이었는데, Material for MkDocs의 원저자이자 유지관리자인 @squidfunk가 끼어듭니다:
PR이 쌓이고 있고 1.2.1에도 우리가 고쳐야 할 몇 가지 문제가 있습니다. @oprypin에게 쓰기 권한을 줘서 MkDocs를 앞으로 나아가게 하는 데 저는 전적으로 찬성합니다.
그 후 @lovelydinosaur는 MkDocs에 유지관리자 그룹을 초대합니다:
@oprypin @squidfunk @ultrabug 모두에게 팀 초대를 보냈습니다.
약 1년 뒤, @oprypin은 GitHub 저장소와 PyPI 프로젝트에서 더 높은 권한을 요청합니다:
MkDocs 조직의 “Owner” 권한을 받을 수 있을까요? […] 추가로, 그리고 어쩌면 더 중요하게는, 저는 아마 PyPI 프로젝트에도 추가되어야 할 것 같습니다.
Owner 권한을 얻은 후, @oprypin은 MkDocs의 주된 유지관리자가 됩니다. 이후 2년 동안 그는 다른 유지관리자 및 기여자들과 함께 꾸준히 프로젝트를 작업합니다. 버그 수정, 의존성 업데이트, 몇 가지 새 기능까지, 프로젝트는 계속 움직였습니다.
2024년 2월 25일
긴장이 공개적으로 드러나다
일상적인 문서 이슈가 @squidfunk가 그 스레드를 이용해 Read the Docs가 MkDocs로 수익을 내면서도 프로젝트에 환원하지 않는다고 지적하면서 다른 무언가로 바뀝니다. @oprypin은 이 순간을 놓치지 않습니다:
@squidfunk가 자기 방식 그대로를 맛보는 날이네, 이런 날도 있군 😂
[…]
그리고 이 얘기를 하고 싶다면, 예전에 당신이 저를 차단했던 Element/Gitter 채팅에서 개인적으로 연락해도 됩니다 😂
@squidfunk의 응답은 이렇습니다:
여기서 이 판도라의 상자를 여는 게 현명한지 잘 모르겠습니다. 네, 제가 Gitter에서 당신을 차단했습니다. 그리고 당신은 정확히 그 이유를 알고 있습니다.
그 뒤로 이어진 것은 그들의 과거사를 길게 공개적으로 풀어놓는 일이었습니다. @oprypin은 자신이 아무 잘못도 하지 않았다고 주장했고, @squidfunk는 한때 자신이 @oprypin의 첫 후원자였고, 둘 사이의 차이에도 불구하고 그가 MkDocs 팀에 합류하도록 보증했으며, 반복되는 개인적 갈등 끝에 결국 소통을 공개 채널로 제한하기로 했던 경위를 회고했습니다.
문서의 작은 수정이 적용되자 이 이슈는 완료로 표시됩니다.
2024년 3월 16일
oprypin이 squidfunk를 조직에서 제거하다
이제 @lovelydinosaur가 @oprypin, @squidfunk, @ultrabug를 프로젝트 유지관리자로 추가했다고 발표했던 그 스레드로 다시 돌아갑니다.
3월 16일, @squidfunk는 다음과 같이 게시합니다:
오늘 MkDocs 조직에서 제거되었다는 이메일을 받았습니다. […] 이 조치 전에 어떤 유지관리자로부터도 연락을 받지 못했습니다. 왜 이런 일이 있었는지 설명해주실 분이 있을까요? […]
알고 보니 @oprypin이 독단적으로 그 결정을 내린 것이었습니다:
안녕하세요. 제가 당신을 GitHub 조직에서 제거했습니다. 당신이 MkDocs를 대표하는 것처럼 보이는 것이 저는 불편합니다. […]
이는 커뮤니티 구성원들로부터 좋지 않게 받아들여졌고, 이후 @lovelydinosaur가 대화에 참여해 @squidfunk의 MkDocs 조직 멤버십을 복구합니다. 추가로, @oprypin의 저장소 소유자 권한도 제거합니다.
2024년 4월 6일
oprypin이 물러나다
4월 6일, @lovelydinosaur는 다음과 같이 씁니다:
좋아요, 여기에는 전반적으로 몇 가지 소통 문제가 있는 것 같군요. 현재로서는 기존 팀원이 “ownership” 권한을 필요로 해서 막혀 있는 이슈가 있다고 보이지 않으니, 당분간은 제가 소유권 열쇠를 쥐고 있겠습니다. […]
세 시간 뒤, @oprypin은 MkDocs에서 물러난다고 발표합니다. 그의 글에서 그는 @squidfunk와의 의견 충돌, @lovelydinosaur의 개입에 대한 좌절, 그리고 프로젝트를 유지관리하는 외로움을 자세히 설명합니다:
MkDocs를 유지관리하는 일은 정말 외로웠습니다. 물론 대부분은 제 잘못이긴 하지만, 그래도요.
[…]
그러다 갑자기, 7년 동안 MkDocs에 정확히 아무것도 하지 않던 [@lovelydinosaur]가 아무런 맥락도 없이 끼어들어 “소통 문제”가 있다고 선언하고 (네, 맞아요…), 저를 관리자에서 내리고, @squidfunk를 다시 추가했고, 그 결과 저는 제 지위를 협상해야 하는 처지가 되었습니다.
[…]
저는 몇 주째 문자 그대로 잠을 설쳐 왔지만, 결국 거기에 대해 제가 할 말도 없고 얻을 것도 없다고 생각합니다.
그는 2024년 4월 20일 1.6.0 릴리스를 팀이 내는 것을 돕기로 합니다. 그리고 같은 해 8월 30일의 1.6.1 릴리스를 제외하면, 이것이 집필 시점까지도 마지막 릴리스입니다.
2024년 4월 8일
커뮤니티가 잠시 결집하다
@oprypin이 물러난 지 이틀 뒤, 활발한 커뮤니티 구성원이자 mkdocstrings의 작성자인 @pawamoy가 “MkDocs를 다음 단계로 끌어올리기” 라는 야심찬 제목의 스레드에서 약 25명의 플러그인 및 테마 작성자들을 초대해 MkDocs 유지관리를 함께 돕자고 제안합니다. 반응은 따뜻했습니다. @squidfunk는 자신이 “이 일이 일어나는 걸 보게 되어 정말 신난다” 고 썼습니다. 그는 또 이렇게 덧붙였습니다:
저는 Material for MkDocs를 더 많은 사람들의 어깨에 올리고 싶고, 그걸 해내기 위해 최근에 재정적으로 보상하는 팀을 꾸리기 시작했습니다.
4월 23일, @oprypin의 마지막 릴리스 며칠 뒤, @lovelydinosaur는 자신이 수석 유지관리자로 돌아올 것이라고 게시합니다. 이 시점에는 그들의 마지막 Pull Request가 저장소에 머지된 지 꼬박 8년이 지난 상태였습니다. 그들이 밝힌 목표는 다음과 같았습니다: MkDocs는 “Material for MkDocs와 구별되는 강하고 독립적인 리더십” 을 가져야 한다. 그들은 28명의 커뮤니티 구성원을 태그하고 토요일 통화 일정을 잡습니다.
통화는 실제로 열렸습니다. @squidfunk는 참여를 거절했습니다. 두 사람이 나타났습니다. 그리고 그 뒤 18개월 동안 그 스레드에서 보이는 활동은 그것이 마지막이었습니다.
2024년 5월 17일
lovelydinosaur의 복귀
@lovelydinosaur는 수년 만에 처음으로 프로젝트에 활발히 기여하는 상태로 돌아옵니다.
이 시기에는 @squidfunk가 유일하게 다른 활발한 유지관리자로 보입니다. @lovelydinosaur는 MkDocs에 몇 가지 기여를 하는 한편, mkdocs/sketch 저장소에서 MkDocs의 리디자인 작업도 시작합니다.
2024년 8월 1일
플러그인 없는 리디자인
@lovelydinosaur는 자신이 제안한 MkDocs 리디자인의 데모를 MkDocs 핵심 팀과 공유합니다. 현재 MkDocs는 사이트 전체를 한 번에 빌드하지만, 제안된 리디자인은 요청이 들어올 때 페이지를 즉석에서 빌드합니다. 유지관리자들과 핵심 기여자들 사이에서는 우려가 제기됩니다:
API에 닥쳐올 변경을 고려할 때 플러그인의 유지보수와 마이그레이션 노력에 대한 우려가 제기되었습니다. [Mia]는 먼저 새로운 코어를 개발하고 안전한 렌더링을 허용하는 버전을 구축할 필요성을 강조했습니다. 그 후 API의 정의와 마이그레이션 경로가 뒤따를 것입니다.
별개의 다른 스레드에서, @lovelydinosaur는 자신이 아예 플러그인을 필요로 하지도 지원하지도 않는 MkDocs의 리디자인을 지향하고 있다고 공유합니다:
그러니까… 직관에 반할 수도 있지만, 이것이 바로 제가 페이지 생성 커스터마이징을 위해 플러그인을 필요로 하지도 지원하지도 않는 MkDocs의 미래 버전을 바라보는 이유를 보여주는 아주 좋은 예입니다.
이 게시물에 달린 비추천은 이것이 커뮤니티가 바라는 방향이 아니라는 점을 보여줍니다.
2024년 8월 30일
MkDocs의 마지막 릴리스
MkDocs 1.6.1이 릴리스됩니다. 오늘에 이르기까지도 이것이 최신 릴리스이며, 저장소는 문서의 한두 개 수정과 업데이트된 CI 배지를 제외하면 그 이후 활발한 개발이 없었습니다.
2025년 7월 17일
이 프로젝트는 버려진 것인가?
플러그인 작성자 @facelessuser가 매우 직접적인 질문과 함께 토론을 엽니다:
이 프로젝트는 활발히 유지관리되고 있습니까, 아니면 버려진 상태입니까?
[…]
이 프로젝트가 유지관리되고 있는지 아닌지를 커뮤니티에 알려주세요. 유지관리되지 않는 것처럼 보이기 시작하고 있습니다.
그는 활발한 후원자가 있음에도 버그 수정 PR들이 몇 달째 검토되지 않은 채 쌓여 있다고 지적합니다.
@pawamoy의 답변은 2024년 4월 이후 무슨 일이 있었는지 매우 분명한 그림을 그려줍니다. 그는 @lovelydinosaur의 복귀를 중심으로 협력적인 유지관리 모델을 만들려 했지만, @lovelydinosaur는 현재 코드베이스에는 거의 관심을 보이지 않았고 대신 리디자인에 집중하고 있었다고 설명합니다. @pawamoy가 백로그를 정리하고 프로젝트를 유지하려 노력하는 동안, @lovelydinosaur는 PR에서 태그될 때 침묵했습니다.
[…] 그 후 저는 이슈 분류, 질문 답변 등을 서서히 멈췄습니다. 그래서 본질적으로 작년 이후로는 별다른 일이 일어나지 않았고, 오늘날 MkDocs는 유지관리되지 않는 것처럼 보입니다.
@lovelydinosaur는 자신이 현재 초기 프리릴리스 단계에 있는 httpx 1.0에 집중하고 있었고, MkDocs에 시간을 낼 수 있을지를 검토 중이라고 답변합니다. 이에 대한 반응은 다음과 같습니다:
전반적인 우려는 리디자인 자체보다는, 실제 현재의 버그를 해결하기 위한 기본적인 유지보수에 더 가깝다고 생각합니다.
약 열흘 뒤인 8월 3일, @oprypin이 떠난 이후 처음으로 스레드에 다시 나타납니다. 그의 복귀 제안에는 한 가지 조건이 붙어 있었습니다:
저는 MkDocs를 예전 그대로 유지관리하는 일로 돌아올 수 있습니다. 단 하나의 조건이 있습니다: [@lovelydinosaur]가 MkDocs와 관련된 모든 자원에 대한 관리자 권한을 완전히 넘기고 그 후 완전히 떠나야 합니다. 우리는 이런 상황이 다시 반복되는 것을 감당할 수 없습니다.
@lovelydinosaur는 응답하지 않았습니다.
2025년 10월 15일
무대 뒤에서는 작업이 계속되다
MkDocs 사용자들이 버그 수정을 요구하는 동안, @lovelydinosaur는 또 다른 저장소인 encode/mkdocs에서 MkDocs 리디자인 작업을 계속합니다. 그 시점에는 그 저장소는 아직 공개되지 않았습니다.
2025년 11월 11일
squidfunk가 Zensical을 발표하다
2025년 11월 11일, mkdocs-material 9.7.0이 릴리스되고, Material for MkDocs가 유지보수 모드에 들어간다고 발표됩니다. 이와 함께 Zensical의 발표가 나옵니다. 이것은 Material for MkDocs 팀이 처음부터 다시 작성한 현대적인 정적 사이트 생성기입니다. 기존 mkdocs.yml 파일을 네이티브로 읽고, 5배 더 빠르게 재구축하며, 완전히 새롭게 설계된 검색 엔진을 탑재합니다.
몇 달간 조용했던 2024년 4월의 유지관리 스레드에, Material for Mkdocs가 유지보수 모드에 들어간 것이 MkDocs에 새로운 출발이 필요하다는 뜻인지 묻는 질문과 함께 그 블로그 글 링크가 게시됩니다. @oprypin이 다시 등장해 Zensical이 바로 그 새로운 출발이라고 지적합니다. MkDocs에 관해서 그는 이렇게 말합니다:
그냥 적당히 괜찮은 상태로 유지관리해서 기존 사용자들이 걱정하지 않게 하세요.
[…]
이를 위해, 저를 MkDocs의 주된 유지관리자로 복귀시키기 위한 커뮤니티 청원을 시작해 주세요.
2026년 1월 14일
MkDocs 2.0
2026년 1월 14일, @lovelydinosaur는 자신이 비공개로 MkDocs v2 작업을 하는 동안, 다른 사람들이 MkDocs 1.6.2 릴리스를 만드는 것에 열려 있다고 언급합니다.
그리고 1월 21일, @lovelydinosaur는 MkDocs 버전 2를 발표하는 토론을 엽니다:
버전 2 릴리스에 대한 예비 문서를 조금 준비해 두었습니다.
저장소는 현재 비공개입니다… 공개하는 데 시간을 들이고 있으며, 초대와 토론은 요청에 따라 가능할 수도 있고 아닐 수도 있습니다. 첫 번째 초안이 어떻게 보이는지 보고 싶다면… https://www.encode.io/mkdocs/
반응은 압도적으로 부정적이었습니다. 커뮤니티에 따르면 제안된 MkDocs 2.0의 가장 큰 단점은 플러그인 지원의 부재였습니다. 애초에 MkDocs를 훌륭하게 만들었던 것이 바로 그것이었기 때문입니다:
Before MkDocs Material, MkDocs was a toy.
[…]
버전 2 발표와 코드는 MkDocs가 다시 본래의 모습으로 돌아가고 있음을 시사합니다 — 다시 장난감이 되는 것이죠.
@facelessuser는 커뮤니티의 많은 사람들이 생각하는 바를 말로 옮깁니다:
거의 새 이름을 붙였어야 했다고 느낍니다. v1과는 너무 멀리 떨어져 있다고 생각하거든요.
v2 프로젝트가 정확히 무엇을 목표로 하는지는 잘 모르겠지만, 잘 되기를 바랍니다. 다만 재시작이 꼭 필요했던 것 같지는 않습니다.
커뮤니티 구성원들은 MkDocs 버전 2 저장소가 MkDocs 조직이 아니라 encode 조직에 위치해 있다는 점을 지적합니다. encode 조직의 기여 가이드라인은 이슈나 pull request를 여는 것을 명시적으로 권장하지 않습니다. 또한 소스 코드를 공개하지 않는 것은 오픈 소스 소프트웨어 개발의 원칙에 어긋난다고도 지적합니다. @lovelydinosaur는 결국 저장소를 비공개로 둔 이유를 설명합니다:
그러니까… 소스를 공유하는 것 자체 가 문제는 아닙니다. 문제는 GitHub 작업 환경입니다. 저는 연기 자욱한 남성들만의 클럽 같은 분위기에 관심이 없습니다. 너무 노골적으로 비전문적으로 느껴집니다.
2월 13일, @lovelydinosaur는 MkDocs 2.x를 MkDocs 1.x와 하위 호환되게 만들 계획이라는 공지를 제거합니다.
2월 18일, Material for MkDocs 팀은 v2가 왜 자신들의 작업 및 더 넓은 플러그인 생태계와 호환되지 않는지에 대한 전체 분석을 담은 자세한 블로그 글을 게시합니다. 플러그인 시스템의 제거부터 라이선스 부재까지를 다룹니다.
2026년 3월 9일
PyPI 장악
2월 18일부터 Material for MkDocs는 모든 mkdocs build 중에 경고를 표시하기 시작했으며, 사용자들에게 MkDocs 2와의 잠재적인 미래 호환성 문제를 알리고 위에서 언급한 블로그 글로 연결했습니다.
@oprypin이 이전에 했던 PyPI 소유권 접근 권한 획득 요청은 과거 어느 시점에 승인되어 있었습니다. 2024년 그가 물러난 뒤 GitHub 저장소에서의 권한은 제거되었지만, PyPI 저장소에서의 권한은 그렇지 않았습니다.
3월 9일, 그는 원치 않는 MkDocs 2.0 업그레이드가 사용자 프로젝트를 망가뜨리는 것을 막기 위한 마지막 수단이라고 설명하며, 자신의 접근 권한을 이용해 프로젝트에서 다른 모든 유지관리자를 제거합니다. 여기에는 원저자 @lovelydinosaur도 포함되었습니다. 그는 두 개의 GitHub 토론에서 이 장악을 발표합니다. 하나는 mkdocs 안에서였고, 하나는 mkdocs-community 안에서였습니다 (이 조직은 이후 ProperDocs로 이름이 바뀌었습니다). 그의 주된 정당화는 조용한 v2 릴리스가 pip install mkdocs를 실행하는 사용자들에게 도달해 예기치 않게 프로젝트를 망가뜨릴 것이라는 점이었습니다. 그는 mkdocs-community/mkdocs에 새 저장소를 만들고, 앞으로의 PyPI 릴리스가 그곳에서 나올 것이라고 발표했으며, 커뮤니티의 지지를 요청했습니다.
@lovelydinosaur는 PyPI 지원 티켓을 제출하고 @oprypin을 MkDocs GitHub 조직에서 차단합니다.
24시간 안에, @oprypin은 물러섭니다:
저는 여기서 완전히 물러나겠습니다. 죄송합니다.
[…]
프로젝트의 지속은 불일치가 아니라 합의에서 나와야 합니다. 제가 다른 방식이 가능하다고 생각한 것은 잘못이었습니다.
@lovelydinosaur는 PyPI 접근 권한을 되찾습니다.
별도의 토론에서 @Andre601은 프로젝트 상태에 대한 우려를 표하고 프로젝트 유지관리의 미래에 관한 여러 질문을 던졌고, 이에 대해 @lovelydinosaur는 다음과 같이 응답합니다:
우리는 더 이상 남성만 있는 온라인 공간에서 어떤 대화도 하지 않을 겁니다. 그럴 일 없습니다.
2026년 3월 15일
oprypin이 ProperDocs를 출범시키다
PyPI 장악 6일 후, @oprypin은 ProperDocs의 공식 출범을 발표합니다. 이것은 MkDocs 1.x의 드롭인 대체품입니다. pip install mkdocs를 pip install properdocs로 바꾸고, mkdocs build를 properdocs build로 바꾸면 됩니다. 기존 플러그인은 코드 변경 없이 동작합니다. 이 프로젝트는 사용자들을 MkDocs 2.0에서 멀어지게 하는 경고도 함께 제공합니다.
며칠 뒤, @jaywhj는 Material for MkDocs의 연속선상에 있는 MaterialX를 발표합니다.
그렇다면 오늘날 상황은 어디에 와 있을까요?
원래의 MkDocs 저장소는 18개월 동안 의미 있는 개발이 없었습니다. 원저자이자 유일한 유지관리자인 @lovelydinosaur는 커뮤니티의 지지를 받지 못하고 기존 플러그인 생태계를 깨뜨리게 될 리디자인을 추진하고 있습니다. encode/mkdocs v2 저장소는 2026년 2월 19일 이후 비활성 상태입니다.
한편, 생태계에서 가장 널리 사용된 부분들을 만든 사람들은 이미 다른 길로 갔습니다.
@oprypin은 프로젝트의 지속에는 합의가 필요하다고 말했고, 그것이 성공할 가능성은 낮다고 판단해 ProperDocs를 독자적으로 시작했습니다. 이 프로젝트가 즉시 엄청난 인기를 얻은 것은 아닙니다. 일주일 뒤 GitHub에서 스타 21개를 모은 상태였습니다.
@jaywhj는 MaterialX를 유지관리하고 있으며, 원래 프로젝트인 Material for MkDocs가 유지보수 모드에 들어갔기 때문에 이것은 커뮤니티에서 어느 정도 관심을 얻는 것으로 보입니다.
Material for MkDocs를 담당했던 @squidfunk의 팀은 그 개발을 멈추고 Zensical을 처음부터 구축하고 있습니다. MkDocs 생태계에서 가장 활발한 기여자 중 한 명인 @pawamoy도 이 프로젝트에 합류했습니다. 집필 시점 기준으로 Zensical은 GitHub에서 3,700개가 넘는 스타를 기록하며 현재 가장 인기 있어 보이고, 따라서 앞으로 성공해 MkDocs를 대체할 가능성이 가장 높은 시도로도 보입니다.
MkDocs 생태계는 실시간으로 분열되고 있습니다. 세 개의 후계자, 세 가지 비전, 그리고 어느 쪽에 베팅할지를 결정하는 커뮤니티.
이 글의 일부 인용문은 저자의 현재 온라인 존재를 반영하도록 업데이트되었습니다.
© 2026 Florian Maas
