Mockito 메인테이너가 10년 만에 자리에서 물러남

• Mockito 핵심 유지관리자가 2026년 3월을 기준으로 약 10년간의 유지관리 역할을 마무리하고, 향후 몇 달간 점진적 권한 이양을 진행할 계획을 밝힘
• 결정의 직접적 계기 중 하나로 JVM 22에서의 에이전트 정책 변경을 언급하며, 보안 목적의 변화 자체는 공감하지만 대안 없는 일방적 전환 요구와 생태계 차원의 고려 부족이 큰 부담으로 작용했음
• 특히 Mockito가 JVM 에이전트의 최대 사용자 중 하나임에도 불구하고, 빌드 도구 지원이나 협업적 논의 없이 문제 해결을 떠안게 된 구조가 자원 소진과 책임 과중으로 이어졌다고 설명함
• 또 다른 요인으로 Kotlin 지원의 구조적 복잡성을 지적하며, Kotlin 특유의 JVM 동작 방식과 불일치한 기능들이 Mockito 내부에 중복 API와 분기 로직을 증가시켜 유지보수를 어렵게 만들고 있음을 밝힘
• 최근에는 Rust 기반 웹 엔진 Servo 작업에서 더 큰 즐거움과 동기를 느끼고 있으며, 제한된 개인 시간을 고려할 때 의무처럼 느껴지는 자원봉사 유지관리 작업을 지속하기 어렵다는 판단에 도달했음을 공유함

---

10년이라는 마일스톤과 역할 이양 결정

• 2026년 3월로 Mockito 유지관리 10주년을 맞이하며, 해당 시점을 자연스러운 책임 이양의 분기점으로 판단함
• 향후 몇 달간 기존 유지관리자로서 지식 이전과 전환 안정화에 집중할 계획임
• 차기 유지관리 체계와 장기 로드맵 논의는 별도의 GitHub 이슈에서 진행 예정임

JVM 에이전트 정책 변경으로 인한 소진

• Mockito 5에서 기본 아티팩트가 JVM 에이전트로 전환된 배경에는 JVM 22부터 동적 에이전트 부착이 플래그 뒤로 숨겨진 정책 변화가 있음
• 보안 관점의 변경 취지에는 동의하지만, 대체 설계나 마이그레이션 지원 없이 결정이 기정사실화된 점이 문제로 지적됨
• Mockito가 JVM 기능 선도 사례로 자주 활용되어 왔음에도, 이번 변화에서는 협업적 피드백 루프가 작동하지 않았음
• 에이전트에 대한 빌드 도구 차원의 지원이 여전히 부족한 현실이 해당 기능의 우선순위가 낮음을 보여준다고 평가함
• 자발적 기여자인 유지관리자에게 과도한 압박이 가해질 경우 오픈소스 협업 구조가 쉽게 붕괴됨을 강조함

Kotlin 지원이 초래한 구조적 부담

• Kotlin의 확산 자체는 부정하지 않지만, JVM 내부 동작 방식의 차이로 인해 mockito-core에 Kotlin 전용 처리 흐름이 다수 추가됨
• suspend 함수 등 Kotlin 기능이 일관되게 동작하지 않는 사례가 존재해 API 중복과 복잡성이 증가함
• 결과적으로 코드베이스가 스파게티화되고 유지보수 난이도가 상승했으며, 이에 대한 작업이 개인적으로 즐겁지 않다고 솔직히 언급함
• Kotlin 중심의 미래가 장기적으로 Mockito 유지관리 동기를 약화시키는 요소로 작용했음

다른 오픈소스 활동에서의 즐거움 회복

• 다수의 오픈소스 프로젝트에 기여해 왔으며, 최근에는 Rust 기반 웹 엔진 Servo 작업을 통해 개발의 즐거움을 다시 느끼고 있음
• 제한된 저녁 시간 선택지에서 Mockito보다 다른 프로젝트가 더 큰 만족을 제공하는 상황이 지속됨
• 자원봉사 기반 유지관리 작업이 장기간 의무처럼 느껴지는 상태는 바람직하지 않다고 판단함

결정의 종합적 배경과 메시지

• JVM 정책 변화로 인한 회의감, Kotlin 지원 구조의 한계, 그리고 다른 프로젝트에서의 동기 회복이 결정의 핵심 요인으로 작용함
• 해당 요인들이 모든 기여자에게 동일하게 적용되지는 않으며, 다른 이들이 Kotlin 지원에 더 적극적일 수 있음을 인정함
• 유지관리자 교체가 프로젝트의 장기적 건강성에 더 이롭다는 판단 아래 역할을 내려놓기로 결정함
• 오픈소스 유지관리 경험 자체는 영광이자 특권이었다고 평가하며, 다른 이들에게도 자원봉사적 기여를 권장함

[GN⁺]

Hacker News 의견들

• Google에서 두 번째 프로젝트를 하면서 mocking을 완전히 포기하게 되었음
  GWT로 시스템을 리라이트하면서 테스트 커버리지를 강제했는데, 모두가 자기 서비스만 테스트하고 DI로 mock을 주입했음
  그 결과 시스템이 극도로 취약해졌고, 8주 된 서비스가 마치 레거시 코드처럼 느껴졌음. 백엔드 순서나 호출 횟수만 바꿔도 하루 종일 mock 수정에 매달려야 했음
  Guice 모듈 구조도 복잡해서 테스트 환경용 mock을 주입하려면 완전히 다른 인젝터를 만들어야 했고, 결국 테스트와 프로덕션이 다른 환경이 되어버렸음
  또 EasyMock vs Mockito 논쟁으로 수많은 엔지니어링 리소스가 낭비되었음
  나는 이후로 mock을 거의 쓰지 않음. 대신 간단한 dummy 서비스를 만들어 최소한의 실제 동작을 흉내 내는 게 훨씬 낫다고 생각함
  mock에 집착하는 사람을 보면 지금도 경계심이 생김

  • “최소한의 올바른 동작을 하는 dummy 버전”이라면 그게 바로 mock의 정의 아닌가 하는 의문이 듦
  • 그런 dummy를 mock으로 구현하지 않는다면 mock을 잘못 쓰고 있는 것임
  • 나도 Google에서 비슷한 결론을 얻었음. 대부분의 경우 fake가 mock보다 낫다고 생각함. 다만 Google처럼 모든 소스에 접근 가능한 환경이 아니면 mock이 필요한 경우도 있음
  • Mockito는 레거시 코드 리팩토링이나 외부 라이브러리 테스트처럼 어쩔 수 없는 상황에서만 썼음. 첫 번째 선택지는 절대 아님
  • mock 남용은 “테스트 피라미드”의 오해에서 비롯됨. 단위 테스트만 강조하다 보니 취약하고 가치 낮은 테스트가 양산됨. AI가 이런 테스트를 자동 생성하면서 상황이 더 악화되고 있음

• 나는 Kotlin에서 4년간 Mockito를 써왔고, 99%의 경우 충분히 쓸 만했음
  복잡하거나 헷갈리는 상황은 대부분 내 관심사 분리 부족 때문이었음
  MockK와의 차이는 거의 없고, 단지 문법 차이 정도임. 다만 Mockito가 유지보수 중단되면 교체를 고려해야 할 듯함

  • 이런 논쟁을 보면 오히려 프로젝트가 잘됐다는 증거 같음. 10년 넘게 헌신한 개발자에게 감사의 건배를 보냄
  • 분노라기보단, Kotlin과 Rust로 옮겨가려는 자연스러운 흐름처럼 보임
  • 처음부터 Kotlin 지원을 거절했어야 했다고 생각함. Kotlin 전용 프레임워크가 따로 있었으면 더 나았을 것임
  • 도구 자체의 문제는 아님. mock과 spy가 너무 편해서 테스트 구조를 제대로 설계하지 않게 되는 게 문제임

• mock은 애플리케이션이 4~5계층일 때 가장 효과적임
  나도 예전엔 DI를 남용해 복잡한 코드 그물망을 만들었지만, 지금은 계층을 제한하고 일관된 구조를 유지함
  단일 클래스 테스트엔 mock을, 요구사항 검증엔 통합 테스트를 씀
  결국 중요한 건 도구가 아니라 개발자의 규율임

• Mockito는 Java에서 가장 인기 있는 mocking 프레임워크임

  • 하지만 이걸로 만들어진 테스트 지옥을 겪으면서 수명을 깎아먹은 기분이었음
  • 스페인어로는 “작은 코딱지”라는 뜻이라 이름이 좀 웃김

• 플랫폼 변경으로 Mockito가 agent 기반으로 바뀌었는데, JVM 22부터 동적 agent 로딩이 플래그 뒤로 숨겨졌기 때문임
  이런 변화가 엔터프라이즈 도입을 늦출 수도 있음

  • 단지 테스트 실행 시 플래그를 추가하면 되는 수준임
  • 어차피 대부분의 기업은 아직 Java 8에서 17로 옮기는 중이라, JVM 22는 한참 뒤 이야기임

• 플랫폼 변경이 Mockito 커뮤니티에 과도한 책임 전가로 느껴졌음
  “JVM 생태계를 막고 있다”는 식의 비난은 건강하지 않다고 생각함

  • 하지만 JDK 팀은 이런 변경을 수년 전부터 예고했음. 약간의 설정만 추가하면 여전히 동적 기능을 쓸 수 있고, 이는 플랫폼 최적화와 보안을 위한 올바른 선택임

• 오픈소스 유지보수는 정말 소모적인 일로 보임
  나였다면 그냥 아카이브하고 손 뗐을 것임. Tim이 이제라도 평온을 찾길 바람

  • 그래도 품위를 지킨 퇴장이었다고 생각함. 오랜 시간 쏟은 노력을 존중하며, Tim이 이룬 성취는 영원히 자랑스러울 것임

• TimvdLippe에게 감사의 말을 전하고 싶음. 훌륭한 비전과 헌신을 보여줬음

• Mockito는 테스트를 잘 아는 사람이 쓰면 괜찮음
  어떤 언어나 프레임워크에서도 나쁜 테스트는 작성자 탓임

• “Agent”란 JVM에 부착되어 실행 중인 애플리케이션을 계측·변경할 수 있는 도구를 뜻함
  프로파일러, 디버거, 모니터링 툴 등이 이 메커니즘을 사용함
  Java 21부터는 보안 강화를 위해 기본적으로 비활성화되었고, -XX:+EnableDynamicAgentLoading 플래그로만 허용됨
  자세한 내용은 JEP 451 문서 참고

  • 같은 문서 JEP 451: Prepare to Disallow the Dynamic Loading of Agents에 배경 설명이 있음
  • 예전엔 런타임 중 디버거를 포트로 연결할 수 있었지만, 보안 문제로 이제는 시작 시 명시적으로 agent를 등록해야 함