10년간 Mockito 메인테이너로 활동해 온 작성자가 2026년 3월을 기점으로 역할을 내려놓기로 한 이유와 배경을 정리한 글.
2026년 3월이면 저는 Mockito 메인테이너를 맡은 지 10년이 됩니다(제 인생 전체의 거의 3분의 1에 해당합니다). 앞으로를 내다보며, 10년이라는 이정표는 메인테이너십을 다른 분들께 넘기기에 좋은 시점이라고 판단했습니다. 앞으로 3월까지 남은 몇 달 동안은 메인테이너십이 원활하게 이양될 수 있도록 시간을 쏟을 예정입니다.
이 이슈에서는 제가 이런 결정을 내린 몇 가지 고려 사항을 나열합니다. 향후 메인테이너십에 대한 계획의 소통과 논의는 다른 곳, 아마도 별도의 GitHub 이슈에서 진행될 것입니다. 그 소식도 곧 공유하겠습니다.
아시다시피 Mockito 5에는 큰 변경이 있었는데, 이제 주 아티팩트가 에이전트(agent)입니다. 그 이유는 JVM 22부터 이전에 이른바 “에이전트의 동적 부착(dynamic attachment of agents)”이 플래그 뒤로 숨겨졌기 때문입니다. 이 변경은 보안 관점에서 타당하며 저도 지지합니다.
하지만 이 변경이 Mockito 메인테이너들에게 제시된 방식은, 좋게 말해도 매우 에너지를 소모시키는 일이었습니다. Mockito는 이런 종류의 에이전트를 아마 가장 크게 사용하는 프로젝트이며, 다른 프로젝트들이 참고하기 위한 영감의 원천으로도 자주 바라봅니다. 그런 만큼 Mockito는 ByteBuddy라는 탄탄한 기반 위에서 JVM 기능 지원을 종종 선도해 왔습니다. 모듈(Modules) 역시 그런 기능 중 하나였고, Rafael이 JVM 메인테이너들에게 피드백을 제공하는 일까지 포함해 몇 달에 걸친 고된 작업을 통해 해결해 냈습니다.
불행히도, 에이전트 논의에서는 그런 협업 방식이 전혀 아니었습니다. 제게는 보안이라는 이유로 이미 결정된 사안처럼 느껴졌습니다. 동적 부착이 여러 면에서 문제가 있다는 점은 맞지만, 대안은 제시되지 않았습니다. 물론 Mockito가 이런 대안을 선도적으로 만들어 나가는 경우가 많으니 그 자체는 괜찮습니다. 다만 이번에는 우리가 홀로 남겨졌다는 느낌을 받았습니다.
제 개인적인 견해로는, 이 변경에 관여한 분들이 그것이 가져올 사회적 영향(societal impact)을 심각하게 과소평가했습니다. 지금까지도 제대로 된 빌드 지원이 존재하지 않는다는 사실은, 에이전트가 우선순위가 아니라는 것을 보여 줍니다. 우선순위가 아니라면 그것 자체는 괜찮지만, Mockito와의 커뮤니케이션에서는 “Mockito가 동적 부착을 사용함으로써 JVM 생태계를 뒤로 잡아끌고 있으니, 즉시 전환하고 나머지는 알아서 해결하라”는 식으로 받아들였습니다.
여기서 중요한 것은, 저(그리고 다른 사람들)가 프로젝트를 위해 최선을 다하는 자원봉사자라는 점입니다. 사회적 영향을 이해하려면 이 점이 중요합니다. 선의로 자기 시간을 쪼개 일하는 개인에게 압박을 가하면, 결국 시스템이 무너집니다. 오픈소스 세계 전체가 소수의 개인에게 의존한다는 사실을 XKCD로 농담하곤 하는데, 이번 상황은 그 말이 더할 나위 없이 사실임을 보여 줍니다. 개인에게 과도한 압박이 가해지면 협업 시스템이 붕괴한다는 점에서 말이죠.
이 일련의 사건은 제가 메인테이너로서의 제 위치를 재고하게 만드는 씨앗을 심었습니다.
최근 몇 년 사이 Kotlin의 인기가 크게 성장했다는 것은 부정할 수 없습니다. Mockito는 JVM 언어들을 위해 여러 “플레이버(flavor)”를 유지하고 있는데, 이런 패키지들은 대체로 통합을 더 편하게 만드는 문법 설탕(sugar)을 포함합니다. 어떤 경우든 기능 구현은 mockito-core가 담당하는 구조입니다.
불행히도 이 모델은 Kotlin에는 잘 맞지 않습니다. 거의 모든 JVM 언어는 내부적으로 비슷하게 동작하지만, Kotlin은 종종 다르게 동작합니다. 그 결과 mockito-core의 여러 지점에서 Kotlin을 위해 별도의 흐름이 존재합니다. 대개는 Kotlin이(제 관점에서는) JVM이 원래 의도하지 않았던 ‘꼼수(shenanigans)’를 부리지만, 결국 가능하긴 했기 때문에 생긴 직접적인 결과입니다.
Kotlin 내부에서도 기능이 일관되게 동작하지 않습니다. 가장 잘 알려진 예가 suspend 함수입니다. 그 결과 Mockito 코드는 점점 더 스파게티화되고, Kotlin의 핵심 언어 기능 하나를 지원하기 위해 API를 통째로 중복 구현하는 경우도 생기며, 전반적으로 유지보수성이 떨어집니다.
개발자들이 Kotlin의 풍부한 기능 때문에 그 언어를 좋아하는 이유는 충분히 이해합니다. 하지만 그 기반 구현은 Mockito 같은 프로젝트에 상당한 단점을 안겨 줍니다. 솔직히 말해, 다루는 게 즐겁지 않습니다.
Kotlin이 더 지배적이 되는 미래는, 제가 Mockito에 계속 에너지를 쏟을 수 있을 것이라는 희망을 갖게 해 주는 미래가 아닙니다.
저는 늘 오픈소스 작업을 좋아해 왔고, 그동안 수백 개의 프로젝트에 기여해 왔습니다. Mockito는 제게 가장 중요한 프로젝트이지만, 다른 프로젝트들에도 꾸준히 참여해 왔습니다. 최근 몇 달 사이 저는 Servo 작업을 하며 프로그래밍의 즐거움을 다시 발견했습니다. Servo는 Rust로 작성된 웹 엔진입니다.
어느 주에 저녁 시간 2시간을 어떻게 쓸지 선택해야 할 때, 지난 1년 동안은 Mockito를 우선으로 두는 경우가 드물었습니다. 과거에는 Mockito가 제 ‘기본 선택(go-to)’이었고 정말 즐겁게 했습니다. 하지만 요즘은 Servo와 관련 프로젝트들이 훨씬 더 큰 즐거움을 줍니다.
위의 이유들 때문에 Mockito 작업이 ‘집안일(chore)’처럼 느껴지기 시작하면, 왜 내가 Mockito를 해야 하는지 스스로 정당화하기가 어려워집니다. 자원봉사 작업은 적어도 오랜 기간 동안은 집안일처럼 느껴져서는 안 된다고 생각합니다.
읽으셨듯이, 이 세 가지 요인이 결합되어 제가 이런 결정을 내리게 되었습니다. 첫 번째는 제가 제 위치를 의심하기 시작한 이유를 설명하고, 두 번째는 상황이 좋은 방향으로 바뀔 것이라는 희망을 갖기 어려운 이유를 설명하며, 세 번째는 다른 방식으로 즐거움을 찾게 된 과정을 설명합니다.
이 점들이 메인테이너로서 저에게는 큰 영향을 미쳤지만, 다른 사람들에게도 같은 방식으로 적용되지는 않을 것이라고 생각합니다. 예를 들어 Kotlin 지원에 의욕적인 분들도 있다는 것을 알고 있습니다. 그래서 저는 10년이면 Mockito를 전진시키는 데 충분한 시간을 보탰다고 결론 내렸습니다. 이제는 다른 누군가가 맡아야 할 때이며, 그것이 프로젝트로서 Mockito의 최선의 이익에 부합한다고 믿습니다. 결국 그것이 제가 처음 메인테이너가 되기로 한 이유이기도 합니다. 제 일이 수백만 소프트웨어 엔지니어를 위한 Mockito를 더 나아지게 만들 수 있다고 믿었기 때문입니다.
궁금해하시는 분들을 위해 덧붙이자면, 네—저는 오픈소스 프로젝트를 유지보수하는 것 같은 자원봉사 역할을 모두에게 진심으로 권합니다. 그 일을 할 수 있었던 것은 영광이자 특권이었고, 함께 일하며 즐거웠던 분들께 감사드립니다.
지정된 사람 없음
라벨 없음
유형 없음
프로젝트 없음
마일스톤 없음
아직 없음
브랜치 또는 풀 리퀘스트 없음
