'돌발위기!' CIO를 위한 오픈소스 포킹 대처법

이런 상상을 해보자. 기업이 잘 운영되면서 안정적이고 잘 엔지니어링 된 오픈소스 소프트웨어로 몇 가지 중요 비즈니스 프로세스를 지원하고 있는데, 갑자기 프로젝트의 개발자 커뮤니티에서 모든 것이 잘못됐음이 명백해졌다. 소프트웨어 포크(fork)가 예정되고 오픈소스 프로젝트의 미래조차 불투명해진 상황에서 어떻게 대처해야 할까.


Image Credit: Omran Jamal/Pexels.com

포크가 실제로 나쁜 것인지 포크에 직면했을 때 CIO가 무엇을 해야하는지에 대해 살펴보기 전에 먼저 여기서 다루려고 하는 이야기가 무엇인지 정리해보자.

소프트웨어 포크에 대해 연구해 온 스페인의 레이 후안 카를로스 대학 연구자 그레고리오 로블레스와 헤수스 곤잘레스 바라호나에 따르면, 포킹(forking)은 개발 커뮤니티의 일부(혹은 프로젝트와 무관한 서드파티)가 프로젝트의 소스 코드 기반을 토대로 완전히 별도의 개발을 시작하는 것이다. 프로젝트가 포크로 인정받으려면, 새로운 프로젝트명과 소프트웨어 브랜치, 평행 인프라(웹사이트, 버저닝 시스템, 메일링 목록 등), 새로운 개발자 커뮤니티(원래와 분리) 등이 필요하다.

무엇보다 포킹이 그리 흔하지 않다는 점을 분명히 하자. 연구자에 따르면, 지난 몇 년간 포크가 더 활성화되긴 했지만 전체 건수는 오픈소스 프로젝트의 수에 비례해 늘어나는 추세는 아니다.

포크의 양면
그리 흔하지 않다고 해도 해당 프로젝트가 현재 사용하고 있는 것이라면 결코 긴장을 늦출 수 없다. 그렇다면 CIO는 포크에 대해 어떻게 생각해야 할까?

오픈 소스 이니셔티브(Open Source Initiative)의 회장 알리슨 랜달은 “한쪽 극단으로 보면 포킹은 오픈소스 코드에 기여하는 공헌자가 갖는 근원적 권리이다. 포킹의 자유는 매우 훌륭한 것이며 때로는 죽어가는 프로젝트를 살리는 좋은 방안이 될 수 있다”라고 말했다. 예를 들어 리브레오피스(LibreOffice)는 포크 이전에 코드의 개발을 저해하는 '인적 문제'로 고통받고 있었다. 리브레오피스 포크는 성공적이었고 현재는 포크 이전의 오픈오피스를 넘어섰다.

물론 포킹이 항상 긍정적인 결과를 낳는 것은 아니다. 랜달은 “프로젝트 포킹이 커뮤니티를 갈라놓고, 긴장을 조장하고, 자원을 차단하고 궁극적으로 2개 프로젝트 모두를 죽이는 사례도 있었다. 만약 프로젝트가 분할되고 각각에 절반의 개발 인력만 배정되면 결국 같은 이용자를 놓고 경쟁하는 상황이 된다. 둘 다 일정한 선을 넘지 못하게 되고 이 지점에서 문제에 빠진다"라고 말했다.

프로젝트 분할이 성공하려면 몇가지 해야 할 일이 있다. 랜달은 "만약 포크가 발표되면 이를 표준 리스크 산정 활동으로 다뤄야 한다"고 조언했다. 그는 “두개의 포크 모두를 평가하고 만약 한쪽이 개발자 확보 측면에서 우세함을 가지면 그게 핵심이다. 또한 한쪽이 충분한 이용자수를 확보하는 지도 봐야한다. 만약 그렇다면 최종적으로 이용자 쪽에 배팅하는 것이 좋다. 설사 이를 지원하는 기업이 없더라도 결국은 사용자가 많은 쪽이 이긴다. 만약 한쪽 포크가 성공적이라면 기업은 그 포크를 지원하게 될 것이다”라고 말했다.


현실은 복잡할 수 있다
가끔은 포크가 성공할지 불확실할 때가 있고 어느 쪽도 개발자와 이용자의 주류를 확보하지 못하기도 한다. 랜달은 “그런 경우에는 기다리거나 다른 프로젝트를 활용할 수 있고 최소한 별도의 대안을 찾아야 한다”라고 말했다.

올해 초 넥스트클라우드(Nextcloud)가 온클라우드(ownCloud)에서 포크했을 때, 온클라우드의 공동창업자 프랭크 칼리첵이 이 포크를 지원했고 곧바로 넥스트클라우드를 창립했다. 그럼에도 불구하고 칼리첵은 피할 수 있다면 포크를 피하는 것이 좋다는 생각이다. 그는 "일반적으로 포킹은 좋은 것이 아니다. 막대한 단점이 있으므로 마지막 선택이 돼야 한다. 포크는 커뮤니티를 어지럽히고 해를 끼치고 최악의 경우 커뮤니티를 나눠버리게 된다”라고 말했다.

칼리첵 역시 넥스트클라우드를 창립했을 때 프로젝트를 활용하는 회사의 CIO이자, 구독이나 지원 패키지에 돈을 내는 사람으로서 포크 착수가 피해야 할 여러 문제를 발생시킨다는 것을 바로 알아차렸다. 그는 “만약 (온클라우드 같은) 회사에 고객이 있다면 그들에 대한 책임이 있는 것이고, 포크 상황에서 가장 중요한 것은 이들 고객을 안심시키는 것이다. 고객이 금전적 손실 없이 매끄럽게 포크로 전환할 수 있게 해야 하는데 이는 정말 까다롭다"라고 말했다.

넥스트클라우드의 경우 최초 배포판이 온클라우드의 '직접적 대안'이며 100% 호환된다는 점을 분명히 했다. 또한 온클라우드 고객의 기존 지원 계약을 모두 승계한다는 사실도 확실히 했다.

문제는 비기술적 요인 때문에 어떤 포크가 승리할지 일정한 불확실성에 노출된다는 점이다. 리브레오피스 프로젝트의 핵심 멤버인 마이클 믹스는 이를 브랜딩의 문제로 파악한다. 그는 “엔지니어는 포크가 전적으로 미래에 관한 것이라 생각하지만 리브레오피스는 기존 오픈오피스의 많은 기능을 지원하고 있다. 리브레오피스와 오픈오피스 모두 무료이고 둘 사이에 자유롭게 오갈 수 있음에도 불구하고 리브레오피스가 자리를 잡는 데 오랜 시간이 걸렸다. 브랜드 구축에는 많은 비용과 자원이 들고 이런 자원이 없으면 포크 자체가 실패할 수 있다"라고 말했다.

포크에 대한 두려움?
그렇다면 CIO는 포크를 두려워해야 할까? 이 질문에 가장 좋은 대답은 과거 사례를 살펴보는 것이다. 로블스와 곤잘레즈-바라호나가 2011년 8월까지 220개의 포킹된 프로젝트를 찾아 분석한 결과를 보면, 원래 프로젝트와 포크 모두 중단된 비율은 9%가 안됐다. 원래 프로젝트의(가능한 혹은 실제) 중단으로 포크가 이뤄진 경우를 제외하면 원래 프로젝트는 10% 정도 중단되고 포크는 그보다 약간 더 많이(14%) 중단된 것으로 나타났다.

이는 결론적으로 포크된 10개 프로젝트 중 9개가 원래 프로젝트든 그에서 나온 포크든 기존에 사용하던 소프트웨어를 계속해서 사용할 수 있다는 의미이다.

이는 넥스트클라우드의 칼리첵이 포크 상황 시 흥분하지 않는 게 최선이라고 말하는 이유이기도 하다. 그는 “CIO에게 할 수 있는 가장 좋은 조언은 긴장을 풀고 2개의 프로젝트가 어떻게 발전하는지, 어느 프로젝트가 더 좋은 기능을 가지고 있는지 관찰하라는 것이다. 어느 쪽을 선택할지 몇 달 안에 결정하면 된다. 즉시 선택할 필요가 전혀 없다"라고 말했다. ciokr@idg.co.kr