이사회가 창업자를 멈춘다면, 워드프레스의 권력도 바뀔까요?

핵심 요약

회사 이사회의 결정이 오픈소스 프로젝트의 운영 권한까지 자동으로 바꾸지는 않습니다.
코드를 공개하는 것과 중요한 결정을 함께 내리는 것은 별개의 문제입니다.
프로젝트를 복제할 수 있어도 배포망과 이용자의 신뢰까지 그대로 가져오기는 어렵습니다.
창업자의 영향력이 큰 프로젝트일수록 권한의 범위와 이의 제기 절차를 명확히 정해야 합니다.

워드프레스 공동 창업자 매트 뮬렌웨그에게 오토매틱 이사회가 휴직을 요구한다면, 워드프레스의 운영 권한도 함께 바뀔까요? 실제 사건을 전제로 한 질문은 아닙니다. 이런 상황을 가정하면 오픈소스 생태계에서 누가 권한을 쥐고 있는지 따져볼 수 있습니다. 웹사이트 운영자에게도 중요한 문제입니다. 운영 주체가 어떤 결정을 내리느냐에 따라 서비스를 계속 이용할 수 있을지가 달라질 수 있기 때문입니다.

이사회가 결정할 수 있는 범위부터 따져봐야 합니다

먼저 회사와 오픈소스 프로젝트를 구분해야 합니다. 워드프레스 프로젝트와 오토매틱이라는 회사는 서로 다른 조직입니다. 한 사람이 양쪽에서 큰 영향력을 행사한다고 해서 둘을 같은 조직으로 볼 수는 없습니다.

이사회의 권한을 알려면 회사 안에서 어디까지 결정할 수 있는지부터 살펴봐야 합니다. 창업자가 회사에서 하는 일을 제한하는 것과 외부 프로젝트에서 맡은 역할을 바꾸는 것은 별개의 결정입니다.

가령 회사에서 맡던 업무를 다른 사람에게 넘겼더라도, 프로젝트의 코드 변경 승인 권한이나 배포 권한까지 함께 넘겼다고 볼 수는 없습니다. 각 권한을 누가 갖고 있는지, 어떤 규칙에 따라 맡았는지 확인해야 합니다.

이처럼 휴직을 가정할 때는 ‘창업자가 자리를 비운다’는 문구만으로 변화를 알 수 없습니다. 어떤 권한을 누가 넘겨받는가를 알아야 실제로 무엇이 달라지는지 판단할 수 있습니다.

코드가 열려 있어도 결정권은 집중될 수 있습니다

오픈소스 코드는 라이선스가 허용하는 범위에서 사용하고 수정하고 재배포할 수 있습니다. 그렇다고 모든 참여자가 프로젝트 운영에 대해 동등한 표결권을 갖는 것은 아닙니다.

코드에 기여하는 일과 프로젝트의 방향을 정하는 일은 다릅니다. 누구나 수정안을 제출할 수 있어도 이를 최종적으로 반영할지는 특정 관리자가 정할 수 있습니다. 토론에 참여하는 사람에게 출시 일정이나 운영 정책을 결정할 권한까지 있는 것도 아닙니다.

이런 권한과 절차를 정하는 규칙이 거버넌스입니다. 쉽게 말해 ‘누가 무엇을 결정하고, 그 결정에 어떻게 이의를 제기할 수 있는가’를 정해 둔 것입니다.

오픈소스가 얼마나 열려 있는지 판단하려면 이 규칙을 살펴봐야 합니다. 코드를 공개했는지와 함께 중요한 결정을 어떤 절차로 내리는지도 봐야 한다는 뜻입니다. 참여자가 결정에 영향을 줄 통로가 없다면, 코드가 공개된 프로젝트에서도 소수에게 권력이 집중될 수 있습니다.

“마음에 안 들면 복제하면 된다”는 말의 한계

오픈소스에서는 포크를 할 수 있습니다. 기존 코드를 가져와 별도의 프로젝트로 발전시키는 방식입니다. 운영 방향에 동의하지 않는 사람들도 이 방법으로 자신들이 원하는 방향의 프로젝트를 이어갈 수 있습니다.

다만 코드를 복제했다고 해서 사람들이 계속 이용할 서비스를 운영할 준비까지 끝나는 것은 아닙니다.

가령 플러그인 배포 서비스를 새로 만든다고 해 보겠습니다. 서버를 마련한 뒤에도 개발자들이 그곳에 플러그인을 등록하도록 설득해야 합니다. 이용자가 업데이트를 믿고 설치할 수 있게 보안 문제에 대응하고 서비스를 관리할 체계도 갖춰야 합니다.

코드는 복제할 수 있어도 신뢰를 얻고 참여자와 관계를 쌓는 일은 다시 해야 합니다. 이를 맡을 사람이 필요하고, 시간과 비용도 듭니다.

포크가 가능하다는 이유만으로 기존 운영자의 영향력이 작다고 보기는 어렵습니다. 이용자가 다른 서비스로 옮기는 데 비용이 든다는 점도 기존 운영자의 권한에 힘을 실어 줍니다.

창업자의 선의에만 기대지 않는 규칙

창업자에게 권한이 모이면 프로젝트의 방향을 빠르게 정할 수 있습니다. 프로젝트의 역사를 잘 아는 사람이 어려운 결정을 맡고 책임진다는 장점도 있습니다.

문제는 그 판단에 다른 의견이 나올 때입니다. 특히 회사의 이해관계와 프로젝트 참여자의 요구가 충돌하면, 창업자 개인을 신뢰한다는 이유만으로 갈등을 풀기는 어렵습니다.

이런 상황에 대비할 규칙이 있는지는 다음 질문으로 확인할 수 있습니다.

회사 업무에서 행사하는 권한과 프로젝트 운영에서 행사하는 권한이 구분돼 있습니까?
중요한 운영 정책을 바꿀 때 따르는 기준과 절차가 공개돼 있습니까?
결정에 영향을 받는 참여자가 이의를 제기할 수 있습니까?
핵심 운영자가 자리를 비울 때 업무와 접근 권한을 넘길 절차가 있습니까?

이런 규칙은 창업자에게도 도움이 됩니다. 갈등이 생길 때마다 혼자 판단하고 책임져야 하는 부담을 덜 수 있기 때문입니다. 참여자도 누구에게 어떤 근거로 문제를 제기해야 할지 알 수 있습니다.

핵심 인물이 자리를 비워도 작동할 규칙

이사회가 창업자의 활동을 제한하더라도 오픈소스 생태계의 권력까지 분산됐다고 보기는 어렵습니다. 운영 권한을 누가 넘겨받았는지, 참여자가 결정에 영향을 줄 통로는 어떻게 달라졌는지 확인해야 합니다. 사용하는 오픈소스 프로젝트를 살필 때도 핵심 인물이 자리를 비운 뒤에 작동할 규칙이 있는지 따져봐야 합니다.