Deno가 Cloudflare에 합류한다면, 오픈소스는 무엇을 얻고 잃을까

핵심 요약

• Deno 런타임과 호스팅 서비스인 Deno Deploy는 서로 다른 제품입니다.
• 개발팀이 기업에 합류했다고 해서 오픈소스 개발을 중단한다고 단정할 수는 없습니다.
• 클라우드 기업이 지원하면 개발에 쓸 자원을 확보하기 쉽지만, 제품의 우선순위도 영향을 받을 수 있습니다.
• 다른 클라우드로 옮기기 쉬운지는 코드 공개 여부뿐 아니라 저장소와 배포 방식에도 달려 있습니다.

Deno 팀이 Cloudflare에 합류하고 Deno Deploy가 종료되는 상황을 가정해 보겠습니다. 개발자라면 당장 “내 서비스도 바꿔야 하나?”라는 생각이 들 겁니다. 답을 찾으려면 팀의 소속이 바뀌는 일과 런타임 개발이 이어지는 일을 구분해야 합니다. 호스팅 서비스가 어떻게 되는지도 따로 봐야 합니다.

Deno Deploy가 끝나면 Deno도 끝날까요

런타임은 프로그램을 실제로 실행하는 소프트웨어입니다. Deno는 JavaScript와 TypeScript를 실행하는 런타임이고, Deno Deploy는 애플리케이션을 배포하고 운영하는 호스팅 서비스입니다.

두 제품은 밀접하게 연결돼 있지만 같은 제품은 아닙니다. 호스팅 서비스가 종료돼도 런타임의 소스코드는 남고 개발도 이어질 수 있습니다. 반대로 코드를 공개해 두었더라도 유지보수 인력이 줄면 업데이트가 더뎌질 수 있습니다.

개발팀이 기업에 합류하는 것도 별개의 문제입니다. 팀이 소속을 바꿨다는 사실만으로 기존 런타임 개발을 접었다고 볼 수는 없습니다. 개발을 계속할지 확인해야 합니다. 다른 프로젝트에 집중하거나 유지보수만 하는 쪽으로 바뀌는지도 살펴봐야 합니다.

사용자 입장에서는 “Deno가 끝나는가”라는 질문만으로 상황을 판단하기 어렵습니다. 내가 쓰는 실행 도구의 지원이 끝나는지, 서비스를 올려 둔 곳이 없어지는지 구체적으로 알아야 합니다. 어느 쪽이냐에 따라 대응도 달라집니다.

코드는 무료로 공개해도, 개발비는 계속 듭니다

오픈소스 프로젝트의 코드는 누구나 볼 수 있습니다. 그렇다고 누구나 그 프로젝트를 계속 운영할 여력까지 있는 것은 아닙니다.

런타임은 보안 문제를 고치고 운영체제에 맞춰 손봐야 합니다. 기존 프로그램이 새 버전에서도 제대로 돌아가는지 확인해야 합니다. 사용자 문의에 답하고 문서를 관리하는 데도 사람이 필요합니다.

호스팅 사업까지 운영하면 맡아야 할 일이 더 늘어납니다. 서버 비용을 내야 하고, 장애가 나면 복구해야 합니다. 개발 도구를 잘 만드는 능력에 더해 서비스를 안정적으로 운영하는 능력도 필요합니다.

이런 팀이 Cloudflare 같은 인프라 기업에 합류하면 인력과 운영 기반을 공유할 수 있습니다. 개발에 쓸 자원을 확보하는 데도 도움이 됩니다. 다만 이는 합류를 설명할 수 있는 사업 논리일 뿐, 특정 팀이 실제로 그 이유 때문에 합류했다고 입증하지는 못합니다.

합류 이후에 어떤 변화가 생기는지도 봐야 합니다. 지원하는 기업이 생기면 프로젝트가 오래 이어질 가능성은 커질 수 있습니다. 다만 어떤 기능부터 만들지는 그 기업의 사업 방향에 따라 달라질 수 있습니다.

코드가 열려 있어도 클라우드 이사는 어렵습니다

“오픈소스니까 다른 곳으로 옮기면 된다”고 생각할 수도 있습니다. 애플리케이션의 실행 코드만 놓고 보면 맞는 말일 수 있습니다. 하지만 실제 서비스를 옮길 때는 코드 외에도 챙겨야 할 것이 많습니다.

작은 예약 서비스를 예로 들어 보겠습니다. 예약 처리 코드는 JavaScript로 작성했더라도 고객 정보는 특정 클라우드의 데이터베이스에 저장할 수 있습니다. 확인 메일을 보내는 데 그 플랫폼의 예약 작업 기능을 쓸 수도 있습니다.

이런 서비스를 옮기려면 실행 환경만 바꿔서는 안 됩니다. 데이터를 옮기고 예약 작업을 다시 구성해야 합니다. 장애 알림도 연결해야 하고요. 플랫폼 전용 기능을 많이 쓸수록 손볼 부분이 늘어납니다.

클라우드 종속은 이렇게 편리한 기능을 하나씩 쓰면서 생깁니다. 그렇다고 반드시 나쁜 선택은 아닙니다. 당장 개발에 드는 시간과 운영 부담을 크게 줄여줄 수 있으니까요.

다만 지금 누리는 편리함이 나중에 서비스를 옮길 때는 비용으로 돌아올 수 있습니다. 소스코드를 공개했는지와 서비스를 다른 곳으로 옮길 수 있는지는 따로 따져봐야 합니다.

개발자가 봐야 할 것은 간판보다 유지보수와 이전 조건입니다

개발팀이 다른 회사로 옮긴다면 기존 프로젝트의 업데이트가 어떻게 이어지는지부터 봐야 합니다. 누가 보안 문제를 고치는지, 기존 사용자를 위한 릴리스가 계속 나오는지가 실제 서비스 운영에 영향을 줍니다.

프로젝트에서 누가 어떤 결정을 내리는지도 중요합니다. 외부 개발자가 코드 수정을 제안할 수 있다고 해서 제품의 방향까지 정할 수 있는 것은 아닙니다. 코드가 공개돼 있어도 운영 주체의 영향력은 남습니다.

호스팅 종료가 발표되면 실제로 서비스를 옮기는 데 필요한 조건부터 확인해야 합니다. 서비스 종료일과 데이터 반출 방법을 알아보고, 대체 환경에서 어떤 기능을 지원하는지도 살펴봐야 합니다. 소규모 서비스를 먼저 옮겨 보면 예상하지 못한 의존성을 발견하는 데 도움이 됩니다.

오픈소스 팀이 안정적으로 개발할 여건을 갖추면 사용자에게도 도움이 될 수 있습니다. 그 이익이 오래가려면 유지보수가 이어져야 하고, 사용자에게 다른 환경을 선택할 여지도 남아 있어야 합니다. 지금 쓰는 클라우드를 떠나야 할 때 코드 외에 무엇을 함께 옮겨야 하는지 미리 확인해 둘 필요가 있습니다.