워드프레스닷컴을 운영하는 오토매틱(Automattic)에서 2026년 9월 초 경영권을 둘러싼 이례적인 사건이 있었다. 9월 9일 이사회가 창업자이자 CEO인 맷 뮬렌웨그를 유급 휴직 처리하고 최고재무책임자를 임시 CEO로 지명했으나, 약 33시간 뒤 뮬렌웨그가 자리에 복귀했다.
이후 회사는 그가 이사회의 전폭적인 지지를 받는 회장 겸 CEO라고 확인했고, 축출 표결에 참여했던 이사진은 회사를 떠난 것으로 보도됐다. 표결의 배경은 명확히 공개되지 않았다.
기업 내부 정치는 보통 개발자의 관심사가 아니다. 그런데 이 회사는 다르다. 워드프레스는 웹의 상당 부분을 구동하고, 오토매틱은 그 생태계에서 가장 큰 상업적 주체다. 재단과 회사, 오픈소스 프로젝트와 상업 제품, 커뮤니티와 창업자가 한 사람을 중심으로 얽혀 있다. 그 중심이 33시간 흔들렸다는 사실 자체가 생태계의 구조를 드러낸다.
타임라인
워드프레스 위에 사업을 올린 사람들의 질문
전 세계 수많은 에이전시·쇼핑몰·미디어가 워드프레스 위에서 돌아간다. 그런 조직이 이번 일에서 던져야 할 질문은 "누가 옳은가"가 아니라 "우리 사업이 특정 인물이나 회사의 결정에 얼마나 노출돼 있는가"다.
이 질문들은 이번 사건과 무관하게 항상 유효하다. 다만 이런 사건이 터졌을 때가, 미뤄 뒀던 점검을 실제로 하게 되는 유일한 시점이기도 하다.
오픈소스 거버넌스라는 오래된 숙제
많은 대형 오픈소스 프로젝트가 창업자 중심 구조로 출발한다. 초기에는 그게 속도의 원천이다. 결정이 빠르고 방향이 일관된다. 그런데 생태계가 커지면 같은 구조가 위험이 된다. 한 사람의 판단이 수만 개 사업의 운명과 직결되기 때문이다.
- 빠른 의사결정
- 일관된 제품 방향
- 장기 비전 유지
- 조율 비용이 낮음
- 단일 인물 리스크 완화
- 이해관계자 대표성
- 예측 가능한 정책 변경 절차
- 기업 인수·경영권 변화에 대한 완충
정답은 없다. 재단 모델도 관료화와 느린 의사결정이라는 대가가 있다. 다만 프로젝트가 특정 규모를 넘으면, "지금 구조가 창업자에게 무슨 일이 생겨도 작동하는가"라는 질문에 답할 수 있어야 한다. 이번 사건은 그 질문을 생태계 전체에 다시 던졌다.
출처
- TechCrunch, "Automattic confirms Mullenweg has returned as CEO after attempted ouster by board" (2026-09-12) — https://techcrunch.com/2026/09/12/automattic-confirms-mullenweg-has-returned-as-ceo-after-attempted-ouster-by-board/
- TechCrunch, "Automattic's board forces CEO Matt Mullenweg into leave of absence" (2026-09-09) — https://techcrunch.com/2026/09/09/automattics-board-forces-ceo-matt-mullenweg-into-leave-of-absence/
- TechCrunch, "Sources say Automattic's board is out after failed attempt to oust CEO" (2026-09-14) — https://techcrunch.com/2026/09/14/sources-say-automattics-board-is-out-after-failed-attempt-to-oust-ceo-matt-mullenweg/
자주 묻는 질문
무슨 일이 있었나요?
2026년 9월 9일 오토매틱 이사회가 CEO 맷 뮬렌웨그를 유급 휴직 처리하고 CFO를 임시 CEO로 지명했습니다. 약 33시간 뒤 그가 복귀했고, 회사는 이후 그가 이사회의 전폭적 지지를 받는 회장 겸 CEO라고 확인했습니다.
왜 그런 표결이 있었나요?
공개된 설명이 없습니다. 보도 역시 소식통 인용에 기반하고 있어 동기는 확인되지 않았습니다. 이후 표결에 관여한 이사진이 회사를 떠난 것으로 전해졌습니다.
워드프레스 사이트 운영에 당장 영향이 있나요?
현재까지 서비스 운영이나 오픈소스 프로젝트 배포에 직접적 변화가 보도되지는 않았습니다. 다만 이런 사건은 플랫폼 의존도를 점검해 볼 계기가 됩니다. 데이터 내보내기, 호스팅 이전, 라이선스 종속 여부를 확인해 두세요.
우리 서비스의 플랫폼 리스크는 어떻게 관리하나요?
콘텐츠와 미디어를 표준 형식으로 상시 내보낼 수 있는 경로를 확보하고, 사이트 빌드를 코드로 재현 가능하게 만들며, 핵심 플러그인이 중단될 경우의 대안을 미리 파악해 두는 것이 기본입니다. 전환 비용을 대략이라도 산정해 두면 의사결정이 빨라집니다.
오픈소스 프로젝트의 거버넌스는 어떻게 봐야 하나요?
창업자 중심 구조는 속도에 유리하지만 단일 인물 리스크를 안습니다. 재단이나 분산형 거버넌스는 리스크를 낮추는 대신 의사결정이 느려집니다. 중요한 것은 형태보다, 핵심 인물이 부재해도 정책 결정과 배포가 계속될 수 있는지 답할 수 있느냐입니다.

댓글 0